Целесообразно ли объединять токены при индексации поисковой системы?

Question

Я работаю над поисковой системой, использующей AWS CloudSearch (хотя я думаю, что мой вопрос актуален для поисковых систем в целом). Допустим, у меня есть индексируемый документ, который имеет текстовое поле с именем Name со значением Somecompany, В настоящее время, если я запускаю запрос, такой как Somecompany тогда, конечно, я получаю этот документ в результате.

Тем не менее, если я запускаю запрос, как Some companyтогда я не получу тот же результат. У меня есть некоторое базовое понимание поисковых систем и перевернутый индекс. Я знаю, что причина, по которой я не получаю документ в результате, заключается в том, что индекс поисковой системы отображает документ только с помощью токена. Somecompany, Там могут быть отдельные отображения документов в индексе для токена Some и для токена company, но независимо от того, мой документ не сопоставлен ни с одним из них (и я не ожидал бы, что это будет).

Возможно ли и / или практично ли индексировать поисковую систему таким образом, чтобы сделать Some company поисковый запрос найти Somecompany документ, который я ищу?

Мне бы тоже хотелось, чтобы сработала обратная ситуация. Итак, если документ проиндексирован с использованием текстового поля Some company тогда я бы хотел запрос Somecompany чтобы найти этот документ.

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

Я обеспокоен этим решением, так как инвертированный индекс будет заполнен уникальными токенами, которые отображаются только в одном документе. Это проблема? Есть ли альтернативное решение?

Answer 1

Я уверен, что предложенное вами решение для сжатия запросов будет работать нормально с точки зрения производительности поиска, и вам не нужно беспокоиться об индексации уникальных терминов. Основной недостаток, который я вижу, заключается в том, что мы просто теряем многие преимущества поисковой системы, такие как стволовые, стоп-слова и синонимы, но если вы имеете дело с названиями компаний, которые по сути являются именами собственными, то это не большая проблема. Возможно, это накладывает на пользователя немного большее бремя, чтобы правильно написать свой запрос (поскольку ввод "sime company" будет соответствовать одному из слов в "some company", в то время как "simecompany" вообще не соответствует "somecompany" и т. Д.), но вы можете улучшить это с помощью нечеткого поиска (~ оператор) и с помощью предложителя.

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