Важно е внимателно да разгледате како и каде се носат одлуките во вашиот агентски систем.
Препуштањето повеќе одлуки на големи јазични модели (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) продолжуваат да напредуваат, рамнотежата меѓу овие пристапи може да се менува. За продукциски оптоварувања претпочитаме архитектури засновани на рутер или хибридни архитектури, а оркестраторите ги оставаме за отворени проблеми што бараат динамична интеракција слична на човечката.