Применяйте возможности генеративной оркестрации

Генеративная оркестрация — это очередной виток эволюции разговорных агентов в Copilot Studio. Она реализует уровень планирования на базе большой языковой модели (LLM), который реализует интерпретацию намерений пользователя, разбивает сложные запросы на более мелкие, выбирает нужные инструменты и знания и выполняет многоступенчатые планы с учетом ограничений, направленных на обеспечение безопасности и соответствия. Вместо того чтобы полагаться исключительно на созданные вручную темы для разговоров, генеративная оркестрация объединяет многоразовые строительные блоки — действия, темы, источники знаний, дочерние агенты и автономные триггеры — в интеллектуальные рабочие процессы.

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

Почему важна генеративная оркестрация?

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

  • Большие наборы тем с пересекающейся логикой.
  • Трудности с обработкой неоднозначных или реплик с множественными намерениями.
  • Неоднородный пользовательский опыт, когда пользователи формулируют вопросы по-разному.
  • Высокая стоимость обслуживания при изменении API или бизнес-правил.

Генеративная оркестрация решает эти задачи следующим образом:

  • Сокращение разрастания тем за счет создания многоразовых компонентов.
  • Автоматическое заполнение слотов на основе параметров ввода.
  • Динамическая адаптация стиля ответа и структуры плана.
  • Повышение релевантности за счет извлечения семантических знаний.
  • Обеспечение проактивных предложений по следующим шагам.

Архитектура и компоненты

На общем уровне, генеративный оркестратор-агент состоит из нескольких ключевых компонентов, работающих вместе:

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

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

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

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

  • Триггеры-события (автономия): механизмы, запускающие оркестратор без сообщения от пользователя. Эти механизмы могут быть запланированными триггерами или триггерами, основанными на событиях, таких как обновление записи в базе данных, которые позволяют агенту автономно запускать план. У каждого триггера могут быть собственные условия и инструкции. Автономные триггеры позволяют агенту действовать проактивно, инициируя рабочие процессы при выполнении определенных условий, а не ограничиваться реакцией на ввод пользователя в чате.

Слои управления и границы принятия решений

В агенте производственного уровня не позволяйте ИИ принимать все решения. Обычно существует три слоя контроля:

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

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

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

Учитывая эти слои, явно определите границы принятия решений. Обратите внимание на то, какие действия и темы:

  • Могут выполняться без подтверждения (ИИ может просто выполнить действие)
  • Требуют подтверждения пользователем в разговоре (например, "Вы уверены, что хотите удалить все записи?")
  • Требуют согласования вне чата (например, подтверждения администратором через рабочий процесс утверждения)

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

Лучшие практики по составлению инструкций агентов

Правильно составленные инструкции для агентов влияют на качество построения планов.

  • Контекстная релевантность

    • Убедитесь, что инструкции ссылаются только на инструменты и знания, доступные агенту.
    • Используйте точные имена инструментов, имена переменных и идентификаторы Power Fx.
  • Рекомендации по ведению диалога

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

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

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

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

Проектирование входных и выходных данных тем

При создании тем уделяйте особое внимание их входным и выходным параметрам в режиме генеративной оркестрации:

  • Определите четкие входные параметры с описаниями: Если тема или действие требует определенной информации (например, "Имя пользователя" для темы сброса пароля), создайте для нее входной параметр темы, дайте ему описательное название и пример. Оркестратор использует эти имена и описания, чтобы автоматически запросить у пользователя недостающее значение. Использование списка допустимых значений или формулы валидации Power Fx для входных данных помогает убедиться, что бот получает действительные данные (например, ограничение кода страны/региона двумя буквами).

  • Используйте автоматическую генерацию запросов: в генеративном режиме агент самостоятельно формирует вопросы, вместо необходимости вручную добавлять узлы вопросов для запроса недостающей информации. Этот подход — значительное изменение по сравнению с классическими ботами. Главное — чтобы названия входных параметров были понятны человеку (например, "дата начала", "адрес электронной почты"), чтобы ИИ мог сформулировать естественный вопрос. Если автоматически сгенерированный вопрос ИИ сформулирован не идеально, рекомендуется скорректировать описание или название входного параметра. Эта функция значительно упрощает диалоги, но зависит от четко определенных входных данных.

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

  • Избегайте "двойной обработки" данных в запросах: если вы настраиваете выходные данные, не передавайте эти же выходные данные в LLM как открытый контекст. Например, если действие возвращает текст сводки, передайте этот текст как структурированные выходные данные и позвольте оркестратору включить его, вместо того чтобы писать инструкцию вроде "Результат действия: {сводка}". Такой подход предотвращает чрезмерную генерацию или повторение контента моделью. Выходные данные должны представлять собой окончательные точки данных всегда, когда это возможно.

Связывание действий, тем и знаний

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

  • Дайте всем элементам интуитивно понятные имена и описания: планировщик в основном решает использовать инструмент или тему, исходя из того, насколько хорошо их название и описание соответствуют запросу пользователя. Используйте активные фразы, соответствующие намерениям пользователя. Например, инструмент с названием "TranslateText" и описанием "Переводит текст на указанный язык" будет выбираться чаще, когда пользователь спрашивает о переводе, чем инструмент с нейтральным названием "Flow1". Названия имеют наибольшее значение. Избегайте неясных названий. Если агент выбирает неправильную тему, пересмотрите соответствующие названия и описания.

  • Предоставляйте обширный "набор инструментов", но тщательно подбирайте его: подключайте все полезные действия, которые могут понадобиться вашему сценарию (API, потоки и т.д.), и создавайте темы для важных потоков. Такой подход дает ИИ больше вариантов для обработки запросов. Однако удаляйте или отключайте инструменты и темы, которые, как вы знаете, неактуальны или опасны для агента, чтобы они не запутали планировщика. Меньший набор качественных вариантов лучше, чем исчерпывающий набор с перекрывающимися возможностями. Перекрывающиеся описания могут привести к тому, что агент будет пытаться выполнить несколько действий одновременно, что может быть нежелательно.

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

  • Обрабатывайте несколько намерений: если пользовательский запрос содержит две отдельные задачи (например, "открой новый счет и отправь мне детали"), генеративный планировщик пытается выполнить обе, последовательно вызывая соответствующие последовательности. Вам не нужно вручную реализовывать ветвление для работы с несколькими намерениями. Ваша задача как разработчика — убедиться, что каждая подзадача (открытие счета, отправка данных) реализована с помощью соответствующего инструмента или темы, и при необходимости их входные и выходные данные связаны между собой.

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

  • Учитывайте рамки использования знаний: сейчас вы не можете заставить агента использовать конкретную статью по запросу. ИИ выбирает релевантные статьи на основе запроса. Также обратите внимание на ограничения. Например, системные темы, такие как "Несколько совпадающих тем", не используются в генеративном режиме, поскольку планировщик иначе осуществляет разрешение неоднозначности. Подробнее о других известных ограничениях генеративной оркестрации.

Тестирование и настройка оркестрируемого агента

Генеративная оркестрация переносит часть логики из явного проектирования в "мозг" ИИ. Итеративное тестирование обеспечивает соответствие ожидаемому поведению. Вот лучшие практики тестирования и совершенствования оркестрируемого агента:

  • Используйте карту активности: Copilot Studio предоставляет карту активности во время тестирования, на которой отображаются шаги, запланированные оркестратором. После того как вы задали агенту сложный запрос, проверьте план: какие темы или действия были задействованы? В каком порядке? Задал ли он уместный уточняющий вопрос? Если агент выбрал неправильную тему или не использовал нужный инструмент, возможно, придется уточнить описания компонентов или скорректировать инструкции.

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

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

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

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

Генеративные системы учатся неявно на ваших конфигурациях и исправлениях. Каждое улучшение инструкций или метаданных делает следующее решение ИИ лучше. Со временем ваш оркестрируемый агент становится более точным и эффективным в обработке запросов.

Пользовательские триггеры в генеративной оркестрации

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

Триггер Когда срабатывает Назначение
При запросе знаний Непосредственно перед выполнением агентом запроса к базе знаний Этот триггер позволяет перехватить момент, когда оркестратор собирается искать источники знаний. Он предоставляет доступ только для чтения к SearchPhrase или ключевым словам, которые агент планирует использовать, а также системную переменную для предоставления пользовательских результатов поиска. Например, вы можете перехватить запрос и перенаправить его в проприетарный индекс или добавить дополнительные данные в результаты.
Это расширенный ("скрытый") триггер — по умолчанию он не отображается в интерфейсе и в настоящее время должен включаться через редактирование YAML-файла (при условии, что тема называется точно OnKnowledgeRequested). Используйте этот триггер, если вам нужно модифицировать или персонализировать этап извлечения знаний, например, для фильтрации определенных результатов или интеграции внешних данных в ответ системы знаний.
Ответ ИИ сгенерирован После того как ИИ составит черновик ответа, но до его отправки пользователю Агент запускает этот триггер после того, как формирует итоговый текст ответа (на основе результатов работы инструментов и тем) и перед отправкой пользователю. Этот шаг дает вам возможность программно изменить ответ или его цитаты. Например, вы можете обработать текст для исправления форматирования или заменить необработанные URL-адреса на удобные ссылки для отслеживания. Вы даже можете решить переопределить ответ. Триггер может сформировать индивидуальное сообщение, и вы можете использовать флаг ContinueResponse, чтобы указать, следует ли отправлять исходный ответ ИИ или нет.
Используйте этот триггер для финальных корректировок или улучшений ответа ИИ, например, для добавления запроса к опросу или удаления нежелательных данных, которые были включены ИИ, но вы хотите их убрать. Чрезмерное использование этого триггера может указывать на логику, которая могла бы быть в основных инструкциях. Используйте этот триггер для детального контроля, когда это необходимо.
По завершении плана После того как весь план будет выполнен и ответ отправлен Когда план завершен, то есть все этапы выполнены и пользователь видит ответ, этот триггер запускается. Обычно этот триггер используют для запуска процессов завершения разговора. Распространенное применение — перенаправить разговор на конкретную конечную тему или на опрос. Например, у вас может быть тема "Завершение чата", которая благодарит пользователя или предлагает дальнейшие шаги. С помощью триггера "По завершении плана" вы можете автоматически активировать эту тему.
Однако будьте осторожны: скорее всего, вы не захотите заканчивать разговор после каждого вопроса пользователя, особенно если пользователь может задать дополнительные вопросы. Добавьте логику завершения разговора только если установлен определенный контекстный параметр или если план решил определенный тип запроса. По сути, используйте "По завершении плана" для выполнения завершающих действий или плавного завершения беседы, когда это уместно.

Больше возможностей генеративной оркестрации

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