Model proponuje, kod rozstrzyga

Weźmy zwykły proces faktur zakupowych. Faktura przychodzi jako PDF na wspólną skrzynkę. Ktoś ją czyta, odszukuje zamówienie, porównuje ilości z przyjęciem magazynowym, dekretuje, sprawdza, kto może zatwierdzić taką kwotę, księguje i planuje płatność.

Są dwa znane sposoby, żeby zautomatyzować to źle. Pierwszy pisze reguły do wszystkiego, łącznie z czytaniem, i przez następny rok utrzymuje szablony pod układ faktury każdego dostawcy. Drugi oddaje całość modelowi — „przeczytaj fakturę i ją zaksięguj” — co działa na pokazie i pada na pierwszym audycie, bo nikt nie umie powiedzieć, dlaczego konkretna faktura została zaksięgowana tak, a nie inaczej.

Wersja, która działa, dzieli proces według rodzaju pracy w każdym kroku, a nie według systemu, którego ten krok akurat dotyka.

Podział według rodzaju pracy

Czytanie. Zamiana czegoś, co napisano dla ludzi, na pola: faktury, maila, dokumentu WZ, formularza reklamacji. W tym modele są dobre, a reguły najbardziej kruche.

Klasyfikowanie i redagowanie. Jaki to rodzaj sprawy, do którego zespołu należy, jak powinna brzmieć odpowiedź albo propozycja dekretacji. To też praca dla modelu, o ile nic nie wychodzi z firmy wyłącznie na jego słowo.

Rozstrzyganie przy niejednoznaczności. Czy reklamacja jest w istocie rezygnacją, czy pozycja faktury opisana w jeden sposób odpowiada pozycji zamówienia opisanej w inny. Model proponuje odpowiedź i pokazuje, na czym ją opiera.

Sprawdzanie względem faktów. Czy dostawca istnieje, czy pozycje sumują się do kwoty, czy ilość mieści się w tolerancji względem przyjęcia, czy ten numer faktury był już księgowany. To kod, zawsze. Model można zapytać, czy suma się zgadza; funkcja to wie.

Zmiana stanu i stosowanie zasad. Księgowanie, płatność, zmiana danych podstawowych, limit zatwierdzania, rozdzielenie obowiązków. Kod i konfiguracja, w transakcji, czytelne dla ludzi odpowiedzialnych za zgodność.

Infografika

Kto wykonuje który krok

Błąd kosztownyBłąd tani

Kod i regułySprawdzalne fakty, pieniądze i stan. Nie ma czego interpretować.

Model proponujeKod weryfikuje propozycję, wątpliwe przypadki idą do człowieka.

Zwykła automatyzacjaIntegracja i reguła. Model niczego tu nie dodaje.

Model działa samOdwracalne i tanie w poprawce, jak wstępne przypisanie sprawy.

Pola i rekordyTekst i dokumenty

Szwem jest propozycja, a nie działanie

Wzorzec, który to spina, łatwo opisać: model nigdy sam nie zmienia stanu. Jego wynikiem jest propozycja — ustrukturyzowany obiekt z odczytanymi polami, wybraną pozycją zamówienia, proponowanym kontem i wskazaniem, z którego miejsca dokumentu pochodzi każda wartość.

Propozycja trafia do warstwy weryfikacji napisanej zwykłym kodem, która sprawdza ją względem systemów źródłowych: czy są wymagane pola, czy każdy identyfikator wskazuje istniejący rekord, czy zgadzają się sumy i podatek, czy zachowano tolerancje, czy nic nie jest księgowane drugi raz, czy zamówienie jest wciąż otwarte. Zatwierdzana jest tylko propozycja, która przeszła, i zatwierdza ją kod.

Kod nie stwierdzi, czy model dobrze przeczytał dokument. Stwierdzi natomiast, czy odczyt jest spójny ze wszystkim, co firma już wie — i wiele błędnych odczytów odpada właśnie tutaj. Te, które przechodzą wszystkie kontrole i nadal są błędne, to ryzyko resztkowe, które mierzy się próbkowaniem, a nie nadzieją.

Czego nie wolno trzymać w promptcie

Limit zatwierdzania wpisany do promptu jest prośbą. Obowiązuje tak długo, jak model odczytuje go zgodnie z intencją. Ten sam limit w kodzie po prostu obowiązuje — i da się go przejrzeć, wersjonować i zmieniać pod tą samą kontrolą co każde inne ustawienie finansowe.

To samo dotyczy wszystkiego, o co zapyta audytor albo regulator. Dział zgodności przejrzy tabelę reguł. Nie przejrzy zachowania modelu na wejściach, których nikt jeszcze nie widział, i nie powinien być o to proszony.

Jest też prostsza wersja tej zasady: nie każcie modelowi robić niczego, co da się policzyć albo wyszukać. Arytmetyka, logika dat, odczyt danych podstawowych i wykrywanie duplikatów są w kodzie tańsze, szybsze i po prostu dokładne.

Gdzie wchodzi człowiek

Propozycje, które nie przeszły weryfikacji, oraz te, które model sam oznaczył jako niepewne, trafiają do człowieka — razem z propozycją, kontrolą, która nie przeszła, i dowodem. Człowiek podejmuje jedną decyzję, zamiast robić sprawę od nowa.

To, które kontrole odpadają i jak często, staje się najużyteczniejszą mapą procesu, jaką kiedykolwiek będziecie mieli. Kontrola, która odpada stale, wskazuje na słaby odczyt, brakujący rekord referencyjny albo regułę, która jest po prostu błędna — a każda z tych rzeczy ma innego właściciela.

Zacznijcie od opisania kroków

Rozrysujcie jeden proces jako kroki i opiszcie każdy z nich: czytanie, klasyfikacja, rozstrzygnięcie, sprawdzenie, zmiana stanu. Te etykiety w dużej mierze same projektują system i od razu pokazują, gdzie model zarabia na swoje miejsce, a gdzie dokładałby tylko ryzyko.

Ta granica — co model może proponować, co egzekwuje kod i co zawsze idzie do człowieka — jest pierwszą rzeczą, którą ustalamy przy inżynierii agentów AI, i zapisujemy ją w kodzie, a nie w promptcie.