Важливо ретельно продумати, як і де ухвалюються рішення у вашій агентній системі.
Передавання більшої кількості рішень 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 баланс між цими підходами може змінюватися. Для виробничих навантажень ми віддаємо перевагу маршрутизаторним або гібридним архітектурам, а оркестратори залишаємо для відкритих задач, що потребують динамічної взаємодії, подібної до людської.