Apache Solr Reference Guide Covering Apache Solr 6.0

perfect recall is trivial: simply return every document in the collection for every query.
Returning to the examples above, it's important for an e-discovery search application to have 100% recall
returning all the documents that are relevant to a subpoena. It's far less important that a recipe application offer
this degree of precision, however. In some cases, returning too many results in casual contexts could overwhelm
users. In some contexts, returning fewer results that have a higher likelihood of relevance may be the best
approach.
Using the concepts of precision and recall, it's possible to quantify relevance across users and queries for a
collection of documents. A perfect system would have 100% precision and 100% recall for every user and every
query. In other words, it would retrieve all the relevant documents and nothing else. In practical terms, when
talking about precision and recall in real systems, it is common to focus on precision and recall at a certain
number of results, the most common (and useful) being ten results.
Through faceting, query filters, and other search components, a Solr application can be configured with the
flexibility to help users fine-tune their searches in order to return the most relevant results for users. That is, Solr
can be configured to balance precision and recall to meet the needs of a particular user community.
The configuration of a Solr application should take into account:
the needs of the application's various users (which can include ease of use and speed of response, in
addition to strictly informational needs)
the categories that are meaningful to these users in their various contexts (e.g., dates, product categories,
or regions)
any inherent relevance of documents (e.g., it might make sense to ensure that an official product
description or FAQ is always returned near the top of the search results)
whether or not the age of documents matters significantly (in some contexts, the most recent documents
might always be the most important)
Keeping all these factors in mind, it's often helpful in the planning stages of a Solr deployment to sketch out the
types of responses you think the search application should return for sample queries. Once the application is up
and running, you can employ a series of testing methodologies, such as focus groups, in-house testing, TREC te
sts and A/B testing to fine tune the configuration of the application to best meet the needs of its users.
For more information about relevance, see Grant Ingersoll's tech article Debugging Search Application
Relevance Issues which is available on SearchHub.org.
Query Syntax and Parsing
Solr supports several query parsers, offering search application designers great flexibility in controlling how
queries are parsed.
This section explains how to specify the query parser to be used. It also describes the syntax and features
supported by the main query parsers included with Solr and describes some other parsers that may be useful for
particular situations. There are some query parameters common to all Solr parsers; these are discussed in the
section Common Query Parameters.
The parsers discussed in this Guide are:
The Standard Query Parser
The DisMax Query Parser
The Extended DisMax Query Parser
Other Parsers
The query parser plugins are all subclasses of QParserPlugin. If you have custom parsing needs, you may want
to extend that class to create your own query parser.
For more detailed information about the many query parsers available in Solr, see https://wiki.apache.org/solr/So
lrQuerySyntax.
Common Query Parameters
Apache Solr Reference Guide 6.0
244