Multi-match queries

A multi-match operation functions similarly to the match operation. You can use a multi_match query to search multiple fields.

The ^ “boosts” certain fields. Boosts are multipliers that weigh matches in one field more heavily than matches in other fields. In the following example, a match for “wind” in the title field influences _score four times as much as a match in the plot field:

  1. GET _search
  2. {
  3.   "query": {
  4.     "multi_match": {
  5.       "query": "wind",
  6.       "fields": ["title^4", "plot"]
  7.     }
  8.   }
  9. }

copy

The result is that films like The Wind Rises and Gone with the Wind are near the top of the search results, and films like Twister, which presumably have “wind” in their plot summaries, are near the bottom.

You can use wildcards in the field name. For example, the following query will search the speaker field and all fields that start with play_, for example, play_name or play_title:

  1. GET _search
  2. {
  3.   "query": {
  4.     "multi_match": {
  5.       "query": "hamlet",
  6.       "fields": ["speaker", "play_*"]
  7.     }
  8.   }
  9. }

copy

If you don’t provide the fields parameter, multi_match query searches the fields specified in the index.query. Default_field setting, which defaults to *. The default behavior is to extract all fields in the mapping that are eligible for term-level queries, filter the metadata fields, and combine all extracted fields to build a query.

The maximum number of clauses in a query is defined in the indices.query.bool.max_clause_count setting, which defaults to 1,024.

Multi-match query types

OpenSearch supports the following multi-match query types, which differ in the way the query is executed internally:

  • best_fields (default): Returns documents that match any field. Uses the _score of the best-matching field.
  • most_fields: Returns documents that match any field. Uses a combined score of each matching field.
  • cross_fields: Treats all fields as if they were one field. Processes fields with the same analyzer and matches words in any field.
  • phrase: Runs a match_phrase query on each field. Uses the _score of the best-matching field.
  • phrase_prefix: Runs a match_phrase_prefix query on each field. Uses the _score of the best-matching field.
  • bool_prefix: Runs a match_bool_prefix query on each field. Uses a combined score of each matched field.

Best fields

If you’re searching for two words that specify a concept, you want the results where the two words are next to each other to score higher.

For example, consider an index that contains the following scientific articles:

  1. PUT /articles/_doc/1
  2. {
  3.   "title": "Aurora borealis",
  4.   "description": "Northern lights, or aurora borealis, explained"
  5. }

copy

  1. PUT /articles/_doc/2
  2. {
  3.   "title": "Sun deprivation in the Northern countries",
  4.   "description": "Using fluorescent lights for therapy"
  5. }

copy

You can search for articles containing northern lights in the title or description:

  1. GET articles/_search
  2. {
  3.   "query": {
  4.     "multi_match" : {
  5.       "query": "northern lights",
  6.       "type": "best_fields",
  7.       "fields": [ "title", "description" ],
  8.       "tie_breaker": 0.3
  9.     }
  10.   }
  11. }

copy

The preceding query is executed as the following dis_max query with a match query for each field:

  1. GET /articles/_search
  2. {
  3.   "query": {
  4.     "dis_max": {
  5.       "queries": [
  6.         { "match": { "title": "northern lights" }},
  7.         { "match": { "description": "northern lights" }}
  8.       ],
  9.       "tie_breaker": 0.3
  10.     }
  11.   }
  12. }

The results contain both documents, but document 1 is scored higher because both words are in the description field:

  1. {
  2.   "took": 30,
  3.   "timed_out": false,
  4.   "_shards": {
  5.     "total": 1,
  6.     "successful": 1,
  7.     "skipped": 0,
  8.     "failed": 0
  9.   },
  10.   "hits": {
  11.     "total": {
  12.       "value": 2,
  13.       "relation": "eq"
  14.     },
  15.     "max_score": 0.84407747,
  16.     "hits": [
  17.       {
  18.         "_index": "articles",
  19.         "_id": "1",
  20.         "_score": 0.84407747,
  21.         "_source": {
  22.           "title": "Aurora borealis",
  23.           "description": "Northern lights, or aurora borealis, explained"
  24.         }
  25.       },
  26.       {
  27.         "_index": "articles",
  28.         "_id": "2",
  29.         "_score": 0.6322521,
  30.         "_source": {
  31.           "title": "Sun deprivation in the Northern countries",
  32.           "description": "Using fluorescent lights for therapy"
  33.         }
  34.       }
  35.     ]
  36.   }
  37. }

The best_fields query uses the score of the best-matching field. If you specify a tie_breaker, the score is calculated using the following algorithm:

Take the score of the best-matching field and add (tie_breaker * _score) for all other matching fields.

Most fields

Use the most_fields query for multiple fields that contain the same text that is analyzed in different ways. For example, the original field may contain text analyzed with the standard analyzer and another field may contain the same text analyzed with the english analyzer, which performs stemming:

  1. PUT /articles
  2. {
  3.   "mappings": {
  4.     "properties": {
  5.       "title": { 
  6.         "type": "text",
  7.         "fields": {
  8.           "english": { 
  9.             "type": "text",
  10.             "analyzer": "english"
  11.           }
  12.         }
  13.       }
  14.     }
  15.   }
  16. }

copy

Consider the following two documents that are indexed in the articles index:

  1. PUT /articles/_doc/1
  2. {
  3.   "title": "Buttered toasts"
  4. }

copy

  1. PUT /articles/_doc/2
  2. {
  3.   "title": "Buttering a toast"
  4. }

copy

The standard analyzer analyzes the title Buttered toast into [buttered, toasts] and the title Buttering a toast into [buttering, a, toast]. On the other hand, the english analyzer produces the same token list [butter, toast] for both titles because of stemming.

You can use the most_fields query in order to return as many documents as possible:

  1. GET /articles/_search
  2. {
  3.   "query": {
  4.     "multi_match": {
  5.       "query": "buttered toast",
  6.       "fields": [ 
  7.         "title",
  8.         "title.english"
  9.       ],
  10.       "type": "most_fields" 
  11.     }
  12.   }
  13. }

copy

The preceding query is executed as the following Boolean query:

  1. GET articles/_search
  2. {
  3.   "query": {
  4.     "bool": {
  5.       "should": [
  6.         { "match": { "title": "buttered toasts" }},
  7.         { "match": { "title.english": "buttered toasts" }}
  8.       ]
  9.     }
  10.   }
  11. }

To calculate the relevance score, a document’s scores for all match clauses are added together and then the result is divided by the number of match clauses.

Including the title.english field retrieves the second document that matches the stemmed tokens:

  1. {
  2.   "took": 9,
  3.   "timed_out": false,
  4.   "_shards": {
  5.     "total": 1,
  6.     "successful": 1,
  7.     "skipped": 0,
  8.     "failed": 0
  9.   },
  10.   "hits": {
  11.     "total": {
  12.       "value": 2,
  13.       "relation": "eq"
  14.     },
  15.     "max_score": 1.4418206,
  16.     "hits": [
  17.       {
  18.         "_index": "articles",
  19.         "_id": "1",
  20.         "_score": 1.4418206,
  21.         "_source": {
  22.           "title": "Buttered toasts"
  23.         }
  24.       },
  25.       {
  26.         "_index": "articles",
  27.         "_id": "2",
  28.         "_score": 0.09304003,
  29.         "_source": {
  30.           "title": "Buttering a toast"
  31.         }
  32.       }
  33.     ]
  34.   }
  35. }

Because both title and title.english fields match for the first document, it has a higher relevance score.

Operator and minimum should match

The best_fields and most_fields queries generate a match query on a field basis (one per field). Thus, the minimum_should_match and operator parameters are applied to each field, which is normally not the desired behavior.

For example, consider a customers index with the following documents:

  1. PUT customers/_doc/1 
  2. {
  3.   "first_name": "John",
  4.   "last_name": "Doe"
  5. }

copy

  1. PUT customers/_doc/2 
  2. {
  3.   "first_name": "Jane",
  4.   "last_name": "Doe"
  5. }

copy

If you’re searching for John Doe in the customers index, you might construct the following query:

  1. GET customers/_validate/query?explain
  2. {
  3.   "query": {
  4.     "multi_match" : {
  5.       "query": "John Doe",
  6.       "type": "best_fields",
  7.       "fields": [ "first_name", "last_name" ],
  8.       "operator": "and" 
  9.     }
  10.   }
  11. }

copy

The intent of the and operator in this query is to find a document that matches John and Doe. However, the query does not return any results. You can learn how the query is executed by running the Validate API:

  1. GET customers/_validate/query?explain
  2. {
  3.   "query": {
  4.     "multi_match" : {
  5.       "query":      "John Doe",
  6.       "type":       "best_fields",
  7.       "fields":     [ "first_name", "last_name" ],
  8.       "operator":   "and" 
  9.     }
  10.   }
  11. }

copy

From the response, you can see that the query is trying to match both John and Doe to either the first_name or last_name field:

  1. {
  2.   "_shards": {
  3.     "total": 1,
  4.     "successful": 1,
  5.     "failed": 0
  6.   },
  7.   "valid": true,
  8.   "explanations": [
  9.     {
  10.       "index": "customers",
  11.       "valid": true,
  12.       "explanation": "((+first_name:john +first_name:doe) | (+last_name:john +last_name:doe))"
  13.     }
  14.   ]
  15. }

Because neither field contains both words, no results are returned.

A better alternative for searching across fields is to use the cross_fields query. Unlike the field-centric best_fields and most_fields queries, cross_fields query is term-centric.

Cross fields

Use the cross_fields query to search for data across multiple fields. For example, if an index contains customer data, the first name and last name of the customer reside in different fields. Yet, when you search for John Doe, you want to receive documents in which John is in the first_name field and Doe is in the last_name field.

The most_fields query does not work in this case because of the following problems:

  • The operator and minimum_should_match parameters are applied on a field basis instead of on a term basis.
  • Term frequencies in the first_name and last_name fields can lead to unexpected results. For example, if someone’s first name happens to be Doe, a document with this name will be presumed a better match because this first name will not appear in any other documents.

The cross_fields query analyzes the query string into individual terms and then searches for each of the terms in any of the fields, as if they were one field.

The following is the cross_fields query for John Doe:

  1. GET /customers/_search
  2. {
  3.   "query": {
  4.     "multi_match" : {
  5.       "query": "John Doe",
  6.       "type": "cross_fields",
  7.       "fields": [ "first_name", "last_name" ],
  8.       "operator": "and"
  9.     }
  10.   }
  11. }

copy

The response contains the only document in which both John and Doe are present:

  1. {
  2.   "took": 19,
  3.   "timed_out": false,
  4.   "_shards": {
  5.     "total": 1,
  6.     "successful": 1,
  7.     "skipped": 0,
  8.     "failed": 0
  9.   },
  10.   "hits": {
  11.     "total": {
  12.       "value": 1,
  13.       "relation": "eq"
  14.     },
  15.     "max_score": 0.8754687,
  16.     "hits": [
  17.       {
  18.         "_index": "customers",
  19.         "_id": "1",
  20.         "_score": 0.8754687,
  21.         "_source": {
  22.           "first_name": "John",
  23.           "last_name": "Doe"
  24.         }
  25.       }
  26.     ]
  27.   }
  28. }

You can use the Validate API operation to gain insight into how the preceding query is executed:

  1. GET /customers/_validate/query?explain
  2. {
  3.   "query": {
  4.     "multi_match" : {
  5.       "query": "John Doe",
  6.       "type": "cross_fields",
  7.       "fields": [ "first_name", "last_name" ],
  8.       "operator": "and"
  9.     }
  10.   }
  11. }

copy

From the response, you can see that the query is searching for all terms in at least one field:

  1. {
  2.   "_shards": {
  3.     "total": 1,
  4.     "successful": 1,
  5.     "failed": 0
  6.   },
  7.   "valid": true,
  8.   "explanations": [
  9.     {
  10.       "index": "customers",
  11.       "valid": true,
  12.       "explanation": "+blended(terms:[last_name:john, first_name:john]) +blended(terms:[last_name:doe, first_name:doe])"
  13.     }
  14.   ]
  15. }

Thus, blending the term frequencies for all fields solves the problem of differing term frequencies by correcting for the differences.

The cross_fields query is usually only useful on short string fields with a boost of 1. In other cases, the score does not produce a meaningful blend of term statistics because of the way boosts, term frequencies, and length normalization contribute to the score.

The fuzziness parameter is not supported for cross_fields queries.

Analysis

The cross_fields query only works as a term-centric query on fields with the same analyzer. Fields with the same analyzer are grouped together and these groups are combined with a Boolean query.

For example, consider an index where the first_name and last_name fields are analyzed with the default standard analyzer and their .edge subfields are analyzed with an edge n-gram analyzer:

Response

  1. PUT customers
  2. {
  3.   "settings": {
  4.     "analysis": {
  5.       "analyzer": {
  6.         "my_analyzer": {
  7.           "tokenizer": "my_tokenizer"
  8.         }
  9.       },
  10.       "tokenizer": {
  11.         "my_tokenizer": {
  12.           "type": "edge_ngram",
  13.           "min_gram": 2,
  14.           "max_gram": 10
  15.         }
  16.       }
  17.     }
  18.   },
  19.   "mappings": {
  20.     "properties": {
  21.       "first_name": { 
  22.         "type": "text",
  23.         "fields": {
  24.           "edge": { 
  25.             "type": "text",
  26.             "analyzer": "my_analyzer"
  27.           }
  28.         }
  29.       },
  30.       "last_name": { 
  31.         "type": "text",
  32.         "fields": {
  33.           "edge": { 
  34.             "type": "text",
  35.             "analyzer": "my_analyzer"
  36.           }
  37.         }
  38.       }
  39.     }
  40.   }
  41. }

copy

You index one document in the customers index:

  1. PUT /customers/_doc/1
  2. {
  3.   "first": "John",
  4.   "last": "Doe"
  5. }

copy

You can use a cross_fields query to search across the fields for John Doe:

  1. GET /customers/_search
  2. {
  3.   "query": {
  4.     "multi_match" : {
  5.       "query": "John",
  6.       "type": "cross_fields",
  7.       "fields": [
  8.         "first_name", "first_name.edge",
  9.         "last_name",  "last_name.edge"
  10.       ]
  11.     }
  12.   }
  13. }

copy

To see how the query is executed, you can run the Validate API:

  1. GET /customers/_validate/query?explain
  2. {
  3.   "query": {
  4.     "multi_match" : {
  5.       "query": "John",
  6.       "type": "cross_fields",
  7.       "fields": [
  8.         "first_name", "first_name.edge",
  9.         "last_name",  "last_name.edge"
  10.       ]
  11.     }
  12.   }
  13. }

copy

The response shows that the last_name and first_name fields are grouped together and treated as a single field. Similarly, the last_name.edge and first_name.edge fields are grouped together and treated as a single field:

  1. {
  2.   "_shards": {
  3.     "total": 1,
  4.     "successful": 1,
  5.     "failed": 0
  6.   },
  7.   "valid": true,
  8.   "explanations": [
  9.     {
  10.       "index": "customers",
  11.       "valid": true,
  12.       "explanation": "(blended(terms:[last_name:john, first_name:john]) | (blended(terms:[last_name.edge:Jo, first_name.edge:Jo]) blended(terms:[last_name.edge:Joh, first_name.edge:Joh]) blended(terms:[last_name.edge:John, first_name.edge:John])))"
  13.     }
  14.   ]
  15. }

Using the operator or minimum_should_match parameters with multiple field groups like the preceding ones can lead to the problem described in the previous section. To avoid it, you can rewrite the previous query as two cross_fields subqueries combined with a Boolean query and apply the minimum_should_match to one of the subqueries:

  1. GET /customers/_search
  2. {
  3.   "query": {
  4.     "bool": {
  5.       "should": [
  6.         {
  7.           "multi_match": {
  8.             "query": "John Doe",
  9.             "type": "cross_fields",
  10.             "fields": [
  11.               "first_name",
  12.               "last_name"
  13.             ],
  14.             "minimum_should_match": "1"
  15.           }
  16.         },
  17.         {
  18.           "multi_match": {
  19.             "query": "John Doe",
  20.             "type": "cross_fields",
  21.             "fields": [
  22.               "first_name.edge",
  23.               "last_name.edge"
  24.             ]
  25.           }
  26.         }
  27.       ]
  28.     }
  29.   }
  30. }

copy

To create one group for all fields, specify an analyzer in your query:

  1. GET customers/_search
  2. {
  3.   "query": {
  4.    "multi_match" : {
  5.       "query": "John Doe",
  6.       "type": "cross_fields",
  7.       "analyzer": "standard", 
  8.       "fields": [ "first_name", "last_name", "*.edge" ]
  9.     }
  10.   }
  11. }

copy

Running the Validate API on the previous query shows how the query is executed:

  1. {
  2.   "_shards": {
  3.     "total": 1,
  4.     "successful": 1,
  5.     "failed": 0
  6.   },
  7.   "valid": true,
  8.   "explanations": [
  9.     {
  10.       "index": "customers",
  11.       "valid": true,
  12.       "explanation": "blended(terms:[last_name.edge:john, last_name:john, first_name:john, first_name.edge:john]) blended(terms:[last_name.edge:doe, last_name:doe, first_name:doe, first_name.edge:doe])"
  13.     }
  14.   ]
  15. }

Phrase

The phrase query behaves similarly to the best_fields query but uses a match_phrase query instead of a match query.

The following is an example phrase query for the index described in the best_fields section:

  1. GET articles/_search
  2. {
  3.   "query": {
  4.     "multi_match" : {
  5.       "query": "northern lights",
  6.       "type": "phrase",
  7.       "fields": [ "title", "description" ]
  8.     }
  9.   }
  10. }

copy

The preceding query is executed as the following dis_max query with a match_phrase query for each field:

  1. GET articles/_search
  2. {
  3.   "query": {
  4.     "dis_max": {
  5.       "queries": [
  6.         { "match_phrase": { "title": "northern lights" }},
  7.         { "match_phrase": { "description": "northern lights" }}
  8.       ]
  9.     }
  10.   }
  11. }

Because by default a phrase query matches text only when the terms appear in the same order, only document 1 is returned in the results:

Response

  1. {
  2.   "took": 3,
  3.   "timed_out": false,
  4.   "_shards": {
  5.     "total": 1,
  6.     "successful": 1,
  7.     "skipped": 0,
  8.     "failed": 0
  9.   },
  10.   "hits": {
  11.     "total": {
  12.       "value": 1,
  13.       "relation": "eq"
  14.     },
  15.     "max_score": 0.84407747,
  16.     "hits": [
  17.       {
  18.         "_index": "articles",
  19.         "_id": "1",
  20.         "_score": 0.84407747,
  21.         "_source": {
  22.           "title": "Aurora borealis",
  23.           "description": "Northern lights, or aurora borealis, explained"
  24.         }
  25.       }
  26.     ]
  27.   }
  28. }

You can use the slop parameter to allow other words between words in query phrase. For example, the following query accepts text as a match if up to two words are between flourescent and therapy:

  1. GET articles/_search
  2. {
  3.   "query": {
  4.     "multi_match" : {
  5.       "query": "fluorescent therapy",
  6.       "type": "phrase",
  7.       "fields": [ "title", "description" ],
  8.       "slop": 2
  9.     }
  10.   }
  11. }

copy

The response contains document 2:

Response

  1. {
  2.   "took": 3,
  3.   "timed_out": false,
  4.   "_shards": {
  5.     "total": 1,
  6.     "successful": 1,
  7.     "skipped": 0,
  8.     "failed": 0
  9.   },
  10.   "hits": {
  11.     "total": {
  12.       "value": 1,
  13.       "relation": "eq"
  14.     },
  15.     "max_score": 0.7003825,
  16.     "hits": [
  17.       {
  18.         "_index": "articles",
  19.         "_id": "2",
  20.         "_score": 0.7003825,
  21.         "_source": {
  22.           "title": "Sun deprivation in the Northern countries",
  23.           "description": "Using fluorescent lights for therapy"
  24.         }
  25.       }
  26.     ]
  27.   }
  28. }

For slop values less than 2, no documents are returned.

The fuzziness parameter is not supported for phrase queries.

Phrase prefix

The phrase_prefix query behaves similarly to the phrase query but uses a match_phrase_prefix query instead of a match_phrase query.

The following is an example phrase_prefix query for the index described in the best_fields section:

  1. GET articles/_search
  2. {
  3.   "query": {
  4.     "multi_match" : {
  5.       "query": "northern light",
  6.       "type": "phrase_prefix",
  7.       "fields": [ "title", "description" ]
  8.     }
  9.   }
  10. }

copy

The preceding query is executed as the following dis_max query with a match_phrase_prefix query for each field:

  1. GET articles/_search
  2. {
  3.   "query": {
  4.     "dis_max": {
  5.       "queries": [
  6.         { "match_phrase_prefix": { "title": "northern light" }},
  7.         { "match_phrase_prefix": { "description": "northern light" }}
  8.       ]
  9.     }
  10.   }
  11. }

You can use the slop parameter to allow other words between words in query phrase.

The fuzziness parameter is not supported for phrase_prefix queries.

Boolean prefix

The bool_prefix query scores documents similarly to the most_fields query but uses a match_bool_prefix query instead of a match query.

The following is an example bool_prefix query for the index described in the best_fields section:

  1. GET articles/_search
  2. {
  3.   "query": {
  4.     "multi_match" : {
  5.       "query": "li northern",
  6.       "type": "bool_prefix",
  7.       "fields": [ "title", "description" ]
  8.     }
  9.   }
  10. }

copy

The preceding query is executed as the following dis_max query with a match_bool_prefix query for each field:

  1. GET articles/_search
  2. {
  3.   "query": {
  4.     "dis_max": {
  5.       "queries": [
  6.         { "match_bool_prefix": { "title": "li northern" }},
  7.         { "match_bool_prefix": { "description": "li northern" }}
  8.       ]
  9.     }
  10.   }
  11. }

The fuzziness, prefix_length, max_expansions, fuzzy_rewrite, and fuzzy_transpositions parameters are supported for the terms that are used to construct term queries, but they do not have an effect on the prefix query constructed from the final term.

Parameters

The query accepts the following parameters. All parameters except query are optional.

ParameterData typeDescription
queryStringThe query string to use for search. Required.
autogenerate_synonyms_phrase_queryBooleanSpecifies whether to create a match phrase query automatically for multi-term synonyms. For example, if you specify ba,batting average as synonyms and search for ba, OpenSearch searches for ba OR “batting average” (if this option is true) or ba OR (batting AND average) (if this option is false). Default is true.
analyzerStringThe analyzer used to tokenize the query string text. Default is the index-time analyzer specified for the default_field. If no analyzer is specified for the default_field, the analyzer is the default analyzer for the index.
boostFloating-pointBoosts the clause by the given multiplier. Useful for weighing clauses in compound queries. Values in the [0, 1) range decrease relevance, and values greater than 1 increase relevance. Default is 1.
fieldsArray of stringsThe list of fields in which to search. If you don’t provide the fields parameter, multi_match query searches the fields specified in the index.query. Default_field setting, which defaults to *.
fuzzinessStringThe number of character edits (insert, delete, substitute) that it takes to change one word to another when determining whether a term matched a value. For example, the distance between wined and wind is 1. Valid values are non-negative integers or AUTO. The default, AUTO, chooses a value based on the length of each term and is a good choice for most use cases. Not supported for phrase, phrase_prefix, and cross_fields queries.
fuzzy_rewriteStringDetermines how OpenSearch rewrites the query. Valid values are constant_score, scoring_boolean, constant_score_boolean, top_terms_N, top_terms_boost_N, and top_terms_blended_freqs_N. If the fuzziness parameter is not 0, the query uses a fuzzy_rewrite method of top_terms_blended_freqs${max_expansions} by default. Default is constant_score.
fuzzy_transpositionsBooleanSetting fuzzy_transpositions to true (default) adds swaps of adjacent characters to the insert, delete, and substitute operations of the fuzziness option. For example, the distance between wind and wnid is 1 if fuzzy_transpositions is true (swap “n” and “i”) and 2 if it is false (delete “n”, insert “n”). If fuzzy_transpositions is false, rewind and wnid have the same distance (2) from wind, despite the more human-centric opinion that wnid is an obvious typo. The default is a good choice for most use cases.
lenientBooleanSetting lenient to true ignores data type mismatches between the query and the document field. For example, a query string of “8.2” could match a field of type float. Default is false.
max_expansionsPositive integerThe maximum number of terms to which the query can expand. Fuzzy queries “expand to” a number of matching terms that are within the distance specified in fuzziness. Then OpenSearch tries to match those terms. Default is 50.
minimum_should_matchPositive or negative integer, positive or negative percentage, combinationIf the query string contains multiple search terms and you use the or operator, the number of terms that need to match for the document to be considered a match. For example, if minimum_should_match is 2, wind often rising does not match The Wind Rises. If minimum_should_match is 1, it matches. For details, see Minimum should match.
operatorStringIf the query string contains multiple search terms, whether all terms need to match (AND) or only one term needs to match (OR) for a document to be considered a match. Valid values are:
- OR: The string to be is interpreted as to OR be
- AND: The string to be is interpreted as to AND be
Default is OR.
prefix_lengthNon-negative integerThe number of leading characters that are not considered in fuzziness. Default is 0.
slop0 (default) or a positive integerControls the degree to which words in a query can be misordered and still be considered a match. From the Lucene documentation: “The number of other words permitted between words in query phrase. For example, to switch the order of two words requires two moves (the first move places the words atop one another), so to permit reorderings of phrases, the slop must be at least two. A value of zero requires an exact match.” Supported for phrase and phrase_prefix query types.
tie_breakerFloating-pointA factor between 0 and 1.0 that is used to give more weight to documents that match multiple query clauses. For more information, see The tie_breaker parameter`.
typeStringThe multi-match query type. Valid values are best_fields, most_fields, cross_fields, phrase, phrase_prefix, bool_prefix. Default is best_fields.
zero_terms_queryStringIn some cases, the analyzer removes all terms from a query string. For example, the stop analyzer removes all terms from the string an but this. In those cases, zero_terms_query specifies whether to match no documents (none) or all documents (all). Valid values are none and all. Default is none.

The fuzziness parameter is not supported for phrase, phrase_prefix, and cross_fields queries.

The slop parameter is only supported for phrase and phrase_prefix queries.

The tie_breaker parameter

Each term-level blended query calculates the document score as the best score returned by any field in a group. The scores from all blended queries are added together to produce the final score. You can change the way the score is calculated by using the tie_breaker parameter. The tie_breaker parameter accepts the following values:

  • 0.0 (default for best_fields, cross_fields, phrase, and phrase_prefix queries): Take the single best score returned by any field in a group.
  • 1.0 (default for most_fields and bool_prefix queries): Add the scores for all fields in a group.
  • A floating-point value in the (0, 1) range: Take the single best score of the best-matching field and add (tie_breaker * _score) for all other matching fields.