Semantic Search
Search that finds things close in meaning, not matching letters
- Semantic search finds what's close in meaning, not what has matching letters.
- Documents and questions each get turned into a set of numbers carrying meaning, and the search checks how close those spots sit.
- The document side gets calculated ahead of time. At search time, only the question needs converting, so it runs fast.
- It finds things worded differently, but it's weak on anything that has to match exactly — part numbers, people's names, figures.
- That's why real systems usually run letter search and meaning search together and merge the results.
Contents
1The analogy
Somewhere in a drawer sits a box of business cards. Filed alphabetically, you can only find someone if you already know their name. Trying to track down the contractor who fixed your roof last year, but the name's slipped your mind? You'd have to flip through the whole box.
So instead, whoever files the cards starts writing what the person does on the back, and grouping similar work into the same section. Waterproofing, leak repair, and roof work go in one section; electrical and wiring go in another. Now, holding "water is dripping from my ceiling," you open the drawer and your hand goes straight to that section without ever knowing a name.
It doesn't matter if the word "leak" never once appears on the card. This system sorts cards by how close the work is, not by which letters got written down.
2In detail
It searches by meaning, not by letters
Old-style search checked whether letters matched. Type "leak repair" and only documents containing that exact phrase came back. The same issue written as "water is coming in" shared no letters at all, so it got buried.
Semantic search turns both the question and every document into a set of numbers carrying meaning, then compares those sets. A document phrased differently, one with typos, even one written in another language, can land in the same group.
You can also throw a long question at it without trouble. Typing in a full sentence like "the washer I bought last month only makes noise while draining" works fine, because the query isn't being counted word by word.
Positions get worked out ahead of time
Reading through every document each time someone searches would be far too slow. So the document side gets converted to a set of numbers and stored ahead of time — the calculation only has to run once, when a document is added or edited.
When a search comes in, the only thing that needs calculating on the spot is the question. Its spot just needs comparing against the ones already stored, and the nearest documents get picked. Rather than checking against every single one, systems also narrow the field to nearby candidates first and only measure precisely within that smaller set.
Values calculated ahead of time are tied to the model that made them. Swap in a new model for converting documents, and everything stored under the old one becomes unusable — it all has to be recalculated from scratch.
Closeness gets measured as direction
How do you decide how close two spots are? A common approach skips distance and checks instead whether they're pointing the same way. Two arrows lined up means close; pointing different directions means far apart.
There's a reason length gets set aside in favor of direction alone. The same content told briefly and told at length produces arrows of different length. Count length directly and the longer document keeps floating to the top. Looking only at direction lets whatever is closest in content rise, regardless of length.
This approach is called cosine similarity. The ranking semantic search hands back is, in the end, measured with this same ruler.
What it's good at and what it isn't
Searching by meaning doesn't always win. Similar in meaning doesn't mean an exact match. For anything where a single character off makes it a different thing — part numbers, account numbers, people's names — meaning-based search tends to stumble.
Negation trips it up too. "Photos without a cat" and "photos of a cat" sit extremely close in meaning-space. Results with the opposite of what you asked for still climb near the top.
New slang and company-only shorthand are hard as well. Anything a model never saw during training doesn't know which section it belongs in, so it gets grouped with the wrong neighbors.
The two approaches run together
That's why real systems don't rely on just one. Letter search and meaning search run side by side, and the two sets of results get merged and re-ranked. A part number gets caught precisely by the letter side; a spelled-out question gets carried by the meaning side.
Sometimes there's an extra filtering pass afterward. Pull the top few dozen candidates and re-rank them with a more careful model. That raises accuracy far more cheaply than carefully checking everything from the start.
The same search sits at the front of systems where an AI looks things up before answering. Pull the wrong document at the front, and no amount of careful reading at the back fixes the answer.
3More precisely
Turning documents and questions into sets of numbers is called embedding, and the storage that holds those sets and quickly finds the closest ones is called a vector database. Narrowing candidates usually relies on an approximate method rather than checking against everything — a trade that gives up a little accuracy for a lot of speed. Because the whole pipeline depends on which model produced the numbers, swapping that model out means every stored document has to be converted again before search works correctly.
The analogy has a limit. A business-card box's sections are labeled by a person, but semantic search has no labeled sections at all. All that exists is coordinates and distance; anything that looks like a section is really just a cluster of things that happen to sit close together. That makes it hard to explain why a given document floated to the top. Letter search can point to which word matched; meaning search can only say the numbers were close. One more difference: a business-card box files one person per card, but a long document doesn't fit into a single spot — it gets cut into paragraphs, each given its own position. Where those cuts fall can shift the results quite a bit.
4Try it yourself
- Semantris ailearn.space Type a word close in meaning to the one on screen and your score climbs — you feel instantly that it works without matching letters
- Kkomantle (Korean word-guessing game) ailearn.space It tells you a number for how close your guess is to the answer, proof that meaning-distance really gets measured
5Common misconceptions
It's easy to think semantic search understands the question, but actually it only measures how close the question's and a document's positions sit.
It's easy to assume meaning-based search always beats letter search, but actually it stumbles more on searches that need an exact match, like part numbers or names.
It's easy to think adding a document keeps it automatically up to date, but actually editing the document or swapping the model means the stored values have to be recalculated.
7One-line summary
In shortSemantic search finds documents whose meaning-position sits close, instead of documents that share letters with your question.
Spotted an error or have a better analogy? Suggest an edit · Last updated2026-09-02