Agente de traducción: traducción agente mediante flujo de trabajo de reflexión
Esta es una demostración en Python de un flujo de trabajo agente de reflexión para traducción automática. Los pasos principales son:
- Solicitar a un LLM que traduzca un texto del
source_language al target_language ; - Haga que el LLM reflexione sobre la traducción para generar sugerencias constructivas para mejorarla;
- Utilice las sugerencias para mejorar la traducción.
Personalización
Al utilizar un LLM como corazón del motor de traducción, este sistema es altamente dirigible. Por ejemplo, al cambiar las indicaciones, es más fácil utilizar este flujo de trabajo que un sistema de traducción automática (TA) tradicional para:
- Modifique el estilo de la salida, como formal/informal.
- Especifique cómo manejar modismos y términos especiales como nombres, términos técnicos y acrónimos. Por ejemplo, incluir un glosario en el mensaje le permite asegurarse de que determinados términos (como código abierto, H100 o GPU) se traduzcan de forma coherente.
- Especifique el uso regional específico del idioma, o dialectos específicos, para atender a un público objetivo. Por ejemplo, el español que se habla en América Latina es diferente del español que se habla en España; El francés que se habla en Canadá es diferente al que se habla en Francia.
Este no es un software maduro y es el resultado de que Andrew haya jugado con las traducciones los fines de semana de los últimos meses, además de que sus colaboradores (Joaquín Domínguez, Nedelina Teneva, John Santerre) ayudaron a refactorizar el código.
Según nuestras evaluaciones utilizando la puntuación BLEU en conjuntos de datos de traducción tradicionales, este flujo de trabajo a veces es competitivo, pero también a veces peor, que las principales ofertas comerciales. Sin embargo, en ocasiones también hemos obtenido resultados fantásticos (superiores a las ofertas comerciales) con este enfoque. Creemos que este es solo un punto de partida para las traducciones agentes, y que es una dirección prometedora para la traducción, con un margen significativo para seguir mejorando, razón por la cual lanzamos esta demostración para fomentar más debate, experimentación, investigación y uso de código abierto. contribuciones.
Si las traducciones agentes pueden generar mejores resultados que las arquitecturas tradicionales (como un transformador de extremo a extremo que ingresa un texto y genera directamente una traducción), que a menudo son más rápidas y más baratas de ejecutar que nuestro enfoque aquí, esto también proporciona una Mecanismo para generar automáticamente datos de entrenamiento (corpus de texto paralelo) que se pueden utilizar para entrenar y mejorar aún más los algoritmos tradicionales. (Consulte también este artículo en The Batch sobre el uso de LLM para generar datos de capacitación).
¡Los comentarios y sugerencias sobre cómo mejorar esto son bienvenidos!
Empezando
Para comenzar con translation-agent , siga estos pasos:
Instalación:
- Se requiere el administrador de paquetes de Poetry para la instalación. Instalación de poesía Dependiendo de su entorno, esto podría funcionar:
- Se requiere un archivo .env con OPENAI_API_KEY para ejecutar el flujo de trabajo. Vea el archivo .env.sample como ejemplo.
git clone https://github.com/andrewyng/translation-agent.git
cd translation-agent
poetry install
poetry shell # activates virtual environment
Uso:
import translation_agent as ta
source_lang , target_lang , country = "English" , "Spanish" , "Mexico"
translation = ta . translate ( source_lang , target_lang , source_text , country )
Consulte ejemplos/example_script.py para ver un script de ejemplo para probar.
Licencia
Translation Agent se publica bajo la licencia MIT . Eres libre de utilizar, modificar y distribuir el código con fines comerciales y no comerciales.
Ideas para extensiones
Aquí hay ideas con las que no hemos tenido tiempo de experimentar pero que esperamos que la comunidad de código abierto lo haga:
- Pruebe otros LLM. Hicimos un prototipo de esto principalmente usando gpt-4-turbo. Nos encantaría que otros experimentaran con otros LLM, así como con otras opciones de hiperparámetros, y vieran si algunos funcionan mejor que otros para pares de idiomas particulares.
- Creación de glosario. ¿Cuál es la mejor manera de crear eficientemente un glosario (tal vez utilizando un LLM) de los términos más importantes que queremos traducir de manera consistente? Por ejemplo, muchas empresas utilizan términos especializados que no se utilizan ampliamente en Internet y que, por lo tanto, los LLM no conocen, y también hay muchos términos que se pueden traducir de múltiples maneras. Por ejemplo, “open source” en español puede ser “Código abierto” o “Fuente abierta”; Ambos están bien, pero será mejor elegir uno y seguir con él para un solo documento.
- Uso e implementación del glosario. Dado un glosario, ¿cuál es la mejor manera de incluirlo en el mensaje?
- Evaluaciones en diferentes idiomas. ¿Cómo varía su rendimiento en diferentes idiomas? ¿Hay cambios que hagan que funcione mejor para determinados idiomas de origen o de destino? (Tenga en cuenta que para niveles muy altos de rendimiento, a los que se acercan los sistemas de traducción automática, no estamos seguros de si BLEU es una gran métrica). Además, su rendimiento en lenguajes de recursos más bajos necesita más estudio.
- Análisis de errores. Hemos descubierto que especificar un idioma y un país/región (por ejemplo, “el español como se habla coloquialmente en México”) funciona bastante bien para nuestras aplicaciones. ¿En qué se queda corto el enfoque actual? También estamos particularmente interesados en comprender su desempeño en temas especializados (como derecho, medicina) o tipos especiales de texto (como subtítulos de películas) para comprender sus limitaciones.
- Mejores evaluaciones. Finalmente, creemos que mejores evaluaciones (evals) son un tema de investigación enorme e importante. Al igual que con otras aplicaciones LLM que generan texto libre, las métricas de evaluación actuales parecen quedarse cortas. Por ejemplo, descubrimos que incluso en documentos en los que nuestro flujo de trabajo de agencia captura mejor el contexto y la terminología, lo que da como resultado traducciones que nuestros evaluadores humanos prefieren a las ofertas comerciales actuales, la evaluación a nivel de oración (utilizando el conjunto de datos FLORES) resultó en que el sistema de agencia obtenga una puntuación más baja. en BLEU. ¿Podemos diseñar mejores métricas (¿quizás usando un LLM para evaluar las traducciones?) que capturen la calidad de la traducción a un nivel de documento que se correlacione mejor con las preferencias humanas?
Trabajo relacionado
Algunos grupos de investigación académica también están empezando a considerar la traducción agencial y basada en LLM. ¡Creemos que son los primeros días para este campo!
- ChatGPT MT: competitivo para lenguajes de recursos altos (pero no bajos) , Robinson et al. (2023), https://arxiv.org/pdf/2309.07423
- Cómo diseñar mensajes de traducción para ChatGPT: un estudio empírico , Gao et al. (2023), https://arxiv.org/pdf/2304.02182v2
- Más allá de la traducción humana: aprovechar la colaboración de múltiples agentes para traducir textos literarios ultralargos , Wu et al. (2024), https://arxiv.org/pdf/2405.11804
