Шаблоны проектирования агентной системы

Агенты GenAI объединяют аналитику моделей GenAI с инструментами для получения данных, внешних действий и других возможностей. На этой странице описывается проектирование агента:

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

Агенты сильно полагаются на средства сбора информации и принятия внешних действий. Дополнительные сведения о средствах см. в разделе "Сервис".

Пример системы агента

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

Клиент отправляет запрос: "Вы можете помочь мне вернуть последний заказ?"

1. Причина и план. Учитывая намерение запроса, агент планирует: "Просмотреть последний заказ пользователя и проверить нашу политику возврата".
2. Поиск сведений (аналитика данных): агент запрашивает базу данных заказов, чтобы получить соответствующий заказ и ссылается на политический документ.
3. Причина: агент проверяет, соответствует ли этот заказ периоду возврата.
   • Необязательное участие человека в процессе: Агент проверяет дополнительное правило: если элемент попадает в определенную категорию или находится за пределами обычного периода возврата, передать на рассмотрение человеку.
4. действие: агент активирует процесс возврата и создает метку доставки.
5. Причина: агент создает ответ для клиента.

Агент ИИ отвечает клиенту: "Готово! Вот ваша этикетка доставки..."

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

Уровни сложности: от LLM до систем агентов

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

Шаблон проектирования	Когда следует использовать	Плюсы	Минусы
LLM + запрос	Универсальный вопрос и ответ Быстрый прототип для краткосрочного использования	Очень просто Легко создать	Минимальная настройка
детерминированная цепочка	Четко определенные задачи Статические конвейеры, такие как базовый RAG Нет необходимости принимать решения на лету	Простота Простой аудит	Негибкий Требует изменения кода для адаптации
одноагентная система	Запросы от умеренной до сложной сложности в одном домене Некоторые динамические решения без затрат на несколько специализированных агентов	Гибкий Проще, чем с несколькими агентами Хороший "по умолчанию"	Менее прогнозируемый Должен защищаться от повторяющихся или неправильных вызовов инструментов
многоагентная система	Большие или кроссфункционные домены Несколько агентов "эксперт" с различными логиками или контекстами беседы	Высоко модульный Масштабирование до больших доменов	Сложный для оркестрации Труднее выполнять трассировку и отладку

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

Дополнительные сведения о теории, лежащей в основе систем агентов, см. в блогах основателей Databricks:

• системы агентов ИИ: модульное проектирование для надежных корпоративных приложений ИИ
• Переход от моделей к составным системам ИИ

LLM и запрос

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

детерминированная цепочка (жестко закодированные шаги)

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

Например, детерминированная цепочка извлечения с расширенной генерацией (RAG) может всегда:

1. Извлеките результаты top-k из векторного индекса, чтобы найти контекст, соответствующий запросу пользователя.
2. Дополните запрос, объединив запрос пользователя с извлеченным контекстом.
3. Создайте ответ, отправив дополненную строку в LLM.

Когда использовать:

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

Преимущества.

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

Соображения.

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

одноагентная система

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

Одноагентная система может:

1. Примите такие запросы, как запросы пользователей, и любой соответствующий контекст, например историю переписки.
2. Размышляйте о том, как лучше реагировать, при необходимости решая, следует ли вызывать инструменты для получения внешних данных или выполнения действий.
3. При необходимости повторно вызывайте LLM или инструменты до достижения цели или выполнения определенного условия, например, при получении допустимых данных или устранении ошибки.
4. Интегрируйте выходные данные инструмента в разговор.
5. Возвращает сплоченный ответ в виде выходных данных.

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

• Если пользователь задает простой вопрос («Какова наша политика возврата?»), агент может ответить непосредственно, используя знания LLM.
• Если пользователь хочет узнать статус своего заказа, агент может вызвать функцию lookup_order(customer_id, order_id). Если это средство отвечает на "недопустимый номер заказа", агент может повторить попытку или предложить пользователю правильный идентификатор, продолжая до тех пор, пока он не сможет предоставить окончательный ответ.

Когда использовать:

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

Преимущества.

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

Соображения.

• По сравнению с жестко заданной последовательностью, следует обеспечить защиту от повторяющихся или недопустимых вызовов инструментов. Бесконечные циклы могут возникать в любом сценарии вызова инструментов, поэтому задайте ограничения итерации или время ожидания.
• Если приложение охватывает совершенно разные поддомены (финансы, devops, маркетинг и т. д.), один агент может стать неуправляемым или перегруженным с требованиями к функциональным возможностям.
• Вам по-прежнему нужны тщательно разработанные запросы и ограничения, чтобы агент оставался сосредоточенным и актуальным.
• Агентность — это континуум; чем больше свободы вы предоставляете моделям для управления поведением системы, тем более агентным становится приложение. На практике большинство производственных систем тщательно ограничивают автономию агента, чтобы обеспечить соответствие и прогнозируемость, например, требуя одобрения человека для рискованных действий.

система с несколькими агентами

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

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

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

Когда использовать:

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

Преимущества.

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

Соображения.

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

Практические советы

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

Если необходимо создать пользовательскую систему агента, Azure Databricks и Custom Agent не зависят от выбранного шаблона, что упрощает развитие шаблонов разработки по мере роста приложения. Рассмотрим следующие рекомендации по разработке стабильных и обслуживаемых систем агентов:

1. Начать просто: Если вам нужна простая цепочка, детерминированная цепочка быстро строится.
2. Постепенно добавляйте сложность: Так как вам нужны более динамические запросы или гибкие источники данных, перейдите в систему с одним агентом с вызовом средства. Если у вас есть четко разные домены или задачи, несколько контекстов беседы или большой набор инструментов, то рассмотрим систему с несколькими агентами.
3. Объединение шаблонов: На практике многие системы агентов реального мира объединяют шаблоны. Например, в основном детерминированная цепочка может иметь один шаг, в котором LLM может динамически вызывать определенные API при необходимости.

Руководство по разработке

• Запросы и средства
  • Формулируйте запросы четко и кратко, чтобы избежать противоречивых инструкций, отвлекающей информации и уменьшить галлюцинации.
  • Укажите только инструменты и контекст, необходимые агенту, а не несвязанный набор API или большой неуместный контекст. Выберите подход к инструменту во время разработки.
• Ведение журнала и наблюдаемость
  • Реализуйте подробное логирование для каждого запроса пользователя, плана агента и вызова средства с помощью логирования MLflow.
  • Храните логи в безопасности и бережно относитесь к персонально идентифицируемой информации (PII) в данных беседы. Рассмотрим классификацию данных для автоматизации.

Руководство по тестированию и итерации

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

Руководство по производству

• Обновления моделей и фиксация версий
  • Поведение LLM может измениться, когда поставщики обновляют модели за кулисами. Используйте закрепление версий и частые тесты регрессии, чтобы убедиться, что логика агента остается надежной и стабильной.
• Оптимизация задержки и затрат
  • Каждый дополнительный вызов LLM или инструмента повышает использование токенов и увеличивает время ответа. По возможности объединить шаги или кэшировать повторяющиеся запросы для поддержания производительности и управления затратами.
• Безопасность и песочница
  • Если агент может обновлять записи или запускать код, изолируйте эти действия или обеспечьте получение одобрения человеком при необходимости. Это крайне важно в корпоративных или регулируемых средах, чтобы избежать непреднамеренного ущерба. Функции каталога Unity обеспечивают изолированное выполнение для рабочей среды.
  • Больше информации о вариантах выбора инструментов см. в инструментах агента ИИ.

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