Open Food Facts ha intentado resolver este problema durante años utilizando expresiones regulares y soluciones existentes como el corrector de Elasticsearch, sin éxito. Hasta hace poco.
Gracias a los últimos avances en inteligencia artificial, ahora tenemos acceso a potentes Modelos de lenguaje grandestambién llamado LLM.
Al entrenar nuestro propio modelo, creamos el Ingredientes Corrector ortográfico y logró no solo superar a los LLM propietarios como GPT-4o o Soneto de Claude 3.5 en esta tarea, sino también para reducir el número de ingredientes no reconocidos en la base de datos 11%.
Este artículo lo guía a través de las diferentes etapas del proyecto y le muestra cómo logramos mejorar la calidad de la base de datos utilizando Machine Learning.
¡Disfruta la lectura!
Cuando un colaborador agrega un producto, sus imágenes pasan por una serie de procesos para extraer toda la información relevante. Un paso crucial es la extracción del lista de ingredientes.
Cuando una palabra se identifica como ingrediente, se hace una referencia cruzada con una taxonomía que contiene una lista predefinida de ingredientes reconocidos. Si la palabra coincide con una entrada de la taxonomía, se etiqueta como ingrediente y se agrega a la información del producto.
Este proceso de etiquetado garantiza que los ingredientes estén estandarizados y sean fáciles de buscar, proporcionando datos precisos para los consumidores y herramientas de análisis.
Pero si no se reconoce un ingrediente, el proceso falla.
Por esta razón, introdujimos una capa adicional al proceso: la Ingredientes Corrector ortográficodiseñado para corregir las listas de ingredientes antes de que el analizador de ingredientes las procese.
Un enfoque más sencillo sería el Algoritmo de Peter Norvigque procesa cada palabra aplicando una serie de eliminaciones, adiciones y reemplazos de caracteres para identificar posibles correcciones.
Sin embargo, este método resultó insuficiente para nuestro caso de uso, por varias razones:
- Caracteres especiales y formato: Elementos como comas, paréntesis y signos de porcentaje tienen una importancia crítica en las listas de ingredientes, lo que influye en la composición del producto y el etiquetado de alérgenos. (p. ej., “sal (1,2%)”).
- Desafíos multilingües: la base de datos contiene productos de todo el mundo con una amplia variedad de idiomas. Esto complica aún más un enfoque básico basado en caracteres como el de Norvig, que es independiente del idioma.
En cambio, recurrimos a los últimos avances en aprendizaje automático, particularmente Modelos de lenguajes grandes (LLM)que destacan en una amplia variedad de Procesamiento del lenguaje natural (PNL) tareas, incluida la corrección ortográfica.
Este es el camino que decidimos tomar.
No se puede mejorar lo que no se mide.
¿Qué es una buena corrección? ¿Y cómo medir el desempeño del corrector, LLM o no LLM?
Nuestro primer paso es comprender y catalogar la diversidad de errores que encuentra el analizador de ingredientes.
Además, es esencial evaluar si un error debería corregirse en primer lugar. A veces, intentar corregir errores puede hacer más daño que bien:
flour, salt (1!2%)
# Is it 1.2% or 12%?...
Por estas razones, creamos el Directrices para la revisión ortográficaun conjunto de reglas que limita las correcciones. Estas pautas nos servirán de muchas maneras a lo largo del proyecto, desde la generación del conjunto de datos hasta la evaluación del modelo.
Las directrices se utilizaron en particular para crear el Punto de referencia del corrector ortográficoun conjunto de datos curado que contiene aproximadamente 300 listas de ingredientes corregidos manualmente.
Este punto de referencia es el piedra angular del proyecto. Nos permite evaluar cualquier solución, Machine Learning o heurística simple, en nuestro caso de uso.
Va a lo largo del Algoritmo de evaluaciónuna solución personalizada que desarrollamos y que transforma un conjunto de correcciones en métricas mensurables.
El algoritmo de evaluación
La mayoría de las métricas y algoritmos de evaluación existentes para tareas relativas al texto calculan la similitud entre una referencia y una predicción, como AZUL o COLORETE puntuaciones para traducción o resumen de idiomas.
Sin embargo, en nuestro caso, estas métricas no son suficientes.
Queremos evaluar qué tan bien el algoritmo Spellcheck reconoce y corrige las palabras correctas en una lista de ingredientes. Por ello, adaptamos el Precisión y Recordar Métricas para nuestra tarea:
Precisión = Correcciones correctas por el modelo / Correcciones totales realizadas por el modelo
Recordar = Correcciones correctas por modelo / Número total de errores
Sin embargo, no tenemos una visión detallada de qué palabras se suponía que debían corregirse… Solo tenemos acceso a:
- El original: la lista de ingredientes presentes en la base de datos;
- El referencia: cómo esperamos que se corrija esta lista;
- El predicción: la corrección del modelo.
¿Hay alguna forma de calcular la cantidad de errores que se corrigieron correctamente, los que el corrector ortográfico omitió y, finalmente, los errores que se corrigieron incorrectamente?
¡La respuesta es sí!
Original: "Th cat si on the fride,"
Reference: "The cat is on the fridge."
Prediction: "Th big cat is in the fridge."
Con el ejemplo anterior, podemos detectar fácilmente qué palabras se suponía que debían corregirse: The , is y fridge ; y qué palabras fueron corregidas erróneamente: on en in. Finalmente, vemos que se agregó una palabra adicional: big .
Si alineamos estas 3 secuencias en pares, original-reference y original-prediction podemos detectar qué palabras se suponía que debían corregirse y cuáles no. Este problema de alineación es típico en bioinformática, llamado Alineación de secuenciacuyo propósito es identificar regiones de similitud.
Esta es una analogía perfecta para nuestra tarea de evaluación del corrector ortográfico.
Original: "Th - cat si on the fride,"
Reference: "The - cat is on the fridge."
1 0 0 1 0 0 1Original: "Th - cat si on the fride,"
Prediction: "Th big cat is in the fridge."
0 1 0 1 1 0 1
FN FP TP FP TP
Al etiquetar cada par con un 0 o 1 Ya sea que la palabra haya cambiado o no, podemos calcular con qué frecuencia el modelo corrige correctamente los errores. (Verdaderos positivos – TP)cambia incorrectamente las palabras correctas (Falsos positivos – FP)y omite errores que deberían haberse corregido (Falsos negativos – FN).
En otras palabras, podemos calcular la Precisión y Recordar del corrector ortográfico!
¡Ahora tenemos un algoritmo robusto que es capaz de evaluar cualquier solución de corrección ortográfica!
Puedes encontrar el algoritmo en el <a target="_blank" class="af ox" href="https://github.com/openfoodfacts/openfoodfacts-ai/blob/develop/spellcheck/src/spellcheck/evaluation/evaluator.py” rel=”noopener ugc nofollow” target=”_blank”>repositorio de proyectos.
Los modelos de lenguaje grande (LLM) han demostrado ser de gran ayuda para abordar las tareas del lenguaje natural en diversas industrias.
Constituyen un camino que tenemos que explorar para nuestro caso de uso.
Muchos proveedores de LLM se jactan del desempeño de su modelo en las tablas de clasificación, pero ¿cómo se desempeñan al corregir errores en las listas de ingredientes? ¡Así los evaluamos!
evaluamos GPT-3.5 y GPT-4o de Abierto ai, Claude-Soneto-3.5 de antrópicoy Géminis-1.5-Flash de Google utilizando nuestro algoritmo de evaluación y referencia personalizado.
Solicitamos instrucciones detalladas para orientar las correcciones hacia nuestras pautas personalizadas.
GPT-3.5-Turbo entregó el mejor rendimiento en comparación con otros modelos, tanto en términos de métricas como de revisión manual. Mención especial va para Claude-Soneto-3.5que mostró correcciones de errores impresionantes (recuerdo alto), pero a menudo proporcionó explicaciones adicionales irrelevantes, lo que redujo su precisión.
¡Excelente! ¡Tenemos un LLM que funciona! ¡Es hora de crear la función en la aplicación!
Bien, no tan rápido…
El uso de LLM privados revela muchos desafíos:
- Falta de propiedad: Nos volvemos dependientes de los proveedores y sus modelos. Con frecuencia se lanzan nuevas versiones de modelos, lo que altera el comportamiento del modelo. Esta inestabilidad, principalmente porque el modelo está diseñado para propósitos generales y no para nuestra tarea específica, complica el mantenimiento a largo plazo.
- Riesgo de eliminación del modelo: No tenemos garantías contra los proveedores que eliminan modelos más antiguos. Por ejemplo, GPT-3.5 está siendo reemplazado lentamente por modelos de mayor rendimiento, ¡a pesar de ser el mejor modelo para esta tarea!
- Limitaciones de rendimiento: El desempeño de un LLM privado está limitado por sus indicaciones. En otras palabras, nuestra única forma de mejorar los resultados es a través de mejores indicaciones, ya que no podemos modificar los pesos centrales del modelo entrenándolo con nuestros propios datos.
Por estas razones, decidimos centrar nuestros esfuerzos en soluciones de código abierto que nos brindarían un control total y superarían a los LLM generales.
Cualquier solución de aprendizaje automático comienza con datos. En nuestro caso, los datos son las listas de ingredientes corregidas.
Sin embargo, no todas las listas de ingredientes son iguales. Algunos están libres de ingredientes no reconocidos, otros son tan ilegibles que no tendría sentido corregirlos.
Por lo tanto, encontramos un equilibrio perfecto eligiendo listas de ingredientes que tengan entre 10 y 40 por ciento de ingredientes no reconocidos. También nos aseguramos de que no haya duplicados dentro del conjunto de datos, pero también con el punto de referencia para evitar cualquier fuga de datos durante la etapa de evaluación.
Extrajimos 6000 listas sin corregir de la base de datos Open Food Facts utilizando PatoDBuna rápida herramienta SQL en proceso capaz de procesar millones de filas por segundo.
Sin embargo, esas listas extraídas aún no están corregidas y anotarlas manualmente requeriría demasiado tiempo y recursos…
Sin embargo, tenemos acceso a LLM que ya evaluamos en la tarea exacta. Por lo tanto, solicitamos al GPT-3.5-Turbo, el mejor modelo en nuestro punto de referencia, que corrigiera cada lista con respecto a nuestras pautas.
El proceso tomó menos de una hora y costó casi 2$.
Luego revisamos manualmente el conjunto de datos usando Arcillauna herramienta de anotación de código abierto especializada en tareas de procesamiento del lenguaje natural. Este proceso garantiza que el conjunto de datos tenga la calidad suficiente para entrenar un modelo confiable.
Ahora tenemos a nuestra disposición un conjunto de datos de entrenamiento y un punto de referencia de evaluación para entrenar nuestro propio modelo en la tarea de corrección ortográfica.
Capacitación
Para esta etapa, decidimos ir con Modelos de lenguaje secuencia a secuencia. En otras palabras, estos modelos toman un texto como entrada y devuelven un texto como salida, lo que se adapta al proceso de revisión ortográfica.
Varios modelos cumplen esta función, como el familia T5 desarrollado por Google en 2020, o los LLM de código abierto actuales como Llama o Mistralque están diseñados para generar texto y seguir instrucciones.
El entrenamiento del modelo consta de una sucesión de pasos, cada uno de los cuales requiere diferentes asignaciones de recursos, como GPU en la nube, validación de datos y registro. Por esta razón, decidimos orquestar la capacitación utilizando Metaflujoun orquestador de canalizaciones diseñado para proyectos de ciencia de datos y aprendizaje automático.
El plan de formación está compuesto de la siguiente manera:
- Las configuraciones y los hiperparámetros se importan a la canalización desde archivos de configuración yaml;
- El trabajo de formación se lanza en la nube utilizando <a target="_blank" class="af ox" href="https://aws.amazon.com/sagemaker/” rel=”noopener ugc nofollow” target=”_blank”>AWS Sagemakerjunto con el conjunto de hiperparámetros del modelo y los módulos personalizados, como el algoritmo de evaluación. Una vez finalizado el trabajo, el artefacto del modelo se almacena en un depósito de AWS S3. Todos los detalles del entrenamiento se rastrean usando Cometa ML;
- El modelo ajustado luego se evalúa en el punto de referencia utilizando el algoritmo de evaluación. Dependiendo del tamaño del modelo, este proceso puede ser extremadamente largo. Por lo tanto, utilizamos vllmuna biblioteca de Python diseñada para acelerar las inferencias de LLM;
- Las predicciones frente al punto de referencia, también almacenadas en AWS S3, se envían a Arcilla para la evaluación humana.
Después de iterar una y otra vez entre refinar los datos y entrenar el modelo, logramos un rendimiento comparable a los LLM propietarios en la tarea de corrección ortográfica, obteniendo una puntuación F1 de 0,65.
