Синтаксис запросов Lucene в службе "Поиск ИИ Azure"

При создании запросов в службе поиска ИИ Azure можно выбрать полный синтаксис Синтаксического анализа запросов Lucene для специализированных форм запросов: дикий карта, нечеткий поиск, поиск близкого взаимодействия, регулярные выражения. Большая часть синтаксиса Синтаксического анализа запросов Lucene реализована без изменений в поиске ИИ Azure, за исключением поиска по диапазону, которые создаются с помощью $filter выражений.

Чтобы использовать полный синтаксис Lucene, задайте тип запроса full и передайте выражение запроса, шаблонное для дикого карта, нечеткого поиска или одной из других форм запросов, поддерживаемых полным синтаксисом. В REST выражения запросов предоставляются в параметре search запроса Поиска документов (REST API).

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

Следующий пример представляет собой поисковый запрос, созданный с использованием полного синтаксиса. В этом конкретном примере демонстрируется поиск в поле и повышение приоритета термина. Он ищет отели, где поле категории содержит термин budget. Все документы, содержащие фразу "recently renovated" , ранжируются выше в результате значения повышения термина (3).

POST /indexes/hotels-sample-index/docs/search?api-version=2023-11-01
{
  "queryType": "full",
  "search": "category:budget AND \"recently renovated\"^3",
  "searchMode": "all"
}

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

Дополнительные примеры см . в примерах синтаксиса запросов Lucene. Дополнительные сведения о запросе и параметрах запроса, включая searchMode, см. в разделе Поиск документов (REST API).

Основы синтаксиса

Следующие основные сведения о синтаксисе применяются ко всем запросам, которые используют синтаксис Lucene.

Оценивание операторов в контексте

Размещение определяет, как будет интерпретироваться символ: как оператор или просто как другой знак в строке.

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

В течение термина, например business~analyst, символ не оценивается как оператор. В этом случае, если запрос является термином или запросом фразы, полнотекстовый поиск с лексическим анализом удаляет и разбивает ~ термин business~analyst в два: business OR analyst.

Приведенный выше пример — тильда (~), но тот же принцип применяется к каждому оператору.

Экранирование специальных знаков

Чтобы использовать любой оператор поиска как часть искомого текста, необходимо экранировать символ, добавив перед ним одну обратную косую черту (\). Например, для поиска с подстановочными знаками в https://, где :// является частью строки запроса, необходимо указать search=https\:\/\/*. Аналогичным образом экранированный шаблон номера телефона может выглядеть вот так: \+1 \(800\) 642\-7676.

Некоторые специальные знаки, требующие экранирования:
+ - & | ! ( ) { } [ ] ^ " ~ * ? : \ /

Примечание.

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

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

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

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

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

Чтобы повысить точность совпадения, можно внедрить в строку запроса логические операторы. В дополнение к символьным операторам полный синтаксис поддерживает текстовые операторы. Всегда указывайте текстовые логические операторы (AND, OR, NOT) прописными буквами.

Текстовый оператор	Символ	Пример	Использование
И	+	wifi AND luxury	Задает термины, которые должны содержаться в совпадении. В примере обработчик запросов ищет документы, содержащие оба wifi и luxury. Знак плюса (+) также можно использовать непосредственно перед термином, чтобы сделать его обязательным. Например, +wifi +luxury указывает, что оба термина должны появляться где-то в поле одного документа.
ИЛИ	(нет) 1	wifi OR luxury	Поиск совпадения при обнаружении хотя бы одного из терминов. В примере обработчик запросов возвращает соответствие документам, wifiluxury содержащим либо оба. Так как OR является оператором соединения по умолчанию, вы также можете его оставить, то есть wifi luxury аналогично wifi OR luxury.
Логическое НЕ	!, -	wifi –luxury	Возвращает совпадение для документов, которые исключают термин. Например, wifi –luxury выполняет поиск документов, имеющих wifi термин, но не luxury.

¹ Символ | не поддерживается для операций OR.

Оператор NOT Boolean

Внимание

Оператор NOT (NOT, !или -) работает по-разному в полном синтаксисе, чем в простом синтаксисе.

• В простом синтаксисе запросы с отрицанием всегда имеют дикий карта автоматически добавлен. Например, запрос -luxury автоматически развертывается в -luxury *.
• В полном синтаксисе запросы с отрицанием не могут сочетаться с диким карта. Например, запросы -luxury * не допускаются.
• В полном синтаксисе запросы с одним отрицанием не допускаются. Например, запрос -luxury не разрешен.
• В полном синтаксисе отрицание будет вести себя так, как если бы они всегда были anDed в запросе независимо от режима поиска.
  • Например, полный синтаксис запроса wifi -luxury в полном синтаксисе получает только документы, содержащие термин wifi, а затем применяет отрицание -luxury к этим документам.
• Если вы хотите использовать отрицания для поиска по всем документам в индексе, рекомендуется использовать простой синтаксис с режимом any поиска.
• Если вы хотите использовать отрицания для поиска по подмножествам документов в индексе, полного синтаксиса или простого синтаксиса со всеми режимами поиска рекомендуется.

Тип запроса	Режим поиска	Пример запроса	Поведение
Простая	любое	wifi -luxury	Возвращает все документы в индексе. Документы с термином "wifi" или документы, отсутствующие термин "роскошь", ранжируются выше, чем другие документы. Запрос развернут в wifi OR -luxury OR *.
Простая	all	wifi -luxury	Возвращает только документы в индексе, содержащие термин "wifi" и не содержат термин "роскошь". Запрос развернут в wifi AND -luxury AND *.
Полностью	любое	wifi -luxury	Возвращает только документы в индексе, содержащие термин "wifi", а затем документы, содержащие термин "роскошь", удаляются из результатов.
Полностью	all	wifi -luxury	Возвращает только документы в индексе, содержащие термин "wifi", а затем документы, содержащие термин "роскошь", удаляются из результатов.

Поиск по полям

Можно определить операцию поиска по полям с синтаксисом fieldName:searchExpression, где выражение поиска представляет собой одно слово или фразу, или более сложное выражение в круглых скобках (при необходимости с логическими операторами). Вот несколько примеров.

• genre:jazz NOT history

• artists:("Miles Davis" "John Coltrane")

Добавьте несколько строк в кавычках, если необходимо, чтобы обе строки считались одной сущностью, в приведенном случае поиска двух разных исполнителей в поле artists.

Поле, указанное в fieldName:searchExpression, должно быть полем searchable. Дополнительные сведения об использовании атрибутов индекса в определениях полей см. в статье Create Index (Azure Search Service REST API) (Создание индексов (REST API службы "Поиск Azure")).

Примечание.

При использовании выражений для поиска по полям не нужно использовать параметр searchFields, так как каждое выражение для поиска по полям имеет явно заданное имя поля. Тем не менее можно по-прежнему использовать параметр searchFields, если требуется выполнить запрос, в котором некоторые части ограничены определенным полем, а остальные можно применить к нескольким полям. Например, запрос search=genre:jazz NOT history&searchFields=description будет сопоставлять jazz только с полем genre, в то время как NOT history — с полем description. Имя поля, указанное в fieldName:searchExpression, всегда имеет приоритет над параметром searchFields, поэтому в данном примере не нужно включать genre в параметр searchFields.

Нечеткий поиск

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

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

Нечеткий поиск может применяться только к терминам, а не к фразам, заключенным в кавычки, но можно добавить тильду к каждому термину по отдельности в многокомпонентном имени или фразе. Например, Unviersty~ of~ Wshington~ будет соответствовать University of Washington.

Поиск близости

Операция поиска с учетом расположения позволяет найти слова, расположенные рядом в документе. Вставьте символ тильды ~ в конце фразы, за которым следует число слов, создающих границу близости. Например, "hotel airport"~5 находит термины hotel и airport в пяти словах друг друга в документе.

Усиление термина

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

В следующем примере показаны эти различия. Предположим, что есть профиль повышения, который повышает приоритет совпадений в определенном поле, например, genre в примере musicstoreindex. Повышение значимости слов может использоваться для дальнейшего повышения приоритета определенных условий поиска относительно других. Например, rock^2 electronic повышает уровень документов, содержащих условия поиска в поле жанра выше, чем другие поля, доступные для поиска в индексе. Кроме того, документы, содержащие рок поисковых терминов, ранжируются выше, чем другой поисковый термин электронный в результате значения повышения термина (2).

Чтобы повысить термин, используйте подсказку, ^символ с коэффициентом повышения (число) в конце термина, который выполняется поиск. Вы также можете повысить приоритет фразы. Чем выше коэффициент повышения, тем более релевантным является термин относительно других терминов поиска. По умолчанию коэффициент повышения значимости равен 1. Несмотря на то что коэффициент повышения приоритета должен быть положительным числом, он может быть меньше 1 (например, 0,20).

Поиск регулярных выражений

Операция поиска по регулярным выражениям позволяет найти совпадение на основе шаблонов, допустимых в Apache Lucene, как указано в документации класса RegExp. В поиске ИИ Azure регулярное выражение заключено между косой чертой /.

Например, чтобы найти документы, motel содержащие или hotelукажите /[mh]otel/. Поиск с регулярными выражениями сопоставляется с отдельными словами.

Некоторые средства и языки накладывают дополнительные требования к escape-символам за пределами правил , введенных поиском ИИ Azure. Для JSON строки, включающие косую черту вперед, экранируются с помощью обратной косой черты: microsoft.com/azure/ становится search=/.*microsoft.com\/azure\/.*/ местом, где search=/.* <string-placeholder>.*/ настраивается регулярное выражение и microsoft.com\/azure\/ является строкой с экранированной косой чертой вперед.

Два распространенных символа в регулярных запросах: . и *. Соответствует . одному символу * и соответствует предыдущему нулю или более раз. Например, /be./ соответствует условиямbee, а bet в то время /be*/ как совпадаетbe, beeа не .betbeee Вместе можно сопоставить любую серию символов, .* поэтому /be.*/ будет соответствовать любому термину, который начинается с be такого рода better.

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

Поиск с подстановочными знаками

Вы можете использовать общепризнанный синтаксис для поиска с использованием нескольких подстановочных знаков (*) или одного (?). Полный синтаксис Lucene поддерживает сопоставление префиксов, инфиксов и суффиксов.

Обратите внимание, что средство синтаксического анализа запросов Lucene поддерживает использование этих символов для поиска одного слова, а не фразы.

Тип аффикса	Описание и примеры
prefix	Фрагмент термина предшествует * или ?. Например, выражение запроса возвращаемого search=alpha*alphanumeric или alphabetical. Сопоставление префикса поддерживается как в простом, так и в полном синтаксисе запроса.
suffix	Фрагмент терминов происходит после * или ?с косой чертой вперед для разделителя конструкции. Например, search=/.*numeric/ возвращает alphanumeric.
инфикс	Фрагменты терминов заключены в * или ?. Например, search=non*al возвращает non-numerical и nonsensical.

В одном выражении можно комбинировать различные операторы. Например, 980?2* совпадения 98072-1222 и 98052-1234? совпадения с одним (обязательным) символом и * совпадениями с символами произвольной длины, следующей за ней.

Для сопоставления с суффиксов требуются разделители косой черты / регулярного выражения. Как правило, нельзя использовать * символ или ? символ в качестве первого символа термина без символа /. Также важно отметить, что * поведение по-разному при использовании вне регулярных запросов. Вне разделителя косой черты / регрессии является * диким карта символом и соответствует любой серии символов, как .* в регрессии. Например, создает тот же результирующий набор, search=/non.*al/ что search=non*alи .

Примечание.

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

Влияние анализатора на дикие запросы карта

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

Рассмотрим ситуацию, когда может потребоваться, чтобы поисковый запрос terminal* возвращал результаты, содержащие такие термины, как terminate, terminationи terminates.

При использовании анализатора en.lucene (English Lucene) применялся бы активный морфологический поиск каждого термина. Например, terminateterminationterminates все маркеры будут токенизированы до маркера termi в индексе. С другой стороны, термины в запросах с использованием диких карта или нечетких поисков не анализируются вообще, поэтому не было бы результатов, которые будут соответствовать запросуterminat*.

С другой стороны, анализаторы Майкрософт (в нашем примере это анализатор en.microsoft) немного более продвинуты и вместо морфологического поиска используют лемматизацию. Это означает, что все созданные маркеры должны быть реально существующими английскими словами. Например, terminate, terminatesи termination в основном будет оставаться целым в индексе, и будет предпочтительный выбор для сценариев, которые зависят много от диких карта и нечетких поисков.

Оценка диких карта и регулярных запросов

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

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

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

Анализаторы, которые маркеризируют специальные символы, включают анализатор пробелов, который учитывает все последовательности символов, разделенные пробелами в виде маркеров (поэтому ❤ строка будет считаться маркером). Кроме того, анализатор языка, например анализатор Microsoft для английского языка (en.microsoft), принимает строку "€" в качестве токена. Можно проверить анализатор, чтобы узнать, какие токены он создает для данного запроса.

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

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

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

Группирование полей аналогично, но группирование ограничивается одним полем. Например, hotelAmenities:(gym+(wifi|pool)) выполняется поиск по полю hotelAmenitiesgym и ( wifiили gym ) и pool.

Предельные размеры запроса

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

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

См. также

• Примеры запросов для простого поиска
• Примеры запросов для полного поиска Lucene
• Поиск документов
• Синтаксис выражений OData для предложений фильтрации и упорядочивания в службе "Поиск Azure"
• Простой синтаксис запросов в поиске ИИ Azure