Важно тщательно продумать, как и где принимаются решения в вашей агентной системе.
Если делегировать LLM больше решений, система потенциально сможет справляться с более широким кругом задач, но это может снизить ее скорость, надежность и устойчивость.
По возможности старайтесь переносить как можно больше процессов принятия решений из LLM в явный программный код. Это особенно важно для производственных процессов и процессов с высоким уровнем риска.
При проектировании агентной системы на базе LLM один из важнейших вопросов — какая часть принятия решений должна выполняться моделью LLM, а какая — явным программным кодом.
Для наглядности представим этот выбор как спектр между следующими подходами:
Архитектуры на основе маршрутизатора явно задают порядок и логику в коде, обеспечивая тестируемость, предсказуемость и устойчивость при решении узкоспециализированных задач (их также называют «агентами рабочих процессов»).
Агенты-оркестраторы используют большие языковые модели (LLM), чтобы динамически определять ход выполнения задач с помощью запросов на естественном языке. Такой подход оптимален для открытых взаимодействий, где заранее заданной логики недостаточно или ее невозможно предусмотреть.
Для производственных процессов с высоким уровнем риска мы обычно рекомендуем шире использовать возможности маршрутизатора, оставляя оркестраторы для приложений, которым нужны гибкие диалоги общего назначения.
Архитектуры на основе маршрутизатора
Агентные системы с маршрутизатором:
Явно задают процесс принятия решений в коде или ПО и используют LLM, чтобы определить, по какому маршруту должно пойти выполнение.
Ближе к традиционным программным системам: у них есть четкие и предсказуемые маршруты, обеспечивающие более стабильные результаты.
Идеально подходят для задач, которые можно строго формализовать.
Ниже приведен упрощенный пример агента бронирования авиабилетов в чат-боте, использующего «подход с маршрутизатором». LLM помогает отнести намерение пользователя к одному из трех вариантов, но именно наше ПО сопоставляет это намерение с шаблонным текстовым ответом. Благодаря жестким ограничениям LLM ее поведение будет более последовательным для пользователя.
Архитектуры с оркестратором
В отличие от систем с маршрутизатором, агентные системы с оркестратором:
Задают логические потоки с помощью запросов на естественном языке, а не программного кода. Примечание: в отличие от языка программирования естественный язык по своей природе неоднозначен и гибок. Это одновременно преимущество и недостаток, о чем мы поговорим далее. Мы называем это «намерением вместо инструкции».
Могут предлагать несколько вариантов обработки, а LLM определяет порядок и способ их выполнения.
Могут динамически создавать новые логические маршруты, которые трудно явно задать в программном коде.
Такая неоднозначность может приводить к нестабильным результатам, но когда все работает, это кажется «волшебством».
В следующем примере подход с оркестратором применяется к той же упрощенной задаче авиакомпании. Вместо того чтобы поручать ПО выбор подходящего ответа, принятие решения делегируют уровню LLM. Здесь используется мультиагентная система: «главный» агент-оркестратор сортирует запрос пользователя и передает его агенту, специально предназначенному для изменения рейсов, а тот формирует окончательный ответ пользователю.
В этом примере уровень LLM одновременно выполняет функции классификатора, маршрутизатора и составителя ответа. В примере с маршрутизатором он выполнял только функцию классификатора, а остальное делало ПО.
По возможности мы рекомендуем использовать архитектуры с маршрутизатором, поскольку у них есть следующие преимущества:
Скорость и эффективность: локальные вычисления выполняются быстрее, чем операции оркестраторов, зависящих от внешних API. Кроме того, обработать логику «IF/ELSE» в Python гораздо дешевле, чем платить поставщику LLM за ее выполнение моделью с 400 миллиардами параметров.
Тестируемость и предсказуемость: отладка, тестирование и сопровождение значительно упрощаются благодаря проверенным методам разработки ПО.
Прозрачность и надежность: меньшая вариативность поведения упрощает устранение неполадок. Кроме того, бо́льшая часть логики приложения представлена прозрачным программным кодом с контролем версий, а не непрозрачными и неинтерпретируемыми весами LLM.
Недостаток подходов с маршрутизатором — их жесткость и негибкость, из-за которых они хуже справляются с более открытыми задачами. Чат-бот, который всегда отвечает совершенно одинаково, может показаться пользователям скучным и однообразным.
Архитектуры с оркестратором обладают мощными возможностями:
Планирование: могут динамически планировать ответы.
Выбор инструментов и передача между агентами: выбирают подходящие инструменты или делегируют задачи агентам.
Итеративное объединение результатов: многократно обрабатывают и творчески комбинируют результаты.
Определение завершенности: устанавливают, когда собрано достаточно информации для окончательного ответа.
Такие фреймворки, как Pydantic-AI или Agents SDK от OpenAI, позволяют быстро и просто реализовать оркестрацию. Поэтому этот подход отлично подходит для демонстраций и проверки концепций.
Недостатки этого подхода:
Нельзя гарантировать, что этапы планирования LLM и последующие действия окажутся правильными и уместными. У системы с маршрутизатором есть та же проблема, но благодаря более строгим ограничениям ее поведение предсказуемее.
Для простых, четко определенных задач полный набор возможностей мультиагентной системы, скорее всего, не нужен. Например, в нашем примере с агентом авиакомпании число типов запросов, с которыми пользователи действительно обращаются в службу поддержки, вероятно, весьма ограничено.
Поскольку в LLM сосредоточено больше логики, злоумышленникам гораздо проще провести джейлбрейк или воспользоваться уязвимостями.
Принятие решений скрывается внутри LLM, поэтому понять работу системы становится сложнее, хотя инструменты мониторинга вроде Langfuse или Braintrust могут отчасти помочь.
Примечание для читателя: хотя возможности моделей быстро меняются, изложенные ниже рекомендации вряд ли изменятся в ближайшем будущем.
Определите границы своей задачи.
Можно ли легко представить желаемую логику принятия решений в виде схемы?
Недопустимы ли для вашего приложения сбои или неожиданное поведение?
Ответ «да» хотя бы на один из этих вопросов указывает, что лучше использовать возможности маршрутизатора.
По возможности мы рекомендуем использовать подходы с маршрутизатором, пока они справляются с задачей. Общее правило: если часть системы можно выразить в коде, реализуйте ее в коде, то есть не используйте LLM без необходимости.
Когда возможности таких подходов исчерпаны, некоторые преимущества оркестратора для открытых задач можно воспроизвести в контролируемой форме. Например:
Выбор инструментов и передача между агентами: легко реализуются с помощью условного ветвления или классификаторов LLM.
Определение завершенности: простые классификаторы LLM могут проверить полноту ответа перед его отправкой пользователю.
Однако «планирование» и «итеративное объединение результатов», несомненно, гораздо сложнее реализовать в жесткой системе с маршрутизатором. Поэтому, когда задача требует таких возможностей — по оценке классификатора LLM или другой логики, — мы предлагаем создать в системе менее ограниченную ветвь с оркестратором.
При выборе между архитектурой с маршрутизатором и оркестратором следует учитывать определенность и сложность задач приложения, а также характер взаимодействия с ним. Сегодня подходы с маршрутизатором обеспечивают надежность, эффективность и простоту тестирования четко определенных задач. Оркестраторы обеспечивают бо́льшую гибкость для широких диалоговых взаимодействий.
По мере развития LLM баланс между этими подходами может меняться. Для производственных нагрузок мы предпочитаем архитектуры с маршрутизатором или гибридные решения, а оркестраторы оставляем для открытых задач, требующих динамичного взаимодействия, похожего на человеческое.