Агентское извлечение в Поиск с использованием ИИ Azure

Примечание

Некоторые агентные функции извлечения доступны в версии REST API 2026-04-01 через программный доступ. Портал Azure и портал Microsoft Foundry продолжают предоставлять предварительный доступ ко всем агентным функциям извлечения. Рекомендации по миграции, включая обзор того, что доступно в общем доступе и что остаётся в предварительном просмотре, см. в разделе "Перенос кода агентного извлечения на последнюю версию".

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

Вот что это делает:

  • Использует большую языковую модель (LLM) для разбиения сложного запроса на небольшие вложенные запросы для повышения охвата индексированного содержимого. Вложенные запросы могут включать журнал чата для дополнительного контекста.

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

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

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

Этот высокопроизводительный конвейер помогает создавать высококачественные данные для обоснования (или ответа) для чат-приложения, благодаря возможности быстро отвечать на сложные вопросы.

Программируемый агентный запрос поддерживается через объект базы знаний в последней стабильной версии REST API (2026-04-01) и в предварительной версии (2025-11-01-preview), а также в соответствующих пакетах Azure SDK. Ответ на запрос к базе знаний предназначен для передачи другим агентам и chat-приложениям.

Почему использовать агентическое извлечение

Существует два случая использования для агентного поиска. Во-первых, это основа интерфейса Foundry IQ на портале Microsoft Foundry (новый). Он предоставляет слой знаний для решений для агентов на платформе Microsoft Foundry. Во-вторых, это основа для кастомизированных агентных решений, создаваемых с помощью API поиска Azure AI.

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

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

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

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

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

Агентивное извлечение добавляет задержку в обработку запросов, но компенсирует это, добавляя следующие возможности:

  • Считывает журнал чата в качестве входных данных в конвейер извлечения.
  • Деконструирует сложный запрос, содержащий несколько "запросов", на составные части. Например: "Найдите мне отель недалеко от пляжа, который предоставляет трансфер до аэропорта и находится в пешей доступности от вегетарианских ресторанов".
  • Перезаписывает исходный запрос в несколько подзапросов с помощью карт синонимов (необязательно) и парафразирования, созданного с помощью LLM.
  • Исправляет ошибки орфографии.
  • Выполняет все вложенные запросы одновременно.
  • Выводит унифицированный результат в виде одной строки. В качестве альтернативы, можно извлечь части ответа для вашего решения. Метаданные о выполнении запросов и ссылочных данных включаются в ответ.

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

Примечание

Включение LLM в планирование запросов добавляет задержку в конвейер запросов. Вы можете снизить последствия с помощью более быстрых моделей, таких как gpt-4o-mini, и суммировать потоки сообщений. Вы можете свести к минимуму задержку и затраты, задав свойства, ограничивающие обработку LLM. Вы также можете исключить обработку LLM полностью для простого текста и гибридного поиска и собственной логики планирования запросов.

Архитектура и рабочий процесс

Агентическое извлечение предназначено для взаимодействия с диалоговыми поисками, которые используют LLM для интеллектуального разбиения сложных запросов. Система координирует несколько служб Azure для предоставления комплексных результатов поиска.

Схема рабочего процесса агентского поиска с помощью примера запроса.

Принцип работы

Агентный процесс извлечения работает следующим образом:

  1. Запуск рабочего процесса. Приложение вызывает базу знаний с действием извлечения, которое предоставляет журнал запросов и бесед.

  2. Планирование запросов: база знаний отправляет историю запросов и бесед в LLM, который анализирует контекст и разбивает сложные вопросы на сконцентрированные подзапросы. Этот шаг автоматизирован и не настраивается.

  3. Выполнение запроса: база знаний отправляет вложенные запросы в источники знаний. Все вложенные запросы выполняются одновременно и могут быть ключевыми словами, вектором и гибридным поиском. Каждый подзапрос проходит семантическое повторное ранжирование, чтобы найти наиболее релевантные совпадения. Ссылки извлекаются и сохраняются в целях ссылки.

  4. Синтез результатов: система объединяет все результаты в унифицированный ответ с тремя частями: объединенное содержимое, исходные ссылки и сведения о выполнении.

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

Обязательные компоненты

Компонент Служба Роль
LLM Azure OpenAI Создает подзапросы на основе контекста беседы и позже использует анкерные данные для генерации ответов.
База знаний Поиск с использованием ИИ Azure Управляет цепочкой обработки, подключаясь к LLM и управляя параметрами запроса.
Источник знаний Поиск с использованием ИИ Azure Упаковывает индекс поиска со свойствами, относящимися к использованию базы знаний
Индекс поиска Поиск с использованием ИИ Azure Сохраняет содержимое, доступные для поиска (текст и векторы) с семантической конфигурацией
Семантический рангер Поиск с использованием ИИ Azure Используется внутри агентного конвейера извлечения для повторного ранжирования результатов по релевантности (L2 ранжирование)

Требования к интеграции

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

Примечание

Для планирования запросов поддерживаются только модели gpt-4o, gpt-4.1 и gpt-5. Вы можете использовать любую модель для окончательного создания ответов.

Доступность и цены

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

Биллинг

Извлечение агента влечет за собой расходы на две услуги:

  • Поиск с использованием ИИ Azure взимает плату за токены выборки, потребляемые во время выполнения вложенных запросов и семантического ранжирования. Бесплатный план (по умолчанию) предоставляет ежемесячное выделение токенов. Стандартный план предоставляет возможность оплаты по факту использования после исчерпания бесплатного лимита. Дополнительные сведения см. в разделе Включение или отключение выставления счетов за агентную выборку.

  • Azure OpenAI выставляет счета за использованные токены на входе и выходе, в планировании запросов на основе LLM и синтезе ответов. Цены всегда являются оплатой по мере использования и основаны на модели, назначаемой базе знаний. Начисления отображаются в вашем счете Azure OpenAI. Сведения о тарифах см. в разделе цены на Azure OpenAI.

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

Аспект Классический конвейер Извлечение агентности
Единицы На основе запроса На основе токена
Затраты на единицу Унифицированные затраты на запрос Переменные затраты на токен (зависят от усилий на рассуждение)
Оценка затрат Оценка количества запросов Оценка использования токена
Бесплатное пособие Ежемесячный бесплатный лимит на запросы Ежемесячное выделение бесплатных токенов

Пример. Оценка затрат

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

Чтобы оценить стоимость выполнения планов запросов по модели «оплата по мере использования» в Azure OpenAI, предположим, gpt-4o-mini:

  • 15 центов за 1 миллион входных токенов.
  • 60 центов за 1 миллион токенов на выходе.
  • 2,000 токенов ввода для среднего размера беседы в чате.
  • 350 маркеров для среднего размера плана вывода.

Предполагаемые затраты на выставление счетов для выполнения запросов

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

  • 10 000 блоков, где каждый блок составляет один до двух абзацев PDF.
  • 500 токенов на блок.
  • Каждый подзапрос перераспределяет до 50 фрагментов.
  • В среднем на один план запроса приходится три вложенных запроса.

Вычисление цены на выполнение

  1. Предположим, что мы делаем 2000 агентных извлечений с тремя подзапросами в каждой схеме. Это дает нам около 6000 общих запросов.

  2. Переупорядочить 50 фрагментов на каждый подзапрос, что составляет в общей сложности 300 000 фрагментов.

  3. Средний блок составляет 500 токенов, поэтому общий объем токенов для пересчета ранжирования составляет 150 миллионов.

  4. Учитывая гипотетическую цену 0,022 за токен, 3,30 $ является общей стоимостью для переранжирования в долларах США.

  5. Переход к стоимости планов запросов: 2000 входных токенов, умноженные на 2000 агентных извлечений, составляют 4 миллиона входных токенов в общей стоимости 60 центов.

  6. Оцените выходные затраты на основе среднего значения в 350 токенов. Если умножить 350 на 2000 агентов извлечения, мы получим 700 000 выходных токенов всего за 42 цента.

Сложив все это вместе, вы заплатите около $3,30 за агентический поиск в Поиск с использованием ИИ Azure, 60 центов за входные токены в Azure OpenAI и 42 цента за выходные токены в Azure OpenAI, всего $1,02 за планирование запросов. Совокупная стоимость полного выполнения составляет 4,32 $.

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

  • Просмотрите журнал действий в ответе, чтобы узнать, какие запросы были отправлены к источникам и какие параметры использовались. Вы можете повторно выполнить эти запросы к индексам и использовать общедоступный токенизатор для оценки маркеров и сравнения с использованием API. Точное восстановление запроса или ответа не гарантируется. Факторы включают тип источника знаний, например, общедоступные веб-данные или удаленный источник знаний в SharePoint, основанный на идентификации пользователя, что может повлиять на выполнение запросов.

  • Уменьшите количество источников знаний (индексов); консолидация контента может снизить фан-аут и объем токенов.

  • Уменьшите когнитивные затраты для снижения использования LLM в процессе планирования и расширения запросов (с использованием итеративного поиска).

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

Начало работы

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

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