Every few weeks a paper lands that makes a model hallucinate less, and a little hope goes around that this is the one that finally fixes it. The latest we read is a good example — VisAlign, which reduces object hallucinations in vision-language models (the LLaVA / Qwen2-VL family) by refining the textual embeddings in the decoder with contrastive learning. It's lightweight, it doesn't require a full retrain, and on the benchmarks it works.
It is also, by the authors' own honesty, narrow — it targets object-level hallucinations in image models, and they flag that generalization to new domains needs validation. That's not a knock. It's the whole point of this post: even a genuinely good mitigation is a smaller number, not a zero. And the gap between "smaller" and "zero" is where production reliability is actually won or lost.
The trap: treating a mitigation as a fix
The failure mode isn't the paper. It's the team that reads "reduces hallucinations" and ships "we use the latest anti-hallucination technique" as a reliability guarantee to a customer. Three things break that promise:
- The rate is never zero. Every mitigation lowers the probability; none removes it. A system that hallucinates 2% of the time instead of 8% is better — and will still confidently invent something in front of a real user, on a schedule you can't predict.
- It's domain-specific. A technique tuned on one distribution (here, annotated object hallucinations) may not hold on yours. The benchmark is not your traffic.
- It drifts. A mitigation that worked at launch degrades as inputs shift, models update, and the system adapts in ways that break yesterday's assumptions.
So the question is never "did we fix hallucination." It's "what does our system do when it hallucinates" — because it will.
Hallucination is an operating discipline, not a bug you close
This is the same stance we take on everything: the model is one component, and the reliability lives in the system around it. Four moves, none of them a technique you buy once:
- Measure it on your data. Your eval has to score grounding and hallucination rate on your real questions, not a public benchmark — and for retrieval systems, prove the answer is even in the corpus before you blame the model.
- Gate on it. A hallucination threshold is part of the bar a change has to clear to ship. No green eval, no merge — and that's also how you decide whether a mitigation like VisAlign actually earns its place: it ships if it moves your number, not because it's new.
- Observe it in production. Catch the drift in traces, not in a customer complaint. A continuous judge on the live trace turns "it got worse" into a metric moving instead of an incident.
- Contain the blast radius. Because the rate is non-zero, anything irreversible sits behind a verifier or a human checkpoint. A confident wrong answer that only displays is a bug; one that sends, pays, or deletes is an incident. The permission boundary is what keeps a hallucination from becoming a headline.
Apply the best mitigation you can find — genuinely, VisAlign and its successors are worth adopting where they fit. Then build as if the model will still hallucinate, because it will.
Research like this is real progress, and we'll take every point of hallucination reduction on offer. But "we made the number smaller" is a model result. "The system stays safe when the number isn't zero" is an engineering result — measure it, gate on it, watch it, and box in what it can break — and it's the only one your users feel. That's the difference between shipping slop and shipping something people can trust.