PoC agentowe: Kill, Iterate, Scale

Ja bym powiedział, że to jest taki bardziej prequel. To w zależności, jak właśnie miałem z tym problem, które kolejne szkolenie, ale stwierdziłem, że to agent musi wykorzystywać MCP, więc piszemy najpierw agenta, bo w sumie potem już wykorzystanie będzie wiadome po tym, jak to MCP wykorzystać. Jeszcze szybkie dodatkowe ogłoszenie do Protopii, czyli firmy, którą prowadzimy z Szymonem i stoi za Patoarchitektami. I stąd słyszcie o naszych doświadczeniach. Szukamy AI inżyniera, czyli osoby, która pomoże nam w budowie rozwiązań agentowych, LLM-owych w tych projektach, którymi Wam się chwalimy, dzielimy doświadczeniami, czy narzekamy na jakieś PoC agentowe.

Napisz do mnie na LinkedInie, na Priwie bądź na Discordzie. Szczegóły znajdziesz w ogłoszeniu. Ogłoszenie oczywiście, tak jak wszystkie inne linki, tutaj znajdziesz na stronie odcinka i pod spodem. Jaki dzisiaj temat? Bo to trochę z Twojego marudkowania wynikł, więc przedstawiaj go. Tak. Jak przygotować się do POC, POV agentowych rozwiązań? Czyli proof of concept, proof of value. Dobrze. To w takim razie motywacja Łukaszu, bo marudkowanie marudkowaniem i co cię zmotywowało, żeby jednak coś sklodować to? Zdenerwowanie, tudzież określiłbym to innym wulgarnym słowem. W pewnym feedbacku tak przyleciało do mnie na przykład tekst od osoby nietechnicznej.

Dokładnie. I inaczej, w Enterprise'ie wystawimy to za pół roku może przy okazji następnego release'u. Dokładnie. Który jeszcze jest nieokreślony. Dobrze. Czyli mamy powiedziane co właściwie robimy, jak to chcemy zrobić, z czym się łączymy. Co dalej? Dobra. Projektujemy scope i granice PoC. Bo teraz to jest problem, że okej, wiemy jak wygląda cały proces, ale tak naprawdę trzeba wyznaczyć Tak naprawdę, co w PoCach albo w Proof of Value jest najbardziej krytyczne? Czyli trzeba sprawdzić te ścieżki krytyczne, których nie jesteśmy pewni, problematyczne, czyli to jest, ładnie było określenie, to jest studium wykonalności, czyli sprawdzić wszystkie fuck-upy, które mogą się zdarzyć, że to się zawali nam.

To ja to wytłumaczę w inny sposób. Pierw mieliśmy, co byśmy chcieli zrobić, a teraz określamy, co realnie zrobimy. Bo pamiętamy, że jest to PoC, czyli udowadniamy, że technologia hipoteczna może działać. Więc nie wszystko, co byśmy chcieli, realnie zrobimy, no bo to się nazywa już pełnowymiarowy produkt. Tak, więc trzeba sobie określić granice automatyzacji przed rozpoczęciem. Co będzie w tym procesie agent robił sam? Gdzie musi być human in the loop? Gdzie agent coś na przykład zaproponuje, przygotuje, a człowiek wykona? I to trzeba wiedzieć przed. I teraz ważne. Patrzymy sobie, że nie będziemy mieli tam, do tego dojdziemy potem, ale że tam nie ma być ładnego UI i innych rzeczy, tylko my sprawdzamy, tak jak powiedziałaś, czy to w ogóle będzie miało sens i czy uda nam się osiągnąć coś, co nas zadowoli.

No i chyba pora na tym płynnie przechodząc na kryteria sukcesu. Które są ciekawe. Znaczy określenie ich jest z reguły ciekawe, bo jak już jesteśmy w tym momencie, to już sporo organizacji chce, żeby się jednak udało. Tak. I trzeba sobie powiedzieć z tym, jeżeli POC zadziała, to trzeba powiedzieć sobie o dokładności. To jest chyba w ogóle największy przypadek i tą dokładność można. Na przykład minimum 8 na 10 przypadków jest obsłużonych poprawnie. Ta definicja poprawnie jest też bardzo rozmyta. Ja tak wrzucam i cenę może dorzucić do dość ważnych, że to nie wyjdzie w formie Excela, nie zrobimy sobie tabelki i powiemy, że o, taka nam dział wyszła. To jednak jest przejście przez to, jak ten POC działał i czy odpowiedź albo akcje, które on wykonał uznajemy za poprawne, uznajemy za akceptowalne, czyli czy jeżeli by coś takiego zrobił człowiek, to byśmy stwierdzili, że jest okej.

Tak, i teraz jest taka rzecz, że pamiętajmy, że w PoCu nie obsłużymy wszystkiego i tam też mogą być lesson learned na pilota produkcję, czyli możemy już teraz zastanowić się, jaki mógłby być pomysł na fallback, failure modes, czyli jak już zaprojektować sobie na przyszłość, co można byłoby zrobić, żeby poprawić, ale sorry, nie testujemy tego, nie implementujemy w większości przypadków. To są wnioski z PoCa, a nie implementacja, bo mamy takie... To, czego nienawidzę u nas w naszej branży, to to, że PoC ma nagle stawać się... Wszyscy piszą PoCe i robią PoCe tak, że zaraz staje się produkcją. I potem jest krzyk o ten dług technologiczny i inne rzeczy, więc trzeba to napisać tak syfiaście, do czego zaraz przejdziemy jeszcze, żeby nie dało się tego użyć jako pilota czy produkcję.

Mimo, że prompting kusi, żeby zrobić to super ładnie, to miałem ostatnio rozmowę z klientem, nawet już rozumiał, że porzucamy. Że na przykład robimy ładowanie danych, że wrzucimy go na blob'a, czy będzie CLI, jest OK, testujemy jakość odpowiedzi, a nie podejście. Dobrze, to śmigamy dalej w takim razie. Co robiliśmy? Działa, wystawione, brzydkie po brzydkie. Co dalej? Wiesz co, dwie rzeczy jeszcze w trakcie tego to są testy i to jest bardziej cały development z naszej strony. Trzeba niestety wprowadzać małe zmiany. I iteracyjnie je testować i patrzeć, czy w ogóle miało to wpływ. Tak powinno się robić na PoCach i pamiętać, że nie wprowadzamy, bo mi się też zdarza zrobić w tym, w pewnym momencie prompty agentów dojechały do wersji V20 i zostałem zapędzony w tak, że trzeba było to przepisać, bo nie miało to sensu.

To naprawdę to są bulety, ale jakieś właśnie wszystkie fuck-upy, inne rzeczy, w szczególności ja bym powiedział, że to są halucynacje i trzymanie się flow. To są takie rzeczy, o których trzeba pamiętać i widzieć, na przykład teraz mimo wniosków z PoC nadal walczę w jednym miejscu teraz produkcyjnym z halucynacjami, bo nadal się gdzieś pojawiają, a ponoć nie powinny. Ja bym jeszcze powiedział, że to się pojawia też tak naprawdę, to jaką jakość danych te systemy udostępniają, że też wykryjemy ograniczenia tego, co agent dostanie i co agent w ogóle może zrobić. To czasami wychodzi na starcie tej fazy analizy, ale też bardzo często wychodzi w trakcie realnego działania i na realnych przypadkach, że no sorry, ale coś tu musimy zmienić. Czyli nam się tak naprawdę poza POC-em tworzą ograniczenia, ale też możliwości rozwojowe dalsze nie po stronie systemu agentowego, tylko systemów docelowych, a czasem źródłowych.

Dobra. I teraz analiza i decyzja. I to jest kurde największa rzecz, bo trzeba sobie odpowiedzieć, jak popatrzymy, bo mamy sobie takie trzy decyzje, które możemy podjąć. Pierwsza, której wszyscy nienawidzą, czyli zabijamy PoCa. Czyli operacja się udała, pacjent zmarł. I to jest też sukces PoCa. Dowiedliśmy, że się nie da. Biznesowo to jest porażka, a de facto po to robimy PoC, żeby nie wtopić dalej. Ja bym powiedział inaczej. Nie to, że się nie da. Bo dać to się pewnie zawsze da. Nie ma sensu biznesowo. Albo nie jesteśmy na to jeszcze gotowi. Czyli mamy zbyt dużo roboty do wykonania, np. z naszymi obecnymi systemami, z porządkami itd., żeby to ruszać teraz.

Dobra. Potem jest opcja najgorsza, czyli robimy kolejną iterację PoCa. Czemu? No właśnie, bo niektórzy chcieliby uzyskać... I to jest taka rzecz, którą sobie trzeba wytłumaczyć. To jest ten cały problem, który jest razem z Kill, czyli zazwyczaj zaczynamy iterować PoC z tego powodu, że w teorii zainwestowaliśmy już za dużo, żeby się wycofać. Albo bardzo samo, żeby się udało. Albo chcemy, żeby się udało. No i teraz trzeba sobie zobaczyć, czy w ogóle jest jedna rzecz, czy jest tam potencjał i tak naprawdę, co my chcemy poprawić. I czy jest na to potencjał w ogóle do poprawy. Znaczy wiesz, to czasami zmienia się też taka opcja, generalnie tu nam się nie sprawdziło, spróbujmy w innym systemie też. Jeżeli to jest po prostu przeskoczowanie kontekstu, to jest to dobra opcja.

Nie, dobra, ale na poważnie to tak, to jest taka rzecz w tym, jedna z której ja się spotykam teraz patrząc się o tym jak mówimy teraz na przykład siedząc przy takim wdrożeniu, to jest przypomnienie o założeniach. Bo nagle się okazuje, że zaczynamy już testy nie POC, tylko testy tego, co ma zostać wdrożone. I teraz zbieram feedback po tym, zbieram, mam gdzieś pisane wymagania, mam feedback po tym, po POC-u, ale to nie tak miało działać. Łukasz, to jest to, co mówiliśmy o podnoszeniu każdego projektu. To też musi być jakiś marketing wewnętrzny, musi być umocowanie i musi być jasna komunikacja, co właściwie tym możemy zrobić, bo jak będzie hasło, wdrożyliśmy EIA, to zbiór oczekiwań, co on miał robić, osób, które nie były w projekcie, a zbiór tego, co miało być, będzie różny.