TRAPO. TRAPO. TRAPO. En la carrera por implementar la inteligencia artificial en los procesos y productos de negocios, ha surgido una tendencia preocupante: la obsesión con la Generación Aumentada por Recuperación (RAG, por sus siglas en inglés). Si bien la RAG (un método que combina grandes modelos de lenguaje [LLM, por sus siglas en inglés] con la recuperación de conocimiento externo) ha abierto innegablemente nuevas vías para interactuar con el conocimiento, demasiados profesionales tienen dificultades con ella. Es hora de replantearnos la conversación sobre la implementación de la IA, reconocer los peligros de depender excesivamente de RAG y explorar enfoques alternativos que puedan ser más adecuados, rentables y elegantes. La manía de RAG: una exageración para muchos casos de uso RAG se ha convertido en la técnica preferida de muchos ingenieros de IA que quieren mejorar la precisión de los modelos de lenguaje proporcionando un contexto externo. La premisa es bastante simple: al cargar grandes cantidades de texto en almacenes de vectores, estos sistemas de IA pueden buscar documentos relevantes, recuperar los datos y combinarlos con las capacidades generativas del modelo de lenguaje para producir respuestas más precisas. Sin embargo, el entusiasmo por RAG ha llevado a una explosión de implementaciones que sobreestiman su utilidad. No es raro ver a ingenieros volcando millones de documentos en almacenes vectoriales, lo que infla los costos de almacenamiento y procesamiento en la nube sin entender si el caso de uso siquiera requiere tal complejidad. Muchos no se plantean si una solución más simple podría ser suficiente o si RAG es siquiera necesario para su problema específico. Los peligros de las implementaciones ingenuas de RAG Lo que es peor, la mayoría de los ingenieros abordan la implementación de RAG con una mentalidad ingenua, pasando por alto los costos a largo plazo y las cargas de mantenimiento. Creen que cargar cada fragmento de texto en un almacén de vectores de alguna manera hará que la IA sea más inteligente. Pero la mayoría de las veces, esta práctica tiene el efecto contrario. Con los almacenes de vectores repletos de documentos redundantes e innecesarios, los LLM se ven abrumados con la recuperación de datos que no agregan valor. Esto da como resultado tiempos de respuesta más lentos, costos más altos y soluciones menos efectivas. RAG funciona mejor cuando se utiliza para aumentar el conocimiento y , no cuando se emplea como un cajón de sastre para cualquier volcado de documentos disponible. La ingeniería excesiva mediante RAG también conduce a la subutilización de otras capacidades clave de la IA y a un enfoque exagerado en la recuperación cuando muchos problemas podrían resolverse con una lógica y una estructura más simples. preciso relevante No todos los problemas necesitan RAG La verdad es la siguiente: no todos los casos de uso requieren una configuración RAG. Si la tarea es específica y está bien definida (como responder a preguntas frecuentes, consultas de soporte al cliente o participar en un diálogo estructurado), una simple tabla de búsqueda o un gráfico de conocimiento pueden ser suficientes. No es necesario incurrir en la sobrecarga que supone ejecutar un enorme almacén de vectores y un modelo de varios millones de parámetros cuando la solución se puede crear utilizando un sistema basado en reglas o incluso un marco de agente. El entusiasmo por utilizar RAG surge de la idea de que más datos equivalen a un mejor rendimiento. Pero en muchos casos, la calidad supera a la cantidad. Un modelo ajustado con conocimiento específico, o incluso un chatbot con conocimiento y capacidades basadas en reglas, puede funcionar mejor sin siquiera tocar un flujo de trabajo de RAG. La decisión de implementar RAG debe estar dictada por la complejidad de la tarea, no por su popularidad entre los entusiastas de la IA. El caso de los agentes pequeños con conocimientos limitados La alternativa a los sistemas RAG inflados suele ser más elegante y eficaz: agentes pequeños y especializados con conocimientos limitados pero precisos. Estos agentes, cuando se utilizan en conjunto, pueden superar a un único modelo grande cargado de terabytes de texto. Cada agente puede diseñarse para gestionar partes específicas de un flujo de trabajo o responder a determinados tipos de consultas, lo que permite sistemas de IA modulares y flexibles. Esto no solo reduce los costes, sino que también hace que todo el sistema sea más fácil de mantener y escalar. Imagine un escenario en el que un agente es responsable de la programación, otro de la elaboración de resúmenes y un tercero de realizar búsquedas en la web. Cada uno de estos agentes puede trabajar en conjunto, aprovechando solo el conocimiento que necesita, sin la sobrecarga de un sistema monolítico. Al implementar muchos modelos pequeños o agentes basados en lógica, las empresas pueden obtener resultados más precisos y rápidos, a la vez que reducen significativamente los costos de procesamiento y almacenamiento. Uso excesivo de los títulos de LLM: cuando la lógica simple es suficiente Por último, está el uso excesivo de los LLM en situaciones en las que bastaría con una lógica simple. Los LLM son extraordinariamente buenos para comprender y generar lenguaje natural, pero eso no significa que deban reemplazar todas las formas de automatización. Muchas tareas (como la validación de datos, el llenado de formularios o la generación de informes estructurados) se pueden realizar de forma más rápida y fiable con scripts básicos, motores de reglas o sistemas deterministas. Un buen ejemplo es el uso de un LLM para una tarea aritmética o un problema de clasificación. Esto es ineficiente e innecesario. No solo desperdicia recursos computacionales, sino que también aumenta la probabilidad de errores en casos en los que una función o un algoritmo simple serían más precisos. El afán por implementar LLM para todo se ha convertido en un síndrome del “martillo que busca clavos” del LLM. Este mal uso conduce a expectativas infladas y a una desilusión final cuando los modelos no funcionan como se espera en tareas para las que no fueron diseñados. Repensando la ingeniería de IA Es hora de repensar la ingeniería de IA y dejar atrás las modas pasajeras. La RAG tiene su lugar en el conjunto de herramientas, pero no es una panacea. El futuro está en implementar los modelos correctos para las tareas correctas; a veces eso significa RAG, pero a menudo no. Con una comprensión matizada de las capacidades de la IA, los ingenieros pueden diseñar sistemas que sean más efectivos, eficientes y fáciles de mantener. Acerca de mí: Tengo más de 20 años de experiencia combinando datos, inteligencia artificial, gestión de riesgos, estrategia y educación. Ganador de 4 hackatones y defensor del impacto social de los datos. Actualmente trabajo para impulsar la fuerza laboral de inteligencia artificial en Filipinas. Obtenga más información sobre mí aquí: https://docligot.com
