Tres formas en que fallan los sistemas RAG en entornos de producción: contexto fragmentado, desviación y uso inadecuado.

Por qué las demostraciones de RAG funcionan y los sistemas en producción no

La generación mejorada por recuperación de información se ha convertido en la arquitectura estándar para la IA empresarial. Los asistentes de soporte, las herramientas internas de conocimiento, los asesores de cumplimiento y los productos de búsqueda inteligente en banca, seguros, salud, telecomunicaciones, retail y gobierno utilizan esta tecnología para conectar los modelos de lenguaje con el conocimiento propio de la empresa. La idea parece sencilla: obtener pasajes relevantes de una base de conocimiento y entregárselos al modelo antes de que responda. Sin embargo, hacer que funcione en entornos de producción es mucho más difícil de lo que sugiere una prueba de concepto.

Muchos equipos logran poner en marcha un prototipo, pero luego se enfrentan a nuevos problemas a escala. Las respuestas que reciben son incompletas. La calidad de la recuperación de información disminuye a medida que aumentan los datos. Se pierde el contexto clave, aparecen alucinaciones, la latencia aumenta gradualmente, y los usuarios reciben respuestas que, aunque técnicamente correctas, son prácticamente inútiles. A veces el sistema de recuperación encuentra los documentos exactos, pero el modelo sigue dando respuestas erróneas.

La configuración empresarial empeora aún más esta situación, ya que el conocimiento está distribuido en miles de documentos, políticas, procedimientos, manuales operativos y directrices regulatorias. Una decisión empresarial puede depender de detalles dispersos en varias secciones de un repositorio, lo que hace que la calidad de la recuperación sea tan importante como la capacidad del modelo.

Existe un concepto erróneo común según el cual un mejor RAG implica necesariamente un mejor LLM. La elección del modelo es importante, pero muchos problemas en entornos de producción surgen en otros aspectos: el procesamiento en fragmentos, la arquitectura de recuperación, la gestión del contexto, los pipelines de clasificación y la evaluación. Un sistema de recuperación bien diseñado, combinado con un modelo capaz, suele superar a uno deficiente que utilice el modelo más avanzado. En sectores regulados como la banca, conocer estos modos de fallo suele ser más valioso que saber los detalles internos del modelo más reciente, ya que el éxito en la producción rara vez depende de una sola actualización de modelo. Depende de qué tan bien se recupere, clasifique, enmarque y presente la información.

Tres escenarios muestran cómo pueden ocurrir los errores:

• Un sistema recupera material relevante pero sigue perdiendo matices cruciales.
• La calidad de la recuperación disminuye a medida que crece la base de conocimientos.

El modelo responde incorrectamente aunque se hayan recuperado los documentos adecuados.

La lección que se desprende de los tres casos es que un buen RAG proviene de una mejor recuperación de información, gestión del contexto, evaluación y diseño del sistema, y no solo de modelos más avanzados.

Caso uno: texto relevante, pero sin abordar el punto clave

Una de las situaciones más frustrantes es cuando el sistema de recuperación encuentra los pasajes relevantes, pero la respuesta sigue siendo insuficiente. Puede ser factualmente correcta, pero carecer del contexto, los detalles sutiles o las matices empresariales que un experto humano detectaría de inmediato. Esto ocurre con mayor frecuencia en documentos largos cuya información está distribuida en varias secciones.

Imagínese un repositorio de conocimientos de un banco que alberga las políticas de onboarding para clientes. Los requisitos principales se encuentran en un capítulo, el manejo de excepciones en otro, y los requisitos regulatorios en una sección separada gestionada por el departamento de riesgos. Un cliente pregunta si un documento en particular es suficiente para abrir una cuenta. El sistema de recuperación muestra la política de onboarding pero pasa por alto la excepción regulatoria documentada en otro lugar. La respuesta del modelo es correcta según lo que ha visto, pero sigue siendo incompleta para los fines empresariales. Eso es un sistema que solo comprende parte del documento y no ve el panorama general.

Los ingenieros suelen sospechar primero del modelo. El culpable habitual es la arquitectura de recuperación.

Los fragmentos de tamaño fijo interrumpen las ideas

Lo primero que hay que examinar es el proceso de fragmentación. Muchas implementaciones utilizan fragmentos de tamaño fijo porque son fáciles de crear y funcionan bien en los experimentos: dividen los documentos cada pocos cientos de tokens y almacenan las partes en una base de datos vectorial. Es sencillo, pero a menudo rompe las relaciones lógicas. Los documentos no están escritos en bloques del tamaño de un token; están organizados en torno a ideas, secciones, políticas, procedimientos y conceptos empresariales. Cuando un límite divide uno de ellos, el contexto se fragmenta. La definición de una política puede quedar en un fragmento y su excepción en otro. El sistema de recuperación obtiene la definición, pero nunca encuentra la excepción, y el modelo llega a conclusiones a partir de pruebas parciales.

Soluciones para el contexto fragmentado

El agrupamiento semántico es la solución habitual. En lugar de cortar según un número arbitrario de tokens, sigue estructuras naturales como encabezados, secciones, párrafos y cambios de tema, lo que preserva las relaciones y mejora notablemente la recuperación de información.

Incluso así, la información importante a menudo se encuentra en el límite entre dos grupos. Si los grupos son completamente independientes, la recuperación aún puede pasarla por alto. Los grupos superpuestos ayudan en este caso. Permitir que los grupos vecinos compartan parte del contenido genera continuidad más allá de los límites, ya que lo que cierra un grupo también abre el siguiente, lo que disminuye las posibilidades de perder contexto relevante.

A medida que los documentos se vuelven más complejos, un diseño de tipo padre-hijo resulta muy útil. Se incluyen y se buscan fragmentos pequeños porque brindan una precisión mayor. Una vez que un fragmento pequeño coincide, el sistema obtiene la sección principal más grande que lo contiene, de modo que el modelo puede ver tanto el detalle coincidente como su entorno. Es como encontrar el párrafo adecuado y luego leer toda la sección en lugar de solo unas pocas frases sueltas.

Los sistemas de producción también demuestran que la mejor respuesta rara vez se encuentra en un único fragmento. La información de apoyo suele estar justo antes o después del resultado principal, por lo que obtener solo el fragmento mejor clasificado puede dejar incompleto el razonamiento. Ampliar la recuperación para incluir fragmentos vecinos junto con el resultado principal mantiene la continuidad y permite al modelo ver cómo se relacionan las partes.

La creciente cantidad de bases de conocimiento eleva la importancia de la calidad en la recuperación de información. La búsqueda vectorial es excelente para encontrar contenido semánticamente similar, pero puede pasar por alto terminologías exactas, nombres de productos, identificadores de políticas, referencias regulatorias y palabras clave específicas del dominio. En la banca, un cliente puede mencionar una regulación concreta, un tipo de cuenta o una categoría de transacción que requiere una coincidencia exacta. Una estrategia híbrida que combina la búsqueda semántica con métodos basados en palabras clave como BM25 abarca ambos aspectos: la búsqueda semántica captura el significado y la búsqueda por palabras clave garantiza la precisión, y juntas cubren más que cualquiera de ellas por separado.

Por último, se realiza el reordenamiento y la optimización del contexto antes de que cualquier contenido llegue al modelo. No todo pasaje recuperado merece ocupar espacio en la solicitud final. Los herramientas de reordenamiento elevan al primer lugar el material más relevante, mientras que la optimización del contexto elimina la redundancia para aprovechar al máximo el espacio disponible. El objetivo no es simplemente recuperar texto relevante, sino dotar al modelo de la comprensión que tendría una persona experta tras leer las secciones pertinentes. Cuando la recuperación mantiene las relaciones entre conceptos, políticas, excepciones y pruebas, la calidad de las respuestas mejora significativamente y los detalles sutiles ocultos en documentos extensos dejan de perderse.

En resumen

Con este síntoma, examine la capa de recuperación anterior al modelo. Revise la estrategia de fragmentación, pase a una fragmentación semántica con solapamiento, agregue la recuperación padre-hijo, amplíe a los fragmentos vecinos y combine la búsqueda híbrida con reclasificación. Estos cambios suelen proporcionar al modelo un contexto más rico y mejor conectado, lo cual es típicamente lo que mantiene las matices en documentos largos.

Situación dos: excelente en desarrollo, deficiente en producción

Una historia común en las empresas es la siguiente: un sistema RAG brilla durante su fase de desarrollo, pero poco después del lanzamiento comienza a devolver resultados irrelevantes o inconsistentes. La demostración salió bien, las consultas de prueba dieron respuestas precisas, la recuperación de información parecía fiable y había mucha confianza. Luego llegó el tráfico real: los usuarios hacen preguntas diferentes, nuevos documentos se añaden constantemente a la base de conocimientos, los procesos empresariales cambian y el volumen aumenta. Las respuestas que antes parecían correctas se vuelven inconsistentes, incompletas o fuera de tema.

¿Han cambiado los datos?

La primera verificación es si la distribución de los datos ha cambiado. Los entornos de desarrollo contienen un conjunto de datos pequeño, seleccionado cuidadosamente y organizado. En producción pueden haber miles o millones de documentos escritos por diferentes equipos en formatos y estándares variados. Imagine un banco que comienza con un conjunto reducido de políticas de incorporación y luego va añadiendo procedimientos de cumplimiento, documentos de auditoría, pautas contra el fraude, manuales del producto, correspondencia con clientes y notificaciones regulatorias. Una consulta que antes seleccionaba entre diez documentos altamente relevantes ahora debe competir con miles de documentos parcialmente relacionados. El sistema de recuperación aún puede devolver contenido de sonido similar sin ofrecer el más útil, y eso suele ser la primera señal de que la calidad de la recuperación ha disminuido a medida que la base de conocimientos crece.

Mida la recuperación por sí sola

A continuación, evalúe la recuperación de información por separado del modelo de lenguaje. Un error común es culpar al LLM por respuestas deficientes cuando el sistema de recuperación nunca proporcionó el contexto adecuado. Métricas como Recall@K y Precision@K lo resuelven rápidamente: si el documento correcto no aparece entre los resultados principales, el modelo nunca tuvo oportunidad. Con frecuencia, es el propio proceso de recuperación el que necesita mejoras.

Una causa frecuente es la deriva de los embeddings. Un modelo de embeddings que funcionaba bien con un conjunto de datos pequeño puede tener dificultades a medida que los documentos se diversifican, ya que diferentes tipos, estilos de escritura y vocabularios específicos del área diluyen su eficacia con el tiempo. La base de conocimientos de un banco podría combinar políticas de los equipos de cumplimiento, manuales de los equipos comerciales y especificaciones de los ingenieros. Todo ello pertenece a una misma organización, pero el lenguaje varía mucho; si los embeddings no capturan esas diferencias, la calidad disminuye.

Las estrategias de fragmentación también pueden volverse obsoletas. Un enfoque que funcionó con cientos de documentos podría fallar con cientos de miles, ya que los fragmentos mal estructurados añaden ruido a la búsqueda de similitudes y dificultan encontrar lo relevante. Por eso, los sistemas RAG en producción necesitan una evaluación continua y no solo una implementación única.

Las consultas reales difieren de las consultas de prueba

Los patrones de consulta merecen atención. Las pruebas de desarrollo suelen incluir preguntas ideales, ya que los ingenieros conocen ya los datos. Los usuarios reales hacen preguntas vagas o incompletas y utilizan términos que la base de conocimientos no contiene. Un agente de servicio podría buscar “reglas de cierre de cuentas premium”, mientras que los documentos oficiales hablan de “procedimientos para finalizar cuentas de clientes de alto valor”. La gente percibe el enlace de inmediato, pero el sistema de recuperación puede no hacerlo. Observar cómo interactúan los usuarios reales suele revelar debilidades que las pruebas nunca detectan.

Veámoslo dentro del pipeline

La observabilidad en la recuperación de datos es otra técnica valiosa. Para cada consulta en producción, la visibilidad debe abarcar:

• qué documentos se recuperaron
• la razón por la que cada uno fue recuperado
• las puntuaciones de similitud
• el contexto final enviado al LLM
• la respuesta generada

Sin esto, la depuración se convierte en una suposición. Con él, las trazas suelen mostrar si el problema surgió en la recuperación, en el reordenamiento, en la construcción de la instrucción o en la generación.

A medida que los datos siguen creciendo, se pueden añadir capas adicionales delante de la búsqueda vectorial, como recuperación híbrida, filtros de metadatos, clasificación de documentos, reordenadores o pipelines específicos del dominio. Por ejemplo, una pregunta bancaria sobre hipotecas debería buscar material relacionado con hipotecas antes que en toda la base de conocimientos empresarial. Reducir el espacio de búsqueda mejora tanto la precisión como la calidad de las respuestas.

La conclusión es que los sistemas RAG de producción son sistemas dinámicos que evolucionan junto con sus datos. No se debe dar por sentado que una solución que funciona bien desde el primer día seguirá funcionando igual después de seis meses; por lo tanto, el monitoreo continuo, la evaluación y el reentrenamiento de los componentes de recuperación son esenciales para mantener la calidad a gran escala.

En resumen

Cuando un sistema funciona bien en la fase de desarrollo pero mal en producción, primero se deben separar los problemas de recuperación de los problemas de generación. Analice las métricas de recuperación, examine los documentos recuperados, verifique la calidad de los embeddings, estudie los patrones reales de consultas e implante mecanismos de observabilidad en todo el proceso. A medida que aumente el volumen de datos, considere el uso de búsquedas híbridas, filtrado de metadatos, reclasificación y métodos de recuperación específicos para cada dominio, a fin de mantener los resultados relevantes y precisos.

Escenario tres: documentos correctos, respuesta incorrecta

Muchos ingenieros asumen que una vez que la recuperación de información funciona, el trabajo está hecho. Uno de los escenarios más difíciles en RAG es justo lo contrario: el sistema encuentra los documentos correctos y el modelo sigue respondiendo incorrectamente. Es especialmente frustrante porque el instinto habitual de depuración apunta directamente a la recuperación de información, mientras que el sistema encargado de ella podría estar realizando su tarea a la perfección. El fallo radica en cómo el modelo procesa y analiza ese contexto.

Imagínese a un asistente de cumplimiento bancario que responde preguntas sobre la lucha contra el blanqueo de dinero. Un usuario pregunta si una cuenta de cliente puede permanecer activa mientras se espera la verificación KYC. La recuperación de información devuelve los documentos normativos adecuados, y la regla relevante está incluida en el contexto. Sin embargo, la respuesta afirma que la cuenta puede permanecer activa indefinidamente. La información necesaria estaba presente, pero el modelo no logró utilizarla correctamente.

Sobrecarga de contexto y problema intermedio

Una de las causas es la sobrecarga de contexto. Cuantos más documentos se recuperan, más tiene que asimilar el modelo, y no todo es igualmente importante, por lo que los detalles cruciales pueden quedar enterrados en una instrucción larga. Esto a menudo se conoce como el problema de “perderse en medio”: los modelos tienden a prestar atención al material cercano al inicio y al final del contexto, pasando por alto lo que está en el medio. La respuesta correcta puede estar literalmente en la instrucción y, aun así, ser ignorada.

La solución consiste en priorizar la calidad del contexto sobre su cantidad. Los equipos a menudo intentan mejorar la precisión recuperando más información, pero más contexto no garantiza necesariamente respuestas mejores; unos pocos pasajes de alta calidad suelen superar a un montón de textos poco relacionados entre sí. La reclasificación es útil en este caso, ya que ordena los pasajes más relevantes antes de que el modelo los vea. Proporcionar al modelo tres documentos altamente relevantes con pruebas claras puede ser más efectivo que diez de relevancia moderada.

Prompts que exigen fundamentación

También es importante el diseño de los prompts. En lugar de permitir que el modelo responda libremente, instrúyalo a basar su respuesta estrictamente en el contexto recuperado y a indicar claramente que no hay suficiente información cuando las pruebas no permiten dar una respuesta. Esto reduce significativamente el razonamiento sin fundamento.

La generación basada en citas también es útil. Cuando el modelo debe nombrar secciones específicas o identificadores de documentos, resulta mucho más fácil verificar si una respuesta se sustenta en las pruebas obtenidas, lo cual es importante en industrias reguladas como la banca, donde la auditabilidad y la explicabilidad son requisitos esenciales.

Fuentes conflictivas

Verifique si los documentos obtenidos son contradictorios. Las grandes organizaciones suelen conservar varias versiones de políticas, procedimientos y pautas, y si la recuperación muestra simultáneamente versiones obsoletas y actuales, el modelo podría no saber cuál tiene prioridad. El filtrado de metadatos y la versionación de documentos se vuelven indispensables.

El objetivo no es simplemente recuperar información, sino asegurarse de que el modelo pueda identificar, priorizar y razonar sobre las pruebas más relevantes que contiene. Un sistema RAG solo tiene éxito cuando la recuperación de información y el razonamiento funcionan en conjunto.

En resumen

Cuando los documentos adecuados vuelven a aparecer y la respuesta sigue siendo incorrecta, observe cómo utiliza el modelo el contexto: sobrecarga, efectos de “perdido en medio”, fuentes contradictorias y una base de información débil. Las soluciones que vale la pena probar son el reordenamiento, la reducción del contexto, respuestas que citan sus fuentes, filtros de metadatos y instrucciones que obligan al modelo a basarse únicamente en las pruebas obtenidas. A menudo, el problema no radica en la recuperación de información en sí, sino en cómo se utiliza ese contexto.

Lo que tienen en común los tres casos

Construir un buen sistema RAG requiere mucho más que simplemente conectar una base de datos vectorial a un LLM. Las implementaciones de prueba suelen parecer impresionantes, pero los verdaderos desafíos surgen cuando los sistemas entran en producción y deben funcionar de manera fiable a gran escala. En estos tres escenarios, los fragmentos de contexto dispersos en documentos extensos hacen que la calidad de la recuperación disminuya a medida que los repositorios crecen, e incluso con la información correcta recuperada, el modelo podría no ser capaz de razonar sobre ella.

El tema recurrente es que la calidad de la recuperación es tan importante como las capacidades del modelo. El LLM más avanzado no puede compensar la falta de contexto, los fragmentos mal estructurados, las estrategias de recuperación débiles o el material irrelevante en la instrucción; además, mejorar la arquitectura de recuperación suele dar mejores resultados que reemplazar el modelo. Para ingenieros, arquitectos y líderes técnicos, lo que diferencia a los sistemas de nivel profesional de las demostraciones llamativas es un diseño cuidadoso: una segmentación adecuada, pipelines de recuperación sólidos, enfoque en el contexto, reclasificación y evaluación continua. La IA empresarial no se trata solo de generar respuestas, sino de crear respuestas relevantes, fundamentadas, explicables y consistentemente fiables.

Lecturas relacionadas

• Ingestión de datos RAG en producción para bancos: PDFs, OCR, tablas y conectores — Cómo ingresar documentos bancarios para RAG: clasificar PDFs, ejecutar OCR con indicadores de revisión, mantener la estructura de Word, manejar tablas e imágenes, y crear conectores resistentes.
• Limpieza de datos para RAG en producción: codificación, OCR, eliminación de duplicados y PII — Cómo convertir documentos empresariales analizados en texto listo para la recuperación: reparación de codificación, eliminación de textos genéricos y duplicados, indicadores de OCR riesgosos, manejo de idiomas y enmascaramiento de PII.