Важно е внимателно да обмислите как и къде се вземат решенията във вашата агентна система.
Възлагането на повече решения на големи езикови модели може да позволи на системата да се справя с повече задачи, но потенциално за сметка на скоростта, надеждността и устойчивостта.
Където е възможно, опитайте да изнесете възможно най-голяма част от процеса на вземане на решения от големи езикови модели в изричен програмен код. Това важи особено за високорискови и/или производствени работни процеси.
При проектирането на агентна система, базирана на големи езикови модели, едно от най-важните решения е каква част от вземането на решения да бъде поверена на модел с големи езикови модели и каква — на изричен софтуер.
За по-лесно разбиране можем да разглеждаме този избор като спектър между следните подходи:
Архитектурите с маршрутизатор определят изрично последователността и логиката в кода, което осигурява възможност за тестване, предвидимост и устойчивост при задачи в тесни области (наричат се още „агенти за работни процеси“).
Агентите оркестратори разчитат на големи езикови модели, за да определят динамично хода на задачите чрез подкани на естествен език. Те са идеални за отворени взаимодействия, при които предварително зададената логика е недостатъчна или невъзможна.
За високорискови производствени работни процеси обикновено препоръчваме повече функции, базирани на маршрутизатор, а оркестраторите да се запазят за приложения, изискващи гъвкави разговори с общо предназначение.
Архитектури с маршрутизатор
Агентните системи с маршрутизатор:
Определят изрично потока за вземане на решения чрез код или софтуер и използват големи езикови модели, за да изберат кой маршрут да следва софтуерът.
Приличат повече на традиционните софтуерни системи, тъй като имат ясни и предвидими пътища, които водят до по-последователни резултати.
Идеални са за задачи, които могат да бъдат строго дефинирани.
Следва опростен пример за Агент за резервации чрез чатбот на авиокомпания, който използва „подход с маршрутизатор“. Макар големите езикови модели да ни помагат да класифицираме намерението на въпроса сред три възможности, в крайна сметка софтуерът свързва това намерение с шаблонен текстов отговор. Тъй като големите езикови модели са силно ограничени, потребителят получава по-последователно поведение.
Архитектури с оркестратор
За разлика от системите с маршрутизатор, агентните системи с оркестратор:
Определят логическите потоци чрез подкани на естествен език вместо чрез софтуер. Забележка: в сравнение с език за програмиране естественият език по своята същност е двусмислен и гъвкав — едновременно положителна и отрицателна характеристика, както ще обсъдим по-късно. Разглеждаме това като „намерение вместо инструкция“.
Могат да предложат множество възможности за обработка, като големите езикови модели определят реда и начина на изпълнение.
Могат динамично да създават нови логически пътища, които трудно се дефинират изрично в софтуер.
Тази двусмисленост може да доведе до непоследователни резултати, но когато подходът работи, усещането може да е „магическо“.
Следващият пример прилага подход с оркестратор към същия опростен проблем с авиокомпания. Вместо софтуерът да определя подходящия отговор, вземането на решения се възлага на слоя с големи езикови модели. Тук имаме многоагентна система, в която „главен“ Агент оркестратор преценява потребителското запитване и го предава на Агент, създаден специално за промяна на полети, който в крайна сметка отговаря на потребителя.
В този пример слоят с големи езикови модели изпълнява ролята на класификатор, маршрутизатор и автор на отговора. В примера с маршрутизатора той изпълняваше само ролята на класификатор, а софтуерът се грижеше за останалото.
Където е възможно, препоръчваме подходи с маршрутизатор заради следните предимства:
Бързина и ефективност: Локалните изчисления са по-бързи от оркестраторите, зависещи от външни API. Освен това е много по-евтино да обработвате логиката „IF/ELSE“ в Python, отколкото да плащате на доставчик на големи езикови модели, за да я изпраща през своя модел с 400 милиарда параметъра.
Възможност за тестване и предвидимост: Значително по-лесно отстраняване на грешки, тестване и поддръжка чрез утвърдени софтуерни практики.
Прозрачност и надеждност: По-малките вариации в поведението улесняват отстраняването на проблеми. Освен това по-голяма част от потока на приложението е изразена чрез прозрачен софтуер с контрол на версиите, а не чрез непрозрачните и неразбираеми тегла на големи езикови модели.
Недостатъкът на подходите с маршрутизатор е, че могат да бъдат твърди и негъвкави и да се затрудняват с по-отворени проблеми. Потребителите може да сметнат чатбот, който винаги дава едни и същи отговори, за скучен и еднообразен.
Проектите с оркестратор предлагат мощни възможности:
Планиране: Могат динамично да планират отговорите.
Избор на инструмент/предаване към Агент: Избират подходящи инструменти или възлагат задачи на агенти.
Итеративно комбиниране на резултати: Итеративно обработват и творчески съчетават резултатите.
Определяне на завършеността: Преценяват кога е събрана достатъчно информация за окончателен отговор.
Рамки като Pydantic-AI или Agents SDK на OpenAI правят оркестрацията лесна и бърза за внедряване. Затова този подход е чудесен за демонстрации или доказване на концепция.
Недостатъците на този подход са следните:
Няма гаранция, че стъпките за планиране на големи езикови модели и последващите действия ще бъдат правилни или подходящи. Системата с маршрутизатор има същия проблем, но тъй като е по-ограничена, поведението ѝ е по-предвидимо.
За прости и добре дефинирани задачи едва ли са ни необходими всички възможности на многоагентна система. Например в примера ни с Агент за авиокомпания вероятно има само ограничен брой видове заявки, които човек би отправил към система за обслужване на клиенти на авиокомпания.
Тъй като в големи езикови модели се съдържа повече логика, злонамерени лица могат много по-лесно да извършат джейлбрейк или друга злоупотреба.
Подходът скрива вземането на решения в големи езикови модели и така затруднява разбирането на системата, макар инструменти за наблюдение като Langfuse или Braintrust да могат отчасти да помогнат.
Бележка към читателя: въпреки че възможностите на моделите се променят бързо, изложеното по-долу едва ли ще се промени в близко бъдеще.
Определете обхвата на проблема си.
Можете ли лесно да представите желаната логика за вземане на решения в диаграма?
Недопустими ли са за приложението ви неуспехите или неочакваното поведение?
Отговор „да“ на който и да е от тези въпроси подсказва, че функциите с маршрутизатор са по-подходящи.
Където е възможно, препоръчваме да използвате подходи с маршрутизатор, докато са достатъчни. Общият принцип е: ако дадена част от системата може да се изрази в код, изразете я в код — не използвайте прекомерно големи езикови модели, когато не са необходими.
Когато тези подходи достигнат границите си, някои от предимствата на отворените оркестратори могат да бъдат възпроизведени по контролиран начин. Например:
Избор на инструмент/предаване към Агент: Реализира се лесно чрез условни разклонения или класификатори с големи езикови модели.
Определяне на завършеността: Прости класификатори с големи езикови модели могат да проверят дали отговорът е пълен, преди да го върнат на потребителя.
„Планирането“ и „итеративното комбиниране на резултати“ обаче несъмнено се постигат много по-трудно в строга система с маршрутизатор. Затова, когато дадена задача ги изисква — според класификатор с големи езикови модели или друга логика — предлагаме да създадете по-слабо ограничен клон с оркестратор в системата си.
Изборът между архитектура с маршрутизатор и такава с оркестратор трябва да отразява яснотата и сложността на приложението ви, както и стила на взаимодействие. Понастоящем подходите с маршрутизатор предлагат надеждност, ефективност и лесно тестване при ясно дефинирани задачи. Оркестраторите предлагат по-голяма гъвкавост за по-широки разговорни взаимодействия.
С развитието на големи езикови модели балансът между тези подходи може да се промени. За производствени натоварвания предпочитаме архитектури с маршрутизатор или хибридни архитектури, а оркестраторите запазваме за отворени проблеми, изискващи динамично взаимодействие, наподобяващо човешкото.