Home / Search evaluation / How to Evaluate Semantic Search Quality

How to Evaluate Semantic Search Quality

Evaluating semantic search means running a fixed set of real queries against the system, judging which results are relevant, and scoring the ranked lists with metrics such as recall, precision, MRR, and nDCG. The judgments are the hard part. They can come from people, from click logs, or from a language model checked against people. The metrics then turn those judgments into numbers that can be compared across models, settings, and releases. A fair comparison holds everything else constant: the same documents, filters, result depth, and a keyword baseline. Evaluation does not end at launch. The same test set should run on every change, so a regression shows up as a falling score before users notice. Similarity scores from the search engine itself are not evaluation, because a nearest result always exists.

What does it mean to evaluate semantic search?

Evaluating semantic search means measuring whether the system returns relevant results for the queries its users actually send, in the order they need them. It answers a question that demos cannot. A few good-looking examples say nothing about the hundreds of queries nobody tried.

Evaluation comes in two broad kinds. Offline evaluation runs a fixed test set and computes metrics from relevance judgments. Online evaluation watches real traffic: clicks, reformulated queries, and abandoned searches. Offline evaluation is repeatable and safe. Online evaluation reflects real behavior but arrives later and mixes in other causes. A sound program uses both.

It also helps to know what is being measured. A semantic search system has stages, from chunking and embedding to retrieval and ranking. The semantic search pipeline shows each one. End-to-end metrics say whether the final list is good. Stage-level checks say why it is not.

The same thinking answers a broader question: how to evaluate a search engine of any kind. Collect real queries, judge results, score them, and compare against a baseline. The method is old. What changes with semantic search is how relevance can be missed, and how judgments can be produced at scale.

Everything in the loop starts with the test set.

How do you build a test set of queries and relevance judgments?

A test set is built by sampling real queries, retrieving candidate results for each, and labeling which results are relevant, ideally on a graded scale. The search test sets and relevance judgments guide covers the process in depth.

The steps are straightforward:

1. Sample queries from logs, covering frequent, rare, and difficult cases.
2. Pool candidate results from several systems so the labels are not biased toward one.
3. Grade each candidate on one written scale, such as 0 for irrelevant to 3 for perfect.
4. Freeze the set and its document collection so later runs compare like with like.

Two query sets work better than one. Zheng and colleagues at LinkedIn describe a golden set of top and topical queries that stays stable, and an open set of trending, newsy, and random queries that changes. The golden set tracks progress. The open set catches new failure types.

Size matters less than fit. Weaviate’s evaluation course notes that even 20 objects with several queries can give meaningful results if they reflect the real task, its difficulty, and its data. It also warns to use one grading scale everywhere, because nDCG’s gain doubles with each grade. Labeling is the expensive part. Weaviate’s RAG evaluation article notes that one query may need 100 documents judged, which is why click logs are often used as weak labels: a clicked result is probably relevant. Labels feed the metrics.

Which metrics are used to measure semantic search quality?

The metrics used to measure semantic search quality are recall@K, precision@K, mean reciprocal rank, and nDCG@K, each scoring the top K results in a different way. Weaviate’s metrics overview notes that all of them range from 0 to 1, and that the “@K” means only the top K results count. The information retrieval metrics guide defines each in full.

The table separates counting from ordering. Recall and precision only count relevant items. MRR and nDCG also care where they appear. nDCG comes from Järvelin and Kekäläinen’s 2002 work on cumulated gain, which added graded relevance and a discount for lower positions. Weaviate’s metrics overview calls nDCG@K highly popular for retrieval systems.

The calculator shows how the same five results score differently on each metric. Change a grade and watch which numbers move.

That is the practical lesson: report at least one counting metric and one ordering metric. Comparing systems with them needs a fair setup.

How do you compare two semantic search systems fairly?

Two semantic search systems are compared fairly by running both on the same documents, queries, judgments, filters, and result depth, with a keyword baseline beside them. Change one thing at a time. If the corpus, chunking, and model all change together, a better score cannot be explained.

The keyword baseline earns its place. Thakur and colleagues’ BEIR benchmark found BM25 a robust baseline across 18 datasets. A new semantic system that cannot beat a tuned BM25 configuration on the test set has not yet justified its cost. A hybrid configuration belongs in the comparison too.

Weaviate’s evaluation course adds practical controls: test models under identical conditions, record model versions and parameters, and structure code so new candidates can be added later. It also recommends reading failures, not only scores. Its listed patterns include favoring longer documents over short relevant ones, mishandling negation, weak domain terminology, and uneven performance across languages.

Segment the results. Averages hide trade-offs. A model can win on paraphrased questions and lose on product codes, and only a segmented report shows that. This also answers which AI model is best for semantic search: no model is best everywhere. Weaviate’s course example shortlists models by public benchmark scores, then picks between them on a custom benchmark built from the team’s own content. Retrieval benchmarks covers the public ones. Judging enough results by hand is slow, which is why language models are now used as judges.

Can a language model judge search relevance?

A language model can judge search relevance well enough to scale evaluation, provided its judgments are first checked against human labels. It turns a labeling bottleneck into a prompt.

LinkedIn’s study gives concrete numbers. Zheng and colleagues used GPT-3.5 to decide whether each result was on topic for a query, then computed an On-Topic Rate over the top 10 results. Their prompt reached 94.5 percent accuracy on a 600 query-post validation set. Against 10 human annotators with search expertise, the pipeline was 81.72 percent consistent.

Weaviate’s RAG evaluation article describes the same approach for general search. A prompt can ask how many results are relevant, which estimates precision. Another can ask whether the results contain everything needed to answer, which approximates recall. A third can compare two result sets and pick the better one.

The caution is in the LinkedIn numbers themselves. Agreement near 82 percent means roughly one judgment in five differs from a human. Calibrate the judge on a human-labeled sample, keep the prompt fixed between runs, and record the model version. Spot-check disagreements. Used that way, an LLM judge makes frequent evaluation affordable. It is also the basis for evaluating retrieval inside RAG systems.

How do you evaluate retrieval in a RAG pipeline?

Retrieval in a RAG pipeline is evaluated separately from the generated answer, with metrics such as context precision and context recall alongside the classic ranking metrics. A wrong answer can come from bad retrieval or from a model that ignored good evidence. Separate scores show which.

Ragas, introduced by Es and colleagues in 2023, made this approach common. Its metrics cover whether retrieval finds relevant and focused context, whether the generator uses that context faithfully, and the quality of the answer, without requiring human reference labels. Weaviate’s retrieval quality article defines context precision as the share of retrieved chunks that are relevant and context recall as the share of needed information present in the retrieved set.

Both views matter. Low context precision means noise is entering the model’s context window. Low context recall means the model must fall back on what it memorized, which invites invented answers. Faithfulness then checks whether the answer is supported by what was retrieved. Semantic search in RAG covers the retrieval side of that pipeline.

For RAG, recall at the context depth usually matters most. A passage the retriever never returns cannot ground the answer, however capable the model is. Recall has a second meaning, though, that is easy to confuse with this one.

How is ANN recall different from search relevance?

ANN recall measures how many of the true nearest vectors an approximate index returns, while search relevance measures whether returned results actually answer the query. Weaviate’s RAG evaluation article draws the line clearly. Index recall compares the approximate index with brute-force search. Information-retrieval recall compares results with relevance judgments.

The two can disagree. An index can return all of its true nearest neighbors, with perfect ANN recall, and still return irrelevant results if the embedding model places the wrong documents nearby. An index can also skip a few true neighbors and lose a relevant document that would have been found by exact search.

Measure them separately. ANN recall is checked by running exact search on a sample of queries and counting overlap with the approximate results. Relevance is checked with the test set. When results disappoint, the comparison shows where to look. High ANN recall with low relevance points at the model or chunking. Low ANN recall points at index settings. Relevance versus recall and why vector search returns irrelevant results cover the diagnosis in detail. Diagnosis matters most after launch, when changes keep coming.

How do you catch quality regressions after launch?

Quality regressions are caught by rerunning the frozen test set on every change and by watching online signals for drift. Weaviate’s retrieval quality article recommends running retrieval evaluation alongside continuous integration so quality becomes a tracked, comparable number rather than a one-time audit.

Offline checks catch what a change breaks. Any new embedding model, chunking rule, index setting, or ranking change should rerun the test set and fail the build if key metrics fall past an agreed threshold. The golden set makes the comparison stable.

Online signals catch what the test set misses. Rising zero-result rates, more reformulated queries, and falling clicks on top results all suggest a problem. New content and new kinds of queries appear constantly, so the open query set should be refreshed from recent traffic. Online search metrics and analytics and monitoring search quality in production cover the dashboards. For a quick sense of what good semantic search looks like before any of this, what semantic search is gives worked examples, and semantic search use cases covers questions such as whether ChatGPT uses it.

Evaluating semantic search means running real queries, judging which results are relevant, and scoring the ranked lists with recall, precision, MRR, and nDCG. Judgments come from people, clicks, or a language model calibrated against people. Fair comparison holds the corpus, filters, and depth constant and includes a keyword baseline. RAG adds context precision, context recall, and faithfulness, and ANN recall is a separate index check. The decision is to build a small frozen test set now, report one counting and one ordering metric, and rerun it on every change so quality never drifts unseen.