Доброго времени суток!
Есть индекс и поле в нем построенное со стеммингом.
Не получается сделать поиск полной фразы.
Т.е. на пример, надо найти точно "Электронный документ".
Как ни пытался - ES первым выводит более длинное значение, какой-нибудь "Справочник по электронному документообороту".
Возможно ли это побороть или переделывать индексы?
А если переделывать как правильно?
Ведь получается, что нужны и полные слова и "обрезки".
Целые для поиска точных фраз и обрезки для всяких не точных поисков.
Или вообще по другому делается?
Обычно, в таких случаях поле индексируют дважды - один раз как со стемингом и синонимами и второй раз без. Поиск осуществляется по обоим полям с бустом. Примеры можно в этой презентации посмотреть.
Отлично! Большое спасибо. В приведенном примере my_type сразу два аналайзера применяется, дополнительных движений не нужно?
Нужно. Запрос на следующем слайде.
Ну про это то я догадался 
Я имел ввиду, что при индексации не надо данные в два поля посылать:
put /my_index/my_type
{ "my_text": "some text",
"my_text.with_synonyms": "some text"
}
Да, оба поля будет созданы автоматически из одного поля исходного документа.
А имеет смысл вырезать стоп слова из оригинальных токенов (без синонимов)?
Я, лично, стоп слова недолюбливаю. Считаю вреда от них больше чем пользы, особенное, если бездумно брать готовый список слов от куда-нибудь. Стандартный список русских стоп слов тут, например. С моей точки зрения, он слишком большой, и зачем туда такие слова, как человек и жизнь засунули - я просто ума не приложу. К тому-же без стемминга такой список стоп слов в русском бесполезен - так как слова в нем заданы только в одной форме.
Единственный случай, когда стоп-слова действительно полезны, с моей точки зрения, это если надо чтобы детишки в школе матерные слова в индексе не могли найти, а контролировать, что в индекс добавляется не возможности. В этом случае, добавляешь мат в файл, грузишь как стоп слова, и все - дешево и сердито. Но, опять-же, в английском, это все просто делается, а в русском - все надо через стеммер пропускать, чтобы многоэтажный мат отловить.
Я поэтому и спрашиваю, что пресловутое "быть или не быть", как фразу не найти.
Вот и выходит, что первый индекс должен быть просто "standard", а второй более хитрый.
И пока я думаю, что должен стандартный токенайзер, а дальше фильты
lowcase ->stop_word -> keyword -> russian_morphology -> engilish_morphlogy -> synonym
- lowcase - чтобы потом не заботиться о регистре написания
- stop_word. - т.к. они в первом индексе есть тут их можно нещадно резать.
- keyword - для всяких исключений и сокращений: СССР, КГБ, ЯрГУ
- russian_morphology - как минимум, мне не понравилось как стеммер swonball с русскими фамилиями работает.
- engilish_morphlogy - до кучи
- synonym - синонимы в нормальной форме.
Есть конечно еще некоторые сомнения:
- Резать ли цифры? Их же много. Но ведь найдется гений, который будет искать организацию по ИНН.
- Нужны ли nGram-ы для всяких нечетких поисков. Если нужны то получается, нужно делать третий индекс. Ибо по опыту сочетание стеммера и nGram даёт не однозначный результат.
В общем, если есть мудрость поделитесь
Понятно, что у всех свои нюансы, но ведь есть общие принципы которые подойдут 98%% задач по поиску в русском тексте.
Как я пытался объяснить в предыдущем сообщении stop_word перед стеммером работать не будет, если только вы все возможные словоформы для каждой лексемы туда на добавите. Поэтому обычно делают так lowercase -> keyword -> russian_morphology -> engilish_morphlogy -> stop_word -> synonym
-
На этот вопрос ответить сложно без внимательного изучения ваших данных и как ваши пользователи привыкли искать и какой тип поиска вы хотите поддерживать.
-
Да, nGram со стеммером применять бессмысленно, так как они и тот и другой выполняет по-сути одну и туже функцию. Если поиск по подстрокам нужен, лучше проиндексировать еще раз.
До редактирования поста так и было 
А потом пришла такая мысль:
- Составить достаточно полный словарь задача посильная.
- Сложность зависит (почти) только от объема входных данных
- Если количество stop слов 30%, то объем на выходе на треть меньше.
- Поэтому вырезать сразу лишнее интереснее.
Получается, что если нужен поиск по подстрокам, то нет смысла вообще связываться со стеммером и морфологическим разбором?
Для меня это взаимозаменяемые решения. Выбор решения зависит от типа и объема данных (ngrams производят больше токенов и размер индекса, как правило получается больше) и предпочтений пользователей (некоторые пользователи предпочитают подстроки, потому что им так проще понять почему они получили тот или иной результат).
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.