Which search do you mean? Six layers, and where each one belongs

Leon

• 2026-03-10

Ask five engineers what search means and you get five systems. One means the box that finds a part number. One means a ranked list. One means a chat window that answers in sentences. Each of them is right about a different problem, so the meeting ends without a decision.

That is the starting point of Modern enterprise search, a whitepaper we wrote for the architects who have to choose. Its claim is short. Search is not one thing, and most arguments about it are about which layer is meant. Name the layer first, and most of the disagreement goes away.

Six layers, one question each

The paper splits search into six layers. Each one builds on the one before it.

The table is the paper's, condensed. No row covers everything. Each layer fills a gap the one above it leaves, and that is the case for running them together instead of picking one.

The layers also depend on each other. An agent is only as good as the search it calls. A hybrid ranking is only as good as the two lists it merges. So the first design decision is which layers your questions need, and what each one needs from the data underneath. Which product to buy comes later. The paper's advice is plain: list the questions people ask today, mark each with the layer it needs, and build the layers you marked most.

Where keyword still wins

A technician types A320-2741-08. There is one right answer. A near miss is the wrong part on the line.

This is where the paper gets specific. Vector search is built to find what is close. For an identifier, close is the failure. Part 2741-08 and part 2741-09 sit next to each other in any space of meaning, and they are different parts. That is why a production system keeps a keyword index beside the vector one. The paper's rule: keep keyword for identifiers, add vectors for meaning, and never replace one with the other.

Keyword retrieval has a second property that matters in regulated work. It explains itself. A BM25 match is a set of terms that appear in the record. A rare term adds more to the score than a common one, and a long document is damped so it cannot win by size alone. An engineer can see why a result ranked where it did.

The same chapter has a design rule I would put on the wall. When the exact match is missing, return nothing and say so. Then offer the close matches as a separate list, marked as close. A list of near misses with no warning invites someone to pick the wrong part.

What vectors add

Keyword search has a vocabulary problem. A field report says the aft door seal was weeping fluid. The ticket about the same fault says hydraulic leak, door 4. No word is shared, so keyword search treats them as unrelated records.

Vector search turns each record into a point in a space where distance stands for meaning. Records about the same fault land close together, whatever words their authors chose. The cost is explanation. A vector match is a distance, and a reviewer has to trust it or open the record. Hence the paper's split: use vectors where people describe a thing, and keep keyword where they name it.

Merging two lists is harder than it looks

Running two indexes leaves the question of order. The paper's answer is a hybrid ranking: exact matches first, close ones after, permissions applied before anything is ranked.

The merge is its own problem, and other teams have written about it. John Wang at Assembled described it in Better RAG results with Reciprocal Rank Fusion and Hybrid Search. His team found that vector search on its own missed short queries with prominent keywords, so they added keyword search beside it. They first tried to combine the two by weighting their scores. That failed because similarity scores varied widely from one customer's data to the next, and no single set of weights held. They moved to reciprocal rank fusion, which merges on rank position instead of raw score. It held up better and needed less tuning.

The Hacker News thread under that post adds two points. One commenter noted that the papers the post cites add a constant to the rank, 1/(60 + rank), instead of the plain 1/rank the post describes. Another commenter, from a search team at a cloud provider, reported further gains from a reranking stage on top of the hybrid list. Neither changes the paper's point. Exact and close are two lists, and the system needs a deliberate rule for turning them into one. Score numbers from different indexes do not compare on their own, which is the subject of a separate paper, What a search score means.

Graph retrieval: how records relate

Hybrid search still treats records as separate documents. Many industrial questions are about the links between them. "Which A320 parts failed after the March notice?" needs the notice, the parts it covers and the tickets those parts caused.

The paper walks through that question step by step. Permissions come first, synced from each source system. Keyword search finds the exact terms, the aircraft type and the notice id. Vector search finds the close ones: failed, fault, removed. The hybrid ranking merges them. Then the graph follows part to notice to ticket, and the answer is a list of parts, each with its source record. A reviewer can open every line.

The thread under the Assembled post asks the same thing: which kind of graph, and which retrieval method? The paper's answer is a typed graph, with a part, the notice about it and the ticket it caused.

Agents that search, and the permissions problem

Ask an agent which suppliers are behind the delays on the A320 line. It does not search once. It finds the delayed orders, then the parts on those orders, then the supplier notices about those parts. Each step is a search.

The paper's argument is that each of those steps has to run as the person who asked. If one step ignores permissions, the answer can contain a record the user could never open. That is why permissions belong in the search layer and not in the agent. An agent that filters afterward has already read what it should not have seen.

A fair counterpoint comes from the security side. Simon Willison's lethal trifecta talk describes the risk when an agent combines access to private data, exposure to untrusted content and a way to send data out. His conclusion is that filters which catch most attacks are not enough, because "in application security, 99% is a failing grade", and that removing any one of the three legs prevents the attack. Permission-aware search does not make an agent immune to prompt injection. Nothing in the paper says it does.

What it does is bound the damage. An agent that searches as its user can only reach what that user could already open, so it cannot pull restricted records into an answer in the first place. The paper adds two more requirements. The agent needs exact matches too, because a supplier notice is found by its id and a close match on an id is the wrong notice. And every step leaves a trail: a reviewer should be able to open each search the agent ran, with its results, and see how the answer was built.

How we built it

The last chapter describes how Curiosity puts all six layers in one system on your infrastructure. Its customer story is Airbus. The Services Innovation Team in Airline Services had forty years of technical data across CRM systems, network drives and engineering databases, written in acronyms and reference numbers that ordinary search could not handle. In the team's words: "By intelligently enhancing our search efficiency, Curiosity lets Airbus technical support quickly find information across millions of documents." The change was one entry point over every source. The engineering references were extracted and joined in a graph, with filters by aircraft type, program and reference number.

The paper recommends three steps, in this order:

1. Index every identifier field for exact match first.
2. Add vectors where people describe a thing instead of naming it.
3. Rank both together, then follow the graph.

Before you choose anything, it asks four questions. Which fields hold identifiers? Where do people write in their own words? Who may see which record, and in which source system is that set? Who needs to check why a result was returned? If you can answer those, you know which layers you need.

The 21 page paper also covers BM25 scoring term by term, the query path as a diagram, and a glossary. Read it on its page or download the PDF directly.

Read the whitepaper (PDF)

Further reading

• Better RAG results with Reciprocal Rank Fusion and Hybrid Search, John Wang, Assembled. Why vector search alone missed keyword queries, and why score weighting gave way to rank fusion.
• Discussion on Hacker News. The standard RRF constant, reranking on top of hybrid search, and practitioners asking how graphs fit into retrieval.
• My Lethal Trifecta talk at the Bay Area AI Security Meetup, Simon Willison. A plain account of what can go wrong when an agent holds private data, reads untrusted content and can send data out.