Samonaprawiające się metryki: kiedy zielona ocena ukrywa prawdziwą regresję
W naszej wielodokumentowej ocenie głębokości (2026-06-04, GLM-4.7) metryka mapowania klauzul osiągnęła niemal doskonałe 1,0, podczas gdy analiza dokumentu na dokument spadła do około jednej trzeciej jego samodzielnej głębokości. Oczywista metryka była tą, która kłamała.
Najbardziej niebezpieczną liczbą w ocenie jest ta, która pozostaje zielona, podczas gdy produkt się psuje. Mamy taką. W dokładnym przebiegu, w którym analiza dokumentu na dokument naszego modelu spadła do około jednej trzeciej jego samodzielnej głębokości, metryka parytetu osiągnęła niemal doskonałe 1,0. Metryka nie była zakłócona ani źle skalibrowana. Mierzyła niewłaściwą rzecz w sposób, który model mógł spełnić bez wykonywania pracy. Nazywamy to samonaprawiającą się metryką, a jej znalezienie było najbardziej użyteczną rzeczą, jaką nasz zestaw ocen zrobił tamtego tygodnia.
Co testowaliśmy
Typowym zadaniem w naszym produkcie jest analiza wielodokumentowa: użytkownik przesyła kilka dokumentów polityki naraz i prosi asystenta o mapowanie każdego z nich względem klauzul ramy, na przykład kontroli załącznika A normy ISO/IEC 27001:2022. Jeden z klientów poinformował nas, że analiza kilku dokumentów w jednym żądaniu daje cieńsze wyniki niż analiza każdego dokumentu osobno. Zanim cokolwiek zmieniliśmy, zbudowaliśmy ocenę, aby odtworzyć i zmierzyć tę lukę (wewnętrzny ticket ISM-549, przebieg bazowy 2026-06-04).
Konfiguracja była wiernie odwzorowana na produkcję. Model: GLM-4.7, dostarczany przez OpenRouter, dopasowany do ocenianej ścieżki żądania. Fixtures: siedem syntetycznych, zanonimizowanych polityk (brak treści klienta), ukształtowanych jak realny scenariusz, który wywołał skargę. Pytanie, na które ocena miała odpowiedzieć, było proste: czy każdy dokument otrzymuje taką samą głębokość analizy, gdy analizowanych jest siedem dokumentów razem, jak wtedy, gdy każdy jest analizowany osobno?
Pierwsza metryka i dlaczego się samonaprawiała
Oczywistym sposobem na ocenę „czy każdy dokument został przeanalizowany” jest zliczenie wierszy mapowania klauzul. Analiza samodzielna generuje tabelę z jednym wierszem na klauzulę, więc analiza grupowa powinna również. Najpierw wypróbowaliśmy dokładnie to.
Parytet wierszy wyniósł około 1,0. Biorąc pod uwagę wyraźnie ponumerowane klauzule i instrukcję „mapuj każdą klauzulę”, GLM-4.7 sumiennie utrzymuje jeden wiersz tabeli na klauzulę, nawet gdy przesyłasz mu naraz siedem dokumentów. Według tej metryki nic nie było nie tak. Ocena była gotowa do zaliczenia.
Produkt był wyraźnie gorszy. Wiersze były obecne; analiza wokół nich zniknęła. Samodzielnie każdy wiersz klauzuli zawierał wyjaśnienie, mocne strony, luki i krótkie podsumowanie. W grupie model zachował szkielet i pozbawił mięśni: ta sama forma tabeli, znacznie mniej per-klauzulowego rozumowania. Metryka samonaprawiła się. Wynik spełniał „jeden wiersz na klauzulę”, jednocześnie znacznie ograniczając per-klauzulową analizę, a zliczanie wierszy nie jest w stanie odróżnić pełnej analizy od pustej.
Co pokazała lepsza metryka
Przestaliśmy więc oceniać strukturę i zaczęliśmy oceniać treść. Główną metryką stała się parytet objętości treści: pogrupowane znaki wyjściowe podzielone przez sumę znaków wyjściowych z analiz samodzielnych, z progiem zaliczenia na poziomie 0,6. W przebiegu bazowym z 2026-06-04 (GLM-4.7, dwie próbki):
| Miara | Próbka 1 | Próbka 2 |
|---|---|---|
| Paritet objętości treści | 0,34 | 0,35 |
| Znaki samodzielne | 48 263 | 47 651 |
| Znaki grupowe | 16 201 | 16 609 |
| Paritet wierszy mapowania klauzul | 1,00 | 0,98 |
| Sędzia LLM: dokumenty ocenione jako nierozcieńczone | 0 na 7 | 0 na 7 |
W tym samym przebiegu bazowym z 2026-06-04, proxy głębokości na poziomie tokenów opowiadało tę samą historię: około 2747 tokenów wyjściowych dla jednego dokumentu wobec około 595 tokenów na dokument, gdy analizowanych było siedem, co daje współczynnik na dokument na poziomie 0,22.
Trzy szczegóły mają tutaj znaczenie. Paritet objętości treści wyniósł 0,34, znacznie poniżej progu 0,6. Niezależny sędzia LLM, proszony jedynie o ocenę, czy analiza każdego dokumentu jest rozcieńczona czy nie, uznał 0 z 7 dokumentów za nierozcieńczone w obu próbkach. Paritet wierszy, metryka, którą prawie wdrożyliśmy, średnio wyniósł 0,99 w obu próbkach (od 0,98 do 1,00). Trzy sygnały dotyczące treści wskazywały w tym samym kierunku: paritet objętości treści na poziomie około jednej trzeciej, proxy tokenów jeszcze niższe na poziomie 0,22 na dokument, a sędzia uznał każdy pogrupowany dokument za rozcieńczony. Jedynym instrumentem, który się nie zgodził, była strukturalna liczba wierszy.
Dlaczego to się dzieje i ograniczenia naszej wiedzy
Nasze odczytanie danych sugeruje, że GLM-4.7 samodzielnie dzieli swój wysiłek między dokumenty podczas pojedynczego dekodowania: proszony o wykonanie siedmiu analiz w jednej odpowiedzi, rozkłada mniej więcej stałe zasoby, zamiast generować siedem pełnych analiz. Nie instrumentowaliśmy wewnętrznych mechanizmów modelu, więc jest to opis zachowania, które zmierzyliśmy, a nie udowodniony mechanizm, i jest ono specyficzne dla tego modelu i kształtu żądania. Dwa fakty dotyczące zakresu są kluczowe. Regresja pojawia się w skali produkcyjnej: ujawnia się przy siedmiu dokumentach, a nie przy dwóch, więc test dymny na małym wejściu przeszedłby czysto. Nie odtworzyła się również, gdy uruchomiliśmy te same fixtures na modelu wiodącym przez bezpośrednie API. Regresja pojawiła się jedynie na dokładnym modelu i ścieżce żądania, które oceniamy i wdrażamy, co jest całym argumentem za oceną ścieżki, którą faktycznie uruchamiasz, zamiast dogodnego zastępnika.
Dlaczego to jest gorsze w zgodności niż gdzie indziej
W większości produktów „płytsze wyniki” to jedynie kosmetyczny problem jakości. W naszych przepływach pracy związanych ze zgodnością nie jest to kosmetyka: tabela mapowania kontroli z obecnymi wierszami i bez analizy wygląda na kompletna na zrzucie ekranu, podczas gdy nie dostarcza audytorowi żadnego per-klauzulowego rozumowania, na którym mógłby polegać. To właśnie sprawia, że samonaprawiająca się metryka jest tutaj naprawdę niebezpieczna. Nie była jedynie niedokładna. Była zielona dokładnie w przypadku awarii, który ma największe znaczenie w naszej dziedzinie: pewny wygląd dostarczanego materiału z cicho usuniętą treścią.
Naprawa, która wynika z tego odkrycia, polega na wykonaniu pełnej analizy o pełnej głębokości dla każdego dokumentu osobno zamiast składania wszystkich siedmiu w jedno dekodowanie, a ocena zalicza się od razu, gdy to zrobimy. Ale naprawa to łatwa część. Nie moglibyśmy jej zbudować, gdy nasza główna metryka upierała się, że nic się nie zepsuło. Zmiana metryki musiała nadejść pierwsza, ponieważ nie można naprawić tego, czego się nie widzi.
Jak złapać samonaprawiającą się metrykę
Samonaprawiająca się metryka to każda metryka, którą model może spełnić bez wykonania podstawowej pracy. Najbardziej podatne na to są metryki strukturalne: zliczenia wierszy, zliczenia elementów, „prawidłowy JSON”, „wszystkie wymagane pola obecne”, nagłówki sekcji. Są tanie w obliczeniu i tanie do oszukania, często przez sam model, a nie przez Ciebie. Zanim zaufasz którejś z nich, przeprowadź te kontrole:
- Oceniaj treść, a nie tylko kształt. Jeśli metryka sprawdza jedynie strukturę (wiersze, pola, nagłówki), połącz ją z taką, która sprawdza treść (znaki, tokeny lub ocenę sędziego dotyczącą gruntowności). Kształt jest konieczny, nigdy niewystarczający.
- Dodaj niezależny instrument. Tani sędzia LLM, który ocenia jakość i nie zgadza się z Twoją główną metryką, to sygnał, którego szukasz. Zgodność to potwierdzenie; rozbieżność oznacza, że Twoja metryka strukturalna prawdopodobnie się samonaprawia.
- Testuj w skali produkcyjnej. Regresja, która pojawia się jedynie przy siedmiu dokumentach, przejdzie przy dwóch. Dobierz wielkość fixtures tak, aby odpowiadała realnemu wejściu, a nie testowi jednostkowemu.
- Testuj model i ścieżkę, którą wdrażasz. Nasze rozcieńczenie nie odtworzyło się na innym modelu ani przez bezpośrednie API. Łatwiejszy do uruchomienia proxy to proxy, które może pominąć błąd występujący jedynie na Twojej ścieżce produkcyjnej.
- Zastanów się, jak wyglądałoby najtańsze przejście. Jeśli model mógłby spełnić Twoją metrykę, wykonując prawie żadnej realnej pracy, zakładaj, że prędzej czy później to zrobi. Zaprojektuj metrykę tak, aby najtańszym sposobem na jej zaliczenie było faktyczne wykonanie zadania.
Ocena ostatecznie spełniła swoją rolę, ale dopiero wtedy, gdy przestaliśmy ufać pochlebnej liczbie. Gdy metryka jest zielona, bardziej użyteczne pytanie brzmi nie „czy zaliczamy”, ale „czy model może zaliczyć to bez wykonywania pracy”. Jeśli odpowiedź brzmi „tak”, metryka się samonaprawia i będzie to robić aż do momentu, gdy klient jako pierwszy to zauważy.
Powyższe dane pochodzą z naszego wewnętrznego przebiegu bazowego dotyczącego parytetu głębokości wielodokumentowej, uruchomionego 2026-06-04 na GLM-4.7 przez OpenRouter, i są punktowe w czasie na dzień tej daty. Kontekst ramy: ISO/IEC 27001:2022, Załącznik A.