Jak nie budować agenta AI. Fakap przy pierwszym agencie: cztery wpadki i 43 904 przebiegi bez jednego trafienia

W pierwszej części opisaliśmy, jak działa nasz agent prowadzący wywiad z klientem. To była wersja na wywiad do gazety. Ta jest wersją z zaplecza: cztery błędy techniczne, które popełniliśmy po drodze, i jeden, który techniczny nie jest. Każdy z nich przez jakiś czas udawał poprawnie działający system – i robił to przekonująco.

Piszemy o nich, bo wszystkie są przenośne: nie dotyczą naszego kreatora, tylko każdego procesu, w którym reguły spotykają się z modelem językowym.

1. Reguła, która przez 43 904 przebiegi nie doszła do głosu

Agent wybiera kolejne pytanie z katalogu, sortując otwarte „luki” po priorytecie. W fazie drążenia problemu obowiązuje sufit liczby pytań, żeby rozmowa nie zamieniła się w przesłuchanie.

Reguła o najniższym priorytecie w tej fazie (pytanie „co już próbowaliście z tym zrobić”) nie padła ani razu w 43 904 symulowanych przebiegach. Od razu uspokajamy: nikt z nas nie klikał tego 43 904 razy. Przebiegi puszcza skrypt, nie człowiek. Przy 43 904 przebiegach zero trafień nie mogło być pechem.

Reguła nie była źle napisana. Po prostu nigdy nie dostawała kolejki. Licznik obejmował także wymianę otwierającą fazę. Reguły w tej fazie były cztery, sufit też wynosił cztery: otwarcie zjadało jeden slot i na ostatnią regułę nigdy nie starczało miejsca. Jak czwarta osoba w trzyosobowej windzie: stoi grzecznie przy drzwiach, a winda odjeżdża za każdym razem.

To nie był błąd kolejności. To był głód. Przestawianie priorytetów tylko przesuwa problem na inną regułę – wtedy przy drzwiach windy stoi ktoś inny. Naprawa polegała na uznaniu, że sufit musi wynosić liczba reguł danej fazy + 1 (dziś pięć) i na zapisaniu tego jako zasady przy samej stałej, żeby następna dołożona reguła nie zagłodziła kolejnej.

Wniosek: jeśli w systemie regułowym jakaś gałąź nigdy nie jest wybierana, nie zakładaj, że warunki są za wąskie. Policz, czy w ogóle ma szansę zostać osiągnięta.

2. Logika, której nie widział żaden test, myliła się do dnia naprawy

Rozmowa zaczyna się od pytania o zgodę. Odpowiedź trzeba zinterpretować: „jasne, pytaj” to zgoda, „dziękuję, wolę nie” to odmowa. Funkcję, która to rozstrzygała, napisaliśmy w komponencie interfejsu, czyli tam, gdzie akurat była potrzebna. Wydawało się to rozsądne.

I tam była poza zasięgiem obu naszych testów naraz: jeden chodzi po przeglądarce i nie zna funkcji, drugi testuje reguły i nie importuje komponentu. Żaden z nich jej nie sprawdzał. Efekt: od pierwszego dnia działania bramy do naprawy 24 sierpnia 2026 myliła się w obie strony. „Nie ma sprawy, pytaj” kończyło rozmowę. „Dziękuję, kończymy” jej nie kończyło. Agent kończył rozmowę, gdy klient chciał ją prowadzić, i ciągnął ją po jawnej odmowie.

Przeniesienie tej jednej funkcji do modułu z czystymi regułami (bez interfejsu, bez stanu) od razu ujawniło oba przypadki, bo dało się je opisać trzema linijkami testu.

Przy okazji ustaliliśmy zasadę na wypadek odpowiedzi niejednoznacznej: przy wątpliwości przyjmujemy, że wolno zadać kolejne pytanie. Nie ma to nic wspólnego ze zgodami na przetwarzanie danych – te zbiera osobny krok kreatora i osobne oświadczenie. Koszt pomyłki jest tu asymetryczny: nadmiarowe pytanie kosztuje jedno kliknięcie, ucięta rozmowa kosztuje cały wywiad. Granicy pilnuje npm run test:rozmowa: jawna odmowa kończy rozmowę niezależnie od tego, co rozpozna wzorzec.

Wniosek: logika, od której zależy przebieg procesu, nie powinna mieszkać w warstwie prezentacji. Nie z powodów estetycznych, tylko dlatego, że w komponencie nie da się jej przetestować niczym poza przeglądarką – a testy przeglądarkowe sprawdzają to, co widać, nie to, co rozstrzyga.

3. „12 stanowisk” jako rozjechany magazyn

Klient może opisać swój problem własnymi słowami. Rozpoznajemy w tym tekście typowe bolączki po rdzeniach słów: „zamknięcie miesiąca”, „przestój”, „przepisywanie”.

Jeden z rdzeni brzmiał stan i miał łapać rozjechane stany magazynowe. Był bardzo pracowity. Łapał także:

• „sprzęt potrafi stanąć”, czyli awarię, nie magazyn,
• „12 stanowisk”, czyli liczbę pracowników,
• „stan konta”, czyli finanse, nie magazyn.

Każde takie trafienie obniżało ocenę obszaru „Dane”. Klient dostawał gorszy wynik za to, że napisał, ilu ma pracowników. Dopóki rozpoznawanie tekstu służyło tylko do dobierania pytań, fałszywe trafienie kosztowało jedno nietrafione zdanie. Od chwili, gdy zaczęło zasilać ocenę, ta sama pomyłka zaczęła kosztować wynik. Rdzenie musiały zwęzić się do form, które nie mają innego znaczenia. Każdy nowy rdzeń dokładamy dziś razem z przypadkiem testowym.

Wniosek: dopasowanie po fragmencie słowa jest wygodne dokładnie do momentu, w którym jego wynik zaczyna na coś wpływać. Zmiana zastosowania reguły jest zmianą wymagań wobec jej precyzji, nawet jeśli sama reguła się nie zmieniła.

4. Liczba zgadnięta „z zapasem w górę” była zawyżona prawie dwukrotnie

Na końcu pokazujemy klientowi, ile kosztowało nas przeprowadzenie jego wywiadu. To jest sedno całego narzędzia: dowód, że automatyzacja tego procesu jest tania, a nie deklaracja, że jest.

Koszt odczytu strony stał tam przez jakiś czas jako 25 groszy: wartość wpisana z głowy, „z zapasem w górę”, zanim ktokolwiek ją zmierzył. Zapas w górę wydawał się bezpieczny: lepiej zawyżyć niż zaniżyć. Tak przynajmniej mówi intuicja, która, jak się okazało, nie miała dostępu do cennika.

Pomiar dał 13,4 grosza. Zgadywanka była zawyżona prawie dwukrotnie. Narzędzie, które miało dowodzić, że automatyzacja jest tania, pokazywało więc, że jest droższa, niż jest. Trudno o zgrabniejszy strzał we własną stopę.

Przy liczbie podawanej jako dowód kierunek odchylenia nie ma żadnego znaczenia. Zawyżona liczba nie jest ostrożna. Jest po prostu nieprawdziwa, tylko w drugą stronę. Dziś obie kwoty pochodzą z konkretnych wykonań workflow, z datą pomiaru i identyfikatorem przebiegu. Koszt odczytu strony ma przy sobie także numery pojedynczych wykonań. Przy stałych stoi notatka, że zmiana modelu albo cennika unieważnia wynik.

Wniosek: w materiale sprzedażowym oszacowanie i pomiar wyglądają identycznie. Różnią się dopiero wtedy, gdy ktoś zapyta, skąd ta liczba.

Piąta, najtrudniejsza: czyj to jest cytat

Piąty błąd nie jest techniczny i żaden test go nie wykryje.

Zdanie o tym, czym firma się zajmuje, układa model na podstawie treści jej strony. Przez pewien czas pokazywaliśmy je w cudzysłowie, pod nagłówkiem „Tak nazwadomeny.pl opisuje Waszą firmę”. Formalnie prawie prawda, bo treść pochodziła ze strony. Praktycznie: wypowiedź modelu podawaliśmy jako wypowiedź cudzej witryny. Różnica przestaje być akademicka, gdy model streści slogan i zabrzmi to jak przechwałka. Wtedy w cudzysłowie stoi zdanie, którego nikt nie napisał, przypisane komuś, kto go nie powiedział.

Dziś ten blok mówi „Tak to zrozumieliśmy”, a tekst stoi w zwykłym akapicie. Cudzysłów zarezerwowaliśmy dla prawdziwych cytatów i wtedy jest podpisany źródłem.

Wspólny mianownik

Wszystkie pięć błędów łączy jedno: system działał. Nie rzucał wyjątkiem, nie zapalał się na czerwono, przechodził testy. Mylił się cicho i z pełnym przekonaniem. A cichy błąd w procesie, który rozmawia z klientami, może działać bardzo długo, zanim ktokolwiek zauważy.

Dlatego jedyną odpowiedzią, jaką znaleźliśmy, jest wyprowadzanie każdej decyzji do miejsca, w którym daje się ją sprawdzić osobno – i mierzenie każdej liczby, którą pokazujemy komuś na ekranie. Także tych, które „na pewno są z zapasem”.