Dieser Beitrag ist ein Anhang zum ursprünglichen Beitrag vom 10.1.2017 mit dem Titel 2017 Machine Translation Quality Evaluation.

Experimentelles Design

Wir werten alle maschinellen Übersetzungssysteme für Englisch-Französisch und Englisch-Deutsch aus. Wir melden BLEU-4 ohne Groß-Kleinschreibungsberücksichtigung [2], berechnet vom Scoring-Skript mteval aus dem Open-Source-Toolkit Phrasal der Universität Stanford. NIST-Tokenisierung wurde auf beide Systemoutputs und die Referenzübersetzungen angewendet. Wir simulieren das Szenario, in dem die Übersetzerin die Auswertungsdaten sequenziell von Anfang an bis zum Ende übersetzt. Wir setzen voraus, dass sie die Ressourcen der entsprechenden Lösungen vollständig nutzt, indem sie das Translation Memory as Anpassungen nutzt und inkrementell anpasst, wobei das Übersetzungssystem aus jedem bestätigten Segment lernt.

Systemoutputs und Skripte zum automatischen Herunterladen und Aufteilen der Testdaten sind unter https://github.com/lilt/labs verfügbar.

Systemtraining

In allen Experimenten werden Produktions-API-Keys und Systeme verwendet. Weil kommerzielle Systeme von Zeit zu Zeit verbessert werden, zeichnen wir das Datum auf, an dem die Systemoutputs generiert wurden.

Lilt

Das Lilt-Baseline-System, das über die REST-API mit einem Produktions-API-Key verfügbar ist. Das System kann mit der folgenden Reihe von API-Aufrufen reproduziert werden:

• POST /mem/create (create new empty Memory)
• Für jedes Quellsegment im Testsatz:
• GET /tr (translate test segment)

28.12.2016

Lilt-angepasst

Das adaptive Lilt-System, das über die REST-API mit einem Produktions-API-Key verfügbar ist. Das System simuliert ein Szenario, in dem ein bestehendes Korpus von Quell-/Zieldaten vor der Übersetzung des Testsatzes zum Training hinzugefügt wird. Das System kann mit der folgenden Reihe von API-Aufrufen reproduziert werden:

• POST /mem/create (create new empty Memory)
• Für jedes Quell-/Zielpaar in den TM-Daten:
• POST /mem (update Memory with source/target pair)
• Für jedes Quellsegment im Testsatz:
• GET /tr (translate test segment)

6.1.2017

Lilt interaktiv

Das interaktive adaptive Lilt-System, das über die REST-API mit einem Produktions-API-Key verfügbar ist. Das System simuliert ein Szenario, in dem ein bestehendes Korpus von Quell-/Zieldaten vor der Übersetzung des Testsatzes zum Training hinzugefügt wird. Um Feedback von einem menschlichen Übersetzer zu simulieren, wird jede Referenzübersetzung für jeden Quellsatz im Testsatz nach der Decodierung dem Speicher hinzugefügt. Das System kann mit der folgenden Reihe von API-Aufrufen reproduziert werden:

• POST /mem/create (create new empty Memory)
• Für jedes Quell-/Zielpaar in den TM-Daten:
• POST /mem (update Memory with source/target pair)
• Für jedes Quellsegment im Testsatz:
• GET /tr (translate test segment)
• POST /mem (update Memory with source/target pair)

4.1.2017

Google

Das statistische phrasenbasierte maschinelle Übersetzungssystem von Google. Das System kann durch Abfragen der Translate-API reproduziert werden:

• Für jedes Quellsegment im Testsatz:
• GET https://translation.googleapis.com/language/translate/v2?model=base

28.12.2017

Google neuronal

Das neuronale maschinelle Übersetzungssystem (GNMT) von Google (GNMT). Das System kann durch Abfragen der Premium-API reproduziert werden:

• Für jedes Quellsegment im Testsatz:
• GET https://translation.googleapis.com/language/translate/v2?model=nmt

28.12.2016

Microsoft

Das statistische maschinelle Baseline-Übersetzungssystem von Microsoft. Das System kann durch Abfragen der Text Translation-API reproduziert werden:

• Für jedes Quellsegment im Testsatz:
• GET /Translate

28.12.2016

Microsoft angepasst

Das statistische maschinelle Übersetzungssystem von Microsoft. Das System simuliert ein Szenario, in dem ein bestehendes Korpus von Quell-/Zieldaten vor der Übersetzung des Testsatzes zum Training hinzugefügt wird. Wir erstellen zunächst ein neues allgemeines Kategorieprojekt in Microsoft Translator Hub, dann ein neues System in diesem Projekt, und laden das Translation Memory als Trainingsdaten hoch. Wir stellen keine Tuning- oder Testdaten zur Verfügung, sodss diese automatisch ausgewählt werden. Wir warten, bis der Trainingsprozess abgeschlossen ist, und stellen das System dann bereit (z. B. mit Kategorie-ID CATEGORY_ID). Dann decodieren wir den Testsatz durch Abfragen der Text Translation-API und geben den Spezifizierer des bereitgestellten Systems als Kategorie-ID weiter:

• Für jedes Quellsegment im Testsatz:
• GET /Translate?category=CATEGORY_ID

30.12.2016 (nach der Migration von Microsoft Translator zum Azure-Portal)

Microsoft neuronal

Dasneuronale maschinelle Übersetzungssystem von Microsoft. Das System kann durch Abfragen der Text Translation-API mit der Kategorie-ID „generalnn“ reproduziert werden:

• Für jedes Quellsegment im Testsatz:
• GET /Translate?category=generalnn

Systran neuronal

Das „rein neuronale“ neuronale maschinelle Übersetzungssystem von Systran. Das System kann über die Demo-Website reproduziert werden. Wir kopierten die Quelle manuell in Chargen von nicht mehr als 2000 Zeichen in die Website. Wir bestätigten, dass die Zeilenumbrüche eingehalten wurden und die Chargenerstellung sich nicht auf das Übersetzungsergebnis auswirkte. Dies war mit erheblichem manuellem Aufwand verbunden und fand im Laufe von mehreren Tagen statt.

Daten: en-de: 2016–12–29–2016–12–30; en-fr: 2016–12–30–2017–01–02

SDL

Das maschinelle Übersetzungssystem Language Cloud von SDL. Das System kann durch eine Vorübersetzungs-Batch-Task in Trados Studio 2017 reproduziert werden.

3.1.2017

SDL angepasst

Das maschinelle Übersetzungssystem „AdaptiveMT“ von SDL, auf das über Trados Studio 2017 zugegriffen wird. Das System kann durch Erstellen einer neuen AdaptiveMT-Engine spezifisch für ein neues Projekt und Vorübersetzung des Testsatzes reproduziert werden. Das neue Projekt wird mit den TM-Daten initialisiert. Wir setzen voraus, dass die lokalen TM-Daten für das Online-Retraining an die AdaptiveMT-Engine weitergegeben werden. Die Vorübersetzungs-Batch-Task dient dazu, Übersetzungen für alle nicht 100%igen Übereinstimmungen zu generieren. Der TM-Inhalt wird angepasst. In den anpassungsbasierten Experimenten bestätigten wir nicht jedes Segment mit einer Referenzübersetzung, weil dazu zu viel manuelle Arbeit in Trados Studio 2017 erforderlich gewesen wäre.

Die Systeme Lilt angepasst, Microsoft angepasstund SDL angepasst sind am besten vergleichbar, weil sie im Batch-Modus angepasst wurden, also durch das Hochladen aller TM-Daten, das vollständige Training und dann das Decodieren des Testsatzes. Natürlich können andere wesentliche, aber nicht vom Benutzer modifizierbare Faktoren wie Baseline-Korpora, Optimierungsverfahren und Optimierungskriterien unterschiedlich sein und sind dies wahrscheinlich auch.

Testkorpora

Wir definierten vier Anforderungen für das Testkorpus:

1. Es ist für typische bezahlte Übersetzungsarbeit repräsentativ
2. Es wird nicht in den Trainingsdaten für eines der konkurrierenden Übersetzungssysteme verwendet
3. Die Referenzübersetzungen wurden nicht durch Post-Editing aus einer der konkurrierenden maschinellen Übersetzungslösungen produziert
4. Es ist groß genug, um Modellanpassung zu erlauben

Weil alle Systeme in der Bewertung kommerzielle Produktionssysteme sind, konnten wir weder einen gemeinsamen Datenzustand durchsetzen noch den Ausschluss von Testdaten aus den Baseline-Korpora als Anforderung sicherstellen (2). Trotzdem ist es in der Praxis relativ einfach, den Einschluss von Testdaten in das Trainingskorpus eines Systems über das folgende Verfahren zu erkennen:

1. Kandidaten-Testdatensatz wählen
2. Testsatz mit allen nicht angepassten Systemen decodieren und mit BLEU bewerten
3. Systeme identifizieren, die signifikant vom Mittelwert abweichen (in unserem Fall um zwei Standardabweichungen)
4. Wenn ein System existiert in (3):
5. Nehmen Sie eine Probe eines Teilsatzes von Sätzen und vergleichen Sie den MT-Output mit den Referenzen.
6. Sind Referenzübersetzungen vorhanden,
7. eliminieren Sie den Kandidaten-Testdatensatz und gehen zu (1)
8. Akzeptieren Sie den Kandidaten-Testdatensatz

Ab November 2016 bewerteten wir die acht öffentlichen Datensätze, die im Anhang beschrieben werden, auf diese Kriterien hin. Das neunte Korpus, das wir ausprobiert haben, war SwissAdmin. Es befriedigte unsere Anforderungen und bestand unsere Datenauswahlverfahren.

SwissAdmin ist eine mehrsprachige Sammlung von Pressemitteilungen der Schweizer Regierung von 1997 bis 2013. Wir verwendeten die jüngsten Pressemitteilungen. Wir teilten die Daten chronologisch auf und reservierten die letzten 1300 Segmente der Artikel von 2013 als Englisch-Deutsch-Testdaten und die letzten 1320 Segmente als Englisch-Französisch-Testsatz. Chronologische Aufteilungen sind in der MT-Forschung Standard, um Änderungen im Sprachgebrauch im Laufe der Zeit zu berücksichtigen. Die Testsätze wurden zusätzlich gefiltert, um ein einzelnes Segment zu entfernen, das mehr als 200 Token enthielt. Die übrigen Artikel von 2011 bis 2013 wurden als domäneninterne Daten für die Systemanpassung reserviert.

SwissAdminen-deen-frTMtestTMtest#segments18,6211,29918,1631,319#words548,435 / 482,69239,196 / 34,797543,815 / 600,58540,139 / 44,874

Ergebnisse

(Aktualisiert mit neuronaler MT von Microsoft)

Anhang: Kandidaten-Datensätze

Die folgenden Datensätze wurden nach dem im Abschnitt Testkorpora angegebenen Verfahren beurteilt und abgelehnt:

• JRC-Acquis
• PANACEA Englisch-Französisch
• IULA Spanisch-Englisch Technisches Korpus
• MuchMore Springer Zweisprachiges Korpus
• WMT Biomedizinische Aufgabe
• Autodesk Post-Editing-Korpus
• PatTR
• Reisedomänendaten (von booking.com und anderswo) per Crawler in Lilt integriert

1 Wir konnten kein interaktives SDL-System produzieren, das mit dem interaktiven Lilt-System vergleichbar ist. Zunächst versuchten wir, die Referenzübersetzungen in Trados Studio zu bestätigen. Wir stellten jedoch fest, dass diese Modellaktualisierungen oft eine Minute oder mehr an Verarbeitungszeit in Anspruch nehmen. Angenommen, das Einfügen der Referenz in die Benutzeroberfläche erfordert 15 Sekunden und die Modellaktualisierung 60 Sekunden. Für en-de wären 1299 * 75 / 3600 = 27,1 Stunden, die notwendig wären, um den Testsatz zu übersetzen. Wir versuchten dann, Schnittstellenmakros zu programmieren, um die Übersetzung und Bestätigung von Segmenten in der Benutzeroberfläche zu automatisieren, aber die Variabilität der Modellaktualisierungen und andere UI-Faktoren wie Scrollen verhinderten eine erfolgreiche Automatisierung des Prozesses. Die Abwesenheit einer Übersetzungs-API verhinderte die massenhafte Fertigstellung der Aufgabe mit Amazon Mechanical Turk.