Планируйте развертывания агентов Copilot Studio с учетом ограничений пропускной способности и скорости

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

В этой статье представлены рекомендации для архитекторов решений, разработчиков и администраторов Power Platform по подготовке масштабных развертываний Copilot Studio к производственному трафику, приёмочному тестированию (UAT), нагрузочному тестированию, сценариям взаимодействия с клиентами (B2C) и автономным рабочим нагрузкам.

Обеспечение пропускной способности выполняется отдельно от подготовки лицензии

Планирование Copilot Studio в рабочей среде включает два связанных, но отдельных рабочих потока:

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

Примечание.

Microsoft использует термин квоты для лимитов скорости Copilot Studio. В более широком отраслевом лексиконе эта деятельность по планированию часто называется обеспечение пропускной способности. Изучите опубликованные лимиты, оцените пиковую скорость запросов и планируйте до начала поступления производственного трафика.

Система оплаты по мере использования может увеличить доступные лимиты по сравнению с конфигурациями с низкой пропускной способностью, но пропускная способность не бесконечна. Проверьте текущие лимиты Copilot Studio, распределение запросов Power Platform, лимиты Power Automate, лимиты защиты сервиса Dataverse, правила регулирования соединителей и лимиты вызываемых API.

Что происходит при регулировании количества запросов?

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

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

Информация о специфических симптомах Copilot Studio и сообщениях об ошибках приведена в статье Устранение ошибок, связанных с ограничениями использования в агентах.

Как измеряются ограничения пропускной способности

Ограничения пропускной способности измеряют, какой объем трафика служба может принять в течение определенного временного окна. Рассматривайте эти временные окна на уровне: за минуту, за пять минут, за 10 минут, за час, за день, за неделю и за месяц. Месячный или недельный объём помогает оценить общий спрос, но более короткие окна более критичны для обеспечения пропускной способности, поскольку регулирование количества запросов часто возникает из-за всплесков трафика.

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

Оцените масштаб ограничений

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

Например, лимиты на сообщения в Copilot Studio для агентов устанавливаются на уровне среды Dataverse. При оценке трафика учитывайте все источники, которые отправляют сообщения агентам в данной среде, включая пользовательские каналы, интеграции, автономные рабочие нагрузки и навыки Azure Bot Framework. Проверьте текущие значения и область действия в квотах и лимитах Copilot Studio.

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

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

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

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

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

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

Совет

Сценарии типа B2C и автономные сценарии использования следует относить к первоочередным случаям применения регулирования частоты запросов. Они способны генерировать всплески трафика, несколько одновременных запросов и высокочастотную фоновую активность быстрее, чем многие внутренние чат-боты для сотрудников.

Ориентируйтесь на пиковые временные интервалы, а не исключительно на месячные совокупные показатели

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

Ежемесячный объём полезен для оценки общего спроса, но его недостаточно для регулирования частоты запросов. Преобразуйте ожидаемое использование в более короткие временные интервалы, чтобы сравнить проект с текущими лимитами на запросы в минуту (RPM), запросы в час (RPH), пиковые нагрузки (burst) и суточные лимиты, приведённые на указанных страницах.

Сформируйте профиль среднего трафика и профиль пикового трафика. Например, если большая часть трафика происходит ежедневно с 17:00 до 18:00, часовой пик должен отражать эту концентрацию. Суточная оценка не обязательно должна быть в 24 раза больше значения часового пика, если трафик сосредоточен в одном временном окне.

Когда ещё может произойти регулирование количества запросов?

Регулирование количества запросов также может возникать, когда:

  • Большое число сотрудников использует агента в заранее известное пиковое окно, например, во время мероприятия или обучения для всего отдела.
  • Маркетинговая кампания, сбой, запуск или запланированное бизнес-мероприятие вызывают короткий скачок трафика.
  • Потоки Power Automate включают циклы, повторы, постраничную обработку или дочерние потоки, которые увеличивают объём запросов.
  • Формирование отчетов, аудиторские операции, выгрузка телеметрии и сохранение транскриптов работают в синхронном режиме в ходе обработки текущего пользовательского запроса.
  • Несколько агентов или рабочих нагрузок используют одну и ту же среду, учётную запись, соединитель или ёмкость нижестоящих API.
  • При проведении нагрузочных тестов рост интенсивности запросов происходил быстрее, чем это позволяла выдержать производственная архитектура или отработанный процесс операционной поддержки.

Где найти соответствующие лимиты на количество запросов

У Copilot Studio есть собственные ограничения, и путь выполнения агента может включать другие сервисы с их собственными ограничениями. Ознакомьтесь со всеми соответствующими лимитами для сервисов, которые использует ваш агент.

Лимиты Copilot Studio

Область обеспечения пропускной способности Что необходимо проверить Где проверить текущие значения Использование
Сообщения агенту Текущий лимит RPM/RPH (запросов в минуту/час) и область применения для сообщений, отправляемых агенту. Квоты и лимиты Copilot Studio Сравните ожидаемое количество сообщений в минуту и в час для целевой среды Dataverse.
Генеративные сообщения ИИ Текущий лимит для генеративной оркестрации, действий агента, инструментов ИИ, действий рабочих процессов агента и генеративных ответов. Сообщения генеративного ИИ агенту Моделируйте ИИ-насыщенные и автономные сценарии с учетом текущих опубликованных ограничений.
Узлы автономного триггера Текущие ограничения, которые применяются, когда автономный агент активируется событиями, расписаниями или фоновыми процессами. Квоты и лимиты Copilot Studio Моделируйте рабочие нагрузки, управляемые событиями и расписаниями, отдельно от интерактивного чат-трафика.
Лимиты запросов по подписке Copilot Studio Текущие лимиты запросов Power Platform для использования Copilot Studio Ограничения подписки на Copilot Studio Используйте эти значения вместе с планированием лимитов скорости для потоков, Dataverse и подключённых сервисов.

Другие лимиты платформы, которые следует учитывать

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

Примечание.

Ограничения других платформ могут повлиять на работу вашего агента, если в пути запроса агента используются сторонние компоненты. Учитывайте также эти ограничения, включая Power Platform, Power Automate, Dataverse, соединители, языковые службы и нижестоящие системы.

Область среды выполнения На что обратить внимание Вопросы по обеспечению пропускной способности Где проверить текущие лимиты
Уровень выполнения запросов Power Platform Запросы через Power Automate, вызовы рабочих процессов Copilot Studio, использование Dataverse, Power Apps и Dynamics 365 Какой пользователь, подключение, пользователь-приложение или субъект-служба инициирует запросы? Достаточно ли распределения запросов для ожидаемой суточной и пиковой нагрузки? Ограничения на запросы и распределение запросов
Потоки Power Automate Триггеры, действия, циклы, дочерние потоки, HTTP-действия, действия соединителей, повторы, разбивка на страницы и параллелизм. Сколько действий создаётся за шаг агента? Подлежат ли учету ограничения по пиковым нагрузкам, параллелизму, триггерам и соединителям? Понимание ограничений платформы и предотвращение регулирования количества запросов

Ограничения автоматизированных, запланированных и мгновенных потоков
Dataverse Операции CRUD, подключаемые модули, рабочие процессы, операции назначения/совместного использования, вызовы соединителей и системные операции, необходимые для завершения транзакций. Какие пользователи, пользователи приложений или субъект-службы инициируют вызовы Dataverse? Могут ли применяться лимиты защиты сервиса или механизмы повторных попыток? Ограничения API, предусмотренные для защиты служб

Обзор ограничений API Dataverse
Соединители Стандартные соединители, премиум-соединители, пользовательские соединители, регулирование количества запросов на уровне конкретного соединителя и нижестоящие API. Какой соединитель является узким местом? Имеет ли нижестоящий сервис собственные ограничения на частоту запросов? Ограничения пропускной способности API для соединителей

Информация о соединителе Power Automate
Распознавание устной речи и службы ИИ Вызовы CLU, запросы ИИ, операции поиска и суммирования, инструменты на основе моделей, размер полезной нагрузки и специфические для сервиса ограничения. Каждый ход пользователя вызывает языковой или ИИ-сервис? Повторяются ли эти вызовы во время повторных попыток или оркестрации? Ограничения распознавания устной речи

Квоты и лимиты Copilot Studio
Внешние API и корпоративные системы API поставщиков, внутренние API, базы данных, промежуточное ПО, шлюзы и пользовательские сервисы. Какой лимит устанавливает владелец нижестоящего сервиса? Есть ли контракт на повторные попытки, очередь или стратегия обратного давления? Руководствуйтесь действующими лимитами нижестоящего сервиса, соглашением об уровнях обслуживания (SLA) и регламентом технической поддержки, определёнными владельцем этого сервиса.

Проектируйте так, чтобы снижать нагрузку на пропускную способность

Не прибегайте к повышению лимитов как к первому способу решения проблемы при проектировании. Сначала проанализируйте дизайн агента и оптимизируйте его эффективность. Если агенту нужно получить информацию, делайте внешние вызовы осознанно, оптимизируйте API-вызовы и избегайте ненужного объёма запросов в Copilot Studio, Power Automate, Dataverse, соединителях и нижестоящих системах.

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

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

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

Что делать, если стандартных лимитов на количество запросов недостаточно

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

Примечание.

Copilot Studio — это SaaS-сервис, для которого установлены ограничения на количество запросов, чтобы защитить сервис для всех клиентов. При соответствующем обосновании техническая команда может установить индивидуальные ограничения для одобренных сценариев.

Открыть запрос на поддержку

Администраторы могут запросить поддержку в центре администрирования Power Platform.

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

Основная информация, которую необходимо включить

Информация Description
Идентификатор среды Среда Dataverse, где работает агент.
Имя или идентификатор агента Агент, на которого распространяется запрос.
Влияние на бизнес Критическое влияние в случае, если стандартных лимитов окажется недостаточно.
Известная информация Что известно о сценарии, канале, условиях запуска, значимости для бизнеса и о том, является ли это B2C, автономным, ориентированным на сотрудников или предназначенным только для внутреннего использования.
Моментальный снимок агента Снимок или экспорт, который помогает рецензентам понять конфигурацию агента, дизайн, подключённые сервисы и соответствующие параметры.
Дизайн агента Высокоуровневое описание тем, применения генеративного ИИ, источников знаний, действий, потоков, соединителей, вызовов Dataverse и внешних API, которые используются агентом.
Оценка среднего трафика Ожидаемый средний объем трафика за час, день, неделю или месяц.
Оценка пикового трафика Ожидаемые пиковые значения для сообщений, сессий, вызовов генеративного ИИ, действий в потоках, вызовов соединителей, запросов к Dataverse и вызовов внешних API, если они известны.

Дополнительные сведения, которые могут помочь

Информация Description
Диапазон дат Дата начала и окончания запрошенного повышения лимита. Отдельно укажите сроки нагрузочного тестирования, пользовательского приемочного тестирования и производства, если они различаются.
Характер пиковых нагрузок Пиковые временные окна, часовые пояса, ожидаемые факторы резкого роста нагрузки и информация о том, концентрируется ли трафик в коротком ежедневном интервале.
Профиль сеанса Одновременные сеансы, средняя и максимальная продолжительность сеанса, сообщения на сеанс и вопросы на сеанс.
Типовые примеры сеансов Характерные пользовательские пути, типичные выполняемые шаги, используемые инструменты и, при наличии, примеры идентификаторов сеансов.
Путь выполнения Потоки, действия, ИИ-запросы, обращения к базе знаний, запросы Dataverse, соединители и API на каждое взаимодействие.
Пиковые значения на уровне функций Пиковая нагрузка на агента, функцию, пользователя, среду, соединитель, минуту, час и день (при наличии данных).
Продукты, требующие проверки Будь то Copilot Studio, выделение запросов Power Platform, Power Automate, соединители, Dataverse, CLU/AI-сервисы или внешние API.
Документальное подтверждение Выборочные идентификаторы сеансов, ошибки, корреляционные идентификаторы, журналы, результаты нагрузочных тестов или производственные наблюдения.
Устранение проблем Опишите, что вы уже предприняли для снижения нагрузки на пропускную способность. Обратитесь к руководству Проектирование для снижения нагрузки на пропускную способность, включая анализ архитектуры, оптимизированные внешние вызовы, сегментацию сред, пакетную обработку, очереди, фильтрацию триггеров, планирование расписания, распределение рабочей нагрузки и другие уже внедренные меры оптимизации.

Важно

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

  • Last updated on