AI projektuje AI, czyli dlaczego produkcja to dopiero początek

Biznes przysyła 100 faktur i 100 poprawnych odpowiedzi. Asystent AI ma z każdej wyciągnąć kwotę. Testy wychodzą idealnie: 100%. Zespół wdraża rozwiązanie w dziale, w którym pracuje 20 osób.

Pierwszego dnia na produkcji przychodzi faktura, na której wydrukowana kwota 1 500 zł jest przekreślona długopisem, a pod spodem ktoś dopisał ręcznie 2 500 zł.

Co z tym zrobi OCR? Nie wiadomo. Może odczyta obie liczby, może jedną, może drugą.

Zespół myśli: to choroby wieku dziecięcego, wypuszczamy poprawkę. Dzień później przychodzi faktura od nowego klienta z Dżibuti, który zupełnie inaczej generuje PDF-y, i OCR znowu się gubi.

Od tego przykładu Maciej Papiewski z LUX MED zaczął swoje wystąpienie na konferencji Analityk / Architekt w erze AI, zorganizowanej przez Andrzej Sobczak i Jan Maria Kowalski, MBA, która przyciągnęła ponad 4 tys. uczestników.

Co się zmieniło przez rok

Zespół Maćka wdraża na produkcję agentów AI i systemy oparte na modelach językowych, ale nie agentów do pisania kodu, tylko rozwiązania dla biznesu, na przykład analizatory dokumentów.

Rok wcześniej występował na naszej konferencji Agentic Coding. Przyznał, że to był wyjątkowo niefortunny moment, bo dwa miesiące później pojawiły się modele, które „wywróciły stołek”. Dziś, jak mówi, większość osób, z którymi rozmawia, pisze kod z pomocą AI.

AI, które buduje AI

Wcześniejsze wystąpienia pokazywały, jak wyglądają „fabryki oprogramowania”, w których zespoły agentów piszą kod. Maciej skupił się na szczególnym przypadku: co się dzieje, kiedy agenci budują systemy, które same korzystają z modeli językowych.

To nie jest zmiana kosmetyczna. Łatwo wpaść tu w błąd, który potem boleśnie wychodzi na produkcji. Z rozmów w kuluarach Maciej wiedział, że zdarza się on po kolei w każdej firmie, która takie systemy buduje.

Żeby agenci kodujący dobrze działali, trzeba zamknąć pętlę informacji zwrotnej. W zwykłym oprogramowaniu robią to testy: automatyczne, ręczne, scenariusze testowe. Firmy uczyły się ich przez dekady i wiedzą, jak sprawdzić, czy wynik jest poprawny.

W systemach z LLM-em wyniki są niedeterministyczne. I nie chodzi tylko o to, że model może coś źle powiedzieć. Problem w tym, że bardzo trudno w ogóle określić, co jest poprawną odpowiedzią. A produkcja jest dużo brudniejsza niż przy zwykłym oprogramowaniu. Maciej powiedział, że „przemnożona razy milion”. Nawet procesy, które wydają się dojrzałe, okazują się żyć w dziwnych PDF-ach od klientów.

Błąd pierwszego dnia

Jak firmy zwykle podchodzą do pierwszych wdrożeń? Maciej rozpisał proces wytwarzania oprogramowania w dużym uproszczeniu („Andrzej i pół sali pewnie by mnie wynieśli na widłach”): analiza, wykonanie, produkcja. Zbieramy wymagania, budujemy, w pętli Agile wracamy do analizy, wdrażamy. Po wdrożeniu jest krótki czas na poprawki, a potem system przechodzi w utrzymanie.

Przy LLM-ach szybko okazuje się, że same wymagania nie wystarczą. Potrzebny jest zbiór referencyjny (Golden Dataset), czyli zestaw prawdziwych przykładów z poprawnymi odpowiedziami. To już powszechna wiedza.

Pułapka polega na czymś innym: na przekonaniu, że jeśli system zdał testy na zbiorze referencyjnym, to jest gotowy. Historia z przekreśloną fakturą i klientem z Dżibuti pokazuje, że nie jest.

Evalsy, nie testy

Najważniejsza teza Macieja brzmi: ewaluacje (evals) są kluczowym czynnikiem, który kształtuje architekturę takiego systemu.

To nie są testy w starym sensie, czyli techniczne zabezpieczenie przed tym, żeby coś się nie zepsuło. Proces jest podobny, ale chodzi o coś innego, dlatego nawet nazywa się je inaczej. Maciej radził, żeby przy takich systemach wyłączyć intuicję, że to to samo. To nie jest to samo.

Ewaluacje są dwóch rodzajów:

• Offline: zbiór referencyjny, na przykład te 100 faktur. Agent kodujący może na nim pracować lokalnie, w pętli, i poprawiać system. To zamyka pętlę po stronie programowania.
• Online: ocena na produkcji. Najprostszy przykład to łapki w górę i w dół pod odpowiedziami w ChatGPT czy Gemini.

Wdrożenie dla jednej osoby

Jak zbierać ewaluacje online, żeby nie skończyło się katastrofą?

W zwykłym oprogramowaniu dla działu liczącego 20 osób nikt nie robiłby stopniowego wdrożenia. Wdraża się od razu wszystkim. Przy agentach AI Maciej radzi zrobić dokładnie odwrotnie: wdrożyć jak najmniejszej grupie. Najlepiej jednej osobie.

Ta osoba musi wiedzieć, że nie może ufać systemowi. Przez pierwsze dwa tygodnie robi swoją pracę ręcznie, równolegle z agentem, i sprawdza, gdzie się myli. Można też zrobić to automatycznie: wysyłać dane równolegle do systemu, który działa w tle (shadow deployment), i porównywać wyniki.

Po co to wszystko? Zwykle okazuje się, że jakieś 2-5% nietypowych przypadków odpowiada za 80% błędów. Właśnie ich się szuka. A jeśli takie przypadki da się łatwo rozpoznać, najprościej przekazać je człowiekowi.

Produkcja to dopiero początek

Maciej ostrzegał, żeby nie liczyć na to, że przed wdrożeniem uda się zebrać dane, które dadzą stuprocentowe zaufanie do agenta. To się nie stanie. Najbrudniejsze dane trzeba zebrać z produkcji, przez wdrożenie w tle albo z pomocą zaufanego użytkownika po stronie biznesu.

W zwykłym oprogramowaniu wejście na produkcję zamykało cykl. Tutaj, jak podkreślił Maciej, wejście na produkcję jest dopiero pierwszym krokiem. Rozwój i testy odbywają się na produkcji, choć dla tradycyjnego inżyniera brzmi to śmiesznie i groźnie. Takich systemów nie da się rozwijać bez sprawdzania ich na żywym organizmie.

Ewaluacje online muszą być połączone z programowaniem pętlą informacji zwrotnej. A zespół, co Maciej sam nazwał zaskakującym, staje się przede wszystkim opiekunem zbiorów danych dla agenta.

Pytania z sali

Zacząłem od wyznania: przez trzy lata byłem testerem i kiedy słyszę „testy na produkcji”, to… Sala się zaśmiała. Zapytałem więc, jak przekonać do tego biznes w tak mocno regulowanej branży jak medycyna.

Maciej odpowiedział, że to są testy na produkcji, ale nie na produkcji w tradycyjnym sensie, więc słowo „produkcja” najlepiej wyrzucić do kosza. Na tym etapie system nie podejmuje samodzielnie żadnych decyzji. Korzysta z niego jedna zaufana osoba, która wie, że nie wolno mu ufać, patrzy na wynik i mówi: „Nie, bzdurę powiedział”.

„Nie możemy systemowi zaufać, dopóki w boju nie udowodni swojej niewinności”.

Dodał, że jeśli wypuści się agenta od razu do 20 osób, ludzie zaczną mu ufać bez zastanowienia. Na pierwszym etapie rozwoju produktu kończy się to katastrofą.

Padło też pytanie, czy planując kolejne wdrożenia, przewidują w harmonogramie dużo więcej czasu na ewaluacje. I jak przekonać ludzi z biznesu do klikania łapek, skoro na przykład lekarz po rozmowie z pacjentem ma jeszcze oceniać odpowiedzi AI.

Maciej odpowiedział, że czas na ewaluacje musi być wpisany w plan projektu. Zbieranie ocen od użytkowników przyznał za bardzo trudny temat. Zauważył, że nawet ChatGPT w pewnym momencie usunął łapki. LUX MED ma to szczęście, że jego biznes jest bardzo zaangażowany. Jego rada: znaleźć w biznesie osobę, która wymyśliła danego agenta. Ona ma naturalną motywację, żeby system dopracować i przez pierwszy okres oceniać wyniki.