VicroCode
Make Code Create Value
VicroCode is a lightweight online platform for publishing, running, sharing, and monetizing code projects. Launch HTML, Python, SQLite, AI agents, management tools, games, and more without server setup.
Please wait while VicroCode loads. You can also explore the AI programming guide
Loading...

AI MARKET GUIDE

The Relay Problem: A Groundedness Checker That Stops Your Assistant From Faking Certainty

An Opus 5.5 user caught the model stating guesses as facts. Here's a narrow Python endpoint that checks a summary against real source spans instead of judging truth.

There's a V2EX thread that stuck with me because the model confessed better than any bug report could. An Opus 5.5 user kept getting answers stated with full confidence that turned out to be made up. When pressed, the model explained itself: it had organized its reply from a compressed impression without going back to check against the documents, and in one case a person's offhand verbal reply happened to fit the data, so it just ran with that and filled in the rest as if confirmed. The user's complaint was sharper than usual — GPT felt defensive and airtight, Opus felt flexible and would casually blurt out something it assumed was true, and this was an official subscription, not some watered-down reseller.

That confession is the whole problem in one paragraph. The model isn't lying on purpose. It's doing what a fluent paraphraser does: it holds a squishy summary in its head and reconstructs details on demand, and somewhere in that reconstruction an inferred value gets promoted to a stated fact. The failure doesn't happen at the thinking step. It happens at the relay step — when the model restates what a source said.

Why a truth gate is the wrong tool

The tempting fix is a big one: build an evidence gate that decides whether each claim is actually true. Don't. Adjudicating truth means you now own a second hard problem (what's true in the world) on top of the first one. You'd be building a thing that's wrong in new and more confident ways.

The narrower, more honest target is relay fidelity. Not "is this claim true," but "did this claim come from the source text the model was given, or did the model invent it in transit?

That's a question you can actually answer, because you have both sides: the model's paraphrase, and the real source it was supposed to be paraphrasing. You're not grading reality. You're checking whether the summary is backed by a span that genuinely exists in the source, or whether it's a confabulation at the relay.

This distinction matters more as people lean harder on these tools. Another thread in the same batch put it bluntly: most engineers aren't becoming ten-times developers, they're using AI to get tasks done with less effort — to fudge their way through. If people are fudging, the one thing you cannot afford is a relay layer that quietly fudges along with them and dresses guesses up as checked facts.

What the checker actually does

The shape is simple. You take two inputs — the model's summary or paraphrase, and the source text it claims to be based on. You split the summary into individual claims. For each claim, you look for a matching span in the source. If you find one, you return the span as evidence. If you don't, you flag it: no matching source. The output isn't a verdict of true or false. It's a map that says, for every sentence the model handed you, here's the receipt, or here's the admission that there is no receipt.

I'd build this as a hosted Python service. The source material lives in a LanceDB knowledge base as chunked passages with embeddings, so a claim can be matched against spans by semantic similarity rather than brittle exact-string matching — which matters, because a paraphrase almost never reuses the source's words verbatim. The matcher itself is small Python: embed each claim, pull the top candidate spans, and decide whether any candidate clears a similarity threshold you can tune. For the embedding step I'd stick to a model already available through the platform's Model Center rather than reaching for an outside service, so the whole thing stays inside one environment.

You can stand the matcher up as an endpoint you run Python online, which means the assistant — or whatever agent is doing the summarizing — can call it as a tool mid-conversation. Summary comes in, span map goes back, and claims that returned "no matching source" either get stripped, get re-asked, or get surfaced to the human with a visible warning. Every check writes a row to a SQLite table: the claim, the matched span or null, the similarity score, a timestamp. After a week you can actually see where your assistant tends to confabulate instead of guessing from vibes.

Where the line is

Be honest about the boundaries, because they're load-bearing. This catches claims the model invented in transit. It does not catch a claim that's faithfully relayed from a source that is itself wrong — garbage in, faithfully-relayed garbage out. It also leans on your similarity threshold: too loose and a vaguely-related span gets accepted as backing, too strict and legitimate paraphrases get flagged. That's a dial you have to calibrate against your own material, not a setting you can copy from a blog post. Any claim that this meaningfully reduces hallucination in your workflow is unverified until you've run it on your own traffic and read the SQLite log yourself.

And it only covers what's in scope here: a Python matcher, a knowledge base of source text, an embedding model that's already on the platform, an endpoint, and a log. It is not a framework for retraining the model, and it won't fix a model that reasons badly — it fixes the specific moment where a reasoned-out summary leaks unsupported detail.

The quieter case for building narrow

There's a thread in that same evidence set, from the Lucy AI Studio writeup, that frames this nicely from the other end. The point it makes is that pulling fields from a fixed set of materials, classifying files, and drafting from specified sources place very different demands on a system than open-ended reasoning does. A groundedness checker is squarely in that first camp. It's a bounded, checkable task with a fixed set of inputs, which is exactly the kind of thing you want a small deterministic tool doing instead of trusting a general model to police itself.

That's also why this is a good first project if you're getting into AI coding and want something real rather than a toy. The scope is tight, the success criterion is observable in your own logs, and the thing it fixes is a problem you've almost certainly already felt — the assistant that sounds certain right up until you check its work. You're not building a lie detector. You're building a receipt printer, and refusing to let the relay step pass off its guesses as confirmed.