Testy regresyjne przed podmianą modelu AI: przypadki z oczekiwanymi decyzjami, które blokują wdrożenie

Kto skorzysta z tego przewodnika.

• CTO i wiceprezesi ds. inżynierii, którzy dostali zapowiedź wycofania modelu stojącego za funkcją produkcyjną i muszą przed tą datą wiedzieć, co zamiennik zrobi inaczej
• Zespoły platformowe, które wywołują modele przez alias albo tag latest i widziały zmianę zachowania bez żadnego wdrożenia w swojej historii
• Właściciele agentów, którzy rezerwują, anulują, zwracają pieniądze albo odmawiają w imieniu klienta, gdzie zmieniona decyzja to zmieniona transakcja
• Zespoły, od których dział finansów chce przejścia na tańszy model, a które nie umieją powiedzieć, czego tańszy model przestanie robić

Co zmienia podmiana modelu i dlaczego przykładowe odpowiedzi tego nie pokazują

Agent na produkcji to pętla decyzji: czy wywołać narzędzie, które, z jakimi argumentami, czy zapytać użytkownika, czy odmówić, czy się zatrzymać. Tekst, który zwraca, jest ostatnim krokiem. Po podmianie recenzent czyta właśnie tekst, a tekst nowszego modelu zwykle czyta się lepiej: czyściej, pewniej, z lepszym formatowaniem. Regresja dotyczy decyzji. Dwa przykładowe scenariusze: po podmianie agent po cichu przestaje anulować zamówienia; model zastępczy, poproszony o sprawdzenie dostępności, sam rezerwuje spotkanie. W obu odpowiedzi wyglądają dobrze, a skutek w systemie jest błędny.

Badania nad ewaluacją agentów doszły do tego samego miejsca. Yao i współautorzy (2024), autorzy tau-bench, oceniają agenta przez porównanie stanu bazy na końcu rozmowy z opisanym stanem docelowym i wprowadzili miarę pass^k, prawdopodobieństwo, że agent zaliczy wszystkie k z k powtórzeń zadania, bo pojedynczy przebieg ukrywa niespójność. Ich najlepszy agent w tamtym czasie zaliczał poniżej 50% zadań i miał pass^8 poniżej 25% w domenie handlu. Testy, które oceniają końcowy tekst według zasad oceny, mierzą złą warstwę. Musi sprawdzać decyzję i stan końcowy oraz uruchamiać każdy przypadek więcej niż raz.

Dryf wyniku i dryf wykonania

Dryfem nazywa się dwie różne rzeczy i potrzebują one różnych kontroli. Dryf wyniku to model dający inną decyzję na tym samym wejściu, bo model się zmienił: migracja po wycofaniu, podmiana na tańszy poziom, alias, który wskazuje teraz gdzie indziej. Dryf wykonania to ten sam identyfikator modelu dający inne zachowanie, bo zmieniło się coś za identyfikatorem. Chen, Zaharia i Zou (2023) zmierzyli zachowanie tej samej usługi GPT-4 w marcu i czerwcu 2023 i stwierdzili spadek skuteczności w rozpoznawaniu liczb pierwszych z 84% do 51%, z gorszym wykonywaniem instrukcji i większą liczbą błędów formatowania w generowanym kodzie. Własna dokumentacja OpenAI do parametru seed mówi, że determinizm jest zapewniany w miarę możliwości, a pole system_fingerprint, które reprezentuje konfigurację zaplecza, z jaką działa model, zmienia się, gdy dostawca aktualizuje konfigurację numeryczną infrastruktury serwującej model.

Obejście stosowane przez praktyków to logowanie identyfikatora modelu i danych o konfiguracji zaplecza (fingerprint), jeśli API je udostępnia, oraz alarm przy zmianie. To dobra kontrola obserwowalności i jej miejsce jest w warstwie śledzenia, obok kosztu i opóźnienia na wywołanie. Zestaw testów regresyjnych to inny instrument. Log mówi tylko tyle, że coś się zmieniło, nic o tym, co agent robi teraz inaczej. Milczy też, gdy identyfikator jest bez zmian, a zachowanie i tak się przesuwa. Na to pytanie odpowiadają testy; zalogowany identyfikator mówi, kiedy uruchomić je poza cyklem wydań, a stały rytm uruchomień pokrywa zmiany bez żadnego sygnału.

Jak trzej główni dostawcy wycofują modele

Okresy wyprzedzenia i mechanika aliasów różnią się między dostawcami, a te różnice decydują, jak duża część migracji jest pod kontrolą zespołu. Tabela streszcza, co dokumentacja każdego dostawcy wskazana w źródłach podaje w dniu publikacji tej strony; konkretne daty się zmieniają i nie są tu powtarzane, a zakres każdej deklaracji trzeba sprawdzić u dostawcy przed migracją.

Testy: przypadki, oczekiwane decyzje, tolerancja, próg

Przypadek to zapisana prawdziwa interakcja: wejście, odpowiedzi narzędzi odtwarzane z nagrania, żeby środowisko się nie zmieniało, oczekiwana decyzja, oczekiwane wywołania narzędzi z istotnymi argumentami oraz stan końcowy. Przypadki pochodzą ze śladów produkcyjnych albo, przed pierwszym uruchomieniem, ze scenariuszy testowych, warstwowanych tak, żeby obecne były te rzadkie i kosztowne: odmowy, działania nieodwracalne, eskalacje do człowieka, przypadki brzegowe z poprzednich incydentów. Każdy przypadek ma tolerancję. Przypadek anulowania nie toleruje zmiany decyzji ani zmiany identyfikatora zamówienia przekazanego do narzędzia; przypadek streszczenia toleruje inne sformułowanie i sprawdza tylko, czy pojawiają się nazwane fakty. Kryteria tekstowe, które wymagają modelu oceniającego, dostają go, a ten sędzia potrzebuje własnej kalibracji wobec ocen ludzi, która jest tematem osobnego przewodnika na tej stronie i nie jest tu powtarzana.

Próg jest zapisywany przed przebiegiem, dla każdej klasy przypadków, a nie po przeczytaniu diffu. Klasy z działaniami nieodwracalnymi dostają zerową tolerancję: każda decyzja niezgodna z oczekiwanym wynikiem blokuje wdrożenie. Klasy z odwracalnymi skutkami dostają udział przypadków, które mogą się zmienić, uzgodniony z właścicielem danego przepływu. Każdy przypadek uruchamia się kilka razy na każdym modelu, więc porównanie to pass^k wobec pass^k; raport porównuje skuteczność i powtarzalność obu modeli z uzgodnionymi progami, a przypadek niespójny na nowym modelu i spójny na starym liczy się jako regresja, bo agent działa w imieniu klienta. Kapoor i współautorzy (2024) argumentują, że ewaluacja agentów bez kosztu jest niepełna, a benchmarki bez zbiorów odłożonych ulegają przeuczeniu; testy raportują koszt i opóźnienie dla każdego przypadku obok diffu decyzji, a wycinek przypadków jest odłożony poza zasięg każdego, kto stroi prompt pod nowy model.

• Wyzwalacze: zmiana modelu albo wersji, zmiana promptu, zmiana schematu albo opisu narzędzia, zmiana identyfikatora modelu albo konfiguracji zaplecza zalogowana na produkcji oraz stały rytm uruchomień niezależny od tych zdarzeń.
• Diff dla każdego przypadku: oczekiwana wobec zaobserwowanej decyzji, wywołania narzędzi i argumenty, stan końcowy, tokeny i koszt, opóźnienie, spójność między powtórzeniami.
• Bramka: próg dla każdej klasy przypadków uzgodniony na piśmie przed pierwszym przebiegiem; po jego przekroczeniu zadanie CI kończy się błędem i podmiana nie idzie dalej.
• Pułapka pewności siebie: tekst nowego modelu jest ukryty przed recenzentami, dopóki nie przeczytają diffu decyzji, żeby pewniejszy ton nie został wzięty za lepszą decyzję.

Procedura podmiany i ścieżka powrotu

Zapowiedź wycofania uruchamia procedurę, która już istnieje. Zbiór przypadków jest zamrażany w dniu zapowiedzi i oznaczany identyfikatorem wersji starego modelu, a wyniki starego modelu na nim są zapisywane jako punkt odniesienia, dopóki stary model jeszcze odpowiada. Zamiennik uruchamia się na tym samym zamrożonym zbiorze; raport diff idzie do właściciela każdego przepływu z dołączonymi przypadkami, które nie przeszły. Zmiany promptu robione pod nowy model są wersjonowane osobno i przechodzą przez testy jeszcze raz, bo poprawka promptu dla jednej klasy przypadków często przesuwa inną. Podmiana wchodzi za przełącznikiem, który do dnia wycofania może wskazać z powrotem stary model, więc regresja znaleziona na produkcji ma powrót przez zmianę konfiguracji, bez hotfixa.

Po dacie wycofania nie ma dokąd wrócić i to jest argument za rozpoczęciem w dniu zapowiedzi, a nie tydzień przed terminem. Procedura wskazuje też, kto obserwuje strony dostawców o wycofaniach i noty wydań, w jakim rytmie i gdzie trzymane są następne znane daty. Przy kolejnej migracji zespół korzysta z istniejących testów, progów i procedury.

Co może pójść nie tak i co z tym robimy.

1. 1
   Podmiana sprawdzona na jakości tekstu, a zmienia się decyzja

   Zespół porównuje przykładowe odpowiedzi starego i nowego modelu, czyta nowe jako czystsze i lepiej ułożone, po czym wdraża. Przypadków, w których agent powinien był zapytać, odmówić albo się zatrzymać, nie ma w próbce, albo są, ale recenzent czyta prozę zamiast wywołania narzędzia. Anulowanie, które już nie następuje, albo spotkanie zarezerwowane zamiast sprawdzone, znajduje klient.

   Co z tym robimy

   Zapisujemy oczekiwaną decyzję, wywołania narzędzi i stan końcowy dla każdego przypadku, a diff liczy się na tych polach, zanim ktokolwiek przeczyta tekst. Przypadki z klas z działaniami nieodwracalnymi są nadpróbkowane ze śladów produkcyjnych. Recenzent widzi najpierw diff decyzji, a tekst dopiero potem.

   Co zostaje u was: zbiór przypadków z oczekiwanymi decyzjami i wywołaniami narzędzi dla każdego przypadku oraz raport diffu decyzji dla każdej podmiany z dołączonymi przypadkami, które nie przeszły
2. 2
   Alias się przesunął, a nikt niczego nie wdrożył

   Aplikacja wywołuje model przez alias albo tag latest. Dostawca kieruje alias na nowe wydanie, w deklarowanym okresie wyprzedzenia albo, przy zmianach konfiguracji zaplecza, bez żadnego wyprzedzenia. Zachowanie zmienia się w dniu bez wdrożenia w historii zespołu, a dochodzenie zaczyna się w kodzie aplikacji. Chen, Zaharia i Zou (2023) udokumentowali, jak zachowanie tego samego endpointu przesunęło się znacząco w ciągu trzech miesięcy.

   Co z tym robimy

   Przypinamy model do stałej wersji tam, gdzie dostawca ją oferuje, logujemy do warstwy śledzenia identyfikator modelu i dane o konfiguracji zaplecza (jeśli API je zwraca) i dodajemy alarm przy zmianie. Zmieniony identyfikator uruchamia przebieg testów poza cyklem wydań, więc zespół widzi diff decyzji zaraz po przebiegu, a nie objaw kilka tygodni później.

   Co zostaje u was: przypięta wersja w konfiguracji, pola identyfikatora i konfiguracji zaplecza w każdym śladzie oraz alarm podpięty pod zaplanowany przebieg testów
3. 3
   Nowszy model brzmi pewniej, więc jest czytany jako lepszy

   Jeden inżynier przepuszcza garść promptów przez oba modele i woli nowy, bo mniej się asekuruje i lepiej formatuje. Pewność siebie w tekście zostaje wzięta za dowód lepszej decyzji. W przypadku opisywanym przez praktyków pewniejszy model poszedł o krok dalej niż proszono i zarezerwował spotkanie; ton był powodem, dla którego nikt tego nie zakwestionował.

   Co z tym robimy

   Liczymy wskaźnik zaliczeń na poziomie decyzji i spójność między powtórzeniami dla każdej klasy przypadków, z tekstem ukrytym, dopóki diff nie zostanie przeczytany. Tam, gdzie nowy model działa poza tym, o co prosił przypadek, przypadek nie przechodzi niezależnie od tego, jak czyta się odpowiedź, a ustalenie trafia do pracy nad promptem dla nowego modelu z dołączonym przypadkiem.

   Co zostaje u was: wskaźnik zaliczeń i pass^k dla każdej klasy dla obu modeli na tym samym zamrożonym zbiorze, przejrzane przed jakimkolwiek tekstem odpowiedzi
4. 4
   Próg ustalony po poznaniu wyniku

   Testy się uruchamiają, nowy model zalicza 92% przypadków, a na tym samym spotkaniu 90% zostaje uznane za akceptowalne. W tych 8% są dwa przypadki odmowy i jeden zwrot pieniędzy, których nikt nie ogląda z osobna, bo wynik łączny przeszedł. Próg ustalony po wyniku niczego nie blokuje.

   Co z tym robimy

   Próg dla każdej klasy przypadków zapisujemy z właścicielem każdego przepływu przed pierwszym przebiegiem, a klasy z działaniami nieodwracalnymi dostają zerową tolerancję. Zadanie CI nie przechodzi przy każdej klasie ponad jej progiem i wypisuje przypadki, które nie przeszły, według klas, więc przypadek zwrotu nie schowa się za setką zaliczonych streszczeń.

   Co zostaje u was: rejestr progów dla każdej klasy przypadków z właścicielem i datą oraz zadanie CI, które kończy się błędem po ich przekroczeniu
5. 5
   Testy uruchamiają się tylko przy zmianach modelu, a edycja narzędzia przechodzi bokiem

   Programista zmienia kolejność listy narzędzi, nazwę parametru albo opis narzędzia w ramach niezwiązanego zgłoszenia. Wybór narzędzia przez model zależy od tych opisów, więc agent zaczyna wybierać inne narzędzie na tym samym wejściu. Model się nie zmienił, więc testy nie zostały uruchomione, a regresja zostaje przypisana modelowi przy następnej podmianie.

   Co z tym robimy

   Liczymy jeden skrót z wersji modelu, promptu i schematów narzędzi razem i uruchamiamy testy, gdy zmieni się którekolwiek z trzech, w tym samym zadaniu CI. Raport diff mówi, które z trzech zmieniło się od punktu odniesienia, więc przyczyna jest w raporcie, a nie w bisekcji.

   Co zostaje u was: łączny skrót modelu, promptu i narzędzi zapisany przy każdym przebiegu testów oraz wyzwalacz CI na każde z nich

Co zostaje u was.

• Zbiór przypadków: prawdziwe interakcje ze śladów produkcyjnych z odtwarzanymi nagraniami narzędzi, oczekiwaną decyzją, oczekiwanymi wywołaniami narzędzi i argumentami, oczekiwanym stanem końcowym i tolerancją dla każdego przypadku, warstwowany według klas i wersjonowany ze skrótem modelu, promptu i narzędzi
• Rejestr progów: jeden wiersz na klasę przypadków z tolerancją, właścicielem i datą uzgodnienia, wpięty w zadanie CI jako bramka blokująca
• Raport diff dla każdej podmiany: różnice decyzji, wywołań narzędzi, stanu końcowego, kosztu i opóźnienia między punktem odniesienia a kandydatem, pass^k dla każdej klasy, dołączone przypadki, które nie przeszły, tekst odpowiedzi ukryty do przeczytania diffu
• Zadanie CI, które uruchamia testy przy zmianie modelu, promptu albo narzędzi, przy zmianie identyfikatora zalogowanej na produkcji oraz w stałym rytmie, z łącznym skrótem zapisanym dla każdego przebiegu
• Pola śledzenia dla identyfikatora modelu i danych o konfiguracji zaplecza, jeśli API je udostępnia, z alarmem przy zmianie i zaplanowanym przebiegiem testów za nim
• Procedura na wycofanie: kto obserwuje które strony dostawców i w jakim rytmie, kroki zamrożenia i punktu odniesienia w dniu zapowiedzi, przełącznik wskazujący z powrotem stary model do dnia jego wycofania oraz ścieżka powrotu

Jak pracujemy.

1. 1
   1. Klasy przypadków i rejestr progów

   Mapujemy z wami decyzje i narzędzia agenta, nazywamy klasy przypadków i zapisujemy tolerancję oraz właściciela dla każdej klasy przed jakimkolwiek przebiegiem. Działania nieodwracalne, odmowy i eskalacje dostają własne klasy z zerową tolerancją. To dokument, który bramka będzie egzekwować.

   Tydzień 1
2. 2
   2. Zbiór przypadków ze śladów produkcyjnych

   Pobieramy prawdziwe interakcje z waszych śladów albo, przed pierwszym uruchomieniem, scenariusze testowe, warstwowane według klas, nagrywamy odpowiedzi narzędzi dla identycznego odtworzenia środowiska i oznaczamy oczekiwaną decyzję, wywołania narzędzi i stan końcowy dla każdego przypadku razem z właścicielami przepływów. Wycinek odłożony trzymamy poza zasięgiem każdego, kto stroi prompty.

   Tydzień 1-3
3. 3
   3. Punkt odniesienia i pierwszy diff

   Uruchamiamy obecny model kilka razy na każdym przypadku, żeby zapisać punkt odniesienia i pass^k dla każdej klasy, a potem model kandydujący na tym samym zamrożonym zbiorze. Pierwszy raport diff idzie do właścicieli przepływów z przypadkami, które nie przeszły, oraz kosztem i opóźnieniem dla każdej klasy.

   Tydzień 3-4
4. 4
   4. Wpięcie w CI i wykrywanie zmian w działającym systemie

   Dodajemy testy jako zadanie CI wyzwalane łącznym skrótem modelu, promptu i narzędzi oraz stałym rytmem, dodajemy pola identyfikatora i konfiguracji zaplecza do waszych śladów z alarmem i zaplanowanym przebiegiem za nim oraz umieszczamy w konfiguracji przełącznik modelu ze ścieżką powrotu.

   Tydzień 4-5
5. 5
   5. Procedura na wycofanie i przekazanie

   Piszemy procedurę z waszym zespołem: kto obserwuje strony dostawców, co się dzieje w dniu zapowiedzi i jak podmiana wchodzi i wraca. Przeprowadzamy z wami jedną podmianę od początku do końca na testach i zostawiamy zbiór przypadków, rejestr i format raportu w waszym repozytorium.

   Tydzień 5-6, zależnie od liczby przepływów

Pozostałe strony z tej serii.

Usługi, które to wdrażają.

Skąd pochodzą daty i liczby.

• Anthropic, Model deprecations: stany w cyklu życia, co najmniej 60 dni wyprzedzenia dla modeli udostępnionych publicznie, platformy partnerskie z własnymi harmonogramami, wycofane parametry żądania zwracające błąd w nowszych modelach
• OpenAI, Deprecations: rozróżnienie deprecation i shutdown, wyprzedzenie co najmniej sześciu miesięcy dla modeli ogólnie dostępnych, trzech dla wariantów specjalistycznych i nawet dwóch tygodni dla preview, datowane snapshoty i aliasy
• Google, Gemini API model deprecations: podane daty wyłączenia to najwcześniejsze możliwe, zamiennik wskazany przy każdym wycofaniu
• Google, Gemini models: wzorce nazw wersji, wersje stabilne zwykle się nie zmieniają, alias latest podmieniany przy każdym wydaniu z dwutygodniowym powiadomieniem e-mail przy zmianach niekompatybilnych, preview wycofywane z co najmniej dwutygodniowym wyprzedzeniem
• OpenAI Cookbook, Reproducible outputs with the seed parameter: determinizm w miarę możliwości i system_fingerprint jako konfiguracja zaplecza, na którym działa model
• Chen, Zaharia i Zou (2023), How is ChatGPT's behavior changing over time?: ten sam endpoint w marcu i czerwcu 2023, rozpoznawanie liczb pierwszych z 84% do 51%, gorsze wykonywanie instrukcji i formatowanie kodu
• Yao i in. (2024), tau-bench: A Benchmark for Tool-Agent-User Interaction: ewaluacja przez porównanie stanu końcowego bazy ze stanem docelowym, miara stabilności pass^k, najlepszy agent poniżej 50% zaliczeń i pass^8 poniżej 25% w domenie detalicznej
• Kapoor i in. (2024), AI Agents That Matter: koszt jako miara obok trafności, zbiory odłożone przeciw przeuczaniu na benchmarku, powtarzalność ewaluacji agentów