Lista kontrolna gotowości do produkcji agentów AI, krok po kroku

Przejście od działającego prototypu do uruchomienia agenta AI w środowisku produkcyjnym odbywa się według przewidywalnej ścieżki, a każdy etap ma swoje własne sprawdzenia oraz sposoby, w jakie może pójść nie tak przy ich pominięciu. Ten przewodnik omawia każdy etap po kolei.

Prototyp ma jeden cel – pokazanie, że dana idea funkcjonuje: jeden komputer, stan przechowywany w pamięci, brak rzeczywistych użytkowników. Środowisko produkcyjne wymaga czegoś więcej. Agent musi przetrwać restarty, obsługiwać kilku użytkowników jednocześnie, odzyskać funkcjonowanie w przypadku awarii na pewnym etapie oraz pozostawiać zapisy, które umożliwią zlokalizowanie problemu w razie błędu.

Niewiele z tych wymagań dotyczy samego AI, ponieważ wywołanie modelu jest zazwyczaj najprostszą częścią. Trudniejsze są kwestie z nim związane: gdzie przechowywany jest stan, co się dzieje, gdy jakiś krok zostanie wykonyany dwukrotnie, oraz jak zmiana ma dotrzeć do rzeczywistego użytkownika bez powodowania szkód. Skorzystaj z poniższych list, aby sprawdzić, co zostało już uwzględnione, a co jeszcze nie, przed uruchomieniem agenta.

Etap 1: rozwój i lokalny prototyp

Cel jest tu celowo wąski – ma on na celu udowodnienie, że podstawowa idea w ogóle funkcjonuje. Nie próbuj jeszcze kształtować go tak, jak będzie wyglądał w produkcji. Robienie tego zbyt wcześnie zazwyczaj oznacza budowę niewłaściwej infrastruktury dla projektu, który jeszcze nie został sfinalizowany.

Upewnij się, że podstawowy proces pracy działa przynajmniej raz, w jak najmniejszym możliwym zakresie. Przeprowadź jedną czystą transakcję od danych wejściowych do poprawnych wyników, zanim pojawią się kolejki, bazy danych czy procesy implementacji.

Dlaczego: Wczesne wybory infrastruktury są zazwyczaj błędne, ponieważ prawdziwy charakter problemu jest nieznany – czas wykonywania, rozmiar stanu oraz możliwe błędy to nadal tylko przypuszczenia. Wersja gotowa do użycia w produkcji, zbudowana najpierw, i tak jest zwykle odbudowywana.

Przykład: Proces triażu zgłoszeń obsługi klienta zaczyna się od krótkiego skryptu: czyta on jedno zgłoszenie, prosi model o określenie kategorii i wyświetla odpowiedź. Nie ma żadnego serwera ani bazy danych, a skrypt uruchamia się ręcznie z terminala.

Niech zachowanie będzie konfigurowalne, a nie hardkodowane. Gdy system musi działać inaczej w zależności od różnych danych wejściowych, takich jak grupy klientów, typy dokumentów, języki czy ton komunikacji, należy to rozwiązać poprzez konfigurację, a nie poprzez dodanie kolejnego węzła w kodzie.

Dlaczego: Wariacje szybko się gromadzą, gdy pojawiają się użytkownicy („Czy obsługuje ono francuskie zgłoszenia?”, „Czy konta firmowe mogą mieć bardziej surowy ton?”). W takim przypadku każda zmiana wymaga modyfikacji kodu i wydania nowej wersji, co powoduje kolejki nowych zadań dla programistów, natomiast przy użyciu konfiguracji jest to szybka edycja.

Przykład: Zamiast warunków if/else dla poszczególnych poziomów klientów, instrukcje agenta są tworzone na podstawie małych szablonów tekstowych – jednego podstawowego i jednego na każdy poziom. Dodanie nowego poziomu oznacza dodanie nowego pliku.

Zapisz, czego prototyp jeszcze nie rozwiązuje. Zanim przejdziesz dalej, celowo wymień braki: restarty w trakcie działania, obsługa kilku użytkowników jednocześnie, rejestrowanie błędów, możliwość uruchamiania poza własnym komputerem.

Dlaczego: Brak, który nikt nie odnotował, staje się później niespodzianką, zwykle odkrytą podczas incydentu, a nie podczas rozmowy planistycznej. Odnotowany brak staje się listą kontrolną dla następnego etapu.

Przykład: Krótka tabela z wierszami takimi jak „stan danych znajduje się w słowniku Pythona, więc potrzebne jest trwałe przechowywanie”, „jednocześnie może działać tylko jedna operacja, więc musi być obsługiwane równoczesne wykonywanie zadań” oraz „brak zapisu tego, co się wydarzyło, więc potrzebny jest rejestr audytowy”. Na tym etapie nic nie jest ustalone – elementy są jedynie nazwane.

Etap 2: środowisko testowe i wstępne

Tutaj system po raz pierwszy styka się z rzeczywistą infrastrukturą oraz jej rzeczywistymi problemami. Działa już z laptopa, może być restartowany i może być używany przez kilka osób jednocześnie.

Wybierz środowisko wykonawcze dostosowane do rzeczywistego obciążenia. Przed podjęciem decyzji o miejscu przechowywania agenta sprawdź konkretne dane: maksymalny czas jego działania, koszt pozostawania w stanie bezczynności oraz to, czy zatrzymany proces może kontynuować pracę od miejsca przerwy.

Dlaczego: Obciążenia agentów rzadko przypominają zwykłe żądania internetowe. Jedna sesja może trwać kilka minut i musi przenosić dużo informacji kontekstowych na przestrzeni wielu kroków. Środowisko wykonawcze zaprojektowane do krótkich żądań wykona timeout w trakcie sesji, natomiast takie przeznaczone do ciągłego ruchu będzie zbyt kosztowne dla zadań wykonywanych kilka razy dziennie.

Przykład: Agent do przeglądania dokumentów prawniczych przetwarza sekcje dokumentu po kolei w ramach jednej sesji, aby zachować pełny kontekst, a długi dokument może wymagać od 10 do 15 minut. To wykluczało użycie funkcji bez serwera z ustalonym limitem czasowym. Wykluczało to również zastosowanie zestawu kontenerów stale uruchomionych, ponieważ agent działa zaledwie kilka razy dziennie, a nadmiarowa moc obliczeniowa pozostałaby nie wykorzystana. Długie, nagłe i rzadkie sesje wskazywały na środowisko wykonawcze, które pobiera opłatę tylko za czas rzeczywistego przetwarzania i nie ma limitu czasowego.

Przenieś stan z pamięci do trwałego, współdzielonego magazynu danych. Wszystko, co musi przetrwać restart lub być widoczne dla więcej niż jednego serwera, takie jak status działania, historia rozmów i wyniki w trakcie przetwarzania, powinno znajdować się w rzeczywistym magazynie danych, a nie w zmiennych wewnątrz biegnącego procesu. Wybierz jeden system jako źródło prawdy.

Dlaczego: Stan przechowywany wyłącznie w pamięci znika po restartie procesu, a w środowisku produkcyjnym dzieje się to częściej, niż większość ludzi się spodziewa, ze względu na aktualizacje, awarie i skalowanie. Stan rozproszony między kilkoma magazynami bez wyraźnego właściciela skutkuje sytuacją, w której dwa systemy nie zgadzają się co do tego, co jest prawdą.

Przykład: W tym przypadku agent edytujący dokumenty przechowuje stan procesu, historię rozmów oraz proponowane zmiany w systemie przechowywania obiektów, bez przechowywania żadnych danych w trakcie obsługi żądania. System przechowywania obiektów stanowi jedyny źródło prawdy, natomiast baza danych jest używana do jednego, wąsko określonego zadania: blokady zlecenia, która zapobiega przetwarzaniu tego samego procesu przez dwa urządzenia. Ogólny stan nie jest dzielony pomiędzy oba systemy, a nie istnieją zasady określające, który z nich ma pierwszeństwo.

Załóżmy, że „to zostało przetworzone dwa razy” oraz „te zostały przetworzone jednocześnie”. Większość rzeczywistych systemów komunikacyjnych może wysłać jeden sygnał kilka razy. Prosta kontrola stanu („rozpocznij, jeśli jeszcze nie rozpoczęto”) zawodzi, ponieważ dwa procesy mogą odczytać wartość „jeszcze nie rozpoczęto” przed tym, jak którykolwiek z nich zapisze wartość „rozpoczęto”. Należy polegać na mechanizmie, który zapewnia, że dokładnie jeden z nich będzie miał pierwszeństwo.

Dlaczego: Bez tego dwa procesy mogą powtarzać tę samą kosztowną pracę lub zapisywać sprzeczne wyniki, a błąd pojawia się tylko wtedy, gdy rzeczywiście dochodzi do nakładania się zadań, co rzadko ma miejsce w spokojnym środowisku deweloperskim.

Przykład: Zamek służący do przejmowania zadań w wczesnych wersjach funkcjonował w normalnych warunkach, ale nie mógł zwolnić zadania, jeśli proces, który go trzymał, uległ awarii lub zamarł. W środowisku produkcyjnym skutkowało to nagromadzeniem zadań zamrożonych w stanie „przetwarzanie” na kilka dni, bez żadnej możliwości ich uratowania. Poprawka polegała na dodaniu terminu wygaśnięcia umowy dzierżawy, tokena zapobiegającego pomyleniu odzyskanego procesu z oryginalnym posiadaczem oraz periodycznego skanowania, które przywraca wszystkie zadania, których umowa wygasła, zanim zostały ukończone. To o wiele lepsze rozwiązanie niż proste „przejmij raz”.

Dodaj funkcje śledzenia i rejestracji zdarzeń jeszcze przed tym, zanim wymusi to incydent. Gdy zaangażowane są więcej niż jedne usługi, takie jak warstwa internetowa, kolejka zadań, procesor zadań oraz środowisko działania AI, jedno działanie użytkownika przechodzi przez każdą z nich. Zorganizuj już teraz sposób na śledzenie tej ścieżki pomiędzy usługami, aby nie musieć jej odtwarzać w trakcie awarii.

Dlaczego: Odtwarzanie zdarzeń na podstawie oddzielnych, niespowiązanych zapisów jest powolne i podatne na błędy, szczególnie pod presją. System, którego śledzenie można rozpocząć od samego początku, zamienia stresujące dochodzenie w szybkie wyszukiwanie informacji.

Przykład: System AI miał szczegółowe śledzenie od samego początku, ale usługa dostępna przez internet przed nim go nie posiadała, więc ślad pokazywał wszystko, co robił agent, a nie żądanie, które je wywołało, ponieważ nic nie łączyło tych dwóch elementów. Rozwiązaniem było utworzenie jednego identyfikatora rundy w momencie wysłania żądania i przekazywanie go we wszystkich logach usług, dzięki czemu pojedyncze wyszukiwanie mogło ujawnić pełną ścieżkę danej rundy, mimo że oba systemy śledzenia pozostały oddzielone.

Próbuj prawdziwego klienta jak najszybciej. Gdy użytkownicy dostępują do systemu za pośrednictwem określonego przeglądarki, aplikacji lub urządzenia, sprawdź to rozwiązanie jak najszybciej na tym konkretnym urządzeniu i nie zadowalaj się ogólnym klientem API czy tylko przybliżeniem.

Dlaczego: Prawdziwi klienci mają swoje specyficzne problemy, takie jak ograniczenia długości, ukryte przerywanie działania i nietypowe kodowanie, których nie wykryje narzędzie ogólne. Zazwyczaj ujawniają się one dopiero u rzeczywistych użytkowników, a wtedy stanowią już incydent produkcyjny, a nie problem występujący w środowisku testowym.

Przykład: Funkcja otwierania dokumentów w aplikacji desktopowej przeszła wszystkie testy automatyczne, ale u użytkowników na jednym systemie operacyjnym zawodziła okresowo. Aplikacja w tajemnicy skracała linki do pobierania po przekroczeniu określonej długości, a tymczasowe dane dostępowe używane do podpisywania tych linków sprawiały, że ich długość znacznie przekraczała ten limit. Rozwiązaniem było podpisywanie linków za pomocą odrębnej tożsamości, która generuje znacznie krótszą podpis, zamiast tymczasowych danych używanych przez resztę systemu.

Zgodź ścieżkę sieciową drzwi wejściowych z sposobem łączenia się klientów. Jeśli użytkownicy mają dostęp do systemu tylko przez sieć prywatną, taką jak VPN, proxy typu zero-trust lub sieć dostępną wyłącznie wewnętrznie, upewnij się, że adres, którego używają, faktycznie prowadzi do celu na tej samej prywatnej ścieżce od początku do końca. Domena brzmiąca jak wewnętrzna, która w rzeczywistości odwołuje się do publicznego balansera obciążeń lub CDN, może działać dla niektórych użytkowników, a u innych powodować przerywane problemy.

Dlaczego: Taka niezgodność powoduje niestabilne problemy: u niektórych użytkowników i czasami, więc przypomina to niewiarygodną infrastrukturę, a nie błąd w ustawieniach. Uchodzi to niezauważone, ponieważ może przechodzić przez komputer programisty, który często korzysta z innej trasy sieciowej niż laptop pracownika.

Przykład: Narzędzie wewnętrzne miało być dostępne wyłącznie przez sieć firmową za pośrednictwem proxy opartego na zasadzie zerowego zaufania, który kieruje ruch przez różne łączniki w zależności od wyboru każdego laptopa. Domena tego narzędzia brzmiała jak wewnętrzna, ale w rzeczywistości wskazywała na publiczną sieć dostarczania treści. Niektóre łączniki mogły uzyskać dostęp do tej publicznej adresacji, podczas gdy inne mogły dotrzeć jedynie do adresów prywatnych, przez co awarie pojawiały się i znikały w zależności od używanego łącznika. Rozwiązaniem było umieszczenie bramy wejściowej na balanserze obciążeń wewnątrz sieci prywatnej, dostępnej całym szlakiem, którym korzystają prawdziwi użytkownicy, plus oddzielna, podpisana ścieżka dla jednej aplikacji desktopowej, która w ogóle nie może korzystać z proxy’u.

Stwórz klienta zastępczego, który może uruchamiać cały proces w dowolnym momencie. Jest to skrypt, który wysyła te same żądania i dokonuje tych samych działań co prawdziwy użytkownik, przez tę samą interfejs, dzięki czemu pełne testy można powtarzać bez czekania na ludzkiego testera.

Dlaczego: Procesy realizowane za pomocą agentów rzadko składają się z jednego żądania i jednej odpowiedzi. Obejmują one kilka kroków, wywołania narzędzi oraz aktualizacje przekazywane w czasie rzeczywistym, co utrudnia dokładną weryfikację ręcznie. Samodzielne testy jednostkowe i integracyjne zazwyczaj sprawdzają poszczególne elementy oddzielnie, a nie całą realistyczną sesję. Dzięki fałszywemu klientowi sprawdzenie, czy cała wieloetapowa rozmowa przebiegła pomyślnie, staje się operacją, którą można przeprowadzić w dowolnym momencie.

Przykład: Narzędzie do testowania obciążenia wykonuje te same wywołania API, które używa prawdziwy panel kliencki do rozpoczęcia testu, a następnie sprawdza tabelę stanu, aby dowiedzieć się, kiedy test się zakończy, ponieważ test kończy się później, a pierwsza odpowiedź nic nie mówi o wyniku. Liczba jednoczesnych testów wzrasta stopniowo – od kilku do kilkudziesięciu, a potem ponad stu – przy tym istnieje sztywny limit całkowitej liczby testów i wydanych środków, ponieważ każdy fałszywy test stanowi rzeczywiste wywołanie modelu, za które pobierana jest opłata. Okazało się, że prawdziwym wąskim gardłem pod obciążeniem był dostawca modelu, a nie otaczająca infrastruktura, czego nie udałoby się odkryć, testując poszczególne elementy osobno.

Wybierz moment, w którym osoba może sprawdzić wyniki działania agenta przed ich uwzględnieniem. Zainstaluj miejsce, w którym ktoś może zobaczyć, co agent zamierza zrobić, i może to zatwierdzić, zmienić lub odrzucić, zamiast pozwalać, by wyniki wchodziły w życie same z siebie od pierwszego dnia.

Dlaczego: Błędy agenta różnią się od zwykłych błędów. Wyglądają wiarygodnie, ale są błędne, nie przypominają oczywistego awarii. Ludzka weryfikacja wykrywa błędy, które przechodzą wszystkie automatyczne kontrole, i buduje historię działań potrzebną do późniejszego określenia, gdzie agent może bezpiecznie działać bez nadzoru.

Przykład: Agent do edycji dokumentów nigdy nie zapisuje zmian bezpośrednio do końcowego dokumentu. Proponuje sugestie, które recenzent może zaakceptować, zmodyfikować lub odrzucić indywidualnie, więc nic z tego, co wygeneruje, nie ma znaczenia, dopóki ktoś nie podjął decyzji.

Etap 3: przedprodukcja

To ostatnie środowisko przed rzeczywistymi użytkownikami. Pytanie zmienia się z „czy funkcja działa?” na „czy cały proces nadal funkcjonuje, gdy warunki nie są idealne?”. Obejmuje to powtarzane wdrożenia, częściowe przerwy w działaniu oraz zmiany wynikające ze zastąpienia modelu lub instrukcji używanych do jego działania.

Stwórz właściwą ocenę, ponieważ samo zdanie lub niezdanie nie wystarcza. Zdecyduj, co oznacza „dobrze” w kontekście wyniku działania agenta – zazwyczaj chodzi o kilka kryteriów (działanie na podstawie właściwych danych wejściowych, rzetelna poprawność, spójność pomiędzy kolejnymi wykonyaniami) – oraz kto lub co ma sprawdzać każde z tych kryteriów: stała zasada, ludzki recenzent czy oddzielny model pełniący rolę sędziego.

Dlaczego: Wynik działania agenta rzadko jest po prostu prawidłowy lub błędny, tak jak w przypadku stwierdzeń w testach jednostkowych. Jedynie sygnał zdanie/niezdanie nie ujawnia, która część funkcjonowania agenta się pogorszyła, a metoda oceny, której nikt dokładnie nie sprawdził, szczególnie jeśli jest to automatyczny sędzia, może po cichu odbiegać od tego, co jest ważne dla osób korzystających z tego wyniku.

Przykład: Agent służący do tworzenia streszczeń jest oceniany według trzech kryteriów: zakresu omówionych kluczowych faktów, obecności jakiejkolwiek wymyślonej treści, której nie ma w źródle, oraz stopnia różnic w wynikach uzyskiwanych przy dwóch uruchomieniach na tym samym wejściu. Osoba sprawdza próbkę pod kątem „wymyślenia czegoś”, ponieważ błąd w tym aspekcie kosztuje najwięcej.

Uruchom agenta ponownie na ustalonej grupie dobrze znanych przykładów. Zachowaj małą, niezmienianą kolekcję wejść z zatwierdzonymi wynikami i uruchamiaj agenta przy każdym wdrożeniu, szczególnie po jakiejkolwiek zmianie w promptzie lub modelu.

Dlaczego: W odróżnieniu od zwykłego kodu zachowanie agenta może się subtelnie zmieniać po niewielkiej modyfikacji promptu lub aktualizacji modelu, a żaden test nie wykryje błędu. Ustalona grupa przykładów jest często jedynym elementem, który może zauważyć, że „agent działa poprawnie, ale jakość wyników stopniowo się pogarsza”.

Przykład: Agent edytujący dokumenty jest sprawdzany na ustalonej serii przykładów na trzy sposoby: czy wybrał właściwe sekcje do edycji (w porównaniu z kluczem odpowiedzi sprawdzonym przez człowieka), czy proponowane przez niego zmiany były poprawne (oceniane przez oddzielny model sędziego) oraz o ile wynik jego pracy różni się przy identycznych danych wejściowych w różnych próbach. Monitorowanie wszystkich trzech kryteriów w poszczególnych wersjach, a nie tylko jednego wyniku „udane/nieudane”, pokazało, że jedna zmiana poprawiła jeden wskaźnik, ale jednocześnie negatywnie wpłynęła na inny.

Niech nieudana kontrola zatrzyma wypuszczenie produktu. Zestaw testów, w którym niepowodzenie nadal pozwala na wdrożenie, jest jedynie komentarzem. Należy połączyć wyniki z procesem wdrażania tak, aby niepowodzenie zatrzymywało go, a obejście tego mechanizmu nie było standardem.

Dlaczego: Jeśli możliwe jest pominięcie jakiegoś etapu bez żadnych konsekwencji, zazwyczaj pod presją terminów to się dzieje, a wtedy uszkodzone zmiany najczęściej przechodzą do fazy wdrożenia.

Przykład: Konfiguracja pipeline’a jest tak ustawiona, że jeśli któryś test się nie powiedzie, krok implementacji nigdy nie zostanie wykonywany. Nie ma przycisku „zrealizuj mimo wszystko”, a obejście tego wymaga świadomej zmiany konfiguracji pipeline’a, a nie kliknięcia w ostrzeżenie.

Celowo wyłącz szybką ścieżkę i upewnij się, że system funkcjonuje prawidłowo nawet w gorszych warunkach. Jeśli wyniki są zwykle przekazywane przez szybką ścieżkę, taką jak cache, żyła połączenia lub kolejka, celowo ją wyłącz i sprawdź, czy wolniejsza alternatywa nadal działa, zamiast aby funkcja po prostu przestała działać.

Dlaczego: Cache’y, żyłe połączenia i podobne skróty to elementy, które najczęściej zawodzą w środowisku produkcyjnym. Bez alternatywy niewielki awaria w jednym małym komponencie może doprowadzić do wyłączenia całej funkcji.

Przykład: Aktualizacje zazwyczaj przychodzą w ciągu sekundy przez połączenie typu push. W teście z wyłączonym tym połączeniem system sprawdza stan co kilka sekund – to wolniejsza metoda, która mimo to pokazuje użytkownikowi wyniki.

Niech narzędzia zapewniają właściwą kolejność, gdy jedna rzecz musi istnieć przed drugą. Jeśli element A musi być przygotowany, zanim będzie można skonfigurować element B, umieść tę sekwencję w procesie wdrażania, a nie w pamięci jakiejś osoby.

Dlaczego: Zasada taka jak „wdrożyć X przed Y” obowiązuje tylko do chwili, gdy osoba, która ją zna, jest nieobecna lub ktoś zautomatyzuje proces, nie znając jej. Sekwencje, które są istotne, powinny znajdować się w narzędziach.

Przykład: Usługa orkiestracji wymaga identyfikatora środowiska wykonawczego AI stworzonego przez inną stertę implementacji, a gdyby każda sterta odwoływała się do drugiej, powstałby cykl. Dlatego sterta środowiska wykonawczego zapisuje swój identyfikator w wspólnym magazynie parametrów po jego utworzeniu, a sterta orkiestracji odczytuje go stamtąd. Gwarantuje się, że środowisko wykonawcze istnieje najpierw, a sterty nigdy nie odwołują się do siebie.

Etap 4: brama produkcyjna

Ostatnia lista kontrolna pojawia się przed tym, jak rzeczywiści użytkownicy zaczną korzystać z systemu. Kwestia poprawności powinna być już rozstrzygnięta. Pozostaje potwierdzenie, że to, co trafia do użytkowników, to dokładnie to, co zostało przetestowane, oraz że błędy można naprawić i wyjaśnić.

Wysyłaj dokładnie ten artefakt, który był testowany. Użyj wersji programu, która przeszła testy przedprodukcyjne, i przypisz jej nową etykietę przeznaczoną do produkcji, zamiast kompilować nową kopię w ostatnim kroku.

Dlaczego: Przeprowadzenie ponownej kompilacji w ostatniej chwili, nawet z „tego samego” źródła, może skutkować użyciem innej wersji zależności, innego datownika lub innych ustawień środowiskowych. Ta różnica oznacza, że w produkcji uruchamiany jest produkt, który nigdy tak naprawdę nie został przetestowany.

Przykład: Aplikacja zapakowana, która przeszła wszystkie testy przedprodukcyjne, jest po prostu ponownie oznaczona jako wersja produkcyjna i wysyłana w takim stanie, bez zmian – to ten sam plik, a nie nowa wersja skompilowana z tego samego kodu.

Zdecyduj z góry, dokąd trafiają powtarzające się błędy i jak długo są przechowywane. Ustal sztywny limit prób ponownych, wybierz miejsce, gdzie powinny trafiać błędy po przekroczeniu tego limitu, oraz określ czas ich przechowywania.

Dlaczego: Bez limitu uszkodzona operacja może próbować się wykonać w nieskończoność, cichutko zużywając zasoby lub blokując kolejkę. Bez określonego miejsca przechowywania błędna operacja po prostu znika, a nikt nie może podjąć żadnych działań wobec błędu, którego nie może zobaczyć.

Przykład: Zadanie, które zawodzi trzy razy, jest automatycznie przenoszone do osobnego obszaru przechowywania i nie jest ponawiane w nieskończoność. Zachowuje się je przez dwa tygodnie, co daje inżynierowi czas na jego wykrycie i zbadanie.

Zaplanuj już ścieżkę audytową. Jeśli decyzje systemu mogą wymagać późniejszego wyjaśnienia dla użytkownika, audytora lub kolegi, ustal z góry, co jest rejestrowane i jak to znaleźć.

Dlaczego: „Dodamy odpowiednie rejestrowanie później” prawie nigdy się nie dzieje, gdy nadchodzą rzeczywiste terminy, a gdy potrzeba staje się oczywista, brakującej historii nie da się odtworzyć z góry.

Przykład: Każda automatyczna decyzja jest zapisywana jako osobny zapis z datą i godziną. Jeśli ktoś później zapyta, dlaczego system postąpił w określonym przypadku, istnieje pisemna odpowiedź, na którą można się powołać, zamiast zgadywać.

Zapisz każdy rzeczywisty incydent, a nie tylko informację o naprawie. Po nieoczekiwanym awarii zarejestruj przyczynę podstawową oraz rozwiązanie, aby zespół mógł je później znaleźć – to znaczy coś więcej niż zamykany ticket lub wątek w czacie.

Dlaczego: Naprawa nieudokumentowana zostanie ponownie opracowana od zera przez kogoś innego, zazwyczaj pod większym naciskiem. Krótka notatka jest często najtańszym sposobem na uniknięcie ponownego przeprowadzania wielogodzinnych dochodzeń.

Przykład: Pewna seria zadań przez kilka dni pozostawała w stanie częściowo przetworzonym, ponieważ nic nie przywracało ich automatycznie. Przyczyna, rozwiązanie oraz uzasadnienie tych działań zostały zapisane w osobnym dokumencie, oddzielnie od poprawki kodu. Później ponowne zbadanie sprawy doprowadziło do rewizji wcześniejszych wniosków – początkowo przypisywano winę modelowi za wymyślanie informacji – a po dokładniejszej analizie okazało się, że prawdziwa przyczyna była subtelniejsza, niż się początkowo sądziło. Ta aktualizacja również została udokumentowana, dzięki czemu pierwotny, mniej dokładny wniosek stracił na ważności.

Wzorzec ukryty za listą kontrolną

Niewiele z tego jest specyficzne dla sztucznej inteligencji. To są nawyki niezbędne w każdym systemie rozproszonym: trwały stan danych, bezpieczne radzenie sobie z powtórzeniami zadań, możliwość śledzenia tego, co się wydarzyło i dlaczego, oraz proces wypuszczania produktu, który zawiera to, co zostało przetestowane.

Agent zmienia miejsce, w którym znajduje się ryzyko. Wykonania są dłuższe i zawierają więcej kontekstu, więc obliczenia muszą temu odpowiadać. Wykonanie może zawieść lub odbiec w sposób, który umyka zwykłym testom, dlatego sprawdzania regresji na dobrze znanych przykładach mają większe znaczenie. Prędzej czy później ktoś zapyta „dlaczego tak się stało?”, a ślad audytowy musi być w stanie na to odpowiedzieć.