How to Diagnose Bad Search Quality

How to Diagnose Bad Search Quality

Before diagnosing or evaluating search quality, establish two different ground truths: a labeled query set measures whether the results are the right ones; exact KNN measures whether ANN finds what brute force would (no labels needed). The first diagnoses relevance, the second diagnoses the index.

Need a Labeled Baseline to Score Quality or Validate a Gain

Use when: user has no golden set, asks "how do I know if my search is good?", or needs to gate releases on a retrieval metric. Every fix in the sections below should be validated this way.

• Pick the metric by usage: Recall@k for RAG, MRR/Hits@1 for single-answer, NDCG@k for re-ranking Choosing the metric
• Build a labeled query set (human, log-based, or LLM-synthetic) and score retrieval with ranx Measuring Retrieval Relevance
• When tuning and evaluating search quality, set a minimum target gain, then make sure your labeled query set is large enough to measure it reliably. Quantify the uncertainty around a measured gain with a confidence interval (e.g. bootstrap the per-query gains, 95%): if it includes zero, the improvement is inconclusive and may be due to query-to-query variation. Adding labeled queries narrows the interval; how many you need depends on the size of the gain you are targeting and on query-to-query variation, not on collection size Before tuning a collection
• If you use the labeled queries to tune or select a configuration, evaluate the final choice on held-out queries. A gain that doesn't survive the held-out evaluation isn't reliable evidence of an improvement.
• For full RAG pipelines, also score generation with Ragas and use the retrieval-vs-generation 2x2 to isolate regressions Pipeline Output Quality
• Gate CI on a per-metric threshold to catch regressions from embedding-model swaps, prompt changes, or index config changes

Don't Know What's Wrong Yet

Use when: results are irrelevant or missing expected matches and you need to isolate the cause.

• For a no-code quick check, use the Web UI's ANN Recall tab to compare approximate vs exact recall@k Web UI ANN Recall
• For the same comparison in code (CI gating, regression tests), run each query twice: once approximate, once with exact=true. Compute recall@k from the overlap ANN recall in CI
• Target >95% recall@k in production. Exact search bad = model, data, or search pipeline problem. Exact good, approximate bad = tune HNSW.
• Match the embedding model to your data: the context window should fit your chunk length with room for special tokens, the model must cover every language in your corpus, and its training domain should resemble yours (e.g. a code-trained model for code) How to choose an embedding model
• Make sure documents are properly chunked; splitting chunks mid-sentence alone can drop quality by 30-40%
• Check if quantization degrades quality (compare with and without)
• Check if filters are too restrictive (then you might need to use ACORN)
• If duplicate results from chunked documents, use Grouping API to deduplicate Grouping

Payload filtering and sparse vector search are different things. Metadata (dates, categories, tags) goes in payload for filtering. Text content goes in sparse vectors for search.

Approximate Search Worse Than Exact

Use when: exact search returns good results but HNSW approximation misses them.

• hnsw_ef controls ANN search breadth; increase it while recall is still climbing, stop at the lowest value that hits your recall target inside your latency budget Search params Raise hnsw_ef only when recall is still climbing
• Increase ef_construct (200+ for high quality) HNSW config
• Increase m (16 default, 32 for high recall) HNSW config
• Enable oversampling + rescore with quantization Search with quantization
• ACORN for filtered queries (v1.16+) ACORN