Voy a lanzar una idea aquí que es más una intuición que algo que haya investigado en profundidad. A lo mejor alguien lo lee y comenta y sacamos algo en claro.
De alguna forma, todo lo que se dice sobre RAG (Retrieval Augmented Generation) respecto a los motores de IA me recuerda muchísimo al uso de glosarios en traducciones automáticas.
Me explico: entrenar un motor de traducción automática requiere muchos datos, datos que además deben ser de buena calidad, luego hacen falta expertos y recursos. Y no todas las empresas tienen todo eso. Así que, en un momento dado, las empresas que ofrecen traducciones automáticas empezaron a pensar en una forma de expandir sus clientes potenciales a todas esas pequeñas y medianas empresas y se sacaron de la manga aplicar glosarios para controlar los resultados.
Yo me he visto varias veces en la tesitura de dar respuesta a peticiones de glosarios para ese fin. Los problemas a lo que se enfrenta uno no son pocos ni pequeños. En el caso de que ya exista un glosario, suele estar destinado a traductores y, generalmente, no es lo suficientemente sistemático. Un traductor humano tiene muchas opciones para buscar y contrastar la terminología adecuada, desde consultar la memoria de traducción, a buscar términos en la página web del cliente para el que está haciendo la traducción, en webs del ramo, en diccionarios y glosarios en línea o en legislación y reglamentos, además de un largo etcétera. En este sentido no es raro que las bases de términos con las que trabajan contengan solo determinadas preferencias de un cliente cuyo uso es vinculante.
Por otro lado, las bases de términos contienen información adicional que sirve, entre otras cosas, para desambiguar homónimos o para limitar el uso de ciertos términos a un contexto determinado. Y uno glosario de este tipo no admite esa información adicional. Esto hace que haya que “limpiar” los glosarios y completarlos. A todo ello hay que sumar que no todos los motores de traducción automática funcionan igual “inyectando terminología”, ni tampoco dan la misma calidad de resultados para todos los idiomas o dominios. Por ejemplo, hay motores de traducción automática que no flexionan los términos o no son capaces de cambiar entre mayúscula y minúscula. Esto significa que un proyecto multilingüe puede incluir varios motores de traducción distintos, incrementando el trabajo para preparar los glosarios, y que la labor del terminólogo para prepararlos es manual y tediosa.
Por todo ello, no pocas veces esos proyectos de glosarios para traducción automática se quedan en nada. El trabajo que requiere prepararlos supera el presupuesto y los plazos de las traducciones. Como cabe suponer, cuando una empresa se decide por traducciones automáticas, lo hace para ahorrar tiempo y dinero.
No tengo experiencia práctica con RAG: nunca me han pedido que desarrolle un grafo de conocimiento para usarlo con IA, aunque que me encantaría hacerlo. Sin embargo, he leído mucho al respecto. Conozco las diferencias entre una ontología y un grafo de conocimiento, he leído artículos sobre las mejoras que cabe esperar de su uso y me baso en todo ello para sospechar que, al final, sucedería lo mismo: pequeñas y medianas empresas que no se pueden permitir desarrollar un agente de IA, pero no quieren renunciar a usarlo y se informan sobre la posibilidad de desarrollar grafos de conocimiento para controlar lo que sucede dentro de esa caja negra que son los LLM. Al final solo para darse cuenta de que la inversión en tiempo y dinero desbarata sus planes, por más que se realice de forma eficiente y en (relativamente) poco tiempo.
Y todo ello sin mencionar el compromiso de datos confidenciales y las pérdidas de gobernabilidad de datos que implican usar motores de traducción automática generales y agentes de IA comerciales.
Leave a Reply