Hallucinations in production: detection and mitigation

A hallucination is a confident, wrong output. You will not eliminate them from a generative feature, so the useful question is not “how do we stop all of them” but “how do we notice one before the user does, and what happens when one gets through.” Framed that way, it becomes an engineering problem you can actually work.

Detection is anomaly detection

A technical product manager at an elder-care technology company gave me the cleanest mental model for this. Her product learns a baseline of a person’s normal daily behavior, a “daily print,” from motion sensors, then watches for deviations. When the pattern breaks in a way that matters, it raises an alert to a caregiver. The system is not trying to be certain about any single reading. It is watching for the reading that does not fit what it already knows.

That is the right way to think about hallucination detection. You establish what a grounded, sensible output looks like for your feature, and you flag the ones that fall outside it. She was also honest about the cost of getting the threshold wrong. It is a delicate balance between too many alerts and missing something important. Set the bar too sensitive and caregivers drown in false alarms and stop trusting the system. Set it too loose and you miss the fall. Detection without a tuned threshold just moves the problem.

There is a cheap and effective probe here. Because these models are non-deterministic, you can run the same prompt several times at a higher temperature and watch whether the answers diverge. Stable answers are a good sign. Wildly different answers on the same input are a strong hallucination signal, and you can flag those automatically before anything reaches a user.

Mitigation is early warning plus containment

The CEO of a grid-reliability company described the mitigation half without ever using the word AI. His product is, in his words, an EKG for electronics. It watches the electrical signal for the tiny wiggles that are the telltale signs something is starting to go wrong, long before a human would smell or hear a failure. By then, he noted, it is too late. So the system accumulates the evidence of stress and raises a flag while there is still time to act.

Two ideas from that transfer directly. First, catch the signal early, at the level of a suspicious pattern, not at the level of a customer complaint. Second, the flag exists to trigger a human intervention while there is still room to correct course. He put a number on why this matters in his world: inverter failures were 59% of all unexpected maintenance cost in a solar plant. The whole business case was catching the bad state before it became an expensive event.

The layers that actually help

No single check catches every hallucination. The teams that keep them away from users stack a few:

A groundedness check that verifies the output is supported by the source or retrieved context.
A self-consistency probe that samples the same input several times and flags divergence.
Deterministic rules for the things you can state as hard constraints, like format or forbidden claims.
A human review step on the highest-stakes outputs, with a clear path to intervene.

How we approach it at Density Labs

In the AI Readiness Assessment, our $2,500 front door, we treat hallucination handling as a detection design, not a hope. We help you define what a grounded output looks like, set an alert threshold you can defend, and decide what happens when a suspicious output is flagged, who sees it and how fast. It is the same discipline the monitoring people have used for decades, pointed at model outputs.

You will not stop every wrong answer. You can make sure a person, not a customer, is the one who catches it.