Why entity scoping is the retrieval decision that matters

The failure this is about

Two customers with the same surname at the same address. A supplier under a parent name and a trading name. A patient with records under a maiden name. An asset re-registered after a transfer.

These are not exotic cases. They are the ordinary condition of enterprise data, and they produce a specific failure: an answer that blends facts about two different entities without indicating it has done so.

That answer is fluent. It looks right. It is the failure that gets programmes cancelled, because it is the one an executive notices personally.

Why better retrieval does not fix it

The usual retrieval improvements — a stronger embedding model, structure-aware chunking, hybrid dense-plus-lexical search, cross-encoder re-ranking — all make the system better at finding similar content.

Entity ambiguity is not a similarity problem. The wrong customer's records are genuinely, correctly similar to the query. A better retriever finds them more reliably.

The information needed to exclude them is not in the text at all. It is the fact that these records belong to a different resolved entity — which exists only if something upstream resolved entities in the first place.

The design consequence

Retrieval is scoped to the resolved entity before similarity is considered at all. Scope first, rank second.

This changes the question from "what is similar" to "what is similar within this entity's records", and no amount of retriever quality substitutes for it.

The uncomfortable implication: the retrieval improvement we expect to matter most is not a retrieval investment. It is a data-layer one, and it has a hard prerequisite — a resolved entity graph. Estates without one cannot apply this at all, which is itself the finding.

Larger context windows make it worse, not better

Worth stating separately because the instinct runs the other way. Increasing top-k on an ambiguous corpus pulls in more confusable material competing for attention. Retrieve broadly, re-rank, and pass few.

How to test this properly

A general question set will not show the effect — entity ambiguity is rare in aggregate and dominant in the cases that matter. Build the benchmark adversarially:

1. Find real confusable entities in your own data: shared names, parent/subsidiary pairs, pre- and post-merger records, changed identifiers.
2. Write questions whose correct answer depends on resolving which entity is meant.
3. Verify the answers by hand. This is slow and there is no shortcut.
4. Measure two things separately: answer accuracy, and blended-answer rate — responses combining facts about two entities without flagging it.

The second number is the one to watch. An answer that is merely wrong gets caught. A blended answer is confidently wrong and does not look wrong.

What we are not claiming

We have not run this benchmark at scale across production estates, and the relative contribution of each retrieval improvement will depend heavily on how ambiguous a given corpus is.

What we are claiming is the mechanism: scoping addresses a failure that ranking cannot, because the discriminating information is not in the text. That argument stands on its own, and the benchmark above is how you would check it on your data rather than take our word for it.