Fabryka agentów AI: jak zacząć i dojść do produkcji

W większości przypadków Azure spełnia wymagania regulacyjne polskich firm.

W AI Sandboxie developer nie doprowadzi do wycieku, o jakim piszą portale IT: dane wyciekły, bo ktoś udostępnił coś w chmurze.

Zapewnienia, że okno kontekstowe jest nie wiadomo jak duże, bywają marketingiem: w praktyce przy automatyzacji kontekst się minimalizuje.

Łukasz Kałużny: Dzięki możliwościom platform chmurowych narzucamy standardy tak, że developer nie doprowadzi do tego, o czym czytamy na portalach IT: że wyciekły dane, bo coś zostało w chmurze udostępnione. Wymuszamy taką konfigurację, że developer czy data scientist w żaden sposób nie kliknie przycisku „wystaw to do internetu”. Kiedy patrzymy, co klienci próbują zrobić samodzielnie, to jest właśnie rzucenie się na to, że zrobimy superagenta i podepniemy wszystko. A sercem, wbrew pozorom, nie jest agent, tylko sposób dostarczenia do niego wiedzy i możliwości wykonywania akcji przez integrację z innymi systemami.

Mikołaj Szczerbicki: Cześć! Witamy w Powered by Protopia. Jestem Mikołaj Szczerbicki i dzisiaj porozmawiamy o agentach AI. Dołączył do mnie Łukasz Kałużny.

Łukasz Kałużny: Cześć wszystkim!

Mikołaj Szczerbicki: Łukasz, znam sporą grupę managerów, którzy już dziś stoją przed wyzwaniem wdrożenia fabryki agentów w swojej organizacji. Zanim do tego przejdziemy, powiedz mi, czym jest agent AI? Albo, co moim zdaniem równie ważne, czym agent nie jest?

Łukasz Kałużny: Zacznijmy od tego, że wokół agentów jest duży hype i krąży wiele definicji, aż po taką, że agent to samodzielny, żyjący byt. Najprościej porównać go do chatbotów. Przyzwyczailiśmy się, że większość rozwiązań AI w organizacjach to albo chatbot, z którym rozmawiamy i który nam pomaga, albo model językowy wpięty w jakiś proces, na przykład w aplikacji.

Odczarowując temat: agent to nadal dokładnie to samo, podane w trochę innej formie. Pozwalamy procesowi, który wykorzystuje LLM-a, czyli duży model językowy, pracować dłużej na danych i samodzielnie podejmować decyzje w granicach, które mu damy. Przykładowe zadanie: pobierz dane z kilku naszych systemów, na przykład z CRM-a, ERP-a, helpdesku czy innego systemu dziedzinowego, połącz je i pokaż mi wszystko, co wiemy o kliencie.

Mikołaj Szczerbicki: Właśnie, Łukasz, wydaje mi się ważne, żebyśmy teraz powiedzieli, co taki agent AI może robić w naszej organizacji.

Łukasz Kałużny: Najlepiej pokazać to na przykładach od naszych klientów. Pierwszy to wszelkiego rodzaju przetwarzanie dokumentów, które ciągle się pojawia, tylko teraz w bardziej inteligentny sposób. Wpływa na przykład dokument, reklamacja, bo to najczęstszy przypadek, i zbieramy informacje o kliencie. Trzeba powiedzieć, że agent dostaje już zOCR-owany dokument.

Mail wpada na skrzynkę albo pracownik wrzuca dokument do systemu. Agent dostaje zOCR-owany dokument, wyciąga z niego informacje, na przykład PESEL, numer klienta czy inne dane identyfikacyjne, i zbiera informacje z różnych systemów w organizacji, żeby wspomóc pracownika. Ciekawy przykład od jednego z klientów: klient zareklamował rachunek, a agent sprawdził, że źle naliczono rabat. Wspiera handlowca, potwierdzając, że rabat faktycznie był źle naliczony, i przygotowuje szkic maila, który wyjaśnia sytuację.

Łukasz Kałużny: To jedna rzecz. Druga to generowanie raportów z danych z różnych systemów: chcę wyszukać X rzeczy w różnych systemach i je zebrać. Ten przypadek pojawił się już kilka razy u klientów: chcemy poznać informacje o kliencie w scalonej formie, żeby nie przeskakiwać między systemami, albo znaleźć niespójności.

Innym ciekawym przypadkiem są procesy, dla których trudno z góry ustalić przebieg, bo zależy on od tego, co się dzieje. Dajemy agentowi możliwość zebrania danych albo wykonania akcji w naszych systemach, zależnie od sytuacji. Pozwalamy mu zachować się trochę — nie lubię tego określenia — jak człowiek: na podstawie informacji, które wpłyną, dokonuje zmiany. Brakuje czegoś w tym miejscu, więc uzupełniam dane tam, tam i tam.

Mikołaj Szczerbicki: Dobrze, ale skoro mówimy o wykorzystaniu agentów AI w organizacji: lepiej mieć kilku mniejszych czy jednego superagenta z supermocą?

Łukasz Kałużny: Kiedy patrzymy, co klienci próbują zrobić samodzielnie, pierwszym odruchem jest rzucenie się na to, że zrobimy superagenta i podepniemy wszystko. Z drugiej strony pojawia się trend, jak kiedyś w mikroserwisach: zróbmy bardzo dużo małych agentów. Trzeba znaleźć między tym odpowiedni balans.

Przejdźmy do tego, jak technicznie zbudowany jest agent. Mamy runtime framework, czyli coś, co uruchamia agenta. To gotowa usługa chmurowa albo kawałek kodu w Pythonie czy innym języku z gotowym frameworkiem, który integruje się z LLM-em, na przykład z OpenAI. Pod spodem agent jest niczym innym jak pętlą, która wywołuje się na podstawie danych wejściowych.

LLM-y mają coś, co nazywamy oknem kontekstowym: ile tekstu możemy przekazać. Technicznie są to tokeny, czyli tekst podzielony i zamieniony na numery odpowiadające literom albo zlepkom liter. To wejście jest ograniczone.

Czym jest integracja, na przykład podpięcie systemu? To powiedzenie LLM-owi w języku naturalnym, że dane wywołanie pozwala pobrać dane o kliencie po numerze PESEL albo po ID klienta. Opisujemy to tak, jakbyśmy opisywali człowiekowi, tylko w formie zoptymalizowanej pod LLM-a: co robi dana metoda, jakie dane pobierze albo zapisze i co trzeba jej przekazać.

Mikołaj Szczerbicki: Czyli w zależności od tego, do czego chcemy agenta wykorzystać, jakie zadania ma wykonywać i czego od niego oczekujemy, powinniśmy tworzyć mniejszych, bardziej wyspecjalizowanych agentów.

Łukasz Kałużny: Tak, bo długość kontekstu jest ograniczona. Możemy trafić na marketingowy bełkot, że kontekst jest nie wiadomo jak duży i zmieści się w nim ileś książek. W praktyce przy automatyzacji okazuje się, że to kosztowne, a agent nie trzyma się instrukcji. Dlatego próbujemy kontekst minimalizować.

Mikołaj Szczerbicki: Właśnie o to chciałem zapytać: czy ogranicza nas tylko worek pieniędzy, czy także technologia?

Łukasz Kałużny: Aktualnie oprócz worka pieniędzy nadal technologia. Dobrze to widać w komunikatach firmy Anthropic, która mówi, że jej celem na najbliższe miesiące i lata jest to, żeby model językowy napędzający agentów trzymał się dokładnie przekazanych instrukcji i kolejności wykonywania. W praktyce to jest właśnie ta niedeterministyczna rzecz: agent nie zawsze trzyma się instrukcji. Stąd minimalizujemy.

To, co nazwałeś superagentem, technicznie opisujemy jako scenariusz connected agents. Mamy agenta orkiestratora, centralnego agenta do dedykowanego procesu biznesowego, który ma podpiętych małych agentów wykonujących akcje na poszczególnych systemach. O agencie orkiestrującym możemy myśleć jak o dyrygencie w orkiestrze albo team leaderze, który rozdziela pracę, a potem łączy ją w całość.

Jedna kluczowa rzecz musi tu wybrzmieć: kawałek LLM-a czy kod runtime są uniwersalne. Problemem jest podłączenie się do naszych systemów i integracja z nimi. Myśląc o fabryce agentów, musimy w firmie ujednolicić sposób integracji z systemami. Kiedy w Protopii pracujemy z klientami, rekomendujemy Azure API Management, czyli centralną bramkę integracyjną, która w jednolity sposób udostępnia agentom różne systemy.

Mikołaj Szczerbicki: Dobrze rozumiem, że gdybyśmy tego nie zrobili, funkcjonalność agentów byłaby mocno ograniczona?

Łukasz Kałużny: Jeżeli piszemy kod agenta samodzielnie i nie korzystamy z gotowej platformy, możemy spróbować zrobić integrację sami. Przy większej skali pojawia się problem: przydałoby się zmodyfikować systemy źródłowe, żeby były kompatybilne z podłączeniem. A jako większa organizacja chcemy jak najtaniej reużywać: jeśli zbudowaliśmy jedną integrację, chcemy jej użyć także w innych miejscach.

Da się to zrobić bez bramki, ale z naszego doświadczenia to proces droższy i wolniejszy. Jeżeli podepniemy system pod bramkę, na przykład Azure API Management, będzie on potem dostępny dla wszystkich agentów, których zbudujemy. Raz podłączony system może być reużyty przez resztę.

Ciekawostka: to także miejsce na opisy, o których mówiłem. Na przykład: tu mamy system HR, tak znajdziesz dane o pracowniku, a tu jego urlopy. Dokumentujemy to centralnie i to ma wartość dla innych, którzy próbują budować i testować agentów.

Mikołaj Szczerbicki: Czyli wprowadza to pewien porządek w organizacji.

Łukasz Kałużny: Tak. I sprawia, że utrzymanie jest potem tańsze.

Mikołaj Szczerbicki: To też bardzo istotne. Krążymy wokół tematu fabryki agentów, więc powiedz: czym ona faktycznie jest?

Łukasz Kałużny: Możemy podejść do tematu w małej skali, czyli po prostu coś testujemy. Data scientist albo programista pisze agenta w Pythonie, korzystając na przykład z frameworków od Microsoftu, OpenAI czy Google'a. To fajne, bo zaczynamy robić jakiś PoC i widzimy pierwsze agenty. Ale klienci, z którymi pracujemy, często z branży finansowej, branż regulowanych albo większych organizacji, chcą to uporządkować.

Fabryka agentów zakłada, że budujemy platformę, która pozwala szybko przejść od testów dalej. Bardzo ważne: testy zwykle chcemy robić na danych jak najbardziej zbliżonych do danych z prawdziwych systemów produkcyjnych, żeby wyłapać wartość. Następnym elementem fabryki są środowiska. Część, w której uruchamiamy agenty, wygląda jak w normalnym oprogramowaniu: środowiska nieprodukcyjne i produkcyjne.

Na fabrykę agentów możemy patrzeć jak na inny modny zwrot, platform engineering. Chodzi o to, żeby łatwo przejść od testu, proof of concept czy proof of value agenta do, jeśli wszystko będzie w porządku, uruchomienia go produkcyjnie i oddania do użycia.

Mikołaj Szczerbicki: Wkraczamy na grząski grunt, czyli dane i ich bezpieczeństwo. Wspomniałeś o klientach z branż regulowanych, a tam bezpieczeństwo danych to jedna z kluczowych rzeczy. Jak to się ma do fabryki agentów i skąd możemy mieć pewność, że nasze dane są bezpieczne?

Łukasz Kałużny: Odłożę na bok wątek regulacyjny. Azure w polskich firmach w większości przypadków spełnia całą część regulacyjną. Budując fabrykę agentów, przychodzimy do klientów z konceptem, który nazywamy AI Sandboxem. Założenie jest takie, że budujemy przestrzeń, na przykład w Azure, odpowiednio przygotowaną i traktowaną jako miejsce do eksperymentów.

Przez przygotowanie rozumiem wszystkie zabezpieczenia i całą konfigurację platformy: nadawanie dostępów, kontrolę ruchu sieciowego wchodzącego i wychodzącego. Budujemy bezpieczną przestrzeń, enklawę, w której możemy uruchamiać eksperymenty.

Mikołaj Szczerbicki: Rozumiem, że już na etapie projektowania platformy ustalamy standardy dla organizacji, które potem wszyscy muszą respektować?

Łukasz Kałużny: Tak, podchodzimy nawet bardziej rygorystycznie. Dzięki możliwościom platform chmurowych narzucamy standardy tak, że developer nie doprowadzi do tego, o czym czytamy na portalach IT: że wyciekły dane, bo coś zostało w chmurze udostępnione. Wymuszamy taką konfigurację, że developer czy data scientist w żaden sposób nie kliknie przycisku „wystaw to do internetu”.

Budujemy zabezpieczoną przestrzeń, która ogranicza możliwość zmiany konfiguracji i zostawia pole na to, co ważne: przetestowanie agenta, rozwiązania generative AI. Nie na odkrywanie — to przykład od klienta — jak w jakiejś open source'owej bibliotece podłączyć się do usługi AI i jak bezpiecznie się zalogować. Sandbox ma więc dwa cele. Pierwszy to zabezpieczenie i możliwość eksperymentów. Drugi to wymuszenie skupienia na wartości biznesowej, a nie na zabawie technologicznej.

Mikołaj Szczerbicki: Wspomniałeś wcześniej o Azure AI Foundry. Jaką wartość daje skorzystanie z takiego rozwiązania w porównaniu z budową platformy samemu? Przypadki mogą być różne. Czy któraś opcja zawsze wygrywa, czy jak zwykle: to zależy?

Łukasz Kałużny: Zazwyczaj to zależy. Z naszej perspektywy, a na co dzień pracujemy z Azure, AI Foundry jest tak zwane good enough. Jest wystarczająco dobre, żeby go użyć. Godzimy się na pewne ograniczenia, ale za to po wdrożeniu platformy możemy z niego korzystać realnie od ręki. Jedna z zalet, które widzimy u klientów: ograniczamy ilość kodu i frameworków i skupiamy się na dwóch rzeczach. Pierwsza to zaprojektowanie agentów, druga to podłączenie systemów i źródeł danych oraz faktyczne testowanie. Szybkość użycia AI Foundry to bardzo dobra rzecz.

Każdy z hyperskalerów ma odpowiednik Azure AI Foundry. Jeżeli masz daną chmurę wdrożoną w organizacji, użyj gotowego rozwiązania platform as a service od tego dostawcy, bo to da największą wartość. Alternatywnie można próbować zbudować platformę na rozwiązaniach open source, ale prawdopodobnie zmarnujemy kilka miesięcy, żeby doprowadzić ją do pełnego działania, zamiast skupić się na wartości, dla której chcemy budować agentów. Mimo mojej miłości do kodu odchodzimy od niego na rzecz pisania promptów i podłączania systemów.

Ważne: z Azure AI Foundry realnie nie ma dużego vendor lock-inu. Jeśli ktoś będzie chciał się wycofać, nie jest zablokowany na Microsoft. Trzeba to podkreślić, bo sercem całości jest model językowy, a ten można wymienić. Następną wartością są instrukcje agenta, czyli napisane system prompty. Po zmianie modelu trzeba je sprawdzić i dopasować, bo każdy model ma swoje niuanse, ale to raczej szlifowanie. A integracje z API Management każdy framework, także open source'owy, będzie konsumował dokładnie tak samo. Strategia wyjścia z rozwiązania, której zresztą wymagają instrukcje podlegające pod KNF, jest, mógłbym powiedzieć, dosłownie copy-paste'owa plus testy.

Mikołaj Szczerbicki: Na początku wspomnieliśmy, że wielu managerów stoi przed wdrożeniem fabryki agentów. Rozmawiamy o etapie testowania, ale biznes to biznes: każdy chce widzieć realne efekty, a nie projekt ładnie pokazywany na prezentacjach. Jak z AI Sandboxa dobrze wejść na produkcję?

Łukasz Kałużny: Nasze podejście jest takie, że AI Sandbox to przestrzeń współdzielona. Tak na niego patrzymy i tak tłumaczymy to klientom: jak w Kubernetesie, gdzie są namespace'y, przestrzeń jest w jakiś sposób podzielona. Przenosimy te same znane praktyki developerskie, które dotyczą zwykłych aplikacji. Sandbox dostarcza konfigurację, którą zobaczymy też na produkcji.

Przy wdrożeniu platformy agentowej, takiej fabryki, przygotowujemy zestaw skryptów deploymentowych dla całego procesu. Agenty i rozwiązanie wypracowane w Sandboxie przenosimy na środowisko nieprodukcyjne, a po testach wdrażamy dosłownie na produkcję, jak kolejną aplikację na Kubernetesie. Tu nic się nie różni.

Warto podkreślić: obowiązują te same praktyki developerskie. Trzymamy agenta as code w repozytorium i wdrażamy go przez CI/CD. Nie ma tu magii ani specjalnego klikania. Znanymi narzędziami developerskimi układamy proces przenoszenia i traktujemy agenta po prostu jak aplikację.

Musi tu wybrzmieć, że dobre praktyki wytwarzania oprogramowania i zarządzania wdrożeniami obowiązują także w tym miejscu. Sandbox, od którego zaczynamy, zapewnia, że środowisko, na które przeniesiemy agenta z fazy testów i odkrywania do fazy faktycznego użycia, jest dokładnie takie samo. Pozbywamy się syndromu „a u mnie działało”, który często pojawia się w IT.

Mikołaj Szczerbicki: Łukasz, dostaliśmy od Ciebie solidną porcję informacji. Czy możemy na koniec zrobić krótkie podsumowanie?

Łukasz Kałużny: Pierwsza rzecz, która jeszcze nie wybrzmiała, to wybór przypadków do testowania agentów. Na początek wybierzmy proste. Kolejny krok to zdefiniowanie, co realnie wyślemy do agenta, na przykład informację, prośbę czy dokument, i co ma być wynikiem. Kiedy zdefiniujemy oczekiwania, następny krok to identyfikacja, co musimy dostarczyć, czyli jakie systemy zintegrować z agentem. Dopiero kiedy to wszystko wiemy, możemy przejść do realizacji. Bez tego naprawdę nie ma to sensu.

Mikołaj Szczerbicki: Sam z doświadczenia wiesz, że to zazwyczaj jest najtrudniejsze…

Łukasz Kałużny: Tak, i najdłuższe. To pierwsza rzecz. Druga, jeśli chodzi o samych agentów AI: nie zakopujmy się we frameworkach open source i pięknych diagramach, które widzimy na obrazkach na LinkedInie. Jeżeli mamy dostawcę chmurowego, wybierzmy usługę platform as a service z jego portfolio. Zazwyczaj będzie to najlepsze i najbardziej opłacalne rozwiązanie, szczególnie żeby pokazać wartość i faktycznie zacząć testować. Jeżeli nie mamy chmury, alternatywą może być gotowa platforma open source dla agentów, na przykład Dify. Model językowy zawsze trzeba będzie jednak jakoś dostarczyć.

Mikołaj Szczerbicki: Czyli zaczynajmy od rozwiązań, po które możemy sięgnąć.

Łukasz Kałużny: Tak, od gotowych platform. Następny element, który warto wyciągnąć z naszej rozmowy: nie można marzyć o superagentach. To dedykowane byty dla konkretnego przypadku biznesowego, procesu czy problemu. Zazwyczaj składają się z jednego nadzorującego agenta i wielu małych, które wykonują realne zadania. Są też inne scenariusze, ale nie polecam ich na początku, bo mogą być koszmarem do testowania i możemy być bardzo niezadowoleni z wyników.

Ostatnia rzecz to zbudowanie platformy z usług PaaS albo gotowych rozwiązań. Po pierwsze bezpieczna przestrzeń w postaci AI Sandboxa, gdzie skupiamy się na testowaniu. Po drugie proces przejścia na środowiska, na których agent będzie faktycznie uruchomiony. I od razu zachęta do kolejnego odcinka, który nagra Marek, o Azure API Management i podejściu do integracji. Bo sercem, wbrew pozorom, nie jest agent, tylko sposób dostarczenia do niego wiedzy i możliwości wykonywania akcji przez integrację z innymi systemami.

Mikołaj Szczerbicki: Super, Łukasz, bardzo Ci dziękuję za wiedzę z własnego doświadczenia, którą się z nami podzieliłeś. Dziękujemy wszystkim, którzy nas dzisiaj słuchali.

Łukasz Kałużny: Dzięki. Na razie.