Embedding search (semantic search) finds the most relevant items in a collection by comparing embedding vectors — embed the query, compare it against stored vectors, return the closest matches.
The Full Flow
SETUP (done once, or whenever content changes):
For each document in your collection:
embedding = embed(document.text)
store(document.id, embedding)
AT SEARCH TIME (for every query):
query_embedding = embed(user_query)
results = find_most_similar(query_embedding, stored_embeddings, top_k=5)
return results # the 5 most semantically similar documentsThis exact flow is the foundation of the retrieval step in RAG — everything covered here applies directly there.
A Simplified Implementation (Small Scale)
def semantic_search(query, documents_with_embeddings, top_k=5):
query_vec = embed(query)
scored = [
(doc, cosine_similarity(query_vec, doc.embedding))
for doc in documents_with_embeddings
]
scored.sort(key=lambda x: x[1], reverse=True)
return scored[:top_k]This brute-force approach (comparing against every stored vector) works fine for a small collection but doesn't scale efficiently to millions of documents — that's what vector databases and approximate nearest neighbor search solve.
What "Relevant" Actually Means Here
Embedding search returns items ranked by semantic similarity to the query — this is not the same as "the correct answer" or "the most useful result" in every case. A highly similar document might still not actually answer the user's specific question (see the limitation discussed in Semantic Similarity), which is why evaluation of actual retrieval quality (see RAG Evaluation) matters, not just trusting similarity scores blindly.
Practical Use Case
Documentation search, FAQ matching, product discovery ("find items similar to this one"), and RAG retrieval are all built on this same core pattern — embed once, compare at query time, return top matches.
Common Mistakes
- Using brute-force comparison against every stored vector at real scale (hundreds of thousands+ documents), causing unacceptably slow search — see Approximate Nearest Neighbor for the scalable alternative
- Not filtering or combining with keyword/metadata matching when exact terms genuinely matter — see Hybrid Search
- Trusting the top similarity score as automatically "the right answer" without any relevance evaluation
Interview Relevance
"Walk me through how semantic search actually works, end to end" — embedding both the query and the stored content, comparing vectors, and ranking by similarity is the expected complete answer.
Practice Question
Design the setup and search-time flow for a semantic search feature over a company's 2,000 internal wiki pages.
