Нечеткий поиск ведет себя более строго, чем ожидалось - PullRequest
Новая
       14

Нечеткий поиск ведет себя более строго, чем ожидалось

0 голосов
/ 14 мая 2019

Я запрашиваю свой собственный экземпляр поиска Azure, используя конечную точку REST после тела POST https://[search].search.windows.net/indexes/[index]/docs/search?api-version=2019-05-06, и мне трудно понять, почему мои нечеткие поиски иногда не находят результатов.

У меня есть один документ, который я пытаюсь найти: 

{
  "Company": "MyCompany",
  "City": "Houston",
  "Country": "United States",
}

Если я выполняю поисковый запрос, например "search": "City:Houston", я получаю документ, как и ожидалось. Точно так же, если я ищу с "search": "City:Housto~", я также получаю документ.

Однако "search": "City:Houst~" не находит ЛЮБЫЕ документы, я пробовал варианты "search": "City:Houst~X" для X между 0.1-1.0 и 0-2, но не могу получить запрос для поиска документа.

Я ожидал, что документ будет найден, пока я дал некоторую подстроку из Хьюстона и добавил символ нечеткого поиска ~. Почему Housto~ соответствует Houston, а не Houst~?

Обновление: Мой почтовый запрос имеет следующий текст: 

{
  "search": "CityName:Houst~",
  "filter": "CityName eq 'Houston'",
  "queryType": "full"
}

Фильтр есть, потому что с тех пор в поиск были добавлены некоторые другие документы с более короткими вариантами, о 'Хьюстон'. Например, был добавлен документ с CityName 'Houst', и этот документ действительно возвращается в результате вышеуказанного поиска. Хорошо, что документ действительно появляется, но мне нужно, чтобы документ с полным текстом «Хьюстон» ТАКЖЕ был возвращен, возможно, с более низким баллом, чем «Хьюст».

Одна вещь, которую я заметил, заключается в том, что при использовании "search": "CityName:Houst~" находит пакет документов с houston (строчная H), но не находит никаких документов с Houston (прописная H). Я смущен этим, поскольку эти два очень похожи, я ожидал бы, что оба будут найдены поиском.

Обновление 2: Проведение дополнительных исследований на основе беседы в ответе Джои Кая также привело меня к к этому связанному вопросу переполнения стека . Проблема, описанная в посте chn, не совпадающая с China, в основном такая же, как и основная проблема, с которой я столкнулся, хотя ответ Джои наиболее актуален для моего вопроса. Я пришел к выводу, что нечеткий поиск лазурного типа не предназначен для сопоставления строк, которые на значительном расстоянии отличаются друг от друга по конструкции (подтверждается ответом, приведенным в связанном вопросе).

1 Ответ

1 голос
/ 14 мая 2019

Я тестирую на своем сайте и могу воспроизвести вашу проблему.

Однако, когда я добавляю "queryType": "full", а не queryType:full, это работает хорошо.

URL-адрес запроса похож на:

https://searchname.search.windows.net/indexes/datasourcename/docs?api-version=2019-05-06&search=Houst~&queryType=full
...