The blogBrick by brick · Episode 2/5
Published on
An answer that cites its sources, or says nothing
Why I put my first complete system on the most demanding ground I know.
"Brick by brick" series, Episode 2/5 · 1. The code Auditor · 3. The FHIR bridge · 4. ITFacto · 5. The model is the last question
The experiment I'd invite you to run
Take the conversational assistant of your choice. Ask it something whose answer exists nowhere: an invented statistic, a recommendation that was never published, a detail about a document that doesn't exist.
It will answer you.
Not always, not systematically - models have improved. But often enough, and above all with the same poise, the same confident syntax, the same absence of any signal as when it's right. That last point is the problem. It isn't that it gets things wrong: it's that nothing outwardly distinguishes the moment it's wrong from the moment it knows.
A system that always answers is a system you must always check. And a system you must always check doesn't save time, it costs time, with a pleasant interface.
That's the problem I wanted to take head-on. So I went and posed it where it hurts most.
Why healthcare
Start with the least technical reason: it's also the sector I hope to work in. Rigour and impact are what I look for in a job, and few fields ask for as much of both at once.
The other three can be checked without taking my word for anything. In the order they mattered.
The corpus exists, and it carries authority. Few fields have a reference body of work that is at once public, free, in French, dated, and genuinely cited by practitioners in their work. The publications of the Haute Autorité de Santé - France's national health authority - meet all five conditions: 6,504 documents, 214,629 pages, split into 796,019 passages. On a corpus of internal procedures or a product catalogue, I'd have built a demonstration nobody could open, check, or contradict.
The field imposes the rule instead of letting me choose it. A plausible but wrong answer doesn't cost a correction here: it costs the trust of an entire profession, durably, and rightly so. Elsewhere, "the system must cite its sources" is a good intention that gets negotiated away at the first deadline. Here it's the entry condition. I wanted ground that gave me no way to cheat on my own standard.
And there's a next step. Healthcare is one of the rare sectors to have equipped itself with an open standard for exchanging the data itself - FHIR. Documenting an answer, then plugging it into a real record, is a path that exists almost nowhere else. That's the next brick, and it's why this one starts here.
So: a question of practice, and somewhere in those 796,019 passages, the one that answers it. Or not.
The "or not" is the subject of this article.
The rule that structured everything
One constraint, set before any design work, and which nothing was allowed to bend:
Every statement cites the extract that grounds it. Otherwise the system says nothing.
No general synthesis without anchoring. No answer made of training-set memories varnished with sources. Sentence by sentence, the extract retrieved from the corpus, with its provenance. And if the search brings back nothing sufficient, an acknowledged non-answer rather than a polite workaround.
The rule sounds restrictive. It is liberating, and that reversal is what I wanted to demonstrate.
Because a system that can say "I find nothing in this corpus that answers your question" makes all its other answers credible. Silence becomes the guarantor of speech. The user no longer has to check everything: they have to check what interests them, and they know where to look, because the extract is right there.
Refusal isn't a failure. It's a feature - probably the hardest one to obtain and the most profitable.
And two outcomes aren't enough. You need three. Answer, refuse - and report an absence, meaning: report that the source itself states there's no established evidence on the question. Without that third path, "the authority hasn't ruled on this" would count as an ordinary answer, and faithfully reporting an absence would look like a regression.
What a system like this really costs
I'll skip the machinery; it's documented everywhere and it isn't the subject of this series. Two findings from the field are worth sharing, though, because they drive the budget far more than the choice of model.
First: the difficulty isn't finding, it's knowing that you haven't found. Bringing back the ten passages closest to a question is nearly routine today. Deciding that those ten passages don't in fact answer it, and standing behind that - there's the work. That's where the difference between a demo and a tool is settled.
Second: the quality of the answer depends first on the preparation of the corpus. Documents that are dated, cleanly segmented, and known for what they cover. That thankless work determines most of the final result, and it never gets a single screenshot in a sales presentation.
The number I could have left out
The system is measured against a 162-question benchmark. Recall at ten passages: 80%. Warm latency: 16 milliseconds.
That leaves the ranking-quality measure, nDCG. And there I had to make a choice I find more instructive than the result itself.
That figure depends entirely on what you accept as a success. If you accept only the exact page the question was drawn from, it's 0.322. If you accept any document in the relevant HAS dossier covering the subject, it's 0.693.
Publishing the second on its own would have been very comfortable. It compares favourably with the 0.314 of the best standard model on R2MED, a recognised benchmark. Except that R2MED is built to require reasoning, whereas my questions are drawn from the documents they have to retrieve - an easier task. The flattering comparison would have been a dishonest one.
So the two bounds travel together, everywhere either one is quoted. It's less spectacular, and it's the only thing I can defend to someone who disagrees.
The yardstick served against me first
The previous episode described a tool that builds nothing: it analyses existing code and says where to start. A six-axis grid, a calibrated score, my written definition of well-built code.
This documented search system is the first thing I built under that grid. It served against me before it served anyone else, and that was exactly the intention.
There's a coherence I hadn't anticipated when I started, and which became the thread of this whole series: requiring a system to show its sources and requiring yourself to measure your own work are the same gesture. In both cases, you refuse to let an unfounded statement stand on the sole grounds that it is well phrased.
What transposes elsewhere
You probably don't work in healthcare. The rule concerns you anyway, and it translates into one question to ask at the first meeting of any project at all:
What should this system do when it doesn't know?
I have never once heard it asked spontaneously. Yet it decides adoption more reliably than raw performance does. A tool that's wrong one time in ten without warning will be abandoned in three weeks. A tool that answers eight times out of ten and declines the other two will be used for years.
Trust isn't earned by being right often. It's earned by being predictable.
And notice which way the demonstration runs: what holds in healthcare holds everywhere else. The reverse has never been true. A system validated on a forgiving corpus proves nothing on a demanding one, whereas a system designed for the demanding case relaxes effortlessly.
Last word
Two bricks laid. The first says how to measure the quality of what you build. The second says how to produce an answer that proves itself, and how to keep quiet when it can't.
Something was still missing, though, and I understood what when I showed the system to practitioners.
Their questions were never general. They were about one specific record, with a specific context, and an answer that was correct in the abstract only got them halfway. They weren't looking for what the literature says. They were looking for what it says for this case.
Which shifts the whole problem: no longer the quality of the answer, but what you plug the system into so that it knows what you're talking about.
That's Episode 3.
📖 In the same series - Episode 1: the code Auditor (my first project doesn't build anything) · Episode 3: the FHIR bridge (plugging knowledge into the real world) · Episode 4: ITFacto (twenty months, five applications, real users) · Episode 5: the model is the last question (the four questions for the first meeting).
The three systems described in this series are online and public. I design traceable, verifiable AI systems, from use case to deployment - more about my background, or write to contact@lamoulinette.ai.