OpenSearch/docs/reference/search/request/highlighting.asciidoc

[[search-request-highlighting]]
=== Highlighting

Highlighters allow you to produce highlighted snippets from one or more fields
in your search results.
The following is an example of the search request body:

[source,js]
--------------------------------------------------
GET /_search
{
    "query" : {
        "match": { "content": "kimchy" }
    },
    "highlight" : {
        "fields" : {
            "comment" : {}
        }
    }
}
--------------------------------------------------
// CONSOLE
// TEST[setup:twitter]

In the above case, the `comment` field will be highlighted for each
search hit (there will be another element in each search hit, called
`highlight`, which includes the highlighted fields and the highlighted
fragments).

[NOTE]
==================================
In order to perform highlighting, the actual content of the field is
required. If the field in question is stored (has `store` set to `true`
in the mapping) it will be used, otherwise, the actual `_source` will
be loaded and the relevant field will be extracted from it.

The `_all` field cannot be extracted from `_source`, so it can only
be used for highlighting if it mapped to have `store` set to `true`.
==================================

The field name supports wildcard notation. For example, using `comment_*`
will cause all <<text,text>> and <<keyword,keyword>> fields (and <<string,string>>
from versions before 5.0) that match the expression to be highlighted.
Note that all other fields will not be highlighted. If you use a custom mapper and want to
highlight on a field anyway, you have to provide the field name explicitly.

[[unified-highlighter]]
==== Unified Highlighter

The unified highlighter (which is used by default if no highlighter type is specified)
uses the Lucene Unified Highlighter.
This highlighter breaks the text into sentences and scores individual sentences as
if they were documents in this corpus, using the BM25 algorithm.
It also supports accurate phrase and multi-term (fuzzy, prefix, regex) highlighting.

===== Offsets Strategy

In order to create meaningful search snippets from the terms being queried,
a highlighter needs to know the start and end character offsets of each word
in the original text.
These offsets can be obtained from:

* The postings list (fields mapped as "index_options": "offsets").
* Term vectors (fields mapped as "term_vectors": "with_positions_offsets").
* The original field, by reanalysing the text on-the-fly.

====== Plain highlighting

This mode is picked when there is no other alternative.
It creates a tiny in-memory index and re-runs the original query criteria through
Lucene's query execution planner to get access to low-level match information on the current document.
This is repeated for every field and every document that needs highlighting.

====== Postings

If `index_options` is set to `offsets` in the mapping the `unified` highlighter
will use this information to highlight documents without re-analyzing the text.
It re-runs the original query directly on the postings and extracts the matching offsets
directly from the index limiting the collection to the highlighted documents.
This mode is faster on large fields since it doesn't require to reanalyze the text to be highlighted
and requires less disk space than term_vectors, needed for the fast vector
highlighting.

Here is an example of setting the `comment` field in the index mapping to allow for
highlighting using the postings:

[source,js]
--------------------------------------------------
PUT /example
{
  "mappings": {
    "doc" : {
      "properties": {
        "comment" : {
          "type": "text",
          "index_options" : "offsets"
        }
      }
    }
  }
}
--------------------------------------------------
// CONSOLE

====== Term Vectors

If `term_vector` information is provided by setting `term_vector` to
`with_positions_offsets` in the mapping then the `unified` highlighter
will automatically use the `term_vector` to highlight the field.
The `term_vector` highlighting is faster to highlight multi-term queries like
`prefix` or `wildcard` because it can access the dictionary of term for each document
but it is also usually more costly than using the `postings` directly.

Here is an example of setting the `comment` field to allow for
highlighting using the `term_vectors` (this will cause the index to be bigger):

[source,js]
--------------------------------------------------
PUT /example
{
  "mappings": {
    "doc" : {
      "properties": {
        "comment" : {
          "type": "text",
          "term_vector" : "with_positions_offsets"
        }
      }
    }
  }
}
--------------------------------------------------
// CONSOLE

[[plain-highlighter]]
==== Plain highlighter

This highlighter of type `plain` uses the standard Lucene highlighter.
It tries hard to reflect the query matching logic in terms of understanding word importance and any word positioning criteria in phrase queries.

[WARNING]
If you want to highlight a lot of fields in a lot of documents with complex queries this highlighter will not be fast.
In its efforts to accurately reflect query logic it creates a tiny in-memory index and re-runs the original query criteria through
Lucene's query execution planner to get access to low-level match information on the current document.
This is repeated for every field and every document that needs highlighting. If this presents a performance issue in your system consider using an alternative highlighter.

[[fast-vector-highlighter]]
==== Fast vector highlighter

This highlighter of type `fvh` uses the Lucene Fast Vector highlighter.
This highlighter can be used on fields with `term_vector` set to
`with_positions_offsets` in the mapping.
The fast vector highlighter:

* Is faster especially for large fields (> `1MB`)
* Can be customized with `boundary_scanner` (see <<boundary-scanners,below>>)
* Requires setting `term_vector` to `with_positions_offsets` which
  increases the size of the index
* Can combine matches from multiple fields into one result.  See
  `matched_fields`
* Can assign different weights to matches at different positions allowing
  for things like phrase matches being sorted above term matches when
  highlighting a Boosting Query that boosts phrase matches over term matches

Here is an example of setting the `comment` field to allow for
highlighting using the fast vector highlighter on it (this will cause
the index to be bigger):

[source,js]
--------------------------------------------------
PUT /example
{
  "mappings": {
    "doc" : {
      "properties": {
        "comment" : {
          "type": "text",
          "term_vector" : "with_positions_offsets"
        }
      }
    }
  }
}
--------------------------------------------------
// CONSOLE

==== Force highlighter type

The `type` field allows to force a specific highlighter type.
The allowed values are: `unified`, `plain` and `fvh`.
The following is an example that forces the use of the plain highlighter:

[source,js]
--------------------------------------------------
GET /_search
{
    "query" : {
        "match": { "user": "kimchy" }
    },
    "highlight" : {
        "fields" : {
            "comment" : {"type" : "plain"}
        }
    }
}
--------------------------------------------------
// CONSOLE
// TEST[setup:twitter]

==== Force highlighting on source

Forces the highlighting to highlight fields based on the source even if fields are
stored separately. Defaults to `false`.

[source,js]
--------------------------------------------------
GET /_search
{
    "query" : {
        "match": { "user": "kimchy" }
    },
    "highlight" : {
        "fields" : {
            "comment" : {"force_source" : true}
        }
    }
}
--------------------------------------------------
// CONSOLE
// TEST[setup:twitter]

[[tags]]
==== Highlighting Tags

By default, the highlighting will wrap highlighted text in `<em>` and
`</em>`. This can be controlled by setting `pre_tags` and `post_tags`,
for example:

[source,js]
--------------------------------------------------
GET /_search
{
    "query" : {
        "match": { "user": "kimchy" }
    },
    "highlight" : {
        "pre_tags" : ["<tag1>"],
        "post_tags" : ["</tag1>"],
        "fields" : {
            "_all" : {}
        }
    }
}
--------------------------------------------------
// CONSOLE
// TEST[setup:twitter]

Using the fast vector highlighter there can be more tags, and the "importance"
is ordered.

[source,js]
--------------------------------------------------
GET /_search
{
    "query" : {
        "match": { "user": "kimchy" }
    },
    "highlight" : {
        "pre_tags" : ["<tag1>", "<tag2>"],
        "post_tags" : ["</tag1>", "</tag2>"],
        "fields" : {
            "_all" : {}
        }
    }
}
--------------------------------------------------
// CONSOLE
// TEST[setup:twitter]

There are also built in "tag" schemas, with currently a single schema
called `styled` with the following `pre_tags`:

[source,html]
--------------------------------------------------
<em class="hlt1">, <em class="hlt2">, <em class="hlt3">,
<em class="hlt4">, <em class="hlt5">, <em class="hlt6">,
<em class="hlt7">, <em class="hlt8">, <em class="hlt9">,
<em class="hlt10">
--------------------------------------------------

and `</em>` as `post_tags`. If you think of more nice to have built in tag
schemas, just send an email to the mailing list or open an issue. Here
is an example of switching tag schemas:

[source,js]
--------------------------------------------------
GET /_search
{
    "query" : {
        "match": { "user": "kimchy" }
    },
    "highlight" : {
        "tags_schema" : "styled",
        "fields" : {
            "comment" : {}
        }
    }
}
--------------------------------------------------
// CONSOLE
// TEST[setup:twitter]

==== Encoder

An `encoder` parameter can be used to define how highlighted text will
be encoded. It can be either `default` (no encoding) or `html` (will
escape html, if you use html highlighting tags).

==== Highlighted Fragments

Each field highlighted can control the size of the highlighted fragment
in characters (defaults to `100`), and the maximum number of fragments
to return (defaults to `5`).
For example:

[source,js]
--------------------------------------------------
GET /_search
{
    "query" : {
        "match": { "user": "kimchy" }
    },
    "highlight" : {
        "fields" : {
            "comment" : {"fragment_size" : 150, "number_of_fragments" : 3}
        }
    }
}
--------------------------------------------------
// CONSOLE
// TEST[setup:twitter]

On top of this it is possible to specify that highlighted fragments need
to be sorted by score:

[source,js]
--------------------------------------------------
GET /_search
{
    "query" : {
        "match": { "user": "kimchy" }
    },
    "highlight" : {
        "order" : "score",
        "fields" : {
            "comment" : {"fragment_size" : 150, "number_of_fragments" : 3}
        }
    }
}
--------------------------------------------------
// CONSOLE
// TEST[setup:twitter]

If the `number_of_fragments` value is set to `0` then no fragments are
produced, instead the whole content of the field is returned, and of
course it is highlighted. This can be very handy if short texts (like
document title or address) need to be highlighted but no fragmentation
is required. Note that `fragment_size` is ignored in this case.

[source,js]
--------------------------------------------------
GET /_search
{
    "query" : {
        "match": { "user": "kimchy" }
    },
    "highlight" : {
        "fields" : {
            "_all" : {},
            "blog.title" : {"number_of_fragments" : 0}
        }
    }
}
--------------------------------------------------
// CONSOLE
// TEST[setup:twitter]

When using `fvh` one can use `fragment_offset`
parameter to control the margin to start highlighting from.

In the case where there is no matching fragment to highlight, the default is
to not return anything. Instead, we can return a snippet of text from the
beginning of the field by setting `no_match_size` (default `0`) to the length
of the text that you want returned. The actual length may be shorter or longer than
specified as it tries to break on a word boundary.

[source,js]
--------------------------------------------------
GET /_search
{
    "query" : {
        "match": { "user": "kimchy" }
    },
    "highlight" : {
        "fields" : {
            "comment" : {
                "fragment_size" : 150,
                "number_of_fragments" : 3,
                "no_match_size": 150
            }
        }
    }
}
--------------------------------------------------
// CONSOLE
// TEST[setup:twitter]

==== Fragmenter

WARNING: This option is not supported by the `unified` highlighter

Fragmenter can control how text should be broken up in highlight snippets.
However, this option is applicable only for the Plain Highlighter.
There are two options:

[horizontal]
`simple`:: Breaks up text into same sized fragments.
`span`:: Same as the simple fragmenter, but tries not to break up text between highlighted terms (this is applicable when using phrase like queries). This is the default.

[source,js]
--------------------------------------------------
GET twitter/tweet/_search
{
    "query" : {
        "match_phrase": { "message": "number 1" }
    },
    "highlight" : {
        "fields" : {
            "message" : {
                "type": "plain",
                "fragment_size" : 15,
                "number_of_fragments" : 3,
                "fragmenter": "simple"
            }
        }
    }
}
--------------------------------------------------
// CONSOLE
// TEST[setup:twitter]

Response:

[source,js]
--------------------------------------------------
{
    ...
    "hits": {
        "total": 1,
        "max_score": 1.4818809,
        "hits": [
            {
                "_index": "twitter",
                "_type": "tweet",
                "_id": "1",
                "_score": 1.4818809,
                "_source": {
                    "user": "test",
                    "message": "some message with the number 1",
                    "date": "2009-11-15T14:12:12",
                    "likes": 1
                },
                "highlight": {
                    "message": [
                        " with the <em>number</em>",
                        " <em>1</em>"
                    ]
                }
            }
        ]
    }
}
--------------------------------------------------
// TESTRESPONSE[s/\.\.\./"took": $body.took,"timed_out": false,"_shards": $body._shards,/]

[source,js]
--------------------------------------------------
GET twitter/tweet/_search
{
    "query" : {
        "match_phrase": { "message": "number 1" }
    },
    "highlight" : {
        "fields" : {
            "message" : {
                "type": "plain",
                "fragment_size" : 15,
                "number_of_fragments" : 3,
                "fragmenter": "span"
            }
        }
    }
}
--------------------------------------------------
// CONSOLE
// TEST[setup:twitter]

Response:

[source,js]
--------------------------------------------------
{
    ...
    "hits": {
        "total": 1,
        "max_score": 1.4818809,
        "hits": [
            {
                "_index": "twitter",
                "_type": "tweet",
                "_id": "1",
                "_score": 1.4818809,
                "_source": {
                    "user": "test",
                    "message": "some message with the number 1",
                    "date": "2009-11-15T14:12:12",
                    "likes": 1
                },
                "highlight": {
                    "message": [
                        "some message with the <em>number</em> <em>1</em>"
                    ]
                }
            }
        ]
    }
}
--------------------------------------------------
// TESTRESPONSE[s/\.\.\./"took": $body.took,"timed_out": false,"_shards": $body._shards,/]

If the `number_of_fragments` option is set to `0`,
`NullFragmenter` is used which does not fragment the text at all.
This is useful for highlighting the entire content of a document or field.

==== Highlight query

It is also possible to highlight against a query other than the search
query by setting `highlight_query`.  This is especially useful if you
use a rescore query because those are not taken into account by
highlighting by default.  Elasticsearch does not validate that
`highlight_query` contains the search query in any way so it is possible
to define it so legitimate query results aren't highlighted at all.
Generally it is better to include the search query in the
`highlight_query`.  Here is an example of including both the search
query and the rescore query in `highlight_query`.
[source,js]
--------------------------------------------------
GET /_search
{
    "stored_fields": [ "_id" ],
    "query" : {
        "match": {
            "comment": {
                "query": "foo bar"
            }
        }
    },
    "rescore": {
        "window_size": 50,
        "query": {
            "rescore_query" : {
                "match_phrase": {
                    "comment": {
                        "query": "foo bar",
                        "slop": 1
                    }
                }
            },
            "rescore_query_weight" : 10
        }
    },
    "highlight" : {
        "order" : "score",
        "fields" : {
            "comment" : {
                "fragment_size" : 150,
                "number_of_fragments" : 3,
                "highlight_query": {
                    "bool": {
                        "must": {
                            "match": {
                                "comment": {
                                    "query": "foo bar"
                                }
                            }
                        },
                        "should": {
                            "match_phrase": {
                                "comment": {
                                    "query": "foo bar",
                                    "slop": 1,
                                    "boost": 10.0
                                }
                            }
                        },
                        "minimum_should_match": 0
                    }
                }
            }
        }
    }
}
--------------------------------------------------
// CONSOLE
// TEST[setup:twitter]

[[highlighting-settings]]
==== Global Settings

Highlighting settings can be set on a global level and then overridden
at the field level.

[source,js]
--------------------------------------------------
GET /_search
{
    "query" : {
        "match": { "user": "kimchy" }
    },
    "highlight" : {
        "number_of_fragments" : 3,
        "fragment_size" : 150,
        "fields" : {
            "_all" : { "pre_tags" : ["<em>"], "post_tags" : ["</em>"] },
            "blog.title" : { "number_of_fragments" : 0 },
            "blog.author" : { "number_of_fragments" : 0 },
            "blog.comment" : { "number_of_fragments" : 5, "order" : "score" }
        }
    }
}
--------------------------------------------------
// CONSOLE
// TEST[setup:twitter]

[[field-match]]
==== Require Field Match

`require_field_match` can be set to `false` which will cause any field to
be highlighted regardless of whether the query matched specifically on them.
The default behaviour is `true`, meaning that only fields that hold a query
match will be highlighted.

[source,js]
--------------------------------------------------
GET /_search
{
    "query" : {
        "match": { "user": "kimchy" }
    },
    "highlight" : {
        "require_field_match": false,
        "fields": {
                "_all" : { "pre_tags" : ["<em>"], "post_tags" : ["</em>"] }
        }
    }
}
--------------------------------------------------
// CONSOLE
// TEST[setup:twitter]

[[boundary-scanners]]
==== Boundary Scanners

When highlighting a field using the unified highlighter or the fast vector highlighter,
you can specify how to break the highlighted fragments using `boundary_scanner`, which accepts
the following values:

* `chars` (default mode for the FVH): allows to configure which characters (`boundary_chars`)
constitute a boundary for highlighting. It's a single string with each boundary
character defined in it (defaults to `.,!? \t\n`). It also allows configuring
the `boundary_max_scan` to control how far to look for boundary characters
(defaults to `20`). Works only with the Fast Vector Highlighter.

* `sentence` and `word`: use Java's https://docs.oracle.com/javase/8/docs/api/java/text/BreakIterator.html[BreakIterator]
to break the highlighted fragments at the next  _sentence_ or _word_ boundary.
You can further specify `boundary_scanner_locale` to control which Locale is used
to search the text for these boundaries.

[NOTE]
When used with the `unified` highlighter, the `sentence` scanner splits sentence
bigger than `fragment_size` at the first word boundary next to `fragment_size`.
You can set `fragment_size` to 0 to never split any sentence.

[[matched-fields]]
==== Matched Fields

WARNING: This is only supported by the `fvh` highlighter

The Fast Vector Highlighter can combine matches on multiple fields to
highlight a single field using `matched_fields`.  This is most
intuitive for multifields that analyze the same string in different
ways.  All `matched_fields` must have `term_vector` set to
`with_positions_offsets` but only the field to which the matches are
combined is loaded so only that field would benefit from having
`store` set to `yes`.

In the following examples `comment` is analyzed by the `english`
analyzer and `comment.plain` is analyzed by the `standard` analyzer.

[source,js]
--------------------------------------------------
GET /_search
{
    "query": {
        "query_string": {
            "query": "comment.plain:running scissors",
            "fields": ["comment"]
        }
    },
    "highlight": {
        "order": "score",
        "fields": {
            "comment": {
                "matched_fields": ["comment", "comment.plain"],
                "type" : "fvh"
            }
        }
    }
}
--------------------------------------------------
// CONSOLE
// TEST[setup:twitter]

The above matches both "run with scissors" and "running with scissors"
and would highlight "running" and "scissors" but not "run". If both
phrases appear in a large document then "running with scissors" is
sorted above "run with scissors" in the fragments list because there
are more matches in that fragment.

[source,js]
--------------------------------------------------
GET /_search
{
    "query": {
        "query_string": {
            "query": "running scissors",
            "fields": ["comment", "comment.plain^10"]
        }
    },
    "highlight": {
        "order": "score",
        "fields": {
            "comment": {
                "matched_fields": ["comment", "comment.plain"],
                "type" : "fvh"
            }
        }
    }
}
--------------------------------------------------
// CONSOLE
// TEST[setup:twitter]

The above highlights "run" as well as "running" and "scissors" but
still sorts "running with scissors" above "run with scissors" because
the plain match ("running") is boosted.

[source,js]
--------------------------------------------------
GET /_search
{
    "query": {
        "query_string": {
            "query": "running scissors",
            "fields": ["comment", "comment.plain^10"]
        }
    },
    "highlight": {
        "order": "score",
        "fields": {
            "comment": {
                "matched_fields": ["comment.plain"],
                "type" : "fvh"
            }
        }
    }
}
--------------------------------------------------
// CONSOLE
// TEST[setup:twitter]

The above query wouldn't highlight "run" or "scissor" but shows that
it is just fine not to list the field to which the matches are combined
(`comment`) in the matched fields.

[NOTE]
Technically it is also fine to add fields to `matched_fields` that
don't share the same underlying string as the field to which the matches
are combined.  The results might not make much sense and if one of the
matches is off the end of the text then the whole query will fail.

[NOTE]
===================================================================
There is a small amount of overhead involved with setting
`matched_fields` to a non-empty array so always prefer
[source,js]
--------------------------------------------------
    "highlight": {
        "fields": {
            "comment": {}
        }
    }
--------------------------------------------------
// NOTCONSOLE
to
[source,js]
--------------------------------------------------
    "highlight": {
        "fields": {
            "comment": {
                "matched_fields": ["comment"],
                "type" : "fvh"
            }
        }
    }
--------------------------------------------------
// NOTCONSOLE
===================================================================

[[phrase-limit]]
==== Phrase Limit

WARNING: this is only supported by the `fvh` highlighter

The fast vector highlighter has a `phrase_limit` parameter that prevents
it from analyzing too many phrases and eating tons of memory.  It defaults
to 256 so only the first 256 matching phrases in the document scored
considered.  You can raise the limit with the `phrase_limit` parameter but
keep in mind that scoring more phrases consumes more time and memory.

If using `matched_fields` keep in mind that `phrase_limit` phrases per
matched field are considered.

[float]
[[explicit-field-order]]
=== Field Highlight Order
Elasticsearch highlights the fields in the order that they are sent.  Per the
json spec objects are unordered but if you need to be explicit about the order
that fields are highlighted then you can use an array for `fields` like this:
[source,js]
--------------------------------------------------
GET /_search
{
    "highlight": {
        "fields": [
            { "title": {} },
            { "text": {} }
        ]
    }
}
--------------------------------------------------
// CONSOLE
// TEST[setup:twitter]

None of the highlighters built into Elasticsearch care about the order that the
fields are highlighted but a plugin may.