Alucinaciones: cuatro causas raíz y sus antídotos
Distinguir un fallo de recuperación de un fallo de fidelidad, porque la solución no es la misma en absoluto.
Casi todo lo que se escribe sobre alucinaciones en RAG trata el problema como si fuera uno solo. No lo es: son cuatro fallos con orígenes distintos que se manifiestan de forma parecida. Esta entrega va sobre cómo distinguirlos ante una respuesta mala concreta, porque el remedio de cada uno es inútil contra los otros tres.
Por qué la palabra estorba
«Alucinación» describe un síntoma: el sistema ha afirmado algo que no es cierto, o que no se sostiene en el material que debía usar. Como etiqueta operativa es inservible, porque agrupa situaciones que exigen intervenciones en puntos completamente distintos del pipeline. Cambiar el prompt no arregla un fragmento que nunca se recuperó. Cambiar de modelo de embeddings no arregla un corpus que no contiene la respuesta.
En un sistema RAG las causas raíz son cuatro, y están ordenadas por el punto del recorrido en que aparecen:
- Ausencia en el corpus. La respuesta no está escrita en ningún documento indexado.
- Fallo de recuperación. La respuesta existe en el corpus, pero el fragmento que la contiene no llegó al contexto.
- Fallo de fidelidad. El fragmento correcto llegó al contexto y el modelo respondió otra cosa.
- Contexto contradictorio. Llegaron varios fragmentos con información incompatible y el sistema eligió mal, mezcló o promedió.
Las cuatro producen una respuesta incorrecta redactada con la misma seguridad. Distinguirlas a ojo, leyendo sólo la respuesta, es imposible. Distinguirlas con la traza es rutinario, y ese es todo el argumento a favor de instrumentar el sistema desde el primer día.
El procedimiento de diagnóstico
Ante un caso reportado, se ejecutan cuatro comprobaciones en este orden. El orden importa: cada una descarta una causa y sólo tiene sentido si la anterior salió negativa.
Paso 1. ¿Existe la respuesta en el corpus?
No lo preguntes al sistema: búscalo tú. Consulta el almacén de documentos por palabras clave, por identificador o por navegación directa, sin pasar por el pipeline de recuperación. Lo que buscas es un pasaje que responda a la pregunta.
Si no aparece, has terminado: es la causa 1. Este paso descarta más casos de los que la gente espera. Una fracción notable de los fallos que llegan como «el sistema alucina» son en realidad preguntas cuya respuesta nunca se documentó, o se documentó en un sitio que no está conectado al índice, o estaba en la tabla de un PDF que la ingesta convirtió en un amasijo ilegible.
Paso 2. ¿Llegó el fragmento al contexto?
Si el pasaje existe, mira la traza de esa consulta concreta: la lista de fragmentos recuperados con su puntuación. La pregunta es binaria: ¿está ahí el fragmento que contiene la respuesta?
Si no está, es la causa 2, y conviene afinar un poco más antes de actuar. Hay tres subcasos con remedios distintos:
- No estaba entre los candidatos iniciales. Fallo de la búsqueda de primera fase. Repite la búsqueda con un
kmucho mayor —doscientos, quinientos— y comprueba si aparece. Si aparece conkgrande, es un problema de ranking; si no aparece ni así, es un problema de representación: la pregunta y el fragmento no se parecen en el espacio de embeddings, o el fragmento quedó troceado de forma que perdió el contexto que lo hacía identificable. - Estaba entre los candidatos y el reranking lo bajó. Se ve en la traza comparando el orden antes y después. Es un problema de modelo de reranking o de un top-k final demasiado agresivo.
- Estaba, y lo eliminó un filtro. De permisos, de fecha, de tipo de documento. Es el subcaso más fácil de arreglar y el más fácil de pasar por alto si la traza no registra los filtros aplicados.
Paso 3. ¿Estaba en el contexto y aun así falló?
Si el fragmento correcto sí llegó, la recuperación hizo su trabajo y el problema está en la generación. Es la causa 3, el fallo de fidelidad. La comprobación limpia consiste en reconstruir el prompt exacto de la traza y volver a ejecutarlo, primero con el mismo modelo y luego con uno distinto.
Si el segundo modelo responde bien con el mismo contexto, el problema es de modelo o de temperatura. Si ambos fallan igual, el problema es del prompt: instrucciones ambiguas, fragmentos mal delimitados, orden que entierra el dato relevante en el medio del contexto —el efecto del que hablaba la entrega 06—, o un contexto tan largo que el dato se diluye.
Hay una variante de la causa 3 que merece nombre propio: el conocimiento paramétrico ganando al contexto. El modelo tiene una creencia previa fuerte sobre el tema y la impone sobre lo que dice el documento. Se reconoce porque la respuesta errónea es la respuesta «genérica correcta» del mundo, y el documento decía otra cosa por ser un caso particular. Aparece mucho con políticas internas que se desvían del estándar del sector.
Paso 4. ¿Se contradecían los fragmentos?
Si el contexto contenía el fragmento correcto y además otros que decían algo incompatible, estás en la causa 4, y no es un fallo del modelo: es un fallo del corpus que se manifiesta en la generación. Dos versiones de la misma política, un documento derogado que sigue indexado, la misma tarifa en dos monedas sin decirlo, un borrador y su versión final conviviendo.
La comprobación es leer los fragmentos recuperados en bruto y preguntarse si un humano competente habría podido responder bien con ese material. Si la respuesta es no, el modelo no tenía nada que hacer.
Tabla de diagnóstico
| Síntoma | Causa probable | Comprobación | Remedio |
|---|---|---|---|
| Responde algo plausible y genérico, sin citas útiles | 1. No está en el corpus | Búsqueda manual en el almacén de documentos | Documentar el hueco o conectar la fuente que falta; reforzar la instrucción de abstención |
| Cita fragmentos del tema pero no el que responde | 2. Fallo de recuperación | Traza: ¿está el fragmento? Repetir con k grande | Búsqueda híbrida, revisar el troceado, reranking, ajustar filtros |
| La cita es correcta pero la afirmación no se deduce de ella | 3. Fallo de fidelidad | Reejecutar el prompt exacto, y con otro modelo | Prompt más estricto, menos fragmentos, temperatura baja, otro generador |
| Responde la versión antigua de una política vigente | 4. Contexto contradictorio | Leer los fragmentos recuperados en bruto | Deduplicar, versionar, retirar lo derogado, priorizar por fecha en el ranking |
| Mezcla dos casos parecidos en una sola respuesta | 4 con 3 | Comprobar si los fragmentos son de documentos distintos | Metadatos que identifiquen el caso, instrucción de no fusionar fuentes |
| Inventa un número o una fecha que no aparece en ningún fragmento | 3, variante paramétrica | Buscar el valor literal en el contexto enviado | Exigir cita textual para datos numéricos; verificación posterior de cifras |
Los remedios, uno a uno
Contra la causa 1 no hay solución técnica dentro del sistema: si el dato no está, no está. Lo único que se puede —y se debe— hacer es que el sistema lo diga. Una instrucción explícita de abstención, un umbral de puntuación mínima por debajo del cual no se llama siquiera al generador, y un registro de esas preguntas para alimentar al equipo que escribe la documentación. La entrega 46 vuelve sobre esto: las preguntas sin respuesta útil son la señal más valiosa que produce un RAG.
Contra la causa 2 está casi toda la caja de herramientas de los bloques tercero y cuarto: búsqueda híbrida cuando el fallo son códigos, referencias o nombres propios; revisión del troceado cuando el fragmento perdió su contexto; reranking cuando el candidato correcto estaba pero mal ordenado; transformación de la consulta cuando la pregunta del usuario no se parece léxica ni semánticamente al texto que la responde.
Contra la causa 3, el orden de intervención es prompt, luego parámetros, luego modelo. Delimitar los fragmentos con marcas claras, numerarlos, exigir que cada afirmación indique de qué fragmento sale, prohibir explícitamente el conocimiento externo, bajar la temperatura y reducir el número de fragmentos suele resolver la mayoría. Si no basta, hay modelos que siguen instrucciones de fidelidad mejor que otros, y ese criterio pesa más en un RAG que cualquier puntuación general de capacidad.
Contra la causa 4, el trabajo es de corpus, no de pipeline: deduplicación, política de versiones, retirada de lo derogado y metadatos de vigencia que el ranking pueda usar para desempatar. Es el remedio más lento y el que más veces se sustituye por parches en el prompt que no funcionan.
Lo que este procedimiento no arregla
Ninguna de estas medidas elimina las alucinaciones. Reducen su frecuencia y, sobre todo, cambian su naturaleza: pasan de ser fallos opacos a ser fallos con causa identificable y remedio conocido. Eso es una mejora enorme en operación y una promesa que no se puede convertir en «el sistema no se equivoca».
Hay además un sesgo de medición que conviene tener presente: los cuatro pasos sólo se pueden ejecutar sobre casos que alguien ha reportado. Los errores que nadie detecta no entran nunca en el procedimiento, y son precisamente los más peligrosos, porque suelen ser los más plausibles. Por eso el diagnóstico reactivo tiene que convivir con evaluación sistemática sobre el golden dataset y con muestreo aleatorio de respuestas reales revisadas por una persona.
Qué viene ahora
Hasta aquí hemos supuesto que el corpus es de fiar, aunque esté incompleto o desordenado. La siguiente entrega quita esa suposición: qué ocurre cuando alguien puede escribir deliberadamente en tus fuentes: inyección de instrucciones a través de un documento recuperado, envenenamiento del índice y exfiltración de datos mediante la propia respuesta. Cambia el modelo de amenaza por completo.
Los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).
Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.