Weryfikator niewidomy: co może widzieć nasza bramka anty-fabrykacji

W lipcu 2026 roku przetestowaliśmy weryfikator chroniący nasz wieloetapowy potok zgodności przed fabrykacją, wprowadzając fałszywe informacje do jego danych wejściowych. Większość wprowadzonych fałszerstw przeszła przez system. Wynik ten wyglądał jak luka w zabezpieczeniach w jedynym komponencie, którego zadaniem jest wykrywanie fałszerstw. Tak jednak nie było, a powodem była zasada projektowa, którą obecnie traktujemy jako stałą zasadę.

Test polegał na wprowadzeniu fałszywych informacji do briefu rozumowania, czyli dokumentu, który weryfikator ma traktować jako ustaloną prawdę, a następnie sprawdzaniu, ile z nich zostało wykrytych. Mierzony w ten sposób, weryfikator nie mógłby zdać testu kompetencji dotyczącego wykrywania fałszerstw. Tymczasem naprawa, do której wszyscy byliby skłonni sięgnąć — pozwolenie weryfikatorowi na flagowanie każdej informacji w wersji roboczej, której nie ma w briefie — okazała się gorsza niż brak wykrywania fałszerstw: wobec czystych wersji roboczych flagowała 9 na 9 w przypadku jednej rodziny modeli i 3 na 9 w przypadku drugiej. Natomiast wąski kontrakt, który zachowaliśmy, wykrył podczas rzeczywistego uruchomienia w produkcji klasę błędów, którą miał wykrywać zgodnie ze swoim zakresem: cytat, który wersja robocza zawierała, a który nie występował w zatwierdzonym zbiorze briefu.

Nazywamy tę zasadę weryfikatorem niewidomym: bramka anty-fabrykacji musi być ograniczona do tego, co może rzeczywiście zobaczyć. Jedyna zmiana, którą zmierzyliśmy, oceniała prawdziwość bez dostępu do źródeł i flagowała większość czystych wersji roboczych, nie wykrywając żadnych fałszerstw, które miały być jej motywacją. Sprawdzanie uczciwości musi być mechaniczne, a mechaniczne oznacza, że odpowiedź tkwi w danych wejściowych.

Test, który nas okłamał

Potok to Beyond, nasz wieloetapowy tryb generowania dokumentów. Model planujący odczytuje zadanie i tworzy brief rozumowania. Model wykonawczy renderuje każdy zaplanowany krok względem tego briefu. Model weryfikatora ocenia każdą wersję roboczą kroku przed jej udostępnieniem użytkownikowi. (Czwarty etap, podsumowujący ukończone uruchomienie, nie odgrywa roli w tej historii.) Trzy role oceny otrzymują różne dane wejściowe, a ta różnica jest głównym punktem tego wpisu.

Nasz weryfikator jest celowo niewidomy. Zarówno model planujący, jak i wykonawczy widzą pełny kontekst: historię rozmowy, pamięci robocze, pliki robocze, przesłaną zawartość dokumentów oraz wstrzykniętą wiedzę ramową. Weryfikator widzi tylko dwa dokumenty: brief i recenzowaną wersję roboczą. Jego kontrakt traktuje fakty i osądy zawarte w briefie jako ustalone, a jego zadaniem jest sprawdzenie, czy wersja robocza pozostała wierna tym ustaleniom.

Test laboratoryjny naruszył to założenie, nie zdając sobie z tego sprawy. Ręcznie wprowadziliśmy fałszywe informacje do samego briefu, uruchomiliśmy weryfikator i policzyliśmy, ile wprowadzonych fałszerstw zostało wykrytych. Wykryto niewiele; większość fałszerstw przeszła. Nazwaliśmy weryfikator uszkodzonym. W rzeczywistości eksperyment zmierzył, czy weryfikator zakwestionuje dokument, któremu ma ufać. Odmówił, zgodnie z projektem.

W tym samym czasie w produkcji pojawił się rzekomy dowód rzeczowy: organizacyjny fakt w udostępnionym wyniku, którego nie zawierał żaden sprawdzony przez nas dokument wejściowy. Zanim wdrożyliśmy poprawkę, sami ją wycofaliśmy: „sfabrykowany” fakt znajdował się w przesłanym pliku, który wykonawca prawidłowo odczytał. Fakt był ugruntowany. Nasza szybka kontrola, podobnie jak weryfikator, po prostu nie sprawdziła tego pliku. Badacz, który nie widzi źródeł, również nie może ocenić ugruntowania. Przeprowadziliśmy ten sam błędny eksperyment na sobie, który przeprowadziliśmy na modelu.

Pułapka, którą zmierzyliśmy

Postanowiliśmy więc skupić się na stronie wersji roboczej, gdzie dane wejściowe weryfikatora rzeczywiście się różnią. Intuicyjna poprawka: flaguj każde stwierdzenie faktograficzne w wersji roboczej, którego nie ma w briefie. Zbudowaliśmy dokładnie takie regułę i zmierzyliśmy ją wobec czystych wersji roboczych, czyli wersji niezawierających żadnych fałszerstw, wygenerowanych przez rodziny modeli używane wówczas w potoku. Pomiary i decyzję o odrzuceniu reguły zapisano w komentarzu projektowym kontraktu i historii commitów; prace zostały przeprowadzone i udokumentowane podczas sesji przeglądu z 22 lipca 2026 roku:

Reguła w teście	Czyste wersje robocze flagowane	Wersje robocze wygenerowane przez
Flaguj stwierdzenia faktograficzne w wersji roboczej, których nie ma w briefie	9 na 9	GLM 5.2
Flaguj stwierdzenia faktograficzne w wersji roboczej, których nie ma w briefie	3 na 9	Grok 4.20

Brama, która odrzuca większość lub wszystkie czyste wersje robocze, nie jest bramą; jest awarią. W przypadku GLM 5.2 każda przetestowana czysta wersja robocza co najmniej wywołałaby ponowne renderowanie; tego, co drugi nieudany weryfikator następnie wyprodukowałby (flagę zastrzeżenia lub zatrzymanie), nie zmierzyliśmy. Mechanizm jest strukturalny. Stwierdzenie w wersji roboczej, którego nie ma w briefie, nie jest dowodem fabrykacji, ponieważ wykonawca, zgodnie z projektem, może ugruntować fakty w źródłach, których weryfikator nie widzi. Aby odpowiedzieć na pytanie „czy to twierdzenie jest prawdziwe?”, niewidomy weryfikator dysponuje jedynie swoimi wcześniejszymi przekonaniami, a prace zgodnościowe to domena, w której wcześniejsze przekonania zawodzą w obu kierunkach: prawdziwe fakty są specyficzne dla przestrzeni roboczej klienta, a fałszywe są prawdopodobne.

Należy zauważyć, czego rozszerzona reguła również nie mogła zrobić: wykryć żadnego fałszerstwa z testu laboratoryjnego, ponieważ te fałszerstwa znajdowały się w briefie, który zarówno wąski kontrakt, jak i rozszerzona reguła traktują jako prawdę. Z konstrukcji rozszerzenie nie dodało żadnej czułości w tej klasie; nasze pomiary na czystych wersjach roboczych pokazały, co faktycznie dodało. To właśnie ta para wyników przekonała nas, że problemem jest mandat, a nie model.

Kontrakt, który przetrwał

To, co weryfikatorowi wolno oceniać, zapisano w jego wdrożonym promencie, a granica jest ostra. W ramach kroku weryfikator egzekwuje dwa kontrakty i nic więcej:

1. Własny kontrakt kroku: wersja robocza spełnia wymagania określone w tytule kroku i specyfikacji treści. Brak treści jest naruszeniem tylko wtedy, gdy specyfikacja kroku tego wymaga.
2. Globalne ograniczenia wynikające z briefu i cytowań, gdzie jedynie trzy rzeczy stanowią naruszenia:
   • sprzeczność: stwierdzenie w wersji roboczej, które bezpośrednio zaprzecza punktowi osądu lub specyfikacji kroku,
   • zmienione cytowanie: cytowanie z briefu odtworzone nieprawidłowo (błędny punkt, artykuł lub brzmienie wymogu),
   • wymyślone cytowanie lub wymóg: cytowanie ramowe lub wymóg stwierdzony w wersji roboczej, którego nie zawiera brief.

Brak czegoś nigdy nie stanowi naruszenia globalnych ograniczeń. Brief kieruje treścią między krokami; krok dotyczący wiadomości e-mail od interesariusza prawidłowo pomija cytowania na poziomie klauzul, które należą do kroku polityki. Weryfikator nie ocenia stylu, tonu, długości ani ogólnej jakości. Prosta wersja robocza, która jest wierna swojemu krokowi, przechodzi.

Takie ukształtowanie wymuszone było przez pomiary, dwukrotnie. Po pierwsze, kalibracja na rzeczywistym użyciu 11 czerwca 2026 roku, na topologii uruchomieniowej, której weryfikatorem był Claude Haiku 4.5 (zestaw zadań sesji nie został zapisany w trwałym dzienniku; trwałym zapisem jest poniższe zestawienie problemów): z 12 zgłoszonych problemów weryfikatora podczas rzeczywistego użytkowania 2 były realne, a 10 stanowiły nadmiernie dosłowne flagi na wersjach roboczych, które były faktycznie wierne. (Ten wskaźnik liczy flagowane problemy, a nie odrzucenia czystych wersji roboczych.) Po drugie, pomiary 9 na 9 i 3 na 9 czystych wersji roboczych opisane powyżej. Oba pomiary potępiły szerszy mandat, każdy na swoim własnym osi fałszywie dodatnich; wąski zakres pozostał skierowany na klasę błędów, która ma znaczenie.

Ograniczenie nie jest słabością. To właśnie ono utrzymuje kontrolę w odpowiedzi. „Czy ta wersja robocza zaprzecza briefowi?” to pytanie, na które odpowiedź tkwi całkowicie w dwóch dokumentach przed weryfikatorem; żadne zewnętrzne fakty nie są potrzebne, aby je rozstrzygnąć. „Czy to twierdzenie jest prawdziwe?” nie jest pytaniem tego rodzaju, a żadne inżynierowanie prompty, które zmierzyliśmy, nie zamienia go w takie.

Co zamiast tego wykrywa fabrykację

Jeśli niewidomy weryfikator sprawdza jedynie wierność, co stoi między użytkownikiem a sfabrykowanym wynikiem? Trzy warstwy, każda ograniczona do kontroli, która nie wymaga faktów poza swoimi danymi wejściowymi:

Cytowania wobec listy zamkniętej. Brief zawiera jawny zestaw cytowań. Instrukcje wykonawcy mówią: odtwórz cytowania z briefu dokładnie tak, jak są zapisane; nigdy nie pomijaj, nie zmieniaj ani nie wymyślaj cytowań ramowych. To, czy numer klauzuli należy do skończonej, znanej listy, można sprawdzić bez oglądania żadnego źródła. W dziedzinie zgodności taki świat zamknięty jest właściwym celem: niebezpiecznym wynikiem nie jest parafraza, lecz cytowanie tekstu, którego zatwierdzony zestaw nie upoważnia.

Brama integralności tam, gdzie źródło istnieje. W uruchomieniach, które przeprowadzały badania internetowe, potok dodatkowo sprawdza adresy URL i ceny wyników względem zatwierdzonego zestawu dowodów, ponieważ tam prawda jest dostępna i ograniczona.

Rurociąg fail-closed z jedną celową wyjątkiem. Werdykt weryfikatora jest jedynym czytelnym maszynowo wynikiem w potoku, obiektem JSON ze ściśle określoną wartością logiczną pass oraz listą problemów, która musi się z nią zgadzać. Werdykt, którego nie można sparsować, zatrzymuje, nigdy nie przechodzi. Nieudany werdykt uruchamia dokładnie jedno ponowne renderowanie z listą problemów, a następnie ponowną weryfikację; drugi niepowodzenie zwalnia krok z flagą zastrzeżenia, po dwukrotnej inspekcji. Awaria weryfikatora lub nieparsowalny werdykt otrzymuje jedną próbę ponowienia, po której zatrzymuje uruchomienie, a krok w trakcie nie jest nigdy zwalniany. Wyjątek ma znaczenie i warto go dokładnie określić: fail-closed dotyczy inspekcji, a nie poprawności. Przejście oznacza, że weryfikator nie wykrył żadnego naruszenia kontraktu, co nie jest gwarancją prawdziwości od niedoskonałego modelu, a dwukrotnie nieudana wersja robocza z flagą nie przeszła niczego.

Przechwycenie, na żywo

2 września 2026 roku uruchomiliśmy sondę jednego zadania przez nasz potok produkcyjny na własnym płatnym koncie: zadanie napisane przez nas samych, bez przesłanego materiału klienta. Celem było sprawdzenie topologii czterech ról w teście z tamtego dnia, która uruchomiła każdą rolę na GLM 5.3 (wysoki wysiłek na planerze, niski na wykonawcy, weryfikatorze i podsumowaniu). Zadanie: przygotować krótki zarys polityki ewidencji aktywów dla ISO/IEC 27001:2022 Załącznik A, jedna strona.

Wersja robocza wykonawcy cytowała klauzule 9.2 i 9.3 ISO/IEC 2701:2022, klauzule dotyczące audytu wewnętrznego i przeglądu zarządzania. Obie klauzule istnieją w standardzie; cytowanie jest dokładnie tym, czego należałoby się spodziewać w kompetentnym dokumencie zgodności. Problem jest kontraktowy, a nie faktograficzny: zatwierdzony zestaw cytowań w briefie ich nie zawierał, co czyni je wymyślonymi cytowaniami w rozumieniu kontraktu, cytowaniami stwierdzonymi w wersji roboczej, których brief nie upoważnia. Weryfikator zwrócił werdykt niepowodzenia, wskazując problem; wykonawca ponownie wyrenderował z cytowaniami przywróconymi do zatwierdzonego zestawu, a druga próba przeszła. Uruchomienie zakończyło się w 155 sekundach bez zastrzeżeń i bez obcięć, wszystkie wywołania na GLM 5.3.

Dwie właściwości tego przechwycenia mają większe znaczenie niż anegdota. Po pierwsze, klasa: faktyczna awaria, która wystąpiła w produkcji, to było cytowanie wykraczające poza zatwierdzony zestaw, dokładnie ta klasa naruszeń, którą sprawdza niewidoma kontrola, a nie ręcznie wprowadzony fakt. Po drugie, wielkość kontroli: weryfikator działał przy niskim wysiłku rozumowania i widział dwa dokumenty. W tym samym tygodniu oceny topologii (1 września 2026: pięć trudnych zadań obejmujących dyscyplinę zakresu, pominięcie odbiorcy, poprawność cytowań, spójność między dokumentami i obsługę niezweryfikowanych dowodów; trzy próby na zadanie na ramię; 30 uruchomień łącznie na dwóch ramionach, GLM 5.3 i ramię proxy Grok 4.20), ramię GLM 5.3 weryfikatora zwróciło parsowalny, ściśle określony werdykt JSON we wszystkich 15 swoich uruchomieniach, z zerowym zatrzymaniem. Ocena była niezależna: Claude Haiku 4.5 uruchomiony przez OpenRouter. Brama, która przechwyciła awarię produkcyjną, jest najbardziej ograniczonym wywołaniem modelu w potoku.

Co to nie oznacza

Przechwycenie produkcyjne to jeden punkt danych z celowej sondy, a nie szacunek wskaźnika. Harness testu laboratoryjnego był wewnętrznym plikiem roboczym, którego nie zachowaliśmy; popieramy jego jakościowy wynik (większość wprowadzonych fałszerstw przeszła, szacowany wskaźnik wykrycia około jednego na cztery w tamtym czasie), ale nie publikujemy go jako precyzyjnego pomiaru, ponieważ artefakty, wersje modeli i zestaw zadań za nim nie były zamrożone. Trwały zapis testu rozszerzonej reguły to pomiary 9 na 9 i 3 na 9 czystych wersji roboczych w komentarzu kontraktu wdrożonego, zmierzone i zapisane 22 lipca 2026; zapis wymienia rodziny modeli generujących wersje robocze (GLM 5.2, Grok 4.20), ale nie nazywa modelu weryfikatora ani zestawu zadań, dlatego przypisujemy jedynie wersje robocze i nie przeprowadziliśmy ponownego testu na innych rodzinach. Dochodzenie wycofanej awarii z lipca poprzedza naszą obecną dyscyplinę dowodową, dlatego opisujemy je bez identyfikatorów uruchomień ani przypisania modelu. Pozostałe ryzyko jest realne i udokumentowane w repozytorium: w uruchomieniach bez badań internetowych wymyślony fakt organizacyjny przez wykonawcę, jako odrębny od wymyślonego cytowania, nadal nie ma zautomatyzowanej bramki, a nie zmierzyliśmy, jak często to występuje; naprawienie tego wymagałoby przekazania weryfikatorowi źródeł, czyli przebudowy, a nie klauzuli prompty. Wszystko tutaj jest punktem w czasie zgodnym z datami: kontrakt i kod na dzień 16 września 2026, sonda 2 września 2026, ocena 1 września 2026, kalibracja na rzeczywistym użyciu 11 czerwca 2026, pomiar rozszerzonej reguły 22 lipca 2026.

Lista kontrolna

Zanim zaufasz, rozszerzysz lub „naprawisz” bramę weryfikacyjną w swoim własnym potoku agenta:

1. Zdecyduj, co weryfikator może zobaczyć, i pozwól, aby to zdecydowało, co może oceniać. Niewidomy oznacza jedynie wierność: sprzeczności, zmienione cytowania, wymyślone cytowania.
2. Brak czegoś w odniesieniu, które producent może słusznie przekroczyć, nigdy nie jest naruszeniem. Jeśli nie możesz udowodnić, że fakt został sfabrykowany, a nie ugruntowany w źródle, którego nie przekazałeś, nie flaguj go.
3. Uczyń uczciwość mechaniczną wszędzie tam, gdzie pozwala na to dziedzina. Cytowania wobec listy zamkniętej, adresy URL i ceny wobec zatwierdzonego zestawu dowodów: te rzeczy można ocenić na podstawie danych wejściowych. Otwarte prawdy nie.
4. Kalibruj na rzeczywistych wersjach roboczych przed zaufaniem bramce. Zmierz swój udział fałszywie dodatnich przed rozszerzeniem kontraktu; nasz wynosił 10 na 12 problemów podczas rzeczywistego użytkowania (11 czerwca 2026). Projektuj kontrakt tak, aby brak czegoś nie był naruszeniem.
5. Werdykt, którego nie można sparsować, musi zatrzymać krok, nigdy go nie przechodzić. Zachowaj jeden czytelny maszynowo werdykt i uczyń przejście wartością logiczną zgodną z listą problemów.
6. Jedno ponowne renderowanie przy nieudanym werdykcie, a następnie ponowna weryfikacja. Zwolnij krok z drugiego niepowodzenia jedynie z flagą zastrzeżenia, po dwóch inspekcjach. Nigdy nie zwalniaj treści nieinspekcjonowanej na żadnej ścieżce, włącznie z awariami weryfikatora. Przejście oznacza, że nie wykryto naruszenia kontraktu, a nie że treść jest prawdziwa.
7. Testuj klasą awarii, którą twoja dziedzina rzeczywiście produkuje (u nas: cytowania wykraczające poza zatwierdzony zestaw), a nie klasą najłatwiejszą do symulacji (ręcznie wprowadzone fakty). I uważaj, gdzie je wprowadzasz: fałszerstwo napisane do dokumentu będącego podstawą weryfikatora nic nie testuje pod względem fabrykacji.
8. Gdy twoje własne dochodzenie podejrzanego fałszerstwa zależy od danych wejściowych, których nie sprawdziłeś, sam jesteś niewidomym weryfikatorem. Wycofaj się najpierw, zmierz później.

Weryfikator, który widzi mniej, nie jest słabszą bramą. Jego werdykty pozostają sprawdzalne, ponieważ ocenia kontrakt, który producent otrzymał.