La alucinación no es un bug que se corregirá en la próxima versión — es una consecuencia estructural de cómo funcionan los modelos de lenguaje. Un modelo genera texto prediciendo el token más probable siguiente dado todo lo que vino antes. No tiene una base de datos interna de hechos, ninguna forma de verificar afirmaciones contra la realidad y ningún concepto de verdad versus falsedad. Cuando produce una declaración que suena plausible pero es falsa, está haciendo exactamente lo que fue entrenado para hacer: generar texto fluido y contextualmente apropiado. El problema es que “contextualmente apropiado” y “factualmente correcto” no son lo mismo, y el modelo no tiene un mecanismo para distinguir entre ambos.
Las alucinaciones más peligrosas son las sutiles. Un modelo que inventa una persona completamente ficticia es fácil de atrapar. Un modelo que atribuye una cita real a la persona equivocada, cita un paper real con el año equivocado o genera un endpoint de API que parece plausible pero no existe — esos son más difíciles. Los desarrolladores lo han aprendido por las malas. Hay casos conocidos de abogados que presentaron escritos legales generados por IA con citas de casos fabricadas que se veían perfectamente formateadas pero referenciaban casos que nunca existieron. Las alucinaciones de código son igual de comunes: un modelo puede sugerir importar una función de librería que fue renombrada tres versiones atrás, o referenciar una firma de método que casi-pero-no-del-todo coincide con la real.
Varios factores hacen que la alucinación sea más o menos probable. Configuraciones de temperature más altas aumentan la aleatoriedad, lo que puede incrementar las tasas de alucinación en preguntas factuales. Preguntar sobre temas oscuros que aparecieron infrecuentemente en los datos de entrenamiento produce más alucinaciones que preguntar sobre temas bien cubiertos. Las salidas más largas y complejas tienen más oportunidades de que las cosas salgan mal. Y los modelos son particularmente propensos a alucinar cuando están bajo presión de producir una respuesta — si haces una pregunta y el modelo no sabe, su entrenamiento lo sesga hacia generar una respuesta que suene confiada en lugar de decir “no estoy seguro”. Por eso darle explícitamente permiso al modelo para decir “no sé” reduce mediblemente las tasas de alucinación.
La industria ha desarrollado una estrategia de defensa en capas. El grounding y RAG proporcionan fuentes externas que el modelo puede referenciar en lugar de depender de la memoria paramétrica. Configuraciones de temperature más bajas reducen la aleatoriedad para tareas factuales. Los system prompts pueden instruir al modelo a citar fuentes y marcar incertidumbre. Las verificaciones post-generación — pasar la salida por un segundo modelo o un pipeline de verificación de hechos — atrapan algunos errores antes de que lleguen a los usuarios. Anthropic, OpenAI y Google han invertido fuertemente en entrenar modelos para que estén mejor calibrados sobre su propia incertidumbre, de modo que sea más probable que maticen o declinen en lugar de confabular. Pero ninguna de estas defensas es perfecta, y tratar cualquier respuesta de IA como verdad absoluta sin verificación sigue siendo riesgoso para cualquier cosa que tenga consecuencias.
Una confusión que vale la pena abordar: las tasas de alucinación han mejorado dramáticamente entre generaciones de modelos, y algunas personas extrapolan esto para concluir que el problema se “resolverá” pronto. Probablemente no será así, al menos no completamente, porque la arquitectura misma no tiene un mecanismo de verificación de verdad. Lo que está mejorando es la calibración — los modelos modernos alucinan menos frecuentemente y son mejores expresando incertidumbre. Pero “menos frecuentemente” no es “nunca”, y en dominios de alto riesgo como medicina, derecho o finanzas, incluso un 1% de tasa de alucinación en afirmaciones factuales es inaceptable sin verificación humana. La conclusión práctica es diseñar tus sistemas asumiendo que el modelo se equivocará ocasionalmente, y construir verificación en tu flujo de trabajo en lugar de esperar que la próxima actualización del modelo la haga innecesaria.