multi-match

Похож на запрос match, но используется для нескольких полей.

Многофункциональные запросы (Multi-match queries)

Операция multi-match функционирует аналогично операции match. Вы можете использовать запрос multi_match для поиска по нескольким полям.

Символ ^ “увеличивает” вес определенных полей. Увеличения — это множители, которые придают больший вес совпадениям в одном поле по сравнению с совпадениями в других полях. В следующем примере совпадение для “ветер” в поле title влияет на _score в четыре раза больше, чем совпадение в поле plot:

GET _search
{
  "query": {
    "multi_match": {
      "query": "ветер",
      "fields": ["title^4", "plot"]
    }
  }
}

В результате фильмы, такие как “Ветер поднимается” и “Ушедший с ветром”, находятся в верхней части результатов поиска, а фильмы, такие как “Ураган”, которые, предположительно, содержат “ветер” в своих аннотациях, находятся внизу.

Вы можете использовать подстановочные знаки в имени поля. Например, следующий запрос будет искать поле speaker и все поля, начинающиеся с play_, например, play_name или play_title:

GET _search
{
  "query": {
    "multi_match": {
      "query": "гамлет",
      "fields": ["speaker", "play_*"]
    }
  }
}

Если вы не укажете параметр fields, запрос multi_match будет искать в полях, указанных в настройке index.query.default_field, которая по умолчанию равна *. Поведение по умолчанию заключается в извлечении всех полей в отображении, которые подходят для запросов на уровне терминов, фильтрации метаданных и комбинировании всех извлеченных полей для построения запроса.

Максимальное количество клауз в запросе определяется настройкой indices.query.bool.max_clause_count, которая по умолчанию равна 1,024.

Типы многофункциональных запросов

OpenSearch поддерживает следующие типы многофункциональных запросов, которые различаются по способу внутреннего выполнения запроса:

  • best_fields (по умолчанию): Возвращает документы, которые соответствуют любому полю. Использует _score лучшего совпадающего поля.
  • most_fields: Возвращает документы, которые соответствуют любому полю. Использует комбинированный балл каждого совпадающего поля.
  • cross_fields: Обрабатывает все поля так, как если бы они были одним полем. Обрабатывает поля с одинаковым анализатором и сопоставляет слова в любом поле.
  • phrase: Выполняет запрос match_phrase для каждого поля. Использует _score лучшего совпадающего поля.
  • phrase_prefix: Выполняет запрос match_phrase_prefix для каждого поля. Использует _score лучшего совпадающего поля.
  • bool_prefix: Выполняет запрос match_bool_prefix для каждого поля. Использует комбинированный балл каждого совпадающего поля.

Лучшие поля (Best fields)

Если вы ищете два слова, которые определяют концепцию, вы хотите, чтобы результаты, в которых два слова находятся рядом друг с другом, имели более высокий балл.

Например, рассмотрим индекс, содержащий следующие научные статьи:

PUT /articles/_doc/1
{
  "title": "Аврора бореалис",
  "description": "Северные огни, или аврора бореалис, объяснены"
}

PUT /articles/_doc/2
{
  "title": "Недостаток солнца в северных странах",
  "description": "Использование флуоресцентных ламп для терапии"
}

Вы можете искать статьи, содержащие “северные огни” в заголовке или описании:

GET articles/_search
{
  "query": {
    "multi_match" : {
      "query": "северные огни",
      "type": "best_fields",
      "fields": [ "title", "description" ],
      "tie_breaker": 0.3
    }
  }
}

Предыдущий запрос выполняется как следующий запрос dis_max с запросом match для каждого поля:

Запрос multi_match позволяет искать по нескольким полям. Он работает аналогично запросу match, но с возможностью указания нескольких полей для поиска.

Пример запроса dis_max

GET /articles/_search
{
  "query": {
    "dis_max": {
      "queries": [
        { "match": { "title": "северные огни" }},
        { "match": { "description": "северные огни" }}
      ],
      "tie_breaker": 0.3
    }
  }
}

Результаты содержат оба документа, но документ 1 имеет более высокий балл, потому что оба слова находятся в поле description:

{
  "took": 30,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 2,
      "relation": "eq"
    },
    "max_score": 0.84407747,
    "hits": [
      {
        "_index": "articles",
        "_id": "1",
        "_score": 0.84407747,
        "_source": {
          "title": "Аврора бореалис",
          "description": "Северные огни, или аврора бореалис, объяснены"
        }
      },
      {
        "_index": "articles",
        "_id": "2",
        "_score": 0.6322521,
        "_source": {
          "title": "Недостаток солнца в северных странах",
          "description": "Использование флуоресцентных ламп для терапии"
        }
      }
    ]
  }
}

Запрос best_fields использует балл лучшего совпадающего поля. Если вы укажете tie_breaker, балл рассчитывается по следующему алгоритму:

  1. Возьмите балл лучшего совпадающего поля.
  2. Добавьте (tie_breaker * _score) для всех других совпадающих полей.

Запрос most_fields

Используйте запрос most_fields для нескольких полей, которые содержат один и тот же текст, анализируемый разными способами. Например, оригинальное поле может содержать текст, проанализированный с помощью стандартного анализатора, а другое поле может содержать тот же текст, проанализированный с помощью английского анализатора, который выполняет стемминг:

PUT /articles
{
  "mappings": {
    "properties": {
      "title": { 
        "type": "text",
        "fields": {
          "english": { 
            "type": "text",
            "analyzer": "english"
          }
        }
      }
    }
  }
}

Рассмотрим следующие два документа, которые индексируются в индексе articles:

PUT /articles/_doc/1
{
  "title": "Гренки с маслом"
}

PUT /articles/_doc/2
{
  "title": "Масло на тосте"
}

Стандартный анализатор анализирует заголовок “Гренки с маслом” в [гренки, масло], а заголовок “Масло на тосте” в [масло, на, тосте]. С другой стороны, английский анализатор производит один и тот же список токенов [масло, тост] для обоих заголовков из-за стемминга.

Вы можете использовать запрос most_fields, чтобы вернуть как можно больше документов:

GET /articles/_search
{
  "query": {
    "multi_match": {
      "query": "гренки с маслом",
      "fields": [ 
        "title",
        "title.english"
      ],
      "type": "most_fields" 
    }
  }
}

Предыдущий запрос выполняется как следующий булев запрос:

GET articles/_search
{
  "query": {
    "bool": {
      "should": [
        { "match": { "title": "гренки с маслом" }},
        { "match": { "title.english": "гренки с маслом" }}
      ]
    }
  }
}

Расчет релевантности

Чтобы рассчитать релевантность, баллы документа для всех клауз совпадений складываются, а затем результат делится на количество клауз совпадений.

Включение поля title.english позволяет получить второй документ, который соответствует стеммированным токенам:

{
  "took": 9,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 2,
      "relation": "eq"
    },
    "max_score": 1.4418206,
    "hits": [
      {
        "_index": "articles",
        "_id": "1",
        "_score": 1.4418206,
        "_source": {
          "title": "Гренки с маслом"
        }
      },
      {
        "_index": "articles",
        "_id": "2",
        "_score": 0.09304003,
        "_source": {
          "title": "Масло на тосте"
        }
      }
    ]
  }
}

Поскольку оба поля title и title.english совпадают для первого документа, он имеет более высокий балл релевантности.

Оператор и минимальное количество совпадений

Запросы best_fields и most_fields генерируют запрос match на основе полей (по одному для каждого поля). Таким образом, параметры minimum_should_match и operator применяются к каждому полю, что обычно не является желаемым поведением.

Например, рассмотрим индекс customers со следующими документами:

PUT customers/_doc/1 
{
  "first_name": "John",
  "last_name": "Doe"
}

PUT customers/_doc/2 
{
  "first_name": "Jane",
  "last_name": "Doe"
}

Если вы ищете “John Doe” в индексе customers, вы можете составить следующий запрос:

GET customers/_validate/query?explain
{
  "query": {
    "multi_match" : {
      "query": "John Doe",
      "type": "best_fields",
      "fields": [ "first_name", "last_name" ],
      "operator": "and" 
    }
  }
}

Цель оператора and в этом запросе — найти документ, который соответствует “John” и “Doe”. Однако запрос не возвращает никаких результатов. Вы можете узнать, как выполняется запрос, запустив API валидации:

GET customers/_validate/query?explain
{
  "query": {
    "multi_match" : {
      "query": "John Doe",
      "type": "best_fields",
      "fields": [ "first_name", "last_name" ],
      "operator": "and" 
    }
  }
}

Из ответа вы можете увидеть, что запрос пытается сопоставить как “John”, так и “Doe” с полем first_name или last_name:

{
  "_shards": {
    "total": 1,
    "successful": 1,
    "failed": 0
  },
  "valid": true,
  "explanations": [
    {
      "index": "customers",
      "valid": true,
      "explanation": "((+first_name:john +first_name:doe) | (+last_name:john +last_name:doe))"
    }
  ]
}

Поскольку ни одно из полей не содержит оба слова, результаты не возвращаются.

Лучшей альтернативой для поиска по полям является использование запроса cross_fields. В отличие от ориентированных на поля запросов best_fields и most_fields, запрос cross_fields ориентирован на термины.

Запрос cross_fields

Используйте запрос cross_fields, чтобы искать данные по нескольким полям. Например, если индекс содержит данные о клиентах, имя и фамилия клиента находятся в разных полях. Тем не менее, когда вы ищете “John Doe”, вы хотите получить документы, в которых “John” находится в поле first_name, а “Doe” — в поле last_name.

Запрос most_fields не работает в этом случае по следующим причинам:

  • Параметры operator и minimum_should_match применяются на уровне полей, а не на уровне терминов.
  • Частоты терминов в полях first_name и last_name могут привести к неожиданным результатам. Например, если чье-то имя — “Doe”, документ с этим именем будет считаться лучшим совпадением, поскольку это имя не появится в других документах.

Запрос cross_fields анализирует строку запроса на отдельные термины и затем ищет каждый из терминов в любом из полей, как если бы они были одним полем.

Пример запроса cross_fields для “John Doe”:

GET /customers/_search
{
  "query": {
    "multi_match" : {
      "query": "John Doe",
      "type": "cross_fields",
      "fields": [ "first_name", "last_name" ],
      "operator": "and"
    }
  }
}

Ответ содержит единственный документ, в котором присутствуют как “John”, так и “Doe”:

{
  "took": 19,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "max_score": 0.8754687,
    "hits": [
      {
        "_index": "customers",
        "_id": "1",
        "_score": 0.8754687,
        "_source": {
          "first_name": "John",
          "last_name": "Doe"
        }
      }
    ]
  }
}

Вы можете использовать операцию API валидации, чтобы получить представление о том, как выполняется предыдущий запрос:

GET /customers/_validate/query?explain
{
  "query": {
    "multi_match" : {
      "query": "John Doe",
      "type": "cross_fields",
      "fields": [ "first_name", "last_name" ],
      "operator": "and"
    }
  }
}

Из ответа вы можете увидеть, что запрос ищет все термины хотя бы в одном поле:

{
  "_shards": {
    "total": 1,
    "successful": 1,
    "failed": 0
  },
  "valid": true,
  "explanations": [
    {
      "index": "customers",
      "valid": true,
      "explanation": "+blended(terms:[last_name:john, first_name:john]) +blended(terms:[last_name:doe, first_name:doe])"
    }
  ]
}

Таким образом, смешивание частот терминов для всех полей решает проблему различия частот терминов, корректируя различия.

Запрос cross_fields обычно полезен только для коротких строковых полей с коэффициентом 1. В других случаях балл не дает значимого смешивания статистики терминов из-за того, как коэффициенты, частоты терминов и нормализация длины влияют на балл.

Параметр fuzziness не поддерживается для запросов cross_fields.

Анализ

Запрос cross_fields работает как термоцентричный запрос для полей с одинаковым анализатором. Поля с одинаковым анализатором группируются вместе, и эти группы комбинируются с помощью булевого запроса.

Например, рассмотрим индекс, в котором поля first_name и last_name анализируются с использованием стандартного анализатора, а их подполе .edge анализируется с помощью анализатора edge n-gram:

Пример

Вы индексируете один документ в индексе customers:

PUT /customers/_doc/1
{
  "first": "John",
  "last": "Doe"
}

Вы можете использовать запрос cross_fields для поиска по полям для “John Doe”:

GET /customers/_search
{
  "query": {
    "multi_match": {
      "query": "John",
      "type": "cross_fields",
      "fields": [
        "first_name", "first_name.edge",
        "last_name", "last_name.edge"
      ]
    }
  }
}

Чтобы увидеть, как выполняется запрос, вы можете использовать API валидации:

GET /customers/_validate/query?explain
{
  "query": {
    "multi_match": {
      "query": "John",
      "type": "cross_fields",
      "fields": [
        "first_name", "first_name.edge",
        "last_name", "last_name.edge"
      ]
    }
  }
}

Ответ показывает, что поля last_name и first_name сгруппированы вместе и рассматриваются как одно поле. Аналогично, поля last_name.edge и first_name.edge также сгруппированы и рассматриваются как одно поле:

{
  "_shards": {
    "total": 1,
    "successful": 1,
    "failed": 0
  },
  "valid": true,
  "explanations": [
    {
      "index": "customers",
      "valid": true,
      "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])))"
    }
  ]
}

Использование параметров operator или minimum_should_match с несколькими группами полей, как описано выше, может привести к проблемам. Чтобы избежать этого, вы можете переписать предыдущий запрос как два подзапроса cross_fields, объединенных с помощью булевого запроса, и применить minimum_should_match к одному из подзапросов:

GET /customers/_search
{
  "query": {
    "bool": {
      "should": [
        {
          "multi_match": {
            "query": "John Doe",
            "type": "cross_fields",
            "fields": [
              "first_name",
              "last_name"
            ],
            "minimum_should_match": "1"
          }
        },
        {
          "multi_match": {
            "query": "John Doe",
            "type": "cross_fields",
            "fields": [
              "first_name.edge",
              "last_name.edge"
            ]
          }
        }
      ]
    }
  }
}

Чтобы создать одну группу для всех полей, укажите анализатор в вашем запросе:

GET /customers/_search
{
  "query": {
    "multi_match": {
      "query": "John Doe",
      "type": "cross_fields",
      "analyzer": "standard",
      "fields": ["first_name", "last_name", "*.edge"]
    }
  }
}

Запуск API валидации для предыдущего запроса показывает, как выполняется запрос:

{
  "_shards": {
    "total": 1,
    "successful": 1,
    "failed": 0
  },
  "valid": true,
  "explanations": [
    {
      "index": "customers",
      "valid": true,
      "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])"
    }
  ]
}

Фразовый запрос

Фразовый запрос ведет себя аналогично запросу best_fields, но использует запрос match_phrase вместо match.

Следующий пример демонстрирует фразовый запрос для индекса, описанного в разделе best_fields:

GET articles/_search
{
  "query": {
    "multi_match": {
      "query": "northern lights",
      "type": "phrase",
      "fields": ["title", "description"]
    }
  }
}

Предыдущий запрос выполняется как следующий запрос dis_max с match_phrase для каждого поля:

GET articles/_search
{
  "query": {
    "dis_max": {
      "queries": [
        { "match_phrase": { "title": "northern lights" }},
        { "match_phrase": { "description": "northern lights" }}
      ]
    }
  }
}

Поскольку по умолчанию фразовый запрос совпадает с текстом только тогда, когда термины появляются в одном и том же порядке, в результатах возвращается только документ 1:

Ответ

{
  "took": 3,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "max_score": 0.84407747,
    "hits": [
      {
        "_index": "articles",
        "_id": "1",
        "_score": 0.84407747,
        "_source": {
          "title": "Aurora borealis",
          "description": "Northern lights, or aurora borealis, explained"
        }
      }
    ]
  }
}

Вы можете использовать параметр slop, чтобы разрешить наличие других слов между словами в фразе запроса. Например, следующий запрос принимает текст как совпадение, если между словами “fluorescent” и “therapy” находится до двух слов:

GET articles/_search
{
  "query": {
    "multi_match": {
      "query": "fluorescent therapy",
      "type": "phrase",
      "fields": ["title", "description"],
      "slop": 2
    }
  }
}

Ответ

В этом случае ответ содержит документ 2:

{
  "took": 3,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "max_score": 0.7003825,
    "hits": [
      {
        "_index": "articles",
        "_id": "2",
        "_score": 0.7003825,
        "_source": {
          "title": "Sun deprivation in the Northern countries",
          "description": "Using fluorescent lights for therapy"
        }
      }
    ]
  }
}

Для значений slop, меньших чем 2, документы не возвращаются.

Параметр fuzziness не поддерживается для фразовых запросов.

Фразовый префиксный запрос

Фразовый префиксный запрос ведет себя аналогично фразовому запросу, но использует запрос match_phrase_prefix вместо match_phrase.

Следующий пример демонстрирует фразовый префиксный запрос для индекса, описанного в разделе best_fields:

GET articles/_search
{
  "query": {
    "multi_match": {
      "query": "northern light",
      "type": "phrase_prefix",
      "fields": ["title", "description"]
    }
  }
}

Предыдущий запрос выполняется как следующий запрос dis_max с match_phrase_prefix для каждого поля:

GET articles/_search
{
  "query": {
    "dis_max": {
      "queries": [
        { "match_phrase_prefix": { "title": "northern light" }},
        { "match_phrase_prefix": { "description": "northern light" }}
      ]
    }
  }
}

Вы можете использовать параметр slop, чтобы разрешить наличие других слов между словами в фразе запроса.

Параметр fuzziness не поддерживается для фразовых префиксных запросов.

Булевый префиксный запрос

Булевый префиксный запрос оценивает документы аналогично запросу most_fields, но использует запрос match_bool_prefix вместо match.

Следующий пример демонстрирует булевый префиксный запрос для индекса, описанного в разделе best_fields:

GET articles/_search
{
  "query": {
    "multi_match": {
      "query": "li northern",
      "type": "bool_prefix",
      "fields": ["title", "description"]
    }
  }
}

Предыдущий запрос выполняется как следующий запрос dis_max с match_bool_prefix для каждого поля:

GET articles/_search
{
  "query": {
    "dis_max": {
      "queries": [
        { "match_bool_prefix": { "title": "li northern" }},
        { "match_bool_prefix": { "description": "li northern" }}
      ]
    }
  }
}

Параметры fuzziness, prefix_length, max_expansions, fuzzy_rewrite и fuzzy_transpositions поддерживаются для терминов, которые используются для построения термовых запросов, но они не оказывают влияния на префиксный запрос, построенный из конечного термина.

Параметры

Запрос принимает следующие параметры. Все параметры, кроме query, являются необязательными.

  • query (Строка): Строка запроса, используемая для поиска. Обязательный параметр.

  • auto_generate_synonyms_phrase_query (Булев): Указывает, следует ли автоматически создавать фразу запроса для многословных синонимов. Например, если вы укажете ba, batting average как синонимы и выполните поиск по ba, OpenSearch будет искать ba ИЛИ “batting average” (если этот параметр установлен в true) или ba ИЛИ (batting И average) (если этот параметр установлен в false). По умолчанию true.

  • analyzer (Строка): Анализатор, используемый для токенизации текста строки запроса. По умолчанию используется анализатор, указанный для поля default_field на этапе индексации. Если анализатор не указан для default_field, используется стандартный анализатор для индекса.

  • boost (Число с плавающей запятой): Увеличивает вес условия на заданный множитель. Полезно для оценки условий в составных запросах. Значения в диапазоне [0, 1) уменьшают релевантность, а значения больше 1 увеличивают релевантность. По умолчанию 1.

  • fields (Массив строк): Список полей, в которых следует выполнять поиск. Если вы не укажете параметр fields, запрос multi_match будет искать в полях, указанных в настройке index.query.default_field, которая по умолчанию равна *.

  • fuzziness (Строка): Количество изменений символов (вставка, удаление, замена), необходимых для преобразования одного слова в другое при определении, соответствует ли термин значению. Например, расстояние между wined и wind равно 1. Допустимые значения — неотрицательные целые числа или AUTO. По умолчанию AUTO выбирает значение в зависимости от длины каждого термина и является хорошим выбором для большинства случаев.

  • fuzzy_rewrite (Строка): Определяет, как OpenSearch переписывает запрос. Допустимые значения: constant_score, scoring_boolean, constant_score_boolean, top_terms_N, top_terms_boost_N и top_terms_blended_freqs_N. Если параметр fuzziness не равен 0, запрос использует метод переписывания fuzzy_rewrite по умолчанию top_terms_blended_freqs_${max_expansions}. По умолчанию constant_score.

  • fuzzy_transpositions (Булев): Установка fuzzy_transpositions в true (по умолчанию) добавляет перестановки соседних символов к операциям вставки, удаления и замены в параметре fuzziness. Например, расстояние между wind и wnid равно 1, если fuzzy_transpositions равно true (перестановка “n” и “i”) и 2, если false (удаление “n”, вставка “n”). По умолчанию является хорошим выбором для большинства случаев.

  • lenient (Булев): Установка lenient в true игнорирует несоответствия типов данных между запросом и полем документа. Например, строка запроса “8.2” может соответствовать полю типа float. По умолчанию false.

  • max_expansions (Положительное целое число): Максимальное количество терминов, к которым может расширяться запрос. Неопределенные запросы “расширяются” до числа соответствующих терминов, которые находятся в пределах указанного расстояния в параметре fuzziness. По умолчанию 50.

  • minimum_should_match (Положительное или отрицательное целое число, положительный или отрицательный процент, комбинация): Если строка запроса содержит несколько поисковых терминов и вы используете оператор or, количество терминов, которые должны соответствовать, чтобы документ считался совпадением. Например, если minimum_should_match равно 2, wind often rising не соответствует The Wind Rises. Если minimum_should_match равно 1, совпадает. Для подробностей см. Minimum should match.

  • operator (Строка): Если строка запроса содержит несколько поисковых терминов, нужно ли, чтобы все термины соответствовали (AND) или только один термин должен соответствовать (OR), чтобы документ считался совпадением. Допустимые значения:

    • OR: Строка интерпретируется как “или”.
    • AND: Строка интерпретируется как “и”. По умолчанию используется OR.

  • prefix_length (Неотрицательное целое число): Количество начальных символов, которые не учитываются при вычислении fuzziness. По умолчанию 0.

  • slop (0 по умолчанию или положительное целое число): Контролирует степень, в которой слова в запросе могут быть перепутаны и все еще считаться совпадением. Из документации Lucene: “Количество других слов, разрешенных между словами в фразе запроса. Например, чтобы поменять местами два слова, требуется два перемещения (первое перемещение ставит слова друг на друга), поэтому для разрешения перестановок фраз значение slop должно быть не менее двух. Значение ноль требует точного совпадения.” Поддерживается для типов запросов phrase и phrase_prefix.

  • tie_breaker (Число с плавающей запятой): Фактор между 0 и 1.0, который используется для придания большего веса документам, соответствующим нескольким условиям запроса. Для получения дополнительной информации см. параметр tie_breaker.

  • type (Строка): Тип запроса multi-match. Допустимые значения: best_fields, most_fields, cross_fields, phrase, phrase_prefix, bool_prefix. По умолчанию используется best_fields.

  • zero_terms_query (Строка): В некоторых случаях анализатор удаляет все термины из строки запроса. Например, анализатор стоп-слов удаляет все термины из строки, кроме “this”. В таких случаях zero_terms_query указывает, следует ли не соответствовать ни одному документу (none) или всем документам (all). Допустимые значения: none и all. По умолчанию используется none.

Параметр fuzziness не поддерживается для запросов типов phrase, phrase_prefix и cross_fields.

Параметр slop поддерживается только для запросов типов phrase и phrase_prefix.

Параметр tie_breaker:

Каждый запрос на уровне терминов с объединением вычисляет оценку документа как наилучшую оценку, возвращенную любым полем в группе. Оценки от всех объединенных запросов складываются, чтобы получить окончательную оценку. Вы можете изменить способ вычисления оценки, используя параметр tie_breaker. Параметр tie_breaker принимает следующие значения:

  • 0.0 (по умолчанию для запросов типов best_fields, cross_fields, phrase и phrase_prefix): Берется единственная наилучшая оценка, возвращенная любым полем в группе.

  • 1.0 (по умолчанию для запросов типов most_fields и bool_prefix): Складываются оценки для всех полей в группе.

  • Число с плавающей запятой в диапазоне (0, 1): Берется единственная наилучшая оценка наилучшего соответствующего поля и добавляется (tie_breaker * _score) для всех других соответствующих полей.