Test symetrii: wdrażanie poprawki do promptu, której nie można odtworzyć

Nie zawsze można udowodnić, że poprawka do promptu działa. Niektóre awarie produkcyjne pojawiają się jedynie w pełnym kontekście, który je wygenerował, a żadne środowisko offline nie odtwarza ich wiarygodnie. Gdy tak się dzieje, uczciwe pytanie brzmi nie „czy poprawka działa”, ale „czy moja zmiana wyróżnia się na tle własnej zmienności modelu między kolejnymi uruchomieniami”. Jeśli odpowiedź brzmi „nie”, zmiana jest wystarczająco bezpieczna, aby ją wdrożyć, nawet jeśli nigdy nie udało się zaobserwować, jak naprawia błąd. Nazywamy to testem symetrii, a dzięki niemu poprawka do promptu, której nigdy nie udało się doprowadzić do awarii, przeszła przez naszą bramę.

Poniższy tekst pochodzi z jednej wewnętrznej oceny z 9 lipca 2026 roku, przeprowadzonej na modelu GLM-5.2, którego używamy w czacie: była to ślepa regresja A/B na całej powierzchni czatu. Metryki są nasze, mierzone na naszych własnych fixture'ach w tym dniu.

Błąd, którego nie można było odtworzyć

W ciągu tygodnia zaobserwowaliśmy dwa defekty generowania dokumentów w przypadku odpowiedzi w języku niemieckim dotyczących polityk. W pierwszym asystent dostarczył politykę, której główne sekcje były ponumerowane od 2 do 6, bez sekcji 1. W drugim przypadku załącznik, do którego się odnoszono, nigdy nie dotarł do modelu, a zamiast poinformować o tym, asystent sfabrykował „zmienioną wersję”, którą czytelnik uznał za poważne obcięcie tekstu, i nigdy nie ujawnił, że w rzeczywistości nie widział dokumentu.

Dla każdego z tych przypadków napisaliśmy regułę w promptach: niezmiennik numeracji (główne sekcje zaczynają się od 1 i są ciągłe) oraz regułę przeciwko fabrykacji (jeśli załącznik, do którego się odnosimy, nie jest obecny, poproś o niego, nie wymyślaj go). Następnie próbowaliśmy odtworzyć oryginalne awarie przy użyciu starego promptu, aby móc zaobserwować, jak nowe reguły je naprawiają.

Awaria numeracji nie dała się odtworzyć. W ponad dwudziestu generacjach przy użyciu starego promptu, włączając w to kształt wiadomości produkcyjnej, która wywołała raport, model GLM-5.2 zawsze zaczynał numerację od 1. Awaria nie występowała bez pełniejszego kontekstu, jaki miała sesja na żywo: nagromadzone wspomnienia użytkownika, długa wieloetapowa rozmowa oraz tryb rozumowania. Naszym zdaniem jeden lub więcej z tych elementów jest potrzebnych, aby ją wywołać. Pojedynczy, jednorazowy test offline nie miał ich, dlatego awaria po prostu nie wystąpiła.

To pułapka. Mieliśmy poprawkę do błędu, którego nie potrafiliśmy wywołać. Nie mogliśmy pokazać, że poprawka coś poprawia, ponieważ w teście offline nic nie było zepsute. Wdrażanie na wiarę nie jest dowodem. Blokowanie na zawsze, ponieważ nie można odtworzyć awarii, nie prowadzi do niczego. Obie te sytuacje są błędne.

Przemodelowanie: ogranicz promień rażenia, nie ścigaj poprawki

Reguła znajduje się w systemowym promptie na każdym etapie czatu, dlatego jej promień rażenia nie ogranicza się do „numeracji dokumentów”. Obejmuje każde zachowanie asystenta: pytania i odpowiedzi dotyczące ram, mapowanie między ramami, zastrzeżenia prawne, odmowy, odpowiedzi wielojęzyczne, ton. Edycja promptu skierowana na jeden tryb awarii może niepostrzeżenie uszkodzić inny, niepowiązany. To ryzyko warto zmierzyć, a w przeciwieństwie do oryginalnego błędu, jest ono mierzalne w trybie offline.

Dlatego przestaliśmy próbować udowodnić, że poprawka działa, i zaczęliśmy mierzyć ryzyko, jakie niesie ze sobą zmiana. Projekt: ślepa regresja A/B na całej powierzchni czatu, porównująca stary prompt z nowym na identycznych danych wejściowych.

• 42 fixture'e obejmujące pytania i odpowiedzi dotyczące zgodności, doradztwo, mapowanie ram, przekierowania usług, odmowy dotyczące bezpieczeństwa, zastrzeżenia prawne, wielojęzyczne odpowiedzi w języku niemieckim i francuskim, ton, generowanie dokumentów oraz dynamiczne fixture'e zawierające sekcje promptów niestandardowych instrukcji i przypiętych plików, które mają realni użytkownicy.
• 252 generacje, tworzące 126 par stare/nowe (trzy próbki na fixture), wszystkie na modelu GLM-5.2, 9 lipca 2026 roku.
• Ślepa próba. Każda para została zapisana jako A/B z losowym seedem etykiety. Manifest zawiera prawdziwe mapowanie stare/nowe i nigdy nie jest pokazywany oceniającym.
• Dwa poziomy oceny. Warstwa deterministyczna sprawdza warunki „musi” i „nie może” na fixture'ach z bramkami (przekierowania centrum pomocy działają, zastrzeżenia prawne są wyświetlane, próby wyodrębnienia promptu są odrzucane, umlauty są zachowane, minimalne długości są utrzymane). Ślepa warstwa jakościowa polega na tym, że oceniający czytają każdą parę bez wiedzy, która gałąź jest która i co się zmieniło, i oceniają, czy są równoważne, A lepsze, czy B lepsze z tagiem istotności.

Warstwa deterministyczna wypadła czysto: zero nieudanych odpowiedzi w żadnej gałęzi, zero asymetrycznych awarii. Nic, co reguła miała chronić, nie zepsuło się po żadnej stronie.

To warstwa jakościowa jest miejscem, w którym dzieje się ciekawa część.

Test symetrii

Ślepi oceniający uznali 118 z 126 par za równoważne. Spośród pozostałych ośmiu, siedem miało istotną różnicę, a jedna była drobną, nieistotną różnicą. Na pierwszy rzut oka siedem różnic w ocenie bezpieczeństwa to porażka.

To błędne odczytanie, a powód tkwi w kierunku. Istotna różnica ma znak: albo nowa gałąź była gorsza, albo stara gałąź była gorsza. Jeśli twoja zmiana w promptach powoduje regresje, istotne różnice są skierowane w jedną stronę, w kierunku „nowa gałąź gorsza”. Jeśli są to jedynie szum modelu między kolejnymi uruchomieniami i nie mają nic wspólnego ze zmianą, lądują w obu gałęziach mniej więcej z równą częstotliwością. Dlatego nie licz tylko istotnych różnic. Odtajniaj je i licz kierunek.

My to zrobiliśmy. Siedem podzieliło się na trzy „nowa gorsza”, cztery „stara gorsza”. Trzy przeciwko czterem to jak najbliżej równego podziału, jaki może dać siedem, wzór, którego należałoby oczekiwać od szumu między uruchomieniami, a nie regresji skierowanej w jedną stronę. Żadna z siedmiu nie miała żadnego prawdopodobnego związku z regułą numeracji dokumentów:

Istotna różnica	Gorsza gałąź	Co zaobserwowaliśmy
Identyfikator klauzuli ISO 27001	nowa	A.8.2 odczytane jako kontrola oceny ryzyka (prawidłowo w dwóch innych próbkach tego fixture'a)
Segmentacja PCI DSS	nowa	segmentacja nadmiernie określona jako ściśle wymagana
Segmentacja PCI DSS	stara	sfabrykowany „Załącznik A1 wymóg segmentacji”
Dokument niemiecki (przeciek CJK)	stara	przypadkowy chiński token w niemieckim tekście zamykającym
Dokument niemiecki (przeciek CJK)	stara	chińskie znaki w niemieckim podsumowaniu
Instrukcja dotycząca zwięzłości	nowa	zepsucie „wyjątkowo zwięzłej” instrukcji niestandardowej
Instrukcja dotycząca zwięzłości	stara	zepsucie „wyjątkowo zwięzłej” instrukcji niestandardowej

Najbardziej wymowny, nasz jedyny przykład, który utkwił w pamięci, to przecieki CJK: w dwóch naszych fixture'ach niemieckich wynik zawierał przypadkowy chiński token (w jednym przypadku znaki oznaczające „bezpieczeństwo informacji”) w inaczej niemieckim dokumencie. To zachowanie związane z przeciekiem tokenów pojawiało się w obu gałęziach w naszych przebiegach niemieckich. W tym przypadku oba przypadki trafiły do starej gałęzi. Gdyby nowa reguła pogarszała wyniki w języku niemieckim, spodziewalibyśmy się ich w nowej gałęzi; one tam nie wystąpiły.

Przypadki precyzji regulacyjnej wskazują w tym samym kierunku. W ISO/IEC 27001:2022 (opublikowana 25 października 2022 r.) załącznik A kontrola 8.2 to „Uprawnienia dostępu uprzywilejowanego”; jedna próbka nowej gałęzi odczytała ją jako kontrolę oceny ryzyka i była to poprawna odpowiedź w dwóch innych próbkach tego samego fixture'a. Według PCI DSS v4.0 (PCI Security Standards Council, marzec 2022 r.) segmentacja sieci nie jest wymogiem bezwzględnym, jest techniką redukcji zakresu, którą Rada opisuje jako sposób na wyłączenie systemów poza zakres oceny, a nie wymagany środek kontrolny; jedna próbka nowej gałęzi nadmiernie określiła ją jako wymaganą, a jedna próbka starej gałęzi wymyśliła, że „Załącznik A1” to wymóg segmentacji. Załącznik A1 to w rzeczywistości dodatkowe wymogi dla dostawców usług wielotenantowych. To rodzaj chwiejnej dokładności, jaką generuje model probabilistyczny w trudnych kwestiach domenowych, a w tym przebiegu trafiły one do obu gałęzi, nie koncentrując się na naszej zmianie.

Tymczasem zachowania, które miała naprawić sama zmiana, utrzymywały się w obu gałęziach przez cały czas: w każdej parze brakującego załącznika model prosił o dokument zamiast go fabrykować, a w każdej parze numeracji struktura była ciągła. W całej ocenie 126 ślepych par plus deterministyczne sprawdzenia na tej samej powierzchni nie znaleźliśmy żadnej awarii przypisywalnej zmianie.

Co to udowadnia i czego nie udowadnia

Bądź precyzyjny w swoich twierdzeniach, ponieważ łatwo je przesadzić. Ta ocena pokazuje brak mierzalnej regresji przy tej wielkości próbki, a nie to, że poprawka działa. Nigdy nie udowodniliśmy, że reguła numeracji naprawia błąd numeracji, ponieważ błąd wymaga kontekstu produkcyjnego, którego nie mogliśmy odtworzyć. Zmiana jest wdrażana na dwóch nogach: analiza kryminalistyczna produkcji, która czyni awarię czytelną, oraz sygnał braku regresji pokazujący, że zmiana niczego innego nie zakłóca. To słabsze twierdzenie niż „odtworzyliśmy błąd i zaobserwowaliśmy, jak poprawka go usuwa”, i jest to najmocniejsze twierdzenie, jakie sytuacja pozwala.

Ograniczenia są realne i warto je jasno określić. Duża, skierowana regresja ujawniłaby się przy trzech próbkach na fixture; subtelna nie, ponieważ 55/45 nie jest widoczne przy tej wielkości próbki, a trzy próbki na 42 fixture'e są grupowane, a nie 126 niezależnymi próbami. Nie uruchomiliśmy kontroli stare-stare, dlatego podział trzy-cztery jest naszym najlepszym oszacowaniem szumu bazowego, a nie zmierzoną wartością bazową, i bez ustalonego z góry marginesu równoważności jest to sygnał braku skierowanej regresji, a nie formalny test niegorszości. Fixture'e są jednorazowe, dlatego interakcja między nową regułą a długą produkcją wątków wykracza poza zakres, co jest dokładnie kontekstem, którego potrzebował oryginalny błąd. Symetryczny podział jest dowodem, że zmiana nie popchnęła wyników w jednym kierunku, a nie dowodem, że jest nieszkodliwa. To, co test kupuje, to konkretny wgląd w promień rażenia, gdy alternatywą było przeczucie.

Przenośna lista kontrolna

Gdy masz poprawkę do promptu dla błędu produkcyjnego, którego nie można odtworzyć w trybie offline, nie wdrażaj jej na wiarę i nie blokuj postępu. Ogranicz zmianę zamiast tego:

• Oddziel dwa pytania. „Czy poprawka działa” wymaga błędu, którego nie można odtworzyć. „Czy zmiana jest bezpieczna” nie. Odpowiedz na to, na które możesz odpowiedzieć.
• Uczciwie oszacuj promień rażenia. Reguła w współdzielonym systemowym promptie dotyka każdego zachowania, a nie tylko tego docelowego. Twórz fixture'e na całej powierzchni, włączając w to warianty niestandardowych instrukcji i przypiętego kontekstu, które mają realni użytkownicy.
• Przeprowadź ślepy test parowany. Te same dane wejściowe, stary versus nowy, losowo przypisane etykiety A/B oraz manifest, którego oceniający nigdy nie widzą. Ślepa próba powstrzymuje cię przed oceną tej gałęzi, którą chcesz, aby wygrała.
• Liczy się kierunek, nie tylko różnica. Odtajniaj istotne różnice i sprawdzaj znak. Asymetria w kierunku „nowa gorsza” to regresja. Mniej więcej równy podział między obiema gałęziami to wzór, który pozwala na zmianę przy tym poziomie dowodów.
• Dodaj powtórzoną kontrolę, jeśli margines jest wąski. Gałąź stary-stary mierzy twoją bazową zmienność bezpośrednio, dlatego porównujesz swoją zmianę do liczby, a nie założenia.
• Zachowaj deterministyczny próg. Połącz ocenę jakościową z twardymi sprawdzianami „musi” i „nie może” dla zachowań, które nigdy nie mogą ulec awarii, aby werdykt o symetrycznym szumie nie mógł zamaskować realnie zepsutego niezmiennika.
• Określ twierdzenie, które naprawdę posiadasz. Mów „brak mierzalnej regresji”, a nie „poprawka działa”, gdy nieudowodniona jest jedynie nie-recesja.

Instynkt, gdy błąd nie daje się odtworzyć, nakazuje próbować go dalej, aż się zepsuje. Czasami nigdy się to nie uda, a wysiłek idzie w złym kierunku. To, czy poprawka zostanie wdrożona, zależy od tego, czy twoja zmiana jest głośniejsza niż własny szum modelu między uruchomieniami. Zmierz to bezpośrednio, a poprawka do promptu, której nigdy nie udało się zaobserwować, że działa, może stać się tą, w której możesz być pewny, że jest bezpieczna.