Точный поиск по фразе с использованием lucene без увеличения количества полей

Question

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

В настоящее время мы передаем наши данные через стандартные токенайзеры, StopFilter, PorterStemFilter и LowerCaseFilter. В связи с этим, когда пользователь хочет найти «управление паролем», поиск выводит результаты, содержащие «менеджер паролей».

Если я удалю StemFilter, я не смогу найти соответствие для корневой формы слова для несфразовых запросов. Я думал, стоит ли индексировать те же данные, что и часть двух полей в документе.

Я задавал один и тот же вопрос на Различные стратегии индексации и поиска в одном поле без удвоения размера индекса? . Однако сотрудники в офисе не рады индексированию тех же данных, что и часть двух полей. (у нас в настоящее время есть около 20 текстовых полей в документе lucene). Есть ли способ поддержать оба перечисленных выше случая с помощью TokenFilters?

Скажем, для StopFilter внесите изменения, чтобы он испускал как входной токен, так и? (для игнорируемого слова) с одинаковыми приращениями позиции. Аналогично для StemFilter, он испускает и входной токен, и токен стебля с одинаковыми приращениями позиции. В основном входные и выходные токены (даже игнорируемые) имеют одинаковые позиции.

Безопасно ли продолжать этот подход? Кто-нибудь еще сталкивался с перечисленными здесь требованиями? Есть ли какие-либо доступные фильтры, которые делают что-то похожее на то, что я упоминал в моем подходе?

Спасибо

Answer 1

Я не понимаю, что вы подразумеваете под "входными и выходными токенами".Храним ли ты данные дважды - один раз как стеблированный, а второй - как ненадежный?

Если вы не храните его дважды, я не думаю, что ваш метод сработает.Предположим, что сохраненное слово jumping, и они ищут jumped.Ваш анализатор запросов может выдавать jump и jumped, но он все равно не будет совпадать с jumping, если у вас нет значения, хранящегося как jump.

И если вы собираетесь хранить значение один раз как основанное, а другое как неосновное, то почему бы просто не сохранить его в двух полях?Тогда вам не придется иметь дело со странными изменениями токенизатора.