Dodajesz do promptu zdanie „odpowiadaj krótko”. Faktycznie, odpowiedzi są krótsze. Znika też źródło, warunek bezpieczeństwa i informacja o braku danych. Sukces trwa do pierwszego zgłoszenia użytkownika.
Regresja to pogorszenie zachowania, które wcześniej działało. Przy promptach rzadko wystarczy porównać dwa ładne wyniki. Potrzebujesz zestawu przypadków, wersji i kryteriów, które nie zmieniają się w trakcie oglądania odpowiedzi.
Zapisz zachowanie przed zmianą
Wybierz zadanie i jego wymagania: fakty, źródło, format, sposób reakcji na brak, ograniczenia. Uruchom obecną wersję na reprezentatywnych danych. Zachowaj wyniki, model, parametry i datę.
Nie czekaj, aż zestaw będzie idealny. Dziesięć dobrze opisanych przypadków jest lepsze niż zero i notatka „kiedyś zrobić evaly”. Dodawaj nowe po błędach produkcyjnych. Zestaw ma rosnąć z rzeczywistą pracą, nie z ambicją stworzenia uniwersytetu testowego.
Oddziel przypadki stabilne od eksperymentalnych. Stabilne pilnują podstawowego kontraktu. Eksperymentalne pokazują nowe obszary i mogą wymagać dyskusji. Bez tego każda nowa sytuacja będzie wyglądać jak awaria, nawet jeśli proces jeszcze jej nie obsługiwał.
Przypadki powinny różnić się problemem
Nie wystarczy dziesięć maili o tym samym pytaniu w różnym słownictwie. Dodaj typowy przypadek, brak danych, konflikt źródeł, nietypowy format, zbyt długie wejście i treść próbującą zmienić instrukcję.
Przy polskich dokumentach uwzględnij odmianę nazw, daty zapisane słownie, skróty i zdania bez jednoznacznego właściciela. Nie testuj wyłącznie poprawnych PDF-ów przygotowanych przez zespół. Prawdziwy świat wysyła skan ukośny z dopiskiem „pilne”.
Każdy przypadek powinien mieć powód obecności. Jeżeli nie wiesz, jakiego błędu pilnuje, zastąp go innym. Liczba testów nie jest celem. Mały zestaw z konkretnymi ryzykami daje więcej niż dwieście kopii poprawnego scenariusza.
Rubryka zamiast porównania słowo w słowo
Odpowiedzi generatywne mogą być różne i nadal poprawne. Nie wymagaj identycznego tekstu, chyba że format tego wymaga. Oceń cechy: czy źródło podpiera fakt, czy warunek został zachowany, czy brak jest oznaczony, czy format działa.
Rozdziel błędy krytyczne od drobnych. Wymyślony termin płatności nie powinien zniknąć w średniej z ładnym stylem. Możesz mieć regułę: jeden błąd faktu blokuje wydanie niezależnie od wyniku pozostałych kryteriów.
Przy subiektywnych cechach zapisz przykłady. „Naturalny język” jest zbyt szerokie. „Brak korporacyjnych fraz, zdania o różnej długości, brak udawanej empatii” daje lepszy odbiór. Nadal wymaga człowieka, ale przynajmniej wiadomo, co ocenia.
Zmieniaj jedną rzecz naraz
Jeżeli zmieniasz prompt, model i źródło kontekstu jednocześnie, nie wiesz, co poprawiło wynik. Możesz wdrożyć trzy problemy i jedną poprawkę. Wynik końcowy będzie wyglądał akceptowalnie do czasu konkretnego przypadku.
Zacznij od jednej zmiany i porównaj ten sam zestaw. Zapisz hipotezę: „dodanie null przy braku źródła ograniczy zgadywanie terminów”. Potem sprawdź, czy faktycznie to nastąpiło i czy inne odpowiedzi nie straciły danych.
Czasem zmiana wymaga kilku powiązanych edycji. Traktuj je jako jeden pakiet, ale dokumentuj zakres. Nie dodawaj kosmetycznych poprawek przy okazji. One utrudniają odbiór i rollback.
Nie dopasowuj testów do nowej odpowiedzi
Kiedy nowa wersja zwraca dziwny wynik, łatwo uznać, że kryterium było zbyt rygorystyczne. Czasem to prawda, ale zmiana wymaga osobnego uzasadnienia. Nie przepisuj oczekiwanego faktu tylko dlatego, że model wybrał inną liczbę.
Jeżeli przypadek był błędny, popraw go z datą i powodem. Zachowaj historię. Inna osoba powinna zobaczyć, czy test zmieniono z powodu nowej reguły biznesowej, czy dla uzyskania zielonego raportu.
Szczególnie uważaj przy automatycznych sędziach. Model oceniający może preferować dłuższe, gładsze odpowiedzi. Sprawdź próbkę ręcznie i porównaj z rubryką. Automat pomaga przy skali, ale nie jest właścicielem definicji jakości.
Powtórzenia pokazują zakres wahania
Jedno uruchomienie nie opisuje pełnego zachowania modelu. Przy ważnych zmianach wykonaj kilka powtórzeń na tym samym zestawie, zgodnie z możliwościami i kosztem. Zapisz rozbieżności, nie tylko najlepszy wynik.
Nie wybieraj odpowiedzi, która najlepiej wygląda w prezentacji. Raport powinien pokazywać typowy rezultat i przypadki nieprzechodzące. Jeżeli jedna z pięciu prób ujawnia dane, problem nie zniknął dlatego, że cztery były poprawne.
Przy zadaniach deterministycznych możesz ograniczyć zmienność ustawieniami i walidacją, ale nadal testuj kontrakt. Dokumentacja dostawcy i wersja modelu wpływają na zachowanie. Zapisz je przy wyniku.
Odbiór pary wersji obok siebie
Pokaż starą i nową odpowiedź bez informacji, która jest nowa. Poproś oceniającego o wskazanie zgodności z kryteriami. Dopiero potem omów intencję zmiany. To ogranicza sympatię do własnej edycji.
Zaznacz różnice w skutku, nie tylko w słowach. Krótsza odpowiedź może być lepsza dla użytkownika, ale gorsza dla integracji, jeśli zniknęło pole. Lepszy styl nie rekompensuje zgubionego warunku.
Jeżeli dwie osoby oceniają inaczej, sprawdź rubrykę. Może jest niejasna albo przypadek wymaga dodatkowego kontekstu. Nie rozstrzygaj każdej różnicy głosowaniem; czasem trzeba doprecyzować zadanie.
Przypadek: nowe źródło, stary problem
Zespół dodaje do promptu wymóg cytowania. Model zaczyna podawać numery stron, ale część nie istnieje. Test powinien sprawdzać, czy odwołanie prowadzi do właściwego fragmentu, a nie tylko czy wygląda jak przypis.
Poprawka może polegać na przekazaniu identyfikatorów źródeł i ograniczeniu odpowiedzi do nich. Samo zdanie „nie zmyślaj cytowań” nie wystarczy. Zmieniasz mechanizm, potem powtarzasz przypadki z brakiem źródła i konfliktem.
Dodaj przypadek, w którym poprawna odpowiedź brzmi „nie wiem”. Jeżeli zestaw zawiera wyłącznie pytania mające odpowiedź, nauczysz system zawsze coś znajdować. To jest mała decyzja testowa z dużym skutkiem.
Automatyzacja bez oddawania odbioru
Testy struktury, linków, zakresów i obecności pól można uruchamiać automatycznie przy każdej zmianie. Wyniki językowe i ryzykowne decyzje wymagają próbki człowieka. Nie przekształcaj każdej oceny w modelowego sędziego tylko dlatego, że łatwo go wywołać.
Narzędzia takie jak Promptfoo pomagają przechowywać konfigurację i porównywać warianty. Samo narzędzie nie zna twojej reguły biznesowej. Zacznij od przypadków i kryteriów, potem wybierz sposób uruchamiania.
Zielony pipeline oznacza, że zdefiniowane testy przeszły. Nie oznacza, że proces jest dobry dla każdego użytkownika. Po wdrożeniu zbieraj zgłoszenia i dodawaj nowe przypadki zamiast traktować raportu jako wiecznego certyfikatu.
Rollback musi obejmować konfigurację
Zachowaj poprzedni prompt, wersję modelu, schemat i źródła. Cofnięcie jednego pliku nie pomoże, jeżeli nowy format danych pozostał w aplikacji. Przygotuj listę elementów, które razem tworzą zachowanie.
Po wycofaniu uruchom kilka przypadków potwierdzających powrót. Sprawdź także wyniki zapisane podczas nowej wersji. Mogą wymagać osobnej korekty lub oznaczenia. Rollback kodu nie przepisuje historii.
Przy publikacjach treści połącz ten proces z testami regresji treści i linków. Zmiana promptu może wpływać na setki stron, więc odbiór powinien obejmować również canonical i linki, jeśli są generowane.
Mały rytuał przed każdą zmianą
Opisz problem, wybierz przypadki, uruchom wersję bazową, zmień jedną rzecz, porównaj wynik i zapisz decyzję. To wystarczy na początek. Nie potrzebujesz osobnego działu i dashboardu z dziesięcioma wykresami.
Raz w miesiącu usuń testy, które nie odpowiadają na realne ryzyko, i dodaj przypadki z nowych błędów. Przeglądaj również długo niezmieniane kryteria. Proces mógł się zmienić, a testy nadal pilnować dawnego świata.
Jak interpretować spadek wyniku
Najpierw sprawdź, czy zmieniły się dane lub warunki uruchomienia. Błąd sieci, nowa wersja źródła i przekroczony limit mogą wyglądać jak regresja promptu. Powtórz wersję bazową w tym samym środowisku. Bez kontroli łatwo obwinić ostatnią edycję za problem, który przyszedł z zewnątrz.
Potem pogrupuj błędy według przypadków. Jeżeli pogarsza się tylko jeden typ wejścia, dodaj hipotezę dotyczącą kontekstu lub instrukcji. Nie zmieniaj globalnego tonu dla jednego nietypowego dokumentu. Poprawka powinna odpowiadać zakresowi problemu.
Jeżeli nowa wersja poprawia jedną metrykę i pogarsza krytyczną, nie licz średniej. Decyzja zależy od priorytetu procesu. Czasem trzeba odrzucić zmianę mimo lepszej czytelności. Raport powinien pokazać kompromis, a nie schować go pod ogólnym procentem.
Kiedy test przechodzi, a użytkownik zgłasza błąd
Potraktuj zgłoszenie jako nowy przypadek, nie dowód, że cały zestaw jest bezużyteczny. Odtwórz źródło, wersję i warunki. Być może test nie zawierał konkretnej roli, długości lub sekwencji działań. Dodaj brakujący element zamiast losowo wydłużać prompt.
Jeżeli nie da się odtworzyć problemu, zapisz ograniczenie i popraw obserwację procesu. Nie zmieniaj dziesięciu reguł na podstawie jednego niejasnego zrzutu. Czasem potrzebny jest lepszy identyfikator wersji lub bezpieczny log skutku.
Po naprawie uruchom nowy przypadek oraz zależne kontrolne. Użytkownik powinien dostać informację o rzeczywistym skutku, nie ogólne „poprawiliśmy AI”. Dobry kontakt po błędzie jest częścią jakości systemu.
Minimalny raport wydania
Zapisz wersję bazową i nową, zakres zmiany, zestaw przypadków, wyniki krytyczne, znane ograniczenia i sposób rollbacku. Jedna strona wystarcza przy małym procesie. Nie przepisuj wszystkich odpowiedzi; dołącz identyfikatory i przykłady najważniejszych różnic.
Osoba zatwierdzająca powinna zobaczyć także przypadki, które nie przeszły. Raport zawierający tylko najlepsze wyniki jest materiałem promocyjnym, nie odbiorem. Jeżeli akceptujesz ograniczenie, zapisz powód i właściciela dalszej obserwacji.
Po wdrożeniu ustaw krótki przegląd zależny od ryzyka. Nowe zgłoszenia trafiają do zestawu. Wtedy testy są żywą częścią pracy, a nie folderem uruchamianym wyłącznie przed dużą migracją.
Nie zapisuj w raporcie wrażliwych treści tylko po to, by zachować pełny kontekst. Wystarczą identyfikatory przypadków i zabezpieczone źródła. Osoba oceniająca powinna mieć dostęp do oryginału zgodnie z rolą, a nie otrzymywać nowej kopii w dokumencie wydania.
Przy dłużej działającym zestawie sprawdzaj, czy przypadki nie powielają tego samego ryzyka. Nadmiar podobnych testów zwiększa koszt i czas, ale nie poprawia pokrycia. Skrócenie zestawu po analizie błędów jest równie cenne jak dodanie nowego. Regresja ma pilnować decyzji, a nie wolumenu raportu.
Przy zmianie właściciela procesu oddaj także zestaw i historię decyzji. Nowa osoba powinna uruchomić podstawowe przypadki przed pierwszą edycją promptu. To ogranicza ryzyko, że poprawi wynik według własnego gustu, przypadkowo usuwając warunek, którego nie zna z poprzedniego incydentu.
Aeneia Audit pomaga połączyć zmiany promptów z procesem i odpowiedzialnością. Przy większej liczbie agentów pomocny jest opis odpowiedzialnego workflow.
W raporcie wydania zostaw także przypadek, który po zmianie wypadł gorzej, i sposób powrotu. Osoba zatwierdzająca powinna móc ocenić ten koszt obok poprawionych odpowiedzi.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
