Alucinacion RAG vs. Fallo de Recuperacion: Un Marco de Diagnostico

Un usuario hace una pregunta a tu sistema RAG. La respuesta es incorrecta. Y ahora, que sigue.

Este es el momento en que la mayoria de los equipos cometen el mismo error: asumen que el problema es el LLM y comienzan a ajustar prompts. Agregan instrucciones como "solo usa el contexto proporcionado" o "responde que no sabes si la respuesta no esta en el contexto." A veces esto ayuda. Con frecuencia no funciona, porque el problema real nunca fue el LLM — fue el pipeline de recuperacion alimentandolo con contexto incorrecto o ausente.

Una respuesta incorrecta de un sistema RAG tiene dos causas raiz fundamentalmente diferentes, y la solucion para una no hace nada por la otra. La alucinacion es un problema de generacion: el LLM tenia el contexto correcto pero fabrico o distorsiono informacion en su respuesta. El fallo de recuperacion es un problema del pipeline: el LLM nunca recibio el contexto correcto en primer lugar, asi que invento algo, cito pasajes irrelevantes o dio una respuesta parcial.

Diagnosticar incorrectamente la causa raiz significa perder tiempo con la solucion equivocada. Este articulo proporciona un marco estructurado para distinguir entre ambos problemas.

Los Dos Modos de Fallo

Fallo de Recuperacion

El pipeline de recuperacion no presento los documentos o fragmentos que contienen la respuesta. El LLM recibe contexto irrelevante, parcialmente relevante o vacio — y luego hace su mejor esfuerzo para responder de todos modos.

Los fallos de recuperacion ocurren antes del LLM. El modelo de embeddings, la estrategia de fragmentacion, la consulta al vector store, los filtros de metadatos o el paso de re-ranking no identificaron el contenido correcto. El LLM funciona correctamente — simplemente trabaja con las entradas equivocadas.

Alucinacion del LLM

El pipeline de recuperacion presento el contexto correcto. El LLM recibio documentos relevantes que contienen la respuesta. Pero la respuesta generada contradice, distorsiona o fabrica informacion que no esta respaldada por el contexto proporcionado.

La alucinacion ocurre despues de la recuperacion. El pipeline hizo su trabajo. El LLM no represento fielmente lo que se le proporciono.

Por Que Importa la Distincion

La solucion para el fallo de recuperacion es trabajo de pipeline: ajustar tamanos de fragmentos, mejorar los embeddings, corregir filtros de metadatos, agregar re-ranking, reparar la corrupcion del indice. Ninguna cantidad de ingenieria de prompts arreglara un pipeline que no recupera los documentos correctos.

La solucion para la alucinacion es trabajo de generacion: mejorar prompts, usar formatos de salida estructurados, agregar requisitos de citacion, cambiar a un modelo mas capaz o implementar verificacion post-generacion contra el contexto fuente.

Aplicar la solucion equivocada desperdicia tiempo y puede empeorar las cosas. Agregar instrucciones de "solo responde desde el contexto" a un sistema con fallos de recuperacion simplemente hara que se niegue a responder — el contexto no contiene la respuesta, asi que la instruccion funciona segun lo disenado pero la experiencia del usuario se degrada.

Diagrama de Flujo de Diagnostico

Sigue esta secuencia para diagnosticar si una respuesta incorrecta de un sistema RAG es un problema de recuperacion o un problema de alucinacion.

Paso 1: Captura el contexto recuperado.

Antes de diagnosticar cualquier cosa, necesitas ver lo que el LLM realmente recibio. Registra o muestra los fragmentos que el pipeline de recuperacion devolvio para la consulta. Si tu sistema no expone esta informacion, eso es lo primero que debes corregir — no puedes diagnosticar lo que no puedes observar.

Paso 2: El contexto recuperado contiene la respuesta correcta?

Lee los fragmentos recuperados tu mismo. La informacion necesaria para responder correctamente la consulta esta presente en el contexto?

Si NO: Esto es un fallo de recuperacion. Continua a la seccion de diagnostico de recuperacion a continuacion.
Si SI: Continua al Paso 3.

Paso 3: La respuesta del LLM representa fielmente el contexto recuperado?

Compara la respuesta del LLM con el contexto recuperado. La respuesta refleja con precision lo que esta en el contexto, o contradice, embellece o fabrica?

Si la respuesta contradice o agrega informacion que no esta en el contexto: Esto es alucinacion. Continua a la seccion de diagnostico de alucinacion.
Si la respuesta es precisa pero incompleta: Podria ser cualquiera — el contexto puede haber contenido la respuesta completa pero el LLM omitio partes (alucinacion por omision), o el contexto mismo estaba incompleto (fallo parcial de recuperacion). Verifica si los documentos fuente contienen informacion que no fue recuperada.

Paso 4: El fallo es consistente o intermitente?

Ejecuta la misma consulta multiples veces (con temperature superior a 0).

Si la respuesta es consistentemente incorrecta de la misma manera: Mas probable que sea un fallo de recuperacion (el mismo contexto incorrecto se recupera cada vez).
Si la respuesta varia entre correcta e incorrecta: Mas probable que sea alucinacion (el LLM es no determinista en como usa el contexto).

Tabla de Comparacion de Sintomas

Sintoma	Fallo de Recuperacion	Alucinacion del LLM
La respuesta es incorrecta con confianza	Comun — el LLM confabula a partir de contexto irrelevante	Comun — el LLM fabrica a pesar del contexto correcto
La respuesta dice "No se" cuando deberia saber	Probable — el contexto correcto no fue recuperado	Improbable — el LLM tiene la respuesta en el contexto pero decidio no usarla (raro)
La respuesta cita un documento real pero la seccion incorrecta	Probable — recupero el fragmento equivocado del documento correcto	Posible — el LLM atribuyo incorrectamente dentro del contexto
La respuesta cita un documento que no existe	Improbable — la recuperacion devuelve documentos reales	Probable — el LLM fabrico la citacion
La respuesta contiene numeros o fechas especificas que son incorrectos	Verifica el contexto — si los numeros no estan en los fragmentos recuperados, es fallo de recuperacion	Si los numeros estan en el contexto pero el LLM los cambio, es alucinacion
La respuesta es parcialmente correcta, parcialmente fabricada	Probable — algo de contexto relevante fue recuperado, algo falta	Probable — el LLM mezclo contexto real con fabricacion
La misma consulta devuelve diferentes respuestas incorrectas	Improbable — la recuperacion es determinista	Probable — generacion no determinista
El problema aparecio repentinamente despues de un cambio en el pipeline	Probable — un cambio en indexacion, embeddings o fragmentacion rompio la recuperacion	Improbable — a menos que se haya cambiado el modelo o el prompt
El problema afecta un tema especifico pero no otros	Probable — esos documentos no fueron indexados, o la fragmentacion los rompio	Improbable — la alucinacion generalmente no es especifica de un tema

Diagnosticando Fallos de Recuperacion

Una vez que has confirmado que el contexto correcto no fue recuperado, identifica donde en el pipeline de recuperacion ocurre el fallo.

Verificacion 1: El documento fuente esta en el indice?

Consulta el vector store directamente por el documento usando sus metadatos (nombre de archivo, ID de documento). Si el documento no esta en el indice, nunca fue indexado o se perdio por corrupcion del indice. Este es un problema de ingesta o integridad del indice, no un problema de recuperacion.

Verificacion 2: El fragmento relevante esta en el indice?

El documento puede estar indexado, pero el pasaje especifico que responde la consulta puede haberse dividido entre fragmentos de una manera que fragmenta la respuesta. Recupera todos los fragmentos del documento fuente y examina si algun fragmento individual contiene la respuesta completa. Si la respuesta abarca dos o mas fragmentos, tu estrategia de fragmentacion necesita ajuste — fragmentos mas grandes, mas solapamiento o fragmentacion semantica.

Verificacion 3: El embedding captura la relacion semantica?

Genera el embedding para la consulta y para el fragmento que deberia haberse recuperado. Calcula su similitud del coseno. Si la similitud es baja a pesar de que el fragmento es semanticamente relevante para la consulta, el modelo de embeddings esta fallando en capturar la relacion. Esto ocurre con vocabulario especifico del dominio en el que el modelo de embeddings no fue entrenado. Considera un modelo de embeddings especifico del dominio o expansion de consultas.

Verificacion 4: Los filtros de metadatos son demasiado restrictivos?

Si tu pipeline de recuperacion usa filtros de metadatos (rangos de fechas, tipos de documentos, departamentos), verifica que los filtros no esten excluyendo los documentos correctos. Esta es una causa sorprendentemente comun de fallo de recuperacion — un filtro que era correcto cuando se configuro se vuelve obsoleto a medida que llegan nuevos documentos con diferentes patrones de metadatos.

Verificacion 5: El re-ranker esta bajando la posicion del fragmento correcto?

Si usas un paso de re-ranking despues de la recuperacion inicial, el re-ranker puede estar puntuando el fragmento correcto por debajo de fragmentos irrelevantes. Verifica los resultados previos al re-ranking para ver si el fragmento correcto fue recuperado inicialmente pero luego fue bajado de posicion.

Diagnosticando la Alucinacion del LLM

Cuando el contexto es correcto pero la salida del LLM es incorrecta, investiga estos factores.

Desbordamiento de ventana de contexto: Si el contexto recuperado es muy largo, el LLM puede perder de vista la informacion en el medio del contexto. Este es el fenomeno de "perdido en el medio." Prueba colocando el fragmento relevante primero en el contexto y observa si la respuesta mejora.

Contexto contradictorio: Si multiples fragmentos recuperados contienen informacion diferente o contradictoria, el LLM puede fusionarlos incorrectamente o elegir el equivocado. Verifica si los fragmentos recuperados son consistentes entre si.

Conflictos en instrucciones del prompt: El prompt del sistema puede contener instrucciones que entran en conflicto con el uso fiel del contexto. Instrucciones como "se servicial y proporciona respuestas completas" pueden motivar al LLM a complementar el contexto con su conocimiento parametrico, lo que lleva a la fabricacion.

Limites de capacidad del modelo: Algunos modelos son mejores que otros en el anclaje fiel al contexto. Si la alucinacion persiste despues de la optimizacion del prompt, considera cambiar a un modelo con capacidades mas fuertes de seguimiento de instrucciones y anclaje al contexto.

Corrigiendo el Problema Correcto

Una vez que has diagnosticado la causa raiz, aplica la correccion dirigida.

Para fallos de recuperacion:

Re-indexar documentos faltantes
Ajustar tamanos y solapamiento de fragmentos
Cambiar a un modelo de embeddings apropiado para el dominio
Relajar filtros de metadatos demasiado restrictivos
Agregar expansion de consultas o busqueda hibrida (por palabras clave mas semantica)
Implementar un paso de re-ranking o ajustar el existente

Para alucinacion del LLM:

Agregar instrucciones explicitas de anclaje: "Solo usa informacion del contexto proporcionado"
Requerir citaciones en linea: obligar al LLM a referenciar fragmentos especificos
Usar formatos de salida estructurados que limiten la respuesta
Reducir la longitud del contexto para evitar efectos de "perdido en el medio"
Implementar verificacion post-generacion: comprobar afirmaciones en la respuesta contra el contexto fuente
Reducir la temperature para disminuir la varianza en las respuestas

Donde Encaja Ertas

El prerrequisito fundamental para todo este marco de diagnostico es la observabilidad. Necesitas ver el contexto recuperado, no solo la respuesta final. Necesitas rastrear una consulta a traves del pipeline de recuperacion — desde el embedding hasta la busqueda vectorial, pasando por el re-ranking hasta el ensamblaje de contexto — y ver que ocurrio en cada etapa.

Ertas Data Suite construye pipelines de recuperacion RAG como flujos de trabajo visuales basados en nodos sobre un canvas. Cada nodo en el pipeline — Query Embedder, Vector Search, Context Assembler, API Response — es observable de forma independiente. Cuando una consulta produce un resultado incorrecto, puedes inspeccionar la salida de cada nodo para ver exactamente donde fallo el pipeline: Capturo el embedding la intencion de la consulta? Devolvio la busqueda vectorial los fragmentos correctos? El ensamblador de contexto los formato correctamente?

Esta es la diferencia entre "el sistema RAG dio una respuesta incorrecta" (un callejon sin salida) y "la busqueda vectorial devolvio 5 fragmentos, ninguno del documento correcto, porque el filtro de metadatos excluyo documentos subidos despues de enero" (un diagnostico accionable). Los pipelines observables convierten la depuracion de adivinacion en ingenieria.

Conclusiones Clave

Una respuesta incorrecta de un sistema RAG no es un problema unico. Es un fallo de recuperacion (el LLM nunca obtuvo el contexto correcto) o una alucinacion (el LLM tenia el contexto correcto pero no lo uso fielmente). El proceso de diagnostico comienza inspeccionando el contexto recuperado — todo lo demas se deriva de ahi.

Construye tu sistema RAG con la observabilidad como un requisito de primera clase, no como algo a posteriori. Registra el contexto recuperado para cada consulta. Mantiene consultas de prueba con respuestas conocidas. Y cuando algo salga mal, diagnostica antes de corregir — los cinco minutos invertidos en confirmar la causa raiz ahorraran dias de ajustar el componente equivocado.