In diesem Artikel erfahren Sie, wie Lilt Unmengen von Daten und mathematischen Gleichungen in natürliche Übersetzungen umwandelt. Modelle für maschinelle Übersetzungen können wie Zauberkunst erscheinen, aber wir lassen Sie hier einen Blick hinter die Kulissen werfen!

Datenerfassung

Das Trainieren eines Modells für maschinelle Übersetzung (MT) ist wie Kochen mit einem Rezept. Sie müssen die Schritte befolgen, aber die Zutaten müssen frisch sein, damit das Gericht gut schmeckt.

Lilt nutzt sowohl offene als auch kostenpflichtige Datenquellen, um an Paralleltexte zu gelangen, die Schlüsselkomponente für Übersetzungen mit MT-Modellen.

Offene Quellen sind frei verfügbare und geprüfte Quellen für Paralleltextdaten, in der Regel über die Lizenz CC-BY oder CC-BY-SA. Zu den Quellen zählen Opus, Paracrawl und CCMatrix.

Bezahlte Quellen sind solche, die unter der Lizenz CC-NC entwickelt werden, wodurch sie nur für nichtkommerzielle und forschungsorientierte Zwecke verwendbar sind. Wir müssen eine Gebühr zahlen, damit wir sie in unseren Modellen verwenden können. Ein Beispiel hierfür ist WIPO COPPA V2.

Wenn es um die Datengröße geht, so ist mehr immer besser. Mehr Daten führen generell zu qualitativ hochwertigeren MT-Modellen. Bis heute konnten wir 3,8 Milliarden Segmente für insgesamt 76 Sprachpaare zusammenstellen.

Datenvorbereitung

Jedes Datenelement, das wir von den o. a. Quellen erhalten, wird sorgfältig verarbeitet. Es genügt zu sagen, dass die Vorbereitung der Daten eine Herkules-Aufgabe ist. Und dabei haben wir mit dem Training noch gar nicht angefangen. Und so funktioniert es!

Bereinigen und validieren

Wir führen eine grundlegende Syntax-basierte Bereinigung der Daten durch, die die folgenden Schritte umfasst:

1. Entfernen leerer Sätze
2. Entfernen von Sätzen, die nur Satzzeichen enthalten
3. Sicherstellen, dass die ausgangs- und zielsprachlichen Dateien eine passende Anzahl von Segmenten umfassen (wenn nicht, wird der Ausgangstext verworfen)

Versionieren der Daten

Wir versionieren unsere Daten mit DVC, da wir so die ausgangssprachlichen und zielsprachlichen Dateien sowie zusätzliche interne Tracker-Dateien zu einer Einheit kombinieren können. Diese Einheit ist eine .dvc-Datei, die an unseren Github übermittelt wird, sodass alle Datenquellen protokolliert werden können, die wir verwenden.

Normalisieren der Segmente

Um die Einheitlichkeit aller Segmente sicherzustellen, führen wir die folgenden Schritte durch:

1. Unicode-Normalisierung: Texte in Uncode oder HTML werden zu menschenlesbaren Texten konvertiert. Zum Beispiel wird „Broken text… it’s flubberific!“ konvertiert zu „BrokenText… it’s flubberific!“.
2. Normalisierung von geschützten Leerzeichen: Für Sprachen wie Französisch, wo es strenge Regeln für die Positionierung von geschützten Leerzeichen gibt, werden bei diesem Schritt die Leerzeichen dort hinzugefügt, wo dies erforderlich ist (wenn es sie nicht schon gibt).
   
   

Filter

Zuerst entfernen wir potenziell problematische Segmente eines Korpus auf Segment- oder Segmentpaar-Ebene. Dies ist als individuelle Filtrierung bekannt

1. Skript: Wir können davon ausgehen, dass ein JA-Segment (Japanisch) mit einem TA-Token/Satz (Tamil) für das Training nicht wirklich verwendbar ist. Wir führen Regeln für Skripte, die nicht effektiv sind, wenn sie in ein anderes Skript eingebettet werden, und entfernen diese Segmente.
2. Sprachcode: Wir verwenden das Paket „python cld3“, um die Sprache eines Segments zu identifizieren. Wenn sie nicht mit der Korpus-Sprache übereinstimmt, wird es weggelassen.
3. Ausschlussmuster: Wir schließen Segmente aus, die Regex-Formeln entsprechen, die auf problematische Muster hinweisen (z. B. „http://“ für URLs).
4. Segmentlänge: Wir schließen alle Segmente aus, die länger als 300 Wörter sind (dies kann je nach Sprache konfiguriert werden).
5. Zahlen: Wir schließen jedes Segmentpaar aus, das dasselbe Zahlensystem verwendet, aber andere Zahlen in den Ausgangs- und Zielsegmenten enthält.
6. Längenverhältnis: Wir schließen alle Segmente aus, in denen Ausgangs- oder Zielsegmente ungewöhnlich lang oder kurz sind (für ein Segmentpaar), nachdem wir es mit einem für den gesamten Korpus ermittelten Schwellenwert verglichen haben.
7. Editierdistanz: Wir schließen alle Segmente aus, in denen die Ausgangs- und Zielsegmente identisch oder ähnlich sind, da dies auf eine falsche Übersetzung hinweisen kann. Wir prüfen die Editierdistanz zwischen den Segmenten anhand eines Mindestwerts von 0,2.
   
   

Datenaugmentierung

Bei unbekannten oder unterrepräsentierten Daten kann es sein, dass die Modelle für maschinelle Übersetzungen ausfallen und sogenannte „Halluzinationen“ erzeugen, d. h. übersetzter Text, der stark vom ursprünglichen Ausgangstext abweicht. Um diesem Problem entgegenzuwirken, erzeugen wir künstlich Beispiele für parallele Satzstrukturen. Das Training mit den künstlichen Beispielen verbessert die Robustheit und Widerstandsfähigkeit des Modells gegenüber diesen Daten, sodass wir eine Vielzahl von Kundendomänen effektiv übersetzen können. Wir ergänzen vorhandene Segmentpaare wie folgt:

1. Mehrere Segmente: Wir verbinden bis zu 5 aufeinanderfolgende Segmente zu einem einzigen langen Segment.
2. Großschreibung: Wir verwenden die Großschreibung für die ausgewählten Segmente (d. h. entweder GROSSSCHREIBUNG oder nur Großschreibung der Anfangsbuchstaben).
3. Nicht zu übersetzende Inhalte: Wir führen nicht übersetzbare Inhalte, die unsere Kunden verwenden, ein, indem wir gemeinsame Token/Sätze in Ausgangs- und Zielsegmenten erfassen und diese in spezielle Zeichen einfassen ($,{ und }).

Byte-Paar-Codierung (BPE)

Der Wortschatz für einen großen Korpus kann riesig sein, wobei viele Wörter nur selten vorkommen. Bei der Byte-Paar-Codierung (BPE) der Wörter werden diese in Wortstücke aufgeschlüsselt (d. h. eating wird ggf. aufgeschlüsselt in eat und ing). So können wir das Volumen des Vokabulars korrigieren und auch die Größe unseres MT-Modells und so auch die Ressourcen, die für das Training des Modells erforderlich sind.

Mit BPE können wir zudem Segmente mit Token übersetzen, die nicht im Trainings-Korpus aufgetaucht sind, was bei morphologisch vielseitigen Sprachen wie den romanischen und slawischen Sprachen häufig vorkommt, da wir Token in bekannte Wortstücke aufteilen können.

Training der MT-Modelle

Seitdem es die Transformer-Architektur gibt, haben auch wir unsere Übersetzungsmodelle darauf aufgebaut.

Bevor wir uns aber den Besonderheiten des Transformer-Modells zuwenden, wollen wir kurz einen Umweg zu einem Konzept machen, das als Einbettungsraum oder kontinuierlicher Repräsentationsraum bekannt ist. Jeder Punkt in diesem hochdimensionalen Raum stellt die Bedeutung eines Satzes dar. Zwei Sätze, die sich ähnlich sind, haben Repräsentationen nahe beieinander. Sie können also selbst erkennen, wie dieses Konzept in die Gestaltung eines Modells für maschinelle Übersetzungen passt. Wir entwickeln einfach zwei Komponenten:

Encoder: Diese Komponente nimmt einen ausgangssprachlichen Satz und wandelt diesen in die Repräsentation des Einbettungsraums um.

Decoder: Diese Komponente nimmt die Repräsentation des Einbettungsraums und wandelt sie in einen Satz (oder mehrere Sätze) der Zielsprache um.

Der Encoder und der Decoder bilden zusammen ein maschinelles Übersetzungsmodell für ein bestimmtes Sprachpaar. Sequence-to-sequence (seq2seq) ist ein Sammelbegriff für die Modelle, bei denen diese Encoder-Decoder-Architektur verwendet wird. Der Transformer gilt unter diesen als besonders leistungsstark.

Und so sieht ein Transformer-Modell aus:

Angesichts der Architektur müssen wir die Größe des Modells wählen. Die Modellgröße richtet sich nach der Anzahl der Parameter und gleicht der Kapazität eines Hotels. Die Informationen, die wir beim Training aus dem Korpus gewonnen haben, verhalten sich analog zu der Anzahl der Personen, die sich tatsächlich im Hotel befinden.

Unser Ziel ist die maximale Auslastung. Daher verwenden wir die Anzahl der Sätze im Parallelkorpus, die aus der Datenvorbereitung stammen, für die Feststellung, welche Modellgröße sich für ein bestimmtes Sprachpaar am besten eignet:

- Kleines Modell, wenn weniger parallele Satzpaare vorhanden sind, z. B. Englisch → Hindi

- Großes Modell, wenn eine Vielzahl an parallelen Satzpaaren vorhanden ist, z. B. Englisch → Deutsch

Und dann trainieren wir das Modell. Die Einzelheiten könnten in einem zukünftigen Blog-Beitrag weiter beschrieben werden. Es reicht, wenn wir hier sagen, dass wir Unmengen an Hochleistungsknoten hochfahren, das Modell mit den während der Datenvorbereiten aufbereiteten Daten trainieren und die Leistung des Modells mit Testsätzen von Organisationen wie WMT, TED und akademischen Gruppen wie LTI vergleichen.

Um die Modelle zu bewerten, verwenden wir automatische Kennzahlen wie den BLEU-Score, der uns bei der Beantwortung von Fragen nach objektiven Bewertungsmöglichkeiten für ein gutes Modell zum Beispiel für Englisch>Französisch hilft.

Wenn alle Tests bestanden wurden, übergeben wir das Modell an unsere Produktionsserver und unsere Übersetzer können es sofort verwenden!