Keyword search finds the documents that contain your words. The trouble is that the customer, the technician, and the engineer who wrote the manual rarely use the same words for the same thing, and a keyword index has no way of knowing they were all talking about one event.
Three names for one failure
A homeowner calls and says the unit hums but won't kick on. The technician who ran the last call wrote "compressor won't start" on the ticket. The manufacturer's service bulletin for the exact condition calls it a locked rotor event. Same failure, three vocabularies, zero shared words. Search the service history for the customer's phrasing and you find nothing; search the bulletins for the tech's phrasing and you find nothing. The knowledge exists in the building. The spellings never meet.
This is not an exotic edge case. It is the normal condition of any business where the people describing problems and the people documenting fixes learned their language in different rooms.
Numbers that stand for meaning
An embedding model reads a passage of text and produces a long list of numbers — several hundred of them — that work like a coordinate. The useful property is that passages meaning similar things get coordinates near each other, regardless of vocabulary. "Hums but won't kick on" and "locked rotor condition" land close together, because the model was trained on enough text to have absorbed that these phrases show up in the same contexts, describing the same physical event. There is no magic in the numbers themselves. They are a learned summary of how language gets used, compressed into a position.
Every chunk of every document in your system gets a coordinate at ingestion time. A question gets a coordinate at the moment it is asked.
The warehouse analogy
A keyword index is a warehouse shelved alphabetically by label. To find anything, you must know exactly what is stamped on the box, and one letter off means you walk past it. Vector search is a warehouse shelved by subject: everything about compressors sits in one aisle, whatever the boxes are labeled, and finding an answer means walking to the neighborhood of the question and pulling the nearest boxes off the shelf. That last step has a technical name — nearest-neighbor lookup — and it is the entire operation: measure which stored coordinates sit closest to the question's coordinate, return those passages.
Where it fails: the 4400-B and the 4400-C
Now the failure, and it is a serious one. Consider two condenser fan motors, Model 4400-B and Model 4400-C. Their catalog descriptions are nearly identical — same horsepower, same frame, differing in shaft length and rotation direction. In meaning-space they are almost the same point, and that placement is technically correct: they very nearly are the same thing. But at the parts counter, "very nearly" is the whole disaster. The wrong motor goes on the truck, doesn't fit at the top of a ladder thirty miles out, and the return trip eats the margin on the job.
Vector search is structurally weak at exact identifiers — part numbers, serial numbers, invoice numbers, permit numbers, code sections. The letter that separates the 4400-B from the 4400-C carries almost no meaning, so it barely moves the coordinate. To the warehouse picker, that letter is the only thing that matters.
Hybrid search is the fix, and it is the default
The remedy is not choosing a winner. It is running both indexes and merging the results. Anything that looks like an identifier or an exact phrase goes through old-fashioned literal matching, which will never confuse a B with a C because it does not know what either means. The phrasing of the question goes through the vector index, which finds the locked-rotor bulletin from the homeowner's description. Exact matches rank above near ones when both fire. This pairing — usually called hybrid search — is how every serious system is built now. A vendor offering pure vector search is selling you the demo, not the parts counter.
What "approximate" is trading away
One more honest mechanic. Measuring a question against every stored coordinate — true exact search — gets slow as the collection grows into the millions of chunks. Production systems use approximate nearest-neighbor indexes, which organize the space so a query only checks promising neighborhoods and answers in milliseconds. The trade, stated plainly: every so often, the genuinely closest passage is not in the handful returned. For "what does the warranty say about wind damage," this barely matters — the fifth-closest paragraph answers about as well as the first. For "find invoice 20447," missing the one right record is total failure. That asymmetry is a second, independent reason exact lookups belong on the keyword path, where finding a literal string is not probabilistic.
When this is the wrong tool
A business with forty documents does not need any of it; a person can read forty documents, and plain keyword search covers the rest. Questions that require arithmetic — the three largest invoices last quarter, total warranty claims by month — are database queries, and retrieval by similarity will answer them badly while sounding fine. And anywhere "close" is dangerous — medication dosages, torque specs, breaker sizing — the system should surface the source passage for a human to read with their own eyes, not convert distance-in-meaning-space into confidence. Similarity is a way of finding candidate text. It is not a way of knowing the text is right.
Where to start
Write down the ten questions your counter staff or your dispatcher answers most often, in the words customers actually use on the phone. Then open the documents that contain the answers and check whether those words appear in them. The size of that vocabulary gap is the size of the case for meaning-based search — and if the gap turns out to be small, you have just saved yourself a system.