Была ли причина использовать для поиска только поля ngrams? Я не уверен, что это проблема в вашем случае, но вы можете посмотреть конфигурацию анализа ngrams в schema.xml. Один из моих индексов выглядит так:
<fieldType name="ngram" class="solr.TextField" >
<analyzer type="index">
<filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="0" splitOnCaseChange="1"/>
<tokenizer class="solr.LowerCaseTokenizerFactory"/>
<filter class="solr.EdgeNGramFilterFactory" minGramSize="2" maxGramSize="15" side="front"/>
</analyzer>
<analyzer type="query">
<filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="0" splitOnCaseChange="1"/>
<tokenizer class="solr.LowerCaseTokenizerFactory"/>
</analyzer>
</fieldType>
Хотя вы можете видеть, что на самом деле используется более безопасный EdgeNGramFilterFactory, здесь важно отметить minGramSize="2". Это означает, что в процессе индексации будут созданы только граммы, состоящие не менее чем из двух символов. Слово «с»? Это не получает ни грамма на всех. Хотя вы можете установить minGramSize="1" и перестроить свой индекс, односимвольные граммы — очень плохая идея, так как ваш поиск «с» будет соответствовать любому документу со словом, начинающимся с «с» (или содержащим букву «с» с NGramFilterFactory ).
Если вы в настоящее время используете NGrams с minGramSize="2", поиск «ca» найдет любые документы с любыми словами, содержащими буквы «ca» последовательно в этом порядке. Это может быть не совсем то, что вы хотите.
Моим главным предложением было бы отказаться от ngrams в пользу более ванильного текстового поля. Хотите ли вы сохранить edge-ngrams для лучшей поддержки усечения, зависит от вас, но я подозреваю, что вам повезет больше, если поле Text будет хотя бы в миксе.
Вы также можете взглянуть на этот вопрос в StackOverflow: "Могу ли я защитить короткие слова от фильтра n-грамм в Solr?" если вы хотите продолжить изучение n-грамм.
Кроме того, вам следует подумать об использовании встроенного инструмента анализа Solr, чтобы выяснить, где ваши поиски терпят неудачу. Вы выбираете поле или fieldType и предоставляете значения для того, что было введено в индекс и что ищется. Он покажет вам, как анализ работает с обоими значениями, чтобы вы могли увидеть, как разбивается каждая строка и почему она создает или не создает совпадающие токены. URL-адрес инструмента зависит от того, находитесь ли вы в многоядерной среде, но если вы зайдете в веб-интерфейс Solr, вы сможете найти ссылку Analysis слева.
Обновление:
Теперь, когда я получил от вас немного больше подробностей и снова думаю об этом, результаты, которые вы получаете, вполне объяснимы.
С помощью minGramSize="1" при поиске без кавычек по запросу "витамин с" будут найдены записи со словом "витамин" (или более длинным словом, содержащим "витамин") и словом "с" (или более длинным словом, содержащим "с"). Поскольку в большинстве записей где-то есть буква «с», это вряд ли является ограничивающим фактором, и ваши результаты будут очень близки или точно такие же, как ваши результаты только для слова «витамин».
В цитируемом поиске по слову «витамин с» буква «с» теперь должна стоять в слове, непосредственно следующем за витамином, что делает поиск гораздо более полезным, но все же не лучшим. Вы должны быть в состоянии проверить это, найдя записи, в которых есть слово после витамина, которое не является обозначением витамина. Например, запись с упоминанием «таблетки витамина» должна быть найдена при поиске «витамин b» (потому что в слове «таблетки» есть буква «b»). и запись с упоминанием «таблицы витаминов» или «дефицита витамина» должна быть найдена при поиске «витамина с».
В результате я настоятельно рекомендую иметь набор полей для поиска отдельно от ваших полей для автозаполнения. NGrams с minGramSize="1" просто не дадут вам разумных результатов для фактического шага поиска.
person
frances
schedule
15.05.2014
