Зачем нужен Payload?

В документации описан плагин "Delimited Payload Token Filter":
https://www.elastic.co/guide/en/elasticsearch/reference/7.0/analysis-delimited-payload-tokenfilter.html

Зачем он нужен и какая от него польза?
Можно ли как-то влиять на релевантность с помощью payload?

Payload это такая штука, что если вы про него спрашиваете, то вам он скорее всего не нужен :slight_smile: На релевантность он влиять может, но для этого вам надо написать свой плагин. Встроенных средств на данный момент нет. Польза от него в том, что можно с каждым термином определенную информацию сохранить, которая потом доступна при запросе.

Игорь, огромное спасибо за ответ!
Перечитал вроде бы всю документацию. Фильтр полезной нагрузки описан и больше ничего. Решил, что что-то упустил и решил переспросить.

До версии 2.4 payload был доступен в function_score запросах:
https://www.elastic.co/guide/en/elasticsearch/reference/2.4/modules-advanced-scripting.html#_term_positions_offsets_and_payloads
Проблема заключалась в том, что термины нужно было передавать вручную, а налету скрипт не имел к ним доступа - то есть отваливается нечеткость поиска.

Сейчас поставил 7 версию ElasticSearch - тут в документации вообще убрали все упоминания payload, оставили только фильтр. И то при установки index_prefixes параметра нельзя использовать term_vector=with_positions_offsets_payloads, чтобы вытаскивать полезную нагрузку.

После версии 6.7 нет ни одного плагина, который бы расширял org.elasticsearch.index.similarity. Я в java не силен и даже примера нет, чтобы попытаться самому написать плагин.

К чему я это все: payload - это мощный инструмент! Печально, что его не только не довели до ума, но и окончательно забросили. Задать вес или коэффициент отдельному термину в строке - это же избавится от сложных запросов с разбиением данных на разные поля. Надеюсь, этот функционал еще доработают :roll_eyes:

Разбиение данных на разные поля в данном случае более предпочтительное решение, так как оно не требует загрузки payload во время поиска.

Какую проблему вы пытаетесь с этим paypload-ом решить?

Давайте в качестве примера рассмотрим распознавание адресов. Этакий аналог дадата.ру ))
Возьмем за основу несколько адресов:

город Москва улица академика Петра Анохина
город Москва улица Юрия Кондратюка
город Киев улица Гната Юры
Московская область город Химки улица Московская

Пользователь может написать слова в любом порядке, делать сокращения (ак. Антохина или Ю. Кондратюка), видоизменять слова (Юрия = Юры), ошибаться в типах (перепутать проезд и переулок, или проспект с улицей), делать очепятки.

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

город^30 Москва^100 улица^20 Юрия^70 Кондратюка^100
город^30 Киев^100 улица^20 Гната^70 Юры^100

Тип компонента адреса (город, улица...) имел бы меньший вес, должности (академика, генерала...) более высокий вес, имена еще больше вес, а точные названия и фамилии самый большой вес. Получается в одной строке есть ключи и дополнения к ключам для поднятия суммарного веса.

Если не делать разбивку по весу, то при запросе "Юры Кондратюка" мы получим вышеописанные две строки, которые будут иметь одинаковый score при similarity = boolean.

Я сейчас даю очень упрощенный пример, просто для обозначения сути проблемы!

Как можно решить задачу с подобным поиском? Делать энное количество полей в документе: отдельно под тип (город, улица), должности, имена, фамилии, варианты написания, сокращения и тд. Дальше делать multi_match запрос с most_fields типом. Это уже усложняет задачу по индексации! Сейчас мы знаем, что нужно к примеру 5 полей, а через месяц будут новые данные и полей будет не 5, а 10. Значит пересоздавать mappings и индекс.

А теперь давайте посмотрим на 4 пример: Московская область город Химки улица Московская - тут у нас слово Московская повторяется дважды. Значит нам нужно делать еще один should запрос match_phrase_prefix и большим slop, чтобы учесть, что это разные термины - рескоринг (https://www.elastic.co/guide/en/elasticsearch/guide/master/_improving_performance.html#rescore-api)

Но! Поскольку у нас строка адреса разнесена на составляющие поля, чтобы задать вес каждому слову, то мы не сможем сделать match_phrase_prefix - значит нам нужно добавить в документ еще одно поле, в котором бы мы писали всю строку целиком.

Как итог:

  1. вместо одного поля нужно заводить энное количество!
  2. проблемное масштабирование и индексация
  3. перечислять все поля при поиске с указанием веса для каждого поля
  4. все равно создавать дополнительное поле для специфических "подзапросов", в котором хранить все слова
  5. размер индекса больше
  6. как мне кажется - скорость поиска будет все же меньше, особенно при длинных запросах
  1. вместо одного поля нужно заводить энное количество!

Это так, но распределиение разных компонентов по разным полям имеет несколько приемуществ. В частности, это позволяет производить аггрегацию, например, по городам, или фильтрацию по регионам.

  1. проблемное масштабирование и индексация

С масштабированием проблема как раз с payload-ами, по скольку они подтягиваются после поиска и как результат вызывают дополнительную нагрузку на диск.

  1. перечислять все поля при поиске с указанием веса для каждого поля

Да, но при этом вы динамически сможете менять вес каждого поля без переиндексации. А поля вам все-равно придется определять, хот я бы при индексации.

  1. все равно создавать дополнительное поле для специфических "подзапросов", в котором хранить все слова

Это можно автоматизировать с помощью copy_to

  1. размер индекса больше

Единственное, что тут больше - это размер source. Но, это не должно существенно повлиять на производительность.

  1. как мне кажется - скорость поиска будет все же меньше, особенно при длинных запросах

Думаю, что наоборот, из-за неэффективности работы с payload.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.