Search your files by meaning and keywords

What this is

This is the search that sits underneath a helper answering from your own material, and its one job is to find the exact right passage in your files. It looks two ways at once. It looks for the exact words a customer typed, and it looks for what they meant, so a question phrased nothing like your documents still comes back with the right answer. I call this a hybrid search, which is a plain way of saying it combines two ways of looking at the same moment instead of leaning on either one alone. It is the piece that lets a helper pull the right answer out of years of files, and the piece that keeps a website helper answering from information you approved rather than guessing.

Why ordinary search was not enough

Ordinary keyword search only finds the exact words a person types, which is why it so often comes back empty on a real customer question. People do not phrase things the way your documents do. Someone asks about a “late payment fee” when your policy calls it an “overdue account charge,” and a plain keyword search finds nothing, even though the answer is sitting right there. Searching by meaning fixes that, but on its own it has the opposite weakness. It can smooth over the exact terms that have to match precisely, like a product code, a person’s name, or a clause number. Neither way is enough by itself, so I run both at once and let each one cover for the other’s blind spot.

How it works, in plain words

The search runs two lookups at the same moment, one for meaning and one for exact words, then combines both and re-sorts them so the best answer rises to the top. Here is each step in plain terms.

First, the meaning lookup. Your documents and the customer’s question are both turned into a form that can be compared by meaning rather than by spelling, using a specialist model from Voyage, called voyage-context-3. That is what lets an oddly worded question land on the passage that actually answers it.

Second, the keyword lookup. Alongside the meaning search, the same question runs through BM25-style keyword ranking, a well-known way of ranking results by their exact words. In these builds that ranking is done by the database’s own full-text search, working in that same style. This is the part that catches the precise terms the meaning search might smooth over.

Third, the two sets of results get merged. Combining two ranked lists fairly is a solved problem, and I use the standard method for it, called Reciprocal Rank Fusion, so that neither list bullies the other. The meaning search leads, and the keyword ranking rescues the exact names and codes it would otherwise miss.

Fourth, the shortlist gets re-sorted. A second Voyage model, rerank-2, takes the merged candidates, around twenty of them, reads each one against the question properly, and keeps only the strongest handful in the right order.

Fifth, the answer gets its context back. Rather than handing over a single stray sentence, the search stitches each match together with the few pieces on either side of it, so the helper answers from a whole passage instead of a fragment.

A story from a live system: tuning the search until it found everything

On one production search I built and delivered, a set of test questions I already knew the correct answers to exposed a quiet failure: on a narrow topic the search was returning none of the five passages it should have, and after a single tuning fix it returned all five. Here is what happened and why it matters.

The search I usually build checks a question against every passage in your files, one at a time, which is exactly right at the sizes I work with. This delivered system held a larger collection, so it used the faster kind of meaning search, the kind that keeps working as documents pile up. That faster kind is approximate, which means that instead of reading every passage it jumps through a structure called HNSW to reach the closest matches. It is quick, but the shortcut can occasionally skip the right passage. That is the trade, and on this system it was skipping answers.

The cause was a single setting that controls how hard the index looks before it settles, called ef_search. I turned it up to 200, ran the same checks again, and the search went from finding none of the right passages to finding all of them. I baked that setting into the system so the fix holds.

A fast, approximate search cannot be judged by how well it answers the handful of questions you happen to try first. It has to be measured against answers you already know and tuned until it returns every one of them, because the passages it quietly drops are exactly the ones a customer will go looking for.

What this means for you

For your business, this is the difference between a helper that reliably finds the right answer in your own material and one that guesses. An oddly worded question still lands on the right passage. The exact terms that have to be right, like a product code or a policy number, are not lost along the way. Because the search hands the helper the exact passage it found, the answer can point back to where it came from, so you or your customer can check it rather than take it on faith. And because it is measured against answers I already know before it is put to work, the search you end up with is one you can rely on to find what is actually there.

Where this is used

This search sits underneath the job of finding anything in your own documents in seconds, and it is also what keeps a website helper answering only from information you have approved. It is the engine behind Find anything in your own documents in seconds, pulling the right answer out of years of files. Before it can look through anything, though, your files have to be read, cleaned up and broken into searchable pieces. That is a separate step, the document ingestion pipeline, the half of the work that happens before anyone asks a question.