Hallucination detection
in/guard/out vs Patronus Lynx
Lynx is a respected open-weights hallucination detector – a Llama-3 fine-tune in 8B and 70B variants that scores RAG faithfulness better than much larger judges. It is also, deliberately, just the model: you host it, wire it into your request path, decide what a score means, and build everything around it. in/guard/out is that everything – with a cheaper first tier and a stronger verb than “detected”.
Side by side
| Capability | Patronus Lynx | in/guard/out |
|---|---|---|
| What it is | An open-weights detector model (8B/70B) | A drop-in enforcement pipeline – detection is one stage of it |
| First line of defense | A GPU inference pass per check | Deterministic, zero-token checks: arithmetic recomputed, number drift, quote gates – before any model runs |
| On detection | A faithfulness verdict | Repair, block, or flag per policy – the drifted number is corrected, not just reported |
| Scope | RAG faithfulness | Numeric grounding, claim audit, format, PII restore, content safety, injection, agent actions and budgets |
| Integration | Host the model, build the pipeline, define thresholds | Change a base URL; policy per key, user, or request |
| Cost of a check | GPU serving per call | The deterministic tier is free; opt-in model tiers cost real tokens and latency – measured per stage, priced into the request |
| Agent traffic | — | Tool policy, action grounding, taint, loop detection, per-run hard budgets |
| Audit output | Scores | Per-stage timeline + the run graph of enforced decisions |
A detector is a component. Use it as one.
The honest relationship: Lynx-class models and in/guard/out are not rivals – they’re different layers. in/guard/out’s guard and judge models are swappable, and a dedicated faithfulness detector is exactly the kind of escalation tier the pipeline is designed to call after the free deterministic checks have had their pass. What the model alone can’t give you is the system: repair semantics, policy modes, PII round-tripping, agent enforcement, and one audit trail.
Frequently asked questions
Lynx beats GPT-class judges on HaluBench – why not just use it?
Use it – as a stage, not a strategy. A detector gives you a verdict; production needs a decision and often a fix. in/guard/out runs free deterministic checks always, lets you opt into model-based checks where they earn their latency, and turns the verdict into repair, block, or flag under your policy – with the evidence and the cost logged per request.
Can in/guard/out use Lynx as its judge?
The judge tier is configurable – any OpenAI-compatible endpoint can serve it, including a self-hosted detector. The pipeline doesn’t care whose model scores the claim; it cares what happens next.
What about hallucinations that aren’t RAG faithfulness?
Most production incidents aren’t: a botched sum, a drifted figure, a promised action that never ran. Those are caught by deterministic grounding and claim audit – no reference documents required, no detector model in the loop.
See it on your traffic first.
FIX mode observes without blocking, so you can measure what in/guard/out catches before enforcing anything. We are running a limited demo - sign up and we will get you in as soon as we can.