Влиять на результаты поиска или модифицировать состав результатов поиска в сервисе Azure AI Search

В этой статье описывается композиция результатов поиска и формирование результатов полнотекстового поиска в соответствии с вашими сценариями. Результаты поиска возвращаются в ответе запроса. Форма ответа определяется параметрами в самом запросе. Это следующие параметры.

Количество совпадений, найденных в индексе (count)
Количество совпадений, возвращаемых в ответе (50 по умолчанию, настраиваемое через top) или на страницу (skip и top)
Оценка поиска для каждого результата, используемого для ранжирования (@search.score)
Поля, включенные в результаты поиска (select)
Логика сортировки (orderby)
Выделение терминов в результатах, сопоставление по всему или частичному термину в тексте
Необязательные элементы из семантического ранжировщика (answers в верхней части, captions для каждого совпадения)

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

Клиенты и API-интерфейсы для определения ответа запроса

Для настройки ответа запроса можно использовать следующие клиенты:

Проводник поиска в портале Azure, используя вид JSON, чтобы указать любой поддерживаемый параметр
Документы — POST (REST API)
Метод SearchClient.Search (Пакет SDK Azure для .NET)
Метод SearchClient.Search (Пакет SDK Azure для Python)
Метод SearchClient.Search (Azure для JavaScript)
Метод SearchClient.Search (Azure для Java)

Композиция результатов

Результаты в основном табличные, состоящие из полей либо всех retrievable полей, либо ограничиваются только полями, указанными в параметре select. Строки — это соответствующие документы, которые обычно ранжируются в порядке релевантности, если логика запроса не исключает ранжирование релевантности.

Вы можете выбрать, какие поля находятся в результатах поиска. Хотя в документе поиска может быть большое количество полей, обычно требуется лишь несколько, чтобы представить каждый документ в результатах. В запросе добавьте select=<field list> , чтобы указать, какие retrievable поля должны отображаться в ответе.

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

POST /indexes/hotels-sample/docs/search?api-version=2025-09-01 
    {  
      "search": "sandy beaches",
      "select": "HotelId, HotelName, Description, Rating, Address/City",
      "count": true
    }

Советы по непредвиденным результатам

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

Измените searchMode=any (по умолчанию) на searchMode=all, чтобы потребовать соответствие всем указанным условиям, а не любому из них. Это особенно важно, если запрос содержит логические операторы.
Поэкспериментируйте с различными лексическими анализаторами или пользовательскими анализаторами, чтобы узнать, изменятся ли результаты поиска. Анализатор по умолчанию разбивает дефисированные слова и сокращает слова на корневые формы, что обычно повышает надежность ответа на запрос. Однако, если необходимо сохранить дефисы или если строки содержат специальные символы, может потребоваться настроить пользовательские анализаторы, чтобы убедиться, что индекс содержит маркеры в правильном формате. Для получения дополнительной информации см. раздел Поиск частично введенных слов и шаблоны со специальными символами (дефисы, подстановочные знаки, регулярные выражения, шаблоны).

Подсчет совпадений

Параметр count возвращает количество документов в индексе, которое считается совпадением для запроса. Чтобы вернуть количество, добавьте count=true в запрос. Нет максимального значения, введенного службой поиска. В зависимости от вашего запроса и содержимого ваших документов, число может быть равно числу всех документов в индексе.

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

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

Совет

Чтобы проверить операции индексирования, можно проверить, содержит ли индекс ожидаемое количество документов, добавив count=true в пустой search=* поисковый запрос. Результатом является полное количество документов в индексе.

При тестировании синтаксиса запросов count=true может быстро показать, приводит ли внесённое вами изменения к увеличению или уменьшению количества результатов, что может быть полезной обратной связью.

Количество результатов в ответе

Поиск Azure AI использует постраничную разбивку на стороне сервера, чтобы предотвратить извлечение слишком большого количества документов за один раз. Параметры запроса, определяющие количество результатов в ответе, это top и skip. top ссылается на количество результатов поиска на странице. skip — это интервал top, и он сообщает поисковой системе, сколько результатов пропустить перед получением следующего набора.

Размер страницы по умолчанию — 50, а максимальный размер страницы — 1000. Если указать значение больше 1000 и в индексе найдено более 1000 результатов, возвращаются только первые 1000 результатов. Если количество совпадений превышает размер страницы, ответ содержит сведения для получения следующей страницы результатов. Например:

"@odata.nextLink": "https://contoso-search-eastus.search.windows.net/indexes/hotels-sample/docs/search?api-version=2025-09-01"

Верхние совпадения определяются оценкой поиска, если запрос представляет собой полный текстовый поиск или семантический поиск. В противном случае верхние совпадения являются произвольным порядком для точных запросов соответствия (где однородное @search.score=1.0 указывает произвольную сортировку).

Задайте top, чтобы переопределить значение по умолчанию 50. В новых предварительных версиях API, если вы используете гибридный запрос, вы можете указать maxTextRecallSize, чтобы вернуть до 10 000 документов.

Для управления разбиением по страницам всех документов, возвращаемых в результирующем наборе, используйте top и skip вместе. Этот запрос возвращает первый набор из 15 соответствующих документов, а также количество общих совпадений.

POST https://contoso-search-eastus.search.windows.net/indexes/hotels-sample/docs/search?api-version=2025-09-01

{
    "search": "room with a view",
    "count": true,
    "top": 15,
    "skip": 0
}

Этот запрос возвращает второй набор, пропуская первые 15, чтобы получить следующий 15 (16–30):

POST https://contoso-search-eastus.search.windows.net/indexes/hotels-sample/docs/search?api-version=2025-09-01

{
    "search": "room with a view",
    "count": true,
    "top": 15,
    "skip": 15
}

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

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

{ "id": "1", "rating": 5 }
{ "id": "2", "rating": 3 }
{ "id": "3", "rating": 2 }
{ "id": "4", "rating": 1 }

Теперь предположим, что вы хотите, чтобы результаты возвращались по два за раз, упорядоченные по рейтингу. Вы выполните этот запрос для получения первой страницы результатов: $top=2&$skip=0&$orderby=rating desc, и это приведет к следующим результатам.

{ "id": "1", "rating": 5 }
{ "id": "2", "rating": 3 }

Предположим, что во время работ по обслуживанию в индекс между запросами добавляется пятый документ: { "id": "5", "rating": 4 }. Вскоре после этого вы выполните запрос для получения второй страницы: $top=2&$skip=2&$orderby=rating desc и получите следующие результаты.

{ "id": "2", "rating": 3 }
{ "id": "3", "rating": 2 }

Обратите внимание, что документ 2 извлекается дважды. Это связано с тем, что новый документ 5 имеет большее значение рейтинга, поэтому он при сортировке попадает в индекс раньше документа 2 и появляется на первой странице. Хотя такое поведение может быть неожиданным, обычно оно характерно для поисковой системы.

Пролистывание большого количества результатов

Альтернативный способ разбиения по страницам — использовать порядок сортировки и фильтр диапазона в качестве обходного skipрешения.

В этом обходном пути сортировка и фильтрация применяются к полю идентификатора документа или другому полю, уникальному для каждого документа. Уникальное поле должно иметь атрибуты filterable и sortable в индексе поиска.

Выполните запрос, чтобы вернуть полную страницу отсортированных результатов.

POST /indexes/good-books/docs/search?api-version=2025-09-01
    {  
      "search": "divine secrets",
      "top": 50,
      "orderby": "id asc"
    }

Выберите последний результат, возвращенный поисковым запросом. Приведен здесь пример результата только с значением идентификатора.
```
{
    "id": "50"
}
```
Используйте это значение идентификатора в запросе диапазона, чтобы получить следующую страницу результатов. Это поле идентификатора должно иметь уникальные значения, в противном случае разбиение на страницы может содержать повторяющиеся результаты.
```
POST /indexes/good-books/docs/search?api-version=2025-09-01
    {  
      "search": "divine secrets",
      "top": 50,
      "orderby": "id asc",
      "filter": "id ge 50"
    }
```
Разбиение на страницы заканчивается, когда запрос возвращает ноль результатов.

Примечание.

filterable Атрибуты sortable можно включить только при первом добавлении поля в индекс, они не могут быть включены в существующем поле.

Упорядочение результатов

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

оценка поиска
оценка семантического переранжировщика
порядок сортировки по полю sortable

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

Порядок по оценке поиска

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

Диапазон @search.score не ограничен или равен от 0 до (но не включая) 1.00 на старых сервисах.

Для любого из алгоритмов @search.score значение, равно 1.00, указывает на неоцененный или неранжированный набор результатов, где оценка 1.0 является одинаковой для всех результатов. Неподсчитанные результаты возникают, когда запрос является нечетким поиском, подстановочным знаком, регулярными выражениями или пустым поиском (search=*). Если необходимо наложить структуру ранжирования на незасчитанные результаты, рассмотрите orderby выражение для достижения этой цели.

Упорядочение с помощью семантического пересмотра порядка

Если вы используете семантический рангировщик, @search.rerankerScore определяет порядок сортировки результатов.

Диапазон @search.rerankerScore составляет от 1 до 4,00, где более высокий показатель указывает на более сильное семантические совпадения.

Заказ с функцией orderby

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

Поля, часто используемые в orderby, включают рейтинг, дату и местоположение. Для фильтрации по расположению требуется, чтобы выражение фильтра вызывает geo.distance() функцию в дополнение к имени поля.

Числовые поля (, Edm.Double, Edm.Int32) сортируются в числовом порядке (Edm.Int64например, 1, 2, 10, 11, 20).

Строковые поля (Edm.StringEdm.ComplexTypeподфилды) сортируются в порядке сортировки ASCII или порядке сортировки Юникода в зависимости от языка.

Числовое содержимое в строковых полях отсортировано по алфавиту (1, 10, 11, 2, 20).
Строка в верхнем регистре сортируется перед строкой в нижнем регистре (APPLE, Apple, БАНАН, Банан, яблоко, банан). Вы можете назначить нормализатор текста для предварительной обработки текста перед сортировкой, чтобы изменить это поведение. Использование токенизатора в нижнем регистре для поля не влияет на поведение сортировки, так как в Azure AI Search сортировка производится по неанализируемой копии поля.
Строки, которые начинаются с диакритических знаков, появляются последними (Äpfel, Öffnen, Üben)

Повышение релевантности с помощью профиля оценки

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

Выделение совпадений

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

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

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

Требования к выделению попаданий

Поля должны быть Edm.String или Collection(Edm.String)
Поля должны быть указаны в searchable

Укажите выделение в запросе

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

По умолчанию разметка формата имеет значение <em>, но вы можете переопределить тег, используя параметры highlightPreTag и highlightPostTag. Клиентский код обрабатывает ответ (например, применение полужирного шрифта или желтого фона).

POST /indexes/good-books/docs/search?api-version=2025-09-01
    {  
      "search": "divine secrets",  
      "highlight": "title, original_title",
      "highlightPreTag": "<b>",
      "highlightPostTag": "</b>"
    }

По умолчанию поиск ИИ Azure возвращает до пяти выделений на поле. Это число можно изменить, добавив тире, за которым следует целое число. Например, "highlight": "description-10" возвращает до 10 выделенных терминов для сопоставления содержимого в поле описания.

Выделенные результаты

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

В поиске ключевых слов каждый термин проверяется независимо. Запрос на "божественные секреты" возвращает совпадения для любого документа, содержащего любой термин.

Подсветка ключевых слов в поиске

В выделенном поле форматирование применяется ко всем терминам. Например, при совпадении с "The Divine Secrets of the Ya-Ya Sisterhood", форматирование применяется к каждому термину отдельно, хотя они идут подряд.

"@odata.count": 39,
"value": [
    {
        "@search.score": 19.593246,
        "@search.highlights": {
            "original_title": [
                "<em>Divine</em> <em>Secrets</em> of the Ya-Ya Sisterhood"
            ],
            "title": [
                "<em>Divine</em> <em>Secrets</em> of the Ya-Ya Sisterhood"
            ]
        },
        "original_title": "Divine Secrets of the Ya-Ya Sisterhood",
        "title": "Divine Secrets of the Ya-Ya Sisterhood"
    },
    {
        "@search.score": 12.779835,
        "@search.highlights": {
            "original_title": [
                "<em>Divine</em> Madness"
            ],
            "title": [
                "<em>Divine</em> Madness (Cherub, #5)"
            ]
        },
        "original_title": "Divine Madness",
        "title": "Divine Madness (Cherub, #5)"
    },
    {
        "@search.score": 12.62534,
        "@search.highlights": {
            "original_title": [
                "Grave <em>Secrets</em>"
            ],
            "title": [
                "Grave <em>Secrets</em> (Temperance Brennan, #5)"
            ]
        },
        "original_title": "Grave Secrets",
        "title": "Grave Secrets (Temperance Brennan, #5)"
    }
]

Подсветка результатов фразового поиска

Форматирование целого термина применяется даже к поиску фраз, где несколько терминов заключены в двойные кавычки. В следующем примере представлен тот же запрос, за исключением того, что "божественные секреты" передаются как заключенная в кавычки фраза (некоторые клиенты REST требуют, чтобы вы избежали внутренние кавычки с обратной косой чертой \"):

POST /indexes/good-books/docs/search?api-version=2025-09-01 
    {  
      "search": "\"divine secrets\"",
      "select": "title,original_title",
      "highlight": "title",
      "highlightPreTag": "<b>",
      "highlightPostTag": "</b>",
      "count": true
    }

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

{
    "@odata.count": 1,
    "value": [
        {
            "@search.score": 19.593246,
            "@search.highlights": {
                "title": [
                    "<b>Divine</b> <b>Secrets</b> of the Ya-Ya Sisterhood"
                ]
            },
            "original_title": "Divine Secrets of the Ya-Ya Sisterhood",
            "title": "Divine Secrets of the Ya-Ya Sisterhood"
        }
    ]
}

Выделение фраз в устаревших службах

Службы поиска, созданные до 15 июля 2020 года, реализуют другой опыт подсветки для фразовых запросов.

В следующих примерах предположим, что строка запроса содержит заключенную в кавычки фразу "Суперкубок". До июля 2020 г. выделен любой термин в фразе:

"@search.highlights": {
    "sentence": [
        "The <em>super</em> <em>bowl</em> is <em>super</em> awesome with a <em>bowl</em> of chips"
   ]

Для служб поиска, созданных после июля 2020 года, в @search.highlights возвращаются только фразы, соответствующие полной фразе:

"@search.highlights": {
    "sentence": [
        "The <em>super</em> <em>bowl</em> is super awesome with a bowl of chips"
   ]

Следующие шаги

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

Создайте демонстрационное приложение в портале Azure для создания HTML-страницы с панелью поиска, фасетной навигацией и областью эскизов, если у вас есть изображения.
Добавление поиска в веб-приложения — это учебник по C# и пример кода, который использует библиотеки JavaScript React для взаимодействия с пользователем. Приложение развертывается с помощью статических веб-приложений Azure и реализует пагинацию.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-05-29