Trustworthy
Why search misses things, and what to do about it.
Your question rarely uses the same words as the document that answers it. That one gap is behind most of what people mean when they say their search is bad — and it is not fixed by trying harder at matching text.
In short
A search here does not look for your phrase, it looks for the answer. The plain literal search always runs underneath at full strength and is never replaced — and everything on top of it reaches content your words did not match, and the documents that back the answer up.
What a search reaches
Two things on top of one guarantee.
what you meant
Documents your words never matched
Your question says renewal; the document says uplift, or true-up, or escalator. Nothing about those strings resembles each other, and the document comes back anyway — because we have read enough of your content to know they are the same subject.
not the ones that resemble it
The documents that support the point
Once it knows which claims are relevant it goes looking for everything in your corpus that states them, so the evidence behind an answer is a real set of documents rather than whichever passage happened to score highest.
always, at full strength
Everything an ordinary good search would find
The literal search for what you typed runs on every question and is never held back, traded off or turned down to make room for anything else. Whatever the rest of the system manages or fails to manage, the plain search is always underneath it — on a question where nothing else helps, its results are what you get.
The gap
Four reasons a search returns the wrong thing.
None of them are solved by a better similarity score, which is why buying a better vector database rarely changes how the search feels.
You and your content use different words
A customer asks about being locked out; the runbook says authentication failure. Neither string appears in the other, and a search that scores text against text has nothing to work with. This is the ordinary case, not the edge case.
The answer is in two documents
One holds the fact about this account, the other holds the rule that governs it. Both rank badly on their own, because neither one is a good match for the whole question — and the whole question is the only thing anyone typed.
The best match is not the best source
The passage that most resembles the question is often a summary, a marketing line, or an out-of-date restatement. The passage that actually supports the point uses different words and sits further down.
You cannot tell which of those happened
A search that returns something plausible gives you no way to know it missed the right document. That is why the answer here shows every source it used and says when it found nothing worth using.
Evidence
Every supporting document, not one arbitrary mention.
When several of your documents state the same thing, the answer is built from all of them — because each one usually says it for a different reason, and the useful reason is rarely in the first result.
The cheaper thing to do, and what most implementations settle for, is to take one document per claim and move on. It looks the same in a demo and it quietly loses the reason you wanted more than a search box: three documents agreeing is not three copies of one sentence, it is three people who knew something slightly different.
One thing worth knowing, because it changes how you read the counts. A source count is a floor: every document behind it is real and openable, rather than an estimate of how many exist. A count of one frequently means one clear statement was found, not that only one document says it — so the number under-promises rather than over-promises, which is the direction you want it to err in.
Checkable from the outside
Four things you can verify without taking our word for anything.
This is the list that matters when you are deciding whether to put a generated answer in front of a customer.
Every source behind every claim
Not one representative document — all of them, each labelled with the system it came from, so a claim resting on one source looks different from a claim resting on five.
What it found and did not use
The ranked passages come back beside the answer, so you can see the material the answer was written from rather than inferring it.
How long it took
Timings arrive in the ordinary response, not behind a special call, so a search that got slow in production is diagnosable from your side without asking us to read a log.
Why a search returned what it did
The Search Playground replays any question and shows what was found and what the answer was built from. Most disappointing answers turn out to be explainable — and usually the explanation is a document that never finished processing.
The answer itself
Retrieval is half the product. Not overstating what it found is the other half.
A retrieval API that hands back passages and stops leaves every caller writing their own grounding prompt over provenance they understand less well than we do.
One answer, every search
Prose is not an opt-in extra tier or a second call. If a search returns documents, it returns something written about them.
Only what your sources say
An answer may state what a document you sent us states, and nothing else. Where your content runs out, the answer runs out — it does not quietly continue from what the model knows about the world in general.
Citations that resolve
Every marker points at a document you gave us, under your own identifier, so a citation is never a dead end.
Refusal is a real outcome
Saying "your content does not answer this" is a success here. We test for it deliberately, using questions we know the corpus cannot answer, scored so that answering one counts as a failure.
On a bad day
It degrades. It does not fall over.
Worth reading before you build on this, because it tells you how much error handling you actually need — which is less than you would expect.
| If this fails | What you still get |
|---|---|
| The connections between your documents are unavailable | Search answers normally from the content itself. You lose the cross-document reach, never the results. |
| The question mentions nothing we recognise | There is nothing to connect it to, so the plain search is the answer. No error, no empty response. |
| Nothing relevant is found to connect | The extra work contributes nothing and the ordinary results stand unchanged. |
| Writing the answer fails | You get a null answer and the ranked documents intact. The caller loses the prose, never the sources. |
What you still get
- The connections between your documents are unavailable
- Search answers normally from the content itself. You lose the cross-document reach, never the results.
- The question mentions nothing we recognise
- There is nothing to connect it to, so the plain search is the answer. No error, no empty response.
- Nothing relevant is found to connect
- The extra work contributes nothing and the ordinary results stand unchanged.
- Writing the answer fails
- You get a null answer and the ranked documents intact. The caller loses the prose, never the sources.
What the graph is shown to do, and the one thing we cannot measure.
The cross-document work contributes to 201 of 231 question runs on our evaluation corpus, so on the large majority of searches it is genuinely reaching content the question alone would not have. What it adds is checkable directly: an answer that states something no single passage does, and every document standing behind it.
What we cannot yet show is that this produces an answer ordinary retrieval would have missed. On the question sets we can score, it has not. We say so rather than publishing a chart, because a chart here would be marketing rather than evidence — and because the claim is cheap for you to test on your own corpus, which is the point.
FAQ
Frequently asked
The questions people actually ask on the first call, including the two we answer with a no.
Start with the free tier. Ship the first answer today.
RAG is free, with no card and no sales call. Add the graph when your corpus earns it.
- no card required
- first workspace is free
- one POST to ingest