Übersetzungsagent: Agentische Übersetzung mithilfe des Reflexionsworkflows
Dies ist eine Python-Demonstration eines Reflection-Agent-Workflows für die maschinelle Übersetzung. Die Hauptschritte sind:
- Fordern Sie einen LLM auf, einen Text von
source_language
in target_language
zu übersetzen. - Lassen Sie den LLM über die Übersetzung nachdenken, um konstruktive Verbesserungsvorschläge zu unterbreiten.
- Nutzen Sie die Vorschläge, um die Übersetzung zu verbessern.
Anpassbarkeit
Durch die Verwendung eines LLM als Herzstück der Übersetzungsmaschine ist dieses System äußerst steuerbar. Durch die Änderung der Eingabeaufforderungen ist es mit diesem Workflow beispielsweise einfacher als mit einem herkömmlichen maschinellen Übersetzungssystem (MT), Folgendes zu erreichen:
- Ändern Sie den Stil der Ausgabe, z. B. formell/informell.
- Geben Sie an, wie mit Redewendungen und Sonderbegriffen wie Namen, Fachbegriffen und Akronymen umgegangen werden soll. Wenn Sie beispielsweise ein Glossar in die Eingabeaufforderung einfügen, können Sie sicherstellen, dass bestimmte Begriffe (z. B. Open Source, H100 oder GPU) konsistent übersetzt werden.
- Geben Sie eine bestimmte regionale Verwendung der Sprache oder bestimmte Dialekte an, um eine Zielgruppe anzusprechen. Beispielsweise unterscheidet sich das in Lateinamerika gesprochene Spanisch vom in Spanien gesprochenen Spanisch; In Kanada wird Französisch anders gesprochen als in Frankreich.
Dabei handelt es sich nicht um ausgereifte Software , sondern das Ergebnis davon, dass Andrew in den letzten Monaten an den Wochenenden mit Übersetzungen herumgespielt hat und dass Mitarbeiter (Joaquin Dominguez, Nedelina Teneva, John Santerre) bei der Umgestaltung des Codes geholfen haben.
Laut unseren Auswertungen unter Verwendung des BLEU-Scores für herkömmliche Übersetzungsdatensätze ist dieser Workflow manchmal mit führenden kommerziellen Angeboten konkurrenzfähig, manchmal aber auch schlechter. Allerdings haben wir mit diesem Ansatz auch gelegentlich fantastische Ergebnisse erzielt (die kommerziellen Angeboten überlegen sind). Wir glauben, dass dies nur ein Ausgangspunkt für Agentenübersetzungen ist und dass dies eine vielversprechende Richtung für die Übersetzung ist, mit erheblichem Spielraum für weitere Verbesserungen. Deshalb veröffentlichen wir diese Demonstration, um mehr Diskussion, Experimente, Forschung und Open Source anzuregen Beiträge.
Wenn Agentenübersetzungen bessere Ergebnisse erzielen können als herkömmliche Architekturen (z. B. ein End-to-End-Transformator, der einen Text eingibt und eine Übersetzung direkt ausgibt) – die oft schneller/kostengünstiger in der Ausführung sind als unser Ansatz hier – bietet dies auch eine Mechanismus zur automatischen Generierung von Trainingsdaten (parallele Textkorpora), die zum weiteren Training und zur Verbesserung herkömmlicher Algorithmen verwendet werden können. (Siehe auch diesen Artikel in The Batch zur Verwendung von LLMs zum Generieren von Trainingsdaten.)
Kommentare und Verbesserungsvorschläge sind herzlich willkommen!
Erste Schritte
Um mit translation-agent
zu beginnen, führen Sie die folgenden Schritte aus:
Installation:
- Für die Installation ist der Poetry-Paketmanager erforderlich. Poesieinstallation Abhängig von Ihrer Umgebung könnte dies funktionieren:
- Zum Ausführen des Workflows ist eine .env-Datei mit einem OPENAI_API_KEY erforderlich. Sehen Sie sich die Datei .env.sample als Beispiel an.
git clone https://github.com/andrewyng/translation-agent.git
cd translation-agent
poetry install
poetry shell # activates virtual environment
Verwendung:
import translation_agent as ta
source_lang , target_lang , country = "English" , "Spanish" , "Mexico"
translation = ta . translate ( source_lang , target_lang , source_text , country )
Unter „examples/example_script.py“ finden Sie ein Beispielskript zum Ausprobieren.
Lizenz
Translation Agent wird unter der MIT-Lizenz veröffentlicht. Es steht Ihnen frei, den Code für kommerzielle und nichtkommerzielle Zwecke zu verwenden, zu ändern und zu verbreiten.
Ideen für Erweiterungen
Hier sind Ideen, mit denen wir noch nicht experimentiert haben, von denen wir aber hoffen, dass sie von der Open-Source-Community umgesetzt werden:
- Probieren Sie andere LLMs aus. Wir haben dies hauptsächlich mit gpt-4-turbo prototypisiert. Wir würden uns freuen, wenn andere mit anderen LLMs sowie anderen Hyperparameteroptionen experimentieren und sehen, ob einige bei bestimmten Sprachpaaren besser abschneiden als andere.
- Glossarerstellung. Was ist der beste Weg, effizient ein Glossar zu erstellen – vielleicht mithilfe eines LLM – der wichtigsten Begriffe, die konsistent übersetzt werden sollen? Beispielsweise verwenden viele Unternehmen Fachbegriffe, die im Internet nicht häufig verwendet werden und die LLMs daher nicht kennen, und es gibt auch viele Begriffe, die auf verschiedene Arten übersetzt werden können. Beispielsweise kann „Open Source“ auf Spanisch „Código abierto“ oder „Fuente abierta“ sein; Beide sind in Ordnung, aber es ist besser, eines auszuwählen und für ein einzelnes Dokument dabei zu bleiben.
- Verwendung und Implementierung des Glossars. Wie lässt sich ein gegebenes Glossar am besten in die Eingabeaufforderung einbinden?
- Auswertungen zu verschiedenen Sprachen. Wie unterscheidet sich die Leistung in verschiedenen Sprachen? Gibt es Änderungen, die es für bestimmte Ausgangs- oder Zielsprachen besser funktionieren lassen? (Beachten Sie, dass wir für sehr hohe Leistungsniveaus, denen sich MT-Systeme annähern, nicht sicher sind, ob BLEU eine gute Metrik ist.) Auch die Leistung bei Sprachen mit geringeren Ressourcen muss weiter untersucht werden.
- Fehleranalyse. Wir haben festgestellt, dass die Angabe einer Sprache und eines Landes/einer Region (z. B. „Spanisch, wie es in Mexiko umgangssprachlich gesprochen wird“) für unsere Bewerbungen ziemlich gut funktioniert. Wo greift der aktuelle Ansatz zurück? Wir sind auch besonders daran interessiert, seine Leistung bei speziellen Themen (wie Jura, Medizin) oder speziellen Textarten (wie Filmuntertiteln) zu verstehen, um seine Grenzen zu verstehen.
- Bessere Bewertungen. Schließlich sind wir der Meinung, dass bessere Bewertungen (Evals) ein großes und wichtiges Forschungsthema sind. Wie bei anderen LLM-Anwendungen, die Freitext generieren, scheinen die aktuellen Bewertungsmetriken unzureichend zu sein. Beispielsweise haben wir herausgefunden, dass selbst bei Dokumenten, bei denen unser Agenten-Workflow den Kontext und die Terminologie besser erfasst, was zu Übersetzungen führt, die unsere menschlichen Bewerter den aktuellen kommerziellen Angeboten vorziehen, die Auswertung auf Satzebene (unter Verwendung des FLORES-Datensatzes) dazu führte, dass das Agentensystem eine schlechtere Bewertung erzielte auf BLEU. Können wir bessere Metriken entwerfen (vielleicht mithilfe eines LLM zur Bewertung von Übersetzungen?), die die Übersetzungsqualität auf Dokumentebene erfassen, die besser mit den menschlichen Vorlieben korreliert?
Verwandte Arbeiten
Einige akademische Forschungsgruppen beginnen auch, sich mit LLM-basierter und agentischer Übersetzung zu befassen. Wir glauben, dass es in diesem Bereich noch am Anfang steht!
- ChatGPT MT: Competitive for High- (aber nicht Low-) Resource Languages , Robinson et al. (2023), https://arxiv.org/pdf/2309.07423
- So entwerfen Sie Übersetzungsaufforderungen für ChatGPT: Eine empirische Studie , Gao et al. (2023), https://arxiv.org/pdf/2304.02182v2
- Jenseits der menschlichen Übersetzung: Nutzung der Zusammenarbeit mehrerer Agenten für die Übersetzung ultralanger literarischer Texte , Wu et al. (2024), https://arxiv.org/pdf/2405.11804