Ранжирование в поиске: оценка релевантности и настройка порядка

Прямой ответ

Порядок результатов поиска определяется оценкой релевантности — числом, которое движок вычисляет для каждого документа. По умолчанию используется BM25.

BM25 учитывает три фактора: частоту термина в документе, обратную частоту термина в коллекции и длину поля относительно средней.

Насыщение частоты — ключевое отличие BM25 от линейной модели: третье совпадение термина добавляет меньше оценки, чем первое, поэтому документ, где термин повторяется десятки раз, не вытесняет остальные.

Явное усиление полей задаётся в запросе:

{
  "query": {
    "multi_match": {
      "query": "ноутбук 16 дюймов",
      "fields": ["title^3", "brand^2", "description"],
      "type": "best_fields"
    }
  }
}

Совпадение в заголовке учитывается с тройным весом, поэтому документ с термином в заголовке поднимается выше документа с совпадением только в описании.

Функциональное ранжирование добавляет к текстовой оценке факторы, не связанные с текстом:

{
  "query": {
    "function_score": {
      "query": {"match": {"title": "ноутбук"}},
      "functions": [
        {"field_value_factor": {"field": "popularity", "modifier": "log1p", "factor": 2}},
        {"gauss": {"released_at": {"origin": "now", "scale": "180d", "decay": 0.5}}}
      ],
      "boost_mode": "sum"
    }
  }
}

Функция по полю популярности и затухание по дате выпуска изменяют порядок внутри текстово релевантной выборки.

Что ломает ожидаемый порядок выдачи

Настройка ранжирования чаще сводится к устранению причин неправильного порядка, чем к подбору коэффициентов.

Анализатор не совпадает между документом и запросом. Приведение слов выполняется только с одной стороны, поэтому совпадение не находится либо оценивается ниже; о приведении — в статье про лемматизацию и стемминг.

Длина поля искажает оценку. Поле с полным текстом документа оценивается ниже короткого заголовка при том же числе совпадений. Разделение на отдельные поля устраняет смешение.

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

Динамический маппинг назначил неверный тип. Поле, определённое как текст вместо ключевого слова, участвует в анализе и не используется для точной фильтрации.

Вес поля задан без измерения. Коэффициенты, выбранные интуитивно, часто усиливают не то поле, и порядок меняется неожиданно.

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

Отдельная задача — подмешивание коммерческих факторов. Функциональное ранжирование позволяет поднять популярные либо новые документы, но чрезмерный вес фактора вытесняет текстово релевантные результаты. Баланс подбирается по статистике переходов.

Практика: настройка порядка результатов

1. Фиксируйте набор проверочных запросов. Десять-двадцать реальных запросов с ожидаемыми первыми позициями — минимальная основа для оценки изменений.

2. Изменяйте по одному параметру. Одновременное изменение весов и функций не показывает, какой параметр повлиял на порядок.

3. Разделяйте поля по роли. Заголовок, краткое описание и полный текст индексируются отдельными полями с разными весами.

4. Проверяйте объяснение оценки. Запрос с флагом объяснения возвращает разбор вклада каждого фактора для конкретного документа.

5. Используйте фильтры вместо запросов там, где оценка не нужна. Фильтр не вычисляет релевантность и кэшируется, поэтому работает быстрее.

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

7. Собирайте статистику переходов. Позиция, на которой пользователь выбирает результат, показывает качество порядка лучше субъективной оценки.

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

Рекомендации:

1. Не подбирайте веса без измерений. Интуитивный коэффициент часто усиливает поле, которое не определяет релевантность для реальных запросов.
2. Различайте релевантность и полезность. Документ может быть текстово релевантен, но бесполезен пользователю, поэтому учитываются поведенческие сигналы.
3. Учитывайте стоимость объяснения оценки. Режим объяснения замедляет запрос и используется для отладки, а не в продуктивной выдаче.
4. Проверяйте влияние на подсказки ввода. Изменение ранжирования затрагивает и подсказки; о подсказках — в статье про autocomplete.
5. Документируйте принятые веса. Причина выбора коэффициента фиксируется вместе с настройкой, иначе последующая правка выполняется вслепую.

Практический сценарий: релевантный документ опускается ниже нерелевантного

Контекст: запрос по названию модели возвращал на первой позиции документ, где модель упоминалась в длинном описании, а документ с моделью в заголовке оказывался ниже.

1. Диагностика. Объяснение оценки показало, что документ с длинным описанием получил более высокую частоту термина, а длина поля снизила оценку заголовочного документа недостаточно сильно.
2. Причина. Название модели и описание индексировались одним полем, поэтому частота термина складывалась по всему тексту, а преимущество заголовка не учитывалось.
3. Действия. (а) Разделили поле на заголовок и описание с отдельными весами; (б) установили вес заголовка выше веса описания и проверили результат на наборе запросов; (в) выполнили переиндексацию, поскольку изменение маппинга не применяется к существующим сегментам; (г) добавили точное совпадение названия модели с дополнительным весом; (д) зафиксировали набор проверочных запросов в тестах, чтобы изменение весов не проходило без проверки.
4. Результат. Документ с моделью в заголовке занимает первую позицию, а изменение весов проверяется автоматическим прогоном набора запросов.

Вывод: смешение разнородного текста в одном поле искажает оценку релевантности. Разделение полей с разными весами и переиндексация восстанавливают ожидаемый порядок, а фиксация проверочных запросов в тестах делает последующие правки измеримыми.

FAQ

Какая формула релевантности используется по умолчанию? BM25. Она учитывает частоту термина с насыщением, обратную частоту в коллекции и длину поля.

Можно ли отключить вычисление релевантности? Да, для фильтрации без упорядочивания используется фильтр, который не вычисляет оценку и кэшируется.

Что показывает режим объяснения оценки? Разбор вклада каждого фактора для конкретного документа: частоту термина, обратную частоту, нормировку длины поля и применённые веса.

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

Источники: Elasticsearch similarity module, Apache Lucene documentation, Okapi BM25 — ссылки в шапке.