Agent zrobił dokładnie to, co napisaliśmy: dlaczego automatyzacje AI zawodzą po cichu

Automatyzacja AI rzadko psuje się głośno. Nie wyrzuca błędu, nie zatrzymuje importu, nie budzi nikogo w nocy. Kończy się sukcesem i oddaje wynik, który wygląda dobrze. Problem polega na tym, że model wykonał instrukcję dosłownie, a instrukcja znaczyła co innego, niż miał na myśli jej autor.

O modelach mówi się, że „rozumieją”. Nie rozumieją, tylko wykonują. Ta różnica jest niewidoczna, dopóki instrukcja jest jednoznaczna, i kosztowna w momencie, gdy przestaje być. Niżej trzy defekty, które zmierzyliśmy u siebie, i to samo zjawisko przełożone na katalog, atrybuty i feedy w sklepie.

Warto rozdzielić dwa rodzaje awarii, bo bronisz się przed nimi zupełnie inaczej:

• Awaria głośna: skrypt kończy się błędem, import staje, kolejka rośnie. Widać ją tego samego dnia i ktoś ją naprawia.
• Awaria cicha: proces kończy się sukcesem, dane wyglądają sensownie, a mimo to każdy wynik ma ten sam defekt. Widać ją dopiero w zestawieniu, o ile ktoś je w ogóle zrobi.

Defekt 1: jedno dwuznaczne zdanie w briefie

Rozdziały przewodników piszemy z pomocą agentów. W briefie redakcyjnym stało zdanie: „jedna tabela albo jedna lista”. Intencją była proporcja, czyli nie zaśmiecaj tekstu wyliczeniami. Agenci odczytali to jako twardy limit i zrobili dokładnie to, co przeczytali.

Skalę zobaczyliśmy dopiero po policzeniu skryptem:

• 10 rozdziałów z 12 nie miało ani jednej listy.
• 31 akapitów przekraczało 700 znaków.
• Jeden rozdział miał 20 akapitów powyżej 600 znaków na 24 wszystkie.

Najciekawsze jest to, dlaczego przez tydzień nikt tego nie zgłosił. Każdy tekst z osobna wyglądał poprawnie: spójny, rzeczowy, bez błędów. Defekt istniał wyłącznie w zestawieniu, a zestawienia nikt nie robi, dopóki nie ma powodu. Dwuznaczny zapis nie zepsuł jednego rozdziału. Zepsuł całą serię, w tę samą stronę i z tego samego powodu.

Defekt 2: jedna nazwa, trzy znaczenia

Drugi defekt jest jeszcze cichszy, bo nie zostawia śladu w tekście, tylko w zachowaniu. W naszym otwartym zestawie skilli dla agentów argument --profile znaczył trzy różne rzeczy w trzech miejscach: raz zestaw reguł walidacji, raz typ asortymentu, raz ścieżkę do pliku konfiguracyjnego.

Człowiek w takiej sytuacji dopytuje. Agent nie dopytuje: bierze najbardziej prawdopodobne znaczenie i idzie dalej. Wynik jest formalnie poprawny i inny niż zamierzony, a komunikat o błędzie nie pojawi się nigdy, bo z punktu widzenia narzędzia nic złego się nie stało.

Poprawka była nudna i skuteczna: jedna nazwa, jedno znaczenie w całym zestawie, a dla osobnych pojęć osobne nazwy. Kolizja nazw to najtańszy do usunięcia rodzaj cichego defektu i jednocześnie najczęściej przeoczony, bo nazwy dobiera się mimochodem, a potem żyją w kilku plikach naraz.

Defekt 3: bez pomiaru masz opinię, nie dane

Defekt pierwszy nie wyszedł z żadnego alertu. Wyszedł dlatego, że człowiek przeczytał tekst i powiedział: „słabo się to czyta”. Dopiero wtedy policzyliśmy długości akapitów, liczbę list i liczbę śródtytułów. Wrażenie zamieniło się w zadanie w momencie, w którym dostało liczby.

Przy okazji jedno polecenie znalazło 57 niedomkniętych cudzysłowów w trzech dokumentach: znak otwierający „ bez pary domykającej. Takiego błędu oko nie łapie przy czytaniu, a powtarza się w każdym pliku, który powstał tym samym procesem. Sprawdzenie zajęło minutę i wcześniej po prostu nie istniało, bo nikt nie pomyślał, żeby je zrobić.

To samo dzieje się w operacjach sklepu

Rozdział przewodnika to niska stawka. W sklepie ten sam mechanizm dotyka opisów, atrybutów i feedów, czyli danych, które klient widzi i po których decyduje o zakupie. Nieprecyzyjna reguła nie psuje jednego produktu. Psuje wszystkie naraz, w każdym kanale, do momentu aż ktoś ją poprawi.

Opisy produktów: „zwięzły” to życzenie, nie instrukcja

„Opis ma być zwięzły i sprzedażowy” brzmi jak polecenie, a jest życzeniem: nie da się go sprawdzić skryptem ani rozstrzygnąć nim sporu. Agent, który dostaje przymiotnik, sam ustala jego wartość, i ustala ją inaczej dla wiertarki, a inaczej dla kolczyków.

Instrukcją staje się to dopiero z kompletem czterech rzeczy:

• Zakres: od 400 do 600 znaków, trzy akapity, pierwsze zdanie z konkretną korzyścią.
• Pola wymagane: materiał, wymiary, kraj produkcji, sposób pielęgnacji, o ile są w karcie produktu.
• Twierdzenia zakazane: zdrowotne, medyczne, „najlepszy na rynku” i wszystko, czego nie ma w danych źródłowych.
• Dwa przykłady: jeden opis dobry i jeden zły, plus jedno zdanie, dlaczego zły jest zły.

Ostatni punkt jest najtańszy i najczęściej pomijany. Model trafia w intencję znacznie lepiej z jednego przykładu negatywnego niż z trzech akapitów wytycznych, bo przykład rozstrzyga przypadki brzegowe, których wytyczna nie przewidziała. Jak taki komplet reguł wygląda w całości, rozłożyliśmy w tekście o opisach produktów tworzonych z AI.

Atrybuty: czarny, black i BLK to trzy wartości

Weź eksport z ERP: kilka tysięcy wierszy i kolumna „kolor”, a w niej czarny, black, BLK, czerń i ciemny. Dla człowieka to jeden kolor. Dla filtra w sklepie, dla feedu i dla agenta to pięć osobnych wartości, dopóki ktoś nie zapisze, która jest kanoniczna i co zrobić z resztą.

Słownik wartości rozstrzyga trzy rzeczy naraz:

• Wartość kanoniczna: do katalogu trafia „czarny” i tylko ta forma.
• Synonimy: black, BLK i czerń mapują się na „czarny”, zamiast zakładać nową pozycję w filtrze.
• Brak danych: pusta komórka zostaje pusta i trafia na listę do uzupełnienia, zamiast dostać kolor wywnioskowany z nazwy produktu.

Bez słownika agent zgadnie, i w większości wierszy zgadnie sensownie. To gorsze niż zgadnięcie źle wszędzie, bo błąd rozproszony po katalogu jest trudniejszy do zauważenia niż błąd konsekwentny. Dlaczego uporządkowane dane są warunkiem wstępnym każdej automatyzacji, opisujemy w rozdziale przewodnika o danych jako warunku wstępnym.

Feedy: napisz wprost, co robić z brakiem danych

Specyfikacja feedu to miejsce, w którym cicha awaria kosztuje najszybciej, bo dane idą prosto do kanału sprzedaży. Trzy rzeczy muszą być w niej zapisane wprost: limit długości tytułu, pola wymagane w danym kanale i postępowanie przy braku danych.

Ostatnie jest najważniejsze i najczęściej pominięte. Agent z poleceniem „uzupełnij brakujące dane” uzupełni je wartością, która brzmi prawdopodobnie, bo dokładnie o to został poproszony. Agent z poleceniem „braki oznacz jako BRAK, nigdy nie zgaduj” odda katalog z dziurami i listę do uzupełnienia. Druga wersja wygląda gorzej w raporcie i jest jedyną, która nie wprowadza klienta w błąd.

Różnicę między życzeniem a instrukcją widać najlepiej wierszami:

Przymiotnik zostawia decyzję modelowi. Liczba i słownik zostawiają ją Tobie.

Efekt skali działa w obie strony

Praca ręczna produkuje błędy pojedyncze i losowe: człowiek myli się nieregularnie i za każdym razem trochę inaczej. Automat produkuje błędy systemowe: ten sam błąd w każdym wierszu, konsekwentnie i bez wyjątków. To jednocześnie największa zaleta automatyzacji i jej największe zagrożenie.

Dwie strony tej samej właściwości:

• Zaleta: jedna poprawka reguły naprawia cały zbiór, bo błąd ma jedno źródło. Ręcznych pomyłek nie da się naprawić hurtem, trzeba je znaleźć po kolei.
• Zagrożenie: do momentu poprawki ten sam błąd widzi każdy klient, na każdej karcie produktu i w każdym kanale, który zdążył zaciągnąć feed.

Dlatego przy automatyzacji opłaca się przenieść uwagę z pojedynczego wyniku na regułę, która go wyprodukowała, i na próbkę, którą ktoś obejrzy przed uruchomieniem całości. Jak liczyć oszczędność z takiego procesu, rozkładamy w anatomii oszczędności automatyzacji, a sam moment zatwierdzania opisujemy jako człowieka w pętli.

Instrukcja dla agenta to interfejs, nie notatka

Notatkę czyta się z dobrą wolą i resztę się domyśla. Interfejs wykonuje się dosłownie i zwraca dokładnie to, co w nim napisano. Instrukcja dla agenta należy do drugiej kategorii, więc pisze się ją jak kontrakt, a nie jak wiadomość do kolegi z zespołu, który zna kontekst.

Trzy rzeczy usuwają większość cichych defektów:

• Zdefiniowany słownik: jedna nazwa, jedno znaczenie w całym procesie, a wartości pochodzą ze słownika, nie z głowy modelu.
• Sprawdzalne kryterium zamiast przymiotnika: nie „ma być czytelne”, tylko liczba, którą policzysz skryptem: długość, liczba pól, dopuszczalne wartości.
• Pomiar próbki, zanim uwierzysz, że działa: sto wierszy albo dwanaście tekstów wystarczy, żeby zobaczyć defekt systemowy. Bez tego nie wiesz, czy masz jakość, czy tylko brak zgłoszeń.

Ten sam mechanizm opisywaliśmy wcześniej od strony kodu, gdzie wąskim gardłem jest weryfikacja, a nie pisanie. W danych produktowych działa identycznie, tylko defekt jest cichszy, bo dane nie mają typów ani testów, dopóki ktoś ich nie dopisze. U nas ta warstwa, czyli słowniki, reguły i kontrole na próbce, jest częścią etapu AI Automation i wchodzi do platformy razem z automatyzacją, którą pilnuje. Nie gwarantuje bezbłędności. Skraca czas między błędem a jego zauważeniem, i o to w tym rzemiośle chodzi.