Jakość odpowiedzi AI po zmianie: jak prowadzić testy regresji?

Wczoraj proces dobrze rozpoznawał dokumenty, dziś po aktualizacji elegancko myli dwie kategorie. Test regresji ma znaleźć właśnie takie pogorszenie: porównać nowe zachowanie z tym, na którym zespół już polegał. Zachowaj przypadki, oczekiwane wyniki i warunki próby. Sprawdzaj całe zadanie, także odmowę i przekazanie sprawy człowiekowi. Nowy numer modelu nie jest samodzielnym listem polecającym dla jego odpowiedzi.

Pierwszy pilotaż odpowiada na pytanie, czy rozwiązanie nadaje się do wybranego zastosowania. Późniejsze porównanie ma inną intencję: sprawdzić, co zmieniło się względem zatwierdzonego sposobu pracy. Dlatego potrzebuje zachowanego punktu odniesienia i powtarzalnych przypadków. Jedna udana odpowiedź po aktualizacji nie wyjaśnia, jak system potraktuje pozostałe sytuacje.

Zapisz, co dokładnie zmieniasz

Utwórz kartę zmiany zawierającą element, powód, właściciela i spodziewany skutek. Rozróżnij zmianę modelu, instrukcji, ustawień, materiałów źródłowych oraz uprawnień. Jeśli aktualizujesz kilka elementów jednocześnie, zapisz, że późniejsze przypisanie przyczyny może być trudniejsze. Tam, gdzie to wykonalne, oceniaj kolejne zmiany osobno i zachowuj ich wyniki.

Do punktu odniesienia wpisz identyfikator modelu lub usługi, wersję instrukcji, źródła oraz datę próby. Gdy dostawca nie udostępnia szczegółowej wersji, zachowaj dostępne informacje i nazwij ograniczenie. Warunki śledzenia aktualizacji warto ustalić już podczas oceny dostawcy AI. Bez tego firma może dowiadywać się o zmianie dopiero z reklamacji użytkownika.

Zachowaj zestaw przypadków z działającego procesu

Wybierz materiały reprezentujące zwykłą pracę, istotne wyjątki i wcześniej znalezione błędy. Zestaw powinien zawierać łatwe przypadki oraz sytuacje, w których poprawnym wynikiem jest dodatkowe pytanie, odmowa lub wskazanie braku informacji. Zapisz pochodzenie i dopuszczony sposób użycia danych. Testowanie jakości nie uzasadnia kopiowania dowolnych dokumentów do kolejnego środowiska.

Nie ograniczaj zbioru do przykładów, na których dopracowano instrukcję. Pozostaw również przypadki przeznaczone wyłącznie do oceny. Jeśli zespół zna je na pamięć i stale dostosowuje do nich rozwiązanie, sprawdza coraz węższą umiejętność. W miarę pojawiania się nowych sytuacji rozwijaj zestaw, zachowując informację, od kiedy dany przypadek należy do porównania.

Oceniaj cechy wyniku, nie identyczność zdań

W wielu zadaniach kilka odpowiedzi może być poprawnych. Ustal obowiązkowe informacje, dopuszczalną swobodę i błędy, których nie wolno zaakceptować. Dla podsumowania istotne mogą być ustalenia, warunki, nazwy i oparcie w źródle. Inna kolejność zdań nie musi oznaczać pogorszenia. Dopisanie nieistniejącej decyzji wymaga osobnej oceny skutku.

Przy każdym kryterium określ, jak je sprawdzisz. Część da się ocenić automatycznie, na przykład obecność wymaganego pola. Inne wymagają porównania z dokumentem przez osobę znającą zadanie. Nie zastępuj oceny zgodności samym testem formatu. Poprawny układ odpowiedzi może zawierać błędne ustalenia. Kryteria początkowego zadania przypomina projekt pilotażu AI.

Rozdziel błędy według skutku

Zdefiniuj kategorie przed porównaniem. Błąd krytyczny dla procesu może oznaczać niedopuszczalne działanie lub ujawnienie materiału poza zakresem. Istotny błąd merytoryczny wymaga poprawki przed odbiorem. Drobna wada stylu może nie blokować użycia. Nazwy i granice kategorii dobierz do własnego zadania; nie istnieje jedna uniwersalna skala odpowiednia dla każdej firmy.

Ustal zasady traktowania przypadku, w którym odpowiedź jest prawidłowa, ale jej sprawdzenie trwa znacznie dłużej. Jakość procesu obejmuje także nakład odbiorcy i czytelność niepewności. Zapisz wpływ takiej zmiany na całkowity koszt pracy z AI. Dzięki temu lepszy wynik jednej miary nie ukryje pogorszenia innego ważnego warunku.

Porównuj w tych samych warunkach

Uruchom stary i nowy wariant na tej samej wersji materiału, z porównywalnymi uprawnieniami oraz ustawieniami. Oddziel rezultat surowy od poprawionego przez człowieka. Jeśli wcześniejszy wynik został ręcznie dopracowany, zachowaj tę informację. Porównanie go z nową surową odpowiedzią dawałoby obraz różnicy, której źródłem może być dodatkowa praca odbierającego.

Zapisuj również błędy techniczne i przekroczenia czasu. Nie pomijaj nieudanych prób w podsumowaniu uruchomień tylko dlatego, że nie wygenerowały tekstu. Jeżeli dostawca zmienił funkcję w sposób uniemożliwiający powtórzenie starego wariantu, wykorzystaj zachowane wyniki z opisem ograniczenia. Decyzja powinna pokazywać, co faktycznie porównano i jaką część procesu trzeba było ocenić inną metodą.

Uwzględnij zmienność odpowiedzi

Ten sam materiał może prowadzić do różnych rezultatów w kolejnych uruchomieniach. Liczbę powtórzeń dobierz do skutku błędu, zmienności zadania i dostępnych zasobów. Nie przedstawiaj jednej udanej odpowiedzi jako dowodu stałej niezawodności. Zachowaj zarówno wynik, jak i warunki próby, aby osoba odbierająca mogła odróżnić pojedynczą obserwację od powtarzającego się zachowania.

Oficjalny przewodnik OpenAI po ocenianiu zaleca testy dopasowane do zadania, powtarzanie oceny po zmianach i łączenie miar z oceną człowieka. To przydatne odniesienie metodologiczne. Progi odbioru, liczba prób i dopuszczalny poziom błędu pozostają decyzją dotyczącą konkretnego procesu, a nie wartością do bezpośredniego przepisania z przykładu dostawcy.

Przetestuj źródła i granice dostępu

Zmiana jakości może wynikać z pobierania innego materiału, mimo że sam model działa podobnie. Sprawdź aktualny dokument, wycofaną wersję, brak źródła i materiał sprzeczny. Oceń, czy odpowiedź wskazuje podstawę oraz czy powstrzymuje się od dopowiadania braków. Jeśli źródła mają daty i właścicieli, zachowaj je przy przypadku testowym.

Dodaj próbę z kontem, które nie ma dostępu do wybranego zasobu. Oczekiwana odmowa jest częścią poprawnego zachowania. Sprawdź także, co dzieje się po odebraniu uprawnienia, szczególnie gdy produkt utrzymuje własny indeks lub kopię. Ten zakres rozwija przegląd uprawnień integracji AI, a uporządkowanie materiałów opisuje architektura wiedzy.

Uzgodnij ocenę człowieka i narzędzia

Jeżeli wynik wstępnie ocenia inny model, sprawdź jego zgodność z oceną osób znających zadanie. Zachowaj próbkę rozbieżności i ustal sposób rozstrzygnięcia. Automatyczna ocena może przyspieszyć przegląd, ale sama również jest elementem rozwiązania wymagającym kontroli. Zmiana modelu oceniającego może zmienić wynik, choć odpowiedzi ocenianego systemu pozostały takie same. Osobny przegląd modelu AI używanego jako sędzia pozwala rozpisać kontrolę oceniającego, zanim jego werdykt stanie się podstawą decyzji o aktualizacji.

Przy ocenie ludzkiej przygotuj krótką instrukcję z przykładami błędów. Poproś dwie osoby o niezależne sprawdzenie wybranego fragmentu zestawu. Jeśli rozumieją kryterium inaczej, doprecyzuj regułę i zapisz, co oraz kiedy w niej zmieniono. W szkoleniu zespołu z weryfikacji pokazujemy, jak ćwiczyć przejście od wrażenia poprawności do wskazania dowodu.

Przykład roboczy: zmiana modelu podsumowań

Zespół ma zatwierdzony proces tworzenia notatek ze spotkań. Po zmianie modelu odpowiedzi są krótsze i czytelniejsze, lecz w części przypadków pomijają warunek, od którego zależy wykonanie zadania. W zestawie porównawczym taki warunek jest elementem obowiązkowym. Osoba odbierająca zapisuje pominięcie jako błąd merytoryczny, niezależnie od poprawy stylu.

Właściciel procesu może wtedy wstrzymać zmianę, ograniczyć ją do innego rodzaju materiału albo dopracować rozwiązanie i ponowić ocenę. Jeśli poprawia instrukcję na ujawnionych przykładach, sprawdza również nowe materiały. Wynik nie powinien opierać się wyłącznie na przypadkach, które posłużyły do poprawki. To przykład ćwiczeniowy opisujący sposób decyzji, bez przypisywania rzeczywistemu klientowi błędów lub osiągniętych rezultatów.

Zdefiniuj warunki wdrożenia i powrotu

Przed uruchomieniem nowego wariantu zapisz warunki przejścia, osobę zatwierdzającą i sposób obserwacji po zmianie. Czasem można rozpocząć od ograniczonej grupy zadań. Wtedy trzeba określić granice, czas próby i kryterium rozszerzenia. Sam status „testy zaliczone” bez wskazania zestawu i ograniczeń nie daje wystarczającej podstawy do przekazania procesu innemu zespołowi. Jeżeli część prób przygotowuje lub uruchamia asystent kodujący, sprawdź komendę, asercję i rzeczywisty wynik testu.

Sprawdź, czy powrót do poprzedniego wariantu jest technicznie możliwy. Jeśli nie, przygotuj alternatywę, na przykład ręczne wykonanie lub ograniczenie funkcji. Zapisz, kto może zatrzymać automatyczne działania i jak rozpoznaje się zadania wymagające ponownego sprawdzenia. Przy całym przebiegu pomocny jest audyt automatyzacji procesu, obejmujący także kolejki i zadania w toku.

Zachowaj wynik, który da się odtworzyć

Pakiet odbioru powinien zawierać kartę zmiany, wersję zestawu, kryteria, surowe odpowiedzi, oceny, rozbieżności oraz decyzję. Ogranicz dostęp do materiałów zgodnie z ich zawartością. Ustal okres zachowania i właściciela aktualizacji. Przyszły przegląd potrzebuje informacji, dlaczego wariant dopuszczono, a nie tylko korzystnej liczby z raportu.

W raporcie pokaż przypadki poprawione, pogorszone i nierozstrzygnięte. Suma punktów nie powinna ukrywać istotnego błędu ani odmiennego skutku dla części zadań. Dodaj listę zastosowań pozostających poza oceną. Jeżeli test dotyczył podsumowań, nie traktuj go jako potwierdzenia wysyłki wiadomości, analizy innych dokumentów czy samodzielnych działań agenta. Każde rozszerzenie wymaga odpowiedniej podstawy.

Kiedy trzeba zmienić sam zestaw testowy?

Zestaw wymaga przeglądu, gdy zmieniają się użytkownicy, typ dokumentów lub sposób wykorzystania odpowiedzi. Stara próba może nadal dobrze porównywać wersje, a jednocześnie coraz słabiej opisywać bieżącą pracę. Zachowaj część wspólną, która pozwala śledzić ciągłość, i dodaj nowe przypadki odpowiadające aktualnemu zakresowi. Raport powinien rozróżniać wyniki dla obu grup.

Usuń albo popraw przypadek, jeśli jego źródło stało się nieaktualne lub wzorcowa odpowiedź zawiera błąd. Zachowaj uzasadnienie i datę tej decyzji. Nie traktuj jednak niewygodnego wyniku jako samodzielnej przyczyny wycofania próby. Najpierw ustal, czy test nadal odpowiada rzeczywistemu wymaganiu. W przeciwnym razie łatwo uzyskać pozorną poprawę przez zmianę pytania, zamiast przez poprawę rozwiązania. Przy odbiorze nowego zestawu poproś właściciela procesu o potwierdzenie, jakie decyzje nadal można na jego podstawie podjąć.

Przy większej aktualizacji zastosuj też porównanie przed zmianą modelu AI. Zachowaj te same przypadki i oddziel wpływ modelu od zmiany instrukcji lub źródeł. Jednoczesna wymiana wszystkich elementów utrudnia wyjaśnienie, skąd wziął się nowy wynik.

Jak zacząć w działającym zespole?

Wybierz najbliższą zmianę i niewielki, uzasadniony zestaw przypadków z obecnej pracy. Zapisz wynik odniesienia, kryteria i odpowiedzialność za odbiór. Jeśli nie ma wcześniejszych danych, nazwij ten etap budowaniem punktu odniesienia. Kolejne porównanie będzie wtedy miało realną podstawę. Nie trzeba czekać na rozbudowaną platformę testową, żeby uporządkować decyzję.

W warstwie Audit pokazujemy, jak wybrać zakres przeglądu.