Многопользовательский синоним поиска в Solr

Question

Я пытаюсь использовать фильтр синонима для поиска фразы.

peter=> spider man, spiderman, Mary Jane, ..... 

Я использую конфигурацию по умолчанию. Когда я ставлю эти синонимы в synonym.txt и перезапустить Solr, кажется, работает только частично: он начинает искать "spider", "man", "spiderman", "Mary" и "Jane" но то, что я хочу, чтобы искать являются осмысленные комбинации - как "spider man", "Mary Jane" и "spiderman".

Answer 1

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

Например, с этой линией в моем fieldType/analyzer блоке в schema.xml:

<filter class="solr.SynonymFilterFactory" synonyms="synonyms.txt" ignoreCase="true" expand="false"/> 

(Обратите внимание на expand="false")
... и эту строку в моей synonyms.txt:

spiderman, spider man, Mary Jane => peter 

Таким образом, Я убеждаюсь, что любое из этих четырех значений будет проиндексировано и, как «peter». Например, если в исходном документе упоминается «The Amazing Spider Man», он будет индексироваться как «The Amazing peter». Когда пользователь ищет «Мэри Джейн», он будет искать «peter» вместо этого, поэтому будет соответствовать.

Важно то, что поскольку «Мэри» не является синонимом, разделенным запятыми, он не будет изменен, если он появится без «Джейн». Поэтому поиск «Мэри потрясающий» на самом деле будет искать «Мэри удивительна», и она не будет соответствовать документу.

Одна из важных деталей заключается в том, что я выбираю нормированную форму (например, «peter»), которая является только одним словом. Я мог бы организовать это так:

peter, spiderman, spider man => Mary Jane 

, но потому, что Мэри Джейн два слова, он может (в зависимости от других особенностей моего поиска), соответствуют два слова отдельно, а также вместе. Выбирая единую форму слова для нормализации, я убеждаюсь, что мой токенизатор не попытается разбить его.

Answer 2

Это известное ограничение в Solr/Lucene. По сути, вам придется предоставить альтернативную форму токенизации, так что конкретные пробелы, разделенные пробелами (например, фразы), рассматриваются как отдельные слова. Одним из способов достижения этой цели является выполнение этой клиентской стороны - то есть в приложении, которое вызывает Solr при индексировании, сохраняет список синонимичных фраз и находит/заменяет эти значения фразы альтернативой (например, удаляя пробелы или заменяя их с разделителем, который не рассматривается как граница токена).

E.g. если у вас есть «Hello There» в качестве фразы, которую вы хотите использовать в синониме, затем замените ее «HelloThere» при индексировании.

Теперь в ваших синонимах.текстовый файл вы можете иметь (например):

Hi HelloThere Wotcha => Hello 

Аналогично при поиске, при необходимости заменить число случаев «Привет Там» в строке запроса HelloThere, а затем они будут соответствовать как синоним Hello.

В качестве альтернативы вы можете использовать AutoPhraseTokenFilter, созданный LucidWorks, доступный на github. Это работает, поддерживая токен-поток, чтобы он мог работать, если комбинация из двух или более последовательных токенов соответствует одной из синонимичных фраз, а если нет, то выбрасывает первый токен, не соответствующий фразе. Я не уверен, сколько накладных расходов это добавляет, но это хороший подход - было бы неплохо иметь по умолчанию в Solr в составе SynonymFilter.

Answer 3

Да, к сожалению, это хорошо известная проблема из-за того, как анализирующий анализатор Solr разбивается на пробелы до. Поэтому вместо того, чтобы видеть «паука» перед «человеком» в потоке токенов, вы вместо этого просто видите каждое слово самостоятельно. Просто «паука» с ничего до/после и просто «человек» ни с чем до/после.

Это потому, что большинство форм запроса Solr видят пространство как «OR». Найдите «spider OR man» вместо того, чтобы смотреть полный текст, анализируя его для генерации синонимов, а затем генерируя запрос из этого.

Для более фона, есть this blog post

Там есть большое количество решений этой проблемы, в том числе следующие:

• hon-lucene-synonyms. Этот плагин запускает анализатор перед генерированием запроса edismax по нескольким полям. Это немного черный ящик, и я обнаружил, что он может генерировать некоторые сложные формы запросов, которые генерируют странные ошибки производительности и релевантности.
• Lucidwork's autophrase query parser Избирательно autophrasing, этот плагин позволяет указать ключевые фразы (паук), которые не должны быть разбиты на или запросы, и может иметь расширение синонима примененных
• OpenSource программы Подключение Match query parser. Ищет одно поле, используя запрос анализатора запроса, перед поиском поля. Также ищет многословные синонимы как фразы. Мой любимый, но отказ от ответственности: я автор :)
• Rene Kriegler's Querqy - Querqy - это плагин Solr для правил предварительной обработки запросов. Эти правила могут идентифицировать ваши ключевые фразы и переписать запрос на не-мультитермическую форму.
• Сканируйте самостоятельно: Научитесь писать свой собственный query parser plugin и справляйтесь с проблемой, как хотите.