Search relevance is the discipline of ranking results so users see what they meant, not just what matched their tokens.
In-app search is often shipped as a checkbox — 'add a search bar, wire it to Elasticsearch, done' — and quickly becomes a top user complaint. The problem is rarely the search engine; it's that lexical matching alone doesn't reflect what users mean. 'Sneakers' should match 'trainers'; 'blue running shoes' should rank differently than 'shoes'; a user who has bought Nike five times probably wants to see Nike results boosted. Search relevance is the systematic work of closing the gap between query and intent. It's part information retrieval, part product design, and increasingly part ML.
BM25 (default in Elasticsearch, OpenSearch, Solr) scores documents by term frequency and inverse document frequency, discounted by document length. It's a strong, well-understood baseline — do not skip past it. Tune before replacing: adjust `k1` (term saturation) and `b` (length normalization); apply field boosts (title matches beat body matches by 3-5x); use edge n-grams for partial matches; enable synonyms via curated dictionaries. A tuned BM25 setup handles most e-commerce and content search adequately. Where it breaks: semantic gaps (query and document use different words for the same concept) and long conversational queries.
Synonyms: curated (a maintained list mapping 'jumper' → 'sweater') or learned (from query-click logs). Curated works better for specialized domains where wrong mappings cause obvious errors; learned works better at scale where curation can't keep up. Spelling correction: use a Levenshtein-distance-based suggester (Elasticsearch's `suggest` API) with a threshold that rejects overly aggressive corrections. Query understanding: detect intent (navigational, transactional, informational), extract entities (brand, category, size), route accordingly. A query like 'Nike size 10 running' should decompose into brand=Nike, size=10, category=running-shoes, not be dumped into full-text search.
Semantic (vector) search embeds queries and documents into a shared vector space so similarity captures meaning, not tokens. Excellent for semantic gaps and conversational queries; weak on exact-match cases (SKU numbers, proper nouns, jargon). Hybrid retrieval combines both: run BM25 and vector search in parallel, merge results via Reciprocal Rank Fusion (RRF) or a learned re-ranker. Modern search engines (Elasticsearch 8+, OpenSearch, Vespa, Qdrant, Weaviate) support hybrid natively. Default to hybrid for new deployments; the BM25 leg catches what vectors miss and vice versa.
LTR trains a model on labeled query-document pairs (or click logs as implicit labels) to score results better than any hand-tuned formula. Typical setup: retrieve top 100 with BM25 or hybrid, re-rank with a gradient-boosted tree (LambdaMART is the classic) or a neural cross-encoder using features like BM25 score, vector similarity, personalization signals, freshness, popularity. LTR is heavy machinery — pays off when you have >100K searches/day and either a query analyst or an ML team to maintain it. Below that, spend the effort on synonyms and query understanding instead.
Offline: build a judgment set (500-2000 queries with human-labeled relevant results), measure NDCG@10 or MRR before/after each change. Automate this in CI so ranking regressions surface before deploy. Online: A/B test on click-through rate, click-to-purchase, session success (did the user find what they searched for), zero-result rate. Track these per query segment (head, torso, tail; new users vs. returning) — a change that improves head queries can silently hurt long-tail. Iteration cadence: relevance engineering is continuous; expect an ongoing 20-40% engineering allocation for any serious search product.
Investor directory · Fundraising library · Articles A–Z · Company funding database