Bramka jakości, w której LLM nie wydaje werdyktów

Na filmie testowym były jabłko, banan i butelka. Badane wydania modułu zapobiegania stratom nie wykrywały butelki, za to zgłaszały wazon, ptaka czy osobę. Potrzebowałem bramki, która zatrzyma takie wydanie i pokaże konkretny powód.

Budowałem dla klienta system autonomicznego testowania pipeline’ów analizy wideo dla handlu. Dostawca publikował nowe wersje jako obrazy Dockera. Mój system miał je uruchamiać, porównywać wyniki i pokazywać, co się pogorszyło. Z tej pracy wyniosłem zasadę: model może proponować, co sprawdzić, ale werdykt musi wyliczać kod. To samo dotyczy weryfikacji czułości testu.

Najpierw jasna reguła

System wykrywał nowe wydanie, pobierał obraz po digeście i uruchamiał go na filmie testowym. Zbierał detekcje, logi oraz dane o wydajności. Kod porównywał rozpoznane obiekty z oznaczeniami wzorcowymi i szukał pogorszenia względem wcześniejszych wersji. Wyniki trafiały do raportu i historii błędów.

Najbardziej użyteczna okazała się bramka, w której brak butelki oznaczał twardy błąd. Działała również przy pierwszym przebiegu, bez wcześniejszego wydania do porównania. Początkowo miała jednak dziurę: pojedyncze wykrycie butelki wystarczało, żeby przejść sprawdzenie. Po recenzji dodałem minimalny próg jej obecności w nagraniu.

Jednocześnie przestałem blokować wydania za każdy błąd wysokiej wagi. Blokadę zostawiłem wyłącznie dla twardego niepowodzenia testu. Wcześniejsza reguła powodowała znieczulenie na alarmy.

Bramka zablokowała wszystkie dziewięć przebadanych wydań modułu zapobiegania stratom. Raporty pokazywały brak butelki i wykrycia nieobecnych obiektów. Porównanie wersji ujawniło też regresję klasyfikacji, gubienie klatek oraz zapętlanie wejściowego klipu.

Nie każdy znaleziony problem był jednak regresją. Brak butelki powtarzał się w badanych wersjach i stanowił ich stałą słabość. Automatyczne odróżnianie stałego defektu od pogorszenia świadomie wstrzymałem: wczytywanie wydań poza kolejnością przekłamywało historię błędów.

Dużo testów, mało nowych odkryć

Kiedy dołożyłem testy generowane przez modele, wynik był skromniejszy, niż sugerowała liczba propozycji. Znalazłem jeden prawdziwy defekt, zgłaszany wielokrotnie, oraz użyteczne zabezpieczenia. Część czerwonych wyników pochodziła z samego środowiska testowego.

Ograniczeniem okazało się to, co udostępniałem modelowi. Adapter pozwalał mu operować właściwie tylko na geometrii ramek wykrytych obiektów. Model powielał więc podobne asercje dla pojedynczych klatek. Rozbudowałem adapter o znaczniki czasu, rozdzielczość, konfigurację wydania i etykiety modelu. Sprawdzenia uporządkowałem w rejestrze.

Modelowi zostawiłem wskazanie sprawdzenia i jego parametrów. Kod odbudowywał test i wykonywał porównanie. Przejął też dobór tolerancji, bo model przy kolejnych przebiegach tej samej wersji potrafił podawać zupełnie różne wartości. Kod wyznaczał najmniejszą tolerancję, przy której wersja odniesienia przechodziła test.

Samo przejście testu nie wystarczało jednak do jego przyjęcia. Potrzebowałem dowodu, że test wykryje błąd. Kod sprawdzał między innymi obecność rzeczywistej asercji i niezależnego źródła oczekiwanego wyniku. Czułość weryfikowałem przez celowe uszkadzanie danych: test miał przejść na wersji odniesienia i zareagować na wprowadzony błąd. W ten sposób rolę krytyka przejął kod.

Gdzie model rzeczywiście pomagał

W ślepym porównaniu większy model chmurowy proponował więcej wartościowych sprawdzeń niż model lokalny. Lokalny przegrywał między innymi dlatego, że odwoływał się do pól, których w artefaktach nie było.

Duży model miał więc dla mnie sens jako autor rejestru sprawdzeń zatwierdzanych przez człowieka. Podczas wykonywania testów wystarczał model lokalny, a bez niego system nadal mógł działać. LLM pomagał też proponować oznaczenia wzorcowe i pisać treść raportu.

O jakości całego rozwiązania decydowały przede wszystkim dane dostępne przez adapter oraz rejestr sprawdzeń. Najwięcej wartości przyniosła prosta bramka blokująca wadliwe wydanie z dowodem w raporcie. Rozbudowana pętla agentów nie dała porównywalnego przyrostu użytecznych wykryć.

Zostały przy tym wyraźne granice pomiarów. Nigdy nie miałem sprzętu docelowego producenta, więc metryki sprzętowe otrzymywały status NA. Wyniki z nagranych mocków oznaczałem osobno od rzeczywistych przebiegów. Nie zmierzyłem czasu pełnego przebiegu. Nie wiem też, czy dostawca wykorzystał raporty do naprawy regresji klasyfikacji.