En Correcto comenzamos una nueva serie de blogs destinados a la parte más técnica de la empresa. A lo largo de las próximas semanas y meses, iremos desgranando los diferentes componentes tecnológicos y retos a los que nos hemos ido enfrentando durante la creación de las herramientas y funcionalidades actuales.
Si bien puede parecer un detalle menor, la decisión de no utilizar el inglés como idioma principal en el desarrollo de tecnologías de inteligencia artificial (IA) y procesamiento de lenguaje natural (PLN) conlleva ciertas limitaciones. La realidad es que la mayoría de las innovaciones en estos campos se originan en contextos angloparlantes, debido a que el inglés sirve como lengua en la investigación académica y la industria tecnológica a nivel global.
Esta prevalencia del inglés se manifiesta en diversos ámbitos, desde documentación técnica hasta foros especializados. Incluso en la investigación académica, los conjuntos de datos abiertos suelen estar predominantemente en inglés, a menos que el proyecto especifique la necesidad de un idioma diferente.
¿Por qué es esto problemático? La inteligencia artificial requiere de conjuntos de datos extensos y de alta calidad para abordar los desafíos más complejos. Mientras que los datos en inglés se benefician del escrutinio y mejoras continuas por parte de una comunidad global de académicos y desarrolladores, los datos en otros idiomas a menudo carecen de un soporte comunitario similar, lo que puede afectar la calidad y eficacia de los modelos de lenguaje en esos idiomas.
Uno de los cuellos de botella más significativos en el desarrollo de modelos de inteligencia artificial es la disponibilidad de datos de alta calidad para entrenamiento. Esto se dificulta cuando se trabaja con idiomas diferentes al inglés. En este contexto, es crucial no solo encontrar conjuntos de datos suficientemente grandes, sino también que estos sean limpios, diversos y equilibrados. Mientras que para el inglés existen abundantes recursos, en idiomas como el español, las barreras son considerablemente mayores.
La estrategia más directa para superar este obstáculo suele ser recurrir a conjuntos de datos de dominio público o bajo licencias flexibles, aptos para uso comercial. Estos conjuntos suelen venir en diferentes formatos, como XML, CSV o texto plano, y requieren un procesamiento cuidadoso para ajustarse a las especificaciones del producto en desarrollo.
Durante nuestras primeras etapas de investigación, optamos por un conjunto de datos con una licencia abierta que incluía transcripciones gubernamentales. Sin embargo, nos enfrentamos a serios problemas en cuanto a la diversidad y limpieza de estos textos. En este sentido, cuando hablamos de 'texto limpio' nos referimos a texto libre de errores ortográficos y en el formato deseado, un criterio esencial para el desarrollo de un corrector ortográfico y de concordancia. A pesar de nuestros esfuerzos por limpiar y transformar estos datos, la calidad del modelo resultante no cumplió con nuestros estándares.
Finalmente, tomamos la decisión de cambiar nuestra fuente de datos, aunque aprovechamos las lecciones aprendidas en las etapas iniciales de limpieza de datos para mejorar el proceso.
Nuestro producto se compone de un conjunto de modelos independientes que se encargan de aspectos ortográficos, de concordancia y de estilo, los cuales se unifican para ofrecer al usuario una corrección integral. Cada uno de estos modelos requiere un tipo de entrenamiento específico. Para el modelo ortográfico, por ejemplo, utilizamos un vocabulario de palabras existentes en el diccionario español. En contraste, el modelo de concordancia se entrena con frases completas.
Dados nuestros requisitos, encontrar un conjunto de datos preexistentes que se ajuste a nuestras necesidades es especialmente desafiante, más aún si se busca en idiomas distintos al inglés. Estamos hablando de localizar un conjunto de datos ordenado y limpio que contenga pares de frases, unas correctamente escritas y otras con errores intencionados de ortografía o concordancia. Es una búsqueda casi imposible.
Para enfrentar este inconveniente de manera más efectiva, optamos por una estrategia de generación sintética de errores. Tras una investigación exhaustiva de los errores más comunes en español, diferenciados por regiones geográficas, generamos nuestros propios conjuntos de datos. Este enfoque nos permitió tener un control más riguroso sobre la calidad de los datos y, en última instancia, mejoró la precisión de los modelos en la identificación y corrección de errores.
En el contexto de la escritura, los tipos errores ocurren en una frecuencia diferente, y a menudo, existen variaciones regionales o culturales. Por ejemplo, ciertos errores como los laísmos, leísmos o dequeísmos podrían ser más prevalentes en algunas regiones de un país que en otras. Por lo tanto, es crucial que nuestro conjunto de datos esté adecuadamente balanceado para evitar el entrenamiento de un modelo sesgado, que podría ignorar ciertos errores o centrarse en exceso en otros.
Después de la fase de generación de errores, procedemos con el balanceo de los datos. Nuestra estrategia consiste en asignar un tipo específico de error a cada frase del conjunto de datos, siempre que la frase sea susceptible a ese tipo de error. Por ejemplo, en la frase 'He estado en aquellas casas de la colina', se podría introducir múltiples tipos de errores de concordancia. Un enfoque sería cambiar el artículo 'la' por 'el', resultando en 'el colina', un error de género. Alternativamente, podríamos reemplazar 'aquellas' por 'aquella', introduciendo un error de concordancia en número.
Para garantizar la diversidad en nuestro conjunto de datos final, cada frase se utiliza una sola vez. Enumeramos las incidencias de cada tipo de error y, utilizando frases distintas, las incorporamos en un conjunto de datos finalizado que se utilizará para el entrenamiento del modelo. De esta manera, aseguramos que el modelo esté expuesto a una variedad representativa de errores, lo que mejora su robustez y precisión.
En los próximos blogs, profundizaremos sobre los componentes y desafíos técnicos que hemos comentado en este primer blog de tecnología, además de explorar otras funcionalidades que hemos estado desarrollado.