Ponawia się model, nigdy przelew

Proces czyta fakturę modelem, weryfikuje wynik, księguje i wysyła polecenie przelewu. Wywołanie modelu przekracza limit czasu, choć po stronie dostawcy w rzeczywistości się zakończyło. Orkiestrator ponawia, dostaje drugi odczyt — niekoniecznie identyczny z pierwszym — i jeśli nic nie pilnuje kroku księgowania, faktura zostaje zaksięgowana dwa razy.

Nic w tym nie jest egzotyczne. Procesy łączące modele ze zwykłymi systemami ponawiają kroki znacznie częściej niż klasyczne integracje: wywołania modelu są wolne, dławione przy dużym ruchu i od czasu do czasu przekraczają limit czasu, a pętla agenta potrafi wywołać to samo narzędzie dwa razy, bo nie zobaczyła wyniku pierwszego wywołania. Ponowień nie da się uniknąć. Bezpieczne ponowienia to decyzja projektowa — i zwykle podejmowana za późno.

Dwie właściwości, przez które ponowienia są groźne

Skutki uboczne. Coś poza procesem się zmienia: zapis w księdze, mail, polecenie przelewu, status w portalu dostawcy. Dwukrotne wykonanie kroku oznacza dwukrotne zrobienie tej rzeczy.

Niedeterminizm. Ponowne wywołanie modelu nie musi dać tej samej odpowiedzi. Ponowienie kroku z modelem nie jest powtórzeniem, tylko nową decyzją. Jeśli weryfikacja sprawdziła pierwszy odczyt, a księgowanie użyło drugiego, nikt nie sprawdził tego, co zostało zaksięgowane.

Klasyczne integracje miały pierwszy problem i nauczyły się go rozwiązywać. Procesy mieszane mają oba, a drugi po cichu podkopuje zwykłe rozwiązanie pierwszego.

Zasady, które to zabezpieczają

Zapiszcie propozycję i pracujcie na zapisie. Wynik modelu zapisuje się raz, z identyfikatorem oraz wersją modelu i promptu, zanim cokolwiek na jego podstawie zadziała. Weryfikacja, księgowanie i ślad audytowy odwołują się do tego samego zapisanego artefaktu. Ponowienia późniejszych kroków z niego korzystają i nigdy nie pytają modelu jeszcze raz. Ponowne zapytanie to świadoma nowa wersja, a nie efekt uboczny przekroczonego czasu.

Klucz idempotencji przy każdej zmianie stanu. Wyprowadzony z tożsamości biznesowej — dostawca i numer faktury, a nie identyfikator uruchomienia — żeby druga próba została rozpoznana jako ta sama operacja. System docelowy albo cienka warstwa przed nim odmawia drugiego zastosowania tego samego klucza i zwraca pierwszy wynik. Dostarczenia „dokładnie raz” między systemami, których nie kontrolujecie, nie da się kupić; w praktyce działa „co najmniej raz” plus deduplikacja.

Stanem zarządza proces, a nie agent. To, gdzie jest sprawa, co zrobiono i co czeka, żyje w trwałym silniku przepływu albo w maszynie stanów, które przetrwają restart. Nie żyje w kontekście agenta ani w pamięci pętli. Agent jest krokiem, który proces wywołuje; to nie on trzyma proces.

Ponowienia według typu kroku. Wywołanie modelu: ponowienie z rosnącym odstępem, ograniczoną liczbę razy, a potem wyjątek. Deterministyczna weryfikacja: bez ponowień, bo za drugim razem odpadnie dokładnie tak samo. Zapis zewnętrzny: ponowienie wyłącznie z kluczem idempotencji.

Odróżnijcie porażkę od niewiadomej. Przekroczony czas przy poleceniu przelewu oznacza, że nie wiecie, co się stało. Następnym krokiem jest zapytanie o status, a nie ponowna wysyłka.

Infografika

Ponowienia bez duplikatów, krok po kroku

1. 01PrzyjęcieKlucz z tożsamości biznesowej, a nie z numeru uruchomienia.
2. 02Odczyt modelemWynik zapisany raz, z wersją modelu i promptu.
3. 03WeryfikacjaDeterministyczna, na zapisanej propozycji. Nie ma czego ponawiać.
4. 04Zmiana stanuKlucz idempotencji; powtórka zwraca pierwszy wynik.
5. 05Skutek zewnętrznyPrzy niejasnym wyniku najpierw zapytanie o status.
6. 06Ślad audytowyDopisywany przy każdym kroku, nigdy nadpisywany.

Zapis, którego potrzebuje proces mieszany

Dla każdej sprawy, wyłącznie dopisywany: wejście albo odwołanie do niego, wersja modelu i promptu, zapisana propozycja, które kontrole się wykonały i z jakim wynikiem, co zostało zatwierdzone i pod jakim kluczem oraz każda decyzja człowieka razem z tym, kto ją podjął.

Taki zapis odpowiada na pytanie, które prędzej czy później zada każdy audytor i każdy zirytowany dostawca — dlaczego to zostało zapłacone i na jakiej podstawie — trzy tygodnie po fakcie. Daje też korzyść inżynierską, którą zespoły zwykle odkrywają późno: gdy zmienia się reguła walidacji, można przepuścić nową weryfikację przez zapisane propozycje bez ponownego wywoływania modelu i zobaczyć dokładnie, które dawne sprawy by zatrzymała.

Sprawdźcie to, psując

Zabijcie proces w połowie kroku. Wymuście przekroczenie czasu przez model. Zwróćcie błąd po tym, jak zapis już się udał. Dostarczcie to samo wejście dwa razy w odstępie godziny. Jeśli którakolwiek z tych prób da zdublowany skutek albo sprawę, której nikt nie potrafi odnaleźć, proces nie jest gotowy — niezależnie od tego, jak dobry jest model.

Te testy są tanie, mechaniczne i prawie nigdy nie ma ich w planie. Należą do tego samego zestawu co przypadki ewaluacyjne i razem z rejestrem decyzji, dzięki któremu każdą pojedynczą sprawę da się wyjaśnić, są tą częścią inżynierii agentów AI, której nikt nie pokazuje na prezentacji, a na której polegają wszyscy.