KI in der Übersetzungsbranche – mehr als „nur“ Machine Translation

Einleitung

In diesem Artikel möchten wir kurz auf die verschiedenen Bereiche in der Übersetzungsbranche eingehen, die von der Einführung künstlicher Intelligenz – insbesondere maschineller Übersetzung (MÜ oder engl. MT) – profitieren würden. Künstliche Intelligenz (KI) ist nicht zu 100 % berechenbar und die Implementierung jeglicher KI birgt natürlich auch neue Risiken. Die Folgen, durch die Einführung von KI oder den Austausch bewährter Algorithmen durch KI, können also unvorhergesehene Auswirkungen mit sich bringen… aber auch eine positive Wendung!

Im linguistischen Bereich lässt sich eine stetige Weiterentwicklung maschineller Übersetzung beobachten. MÜ dient als bestes Beispiel für maschinelles Lernen (ML). Zudem wissen wir bereits, was wir von MÜ erwarten können, was die Vorteile sind und wie wir den Risiken entgegenwirken können. Abhängig davon, wie wir mit MÜ umgehen, bietet sich uns zudem die Möglichkeit, ML zur weiteren Optimierung anzuwenden. Zum Beispiel für Entscheidungen, die auf Basis gesammelter Informationen automatisiert getroffen werden, um Mitarbeiter entweder mit Hinweisen zu versorgen oder diese sogar zu ersetzen, um Kapazitätsengpässe im Bereich Continuous Development/Continuous Translation zu vermeiden. Aber auch für die Erstellung von Prognosen und die Aufdeckung potenzieller Risiken wie verspätete Liefertermine oder das Abspringen eines Kunden – und vielleicht sogar um korrektive Maßnahmen vorzuschlagen.

Maschinelles Lernen kann in verschiedenen Bereichen und für verschiedene Lernansätze angewendet werden (z. B. geführtes oder selbstständiges Lernen, bestärkendes Lernen, Transferlernen, etc.). Die Suche nach der besten Kombination gestaltet sich als sehr interessant, weshalb wir darauf im Folgenden gerne näher eingehen möchten.

Erste Schritte: Vendoren durch ML vorschlagen lassen

Vor einigen Jahren haben wir unsere Projektmanager in einer Umfrage dazu befragt, in welchem Bereich ML ihre Arbeit beschleunigen und vereinfachen würde. Wie sich herausstellte, verbringen Projektmanager viel Zeit damit, nach geeigneten Vendoren für bestimmte Jobs zu suchen – was sich als eher lästig erwiesen hat. Aus diesem Grund haben wir begonnen, mit ML zu experimentieren, um den am besten geeigneten Vendor für ein Projekt zu finden.

Zunächst wollten wir herausfinden, wie realistisch es ist, dass ein neuronales Netzwerk dahingehend trainiert werden kann, dass es die gleichen Entscheidungen trifft, die ein Projektmanager treffen würde. Dafür haben wir die initialen Daten zur Hand genommen und Vendoren von zehntausenden bereits abgeschlossenen Jobs zugewiesen, um das Modell mit Infos zu füttern und zu trainieren. Obwohl es eine Reihe fortschrittlicher Architekturen neuronaler Netzwerke gibt, haben wir uns für ein simples Regressions-/Klassifizierungsmodell entschieden – was gut funktioniert hat. Bei der nachträglichen Prüfung hat sich gezeigt, dass das Modell in mehr als 99 % der Fälle die richtige Entscheidung getroffen hat. Als wir versucht haben, das Modell in der Realität anzuwenden, zeigte sich jedoch, dass die ausgewählten Vendoren oft nicht geeignet waren. Das war unter anderem darauf zurückzuführen, dass Vendoren in der Vergangenheit oft einem Job zugewiesen wurden, für den sie aus heutiger Sicht nicht geeignet waren. Hier spricht man auch von „Garbage in – Garbage out“ (Müll rein, Müll raus).

Den Tätigkeitsbereich der Projektmanager neu evaluieren

Erst vor kurzem haben wir eine Umfrage durchgeführt, um herauszufinden, welche Tätigkeiten im Bereich Projektmanagement die meiste Zeit in Anspruch nehmen. Zudem waren wir interessiert daran zu erfahren, in welchen anderen Bereichen die Einführung von ML sinnvoll sein könnte. Die Ergebnisse der Umfrage haben gezeigt, dass die Suche nach einem geeigneten Vendor dabei nach wie vor ganz vorne steht, aber auch, in welchen anderen Bereichen wir diesbezüglich noch aufholen können.

In der nachfolgenden Tabelle zeigen wir die Tätigkeiten, die wir im Projektmanagement optimieren werden sowie unserer Ideen, wie wir eine bestimmte Tätigkeit, zumindest teilweise oder sogar komplett, automatisieren können.

Der Begriff System bezieht sich dabei auf unser Projektmanagement- bzw. ERP-System.

Manuelle Tätigkeiten	Wie können wir die Tätigkeit durch ML zumindest teilweise automatisieren?	Wie können wir die manuelle Tätigkeit eliminieren?
Suche nach Ressourcen	Ressourcen (Vendoren, TMs, Glossare, etc.) aus ähnlichen Projekten vorschlagen lassen	Den für einen Job am besten geeigneten Vendor auf Basis bestimmter Kriterien, wie Sprachkombination, Domain, Qualifikation, Erfahrung, Preis, Verfügbarkeit, Produktivität, Feedback durch PM/Korrekturleser, etc. auswählen lassen
Projektvorbereitung und -planung	Projekt-Workflow auf Basis des SLAs und anderen ähnlichen abgeschlossenen Projekten vorschlagen lassen, Analyse des kritischen Pfades des Projekts und zeitliche Prognose der einzelnen Projektschritte	–
Manuelle Vorbereitung der Anweisungen für Vendoren	Filtern der wichtigsten Vorgaben und Erstellung strukturierter Anweisungen für die Vendoren auf Basis dieser Vorgaben	–
Überwachung der Liefertermine	Echtzeit-Analyse zur Prognose von Verzögerungen auf Basis von Vergangenheitsdaten und Benachrichtigungen für PMs	Schon durch wenige automatische Kontrollen können Liefertermine zuverlässig überwacht und manuelle Tätigkeiten eliminiert werden
Korrektur der Daten im System	Einheitlichkeit der Daten auf Basis gängiger Muster im Systemhintergrund analysieren, Benachrichtigung der zuständigen Mitarbeiter bezüglich potenziell inkorrekter Daten	–

Vendor Suggestion 2.0 – Vendoren vorschlagen lassen

Wie oben im Text beschrieben, ließen sich durch ML zwar Vendoren vorschlagen, aber oft waren die Vorschläge aus Sicht einiger Projektmanager nicht passend. Daher haben wir uns folgende Lösungen überlegt:

1. Einbeziehen des Faktors von wem das Projekt geleitet wird und wer demnach die automatischen Vorschläge erhält. Dieser Punkt ermöglicht die individuelle Anpassung der ML-Ergebnisse auf Basis einzelner Personen und Abteilungen, sodass die gesammelten Daten auf verschiedene Projektmanager angewendet werden können und gleichzeitig keine ungeeigneten Vendoren mehr vorgeschlagen werden.
2. Reduzierung der Gewichtung der Einträge im Bereich Training/Prüfung, da diese obsolet werden. Das bedeutet, dass aktuellere Daten mehr Gewichtung erhalten als Daten, die bereits fünf Jahre alt sind. Daten die älter als fünf Jahre sind, werden nicht berücksichtigt.

Die Ergebnisse aus der Anwendung dieser Architektur wurden noch nicht ausgewertet, aber wir haben bereits jetzt neue Anpassungen für den nächsten Durchlauf gesammelt. Anstatt das Modell anhand der Daten der letzten fünf Jahre komplett neu zu trainieren, werden wir versuchen, auf bestärkendes Lernen der Daten umzusteigen, die erst nach dem initialen Training des Netzwerks erfasst werden.

Abgesehen davon können wir neue Projekte mit abgeschlossenen Projekten auf Basis bestimmter Kriterien vergleichen, wie z. B. Kunde/Account, Sprachkombination(en), Domain und SLA, aber auch auf Basis eines linguistischen Auszuges des zu übersetzenden Textes (Hallo natürliche Sprachverarbeitung!). Zudem können wir, wo möglich, Ressourcen aus ähnlichen, bereits abgeschlossenen Projekten wiederverwenden.

Was steht noch auf der ML-Roadmap?

Korrektur der Daten im System

Bei der Verarbeitung der Daten aus bereits abgeschlossenen Projekten in unserer Datenbank, sind uns einige Inkonsistenzen aufgefallen. Bei der genaueren Analyse der Daten haben wir festgestellt, dass mit nur etwas mehr Aufwand inkorrekte Daten, die die Arbeit der Projektmanager erheblich erschweren, mit einer höheren Bestimmtheit identifiziert werden können. Falsche Daten können zum Beispiel durch Fehler durch den Benutzer, Fehler im Programmcode oder auch durch Tippfehler entstehen. Ganz egal, wo der Fehler entstanden ist, wichtig ist, ihn zu identifizieren – und es gibt keinen Grund, dies nicht zu tun.

Fehlerhafte Daten können zum Beispiel mittels Analyse während einer geplanten Datenverarbeitung oder in einer separaten Datenanalyse festgestellt werden. Bei beiden Punkten ist das Ziel die Identifizierung der Fälle, die einem bestimmten Muster nicht entsprechen (gemäß eines Regressionsmodells). Die automatisierte Korrektur potentiell fehlerhafter Daten wäre jedoch zu riskant. Es ist daher völlig ausreichend, wenn die potenziellen Fehler an den zuständigen Mitarbeiter weitergeleitet werden, der diese dann prüfen und, falls nötig, korrigieren kann.

Projektvorbereitung und -planung

In der Anfangsphase eines Projekts, wie der Angebotserstellung oder der Projektfreigabe, ist es oftmals nötig, eine realistische Bearbeitungsdauer anzugeben. Um dies zu tun, müssen die Deadlines für jeden Projektschritt festgelegt, der kritische Pfad bestimmt und ein zeitlicher Puffer für Eventualitäten einkalkuliert werden. Die Deadline für jeden Projektschritt kann von einem neuronalen Netzwerk kalkuliert werden, das auf Basis bereits abgeschlossener Projektschritte trainiert wurde.

Um eine erste Einschätzung der Deadline liefern zu können, gibt es noch eine andere Vorgehensweise: Das Netzwerk kann auf Basis bereits abgeschlossener Projekte trainiert werden und dabei den Umfang, die Sprachkombinationen, die Domain und andere Projekteigenschaften in Betracht ziehen. Die durch diese Vorgehensweise geschätzten Deadlines sind zwar nur grobe Termine, aber diese Art von Algorithmus ist wesentlich einfacher zu implementieren.

Überwachung der Liefertermine

Für die Überwachung der Liefertermine lässt sich der gleiche Ansatz wie für die Projektplanung anwenden. Wenn das Projekt aber bereits gestartet wurde und die Bearbeitung bereits läuft, liegen hierzu wesentlich mehr Daten vor. Zum Beispiel wissen wir dann, welche Schritte bereits abgeschlossen sind und welche Vendoren den verbleibenden Schritten zugewiesen sind. In diesem Fall ist es für uns ausreichend, realistische Liefertermine für die verbleibenden Schritte und den kritischen Pfad zu berechnen, den aktuellen Zeitpunkt hinzuzufügen, um den voraussichtlichen Termin für die Projektfertigstellung zu berechnen und diesen dann mit dem vorab besprochenen Liefertermin zu vergleichen. Liegt der berechnete Termin sogar noch vor der eigentlich besprochenen Deadline, freuen wir uns natürlich, denn die Wahrscheinlichkeit ist groß, dass wir den Termin einhalten können. Liegt der berechnete Termin jedoch nach der eigentlich besprochenen Deadline, können wir die Differenz in ein gängiges Histogramm eingeben, um zu berechnen, wie wahrscheinlich es ist, dass der eigentliche Liefertermin noch eingehalten werden kann (in diesem Fall liegt die Wahrscheinlichkeit definitiv unter 100 %)

Manuelle Vorbereitung der Anweisungen für Vendoren

Auch, wenn die Vorbereitung klarer, einheitlicher und aktueller Anweisungen für Vendoren ein wichtiger Punkt bei der Arbeit als Projektmanager ist, werden letzten Endes die Anweisungen der Kunden häufig einfach nur kopiert und eingefügt. Diese Vorgehensweise ist primitiv und nicht zielführend. Während es für Projekte bestimmter Kunden durchaus Sinn macht, Entwürfe mit aktuellen Anweisungen für die verschiedenen beteiligten Vendoren (z. B. Engineers, Übersetzer, Lektoren, Korrekturleser, DTP-Spezialisten, etc.) zu pflegen, kann diese Vorgehensweise für andere Kunden schlichtweg nicht realisierbar sein oder zusätzliche Arbeit bedeuten.

In diesem Fall können uns bestimmte Techniken aus der natürlichen Sprachverarbeitung helfen, wie z. B. Information Extraction und Named Entity Recognition. Wenn wir diese Techniken auf Projektbeschreibungen anwenden, die wir von Kunden in unstrukturierten Formaten erhalten haben, können wir relevante Projekteigenschaften, wie Umfang, Sprachkombination, Account, Projektname, Deadline, etc. als separate Werte herausfiltern. Diese Informationen geben wir dann einfach in eine strukturierte Vorlage für Arbeitsanweisungen ein und erhalten einen Entwurf mit den Anweisungen für die Vendoren. Wenn im Projektmanagement-System noch kein zugehöriges Projekt angelegt wurde, ist es ratsam, ein Projekt auf Basis der extrahierten Projekteigenschaften zu erstellen.

Entwickeln oder kaufen

Mit der Weiterentwicklung der Technologien und der kontinuierlichen Digitalisierung wird Softwareentwicklung auch für Sprachdienstleister immer wichtiger. Die Einführung relativ neuer und sich schnell verändernder Bereiche wie maschinelles Lernen, kann sich jedoch als noch zu kompliziert erweisen.

In diesem Sinne können Unternehmen sich entweder dazu entscheiden, mit Python/R ihre eigenen ML-Microservices aufzusetzen oder auf hervorragende kognitive Services von IT-Giganten wie Google, Amazon oder Microsoft sowie Integrationen von Unternehmen wie Intento zurückzugreifen.

ML-Anbieter	Vorteile	Nachteile
Eigene, selbstständige Entwicklung	Besseres Verständnis für die Arbeitsweise von ML Maximale Diskretion Bessere Verfügbarkeit	Ein Entwicklerteam für ML kann für kleine/mittelständische Unternehmen ggf. zu kostspielig sein Entwicklung kann mehr Zeit in Anspruch nehmen Ggf. minderwertigere Produktqualität
Professioneller Cloud-Service	Schnelle Einführung Bewährte Qualitätslösungen Höhere Spitzenleistung	Drittanbieter hat Zugriff auf die Daten Auf lange Sicht kostspieliger

Obwohl durch ML hervorragende Ergebnisse erzielt werden können, schwingen auch gewisse Risiken mit. Es ist also ratsam, ML-Lösungen zur Unterstützung im operativen Geschäft zu integrieren, und stets einen Mitarbeiter ein Auge darauf haben zu lassen – zumindest bis Sie der ML-Lösung zu 100 % vertrauen und die potenziellen Risiken richtig einschätzen können.