translation agent

Agent de traduction : traduction agentique utilisant un workflow de réflexion

Il s'agit d'une démonstration Python d'un flux de travail agent de réflexion pour la traduction automatique. Les principales étapes sont :

1. Inviter un LLM à traduire un texte de source_language vers target_language ;
2. Faire réfléchir le LLM sur la traduction pour proposer des suggestions constructives pour l'améliorer ;
3. Utilisez les suggestions pour améliorer la traduction.

Personnalisation

En utilisant un LLM comme cœur du moteur de traduction, ce système est hautement pilotable. Par exemple, en modifiant les invites, il est plus facile d'utiliser ce flux de travail qu'un système de traduction automatique (MT) traditionnel pour :

• Modifiez le style de la sortie, tel que formel/informel.
• Spécifiez comment gérer les expressions idiomatiques et les termes spéciaux tels que les noms, les termes techniques et les acronymes. Par exemple, l'inclusion d'un glossaire dans l'invite vous permet de vous assurer que des termes particuliers (tels que open source, H100 ou GPU) sont traduits de manière cohérente.
• Spécifiez l'utilisation régionale spécifique de la langue, ou des dialectes spécifiques, pour servir un public cible. Par exemple, l’espagnol parlé en Amérique latine est différent de l’espagnol parlé en Espagne ; Le français parlé au Canada est différent de la façon dont il est parlé en France.

Ce n'est pas un logiciel mature et c'est le résultat d'Andrew jouant avec les traductions le week-end des derniers mois, ainsi que de collaborateurs (Joaquin Dominguez, Nedelina Teneva, John Santerre) aidant à refactoriser le code.

Selon nos évaluations utilisant le score BLEU sur des ensembles de données de traduction traditionnels, ce flux de travail est parfois compétitif, mais aussi parfois pire, que les principales offres commerciales. Cependant, nous avons parfois obtenu des résultats fantastiques (supérieurs aux offres commerciales) avec cette approche. Nous pensons qu'il ne s'agit que d'un point de départ pour les traductions agentiques, et qu'il s'agit d'une direction prometteuse pour la traduction, avec une marge d'amélioration significative. C'est pourquoi nous publions cette démonstration pour encourager davantage de discussions, d'expérimentations, de recherches et d'open source. cotisations.

Si les traductions agentiques peuvent générer de meilleurs résultats que les architectures traditionnelles (telles qu'un transformateur de bout en bout qui entre un texte et produit directement une traduction) -- qui sont souvent plus rapides/moins chères à exécuter que notre approche ici -- cela fournit également un mécanisme pour générer automatiquement des données de formation (corpus de textes parallèles) qui peuvent être utilisées pour former et améliorer davantage les algorithmes traditionnels. (Voir également cet article dans The Batch sur l'utilisation des LLM pour générer des données de formation.)

Les commentaires et suggestions pour améliorer cela sont les bienvenus !

Commencer

Pour démarrer avec translation-agent , procédez comme suit :

Installation:

• Le gestionnaire de packages Poetry est requis pour l’installation. Installation de Poetry Selon votre environnement, cela peut fonctionner :

pip install poetry

• Un fichier .env avec un OPENAI_API_KEY est requis pour exécuter le workflow. Voir le fichier .env.sample à titre d'exemple.

git clone https://github.com/andrewyng/translation-agent.git
cd translation-agent
poetry install
poetry shell # activates virtual environment

Usage:

 import translation_agent as ta
source_lang , target_lang , country = "English" , "Spanish" , "Mexico"
translation = ta . translate ( source_lang , target_lang , source_text , country )

Voir examples/example_script.py pour un exemple de script à essayer.

Licence

Translation Agent est publié sous la licence MIT . Vous êtes libre d'utiliser, de modifier et de distribuer le code à des fins commerciales et non commerciales.

Idées d'extensions

Voici des idées que nous n'avons pas eu le temps d'expérimenter mais que nous espérons que la communauté open source fera :

• Essayez d'autres LLM. Nous avons prototypé cela principalement en utilisant gpt-4-turbo. Nous aimerions que d'autres expérimentent d'autres LLM ainsi que d'autres choix d'hyperparamètres et voient si certains fonctionnent mieux que d'autres pour des paires de langues particulières.
• Création d'un glossaire. Quelle est la meilleure façon de créer efficacement un glossaire – peut-être à l’aide d’un LLM – des termes les plus importants que nous souhaitons traduire de manière cohérente ? Par exemple, de nombreuses entreprises utilisent des termes spécialisés qui ne sont pas largement utilisés sur Internet et que les LLM ne connaissent donc pas, et il existe également de nombreux termes qui peuvent être traduits de plusieurs manières. Par exemple, « open source » en espagnol peut être « Código abierto » ou « Fuente abierta » ; les deux vont bien, mais il vaut mieux en choisir un et s'y tenir pour un seul document.
• Utilisation et mise en œuvre du glossaire. Étant donné un glossaire, quelle est la meilleure façon de l'inclure dans l'invite ?
• Évaluations sur différentes langues. Comment ses performances varient-elles dans différentes langues ? Y a-t-il des changements qui améliorent son fonctionnement pour des langues sources ou cibles particulières ? (Notez que pour les niveaux de performances très élevés, auxquels les systèmes MT se rapprochent, nous ne sommes pas sûrs que BLEU soit une bonne mesure.) De plus, ses performances sur des langages à ressources moindres nécessitent une étude plus approfondie.
• Analyse des erreurs. Nous avons constaté que spécifier une langue et un pays/une région (par exemple, « l'espagnol couramment parlé au Mexique ») fait un très bon travail pour nos applications. Où l’approche actuelle échoue-t-elle ? Nous sommes également particulièrement intéressés à comprendre ses performances sur des sujets spécialisés (comme le droit, la médecine) ou des types de texte spéciaux (comme les sous-titres de films) pour comprendre ses limites.
• De meilleures évaluations. Enfin, nous pensons que de meilleures évaluations (evals) constituent un sujet de recherche énorme et important. Comme pour d'autres applications LLM qui génèrent du texte libre, les mesures d'évaluation actuelles semblent insuffisantes. Par exemple, nous avons constaté que même sur les documents dans lesquels notre flux de travail agent capture mieux le contexte et la terminologie, ce qui donne lieu à des traductions que nos évaluateurs humains préfèrent aux offres commerciales actuelles, l'évaluation au niveau de la phrase (à l'aide de l'ensemble de données FLORES) aboutissait à une note plus faible du système agent. sur BLEU. Pouvons-nous concevoir de meilleurs indicateurs (peut-être en utilisant un LLM pour évaluer les traductions ?) qui capturent la qualité de la traduction au niveau du document qui correspond mieux aux préférences humaines ?

Travaux connexes

Quelques groupes de recherche universitaires commencent également à s’intéresser à la traduction agentique et basée sur le LLM. Nous pensons qu'il est encore tôt pour ce domaine !

• ChatGPT MT : compétitif pour les langues à ressources élevées (mais pas faibles) , Robinson et al. (2023), https://arxiv.org/pdf/2309.07423
• Comment concevoir des invites de traduction pour ChatGPT : une étude empirique , Gao et al. (2023), https://arxiv.org/pdf/2304.02182v2
• Au-delà de la traduction humaine : exploiter la collaboration multi-agents pour traduire des textes littéraires ultra-longs , Wu et al. (2024), https://arxiv.org/pdf/2405.11804