Вопрос 1
Подстановочные запросы (как правило) не анализируются (т. Е. Они не разбиваются на токены или не проходят через фильтры), что означает, что все, что зависит от фильтры, обрабатывающие токены ввода / вывода, будут давать странные результаты (например, если строка ввода разбита на несколько строк).
Сопоставление происходит с токенами, поэтому то, что вы вводите, почти (строчный регистр все еще работает) сопоставляется непосредственно с префиксом / постфиксом токенов в индексе. Обычно вам следует избегать подстановочных запросов для общих поисковых запросов, поскольку они довольно ограничены для обычного поиска и могут давать странные результаты (как показано).
Нечеткий поиск основан на «расстоянии редактирования» - то есть число, которое сообщает Solr, сколько символов можно удалить / вставить / изменить, чтобы добраться до полученного токена. Это даст вашим пользователям OK-i sh результаты, но может быть трудно расшифровать в смысле «почему это дало мне удар», когда разрешенное расстояние больше (Lucene / Solr поддерживает до 2 в расстоянии редактирования, которое также используется по умолчанию, если расстояние редактирования не указано).
Стемминг - это обычно путь к go, поскольку это фактический "формальный" процесс взятия термина и его уменьшения. его основа - фактическое «значение» (оно на самом деле ничего не знает о значении, как в термине обработки естественного языка, но делает это в соответствии с набором правил и исключений stati c для настроенного языка) слово . Его можно настроить для каждого языка в соответствии с правилами, подходящими для этого языка, что невозможно ни в одном из двух других вариантов.
Для вашего недостатка в отношении стеблирования («поскольку он не может сравниться с насосами») - это может быть хорошей вещью. Для ваших пользователей будет более понятным, на чем основаны результаты поиска, и вместо того, чтобы включать pumps в результаты поиска, включите его как исправление орфографии («Вы имели в виду pump / pumps вместо этого?») , Это даст гораздо лучший опыт для любого пользователя, где результаты поиска будут более точно соответствовать тому, что они ищут.
Требования могут отличаться в зависимости от того, каков ваш реальный вариант использования; т. е. если это просто для программ c попыток найти термины, которые похожи.
Вопрос 2
Представьте результаты, которые вы считаете более подходящими в качестве первых попаданий - если вы выполняете подстановочный или нечеткий поиск, вы не можете сделать это с помощью одних только оценок, поэтому вам придется сделать несколько запросов, а затем представлять их друг за другом. Я обычно предлагаю сделать это явное действие пользователем поиска при обсуждении этого в проектах.
Вместо этого, в качестве основного поиска, вы можете использовать NGramFilter в отдельном поле и использовать инструкцию copyfield, чтобы получить одинаковое содержимое в обоих полях, а затем оцените ngramfilter гораздо ниже, чем попадания в более «точное» поле. Обычно вам нужно три поля в этом случае - одно для точных попаданий (неосновных), одно для обращенных к стволу и одно для попаданий ngram - и затем оцените их соответствующим образом с параметром qf для edismax. Обычно он дает вам самые быстрые и легкие результаты для достойных результатов поиска для ваших пользователей, но не забудьте дать им достойные способы либо фильтрации набора результатов (фасетов), либо изменения их запросов во что-то более значимое (вы имели в виду также xyz, et c.).
Угадать намерения пользователя обычно очень сложно, если вы не потратили много времени и ресурсов на персонализацию (например, Google), так что оставьте это на потом - большинство пользователей довольны до тех пор, пока у них есть четкий и внятный способ решения своих проблем, даже если вы не добились идеального результата для первого результата.