Бизнес-ранжирование

Кандидаты и предпочтения

Сначала отделяют обязательные ограничения: доступ к данным, наличие и допустимая категория. Затем ранжируют подходящих кандидатов. Популярный товар другой категории не должен появляться только из-за большого бизнес-сигнала. У каждого сигнала есть диапазон и распределение: число продаж от 0 до миллиона нельзя бездумно складывать с текстовым score.

Функции и нормализация

function_score объединяет исходную оценку и функции через boost_mode и score_mode. field_value_factor использует числовое поле; логарифмические модификаторы помогают сжать большие значения, но требуют допустимого диапазона. Decay functions постепенно уменьшают вклад с удалением от даты, цены или координаты. rank_feature рассчитан на подготовленные положительные признаки и требует соответствующего mapping.

Скрипты и второй этап

script_score гибок, но вычисления на многих кандидатах могут быть дорогими. Итоговый score должен быть допустимым неотрицательным числом. Rescore применяет более дорогую оценку к окну лучших документов на каждом шарде; слишком маленькое окно ограничивает возможные улучшения. Проверяйте не только верхний товар, но и устойчивость порядка для редких запросов и отсутствующих признаков.

{
  "query": {
    "function_score": {
      "query": {
        "match": {
          "name": "headphones"
        }
      },
      "field_value_factor": {
        "field": "rating",
        "modifier": "sqrt",
        "missing": 1
      },
      "boost_mode": "multiply"
    }
  }
}

Разбор на примере каталога

Представьте текстовые score 8 и 6 и продажи 10 и 100000. Простое умножение почти гарантированно продвинет второй товар независимо от текстовой разницы. Логарифм или функция насыщения сжимает масштаб, а ограниченное влияние сохраняет шанс сильного текстового совпадения. Не выбирайте коэффициент по этим двум числам: проверьте распределение продаж, товары без истории, новые товары и запросы по точным моделям. У каждого случая могут быть разные последствия для бизнеса.

Релевантность с ограничениями

Разделите три роли: must описывает текстовую релевантность, filter — допуск, must_not — исключения. Пример ищет travel по name^3 и description, требует наличие и цену ниже 800, затем исключает preorder. multi_match должен оставаться в поисковом пути must, а не внутри локального или внешнего filter.

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

{
  "query": {
    "bool": {
      "must": [
        {
          "multi_match": {
            "query": "travel",
            "fields": [
              "name^3",
              "description"
            ]
          }
        }
      ],
      "filter": [
        {
          "term": {
            "in_stock": true
          }
        },
        {
          "range": {
            "price": {
              "lt": 800
            }
          }
        }
      ],
      "must_not": [
        {
          "term": {
            "status": "preorder"
          }
        }
      ]
    }
  },
  "size": 2,
  "_source": [
    "name",
    "price",
    "status",
    "in_stock"
  ]
}

{
  "hits": {
    "total": {
      "value": 34,
      "relation": "eq"
    },
    "hits": [
      {
        "_id": "23",
        "_score": 4.8997154,
        "_source": {
          "name": "Dell Travel Speaker 23",
          "price": 100,
          "in_stock": true,
          "status": "discontinued"
        }
      },
      {
        "_id": "53",
        "_score": 4.8997154,
        "_source": {
          "name": "Dell Travel Speaker 53",
          "price": 100,
          "in_stock": true,
          "status": "discontinued"
        }
      }
    ]
  }
}