Wersjonowanie promptów i modeli: testy regresji i kontrola zmian w AI

W klasycznym oprogramowaniu „drobna zmiana” w jednym miejscu rzadko psuje funkcję dziesięć ekranów dalej. W systemach AI psuje, i to często. Zmieniasz jedno zdanie w prompcie, żeby asystent był „bardziej zwięzły”, a tydzień później okazuje się, że przestał podawać numery spraw, bo skrócił też te fragmenty. My traktujemy prompt i konfigurację modelu jak kod produkcyjny: wersjonujemy je, testujemy regresję przed każdym wdrożeniem i trzymamy ścieżkę powrotu. Bez tej dyscypliny zmiany w AI to ruletka, w której wygraną zauważasz od razu, a przegraną dopiero ze skarg klientów.

Prompt to nie konfiguracja, to program napisany w języku naturalnym, a model jest na ten program nieintuicyjnie wrażliwy. Przeniesienie instrukcji o formacie z końca na początek, dodanie jednego przykładu, zmiana słowa „opisz” na „wymień” — każda z tych rzeczy może przesunąć zachowanie modelu w całej klasie zapytań, nie tylko w tym jednym, które testowałeś ręcznie. Sprawdzasz trzy przypadki, wyglądają lepiej, wdrażasz — i nie wiesz, że w czwartej klasie pytań jakość spadła.

Druga pułapka to zmiana, której nie wprowadziłeś sam. Dostawca modelu aktualizuje wersję pod tą samą nazwą, zmienia się temperatura domyślna, biblioteka inaczej składa wiadomości. System, którego nie tknąłeś, zaczyna odpowiadać inaczej. Dlatego pin wersji modelu i zapisana konfiguracja są równie ważne co wersjonowanie promptu — kontrolujesz nie tylko swoje zmiany, ale i cudze. Bez golden setu i testu regresji takie cichy dryf wykrywasz dopiero, gdy ktoś policzy reklamacje.

Wersjonowanie w AI nie kończy się na tekście promptu. Odpowiedź modelu to funkcja kilku rzeczy naraz i każda z nich musi mieć zapisaną wartość, inaczej nie odtworzysz, dlaczego wczoraj działało, a dziś nie. Traktujemy cały ten zestaw jako jeden artefakt z numerem wersji: zmiana dowolnego pola to nowa wersja i nowy przebieg testów.

Klucz to powiązanie wszystkich tych pól w jedną, niepodzielną wersję. Jeśli wersjonujesz prompt osobno od modelu, w razie awarii nie wiesz, którą parę cofnąć. My nadajemy całej konfiguracji jeden numer i każdą odpowiedź w logach znakujemy tym numerem — wtedy z produkcji da się odtworzyć dokładnie, co wygenerowało dany wynik. To samo podejście opisujemy szerzej przy wyborze modelu LLM do zadania.

Golden set to zbiór reprezentatywnych zapytań z oznaczonym oczekiwanym wynikiem albo kryteriami akceptacji. To on jest siatką bezpieczeństwa, która łapie regresję, zanim trafi do klienta. Zasada brzmi prosto: żadna zmiana promptu ani modelu nie idzie na produkcję, dopóki nie przejdzie testów regresji na aktualnym golden secie, a wyniki nie zostaną porównane z linią bazową poprzedniej wersji. Budowę takiego zbioru i dobór metryk rozwijamy w tekście o tym, jak ewaluować system RAG, a sam pomiar poprawności wyjść — w artykule o walidacji wyjść LLM.

Golden set zaczynamy od 50-100 realnych zapytań z logów albo zgłoszeń, nie od przykładów wymyślonych przy biurku — te ostatnie są zbyt regularne i nie oddają języka użytkowników. Dla każdego zapytania definiujemy, jak wygląda dobra odpowiedź: czasem to dokładny wynik, częściej zestaw faktów, które muszą wystąpić, i format, którego trzeba się trzymać. Ważne, by w zbiorze były też przypadki trudne i graniczne — to one regresują najpierw. Test uruchamiamy przy każdej zmianie i porównujemy odsetek zaliczonych zapytań z poprzednią wersją; spadek nawet o kilka punktów to sygnał do zatrzymania wdrożenia.

Liczby zaliczeń nie wystarczą bez kontekstu, dlatego całość spinamy z obserwowalnością: każdy przebieg ma zapisaną wersję, wynik per kategoria zapytań i przykłady, które się pogorszyły. Wtedy zamiast „jakość spadła” widzisz „klasa pytań o terminy płatności spadła z 88 na 71 procent po zmianie szablonu” — i wiesz, co cofnąć.

Test regresji offline łapie dużo, ale nie wszystko — realny ruch ma rozkłady, których nie odwzorujesz w golden secie. Dlatego zmiany modelu albo dużej wersji promptu wdrażamy stopniowo. Tryb shadow to puszczenie nowej wersji równolegle do starej: klient widzi nadal odpowiedź dotychczasowej wersji, a nowa generuje wynik „w cieniu”, tylko do porównania. Zero ryzyka dla użytkownika, a ty zbierasz dane o tym, jak nowa wersja zachowuje się na prawdziwym ruchu, zanim cokolwiek przełączysz.

A/B idzie krok dalej: kierujesz część ruchu, na przykład 5-10 procent, do nowej wersji i porównujesz metryki jakości oraz biznesowe na obu grupach. To etap, na którym widać rzeczy niewidoczne offline — czas odpowiedzi, koszt, reakcje użytkowników. Bramkę przejścia definiujemy z góry: nowa wersja przejmuje cały ruch tylko, gdy nie pogarsza kluczowych metryk względem starej. Tę samą logikę stosujemy do routingu zgłoszeń, gdzie zmiana progu klasyfikatora też potrafi cicho przesunąć zachowanie.

Granica uczciwości: shadow i A/B kosztują, bo generujesz odpowiedzi podwójnie albo prowadzisz dwie ścieżki. Dla małych zmian promptu sam test regresji offline zwykle wystarcza; shadow i A/B rezerwujemy na zmiany modelu i przebudowy promptu, gdzie ryzyko jest realne. To kompromis między bezpieczeństwem a kosztem, nie procedura na każdą literówkę.

Ostatni filar to ślad i ścieżka powrotu. Dziennik zmian odpowiada na pytanie „co i kiedy się zmieniło”: numer wersji, data, autor, jakie pola dotknięto, wynik testów regresji i decyzja o wdrożeniu. Bez tego diagnostyka awarii zaczyna się od archeologii — kto, co i dlaczego zmienił trzy tygodnie temu. Z dziennikiem zaczyna się od jednego pytania: „która wersja weszła tuż przed tym, jak metryki spadły”, i odpowiedź jest na wyciągnięcie ręki.

Rollback musi być przygotowany, zanim go potrzebujesz. Skoro cała konfiguracja ma jeden numer wersji, cofnięcie to przełączenie wskaźnika na poprzednią, sprawdzoną wersję — sekundy, nie godziny przepisywania promptu z pamięci. Trzymamy poprzednią wersję gotową do uruchomienia i definiujemy wprost, co wyzwala powrót: spadek metryki jakości poniżej progu, skok kosztu albo wzrost reklamacji. To samo myślenie stosujemy w bieżącym monitoringu jakości agenta AI, gdzie alert łączy się z gotowym rollbackiem. Cel jest jeden: każda zmiana w systemie AI ma być odwracalna i udokumentowana, żeby „drobna zmiana” nigdy nie była drogą w jedną stronę.

Tak, i to z tego samego powodu co kod: prompt steruje zachowaniem systemu produkcyjnego, a jego zmiana ma realne skutki. Różnica jest taka, że prompt jest bardziej wrażliwy — przesunięcie jednego zdania potrafi zmienić odpowiedzi w całej klasie zapytań. Bez numeru wersji i dziennika nie odtworzysz, co i kiedy zmieniło zachowanie, a diagnostyka awarii zamienia się w zgadywanie.

Zaczynamy zwykle od 50-100 realnych zapytań i rozbudowujemy go w miarę, jak pojawiają się nowe typy błędów z produkcji. Ważniejsza od liczby jest reprezentatywność: zbiór ma pokrywać główne klasy pytań plus przypadki trudne i graniczne, bo to one regresują najpierw. Każdy nowy incydent na produkcji to kandydat do dopisania do golden setu, żeby ten sam błąd nie wrócił niezauważony.

Bo test offline mierzy na zbiorze, który sam zdefiniowałeś, a realny ruch ma rozkłady i sformułowania, których w nim nie ma. Shadow puszcza nową wersję na prawdziwym ruchu bez ekspozycji klienta, więc wyłapuje dryf niewidoczny w golden secie, zanim cokolwiek przełączysz. To uzupełnienie testu regresji, nie jego zamiennik — pierwszy chroni przed znanymi błędami, drugi przed nieznanymi.

Tak, i to jeden z najczęstszych cichych źródeł regresji. Dostawca potrafi zmienić model pod tą samą nazwą, a system, którego nie tknąłeś, zaczyna odpowiadać inaczej. Dlatego pinujemy dokładną wersję modelu zamiast etykiety „latest” i okresowo puszczamy golden set, żeby wychwycić dryf, na który nie mamy bezpośredniego wpływu.

Powrót do poprzedniej wersji powinien być kwestią sekund, nie godzin — dlatego cała konfiguracja ma jeden numer wersji, a poprzednia, sprawdzona wersja jest trzymana gotowa do uruchomienia. Definiujemy z góry, co wyzwala rollback: spadek metryki jakości poniżej progu, skok kosztu albo wzrost reklamacji. Im wcześniej zdefiniujesz te warunki, tym mniej decyzji podejmujesz pod presją w trakcie awarii.