AI from First Principles · Chapter 4 of 10
Embeddings, without the mathematics
The idea behind search, retrieval and most “AI similarity” features.
An embedding turns text into a list of numbers — a point in space — chosen so texts with similar meaning land near each other. “Cancel my subscription” and “how do I stop being billed” land close together despite sharing almost no words.
That is the whole concept. Semantic search, vector search and similarity matching are all: embed the query, find the nearest stored points, return what they came from.
Three things a reviewer needs to know
- Embeddings are not encryption and not anonymisation. Text can be substantially recovered from its embedding, so a vector store holding customer data is a store of customer data with the same classification, retention and access requirements as the source. Treat “it's only vectors” as a finding, not a mitigation.
- The vector store needs access control matching the source. The classic failure: documents access-controlled in SharePoint get embedded into one index every employee can query, and the permission model is silently gone. This is the most common real AI data incident, and it has nothing to do with the model.
- Similar is not relevant. Nearest-neighbour returns the closest thing in the index even when nothing in it is any good. An empty or wrong index does not error — it confidently returns its best bad match.
A question that finds real problems in five minutes
“Show me two users with different permissions asking the assistant the same question.”
If both get the same answer, the permission model did not survive the trip into the index. No tooling required, and it finds a serious issue often enough to be worth making routine.
What they are good at, and where they quietly fail
An embedding turns a piece of text into a list of numbers positioned so that similar meanings sit near each other. That one property gives you search that works on meaning rather than spelling — and it also gives you a set of failure modes that are easy to miss because the system never errors.
| Works well for | Fails quietly at |
|---|---|
| Finding documents about the same topic when the words differ | Negation. 'The contract permits assignment' and 'the contract does not permit assignment' sit very close together |
| Grouping and deduplicating similar items | Precise identifiers. Part numbers, case IDs and version strings — nearby in meaning, wrong in fact |
| Recommendation and 'more like this' | Numbers and dates. 'Under £500' and 'over £500' are semantically similar and operationally opposite |
| Routing a question to the right area of a corpus | Rare, domain-specific vocabulary the embedding model saw little of in training |
| Cheap first-pass filtering before something more expensive | Anything where being approximately right is being wrong |
The pattern in the failures is consistent: embeddings capture aboutness. Two sentences about the same subject are close together even when they assert opposite things about it. That is exactly what you want for ‘find me documents on this topic’ and exactly what you do not want for ‘does this contract permit X’.
Why hybrid search is the default in serious systems
Because the two search methods fail in opposite directions, which is the ideal property for a combination.
Keyword search is exact and literal: it will find the part number and miss the document that describes the same thing in different words.
Embedding search is semantic and fuzzy: it will find the paraphrase and rank a near-miss part number just as highly as the right one.
Run both, merge the rankings, and the combination is meaningfully better than either — which is why nearly every production retrieval system does it, and why a system built on embeddings alone usually has a class of query it fails on that nobody has characterised.
The diagnostic question for a vendor: “what happens if I search for an exact identifier that appears in one document?” If the answer is not immediate and confident, the system is embeddings-only.
Check yourself