Cada pocas semanas aparece un paper que hace alucinar menos a un modelo, y con él una pequeña esperanza de que este sea el que por fin lo resuelve. El último que leímos es un buen ejemplo: VisAlign, que reduce las alucinaciones de objetos en modelos de visión-lenguaje (la familia LLaVA / Qwen2-VL) refinando los embeddings textuales del decoder con aprendizaje contrastivo. Es ligero, no exige reentrenar de cero y en los benchmarks funciona.
También es, por honestidad de los propios autores, acotado: ataca alucinaciones de objetos en modelos de imagen, y advierten que generalizar a otros dominios está por validar. Eso no es una crítica. Es justo el punto de esta nota: incluso una mitigación buena de verdad da un número más pequeño, nunca un cero. Y entre «más pequeño» y «cero» está el terreno donde se gana o se pierde la confiabilidad en producción.
La trampa: confundir una mitigación con una solución
El modo de fallo no está en el paper. Está en el equipo que lee «reduce alucinaciones» y le vende al cliente un «usamos la última técnica anti-alucinación» como si fuera una garantía. Tres cosas rompen esa promesa:
- La tasa nunca es cero. Cada mitigación baja la probabilidad; ninguna la elimina. Un sistema que alucina el 2 % de las veces en lugar del 8 % es mejor, y aun así se va a inventar algo con total aplomo delante de un usuario real, en un momento que no puedes predecir.
- Depende del dominio. Una técnica afinada sobre una distribución —aquí, alucinaciones de objetos anotadas— puede no sostenerse sobre la tuya. El benchmark no es tu tráfico.
- Deriva. Una mitigación que funcionaba el día del lanzamiento se degrada a medida que cambian los inputs, se actualizan los modelos y el sistema se adapta de formas que rompen las suposiciones de ayer.
Así que la pregunta nunca es «¿arreglamos la alucinación?». Es «¿qué hace nuestro sistema cuando alucine?», porque va a alucinar.
La alucinación es una disciplina operativa, no un bug que cierras
Es la misma postura que mantenemos con todo: el modelo es un componente, y la confiabilidad vive en el sistema que lo rodea. Cuatro movimientos, y ninguno es una técnica que se compre una vez:
- Mídela con tus datos. Tu eval tiene que puntuar el grounding y la tasa de alucinación sobre tus preguntas reales, no sobre un benchmark público. Y en sistemas de recuperación, demuestra que la respuesta está siquiera en el corpus antes de culpar al modelo.
- Ponle un gate. Un umbral de alucinación forma parte del listón que un cambio tiene que superar para salir. Sin eval en verde no hay merge. Así decides también si una mitigación como VisAlign se gana su sitio: entra si mueve tu número, no por ser nueva.
- Vigílala en producción. Detecta la deriva en los traces, no en la queja de un cliente. Un juez continuo sobre el trace en vivo convierte «esto empeoró» en una métrica que se mueve, en vez de un incidente.
- Contén el radio de daño. Como la tasa no es cero, todo lo irreversible va detrás de un verificador o un checkpoint humano. Una respuesta convincente y equivocada que solo se muestra es un bug; una que envía, paga o borra es un incidente. El límite de permisos es lo que impide que una alucinación acabe en titular.
Aplica la mejor mitigación que encuentres —en serio, VisAlign y sus sucesores valen la pena donde encajan. Y después construye como si el modelo fuera a alucinar igualmente, porque lo hará.
Investigación como esta es progreso de verdad, y nos quedamos con cada punto de reducción que haya en el mostrador. Pero «hicimos el número más pequeño» es un resultado del modelo. «El sistema sigue siendo seguro cuando el número no es cero» es un resultado de ingeniería —mídela, ponle gate, vigílala y acota lo que puede romper— y es el único que tus usuarios notan. Esa es la diferencia entre entregar slop y entregar algo en lo que la gente puede confiar.