Cada pocas semanas aterriza un paper que hace que un modelo alucine menos, y circula una pequeña esperanza de que este es el que por fin lo arregla. 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 liviano, no requiere un reentrenamiento completo, y en los benchmarks funciona.
También es, por la propia honestidad de los autores, acotado — apunta a alucinaciones a nivel de objeto en modelos de imagen, y señalan que la generalización a nuevos dominios necesita validación. Eso no es una crítica. Es justamente el punto de esta nota: incluso una mitigación genuinamente buena es un número más chico, no un cero. Y la brecha entre "más chico" y "cero" es donde la confiabilidad de producción de verdad se gana o se pierde.
La trampa: tratar una mitigación como un arreglo
El modo de fallo no es el paper. Es el equipo que lee "reduce alucinaciones" y le entrega a un cliente "usamos la última técnica anti-alucinación" como garantía de confiabilidad. 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í inventará algo con confianza frente a un usuario real, en un momento que no puedes predecir.
- Es específica del dominio. Una técnica ajustada 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 funcionó al lanzamiento se degrada a medida que los inputs cambian, los modelos se actualizan, 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 alucina?" — porque lo hará.
La alucinación es una disciplina de operación, no un bug que cierras
Esta es la misma postura que tomamos con todo: el modelo es un componente, y la confiabilidad vive en el sistema a su alrededor. Cuatro movimientos, ninguno una técnica que compras una vez:
- Mídela sobre tus datos. Tu evaluación tiene que puntuar la fundamentación y la tasa de alucinación sobre tus preguntas reales, no sobre un benchmark público — y para sistemas de recuperación, prueba que la respuesta siquiera está en el corpus antes de culpar al modelo.
- Pon una compuerta. Un umbral de alucinación es parte de la barra que un cambio tiene que pasar para lanzarse. Sin evaluación en verde, no hay merge — y así también decides si una mitigación como VisAlign de verdad se gana su lugar: se lanza si mueve tu número, no porque sea nueva.
- Obsérvala en producción. Atrapa la deriva en los traces, no en una queja de un cliente. Un juez continuo sobre el trace en vivo convierte "empeoró" en una métrica moviéndose en lugar de un incidente.
- Contén el radio de daño. Como la tasa no es cero, cualquier cosa irreversible va detrás de un verificador o un checkpoint humano. Una respuesta segura y equivocada que solo muestra es un bug; una que envía, paga o borra es un incidente. El límite de permisos es lo que evita que una alucinación se convierta en un titular.
Aplica la mejor mitigación que encuentres — en serio, VisAlign y sus sucesores valen la pena donde encajan. Después construye como si el modelo igual fuera a alucinar, porque lo hará.
Investigación como esta es progreso real, y tomaremos cada punto de reducción de alucinación que haya en oferta. Pero "hicimos el número más chico" 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 compuerta, vigílala y acota lo que puede romper— y es el único que tus usuarios sienten. Esa es la diferencia entre entregar slop y entregar algo en lo que la gente puede confiar.