A 0.85 cosine score is relative, not calibrated. It ranks this chunk against others for this query; it is not an 85% probability of relevance, and is meaningless across models.
Imagine a race where everyone gets a number for how close they finished to the winner. A 0.85 just means this runner came in ahead of the ones who got 0.84 or 0.83 in that one race. It does not mean they ran well, or that they had an 85 percent chance of winning. Now run the race on a different track, with a different judge who measures distances differently. The exact same runner gets a totally different number, because the scale itself changed. So the number is great for putting runners in order within one race. But you can never read it as a grade like 'this runner is 85 percent good,' and you can never compare a number from one race to a number from another. To know who actually performed well, you need a separate, fair judge.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Almost every dense retriever hands you a similarity score next to each chunk, and almost every newcomer reaches for the same instinct: a 0.85 looks high, so let me keep everything above 0.7 and treat the number as confidence. That instinct is wrong, and interviewers probe it deliberately because it reveals whether you understand what an embedding space actually is. The question is a small trap with a large payoff: get it right and you signal that you have actually debugged a retrieval pipeline, not just wired one together from a tutorial.
The short version is that cosine similarity is a relative ranking signal, not an absolute, calibrated measure of relevance. It tells you how one chunk compares to other chunks for one query inside one model's geometry. It does not tell you the probability that the chunk answers the question, and it does not transfer to a different model.
This section unpacks the geometry behind the number, why the value is uncalibrated, the two failure modes that follow directly from that fact, and the production playbook that replaces a magic threshold with something defensible. By the end you should be able to explain not just that thresholding on raw cosine is wrong, but precisely why and what to do instead.
What cosine similarity actually computes
Cosine similarity measures the angle between two vectors, ignoring their magnitudes. You normalize both to unit length and take their dot product, which is the cosine of the angle between them.
The denominator divides out both vectors' lengths, so only direction survives. The output is bounded between -1 and 1, but trained embeddings are anisotropic (they cluster in a narrow cone), so real query-chunk pairs rarely span that full range and instead land in a compressed high band, often 0.6 to 0.9. A value of 1 means the vectors point in identical directions; 0 means they are orthogonal. A higher value means the two embeddings point in more similar directions.
That is the entire semantics: direction agreement. Nothing in this definition references relevance, ground truth, or probability. The model was trained so that semantically related texts land near each other, but the raw number that falls out is just geometry, not a graded judgment of usefulness. Crucially, the score is computed without any knowledge of what counts as a 'good' answer; it never saw your relevance labels, so it cannot encode them. Treating its output as a probability is reading meaning into a number that was never asked to carry it.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
# BAD: absolute threshold treated as calibrated confidence
hits = index.query(qvec, top_k=20)
good = [h for h in hits if h.score > 0.7] # breaks per query / per model
# BETTER: rank with cosine, then judge relevance with a reranker
hits = index.query(qvec, top_k=50) # cosine = candidate generation
ranked = reranker.rerank(query, [h.text for h in hits])
good = [r for r in ranked if r.relevance_score > 0.5] # calibrated signal| Property | Raw cosine score | Reranker / calibrated score |
|---|---|---|
| Meaning | Relative rank in this space | Estimate of actual relevance |
| Comparable across models | No, different vector spaces | Closer, trained for relevance |
| Safe to threshold globally | No, distribution shifts per query | More defensible with eval set |
| Cost | Cheap, one dot product | Higher, cross-encoder per pair |
Real products, models, and research that use this idea.
- Pinecone and Weaviate return raw similarity scores that teams wrongly threshold globally; vendor docs in 2026 explicitly warn the values are not calibrated probabilities.
- Cohere Rerank 3.5 is sold precisely as the calibrated relevance layer to put after dense retrieval instead of trusting raw cosine.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you build a defensible accept/reject gate for retrieved chunks if cosine isn't calibrated?
Add a cross-encoder reranker and threshold on its score, or calibrate a per-model cosine cutoff against a labeled eval set; validate with context precision and recall.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Hard-coding an absolute cosine threshold like 'keep chunks > 0.7' across all queries, then treating the surviving score as a calibrated probability of relevance.
60 second bullets to scan on the way to the call.
Why cosine similarity is relative, not an absolute probability
What the 0.85 value actually compares against
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.