Semantic Retrieval Debugger
Free online semantic similarity checker. Paste a query and candidate passages, see their embedding similarity ranking with a top-k retrieval line, and compare it against plain keyword overlap - so you can see exactly why a passage was or was not retrieved. Runs entirely in your browser.
Semantic Retrieval Debugger
Free online semantic similarity checker. Paste a query and candidate passages, see their embedding similarity ranking with a top-k retrieval line, and compare it against plain keyword overlap - so you can see exactly why a passage was or was not retrieved. Runs entirely in your browser.
About the semantic retrieval debugger
How it works
An embedding model turns each passage into a vector - a list of numbers that places its meaning as a point in space. Similarity is the cosine of the angle between two vectors, shown here on a 0 to 1 scale: passages about the same thing land close together even when they share no words. The tool embeds your query and every candidate, ranks candidates by their cosine similarity to the query, and draws your top-k line - in a retrieval pipeline, only ranks above that line come back. Word overlap is computed alongside as the share of query words each candidate contains, which is roughly what a keyword search engine would reward.
Why show word overlap next to it
Because the two verdicts disagree in exactly the cases that break retrieval. A passage can share most of the query's words and still mean something else - keyword search picks it, semantic retrieval leaves it outside top-k. Another passage can share no words at all and be the right answer - keyword search misses it, embeddings pull it in. The flags mark both cases, and the evidence view spells out the shared words token by token. The semantic score cannot be broken down the same way: it comes from whole-passage vectors, and the tool says so rather than inventing per-word attributions.
Privacy and honest limits
Queries and passages often contain business data, so nothing leaves the browser: demo mode ships with precomputed constructed vectors, and real mode downloads the model into the browser and runs inference locally - no API calls, no logging. The honest limits: demo numbers are constructed for the walkthrough and labelled as such; the real model is a small English model, so scores for other languages are unreliable; and word overlap is a deliberately simple approximation of keyword search, not a BM25 implementation.
FAQ
Common questions and answers about this topic.
How do I find out why my RAG pipeline is not retrieving a passage?
Paste the user's query as the Query, then paste the passage you expected plus the passages that actually came back as candidates. The ranking shows whether the model really scores your passage below the others, the gap column shows by how much, and the top-k line shows whether it just missed the cut. If it ranks high here but still is not retrieved in production, the problem is elsewhere in the pipeline - chunking, filtering, or a different embedding model.
What does semantic similarity mean?
It is a measure of how close two texts are in meaning, regardless of the words they use. An embedding model maps each text to a vector so that texts about the same thing land near each other; the similarity score is the cosine of the angle between those vectors. That is why “my laptop will not turn on” and “the computer fails to boot” can score high together despite sharing no words - and why it is the measure semantic search and RAG pipelines actually rank by.
How do I read the score - is 0.7 similar enough?
Scores here run from 0 to 1 - higher means closer in meaning. But there is no universal threshold: 0.7 can be a strong match under one model and mediocre under another, because absolute values shift with the model and the kind of text. What transfers across models is the comparison - which candidate ranks first, and how big the gap to the next one is. That is why retrieval pipelines take the top-k by rank instead of everything above a fixed score, and why this tool leads with the ranking rather than the raw numbers.
What is the difference between semantic similarity and keyword search?
Keyword search rewards shared words; semantic similarity rewards shared meaning. They agree most of the time - and the interesting failures live where they do not. A passage full of your query's words that talks about something else is a keyword false positive; a paraphrase with zero shared words is a keyword blind spot. The two bars on every row put both verdicts side by side, and the flags mark exactly these two disagreement cases. Production systems often combine both signals (hybrid search) precisely because each one fails differently.
How does the model know two texts mean the same thing?
Embedding models are trained on enormous numbers of text pairs that humans or data pipelines marked as related - questions with their answers, paraphrases, titles with their articles. Training pushes related pairs' vectors closer and unrelated pairs' vectors apart, so after enough examples the geometry itself encodes meaning: direction and distance in that space reflect what tends to co-occur as “the same topic”. The model has no dictionary of synonyms - closeness is a statistical result of that training, which is also why different models draw slightly different maps and score the same pair differently.
What does this tool cover, and what are its limits?
It scores one query against up to 12 candidate passages, with two demo scenarios and a real-model mode. Demo scores come from constructed vectors built for the walkthrough - clearly labelled, with word overlap, ranking and verdict all running the real code. Real mode downloads a small English embedding model (about 23 MB) into the browser; scores for other languages are unreliable and the tool says so. Word overlap is a deliberately simple keyword-view approximation, not BM25. It does not chunk documents, call any embedding API, or reproduce your production model's exact scores - it shows you the mechanism those systems rank by.