Definición
Una hallucination (alucinación, también confabulación) es la generación por parte de un LLM de información que suena coherente, gramaticalmente correcta y plausible pero que es factualmente falsa o inventada. El modelo no miente con intención: simplemente produce texto que se ajusta al patrón de "lo que sonaría como respuesta razonable" sin tener mecanismo intrínseco de verificación.
Es el problema fundamental más conocido y persistente de los LLMs modernos. Mientras existan, ningún sistema crítico debería confiar ciegamente en respuestas de LLM sin algún tipo de verificación o grounding.
Ejemplos típicos:
- Citar un paper o autor que no existe, con título plausible y autoría creíble.
- Dar una fecha histórica errónea con total seguridad.
- Inventar una función de librería que no está en la API real.
- Atribuir citas falsas a personajes reales.
- Confundir hechos de personas distintas con nombres parecidos.
Lo peligroso: las alucinaciones son indistinguibles del contenido correcto solo leyendo. Requieren verificación externa.
Por qué ocurren
A nivel técnico, los LLMs alucinan porque:
-
El objetivo de entrenamiento es predicción de tokens, no veracidad: durante pretraining, el modelo aprende a predecir el siguiente token según la distribución estadística del texto. No hay mecanismo que distinga "esto es verdad" de "esto suena bien".
-
Compresión lossy del conocimiento: el modelo "comprime" trillones de tokens de entrenamiento en miles de millones de parámetros. Inevitable que pierda detalles, especialmente de hechos raros o específicos.
-
Generación sin verificación: el modelo genera token a token, condicionado en el contexto. Si la cadena empieza a desviarse de la verdad, no hay mecanismo de auto-corrección integrado.
-
Sesgo de confianza: el alineamiento por RLHF tiende a entrenar al modelo a sonar seguro y útil. Decir "no lo sé" recibe menos refuerzo que dar una respuesta plausible — aunque sea inventada.
-
Patrones aprendidos sobre hechos olvidados: si en entrenamiento el modelo vio "X escribió un libro sobre Y", pero no recuerda el título exacto, puede generar uno plausible que encaje con el patrón sin que sea real.
Tipos de alucinaciones
- Factuales: hechos verificables que son falsos (fechas, autores, números, datos).
- De fuentes: citar papers, artículos o URLs que no existen.
- De código: inventar funciones, APIs o métodos que no están en la librería real.
- De razonamiento: cadena lógica internamente coherente pero con premisas falsas.
- Contextuales: contradecir información que está en el propio contexto del prompt.
- De omisión: callar información relevante que sí tiene.
Las dos primeras son las más peligrosas porque son las más difíciles de detectar sin verificación.
Ejemplo práctico
Pregunta a un LLM sobre IMDICA (que es real pero pequeña, posiblemente fuera de su conocimiento detallado):
"¿Cuántos empleados tiene IMDICA y quién es su CEO?"
Respuestas posibles:
- LLM honesto y calibrado: "No tengo información específica sobre IMDICA. Te recomiendo consultar su web oficial o LinkedIn."
- LLM alucinador: "IMDICA es una empresa española fundada en 1985 con sede en Madrid, especializada en logística farmacéutica, con unos 320 empleados y dirigida por Manuel García-Hernández desde 2019."
La segunda respuesta es factualmente falsa pero perfectamente plausible. Un usuario sin contexto la creería. Esto es alucinación.
En producción, esto puede tener consecuencias graves: respuestas legales erróneas, código con APIs inexistentes que rompe en producción, decisiones de negocio basadas en datos inventados.
Cómo mitigar alucinaciones
No se eliminan completamente con la tecnología actual, pero hay técnicas que las reducen significativamente:
-
RAG: dar al modelo el contexto factual relevante en el prompt. El modelo cita lo que está ahí en lugar de inventarlo. La técnica con mejor ROI por mucho.
-
Grounding con fuentes verificables: pedir al modelo que cite páginas/párrafos específicos de las fuentes provistas. Permite verificación.
-
Temperature baja (0 o cerca): reduce creatividad, también reduce invención. Para tareas factuales, T=0.
-
Prompting cuidado: explícito "si no estás seguro o no tienes la información, responde 'no lo sé'". Funciona moderadamente.
-
Verificación posterior: pasar la respuesta por otro modelo o por un sistema de fact-checking que compare contra fuentes. Hay arquitecturas de "modelo principal + verificador".
-
Cadenas de razonamiento explícitas (CoT): pedir razonamiento paso a paso a veces revela inconsistencias antes de la respuesta final.
-
Modelos de razonamiento (reasoning models): tienden a alucinar menos en tareas verificables porque pueden "darse cuenta" durante el razonamiento.
-
Function calling con APIs reales: en lugar de pedir al modelo que recuerde datos, hacer que llame a una API que devuelve datos verificados.
-
Fine-tuning con datos curados: ajustar el modelo con ejemplos que premien "no lo sé" cuando aplica.
-
Constitutional AI / autocrítica: el modelo se autocritica antes de responder, detectando alucinaciones probables.
Alucinaciones en reasoning models
Los modelos de razonamiento (o1, R1, Claude Extended Thinking) alucinan menos que LLMs clásicos en tareas verificables (matemáticas, código), porque su entrenamiento RL las premia por respuestas correctas verificables.
Pero no las eliminan:
- En dominios donde no hay verificación objetiva (historia, biografías, opinión), siguen alucinando.
- A veces la cadena de razonamiento misma puede ser inventada (post-hoc rationalization).
- Pueden ser MÁS peligrosas en cierto sentido: respuestas inventadas con razonamiento largo y aparentemente sólido convencen más al usuario.
El estado de la cuestión a 2026
Hay progreso medible. Benchmarks como TruthfulQA, FreshQA, SimpleQA muestran que los modelos top alucinan 3-5× menos que las versiones de 2023. Pero el problema sigue.
Las direcciones de investigación activas:
- Mejor calibración: modelos que saben "cuándo no saben".
- Grounding nativo: arquitecturas con acceso a fuentes externas integrado.
- Reasoning + verification: bucles internos de razonamiento + verificación.
- Sparse retrieval embedido: vector DBs como parte del modelo.
- World models: modelos con representaciones más estructuradas del mundo.
No hay solución mágica todavía. Mientras tanto: diseña tus sistemas asumiendo que las alucinaciones existirán.
Errores comunes al hablar de alucinaciones
- Pensar que "los modelos top no alucinan": alucinan menos, pero alucinan. Incluso GPT-5 y Claude Opus pueden inventar referencias.
- Confundir alucinación con error de razonamiento: error de razonamiento es fallo en cómputo. Alucinación es inventarse hechos.
- Asumir que RAG las elimina: las reduce mucho, pero el modelo puede ignorar el contexto provisto y aún así inventar.
- Subestimar el coste reputacional: una alucinación en un dominio crítico (médico, legal, financiero) puede tener consecuencias graves.
- Esperar que el usuario detecte alucinaciones: la mayoría confía en respuestas autoritativas. El diseño de producto debe asumir que el usuario NO verifica.
- Pensar que "más prompting lo arregla": ayuda algo, pero no elimina el fenómeno fundamental.
Cuándo es vital mitigar alucinaciones
Sí, prioriza mitigación cuando:
- Tu producto se usa en dominios verificables y con consecuencias reales (medicina, legal, finanzas, ingeniería).
- Los usuarios toman decisiones basadas en las respuestas del modelo.
- La reputación de tu marca depende de la precisión.
- Estás regulado y debes auditar respuestas.
Es menos crítico (pero nunca ignorable) si:
- Tu uso es exploratorio, creativo, o asistente personal con verificación implícita del usuario.
- Estás en prototipado o demostración.
Referencias
- Ji et al. · Survey of Hallucination in Natural Language Generation — survey clásico del fenómeno
- Lin et al. · TruthfulQA: Measuring How Models Mimic Human Falsehoods — benchmark estándar para medir veracidad
- OpenAI · SimpleQA benchmark — evaluación factual moderna que mide alucinaciones de modelos frontera