Una alucinación es una afirmación generada con apariencia de respuesta válida pero sin
respaldo suficiente. No es un modo de error separado: surge del mismo mecanismo que hace útil
al LLM. El modelo continúa con texto probable; no consulta la verdad
antes de escribir cada token.
Formas comunes
inventar un hecho, fecha, API o parámetro;
atribuir una afirmación a una fuente que no la contiene;
completar un hueco del contexto sin declarar incertidumbre;
producir código que compila «en apariencia» pero usa una interfaz inexistente;
mezclar información correcta con una conclusión no sustentada.
También puede equivocarse sin alucinar: interpretar mal una instrucción, perder un detalle en
un contexto largo o aplicar una regla de forma inconsistente. «Alucinación» no debe convertirse
en nombre genérico de cualquier fallo.
Qué aumenta el riesgo
preguntas fuera de los datos de entrenamiento o posteriores a su corte;
contexto ambiguo, contradictorio o insuficiente;
exigir una respuesta aunque no haya evidencia;
documentos largos donde la fuente relevante queda enterrada;
tareas con entidades, cifras o APIs muy específicas;
cadenas agentic donde un error temprano alimenta los pasos siguientes.
Mitigación por capas
Fuente: recupera información actual y autorizada con
RAG o herramientas.
Validación: comprueba esquema, rangos, IDs y reglas de negocio fuera del modelo.
Grounding: exige que cada afirmación importante apunte al fragmento que la respalda.
Verificación: ejecuta código, consulta el sistema de registro o pide revisión humana.
Evaluación: mide errores con casos reales y vuelve a ejecutar la suite al cambiar de
modelo, prompt o retrieval.
[!WARNING]
Un prompt que diga «no alucines» no crea una garantía. Tampoco temperatura cero convierte al
modelo en fuente de verdad.
Cuándo no delegar la decisión
Si una respuesta puede autorizar dinero, acceso, diagnóstico, contrato o una operación
irreversible, el modelo puede asistir, pero la decisión necesita una regla verificable y el
nivel de supervisión adecuado.