Поиск с использованием различных комбинаций пробелов, дефисов, регистров и знаков препинания.

Мы рассматривали слова через дефис как особый случай и написали собственный анализатор, который использовался во время индексации для создания трех версий этого токена, поэтому в вашем случае wal-mart станет walmart, wal-mart и wal-mart. Каждый из этих синонимов был написан с использованием пользовательского фильтра SynonymFilter, который изначально был адаптирован из примера из книги Lucene in Action. SynonymFilter располагался между токенизатором пробелов и токенизатором нижнего регистра.

Во время поиска любая из трех версий будет соответствовать одному из синонимов в индексе.

Почему «WalMart» не соответствует «Walmart» с моей исходной схемой?

Потому что вы определили параметр mm вашего обработчика DisMax/eDismax со слишком высоким значением. Я поиграл с этим. Когда вы определяете значение mm равным 100%, вы не получите соответствия. Но почему?

Потому что вы используете один и тот же анализатор для времени запроса и индекса. Ваш поисковый запрос «WalMart» разделен на 3 токена (слова). А именно это «вал», «март» и «валмарт». Solr теперь будет обрабатывать каждое слово отдельно при подсчете до <str name="mm">100%</str>*.

Кстати, я воспроизвел вашу проблему, но проблема возникает при индексации Walmart, но при запросе с WalMart. При выполнении наоборот все работает нормально.

Вы можете переопределить это, используя LocalParams, вы можете перефразировать свой запрос следующим образом {!mm=1}WalMart.

Есть более сложные, такие как [ ... ] «Макдональдс» [ чтобы соответствовать ] Слова с другими знаками препинания: «Мак-Дональд Инжиниринг Компани, Инк.»

Здесь также помогает игра с параметром mm.

В общем, как лучше всего моделировать схему с такими требованиями?

Здесь я согласен с Sujit Pal, вы должны пойти и реализовать собственную копию SynonymFilter. Почему? Потому что он работает иначе, чем другие фильтры и токенизаторы. Он создает токены вместо смещения проиндексированных слов.

Что на месте? Это не увеличит количество токенов вашего запроса. И вы можете выполнить обратный перенос (соединение двух слов, разделенных пробелом).

Но нам не хватает хорошего synonyms.txt, и мы не можем поддерживать его в актуальном состоянии.

При расширении или копировании SynonymFilter игнорируйте статическое отображение. Вы можете удалить код, который отображает слова. Вам просто нужна обработка смещения.

Обновление Я думаю, вы также можете попробовать PatternCaptureGroupTokenFilter, но работа с названиями компаний с помощью регулярных выражений вскоре может столкнуться с его ограничениями. Я посмотрю на это позже.

* Вы можете найти это в своем solrconfig.xml, поищите свой <requestHandler ... />

Я позволю себе сначала внести некоторые коррективы в анализатор. Я считаю, что WordDelimiterFilter функционально является вторым этапом токенизации, поэтому давайте поместим его сразу после Tokenizer. После этого нет необходимости поддерживать регистр, поэтому далее идет нижний регистр. Это лучше для вашего StopFilter, поскольку нам больше не нужно беспокоиться об игноркейсе. Затем добавьте стеммер.

<tokenizer class="solr.WhitespaceTokenizerFactory"/>
<filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="0" splitOnCaseChange="1" splitOnNumerics="0"/>
<filter class="solr.LowerCaseFilterFactory"/>
<filter class="solr.StopFilterFactory"
        words="stopwords.txt"
        enablePositionIncrements="true"
        />
<filter class="solr.SnowballPorterFilterFactory" language="English" protected="protwords.txt"/>

В общем, это не за горами. Основная проблема заключается в том, что «Wal Mart» против «Walmart». Для каждого из них WordDelimiterFilter не имеет к этому никакого отношения, здесь разделяется токенизатор. «Wal Mart» разделяется токенизатором. «Walmart» никогда не разделяется, поскольку никто не может разумно знать, где он должен быть разделен.

Одним из решений для этого было бы использовать вместо этого KeywordTokenizer и позволить WordDelimiterFilter выполнять всю токенизацию, но это приведет к другим проблемам (особенно при работе с более длинным и сложным текстом, таким как ваш " Пример Mc-Donald Engineering Company, Inc. будет проблематичным).

Вместо этого я бы рекомендовал ShingleFilter. Это позволяет вам объединять соседние токены в один токен для поиска. Это означает, что при индексировании «Wal Mart» он будет использовать токены «wal» и «mart», а также индексировать термин «walmart». Обычно он также вставляет разделитель, но в этом случае вы захотите переопределить это поведение и указать разделитель "".

Теперь мы поместим ShingleFilter в конец (он может испортить стемминг, если вы поместите его перед стеммером):

<tokenizer class="solr.WhitespaceTokenizerFactory"/>
<filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="0" splitOnCaseChange="1" splitOnNumerics="0"/>
<filter class="solr.LowerCaseFilterFactory"/>
<filter class="solr.StopFilterFactory"
        words="stopwords.txt"
        enablePositionIncrements="true"
        />
<filter class="solr.SnowballPorterFilterFactory" language="English" protected="protwords.txt"/>
<filter class="solr.ShingleFilterFactory" maxShingleSize="2" tokenSeparator=""/>

Это создаст только 2 последовательных токена (а также исходные одиночные токены), поэтому я предполагаю, что вам не нужно совпадать больше, чем это (если вам нужно «doremi», чтобы соответствовать «Do Re Mi ", например). Но для приведенных примеров это работает в моих тестах.

Обновление версии Lucene (с 4.4 до 4.10) в solrconfig.xml волшебным образом устранило проблему! У меня больше нет ограничений, и мой анализатор запросов ведет себя так, как ожидалось.