Making the gaps visible

The default is to fill the hole

Asked something it does not know, a model does not stop. It produces the most plausible continuation, and a plausible continuation to “what is your delivery charge to Kano?” is a number.

You cannot switch this off. You can make it far less likely, and (more importantly) you can make the gap visible when it happens. Three techniques, in ascending order of strength.

1. The bracket

One line, added to every request:

If the facts sheet does not answer part of this, write
[CHECK: what is missing] instead of guessing.

Small and remarkably effective. A visible bracket is a three-second fix; an invented delivery charge is a customer expectation you now have to honour or explain away.

Why it works: it gives the model a licence and a format. Left to itself, a helpful-sounding complete answer is more likely than an incomplete one. Naming an acceptable alternative changes what counts as a good answer.

Why it does not always work: the bracket is not a check. Nothing in the model verifies whether the fact was present. It has been nudged toward flagging gaps, and it will still miss some: typically the ones where the invented answer felt very natural, which are precisely the ones you would most like flagged. Treat it as a large improvement, not a guarantee.

2. Closing the book

Stronger, and it changes what the model is doing:

Answer ONLY using the FACTS section below. If the answer
is not there, reply exactly: NOT IN FACTS.
Do not use general knowledge.

This is the difference between an open-book and a closed-book exam. It cuts invention substantially, because you have made the wrong behaviour (reaching for general knowledge) explicitly forbidden rather than merely unhelpful.

The cost is real and worth understanding. A strictly grounded model becomes literal-minded. Your sheet says you deliver to Ikeja; the customer asks about Ikeja GRA; you get NOT IN FACTS. That is annoying, and it is the correct trade: a system that refuses when uncertain is one you can hand to a member of staff, and a system that improvises is not.

3. Make it show its working

The strongest, because it converts a claim into something checkable:

For each factual statement in your reply, quote the exact
line from the FACTS section it came from. Put quotes in
square brackets after each sentence.

Now your checking pass is mechanical. Every sentence either carries a quote you can verify against the page, or it does not, and a sentence without one is unsupported, whatever it says.

This is where a subtle failure shows up, and it is worth naming because it undermines the whole technique if you do not know about it. A model can produce a fabricated citation: a quote that reads plausibly and is not on the page. So the quotes have to be checked against the source, not merely counted. In practice this is quick (you are scanning a one-page sheet) and it catches the fabrications that survive both earlier techniques.

Use all three, in layers

They stack, and each catches what the previous one lets through:

1. The facts sheet supplies real material, so there is less to invent.
2. Closed-book grounding forbids reaching outside it.
3. The bracket gives a clean way to report a genuine gap.
4. Quotes make each remaining claim checkable in seconds.
5. Your reading pass catches the rest.

None of these is a guarantee on its own. Together they turn a fluent guesser into something you can supervise cheaply, which is the whole objective.

The thing worth remembering

A request that produces a confident wrong answer and a request that produces NOT IN FACTS may be equally good prompts. The difference is which failure you can see.

Design for visible failure. Every technique in this lesson is a version of that one idea, and it is the idea that makes the rest of the course workable.

Why the default leans toward answering

It helps to know that this behaviour was partly trained in. After the initial training, models are tuned on human preferences, and human raters consistently prefer a helpful, complete-sounding answer to a refusal. That preference is what the tuning optimises toward.

The result is a machine with a mild, systematic bias against saying it does not know. Vendors have worked hard on this and it has improved, but the pull is still there, which is why an explicit licence to say NOT IN FACTS does so much work. You are not fighting a bug. You are offsetting a preference that was deliberately installed for good reasons in other contexts.

What the numbers look like

Published evaluations of grounded question answering generally show large reductions in fabricated content when the model is confined to supplied sources, but not zero, and the residue is stubborn. Nobody should quote a percentage at you as though it applied to your prompt and your documents.

The practical reading: grounding turns a frequent problem into an occasional one. An occasional problem still reaches customers if nobody checks. So the layers stay, and so does the reading pass.