Należy starannie rozważyć, jak i gdzie podejmowane są decyzje w systemie agentowym.
Przekazanie większej liczby decyzji do LLM może pozwolić systemowi obsługiwać więcej zadań, ale potencjalnie kosztem szybkości, niezawodności i odporności.
W miarę możliwości przenoś jak największą część procesu decyzyjnego z LLM do jawnego kodu oprogramowania. Dotyczy to zwłaszcza procesów produkcyjnych lub obarczonych wysokim ryzykiem.
Podczas projektowania systemu agentowego opartego na LLM jedną z najważniejszych decyzji jest określenie, jaka część procesu decyzyjnego ma być realizowana przez model LLM, a jaka przez jawnie zdefiniowane oprogramowanie.
Aby lepiej to zrozumieć, potraktujmy ten wybór jako spektrum między następującymi podejściami:
Architektury oparte na routerze definiują kolejność i logikę bezpośrednio w kodzie, zapewniając testowalność, przewidywalność i odporność w zadaniach z wąskiej dziedziny (nazywa się je również „agentami przepływu pracy”).
Agenty-orkiestratory wykorzystują duże modele językowe (LLM) do dynamicznego ustalania przebiegu zadań na podstawie poleceń w języku naturalnym. Sprawdzają się w otwartych interakcjach, w których wcześniej zdefiniowana logika jest niewystarczająca lub niemożliwa do zastosowania.
W produkcyjnych procesach wysokiego ryzyka zwykle zalecamy szersze wykorzystanie mechanizmów routera, a orkiestratory pozostawiamy do zastosowań wymagających elastycznych rozmów o ogólnym przeznaczeniu.
Architektury oparte na routerze
Systemy agentowe oparte na routerze:
Jawnie definiują przebieg procesu decyzyjnego w kodzie lub oprogramowaniu, a LLM służy do wyboru ścieżki, którą ma podążyć program.
Są bliższe tradycyjnym systemom informatycznym, ponieważ mają jasno określone i przewidywalne ścieżki, co przekłada się na bardziej spójne wyniki.
Idealnie nadają się do ściśle zdefiniowanych zadań.
Poniżej przedstawiono uproszczony przykład agenta do rezerwacji lotów, który wykorzystuje „podejście oparte na routerze”. LLM pomaga sklasyfikować intencję pytania jako jedną z trzech możliwości, lecz to oprogramowanie ostatecznie przypisuje ją do szablonu odpowiedzi tekstowej. Ponieważ działanie LLM jest ściśle ograniczone, użytkownik otrzymuje bardziej spójne odpowiedzi.
Architektury orkiestratorów
W przeciwieństwie do systemów opartych na routerze systemy agentowe z orkiestratorem:
Definiują przepływy logiczne za pomocą poleceń w języku naturalnym zamiast w oprogramowaniu. Uwaga: w porównaniu z językiem programowania język naturalny jest z natury niejednoznaczny i elastyczny — ma to zarówno zalety, jak i wady, które omówimy później. Określamy to jako „intencję zamiast instrukcji”.
Mogą udostępniać wiele sposobów przetwarzania, a LLM ustala kolejność i metodę ich wykonania.
Mogą dynamicznie tworzyć nowe ścieżki logiczne, które trudno jawnie zdefiniować w oprogramowaniu.
Ta niejednoznaczność może prowadzić do niespójnych wyników, lecz gdy wszystko działa, efekt bywa wręcz „magiczny”.
Poniższy przykład pokazuje zastosowanie orkiestratora do tego samego uproszczonego problemu związanego z linią lotniczą. Zamiast pozostawiać wybór właściwej odpowiedzi oprogramowaniu, proces decyzyjny przekazuje się warstwie LLM. Mamy tu system wieloagentowy, w którym „główny” agent-orkiestrator wstępnie analizuje zapytanie użytkownika i przekazuje je agentowi zaprojektowanemu specjalnie do zmiany lotów, który ostatecznie udziela odpowiedzi.
W tym przykładzie warstwa LLM pełni funkcję klasyfikatora, routera i autora odpowiedzi. W przykładzie z routerem pełniła jedynie funkcję klasyfikatora, a resztę obsługiwało oprogramowanie.
W miarę możliwości zalecamy stosowanie architektur opartych na routerze ze względu na następujące zalety:
Szybkość i wydajność: obliczenia lokalne są szybsze niż działanie orkiestratorów zależnych od zewnętrznych interfejsów API. Przetwarzanie logiki „IF/ELSE” w Pythonie jest również znacznie tańsze niż płacenie dostawcy LLM za przepuszczenie jej przez model z 400 miliardami parametrów.
Testowalność i przewidywalność: debugowanie, testowanie i utrzymanie są znacznie łatwiejsze dzięki sprawdzonym praktykom programistycznym.
Przejrzystość i niezawodność: mniejsza zmienność zachowania ułatwia rozwiązywanie problemów. Większa część przepływu aplikacji jest ponadto zapisana w przejrzystym oprogramowaniu objętym kontrolą wersji, a nie w nieprzejrzystych i trudnych do interpretacji wagach LLM.
Wadą podejść opartych na routerze jest ich sztywność i ograniczona elastyczność, przez co gorzej radzą sobie z bardziej otwartymi problemami. Chatbot, który zawsze udziela dokładnie tych samych odpowiedzi, może być postrzegany przez użytkowników jako nudny lub niezmienny.
Architektury orkiestratorów oferują zaawansowane możliwości:
Planowanie: mogą dynamicznie planować odpowiedzi.
Wybór narzędzi i przekazywanie zadań agentom: wybierają odpowiednie narzędzia lub delegują zadania agentom.
Iteracyjne łączenie wyników: wielokrotnie przetwarzają i kreatywnie łączą wyniki.
Ustalanie zakończenia: określają, kiedy zebrano wystarczająco dużo informacji, aby sfinalizować odpowiedź.
Platformy takie jak Pydantic-AI czy Agents SDK firmy OpenAI pozwalają szybko i łatwo wdrożyć orkiestrację. Dlatego rozwiązanie to świetnie nadaje się do demonstracji i tworzenia weryfikacji koncepcji.
Podejście to ma jednak następujące wady:
Nie ma gwarancji, że etapy planowania wykonywane przez LLM i wynikające z nich działania będą poprawne lub odpowiednie. System oparty na routerze ma ten sam problem, ale ze względu na większe ograniczenia jego zachowanie jest bardziej przewidywalne.
W przypadku prostych, dobrze zdefiniowanych zadań pełne możliwości systemu wieloagentowego prawdopodobnie nie są potrzebne. Na przykład w naszym agencie linii lotniczej istnieje zapewne tylko ograniczona liczba typów zapytań, które użytkownik rzeczywiście chce kierować do systemu obsługi klienta.
Ponieważ LLM zawiera więcej logiki, jest znacznie bardziej podatny na obchodzenie zabezpieczeń i inne nadużycia ze strony atakujących.
Przeniesienie procesu decyzyjnego do LLM utrudnia zrozumienie systemu, choć narzędzia monitorujące, takie jak Langfuse czy Braintrust, mogą częściowo w tym pomóc.
Uwaga dla czytelnika: choć możliwości modeli szybko się zmieniają, poniższe zalecenia prawdopodobnie pozostaną aktualne w najbliższej przyszłości.
Określ zakres problemu.
Czy możesz łatwo przedstawić oczekiwaną logikę decyzyjną na diagramie?
Czy awarie lub nieoczekiwane zachowanie aplikacji są dla Ciebie nieakceptowalne?
Odpowiedź „tak” na którekolwiek z powyższych pytań przemawia za zastosowaniem mechanizmów routera.
W miarę możliwości zalecamy korzystanie z routera tak długo, jak jest to wystarczające. Ogólna zasada brzmi: jeśli część systemu można zapisać w kodzie, należy to zrobić — nie warto nadużywać LLM, gdy nie są potrzebne.
Po osiągnięciu granic tego podejścia niektóre zalety otwartego działania orkiestratorów można odtworzyć w kontrolowany sposób. Na przykład:
Wybór narzędzi i przekazywanie zadań agentom: można łatwo wdrożyć za pomocą rozgałęzień warunkowych lub klasyfikatorów LLM.
Ustalanie zakończenia: proste klasyfikatory LLM mogą sprawdzić kompletność odpowiedzi przed przekazaniem jej użytkownikowi.
„Planowanie” i „iteracyjne łączenie wyników” jest jednak niewątpliwie znacznie trudniejsze do osiągnięcia w sztywnym systemie opartym na routerze. Gdy zadanie wymaga tych funkcji — zgodnie z oceną klasyfikatora LLM lub innej logiki — sugerujemy utworzenie w systemie mniej ograniczonej gałęzi orkiestratora.
Wybór między architekturą routera a orkiestratora powinien zależeć od tego, jak jasno zdefiniowana i złożona jest aplikacja oraz jaki styl interakcji oferuje. Podejścia oparte na routerze zapewniają obecnie niezawodność, wydajność i łatwość testowania jasno zdefiniowanych zadań. Orkiestratory oferują większą elastyczność w szerszych interakcjach konwersacyjnych.
Wraz z rozwojem LLM proporcje między tymi podejściami mogą się zmieniać. W przypadku obciążeń produkcyjnych skłaniamy się ku architekturom opartym na routerze lub rozwiązaniom hybrydowym, a orkiestratory pozostawiamy do otwartych problemów wymagających dynamicznej interakcji przypominającej kontakt z człowiekiem.