En un par de años, RAG se ha convertido en una especie de señal de credibilidad en el campo de la IA. Si una empresa quiere parecer seria ante los inversores, los clientes o incluso su propio liderazgo, ahora se espera que tenga lista una historia de recuperación-generación aumentada. Los LLM cambiaron el panorama casi de la noche a la mañana e impulsaron la IA generativa a casi todas las conversaciones comerciales.
Pero en la práctica: construir un mal sistema RAG es peor que no tener ningún RAG.
He visto este patrón repetirse una y otra vez. Algo se envía rápidamente, la demostración se ve bien, el liderazgo está satisfecho. Entonces los usuarios reales empiezan a hacer preguntas reales. Las respuestas son vagas. A veces mal. De vez en cuando confiado y completamente absurdo. Generalmente ese es el final. La confianza desaparece rápidamente, y una vez que los usuarios deciden que no se puede confiar en un sistema, no vuelven a comprobarlo para ver si ha mejorado y no le darán una segunda oportunidad. Simplemente dejan de usarlo.
En este caso, el verdadero fallo no es técnico sino humano. La gente tolerará herramientas lentas e interfaces torpes. Lo que no tolerarán es que los engañen. Cuando un sistema le da la respuesta incorrecta con confianza, se siente engañoso. Recuperarse de eso, incluso después de meses de trabajo, es extremadamente difícil.
Sólo unas pocas respuestas incorrectas son suficientes para que los usuarios vuelvan a realizar búsquedas manuales. Cuando el sistema finalmente se vuelve verdaderamente confiable, el daño ya está hecho y nadie quiere usarlo más.
En este artículo, comparto seis lecciones que desearía haber sabido antes de implementar proyectos RAG para clientes.
1. Comience con un problema empresarial real
Las decisiones importantes de RAG se toman mucho antes de escribir cualquier código.
¿Por qué te embarcas en este proyecto? Realmente es necesario identificar el problema a resolver. Hacerlo “porque todos los demás lo hacen” no es una estrategia. Luego está la cuestión del retorno de la inversión, que todo el mundo evita. ¿Cuánto tiempo se ahorrará esto realmente en flujos de trabajo concretos y no solo en base a métricas abstractas presentadas en diapositivas? Y finalmente, el caso de uso. Aquí es donde la mayoría de los proyectos RAG fracasan silenciosamente. “Responder preguntas internas” no es un caso de uso. ¿Está ayudando a RR.HH. a responder a preguntas sobre políticas sin interminables idas y venidas? ¿Está brindando a los desarrolladores acceso instantáneo y preciso a la documentación interna mientras codifican? ¿Es un asistente de incorporación de alcance limitado durante los primeros 30 días de una nueva contratación? Un sistema RAG potente hace una cosa bien.
RAG puede ser poderoso. Puede ahorrar tiempo, reducir la fricción y mejorar genuinamente la forma en que trabajan los equipos. Pero sólo si se trata como una infraestructura real, no como un experimento de tendencia.
La regla es simple: no sigas las tendencias. Implementar valor.
Si ese valor no se puede medir claramente en tiempo ahorrado, ganancia de eficiencia o reducción de costos, entonces el proyecto probablemente no debería existir en absoluto.
2. La preparación de datos llevará más tiempo del esperado
Muchos equipos apresuran el desarrollo de RAG y, para ser honesto, se puede lograr un MVP simple muy rápidamente si no nos concentramos en el rendimiento. Pero RAG no es un prototipo rápido; Es un enorme proyecto de infraestructura. En el momento en que comience a estresar su sistema con datos reales en evolución en producción, las debilidades en su canal comenzarán a surgir.
Dada la reciente popularidad de los LLM con grandes ventanas de contexto, a veces medidas en millones, algunos declaran que los modelos de contexto largo hacen que la recuperación sea opcional y los equipos simplemente están tratando de evitar el paso de recuperación. Pero por lo que he visto, al implementar esta arquitectura muchas veces, las ventanas de contexto grandes en los LLM son muy útiles, pero no sustituyen a una buena solución RAG. Cuando se compara la complejidad, la latencia y el costo de pasar una ventana de contexto masiva versus recuperar solo los fragmentos más relevantes, sigue siendo necesario un sistema RAG bien diseñado.
Pero, ¿qué define un “buen” sistema de recuperación? Tus datos y su calidad, por supuesto. El principio clásico de “basura entra, basura sale” se aplica tanto aquí como en el aprendizaje automático tradicional. Si sus datos de origen no están preparados meticulosamente, todo su sistema tendrá problemas. No importa qué LLM utilices; la calidad de su recuperación es el componente más crítico.
Con demasiada frecuencia, los equipos envían datos sin procesar directamente a su base de datos de vectores (VectorDB). Rápidamente se convierte en una zona de pruebas donde el único mecanismo de recuperación es una aplicación basada en similitud de cosenos. Si bien puede pasar las pruebas internas rápidas, es casi seguro que fallará bajo la presión del mundo real.
En los sistemas RAG maduros, la preparación de datos tiene su propio proceso con pruebas y pasos de versionado. Esto significa limpiar y preprocesar su corpus de entrada. Ninguna fragmentación inteligente o arquitectura sofisticada puede corregir datos fundamentalmente incorrectos.
3. La fragmentación eficaz consiste en mantener las ideas intactas
Cuando hablamos de preparación de datos, no solo nos referimos a datos limpios; Estamos hablando de un contexto significativo. Eso nos lleva a fragmentar.
La fragmentación se refiere a dividir un documento fuente, tal vez un PDF o un documento interno, en partes más pequeñas antes de codificarlo en forma vectorial y almacenarlo en una base de datos.
¿Por qué es necesaria la fragmentación? Los LLM tienen una cantidad limitada de tokens, e incluso los “LLM de contexto largo” resultan costosos y se distraen con demasiado ruido. La esencia de la fragmentación es seleccionar el bit de información más relevante que responderá a la pregunta del usuario y transmitir solo ese bit al LLM.
La mayoría de los equipos de desarrollo dividen documentos utilizando técnicas simples: límites de tokens, recuento de caracteres o párrafos aproximados. Estos métodos son muy rápidos, pero normalmente es en ese punto donde la recuperación comienza a degradarse.
Cuando fragmentamos un texto sin reglas inteligentes, se convierte en fragmentos en lugar de conceptos completos. El resultado son piezas que poco a poco se separan y se vuelven poco fiables. Copiar una estrategia ingenua de fragmentación de la arquitectura publicada de otra empresa, sin comprender su propia estructura de datos, es peligroso.
Los mejores sistemas RAG que he visto incorporan Semantic Chunking.
En la práctica, la fragmentación semántica significa dividir el texto en partes significativas, no solo en tamaños aleatorios. La idea es mantener cada pieza enfocada en un pensamiento completo. El objetivo es asegurarse de que cada fragmento represente una única idea completa.
Cómo implementarlo: Puede implementar esto usando técnicas como: División recursiva: dividir el texto basándose en delimitadores estructurales (por ejemplo, secciones, encabezados, luego párrafos y luego oraciones). Transformadores de oraciones: utiliza un modelo liviano y compacto para identificar todas las transiciones importantes en función de reglas semánticas para segmentar el texto en esos puntos.
Para implementar técnicas más sólidas, puede consultar bibliotecas de código abierto, como los diversos módulos de segmentación de texto de LangChain (especialmente sus módulos recursivos avanzados) y artículos de investigación sobre segmentación de temas.
4. Tus datos quedarán obsoletos
La lista de problemas no termina ahí una vez que lo hayas lanzado. ¿Qué sucede cuando sus datos de origen evolucionan? Las incorporaciones obsoletas acaban lentamente con los sistemas RAG con el tiempo.
Esto es lo que sucede cuando el conocimiento subyacente en su corpus de documentos cambia (nuevas políticas, hechos actualizados, documentación reestructurada) pero los vectores en su base de datos nunca se actualizan.
Si sus incrustaciones son débiles, su modelo esencialmente alucinará a partir de un registro histórico en lugar de hechos actuales.
¿Por qué es técnicamente difícil actualizar VectorDB? Las bases de datos vectoriales son muy diferentes de las bases de datos SQL tradicionales. Cada vez que actualiza un solo documento, no simplemente cambia un par de campos, sino que es posible que tenga que volver a fragmentar todo el documento, generar nuevos vectores grandes y luego reemplazar o eliminar por completo los antiguos. Se trata de una operación computacional intensiva, que requiere mucho tiempo y que puede conducir fácilmente a una situación de tiempo de inactividad o inconsistencias si no se trata con cuidado. Los equipos suelen omitir esto porque el esfuerzo de ingeniería no es trivial.
¿Cuándo hay que volver a incrustar el corpus? No existe una regla general; Las pruebas son su única guía durante esta fase de POC. No espere una cantidad específica de cambios en sus datos; el mejor enfoque es hacer que su sistema se reincorpore automáticamente, por ejemplo, después del lanzamiento de una versión principal de sus reglas internas (si está creando un sistema de recursos humanos). También es necesario volver a incrustarlo si el dominio en sí cambia significativamente (por ejemplo, en caso de algún cambio regulatorio importante).
Una buena práctica es incrustar versiones o realizar un seguimiento de qué documentos están asociados con qué ejecución para generar un vector. Este espacio necesita ideas innovadoras; La migración en VectorDB suele ser un paso omitido por muchos equipos.
5. Sin evaluación, las fallas surgen solo cuando los usuarios se quejan
La evaluación RAG significa medir qué tan bien se desempeña realmente su aplicación RAG. La idea es comprobar si su asistente de conocimientos impulsado por RAG brinda respuestas precisas, útiles y fundamentadas. O, más simplemente: ¿realmente funciona para su caso de uso real?
Evaluar un sistema RAG es diferente a evaluar un LLM clásico. Su sistema tiene que funcionar con consultas reales que no puede anticipar por completo. Lo que desea comprender es si el sistema obtiene la información correcta y responde correctamente.
Un sistema RAG está formado por múltiples componentes, desde cómo fragmenta y almacena sus documentos hasta la incrustación, la recuperación, el formato de solicitud y la versión LLM.
Por esta razón, la evaluación del GAR también debería ser multinivel. Las mejores evaluaciones incluyen métricas para cada parte del sistema por separado, así como métricas comerciales para evaluar el rendimiento de todo el sistema de un extremo a otro.
Si bien esta evaluación generalmente comienza durante el desarrollo, la necesitará en cada etapa del ciclo de vida del producto de IA.
Una evaluación rigurosa transforma a RAG de una prueba de concepto a un proyecto técnico mensurable.
6. Las arquitecturas de moda rara vez se adaptan a su problema
Las decisiones de arquitectura con frecuencia se importan de publicaciones de blogs o conferencias sin siquiera preguntarse si se ajustan a los requisitos internos específicos.
Para aquellos que no están familiarizados con RAG, existen muchas arquitecturas RAG, comenzando desde un sistema RAG monolítico simple y ampliando hasta flujos de trabajo complejos y agentes.
No necesita un Agentic RAG complicado para que su sistema funcione bien. De hecho, la mayoría de los problemas empresariales se resuelven mejor con una arquitectura RAG básica o RAG de dos pasos. Sé que las palabras “agente” y “agentic” son populares en este momento, pero priorice el valor implementado sobre las tendencias implementadas.
RAG monolítico (básico): comience aquí. Si las consultas de sus usuarios son sencillas y repetitivas (“¿Cuál es la política de vacaciones?”), todo lo que necesita es una canalización RAG simple que recupere y genere. Reescritura de consultas en dos pasos: utilice esto cuando la entrada del usuario pueda ser indirecta o ambigua. El primer paso del LLM reescribe la entrada ambigua del usuario en una consulta de búsqueda mejor y más limpia para VectorDB. Agentic RAG: considere esto solo cuando el caso de uso requiera un razonamiento complejo, ejecución de flujo de trabajo o uso de herramientas (por ejemplo, “Busque la política, resúmala y luego redacte un correo electrónico a RR.HH. solicitando una aclaración”).
Los sistemas RAG son una arquitectura fascinante que ha ganado un gran impulso recientemente. Si bien algunos afirman que “RAG está muerto”, yo creo que este escepticismo es simplemente una parte natural de una era en la que la tecnología evoluciona increíblemente rápido.
Si su caso de uso es claro y desea resolver un problema específico que involucra grandes volúmenes de datos de documentos, RAG sigue siendo una arquitectura altamente efectiva. La clave es mantenerlo simple e integrar al usuario desde el principio.
No olvide que construir un sistema RAG es una tarea compleja que requiere una combinación de habilidades de aprendizaje automático, MLOps, implementación e infraestructura. Es absolutamente necesario embarcarse en el viaje con todos, desde los desarrolladores hasta los usuarios finales, involucrados desde el primer día.
🤝 Manténgase conectado
Si te ha gustado este artículo, no dudes en seguirme en LinkedIn para obtener información más honesta sobre IA, ciencia de datos y carreras.
👉 LinkedIn: Sabrine Bendimerad
👉 Medio: https://medium.com/@sabrine.bendimerad1
👉 Instagram: https://tinyurl.com/datailearn