Spell checking, suggestions & similar documents

DirectSolrSpellChecker is the default and recommended implementation: it compares query terms against the main index’s term dictionary directly, with no separate sidecar index to build or keep in sync, so suggestions are always as fresh as the index itself. Its main tuning knobs are maxEdits (the maximum Damerau-Levenshtein edit distance considered, 1 or 2), minPrefix (how many leading characters must match exactly, which both narrows candidates and speeds the lookup), and maxQueryFrequency (a document-frequency ceiling, absolute or a fraction of the index, above which a term is assumed already correct and not corrected against).

WordBreakSolrSpellChecker handles a different class of typo: words run together or split apart, by combining adjacent query terms and/or breaking a single term into two. combineWords and breakWords (both true by default) toggle each direction; maxChanges caps how many word breaks or combinations one suggestion may apply, and breakSuggestionTieBreaker (MAX_FREQ, MIN_FREQ, MAX_FREQ_PROD) picks which candidate wins when several break the same way. It is normally registered alongside DirectSolrSpellChecker under the same request handler so both run together.

A per-token correction list is often not directly usable — the caller wants one corrected query to re-run, not a menu of independent suggestions. spellcheck.collate=true asks Solr to assemble the individual token corrections back into one query string that is verified to actually return hits before being returned; spellcheck.maxCollationTries bounds how many candidate collations are tried, and spellcheck.collateExtendedResults=true returns, per collation, which original term each correction replaced. spellcheck.alternativeTermCount also asks for corrections on terms that already match something, useful for a "Showing results for X. Search instead for Y?" experience even when the original query was not a hard miss. spellcheck.build=true (re)builds the underlying dictionary; for DirectSolrSpellChecker that build step is cheap since it reads the live index rather than materializing a copy.

lookupImpl chooses the in-memory data structure and, with it, what kind of match the suggester can serve:

A suggester’s dictionary must be built before it can answer anything, either explicitly with suggest.build=true, on a schedule via buildOnStartup / buildOnCommit in its solrconfig.xml definition, or by calling suggest.reload=true to restore a previously built structure from disk without recomputing it.

suggest.dictionary may repeat to query several suggesters in one call and merge their results; suggest.cfq supplies a context-filter value for a suggester whose dictionary declared a contextField, scoping suggestions to, say, only one product category. Because the suggester is a separate structure from the main index, it is a much lower-latency path than running the equivalent prefix query through the standard request handler — the tradeoff is a build step to keep it in sync.

An analyzer-based alternative — an edge_ngram token filter feeding a plain text field, matched with an ordinary query at request time — is covered in Text analysis; it needs no separate build step and composes with normal filtering/faceting, at the cost of enlarging the index and the flexibility the dedicated lookups above trade away.

The MoreLikeThisHandler is a dedicated request handler (conventionally mounted at /mlt) that takes either a document q selects or raw content posted as a stream, and returns similar documents directly as the main response — the source document’s own match, if any, is not what the caller wants back.

The MoreLikeThisComponent instead attaches to an ordinary /select request (mlt=true) and adds a moreLikeThis section to the response with, for each hit in the main result list, its own set of similar documents — the right shape for a "customers who viewed this also viewed…​" list rendered alongside a normal search results page, rather than a single lookup.

\{!mlt qf=<fields>}<id> embeds the same similarity logic as a query clause — the counterpart to the two request-level forms above, usable anywhere a query fragment can appear (fq, bq, a sub-query) so "similar to this document" composes with ordinary filtering, boosting, and paging instead of living in a dedicated response section.

A feature store is a named, versioned collection of feature definitions — each one a value computed per document per query, such as a stored field’s value, a function query result, or a query’s match score/count against the document (SolrFeature). Features within one store must have unique names; the same name can be reused across different stores for, say, an A/B-tested feature set. Feature definitions are uploaded as JSON to a REST endpoint, independent of the schema or solrconfig.xml.

A feature’s params can also reference external feature info (efi.*) supplied at query time — the user’s location, session context, or anything not derivable from the document alone — through a $\{efi.name} placeholder, letting the same trained model take request-specific signals into account.

A model is a JSON document naming a feature store plus the trained weights/structure that turn a feature vector into a single re-rank score, uploaded to the model store the same way. Solr ships LinearModel (a weighted sum, for models like logistic regression), MultipleAdditiveTreesModel (gradient-boosted trees, e.g. LambdaMART, expressed as an ensemble of decision trees), and NeuralNetworkModel; a custom model class can be plugged in for anything else.

Once a model is stored, rq=\{!ltr model=<name> reRankDocs=<n>} re-ranks the top reRankDocs matches from q using that model — \{!ltr} behaves like \{!rerank} internally (it re-scores a bounded top-N rather than the whole result set) so the two are not normally combined for the same request. Any efi.* parameters the model’s features reference are passed alongside it.

The [features] document transformer (added to fl in square brackets, like any other transformer) returns each returned document’s raw feature values instead of, or alongside, the model’s final score — essential for logging training data for the next offline training run, and for debugging why a model ranked a document where it did. logAll=true logs every feature in the named store rather than only the ones the active model uses; format=dense (default) or sparse controls how zero/absent values are represented.

Feature selection, labelling, and model training all happen outside Solr; only the trained model and its feature definitions come back in. A typical cycle logs features for production traffic with [features], trains a new model offline against click or judgment data, and uploads the result to the model store to replace the active model — Solr itself never re-trains anything.