Este artículo es un anexo de nuestro artículo original publicado el 10/01/2017, titulado Evaluación de calidad de la traducción automática de 2017.
Evaluamos todos los sistemas de traducción automática para las combinaciones inglés-francés e inglés-alemán. Informamos de BLEU-4 [2], ignorando las diferencias entre mayúsculas y minúsculas, calculado por el script de puntuación mteval del conjunto de código abierto de la Universidad de Stanford, Phrasal. Se aplicó la tokenización NIST a las producciones de los sistemas y las traducciones de referencia. Simulamos la situación hipotética en la que el traductor traduce los datos de evaluación secuencialmente desde el principio hasta el final. Suponemos que hace uso completo de los recursos que las soluciones correspondientes ofrecen mediante el uso de la memoria de traducción como datos de adaptación y mediante la adaptación incremental, donde el sistema de traducción aprende de cada segmento confirmado.
Las producciones y los scripts de los sistemas para descargarlos automáticamente y dividir los datos de prueba están disponibles en: https://github.com/lilt/labs.
Se usaron en todos los experimentos sistemas y claves API de producción. Dado que los sistemas comerciales se mejoran periódicamente, registramos la fecha en que se generaron las producciones de los sistemas.
El sistema de referencia Lilt está disponible a través de la API REST con una clave API de producción. El sistema se puede reproducir con la siguiente serie de llamadas de API:
28/12/16
El sistema adaptativo de Lilt está disponible a través de la API REST con una clave API de producción. El sistema simula una situación hipotética en la que se agrega un corpus existente de datos del origen/destino para su entrenamiento antes de traducir el conjunto de prueba. El sistema se puede reproducir con la siguiente serie de llamadas de API:
06/01/2017
El sistema adaptativo e interactivo de Lilt está disponible a través de la API REST con una clave API de producción. El sistema simula una situación hipotética en la que se agrega un corpus existente de datos del origen/destino para su entrenamiento antes de traducir el conjunto de prueba. Para simular la retroalimentación de un traductor humano, se agrega cada traducción de referencia para cada oración de origen en el conjunto de prueba a la memoria después de decodificar. El sistema se puede reproducir con la siguiente serie de llamadas de API:
04/01/2017
El sistema estadístico de traducción automática basado en frases de Google. El sistema se puede reproducir consultando la API Translate:
28/12/2017
El sistema de traducción automática neuronal de Google (GNMT). El sistema se puede reproducir consultando la API Premium:
28/12/2016
El sistema de traducción automática estadística de referencia de Microsoft. El sistema se puede reproducir consultando la API Text Translation:
28/12/2016
El sistema de traducción automática estadística de Microsoft. El sistema simula una situación hipotética en la que se agrega un corpus existente de datos del origen/destino para su entrenamiento antes de traducir el conjunto de prueba. Primero creamos un nuevo proyecto de categoría general en Microsoft Translator Hub, luego, un nuevo sistema dentro de ese proyecto y cargamos la memoria de traducción como datos de entrenamiento. No hacemos ningún ajuste ni damos datos de prueba, de modo que se seleccionen automáticamente. Dejamos que el proceso de entrenamiento se complete y luego se implementa el sistema (por ejemplo, con la ID de categoría CATEGORY_ID). Luego, decodificamos el conjunto de prueba consultando la API Text Translation y pasamos el especificador del sistema implementado como ID de categoría:
30/12/2016 (después de la migración de Microsoft Translator al portal de Azure)
El sistema de traducción automática neuronal de Microsoft. El sistema se puede reproducir consultando la API Text Translation con la ID. de categoría «generalnn»:
El sistema de traducción automática neuronal Pure Neural de Systran. El sistema se puede reproducir a través del sitio web de demostración. Copiamos y pegamos manualmente la fuente en el sitio web en lotes de no más de 2000 caracteres. Verificamos que se respetaran los saltos de línea y que la división por lotes no tuviera ningún impacto en el resultado de la traducción. Esto implicó un esfuerzo manual importante y se hizo en varios días.
Fecha(s): en-de: 29–12–2016–30–12-2016; en-fr: 30–12–-2016–02–01-2017
El sistema de traducción automática en la nube Language Cloud de SDL. El sistema se puede reproducir a través de una tarea por lotes de pretraducción en Trados Studio 2017.
03/01/2017
El sistema de traducción automática AdaptiveMT de SDL, al que se accede a través de Trados Studio 2017. El sistema se puede reproducir creando primero un nuevo motor de AdaptiveMT específico para un nuevo proyecto y pretraduciendo el conjunto de prueba. El nuevo proyecto se inicia con los datos de la TM. Asumimos que los datos de la TM local se propagan al motor de AdaptiveMT para un reentrenamiento en línea. Se usa la tarea de lotes de pretraducción para generar traducciones para todas las coincidencias no exactas. La adaptación se lleva a cabo en el contenido de la TM. En los experimentos basados en la adaptación, no confirmamos cada segmento con una traducción de referencia debido a la cantidad de trabajo manual que habría sido necesario en Trados Studio 2017.
Los sistemas de Lilt adaptado, Microsoft adaptado y SDL adaptado son más similares porque se adaptaron en el modo por lotes, es decir, cargando todos los datos de la TM, lo que permitió que el entrenamiento se completara y luego se decodificara el conjunto de prueba. Por supuesto, pueden diferir y probablemente difieren otros factores esenciales pero no modificables por el usuario, como los corpus de referencia, los procedimientos de optimización y los criterios de optimización.
Definimos cuatro requisitos para el corpus de prueba:
Dado que todos los sistemas de la evaluación son sistemas de producción comercial, no podíamos imponer una condición de datos comunes ni garantizar la exclusión de los datos de prueba del corpus de referencia como en el requisito (2). Sin embargo, en la práctica es relativamente fácil detectar la inclusión de datos de prueba en el corpus de entrenamiento de un sistema mediante el siguiente procedimiento:
A partir de noviembre de 2016, evaluamos los ocho conjuntos de datos públicos descritos en el Apéndice con respecto a estos criterios. El noveno corpus que probamos fue SwissAdmin, que satisfizo nuestros requisitos y pasó nuestro procedimiento de selección de datos.
SwissAdmin es una colección multilingüe de comunicados de prensa del gobierno suizo entre 1997 y 2013. Usamos los comunicados de prensa más recientes. Dividimos los datos cronológicamente y reservamos los últimos 1300 segmentos de los artículos de 2013 como datos de prueba inglés-alemán, y los últimos 1320 segmentos como conjunto de prueba inglés-francés. Las divisiones cronológicas son un estándar en la investigación de la TA para explicar los cambios en los usos lingüísticos con el paso del tiempo. Además, se agregó otro filtro a los conjuntos de prueba para eliminar un solo segmento que contenía más de 200 tokens. El resto de los artículos de 2011 a 2013 se reservaron como datos dentro del dominio para la adaptación del sistema.
SwissAdminen-deen-frTMtestTMtest#segments18,6211,29918,1631,319#words548,435 / 482,69239,196 / 34,797543,815 / 600,58540,139 / 44,874
(Actualizado con la TA neuronal de Microsoft)
Los siguientes conjuntos de datos fueron evaluados y rechazados de acuerdo con el procedimiento especificado en la sección Corpus de prueba:
1 No pudimos producir un sistema interactivo SDL similar a Lilt interactivo. Primero intentamos confirmar las traducciones de referencia en Trados Studio. Sin embargo, nos dimos cuenta de que ese modelo se actualiza a menudo; requiere un minuto o más de procesamiento. Supongamos que se necesitan 15 segundos para pegar la referencia en la interfaz de usuario y se necesitan 60 segundos para actualizar el modelo. Para en-de, se habrían necesitado 1299 x 75 / 3600 = 27,1 horas para traducir el conjunto de prueba. Luego, intentamos escribir macros de la interfaz para automatizar la traducción y la confirmación de los segmentos en la interfaz de usuario, pero la variabilidad de las actualizaciones modelo y otros factores de la interfaz de usuario, como el desplazamiento, impidieron la automatización exitosa del proceso. La ausencia de una API de traducción impidió la conclusión en conjunto de la tarea con Amazon Mechanical Turk.