Modos de fallo de pipelines RAG: Guia de campo para depuracion en produccion

Los pipelines RAG fallan silenciosamente. A diferencia de un servicio caido o una excepcion lanzada, un pipeline RAG roto sigue devolviendo respuestas. Solo que son respuestas incorrectas, respuestas incompletas o respuestas contaminadas con informacion que nunca deberia haber llegado al LLM. El sistema parece saludable mientras entrega resultados inutiles.

Esta guia cataloga los modos de fallo que vemos repetidamente en sistemas RAG en produccion. Cada entrada sigue la misma estructura: lo que observa, por que sucede y como solucionarlo. Guardela en marcadores. La necesitara a las 2 AM cuando su pipeline de recuperacion devuelva sinsentidos y no pueda averiguar por que.

Modo de fallo 1: Fallo de recuperacion (los documentos relevantes existen pero no se recuperan)

Sintomas: El LLM dice "No tengo informacion sobre eso" o alucina una respuesta, aunque el documento correcto esta en su almacen de vectores. Los usuarios informan que el sistema "no sabe" cosas que usted sabe que indexo.

Causa raiz: El embedding de la consulta y el embedding del fragmento del documento no estan lo suficientemente cerca en el espacio vectorial a pesar de estar semanticamente relacionados. Esto sucede cuando:

• La consulta usa terminologia diferente al documento fuente (el usuario pregunta sobre "despedir empleados", los documentos usan "terminacion involuntaria")
• El modelo de embedding no fue entrenado con el vocabulario de su dominio
• Los fragmentos son demasiado grandes, diluyendo el embedding con contexto irrelevante
• Los fragmentos son demasiado pequenos, perdiendo el significado semantico que coincidiria con la consulta

Solucion:

• Agregue una capa de busqueda hibrida (busqueda por palabras clave BM25 junto con similitud vectorial) para capturar desajustes de terminologia
• Pruebe la recuperacion con consultas reales de usuarios antes de lanzar, no solo con consultas que usted mismo escribio
• Experimente con tamanos de fragmentos: 256-512 tokens es un punto de partida razonable para la mayoria de los tipos de documentos
• Considere modelos de embedding adaptados al dominio si su contenido usa vocabulario especializado
• Agregue expansion o reescritura de consultas para reformular las consultas de los usuarios antes del embedding

Modo de fallo 2: Contexto incorrecto recuperado (documentos irrelevantes obtienen alta puntuacion)

Sintomas: El LLM da respuestas seguras pero incorrectas, citando informacion del documento equivocado, la seccion equivocada o un tema completamente diferente. Los fragmentos recuperados parecen plausibles pero no son relevantes para la pregunta real.

Causa raiz: La similitud vectorial no es lo mismo que la relevancia. Dos pasajes pueden ser semanticamente similares (mismo dominio, mismo vocabulario) sin que uno sea relevante para el otro. Desencadenantes comunes:

• El texto repetitivo (encabezados, pies de pagina, descargos de responsabilidad) obtiene altas puntuaciones de similitud porque aparece en todas partes
• Los documentos de diferentes periodos de tiempo o versiones no se distinguen
• Faltan filtros de metadatos, por lo que la busqueda considera todo el corpus en lugar del subconjunto relevante

Solucion:

• Agregue filtrado por metadatos (fecha, tipo de documento, departamento, version) para que la recuperacion reduzca el espacio de busqueda antes de la clasificacion por similitud
• Elimine el texto repetitivo durante la ingesta: remueva encabezados, pies de pagina y descargos de responsabilidad repetidos antes del fragmentado
• Implemente un paso de re-clasificacion despues de la recuperacion inicial usando un modelo cross-encoder que puntue la relevancia consulta-documento con mayor precision que la similitud coseno sin procesar
• Agregue un umbral de relevancia: no pase fragmentos al LLM si su puntuacion de similitud cae por debajo de un minimo probado

Modo de fallo 3: Contexto obsoleto (los documentos estan desactualizados)

Sintomas: El LLM da respuestas basadas en informacion antigua: los precios del trimestre pasado, una politica reemplazada, un endpoint de API obsoleto. Los usuarios pierden la confianza porque saben que la informacion cambio pero el sistema sigue dando la respuesta anterior.

Causa raiz: El almacen de vectores contiene embeddings de documentos que desde entonces han sido actualizados o reemplazados, y el pipeline de indexacion no detecta ni maneja las actualizaciones. Este es el fallo mas comun de RAG en produccion porque la mayoria de los equipos construyen el pipeline de indexacion inicial pero nunca construyen el pipeline de actualizacion.

Solucion:

• Implemente versionado de documentos con marcas de tiempo en los metadatos para poder filtrar por recencia
• Construya un pipeline de reindexacion incremental que detecte documentos modificados y re-embeba solo los fragmentos actualizados
• Agregue una marca de tiempo de "ultima indexacion" a cada fragmento y muestrela al LLM en el contexto para que pueda advertir sobre informacion potencialmente obsoleta
• Programe reindexaciones completas regulares como red de seguridad, incluso si tiene actualizaciones incrementales
• Vea nuestro analisis detallado sobre la deriva de embeddings y vectores obsoletos para estrategias de deteccion

Modo de fallo 4: Corrupcion en el limite del fragmento (la respuesta se divide entre fragmentos)

Sintomas: El LLM da respuestas parciales que se sienten incompletas, o combina informacion de dos secciones no relacionadas porque el contenido relevante se dividio en los limites del fragmento. Los usuarios describen las respuestas como "cercanas pero les falta el detalle clave."

Causa raiz: La fragmentacion de tamano fijo divide los documentos en conteos arbitrarios de caracteres o tokens, ignorando los limites semanticos. Un parrafo critico se divide por la mitad. La primera mitad queda en un fragmento, la segunda en otro. La recuperacion encuentra una mitad pero no la otra.

Solucion:

• Use fragmentacion semantica que respete los limites de parrafos, secciones y encabezados
• Agregue superposicion de fragmentos (10-20% del tamano del fragmento) para que el contenido del limite aparezca en fragmentos adyacentes
• Para documentos estructurados (contratos legales, especificaciones tecnicas), fragmente por jerarquia de secciones en lugar de por tamano
• Incluya el encabezado de la seccion padre en cada fragmento para que el LLM tenga contexto estructural incluso para fragmentos a mitad de seccion
• Vea nuestro articulo sobre como los fragmentos deficientes envenenan las respuestas de RAG para un desglose detallado

Modo de fallo 5: Desbordamiento de la ventana de contexto (demasiado contexto recuperado)

Sintomas: El LLM ignora algunos documentos recuperados, da respuestas que solo hacen referencia a los primeros o ultimos fragmentos (sesgo de primacia/recencia), o produce respuestas excesivamente genericas que no se involucran con los detalles especificos del contexto.

Causa raiz: El paso de recuperacion devuelve demasiados fragmentos, excediendo la utilizacion efectiva del contexto del LLM. Incluso los modelos con ventanas de contexto de mas de 128K muestran rendimiento degradado cuando el contexto es ruidoso o excesivo. El modelo no puede distinguir la senal del ruido cuando esta enterrado en diez paginas de texto vagamente relevante.

Solucion:

• Reduzca la recuperacion top-k a 3-5 fragmentos en lugar de 10-20
• Agregue un paso de re-clasificacion y solo pase los resultados mejor clasificados al LLM
• Implemente compresion de contexto: resuma o extraiga oraciones clave de los fragmentos recuperados antes de pasarlos al modelo
• Pruebe el rendimiento real de su modelo a diferentes longitudes de contexto con sus tipos de documentos especificos
• Considere si necesita todos los fragmentos o solo el mas relevante

Modo de fallo 6: Fuga de PII a traves del contexto

Sintomas: La respuesta del LLM incluye nombres personales, direcciones de correo electronico, numeros de telefono u otra informacion de identificacion personal de documentos que no debian mostrarse al usuario actual. El equipo de cumplimiento presenta un informe de incidentes.

Causa raiz: Los documentos que contienen PII fueron indexados sin redaccion, y el pipeline de recuperacion no tiene una capa de control de acceso. El LLM incluye fielmente lo que sea que este en el contexto, incluyendo datos sensibles que nunca deberia haber visto.

Solucion:

• Agregue la redaccion de PII como una etapa del pipeline entre el analisis del documento y el fragmentado/embedding
• Implemente controles de acceso a nivel de documento y de fragmento para que la recuperacion respete los permisos de los usuarios
• Audite su almacen de vectores en busca de exposicion de PII: busque patrones (correos electronicos, numeros de telefono, SSN) en el texto de fragmentos almacenados
• Vea nuestra guia sobre fugas de PII en ventanas de contexto de RAG para un marco integral de prevencion

Modo de fallo 7: Alucinacion a pesar del contexto correcto

Sintomas: Los documentos correctos se recuperan y estan presentes en el contexto, pero el LLM aun genera informacion incorrecta. Puede sintetizar hechos que no estan en ninguno de los fragmentos recuperados, o malinterpretar el contexto y sacar conclusiones erroneas.

Causa raiz: El LLM esta mezclando su conocimiento parametrico (datos de pre-entrenamiento) con el contexto proporcionado, y su conocimiento parametrico esta ganando. Esto es mas comun con modelos mas grandes y capaces que tienen prioris fuertes. Tambien sucede cuando el contexto contradice los datos de entrenamiento del modelo: el modelo "confia en si mismo" mas que en el contexto.

Solucion:

• Agregue instrucciones explicitas en el prompt del sistema: "Responde SOLO basandote en el contexto proporcionado. Si el contexto no contiene la respuesta, dilo."
• Use modelos mas pequenos y ajustados que esten entrenados para ser fieles al contexto en lugar de depender del conocimiento parametrico
• Implemente requisitos de citacion: obligue al modelo a citar el fragmento especifico al que hace referencia
• Agregue un paso de verificacion que compruebe si la respuesta esta fundamentada en el contexto recuperado
• Considere el ajuste fino para la fidelidad al contexto si este es un problema persistente

Modo de fallo 8: Desajuste del modelo de embedding

Sintomas: La calidad de recuperacion es consistentemente pobre en todas las consultas a pesar de una buena fragmentacion y documentos suficientes. Los documentos relevantes obtienen puntuaciones mas bajas de lo esperado. Cambiar a un modelo de embedding diferente cambia dramaticamente los resultados.

Causa raiz: El modelo de embedding fue elegido basandose en puntuaciones de referencia en lugar de la adecuacion al dominio. Los modelos de embedding de proposito general pueden tener un rendimiento deficiente en contenido especializado (medico, legal, financiero) porque no fueron entrenados con ese vocabulario. Ademas, usar diferentes modelos de embedding para la indexacion y la consulta produce puntuaciones de similitud sin sentido.

Solucion:

• Siempre use el mismo modelo de embedding para la indexacion y la consulta: esto no es negociable
• Pruebe multiples modelos de embedding en sus documentos reales con sus consultas reales antes de comprometerse
• Considere modelos de embedding especificos del dominio o ajustados para contenido especializado
• Ejecute una evaluacion de recuperacion: para 50-100 pares conocidos de consulta-documento, mida si el documento correcto aparece en los resultados top-k

Lista de verificacion de diagnostico

Cuando su pipeline RAG produce malos resultados, trabaje a traves de esta lista de verificacion en orden:

1. Esta el documento en el almacen? Verifique que el documento fuente fue realmente indexado. Los fallos de ingesta son mas comunes de lo que piensa.
2. Es recuperable el fragmento? Consulte el almacen de vectores directamente con el texto exacto del documento fuente. Si incluso una coincidencia exacta falla, su pipeline de embedding esta roto.
3. Se recupera el fragmento correcto para consultas reales? Pruebe con consultas reales de usuarios, no con consultas sinteticas que usted escribio.
4. Es correcto el contenido del fragmento? Lea el texto sin procesar del fragmento. Esta completo? Esta corrupto? Contiene la informacion necesaria para responder la pregunta?
5. Esta el contexto llegando al LLM? Registre el prompt completo enviado al modelo, incluyendo todo el contexto recuperado. Confirme que nada se esta truncando o descartando.
6. Esta el LLM usando el contexto? Si el contexto es correcto pero la respuesta es incorrecta, el problema esta en el paso de generacion, no en la recuperacion.

Construyendo pipelines RAG observables

La mayoria de estos modos de fallo comparten un habilitador comun: la falta de observabilidad. Cuando su pipeline RAG es una cadena de llamadas a funciones invisibles (analisis de documentos, fragmentacion, embedding, recuperacion, ensamblaje de contexto, generacion), diagnosticar fallos requiere rastrear codigo que escribio hace meses bajo presion de plazos.

Ertas Data Suite adopta un enfoque diferente. Cada etapa del pipeline RAG es un nodo visible en un lienzo: File Import, Parser, PII Redactor, RAG Chunker, Embedding, Vector Store Writer para la indexacion; API Endpoint, Query Embedder, Vector Search, Context Assembler, API Response para la recuperacion. Cada nodo registra sus entradas y salidas. Cuando la calidad de recuperacion se degrada, puede inspeccionar exactamente lo que produjo cada etapa sin agregar sentencias de impresion a funciones Python enterradas.

El pipeline no esta oculto dentro de abstracciones de LangChain o callbacks de LlamaIndex. Es visible, auditable y depurable, que es exactamente lo que necesita cuando RAG en produccion se rompe a las 2 AM.

La verdad incomoda

Los pipelines RAG no son infraestructura de "configurar y olvidar". Son sistemas vivos que se degradan a medida que los documentos cambian, las consultas de los usuarios evolucionan y los modelos de embedding derivan. Cada equipo que despliega RAG en produccion eventualmente encuentra la mayoria de los modos de fallo de este catalogo. La diferencia entre los equipos que se recuperan rapidamente y los que pasan semanas depurando es la observabilidad: puede ver lo que cada etapa de su pipeline esta haciendo, o esta adivinando?

Construya sus pipelines RAG para poder ver dentro de ellos. Su yo futuro se lo agradecera.