eDisMax Worked Examples and Tuning in Practice

Configuration

Three queries worked through end to end, and the order in which experienced teams tune eDisMax.

A short query. Two words, both required, title matches worth double.

GET /solr/classicbook/select
  ?q=ancient philosophy
  &defType=edismax
  &qf=title^2 summary^1 content^0.2
  &mm=100%
  &pf=title^5&ps=1

Both terms must appear. A document with “ancient” in the title but no “philosophy” anywhere is not in the result set — no phrase boost can bring it back. Among the documents that do qualify, the ones carrying the exact phrase in the title lead.

A long query. Seven words, where demanding all of them returns nothing.

GET /solr/classicbook/select
  ?q=quantum field theory experiments at low temperatures
  &defType=edismax
  &qf=title^2 summary^1 text_all^0.3
  &mm=2<75% 6<60%
  &pf=title^5&ps=2
  &pf2=title^4&ps2=1
  &pf3=title^3

Seven clauses under 6<60% require four matches, so the result set stays populated. The full phrase almost certainly never occurs, and that is fine: pf2 and pf3 catch “quantum field”, “field theory” and “low temperatures”, and documents holding several of those fragments rise to the top on their own.

A query-time override. Handler defaults are the rule; overrides are for the exception.

GET /solr/classicbook/select
  ?q=renaissance art paintings
  &defType=edismax
  &qf=title^4 summary^2 text_all^0.4
  &pf=title^6&ps=3
  &rows=20
  &sort=score desc, publish_date desc

Anything sent on the request replaces the handler default of the same name for that call only. Sorting by score desc first and a date second keeps relevance in charge while breaking ties in favour of newer material.

Add &debugQuery=true to any of these and read debug.parsedquery. It is the only way to know what your parameters actually produced, and it is how every capture on this page was taken.

02 · Tuning in practice

Put the defaults in the handler

A parameter that lives in solrconfig.xml is a decision made once. A parameter pasted into every client is a decision that drifts.

Move mm before you move boosts

Too many results and too few results are both mm problems. Boosts change order; only mm changes membership.

Start with pf and ps=2, add pf2 when queries get long

Short queries are served by pf alone. Add pf2 once your logs show queries of four words and up.

Resist high slop

Every point of slop makes a phrase match less meaningful. Past four or five the phrase boost stops distinguishing anything.

Match the analyzer to the job

Phrase boosting depends on token positions. A field that strips stopwords holds different positions from one that keeps them, so the same slop behaves differently per field.

Tune against real queries

Pull the actual query log, not the queries you imagine. Zero-result queries point at mm and analysis; low click-through on populated result pages points at boosts.

The eDisMax query parser

Worked examples and tuning in practice (this page)