Log, którego nie da się odtworzyć, nie jest rejestrem decyzji

Wyobraź sobie dostawcę, który pół roku po fakcie kwestionuje zamówienie. Ilość była trzy razy większa niż zwykle, towar powstał na zamówienie, a kupujący twierdzi teraz, że to była pomyłka. Zamówienie złożyło oprogramowanie. Otwierasz logi i znajdujesz dokładnie to, co logi zwykle zawierają: znacznik czasu, identyfikator zadania, wywołanie interfejsu dostawcy i odpowiedź o powodzeniu.

Nie znajdujesz natomiast niczego, co by to wyjaśniało. Na jaką prognozę popytu patrzył system? Ta tabela jest przeliczana co noc od tamtej pory. Która wersja reguł zamawiania obowiązywała? Edytowano je dwa razy. Czy system rozważał mniejsze zamówienie i je odrzucił? Nic na to nie wskazuje. Decyzja zapadła, a jej powody nie istnieją już nigdzie.

Logi i rejestr odpowiadają innym ludziom

Przyczyną nie jest niedbałość. Logi pisze się dla inżyniera, który szuka usterki dziejącej się teraz: zdarzenia, błędy, czasy wykonania, tyle kontekstu, żeby znaleźć wadliwą linię. Zakładają czytelnika, który zna system i patrzy na niego tego samego dnia.

Rejestr decyzji pisze się dla kogoś zupełnie innego: dla właściciela, który musi za decyzję odpowiedzieć, dla audytora, kontrahenta, sądu. Ten czytelnik przychodzi po miesiącach, nie zna systemu i musi się dowiedzieć, co system widział, co z tego wywnioskował i dlaczego. Tam, gdzie każdy istotny krok zatwierdzał człowiek, to on mniej więcej był rejestrem. Usuń akceptację — o tym, dlaczego to wcale nie jest proste, piszemy w tekście ostatnim człowiekiem w pętli jest podpis — a zapis musi unieść to, co dotąd człowiek nosił w głowie.

Gdzie zawodzą zapisy decyzji

Zapisują działania, a nie obserwacje. „Zamówienie wysłane” to działanie. To, co system widział przed wysłaniem, jest częścią, która je wyjaśnia, a zwykle przechowuje się ją wyłącznie jako odwołanie do tabel, które ciągle się zmieniają. Odwołanie do zmiennych danych nie jest ich zapisem.

Nie przypinają wersji. „Zadziałała reguła 7” nic nie znaczy, kiedy regułę 7 już zmieniono. Tak samo jest z wersjami modeli, promptami, progami i konfiguracją. Zapis, który wskazuje logikę bez dokładnej wersji, prędzej czy później opisze coś, co nigdy nie zostało uruchomione.

Może je zmienić to, co opisują. Jeśli pętla ma prawo zapisu do własnej historii, historia jest deklaracją, a nie dowodem. Nie trzeba do tego złej woli — wystarczy zadanie porządkujące albo migracja.

Kończą się na działaniu. Nic nie łączy decyzji z tym, co nastąpiło potem. Bez dołączonego wyniku nie da się porównać tego, czego się spodziewano, z tym, co zaszło — a część systemu, która ma się poprawiać, nie ma się z czego prawdziwego uczyć.

Są przechowywane przypadkiem. Okres przechowywania to ten, z którym przyszło narzędzie do logowania. Pytania, które naprawdę mają znaczenie — spór, reklamacja, kontrola — przychodzą zwykle długo po tym, jak domyślne okno się zamknęło.

Co musi zawierać wpis w rejestrze

Cztery części, a na każdą da się odpowiedzieć z samego zapisu:

Co zaobserwowano. Dane wejściowe w takiej postaci, w jakiej były w danej chwili — skopiowane albo przechowane jako skrót treści wskazujący na dane, których nigdy się nie nadpisuje.

Co wywnioskowano. Decyzja, rozważone i odrzucone warianty oraz dokładna wersja każdego elementu logiki, który ją wytworzył. Jeśli brał w tym udział model, którego wynik może się różnić między uruchomieniami, do zapisu trafia też jego surowa odpowiedź.

Co zrobiono. Działanie w takiej postaci, w jakiej faktycznie wyszło, z identyfikatorem po stronie kontrahenta, żeby wpis dało się zestawić z jego dokumentami.

Co stało się potem. Wynik, dołączony później i powiązany z wpisem, tak żeby zapis decyzji i zapis jej skutków były jedną rzeczą, a nie dwoma systemami do uzgadniania.

Wokół tych czterech części obowiązują trzy zasady. Rejestr jest tylko do dopisywania. Leży poza ścieżką zapisu pętli, pod poświadczeniami, których pętla nie ma. A okres przechowywania wyznacza najdłuższy czas, przez jaki ktoś mógłby zapytać o decyzję — nie budżet na dyski.

Nie ma w tym nic egzotycznego. Unijne przepisy o sztucznej inteligencji coraz wyraźniej oczekują, że systemy podejmujące istotne decyzje będą przez cały cykl życia automatycznie prowadzić zapis pozwalający prześledzić ich działanie — choć co dokładnie obowiązuje w danym przypadku, zależy od branży i zastosowania. Otwarte pytanie nie dotyczy tego, czy zapis istnieje, tylko tego, czy na cokolwiek odpowiada. Użyteczną miarą jest odtworzenie: mając wpis, czy da się ponownie przeprowadzić decyzję na tych samych danych i tych samych wersjach i dostać ten sam wynik? Jeśli tak, rejestr decyzję wyjaśnia. Jeśli nie, dowodzi tylko, że zapadła.

To ta sama dyscyplina, dzięki której audytowalna jest samonaprawa. System, który potrafi odbudować swój stan z trwałego zapisu, i system, który potrafi z takiego zapisu wytłumaczyć swoje decyzje, korzystają z tego samego.

Test na dziś

Wybierz jedną automatyczną decyzję, którą twoje systemy podjęły w zeszłym miesiącu: zamówienie, zmianę ceny, zwrot pieniędzy, zgłoszenie zamknięte bez człowieka. Daj sobie godzinę i odpowiedz na cztery pytania wyłącznie na podstawie zapisów, nikogo nie pytając:

1. Co system widział w chwili decyzji?
2. Która wersja logiki ją podjęła?
3. Co innego mógł zrobić i dlaczego tego nie zrobił?
4. Co stało się potem?

Policz odpowiedzi, które udało się znaleźć. Każda, która zależała od czyjejś pamięci, to luka, której autonomiczna działalność nie wypełni — bo osoba, która pamięta, jest dokładnie tą, którą taka działalność usuwa.

Rejestr to jeden z sześciu komponentów, które ten program uważa za niezbędne, i to on decyduje, czy pozostałe da się w ogóle sprawdzić.