В документации описан плагин "Delimited Payload Token Filter":
https://www.elastic.co/guide/en/elasticsearch/reference/7.0/analysis-delimited-payload-tokenfilter.html
Зачем он нужен и какая от него польза?
Можно ли как-то влиять на релевантность с помощью payload?
Payload это такая штука, что если вы про него спрашиваете, то вам он скорее всего не нужен 
На релевантность он влиять может, но для этого вам надо написать свой плагин. Встроенных средств на данный момент нет. Польза от него в том, что можно с каждым термином определенную информацию сохранить, которая потом доступна при запросе.
Игорь, огромное спасибо за ответ!
Перечитал вроде бы всю документацию. Фильтр полезной нагрузки описан и больше ничего. Решил, что что-то упустил и решил переспросить.
До версии 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 - это мощный инструмент! Печально, что его не только не довели до ума, но и окончательно забросили. Задать вес или коэффициент отдельному термину в строке - это же избавится от сложных запросов с разбиением данных на разные поля. Надеюсь, этот функционал еще доработают 
Разбиение данных на разные поля в данном случае более предпочтительное решение, так как оно не требует загрузки 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, чтобы учесть, что это разные термины - рескоринг (Improving Performance | Elasticsearch: The Definitive Guide [master] | Elastic)
Но! Поскольку у нас строка адреса разнесена на составляющие поля, чтобы задать вес каждому слову, то мы не сможем сделать match_phrase_prefix - значит нам нужно добавить в документ еще одно поле, в котором бы мы писали всю строку целиком.
Как итог:
- вместо одного поля нужно заводить энное количество!
Это так, но распределиение разных компонентов по разным полям имеет несколько приемуществ. В частности, это позволяет производить аггрегацию, например, по городам, или фильтрацию по регионам.
- проблемное масштабирование и индексация
С масштабированием проблема как раз с payload-ами, по скольку они подтягиваются после поиска и как результат вызывают дополнительную нагрузку на диск.
- перечислять все поля при поиске с указанием веса для каждого поля
Да, но при этом вы динамически сможете менять вес каждого поля без переиндексации. А поля вам все-равно придется определять, хот я бы при индексации.
- все равно создавать дополнительное поле для специфических "подзапросов", в котором хранить все слова
Это можно автоматизировать с помощью copy_to
- размер индекса больше
Единственное, что тут больше - это размер source. Но, это не должно существенно повлиять на производительность.
- как мне кажется - скорость поиска будет все же меньше, особенно при длинных запросах
Думаю, что наоборот, из-за неэффективности работы с payload.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
© 2020. All Rights Reserved - Elasticsearch
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant logo are trademarks of the Apache Software Foundation in the United States and/or other countries.