Простой синтаксис запросов в Поиск с использованием ИИ Azure

Примечание

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

Для сценариев полнотекстового поиска Поиск с использованием ИИ Azure реализует два языка запросов на основе Lucene, каждый из которых выровнен с анализатором запросов. Средство синтаксического анализа простых запросов используется по умолчанию. Он охватывает распространенные варианты использования и пытается интерпретировать запрос, даже если он не полностью составлен. Другой средство синтаксического анализа — Lucene Query Parser и поддерживает более сложные конструкции запросов.

В этой статье приведена ссылка на синтаксис запросов для простого средства синтаксического анализа запросов.

Синтаксис запросов для обоих средств синтаксического анализа применяется к выражениям запросов, переданным в search параметре запроса, не путать с синтаксисом OData, с собственным синтаксисом и правилами для filter и orderby выражений в одном запросе.

Хотя простой анализатор основан на классе Apache Lucene Simple Query Parser, его реализация в Поиск с использованием ИИ Azure исключает нечеткий поиск. Если вам нужен нечеткий поиск, вместо этого рассмотрите альтернативный синтаксис полного запроса Lucene .

Пример (простой синтаксис)

Этот пример демонстрирует простой запрос, который выделяется "queryType": "simple" и обладает допустимым синтаксисом. Хотя тип запроса задан ниже, это значение по умолчанию и может быть опущено, если вы не возвращаетесь к альтернативному типу. В следующем примере выполняется поиск по независимым терминам с требованием, чтобы все соответствующие документы включали "пул".

POST https://{{service-name}}.search.windows.net/indexes/hotel-rooms-sample/docs/search?api-version=2026-04-01
{
  "queryType": "simple",
  "search": "budget hotel +pool",
  "searchMode": "all"
}

Параметр searchMode относится к этому примеру. Всякий раз, когда логические операторы используются в запросе, следует searchMode=all установить, чтобы убедиться, что все критерии соответствуют. В противном случае можно использовать значение по умолчанию searchMode=any, которое предпочитает полноту вместо точности.

Дополнительные примеры см. в примерах синтаксиса простых запросов. Дополнительные сведения о запросе и параметрах см. в разделе "Документы поиска" (REST API).

Поиск ключевых слов по терминам и фразам

Строки, передаваемые параметру search, могут включать термины или фразы на любом поддерживаемом языке, логические операторы, операторы приоритета, подстановочные знаки или префиксы для запросов 'начинается с', escape-символы и символы кодирования URL. Параметр search является необязательным. Не указано, поиск (search=* или search=" ") возвращает первые 50 документов в произвольном порядке (без проверки).

  • Поиск терминов — это запрос одного или нескольких терминов, где любой из терминов считается совпадением.

  • Поиск фраз — это точная фраза, заключенная в кавычки" ". Например, хотя Roach Motel (без кавычек) будет искать документы, содержащие Roach и/или Motel в любом месте в любом порядке, "Roach Motel" (с кавычками) будет соответствовать только документам, содержащим всю фразу вместе и в указанном порядке (лексический анализ по-прежнему применяется).

В зависимости от клиента поиска может потребоваться экранировать кавычки в поиске фраз. Например, в запросе POST поиск фразы "Roach Motel" в теле запроса может быть указан как "\"Roach Motel\"". Если вы используете Azure SDKs, клиент поиска экранирует кавычки при сериализации текста поиска. Ваша фраза поиска может быть отправлена как "Roach Motel".

По умолчанию все строки, передаваемые в параметре search , проходят лексический анализ. Убедитесь, что вы понимаете поведение маркеризации используемого анализатора. Часто, когда результаты запроса неожиданные, причина может заключаться в том, как термины токенизируются на этапе запроса. Чтобы подтвердить выходные данные, можно протестировать маркеризацию на определенных строках .

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

Так просто, как это кажется, существует один аспект обработки запросов в Поиск с использованием ИИ Azure, который может создавать неожиданные результаты, увеличивая количество результатов поиска, а не уменьшая их, когда во входную строку добавляется больше терминов и операторов. На самом деле увеличение функциональности зависит от включения оператора NOT в сочетании с настройкой параметра searchMode, которая определяет, как интерпретируется оператор NOT с точки зрения поведения AND или OR. Дополнительные сведения см. об операторе NOT в разделе «Логические операторы».

Логические операторы

Логические операторы можно внедрить в строку запроса, чтобы повысить точность совпадения. В простом синтаксисе булевые операторы основаны на символах. Текстовые операторы, такие как слово AND, не поддерживаются.

Символ Пример Использование
+ pool + ocean Операция AND . Например, предполагается, pool + ocean что документ должен содержать оба термина.
| pool | ocean Операция OR находит совпадение при обнаружении любого термина. В этом примере обработчик запросов вернет совпадение для документов, содержащих либо pool, либо ocean, или оба. Так как OR является оператором сочетания по умолчанию, его можно также оставить, например pool ocean , эквивалентно pool | ocean.
- pool – ocean Операция NOT находит документы, которые не содержат термин.

Параметр searchMode в запросе управляет тем, объединяется ли термин с оператором NOT через AND или OR с другими терминами в запросе (при отсутствии логических операторов у других терминов). Допустимые значения включают any или all.

searchMode=any увеличивает отзыв запросов, включив дополнительные результаты, и по умолчанию - будет интерпретироваться как "OR NOT". Например, pool - ocean будет соответствовать документам, которые содержат термин pool или те, которые не содержат термин ocean.

searchMode=all увеличивает точность запросов, включая меньше результатов, и по умолчанию - будет интерпретировано как "AND NOT". Например, с searchMode=any, запрос pool - ocean будет соответствовать документам, содержащим термин "пул", и всем документам, которые не содержат термин "океан". Это, возможно, более интуитивно понятное поведение для - оператора. Поэтому следует использовать searchMode=all вместо searchMode=any, если вы хотите оптимизировать поиск для точности, а не полноты, и ваши пользователи часто используют оператор - в поисках.

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

Запросы по префиксу

Для запросов "начинается с" добавьте оператор суффикса (*) в качестве заполнителя для оставшейся части термина. Перед добавлением оператора суффикса запрос префикса должен начинаться по крайней мере с одним символом обычного текста.

Символ Пример Использование
* lingui* будет соответствовать "лингвистическому" или "лингвини" Звездочка (*) представляет один или несколько символов произвольной длины, без учета регистра.

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

Простой синтаксис поддерживает только сопоставление префикса. Для сопоставления с окончанием или серединой термина, используя суффикс или инфикс, используйте полный синтаксис Lucene для поиска с подстановочными знаками.

Экранирование операторов поиска

В простом синтаксисе операторы поиска включают следующие символы: + | " ( ) ' \

Если любой из этих символов является частью токена в индексе, экранируйте его, поставив перед ним одну обратную косую черту (\) в запросе. Например, предположим, что вы использовали пользовательский анализатор для всей токенизации терминов, а индекс содержит строку "Luxury+Hotel". Чтобы получить точное совпадение с этим токеном, вставьте escape-символ: search=luxury\+hotel.

Чтобы упростить задачу в более типичных случаях, есть два исключения из этого правила, где экранирование не требуется:

  • Оператор NOT - должен быть экранирован только в том случае, если он является первым символом после пробела. Если отображается - в середине (например, в 3352CDD0-EF30-4A2E-A512-3B30AF40F3FD), можно пропустить экранирование.

  • Оператор * суффикса должен быть экранирован только в том случае, если это последний символ перед пробелом. Если * находится в середине (например, в 4*4=16), экранирование не требуется.

Примечание

По умолчанию стандартный анализатор удаляет и разбивает слова на дефисы, пробелы, амперсанды и другие символы во время лексического анализа. Если требуется, чтобы специальные символы оставались в строке запроса, может потребоваться анализатор, сохраняющий их в индексе. Некоторые варианты включают Microsoft анализаторы естественного языка анализаторы языка, которые сохраняют дефисированные слова, или адаптированные под пользователя анализаторы для более сложных шаблонов. Дополнительные сведения см. в разделе "Частичные термины", "шаблоны" и "Специальные символы".

Кодировка небезопасных и зарезервированных символов в URL-адресах

Убедитесь, что все небезопасные и зарезервированные символы кодируются в URL-адресе. Например, "#" является небезопасным символом, так как это идентификатор фрагмента или привязки в URL-адресе. Если символ используется в URL, он должен быть закодирован как %23. & ' и '=' являются примерами зарезервированных символов, так как они разделяют параметры и указывают значения в Поиск с использованием ИИ Azure. Дополнительные сведения см. в разделе RFC1738: универсальные указатели ресурсов (URL-адрес).

Небезопасные символы " ` < > # % { } | \ ^ ~ [ ]. Зарезервированные символы — ; / ? : @ = + &.

Специальные символы

Специальные символы могут варьироваться от символов валюты, таких как "$" или "€", до эмодзи. Многие анализаторы, включая стандартный анализатор по умолчанию, исключают специальные символы во время индексирования, что означает, что они не будут представлены в индексе.

Если требуется специальное представление символов, можно назначить анализатор, сохраняющий их:

  • Анализатор пробелов рассматривает любую последовательность символов, разделенную пробелами, как маркеры (поэтому эмодзи "❤" будет считаться маркером).

  • Анализатор языка, например английский анализатор Microsoft (en.microsoft), будет принимать строку "$" или "€" в качестве токена.

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

При использовании символов Юникода убедитесь, что символы правильно экранируются в URL-адресе запроса (например, для '❤' будет использоваться последовательность экранирования %E2%9D%A4+). Некоторые веб-клиенты выполняют этот перевод автоматически.

Приоритет (группирование)

Вы можете использовать скобки для создания вложенных запросов, в том числе для включения операторов в этих скобках. Например, будет искать документы, motel+(wifi|luxury) содержащие термин "мотель" и "wifi" или "роскошь" (или оба).

Ограничения размера запроса

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

  • Для GET длина URL-адреса не может превышать 8 КБ.

  • Для POST (и любого другого запроса), где текст запроса включает search и другие параметры, например filter и orderbyмаксимальный размер составляет 16 МБ. К дополнительным ограничениям относятся:

    • Максимальная длина предложения поиска составляет 100 000 символов.
    • Максимальное количество предложений в search (выражениях, разделенных AND или OR), равно 1024.
    • Максимальный размер термина поиска составляет 1000 символов для поиска префикса.
    • Существует также ограничение примерно в 32 КБ по размеру любого отдельного термина в запросе.

Дополнительные сведения об ограничениях запросов см. в разделе об ограничениях запросов API.

Дальнейшие действия

Если вы планируете создавать запросы программно, ознакомьтесь с Полнотекстовым поиском в Поиск с использованием ИИ Azure, чтобы понять этапы обработки запросов и последствия анализа текста.

Вы также можете ознакомиться со следующими статьями, чтобы узнать больше о создании запросов:

  • Last updated on