Нечеткий поиск для исправления ошибок и опечаток

Примечание.

Поиск с использованием ИИ Azure доступна через портал Azure, REST API и Azure SDKs. Он также лежит в основе Foundry IQ — управляемого слоя знаний, который преобразует корпоративный контент в многократно используемые базы знаний с учетом разрешений доступа для агентов на портале Microsoft Foundry.

Поиск с использованием ИИ Azure поддерживает нечеткий поиск, тип запроса, который компенсирует опечатки и пропущенные термины во входной строке. Нечеткий поиск сканирует термины, имеющие аналогичную структуру. Расширение поиска для охвата близких совпадений имеет эффект автокоррекции опечаток, когда несоответствие заключается всего лишь в нескольких неправильно размещённых символах.

Это упражнение по расширению запросов, которое обеспечивает соответствие терминам, имеющим аналогичную структуру. При указании нечеткого поиска поисковая система создает граф (на основе теории детерминированного конечного автомата) аналогично составленных терминов для всех терминов в запросе. Например, если запрос содержит три термина "university of washington", граф создается для каждого термина в запросе search=university~ of~ washington~ (в нечетком поиске нет стоп-слов, поэтому "of" получает граф).

График может состоять из 50 расширений или перестановок каждого термина, включая как правильные, так и неправильные варианты. Затем движок возвращает в ответе наиболее релевантные соответствия.

Для термина, например "университет", граф может иметь "unversty, universty, university, universe, inverse". Все документы, соответствующие тем, которые отображаются в графе, включаются в результаты. В отличие от других запросов, которые анализируют текст для обработки различных форм одного и того же слова ("мыши" и "мышь"), в нечетких запросах сравнения принимаются буквально, без лингвистического анализа текста. "Вселенная" и "инверсная", которые семантично отличаются, совпадают, потому что синтаксические несоответствия небольшие.

Совпадение принимается, если несоответствия ограничены двумя или меньшими изменениями, где изменение — это вставленный, удаленный, замененный или передвинутый символ. Алгоритм исправления строк, указывающий разностную метрику расстоянияDamerau-Levenshtein. Он описывается как "минимальное количество операций (вставки, удаления, замены или транспозиции двух смежных символов), необходимых для изменения одного слова на другое".

В Поиск с использованием ИИ Azure:

  • Нечеткий запрос применяется ко всем терминам целиком. Фразы не поддерживаются напрямую, но можно указать нечеткое совпадение для каждого термина многокомпонентной фразы с помощью и конструкций. Например: search=dr~ AND cleanin~. Это выражение запроса находит совпадения в «сухой очистке».

  • Расстояние редактирования по умолчанию равно 2. Значение ~0 означает отсутствие расширения (совпадением считается только точный термин), но можно указать ~1 для одной степени различия или одной правки.

  • Нечеткий запрос может расширить термин до 50 вариантов. Это ограничение не настраивается, но вы можете эффективно уменьшить количество расширений, уменьшая расстояние редактирования до 1.

  • Ответы состоят из документов, содержащих соответствующие совпадения (до 50).

Во время обработки запросов нечеткие запросы не проходят лексический анализ. Входные данные запроса добавляются непосредственно в дерево запросов и разворачиваются для создания графа терминов. Единственным выполненным преобразованием является нижний регистр.

Совокупности графов представляются в качестве критериев соответствия токенам в индексе. Как можно понять, нечеткий поиск по своей природе медленнее, чем другие формы запросов. Размер и сложность вашего индекса могут определить, достаточно ли преимуществ, чтобы компенсировать задержку ответа.

Примечание.

Поскольку размытый поиск, как правило, работает медленно, может быть целесообразно рассмотреть такие альтернативы, как индексирование n-грамм с использованием прогрессии коротких последовательностей символов (двух- и трехсимвольные последовательности для маркеров биграмм и триграмм). В зависимости от языка и поверхности запросов n-грамма может повысить производительность. Компромисс заключается в том, что индексирование n-грамм является очень памятьемким и создает гораздо больший индекс.

Еще одна альтернатива, которую можно рассмотреть, если вы хотите обрабатывать только самые вопиющие случаи, будет картой синонимов. Например, можно сопоставить "поиск" с наборами "поиcк, пoиcк, поис" или "извлечение" с "извлечениe".

Строковые поля, которые атрибутируются как "доступные для поиска", являются кандидатами на нечеткий поиск.

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

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

Нечеткие запросы создаются с помощью полного синтаксиса запроса Lucene, вызова полного синтаксического анализа запросов Lucene и добавления символа ~ тильды после каждого целого термина, введенного пользователем.

Ниже приведен пример запроса, который вызывает нечеткий поиск. Он включает четыре термина, два из которых написаны с ошибками.

POST https://[service name].search.windows.net/indexes/hotels-sample/docs/search?api-version=2026-04-01
{
    "search": "seatle~ waterfront~ view~ hotle~",
    "queryType": "full",
    "searchMode": "any",
    "searchFields": "HotelName, Description",
    "select": "HotelName, Description, Address/City",
    "count": true
}

  1. Задайте для типа запроса полный синтаксис Lucene (queryType=full).

  2. Предоставьте строку запроса, в которой каждый термин заканчивается оператором тильды (~) в конце каждого целого термина (search=<string>~). Граф расширения создается для каждого термина в входных данных запроса.

    Включите необязательный параметр, число от 0 до 2 (по умолчанию), если вы хотите указать расстояние редактирования (~1). Например, "blue~" или "blue~1" вернет результаты с "blue", "blues" и "glue".

При необходимости можно повысить производительность запросов, уточнив запрос на определенные поля. searchFields Используйте параметр, чтобы указать поля для поиска. Вы также можете использовать select свойство, чтобы указать, какие поля возвращаются в ответе запроса.

Для простого тестирования рекомендуется обозреватель поиска или клиент REST для итерации выражения запроса. Оба инструмента являются интерактивными, что означает, что можно быстро просмотреть несколько вариантов термина и оценить отклики.

Если результаты неоднозначны, подсветка совпадений может помочь определить совпадение в ответе.

Примечание.

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

Пример 1. Нечеткий поиск с точным термином

Предположим, что в "Description" поле в документе поиска существует следующая строка: "Test queries with special characters, plus strings for MSFT, SQL and Java."

Начните с нечеткого поиска по запросу "special" и добавьте выделение совпадений в поле Description.

search=special~&highlight=Description

В ответе, поскольку вы добавили подсветку совпадений, форматирование применяется к слову "специальный" как к соответствующему термину.

"@search.highlights": {
    "Description": [
        "Test queries with <em>special</em> characters, plus strings for MSFT, SQL and Java."
    ]
}

Повторите запрос, исказив написание "специальный", убрав несколько букв ("pe"):

search=scial~&highlight=Description

Пока что изменений в ответе нет. Учитывая расстояние в 2 символа по умолчанию, удаление двух символов "pe" из «специального» по-прежнему позволяет успешное сопоставление с этим термином.

"@search.highlights": {
    "Description": [
        "Test queries with <em>special</em> characters, plus strings for MSFT, SQL and Java."
    ]
}

Попробуйте еще один запрос, изменив термин поиска, удалив один последний символ для общего количества трех удалений (от "специальный" до "scal").

search=scal~&highlight=Description

Возвращается тот же ответ, но теперь вместо совпадения по слову "special" используется нечёткое совпадение по слову "SQL".

"@search.score": 0.4232868,
"@search.highlights": {
    "Description": [
        "Mix of special characters, plus strings for MSFT, <em>SQL</em>, 2019, Linux, Java."
    ]
}

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

Связанный контент

  • Last updated on