Oprogramowanie z modelem wymaga nadzoru nad wynikiem, nie tylko utrzymania

Stan systemu i jakość wyniku

Każde oprogramowanie w produkcji wymaga patrzenia, jak działa: metryki, logi, alerty, ktoś, kto reaguje. To nie zaczęło się od modeli i nie skończy się razem z nimi.

Różnica przy modelu jest różnicą stopnia, nie rodzaju. W programie deterministycznym wynik jest w dużej mierze sprawdzalny maszynowo — porównujesz go z oczekiwanym, test przechodzi albo nie, a sygnały operacyjne zwykle idą w parze z poprawnością. W systemie z modelem większość wyników nie ma takiego testu. Odpowiedź może wyglądać poprawnie, przejść wszystkie kontrole formatu i schematu, a być błędna — i jedynym sprawdzeniem, jakie ją złapie, jest przeczytanie jej.

To jest cała różnica: monitoring pilnuje, żeby system działał, a nie tego, czy to, co zwrócił, ma sens.

Trzy źródła niepewności

Rozdzielmy trzy źródła niepewności: próbkowanie, wejście w języku naturalnym i aktualizacje modelu przez dostawcę. Żadne z nich nie występuje automatycznie razem z pozostałymi, a każde wymaga innego środka.

**Próbkowanie.** To samo żądanie może dać inną odpowiedź przy kolejnym uruchomieniu — zachowanie jest rozkładem, nie funkcją. Dotyczy to ustawień, w których próbkowanie jest włączone; przy temperaturze bliskiej zera i ustalonym schemacie odpowiedzi problem jest mały, choć nie znika: rozkład nigdy nie jest punktem.

**Zakres wejścia.** Wejście w języku naturalnym dopuszcza przypadki, których projekt nie przewidział. Występuje tam, gdzie wejściem jest swobodny tekst; przy ściśle walidowanym formularzu zakres jest tak wąski jak w każdym innym programie.

**Zmiana bez zmiany w twoim kodzie.** Dostawca aktualizuje wersję modelu, z której korzystasz. Kod się nie zmienił, nie było nowego wdrożenia, a program zachowuje się inaczej. Dotyczy to wdrożeń, w których model przychodzi od zewnętrznego dostawcy. Przy wagach uruchomionych u siebie ten problem znika — kosztem tego, że za aktualizacje, jakość i bezpieczeństwo odpowiadasz sam.

Co ustalają testy

Zestaw testów nad deterministycznym kodem ustala coś o sprawdzonych przypadkach, w granicach specyfikacji; nie daje dowodu, że całe zachowanie jest poprawne. Nad modelem ustala dokładnie to samo, z dwiema różnicami. Pierwsza: wynik dotyczy konkretnej wersji modelu, a ta wersja nie jest częścią twojego repozytorium ani twojego wdrożenia — o ile model nie działa na twoich wagach. Druga: przy próbkowaniu to samo wejście może wypaść inaczej w kolejnym przebiegu, więc jeden zielony test nie opisuje zachowania, tylko jedną jego próbkę.

Zmienia się kształt awarii

W starym świecie rzadkie wejście uruchamiało błąd w kodzie, którego intencję nadal znaliśmy: wiedzieliśmy, co program miał zrobić, i widzieliśmy, gdzie się pomylił. Tutaj awarie przychodzą jako zachowania, których nikt nie przewidział. Sformułowanie, którego projektant nie wyobraził sobie, gdy pisał instrukcje. Decyzja, która brzmi wiarygodnie i jest błędna. Przypadek, dla którego w projekcie nie ma miejsca.

Kodu nie da się przejrzeć pod kątem przypadku, którego nie umiesz sobie wyobrazić. Takie przypadki wychodzą z ruchu: na produkcji, w testach z użytkownikami, w rozmowie, która pokazuje, że ludzie używają programu inaczej, niż zakładaliśmy.

Po co kadencja, a nie tylko reakcja

Praca nad systemem z modelem przenosi się z „napraw, gdy padnie" na „czytaj wynik, gdy działa": obserwacja działającej aplikacji, wychwytywanie tego, co faktycznie się wydarzyło, dokładanie tych przypadków do zestawu testów lub ewaluacji i powtarzanie.

Reakcja na awarię nie wystarcza, bo przy modelu awaria nie ogłasza się sama. Nie ma wyjątku, logu z błędem ani spadku, który przyciągnie wzrok — jest odpowiedź, która wygląda poprawnie i jest zła. Żeby ją znaleźć, trzeba czytać wyniki, a czytanie wyników ma sens tylko wtedy, gdy robi się je regularnie: jednorazowy przegląd mówi coś o dniu, w którym go zrobiono.

Kadencja nie jest jednak uniwersalna i nie ma jednej właściwej. Wyznacza ją szkoda, jaką robi błędna odpowiedź, i to, po jakim czasie jej skutki stają się widoczne. Inna będzie dla systemu, który podpowiada operatorowi, a inna dla takiego, który sam wysyła dokumenty.

Zakres tej zmiany jest przy tym węższy, niż brzmi. Routing, przechowywanie danych, ponowienia, kontrakty i narzędzia, które model wywołuje, pozostają deterministyczne i można je sprawdzać dotychczasowymi metodami. Nadzoru wymaga przede wszystkim zachowanie modelu i sposób, w jaki reszta aplikacji korzysta z jego odpowiedzi — bo deterministyczna otoczka wygląda jak cały program.

Uczciwy kontrargument

Na każde z trzech źródeł niepewności istnieje częściowe lekarstwo i żadne nie zamyka sprawy.

Temperatura zero, dekodowanie z ograniczeniami i pamięć podręczna odpowiedzi zawężają rozrzut odpowiedzi, ale nie zwężają zakresu wejścia. Logi pozwalające odtworzyć przebieg dają możliwość powtórzenia konkretnego przypadku, nie pewność co do następnego — a przy próbkowaniu powtórzenie nie zawsze daje ten sam wynik. Twarde procedury awaryjne na krytycznych ścieżkach chronią deterministyczną otoczkę, nie model.

Żadna z tych technik nie rozwiązuje jednak problemu zmiany modelu przez dostawcę: repozytorium pozostaje nietknięte, a zachowanie się przesuwa.

Zostaje też pytanie, kto ma czytać wynik. Część monitoringu i przygotowywania przypadków testowych można oddać modelom, ale wtedy trzeba odpowiedzieć na trudniejsze pytanie: czy agent, który decyduje, co jest usterką, jest wystarczająco wiarygodny, żeby tę decyzję podjąć samodzielnie.

Co to znaczy dla twojej firmy

Jeśli budżetujesz wdrożenie AI jako jednorazowy koszt, w tym budżecie brakuje miejsca na nadzór nad wynikami — czyli na pracę, która nie kończy się przy wdrożeniu. To nie jest dodatek do projektu; to pozycja, która zostaje po jego zakończeniu.

Ustal też dwie rzeczy, z których pierwsza jest kryterium, a druga osobą. Kryterium: jaka odpowiedź jest nieakceptowalna i co się dzieje, gdy system taką zwróci — czy zatrzymuje proces, czy tylko zapisuje zdarzenie. Osoba: kto to czyta i kto ma prawo zatrzymać system, gdy wyniki przestaną się zgadzać.

Bez tych dwóch odpowiedzi nadzór jest deklaracją. System działa, dopóki ktoś nie zauważy czegoś przypadkiem — a wtedy zwykle zauważa to klient, nie zespół.