Hallucination detection

When a request supplies the passages the model was meant to answer from, CID222 scores the reply against them and records whether it was supported. The check runs after the reply reaches the user.

The problem

A retrieval-augmented application hands the model source passages and asks it to answer from them. The model sometimes answers from something else. Nothing in the request or the reply says which happened, and the reader — who asked the question precisely because they did not know the answer — is the last person able to tell.

How CID222 does it

What is scored, and only then

The check is Tier 2: it runs in the background after the response has already been streamed to the client. It never delays the reply and never changes it.

It runs only when the request carries a contexts array — the passages the answer was supposed to use. Without contexts there is nothing to score against, and the check returns immediately without writing anything.

cid-hallucination-guard compares the answer with the contexts and returns two numbers: a hallucination score, which is the model's probability that the answer is unsupported, and a supported ratio, which is the complementary probability that it is grounded.

The decision is the gateway's

The service does not decide. The gateway compares its two numbers against the tenant's Hallucination output-filter row: the reply is treated as hallucinated when the score exceeds that row's threshold, or when the supported ratio falls below its minimum. Three rows ship seeded, scoped by context type, so a medical or legal question can be held to a stricter bar than a general one.

What the user and the administrator see

Two languages, one routing rule

The service holds an English model and a Turkish one, both baked into the image; nothing is downloaded at runtime. Routing is by the lang field the caller sends.

Limits and known gaps

• It cannot block. The seeded strict row carries a reject action, and the code maps that action onto a detection status of rejected — but the reply left the gateway before the check ran. Nothing is withheld. Read reject here as "record this as a rejection-grade finding", not as an enforcement.
• No contexts, no check. An ordinary chat request supplies none, so the overwhelming majority of traffic is never scored. This is a check for retrieval-augmented callers, not a general fact-checker.
• The score is not calibrated. The two checkpoints are token-classification models loaded as sequence classifiers, so the supported ratio is a pooled probability rather than the fraction of the answer the name suggests. It separates obvious fabrication from obvious paraphrase; it is not a measurement.
• Long answers are scored on their opening. Inputs are truncated to 512 tokens, so a long answer against a long context is judged on its beginning.
• Unavailable is not grounded. When the model fails to load or the call fails, the service returns a fail-open result and flags it. The gateway detects that state and writes nothing — a clean row would claim the response was checked. An absent detection therefore means either "grounded" or "not checked", and only the flags distinguish them.
• The session warning has no dashboard view. It is written to the session record and readable through the sessions API; no page renders it. The detection row is where an administrator sees the finding.
• A background detection needs a session. The check attributes its detection to a session id, so a caller that supplies none gets no record.

Related

• The content safety pipeline — the response-side tiers and how output rules resolve.
• Toxicity and attack detection — the request-side detectors.
• Data handling and retention — what the detection row and the session warning keep.