Relevance & scoring

Older Solr versions (luceneMatchVersion below 6.0) scored with ClassicSimilarity — a vector- space TF/IDF model where term frequency contributes roughly as sqrt(freq) and never saturates: the hundredth occurrence of a term in a field still keeps adding to the score. BM25Similarity is Solr’s current default similarity, in effect since Solr 6 (any collection with luceneMatchVersion 6.0 or higher uses it unless a Similarity is configured otherwise) — ClassicSimilarity/TF-IDF was the old default before Solr 6, and is no longer what a modern collection uses out of the box. BM25 keeps the same two intuitions — term frequency and inverse document frequency — but saturates term frequency so extra occurrences matter less and less, and normalises for field length so a match in a short field is not diluted the way it is under classic TF/IDF. See Major Changes in Solr 6 for the version cutover and Schema Elements (the Similarity section) for how a collection’s active similarity is determined.

BM25 exposes two tunables on the field type’s similarity: k1 (default 1.2) controls how quickly term-frequency saturates, and b (default 0.75) controls how strongly field length is normalised — b=0 disables length normalisation entirely.

debug=results (or the legacy debugQuery=true, equivalent to debug=all) attaches an explain block to every hit, breaking its score down term by term — the same idf, tf and length-normalisation factors BM25 multiplied together. explainOther runs that same explanation against a second Lucene query, so you can compare why a document you expected to rank highly scored lower than the documents that actually came back. See Common Query Parameters (the debug and explainOther sections).

debug=query and debug=timing narrow the output to just the parsed query or just the phase timings when the full per-document explanation is not needed.

The Query Elevation Component lets an editor force specific documents to the top of the results for a specific query string, independent of what BM25 would otherwise compute — the standard way to implement "sponsored" or "best bets" results, or to hand-correct a query that relevance tuning alone does not fix. Elevated (and excluded) document IDs are declared per query string in an elevate.xml file referenced from the component’s solrconfig.xml configuration; enableElevation, forceElevation and exclusive control its behaviour at request time, and elevateIds/excludeIds can override the file for a single request. See Query Elevation Component.

For re-ranking the top N results with a second, costlier query — rather than pinning specific documents by ID — see the rq/ReRank coverage on Spell checking, suggestions & similar documents, which also covers Learning To Rank.

Every relevance decision above — which similarity, which boosts, how aggressively to elevate or re-rank — ultimately trades off precision (what fraction of the returned results are relevant) against recall (what fraction of all relevant documents in the collection were returned). A legal e-discovery search wants recall near 100% even at the cost of precision; a product search’s first page wants high precision and can afford to miss a few borderline matches. Query structure choices covered elsewhere on this site — minimum_should_match-style clause requirements, fuzzy and wildcard matching, synonym expansion — shift that balance as much as scoring does. See Relevance for the conceptual overview this page’s scoring mechanics implement.