Po co agentom AI czarna skrzynka

„Woda w strefie B, 20 cm i rośnie. Ewakuujemy zmianę nocną?”

Jedenaście słów. Dyżurna operatorka pyta system AI, który ma wspierać sztab kryzysowy.

Odpowiedź ma 187 słów. Gdzieś w środku pada rekomendacja: ewakuować strefę B, punkt zbiórki na parkingu P2.

Operatorka odpisuje: „P2 jest pod wodą”. I odchodzi od systemu. Dalej ustala wszystko bezpośrednio z koordynatorem.

Tę scenę Piotr Ratajski, dyrektor Fabryki AI w Alior Banku, pokazał na konferencji „Analityk & Architekt w erze AI”. Zaznaczył, że to przykład ilustracyjny: system wieloagentowy do zarządzania kryzysowego, zbudowany po to, żeby pokazać koncepcję. Ale błąd, który w nim wystąpił, według Piotra często pojawia się w prawdziwych systemach. A koncepcja, którą przedstawił, AI Watch Tower, pozwala takie błędy znajdować i naprawiać.

Wieża kontroli i czarna skrzynka

Piotr sięgnął po metaforę z lotnictwa. AI Watch Tower to wieża kontroli lotów, w której zbiera się wszystkie dane i zapisuje każdą rozmowę. Czarną skrzynką jest zapis przebiegu (trace), czyli rejestr każdego kroku, użytego narzędzia i podjętej decyzji.

Przy jednym agencie danych jest niewiele. Przy kilku jest ich dużo więcej, a połączenie wszystkich kropek nie jest proste.

Chodzi przy tym nie o szukanie winnych, tylko o diagnozowanie i poprawianie. Twórcy systemu dostają twarde fakty, na podstawie których mogą zmienić prompty albo sposób działania systemu. Po to, żeby użytkownicy nie tracili do niego zaufania, a proces naprawdę stawał się lepszy.

Dlaczego projekty agentowe upadają

Piotr przypomniał prognozę Gartnera: ponad 40% projektów agentowych ma zostać anulowanych do końca 2027 roku. Powody są zwykle trzy:

• rosnące koszty: ile to kosztuje?
• niejasna wartość: czy to komuś pomaga?
• niewystarczająca kontrola ryzyka: czy nad tym panujemy?

Po wdrożeniu zwykle zostają warsztaty, ankiety i przekopywanie logów w poszukiwaniu przyczyn. AI Watch Tower ma odpowiadać na wszystkie trzy pytania z jednego zbioru danych. Do tego automatycznie ocenia pracę AI: model w roli sędziego (LLM-as-a-judge) sprawdza odpowiedzi agentów na podstawie zbiorów danych przygotowanych przez twórców systemu.

Piotr zwrócił też uwagę, że dokładność to jeszcze nie użyteczność. To samo pytanie może poprowadzić rozmowę z agentem w różne strony, więc system trzeba oceniać z wielu stron naraz. Pomiary techniczne warto uzupełniać warsztatami, ankietami i innymi metodami badania użyteczności, bo od tego, czy ludzie będą chcieli z systemu korzystać, zależy jego sukces.

Laboratorium w pakiecie

Wieża kontroli pokazuje, który agent co zrobił i ile to kosztowało. Ale, jak podkreślił Piotr, dostajemy z nią w pakiecie coś więcej: laboratorium do badania doświadczeń użytkowników.

Nie trzeba od razu budować złożonego systemu. Piotr radzi zacząć nawet od jednego agenta, który korzysta z bazy wiedzy i uruchamia narzędzia. Ważne, żeby testować go na różnych typach użytkowników, bo w firmie nigdy nie ma tylko jednego.

W przykładzie ze sztabem kryzysowym dochodzi jeszcze czas. Koordynatorka potrzebuje szybkiej informacji: gdzie ewakuować ludzi i ilu ich jest na nocnej zmianie.

„W kryzysie latencja przestaje być parametrem. Staje się doświadczeniem”.

I jeszcze jedna zasada: system wspiera decyzje, ale sam ich nie podejmuje.

Jak zbudować wieżę

Piotr pokazał przykładową architekturę, w dużej mierze opartą na narzędziach open source:

• warstwa interfejsu, czyli to, co widzi użytkownik,
• symulator person do testów, czyli automatyczne sprawdzanie odpowiedzi na różnych typach użytkowników. Jak podkreślił Piotr, persony to tylko hipotezy,
• system wieloagentowy (na przykład w LangGraph) z koordynatorem i punktami, w których decyzję zatwierdza człowiek,
• baza wiedzy z wewnętrznymi procedurami,
• bramka do modeli (na przykład LiteLLM), która kieruje zapytania do modeli, przełącza je przy awarii i pilnuje budżetu każdego agenta,
• zapis przebiegu i kosztów (OpenTelemetry), trafiający do wieży kontroli, na przykład w Langfuse.

Dzięki temu dostajemy dowody na trzech poziomach: co przeżył człowiek, co zrobili agenci i co zmieniło się w pracy.

Pięć person, pięć definicji jakości

Najciekawsza część wystąpienia dotyczyła użytkowników. W sztabie kryzysowym jest ich pięć typów i każdy oczekuje czegoś innego:

1. Marta, dyżurna operatorka: „Daj mi TAK albo NIE i ilu ludzi”.
2. Tomasz, szef sztabu: „Pokaż warianty i skąd to wiesz”.
3. Ewa, komunikacja kryzysowa: „Ani jednego niepotwierdzonego faktu”.
4. Krzysztof, kierownik w terenie: pracuje w trudnych warunkach i ma jedną kreskę zasięgu.
5. Ola, nowa koordynatorka: „Wytłumacz, dlaczego tak”.

„Ta sama odpowiedź może być świetna dla Tomasza i fatalna dla Marty”.

Integracja z systemem tożsamości (na przykład Entra ID) pozwala rozpoznać, kto pyta i jakie ma uprawnienia, a potem dopasować do niego odpowiedź.

Wróćmy do odpowiedzi na 187 słów. System automatycznie ocenił ją z perspektywy każdej persony. Marta dała 2 na 5, bo odpowiedź była za długa, a decyzja padła dopiero w czwartym zdaniu, i to przy alarmie w tle. Tomasz dał 4, Ewa 3, Krzysztof 1, Ola 4. Średnia 2,8 nic nie mówi.

Rozwiązaniem nie jest jednak skracanie wszystkich odpowiedzi na siłę, bo niektóre persony potrzebują pełnego uzasadnienia.

Otwieramy czarną skrzynkę

Dlaczego agent wskazał zalany parking? Zapis przebiegu w wieży kontroli dał odpowiedź.

Błąd pojawił się w czwartym z sześciu kroków. Agent od procedur przeszukał bazę planów ciągłości działania. Znalazł stary plan z 2023 roku, w którym punktem zbiórki był parking P2, z dopasowaniem do pytania na poziomie 0,91. Aktualny plan z 2025 roku, wskazujący parking P4, miał dopasowanie 0,87.

„Winny nie jest model ani prompt. Winne są dane w jednym agencie. Stary plan był semantycznie bliżej pytania”.

Bez zapisu w wieży kontroli zespół szukałby błędu w modelu językowym, a problem leżał w nieaktualnej bazie wiedzy.

Wieża pokazuje też koszty. Cały incydent kosztował 3,84 dolara, a agent od procedur zużył 36% tej kwoty.

Kto sprawdza sędziego

Model, który ocenia odpowiedzi agentów, też może się mylić. Dlatego, jak mówi Piotr, sędzia AI ocenia każdą rozmowę, a ludzie sprawdzają sędziego.

Pierwsza wersja kryteriów oceny dawała zgodność z ocenami ludzi na poziomie 68%, mniej więcej w dwóch przypadkach na trzy. Po doprecyzowaniu kryteriów zgodność wzrosła do 83%, czyli w pięciu przypadkach na sześć. Dopiero tak sprawdzony sędzia może samodzielnie oceniać pracę systemu, na przykład w nocy.

Piotr pokazał też eksperyment. Nowa wersja promptu, przetestowana na personach w 24 scenariuszach, poprawiła wyniki dla operatorki i szefa sztabu. Ale u kierownika w terenie wynik spadł o 0,5 punktu, a u nowej koordynatorki o 0,4. Spadek powyżej ustalonego progu 0,3 punktu automatycznie zablokował wdrożenie.

Cztery pułapki

Na koniec Piotr wymienił cztery pułapki:

1. Sędzia AI ma swoje skrzywienia. Zawsze sprawdzaj go na ocenach ludzi.
2. Metryka, która staje się celem, przestaje mierzyć. Skracanie odpowiedzi na siłę szkodzi innym personom.
3. Dane osobowe w zapisach. Zamaskuj je, zanim zaczniesz zapisywać przebiegi.
4. Persona to hipoteza. Potwierdzi ją albo obali dopiero prawdziwe użycie.

„Obserwowalność to nie nadzór nad ludźmi. To czarna skrzynka, dzięki której błąd nie powtórzy się drugi raz”.

Pytania z sali

Andrzej Sobczak zapytał czy wyniki z wieży wracają w banku do analityków na etapie odkrywania potrzeb. Aż się prosi, żeby osoby na początku procesu dostawały twarde dane, a nie tylko opinie z ankiet.

Piotr odpowiedział, że każda firma, która chce poprawiać adopcję i dbać o to, żeby ludzie chcieli korzystać z inwestycji w AI, musi mierzyć użyteczność na różnych poziomach. To dobra praktyka, która powinna działać wszędzie, bo jakości rozwiązań opartych na generatywnym AI nie da się sprawdzić zero-jedynkowo. Najważniejsza jest adopcja, a bez dowodów, badań i symulacji na użytkownikach albo ich personach nie da się nią świadomie sterować.