Pięciu agentów, jeden orkiestrator, 70% mniej rutynowej pracy

W wersji demo agent AI szybko sprawia wrażenie pewnego siebie. Dostaje zadanie, sięga po informacje, wykonuje akcje i dostarcza dokładnie taki wynik, jaki chcesz zobaczyć. Proof of concept może też przekonująco pokazać, że pomysł działa technicznie. Czy powstanie z tego niezawodne narzędzie do codziennej pracy w firmie, pozostaje otwartą kwestią.

Tam model zderza się z procesami, które kształtowały się latami, z logiką uprawnień, systemami legacy, wymogami compliance i niezliczonymi nieudokumentowanymi wyjątkami, które mimo to obowiązują każdego dnia. To tarcie decyduje, czy agent zacznie realnie pracować, czy po pilotażu trafi do szuflady.

Zanim więc padnie pytanie, jakiego agenta wdrożyć, trzeba odpowiedzieć na trudniejsze: jaką konkretnie pracę ma przejąć system AI, na jakich warunkach, w oparciu o jaką wiedzę i z jaką odpowiedzialnością? Dla nas „agent AI” to kategoria nadrzędna. W zależności od procesu powstaje z tego pojedynczy agent, system wieloagentowy albo połączenie AI, klasycznego oprogramowania i akceptacji przez ludzi. Architektura wynika z procesu.

Dlaczego LLM to jeszcze nie agent gotowy do pracy w firmie

Częsty błąd w inicjatywach AI to odruch, by dodać model językowy do istniejącej aplikacji i nazwać wynik agentem. Dokument trafia do LLM, model zwraca streszczenie, może jeszcze z warstwą RAG i kilkoma wywołaniami API. Na potrzeby proof of concept to często wystarcza. System firmowy musi jednak każdego dnia niezawodnie radzić sobie z rzeczywistością: z różnorodnymi danymi wejściowymi, zmieniającymi się zakresami odpowiedzialności, wyjątkami i zależnościami od innych systemów.

Agent działający na produkcji musi więc rozpoznać, które informacje są istotne, jaki krok jest następny, który komponent za niego odpowiada, z jakich danych wolno mu korzystać i kiedy sprawę przejmuje człowiek. Do tego dochodzą pytania, które w demo rzadko wychodzą na jaw:

• Jak utrzymać stan sprawy przez kilka kolejnych kroków?
• Co się dzieje, gdy system jest niedostępny albo agent nie potrafi niezawodnie wykonać zadania?
• Jak egzekwowane są uprawnienia?
• Jak prześledzić, dlaczego system podjął określoną decyzję?

LLM jest tylko jednym z kilku komponentów. Prostą nakładkę na GPT od architektury agentów zbudowanej na miarę odróżnia logika systemu wokół modelu: orkiestracja, zakresy odpowiedzialności, mechanizmy kontroli i przekazywanie spraw innym systemom lub ludziom. Agent dla firmy musi przede wszystkim działać niezawodnie, w sposób identyfikowalny i kontrolowany. To inne zadanie projektowe niż optymalizacja odpowiedzi modelu.

Analiza procesu przed prompt engineeringiem

Dlatego zaczynamy od dokładnej analizy procesu. Co naprawdę dzieje się na co dzień? Kto zbiera jakie informacje, jakie systemy są otwierane i kto w którym momencie podejmuje decyzję? Co jest udokumentowane, a co istnieje tylko jako doświadczenie poszczególnych pracowników? I przede wszystkim: które części da się sensownie zautomatyzować systemem probabilistycznym, a które lepiej zostawić w logice deterministycznej?

Ten ostatni punkt bywa niedoceniany, bo nie każdy krok procesu potrzebuje LLM:

Z tego podziału wyłania się architektura. Dopiero gdy wiadomo, które narzędzie najlepiej wykona które zadanie, można zdecydować, gdzie potrzebny jest agent, gdzie wystarczy klasyczne oprogramowanie, a gdzie odpowiedzialność ponosi człowiek. Pytanie brzmi wtedy: jak odwzorować ten proces pracy jako system, w którym ludzie, oprogramowanie i AI sensownie ze sobą współpracują? Pojedynczy agent może korzystać z kilku narzędzi, a złożony proces może wymagać kilku wyspecjalizowanych agentów. Ważne, żeby architektura niezawodnie odwzorowywała proces, a zakresy odpowiedzialności były jasne. Jak podchodzimy do takiej analizy, opisujemy na stronie Jak pracujemy.

Prawdziwy przykład: pięciu agentów w jednym procesie biznesowym

RPP Group działa na styku polityk publicznych, polityki i komunikacji. Dostęp do wydajnego LLM nigdy nie był problemem. Prawdziwy problem polegał na tym, że wysoko wykwalifikowani analitycy poświęcali dużo czasu na przewidywalną, powtarzalną pracę: analizę obszernych dokumentów, porządkowanie informacji o politykach publicznych i przygotowywanie materiałów komunikacyjnych. Te zadania wymagają znajomości dziedziny, a mimo to przebiegają według powtarzalnych wzorców, dlatego dobrze nadawały się do systematycznej automatyzacji.

Dokumenty z zakresu polityk publicznych liczą często sto stron i więcej. Treść trzeba wyodrębnić, uporządkować, porównać z innymi źródłami i osadzić w kontekście, który da się zakomunikować. Do tego dochodził twardy warunek, który wyklucza wiele standardowych rozwiązań: poufnych dokumentów politycznych nie wolno przetwarzać w pierwszej lepszej chmurze zewnętrznej.

Pojedynczy chatbot pokryłby tylko część tych zadań. Razem z Policy-Insider.AI zbudowaliśmy ChatRPP, system wieloagentowy z pięcioma wyspecjalizowanymi agentami i orkiestratorem, działający w istniejącej infrastrukturze RPP Group. Liczba pięć wynikła z podziału pracy. Orkiestrator kieruje każde zapytanie do właściwego specjalisty, czyli agenta od analizy dokumentów, przygotowywania tekstów, planowania strategicznego albo researchu politycznego, i zapewnia mu potrzebny kontekst oraz narzędzia. Osobni agenci QA sprawdzają wyniki pod kątem wewnętrznych standardów.

Dlaczego specjalizacja ma znaczenie w systemach wieloagentowych

Im bardziej złożony proces, tym staranniej trzeba sprawdzić, czy jeden uniwersalny agent to właściwa architektura. System, który analizuje dokumenty, przeszukuje internet, interpretuje dane wewnętrzne, przygotowuje treści, przestrzega zasad compliance i sprawdza wyniki, technicznie da się zbudować w postaci jednego agenta. Gdy jednak zadania wymagają różnych kontekstów, narzędzi, uprawnień lub mechanizmów kontroli, podział między wyspecjalizowanych agentów jest często lepszym wyborem. System wieloagentowy to jedna z kilku możliwych decyzji architektonicznych.

Wyspecjalizowani agenci wyraźnie rozdzielają zadania i zakresy odpowiedzialności. Orkiestrator koordynuje, specjaliści wykonują jasno zdefiniowane kroki, źródła danych są podłączone w kontrolowany sposób, a wyniki pośrednie można po drodze sprawdzać, uzupełniać lub odrzucać. Jakość mierzy się wtedy nie tyle wynikiem benchmarku pojedynczego LLM, ile tym, jak solidnie cały łańcuch, czyli routing, wyszukiwanie, przetwarzanie, generowanie i kontrola, sprawdza się w codziennej pracy na produkcji.

W ChatRPP połączyliśmy orkiestrację wielu agentów, kilka modeli LLM, RAG, przetwarzanie dokumentów i klasyczną logikę w Pythonie, zintegrowaliśmy specjalistyczną usługę Policy-Insider.AI i uruchomiliśmy całość w infrastrukturze zgodnej z RODO. Na produkcji działa architektura AI zbudowana na miarę, w której wyspecjalizowani agenci współpracują z klasycznym oprogramowaniem, źródłami danych i mechanizmami governance. Wzorce architektury, protokoły i governance szerzej omawiamy w artykule o systemach wieloagentowych.

Kwestia danych należy do architektury

W prezentacjach integracja często wygląda na wygodny dodatek: agent łączy się ze Slackiem, CRM, kalendarzem i repozytorium dokumentów. W firmie dostęp to niemal zawsze kwestia governance. Co agent może czytać? Jakie informacje wolno mu łączyć ponad granicami systemów? Co może zmienić sam, a co przedstawia człowiekowi do akceptacji? I jak rejestrować, kto co i kiedy uruchomił, żeby wynik dało się prześledzić jeszcze po kilku tygodniach?

Te pytania trzeba uwzględnić w projekcie od początku. Agenci działają w ramach zdefiniowanych uprawnień, zatrzymują się przy wrażliwych akcjach, czekają na akceptację, a w razie wątpliwości robią raczej za mało niż za dużo. Ogólny model governance rzadko wystarcza: agent przygotowujący wpis na bloga potrzebuje innej logiki akceptacji niż agent, który pracuje z poufnymi danymi finansowymi albo zmienia rekordy w systemie produkcyjnym. Architektura szyta na miarę oznacza więc także governance szyte na miarę.

Integracja z systemami legacy to prawdziwy test architektury

Prezentacje działają najlepiej tam, gdzie każdy system ma czyste API. W firmie dane leżą w wielu aplikacjach: jedne są nowoczesne i udokumentowane, inne rozwijały się przez dziesięć czy piętnaście lat i rozumie je tylko garstka osób w firmie. Modele uprawnień rzadko do siebie pasują, a spora część pracy w procesach wciąż odbywa się przez e-maile, załączniki w Excelu i ręczne przekazywanie spraw. Na tych stykach widać, czy agent naprawdę przejmuje pracę.

Rozwiązanie szyte na miarę musi więc rozstrzygnąć znacznie więcej niż samą odpowiedź modelu:

• Który system jest źródłem nadrzędnym dla których informacji?
• Kiedy informacje trzeba pobierać na bieżąco, a kiedy można je przechowywać w pamięci podręcznej?
• Jak utrzymać stan procesu składającego się z wielu kroków?
• Co się dzieje przy sprzecznych danych albo nieudanym wywołaniu narzędzia i które kroki można wycofać?
• Gdzie włącza się człowiek i które działania muszą podlegać audytowi?

To klasyczne pytania architektoniczne. Nowe jest to, że pojawiają się teraz w systemach probabilistycznych, których zachowania nie da się już w pełni opisać tablicą prawdy. W inżynierii AI nie wystarczy więc połączyć interfejsów. Trzeba też określić, jak system radzi sobie z niepewnością, błędami i decyzjami. Jak takie połączenie wygląda w praktyce, pokazuje nasz artykuł o integracji AI z SAP, Microsoft 365 i Jira.

Wartość biznesowa to odzyskany czas zespołu

W RPP Group celem nigdy nie było błyszczenie szczególnie efektownymi odpowiedziami. Chodziło o to, by odciążyć doświadczonych analityków od pracy, która zabiera czas, a nie wymaga ich wiedzy eksperckiej. Według case study czas poświęcany na rutynowe zadania wykonywane ręcznie spadł o około 70%, a wyniki trafiają bezpośrednio do codziennej pracy analityków.

To inny wskaźnik niż benchmarki LLM, które chętnie cytuje prasa branżowa. Czy model zdobywa w MMLU dwa punkty więcej, czy mniej, to dla CTO sprawa drugorzędna. Robi się ciekawie, gdy prawdziwy proces biznesowy zmienia się strukturalnie. Mniej rutyny oznacza odzyskany czas zespołu, który RPP Group przeznacza teraz na pracę strategiczną i kontakt z klientami.

Na miarę znaczy: właściwy poziom abstrakcji

„AI szyte na miarę” bywa rozumiane jako trenowanie osobnego modelu bazowego dla każdej firmy. W naszym podejściu chodzi o coś innego: o swobodę wyboru właściwego poziomu abstrakcji dla każdego problemu. Model bazowy może pochodzić od zewnętrznego dostawcy, RAG jest często pragmatycznym wyborem, istniejące API pozostają w użyciu, a gotowe komponenty do przetwarzania dokumentów czy orkiestracji stosujemy wtedy, gdy pasują. Rozwiązanie staje się szyte na miarę tam, gdzie te elementy składają się w system odwzorowujący dokładnie te procesy, które w firmie mają znaczenie.

Praca inżynierska obejmuje więc projektowanie procesów, architekturę systemu, orkiestrację, dostęp do danych, zarządzanie stanem, governance, integrację z krajobrazem IT i, co najczęściej się niedocenia, ewaluację. Dlatego analiza procesu jest osobnym etapem. Decyduje o tym, co warto zbudować, a w wielu przypadkach także o tym, czego budować się nie opłaca.

Od funkcji do infrastruktury

Gdy firmy osadzają dedykowane systemy AI w prawdziwych procesach, między ludźmi a oprogramowaniem firmowym powstaje nowa warstwa. ERP, CRM, DMS, narzędzia do współpracy i bazy danych działają dalej, a nad nimi warstwa procesowa przenosi informacje między tymi systemami i koordynuje zadania w wielu aplikacjach.

Standardowi agenci dobrze sprawdzają się w wielu typowych zadaniach. Gdy spotykają się wiedza specyficzna dla firmy, własne procesy, wrażliwe dane i rozbudowany przez lata krajobraz systemów, dźwignią staje się rozwiązanie zaprojektowane na miarę. Nie każdy proces potrzebuje do tego pięciu agentów, a niektóre nie potrzebują żadnego:

• Część kroków pozostaje deterministyczna, bo system probabilistyczny nic tam nie wnosi.
• Inne zyskują na pojedynczym, jasno ograniczonym kroku AI w aplikacji, która poza tym pozostaje klasyczna.
• Jeszcze inne procesy osiągają swój potencjał dopiero wtedy, gdy kilku wyspecjalizowanych agentów współpracuje pod kontrolą orkiestratora.

Kluczowa umiejętność to rzetelna ocena, która z tych architektur przyniesie firmie najwięcej w przypadku danego procesu. Dokładnie tak zaczyna się każda współpraca z theBlue.ai: od analizy tego, jak naprawdę przebiega praca, jakie decyzje są podejmowane, jakie systemy biorą w niej udział i gdzie wiedza ekspercka ludzi pozostaje niezastąpiona. Więcej na stronie Systemy wieloagentowe.

Najczęściej zadawane pytania