Solr NGramTokenizerFactory и PatternReplaceCharFilterFactory — результаты анализатора не соответствуют результатам запроса

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

Я пытаюсь заставить пользовательский ввод соответствовать моему индексу NGram (minGramSize=2, maxGramSize=2). Моя схема индексации и времени запроса приведена ниже, в которой

  1. Я удаляю все небуквенно-цифровые символы, используя PatternReplaceCharFilter.
  2. Я токенизирую с помощью NGramTokenizerFactory.
  3. Я использую нижний регистр, используя LowerCaseFilterFactory (что оставляет небуквенные токены на месте, поэтому мои числа останутся).

Используя приведенную ниже схему, я полагаю, что поиск «PCB-1260» (с правильно экранированным тире) должен соответствовать индексированному Ngram токенизированному и прописному значению «Arochlor-1260» (т. е. биграммы для 1260 равны «12 26 60" как в индексированном, так и в запрошенном значении).

К сожалению, я не получаю никаких результатов, пока не удалю тире. [EDIT - даже когда я правильно избегаю тире и оставляю его в запросе, я также не получаю результатов]. Это кажется странным, потому что я делаю полную замену шаблона всех буквенно-цифровых символов, используя PatternReplaceCharFilter, который, как я полагаю, удаляет все пробелы и тире.

Анализатор запросов на странице администратора показывает правильное сопоставление с использованием приведенной ниже схемы, поэтому я немного растерялся. Есть ли что-то фундаментальное в PatternReplaceCharFilter или NGramTokenizerFactory, чего я здесь не учел?

Я проверил код и другие сообщения, но не могу понять это. После недели биться головой о стену, я отдаю это на рассмотрение стека....

<fieldtype name="tokentext" class="solr.TextField" positionincrementgap="100">
    <analyzer type="index">
        <charfilter class="solr.PatternReplaceCharFilterFactory" pattern="([^A-Za-z0-9])" replacement=""/>
        <tokenizer class="solr.NGramTokenizerFactory" mingramsize="2" maxgramsize="2"/>
        <filter class="solr.LowerCaseFilterFactory"/>
    </analyzer>
    <analyzer type="query">
        <charfilter class="solr.PatternReplaceCharFilterFactory" pattern="[^A-Za-z0-9]" replacement=""/>
        <tokenizer class="solr.NGramTokenizerFactory" mingramsize="2" maxgramsize="2"/>
        <filter class="solr.LowerCaseFilterFactory"/>
    </analyzer>
</fieldtype>

regex solr n-gram
person Josh    schedule 23.06.2011    source источник
comment
Думаю, это останется загадкой...   -  person Josh    schedule 01.07.2011

Ответы (1)


arrow_upward
0
arrow_downward

Итак, что-то определенно странное с PatternReplaceCharFilter, который не может удалить тире во время запроса. В конечном счете, я просто выполнил предварительную обработку в php пользовательского ввода с помощью preg_replace перед отправкой в ​​Solr, и — альт! - работал как шарм с ожидаемыми результатами. Удивительно, что PatternReplaceCharFilter не вел себя...

Вот php-код предварительного запроса, который я использовал, чтобы избавиться от тире, если кому-то это нужно.

$pattern = '/([-])/';
$replacement = ' ';
$usrpar = preg_replace($pattern, $replacement, $raw_user_search_contents);
$res = htmlentities($usrpar, ENT_QUOTES, 'utf-8');

После этого я просто передал $res Solr...

person Josh    schedule 08.07.2011
comment
У меня была аналогичная проблема на этой неделе, но с амперсандами. Ответ заключался в том, что, пока я использовал амперсанд (кодированный URL-адрес% 26), мне нужно было найти объект HTML ''. Возможно, ваши результаты также интерпретируются индексатором как объекты HTML. - person mattdeboard; 14.12.2011