Harness regresyjny na wycofanie i podmianę modelu: zbiór przypadków z oczekiwaną decyzją, który blokuje migrację, zanim trafi na produkcję

Dla kogo jest ten przewodnik.

• CTO i szefowie inżynierii, którzy dostali zapowiedź wycofania modelu stojącego za funkcją produkcyjną i muszą wiedzieć, co zamiennik zrobi inaczej, zanim minie termin
• Zespoły platformowe, które wołają model przez alias albo znacznik latest i widziały zmianę zachowania w dniu, w którym niczego nie wdrażały
• 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, którym dział finansów kazał przejść na tańszy model, a które nie umieją powiedzieć, czego tańszy model przestanie robić

Co zmienia podmiana modelu i dlaczego próbka odpowiedzi tego nie pokaże

Agent na produkcji to pętla decyzji: czy wywołać narzędzie, które, z jakimi argumentami, czy dopytać użytkownika, czy odmówić, czy się zatrzymać. Tekst, który zwraca, jest ostatnim krokiem. Po podmianie modelu recenzent czyta właśnie tekst, a tekst nowszego modelu zwykle czyta się lepiej: czyściej, pewniej, w lepszym formatowaniu. Regresja siedzi w decyzjach. W wątku na forum dla programistów z lipca 2026 ktoś opisuje podmianę, która po cichu zepsuła anulowanie zamówień przez agenta; w innym wątku z sierpnia 2026 zamiennik, poproszony o sprawdzenie dostępności terminu, sam umówił spotkanie. W obu przypadkach odpowiedzi wyglądały poprawnie, a stan świata był zły.

Badania nad ewaluacją agentów doszły do tego samego miejsca. Yao i współautorzy (2024), twórcy tau-bench, oceniają agenta przez porównanie stanu bazy danych na końcu rozmowy ze stanem docelowym opisanym w adnotacji, i wprowadzili miarę pass^k, czyli prawdopodobieństwo, że agent zaliczy wszystkie k z k powtórzeń tego samego zadania, bo pojedynczy przebieg ukrywa niestabilność. Ich najlepszy agent zaliczał wtedy mniej niż 50% zadań i miał pass^8 poniżej 25% w domenie sprzedaży detalicznej. Harness, który ocenia końcowy tekst według kryteriów, mierzy niewłaściwą warstwę. Musi sprawdzać decyzję i stan końcowy i musi uruchamiać każdy przypadek więcej niż raz.

Dryf wyniku i dryf wykonania

Dryfem nazywa się dwie różne rzeczy i każda wymaga innej kontroli. Dryf wyniku to inna decyzja modelu na tym samym wejściu, bo model się zmienił: migracja po wycofaniu, przejście na tańszą klasę, alias, który wskazuje już gdzie indziej. Dryf wykonania to inne zachowanie przy tym samym identyfikatorze modelu, bo zmieniło się coś za identyfikatorem. Chen, Zaharia i Zou (2023) zmierzyli ten sam endpoint GPT-4 w marcu i w czerwcu 2023 i zobaczyli spadek trafności rozpoznawania liczb pierwszych z 84% do 51%, razem z gorszym wykonywaniem instrukcji i większą liczbą błędów formatowania w generowanym kodzie. Dokumentacja OpenAI do parametru seed mówi wprost, że determinizm jest zapewniany w miarę możliwości, a pole system_fingerprint, opisujące konfigurację zaplecza, na którym działa model, zmienia się, gdy dostawca aktualizuje numeryczną konfigurację infrastruktury serwującej model.

Obejście, które praktycy powtarzają w każdym wątku na ten temat, to logowanie identyfikatora modelu i fingerprintu odsyłanych przez dostawcę przy każdej odpowiedzi oraz alert przy zmianie. To dobra kontrola obserwowalności i jej miejsce jest w warstwie śladów, obok kosztu i latencji na wywołanie. Harness jest innym instrumentem. Log mówi zespołowi, że coś się zmieniło, i nie mówi nic o tym, co agent robi teraz inaczej, a milczy zupełnie, gdy identyfikator stoi w miejscu, a zachowanie i tak się przesuwa. Na to pytanie odpowiada harness, a zalogowany identyfikator mówi tylko, kiedy uruchomić go poza cyklem wydania.

Jak trzej główni dostawcy wycofują modele

Okresy wyprzedzenia i mechanika aliasów różnią się między dostawcami, a te różnice decydują o tym, ile z migracji zespół ma pod kontrolą. Tabela streszcza, co dokumentacja każdego dostawcy deklaruje w chwili pisania; konkretne daty się zmieniają i nie ma ich tutaj.

Harness: 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, decyzja, jakiej oczekuje się od agenta, wywołania narzędzi, jakie ma wykonać, z argumentami, które mają znaczenie, oraz stan końcowy. Przypadki pochodzą ze śladów produkcyjnych, warstwowanych tak, żeby były w nich te rzadkie i kosztowne: odmowy, działania nieodwracalne, przekazania do człowieka, sytuacje 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 pojawiły się wskazane fakty. Kryteria tekstowe, które wymagają modelu w roli sędziego, dostają go, a ten sędzia potrzebuje własnej kalibracji wobec ocen ludzi. To temat osobnego przewodnika w tym serwisie i tutaj się go nie powtarza.

Próg jest spisany przed uruchomieniem, dla każdej klasy przypadków, a nie po przeczytaniu różnic. Klasy z działaniami nieodwracalnymi dostają tolerancję zero: jedna zmieniona decyzja blokuje podmianę. Klasy z odwracalnym skutkiem 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, żeby porównanie było pass^k do pass^k, jak u Yao i współautorów, a przypadek, który na nowym modelu raz przechodzi i dwa razy nie, liczy się jako niestabilny, co dla agenta działającego w imieniu klienta jest regresją. Kapoor i współautorzy (2024) argumentują, że ewaluacja agentów bez kosztu jest niepełna, a benchmarki bez zbioru odłożonego są przeuczane; harness raportuje koszt i latencję na przypadek obok różnic w decyzjach, a część przypadków jest odłożona i niedostępna dla nikogo, kto stroi prompt pod nowy model.

• Wyzwalacze: zmiana modelu albo wersji, zmiana promptu, zmiana schematu albo opisu narzędzia oraz zmiana identyfikatora lub fingerprintu modelu zalogowana na produkcji.
• Diff na przypadek: decyzja oczekiwana i zaobserwowana, wywołania narzędzi z argumentami, stan końcowy, tokeny i koszt, latencja, stabilność między powtórzeniami.
• Bramka: próg dla każdej klasy przypadków uzgodniony na piśmie przed pierwszym uruchomieniem; przekroczenie kończy zadanie CI błędem i podmiana nie wchodzi.
• Pułapka pewności: tekst nowego modelu jest ukryty przed recenzentami do czasu przeczytania różnic w decyzjach, żeby pewniejszy ton nie został wzięty za lepszą decyzję.

Procedura podmiany i droga powrotu

Zapowiedź wycofania uruchamia procedurę, która już istnieje. Zbiór przypadków zostaje zamrożony w dniu zapowiedzi i oznaczony identyfikatorem wersji starego modelu, a wyniki starego modelu na tym zbiorze są zapisywane jako punkt odniesienia, dopóki stary model jeszcze odpowiada. Zamiennik uruchamia się na tym samym zamrożonym zbiorze; raport różnic trafia do właściciela każdego przepływu razem z przypadkami, które nie przeszły. Zmiany promptu robione pod nowy model są wersjonowane osobno i znów przechodzą przez harness, bo poprawka pod jedną klasę 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 liczony w minutach, bez hotfixa.

Po dniu wycofania nie ma już do czego wracać, i to jest argument za tym, żeby zacząć w dniu zapowiedzi, a nie tydzień przed terminem. Procedura wskazuje też, kto śledzi strony z wycofaniami i noty wydań dostawców, jak często, i gdzie są zapisane kolejne znane daty, żeby następna zapowiedź nikogo nie zaskoczyła. Zespół, który przeszedł to raz, ma zbiór przypadków, zadanie CI i format raportu; druga migracja to jedno uruchomienie i przegląd różnic.

Gdzie to się psuje i co z tym robimy.

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

   Zespół porównuje próbkę odpowiedzi starego i nowego modelu, czyta nowe jako czystsze i lepiej ułożone, i wdraża. Przypadków, w których agent powinien był dopytać, odmówić albo się zatrzymać, w próbce nie ma, albo są, ale recenzent czyta prozę zamiast wywołania narzędzia. Anulowanie, które już nie następuje, albo spotkanie umówione 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 liczymy na tych polach, zanim ktokolwiek przeczyta tekst. Przypadki z klas z działaniami nieodwracalnymi pobieramy ze śladów produkcyjnych w nadmiarze. Recenzent widzi najpierw różnice w decyzjach, a tekst dopiero potem.

   Co zostaje u was: zbiór przypadków z oczekiwaną decyzją i wywołaniami narzędzi dla każdego z nich oraz raport różnic w decyzjach z każdej podmiany, z załączonymi przypadkami, które nie przeszły
2. 2
   Alias się przesunął, a nikt niczego nie wdrażał

   Aplikacja woła model przez alias albo znacznik latest. Dostawca przestawia alias na nowe wydanie, w zadeklarowanym okresie wyprzedzenia albo, przy zmianach konfiguracji zaplecza, bez żadnego. Zachowanie zmienia się w dniu, w którym w historii zespołu nie ma wdrożenia, i dochodzenie zaczyna się w kodzie aplikacji. Chen, Zaharia i Zou (2023) udokumentowali, że zachowanie tego samego endpointu przesunęło się wyraźnie w ciągu trzech miesięcy.

   Co z tym robimy

   Przypinamy model do stałej wersji tam, gdzie dostawca ją oferuje, logujemy identyfikator modelu i fingerprint odsyłane z każdą odpowiedzią do warstwy śladów i dodajemy alert przy zmianie. Zmieniony identyfikator uruchamia harness poza cyklem wydania, więc zespół widzi różnice w decyzjach tego samego dnia, a nie objaw kilka tygodni później.

   Co zostaje u was: przypięta wersja w konfiguracji, pola identyfikatora i fingerprintu w każdym śladzie oraz alert podpięty pod zaplanowane uruchomienie harnessu
3. 3
   Nowszy model brzmi pewniej, więc uchodzi za lepszy

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

   Co z tym robimy

   Liczymy odsetek zaliczeń na poziomie decyzji i stabilność między powtórzeniami dla każdej klasy przypadków, z tekstem ukrytym do czasu przeczytania różnic. Tam, gdzie nowy model robi więcej, niż przypadek zakładał, przypadek nie przechodzi niezależnie od tego, jak czyta się odpowiedź, a wynik trafia do prac nad promptem pod nowy model razem z tym przypadkiem.

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

   Harness się uruchamia, nowy model zalicza 92% przypadków i na tym samym spotkaniu 90% zostaje uznane za wystarczające. W pozostałych 8% są dwa przypadki odmowy i jeden zwrot pieniędzy, na które nikt nie patrzy osobno, bo suma przeszła. Próg stał się opisem wyniku zamiast bramką.

   Co z tym robimy

   Spisujemy próg dla każdej klasy przypadków z właścicielem danego przepływu przed pierwszym uruchomieniem, a klasy z działaniami nieodwracalnymi dostają tolerancję zero. Zadanie CI kończy się błędem przy każdej klasie ponad progiem i wypisuje przypadki, które nie przeszły, według klas, więc zwrot pieniędzy 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 na nim kończy się błędem
5. 5
   Harness uruchamia się tylko przy zmianie modelu, a zmiana narzędzia przechodzi bokiem

   Programista zmienia kolejność narzędzi, nazwę parametru albo opis narzędzia przy okazji niezwiązanego zadania. Wybór narzędzia przez model zależy od tych opisów, więc agent zaczyna sięgać po inne narzędzie na tym samym wejściu. Model się nie zmienił, więc harness nie ruszył, a regresję przypisuje się modelowi przy następnej podmianie.

   Co z tym robimy

   Liczymy jeden hash z wersji modelu, promptu i schematów narzędzi i uruchamiamy harness przy zmianie któregokolwiek z tych trzech, w tym samym zadaniu CI. Raport różnic wskazuje, które z trzech zmieniło się od punktu odniesienia, więc przyczyna jest w raporcie, a nie w bisekcji.

   Co zostaje u was: wspólny hash modelu, promptu i narzędzi zapisany przy każdym uruchomieniu harnessu oraz wyzwalacz CI na zmianę dowolnego z nich

Co zostaje u was.

• Zbiór przypadków: prawdziwe interakcje ze śladów produkcyjnych z nagranymi odpowiedziami narzędzi, oczekiwaną decyzją, oczekiwanymi wywołaniami narzędzi z argumentami, oczekiwanym stanem końcowym i tolerancją dla każdego przypadku, warstwowany według klas i wersjonowany razem z hashem modelu, promptu i narzędzi
• Rejestr progów: jeden wiersz na klasę przypadków z tolerancją, właścicielem i datą uzgodnienia, podpięty do zadania CI jako bramka blokująca
• Raport różnic z każdej podmiany: różnice w decyzjach, wywołaniach narzędzi, stanie końcowym, koszcie i latencji między punktem odniesienia a kandydatem, pass^k dla każdej klasy, załączone przypadki, które nie przeszły, tekst odpowiedzi ukryty do czasu przeczytania różnic
• Zadanie CI, które uruchamia harness przy zmianie modelu, promptu albo narzędzi oraz przy zmianie identyfikatora zalogowanej na produkcji, ze wspólnym hashem zapisanym przy każdym uruchomieniu
• Pola w śladach na identyfikator modelu i fingerprint zaplecza odsyłane z każdą odpowiedzią, z alertem przy zmianie i zaplanowanym uruchomieniem harnessu za nim
• Procedura na wycofanie: kto śledzi które strony dostawców i jak często, kroki zamrożenia i punktu odniesienia w dniu zapowiedzi, przełącznik wskazujący z powrotem stary model do dnia wycofania oraz droga powrotu

Jak pracujemy.

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

   Rozrysowujemy z wami decyzje i narzędzia agenta, nazywamy klasy przypadków i spisujemy tolerancję oraz właściciela dla każdej klasy przed jakimkolwiek uruchomieniem. Działania nieodwracalne, odmowy i przekazania do człowieka dostają własne klasy z tolerancją zero. To jest 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, warstwowane według klas, nagrywamy odpowiedzi narzędzi, żeby środowisko odtwarzało się identycznie, i razem z właścicielami przepływów opisujemy oczekiwaną decyzję, wywołania narzędzi i stan końcowy dla każdego przypadku. Część przypadków odkładamy poza zasięg osób strojących 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 różnic trafia do właścicieli przepływów z przypadkami, które nie przeszły, oraz kosztem i latencją dla każdej klasy.

   Tydzień 3-4
4. 4
   4. Podpięcie do CI i haki produkcyjne

   Dodajemy harness jako zadanie CI wyzwalane wspólnym hashem modelu, promptu i narzędzi, dokładamy do waszych śladów pola identyfikatora i fingerprintu z alertem i zaplanowanym uruchomieniem za nim, a przełącznik modelu z drogą powrotu wstawiamy do konfiguracji.

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

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

   Tydzień 5-6

Pozostałe strony z tej serii.

Gdzie to zamienia się w usługę.

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