PoC agentowe: Kill, Iterate, Scale

Niestety, mimo że prompt jest bardzo precyzyjny, prawie za każdym zapytaniem odpowiedzi różnią się merytorycznie. Te wszystkie czaty GPT, co-piloty, to jest no-go. Do takich eksperymentów, które mają się przerodzić w coś faktycznie przydatnego potem od strony biznesowej. I czemu? Bo nagle tak jak w moich przypadkach okazuje się, że w trakcie poca dowiadujemy się, że API jest, ale tej części danych nigdy nikt nie chciał z API, więc nie wystawiamy z systemu. 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ę.

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ę.

Który będzie źródłem wniosków, niekoniecznie będzie bazą kodu do dalszego rozwoju, może tak to nazwijmy. Tak. To co, budujemy PoCa. Mhm. Dobra, to tutaj będzie tak. Jedna rzecz, którą ci pewnie zaskarbiło twoje. Wrzucamy tam przy POCu logów nigdy nie za dużo, żeby można było łatwo. W przypadku agentówki szczególnie te logi będą spuchnięte i tyle. Tym bardziej, że większość tych systemów do agentów mamy to prawie z pudełka praktycznie można powiedzieć w wielu sytuacjach. Więc koszt dodania logów jest minimalny. Tak i teraz załóżmy sobie, Brzydki workflow, brzydka automatyzacja, brzydki hod, brzydki UI. To wszystko jest OK, bo skupiamy się na tym celu, co my sobie wyznaczyliśmy.

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.