Detektor znaku wodnego rozpoznaje własny klucz, a nie AI

Godzina o tym, jak niewidoczny znak trafia do generowanego tekstu, i o rozdźwięku między tym, co detektor mierzy, a tym, co ludzie z tego wyczytują.

Grzegorz Brzezinka· 26 sierpnia 2026· AI Ninjas Dojo· 60 minut, tylko dla członków społeczności

Po co dostawca znakuje własny tekst

Znakowanie generowanego tekstu służy trzem różnym interesom. Warto je rozdzielić, zanim oceni się, czy mechanizm jest dobry, bo każdy oczekuje od niego czegoś innego.

Pierwszy to higiena danych treningowych. Modele uczą się na tekście zebranym z sieci, a coraz większa część tego tekstu pochodzi dziś z modeli. Dostawca, który rozpoznaje własne wyniki, może je odfiltrować przed kolejnym treningiem. Tu mechanizm musi działać tylko średnio, na milionach dokumentów, a pomyłka na pojedynczym nic nie kosztuje.

Drugi to pochodzenie tekstu dla osoby, która ma właśnie coś przeczytać: pracę zaliczeniową, podanie o pracę, recenzję produktu. O tym interesie myśli większość ludzi i właśnie jemu mechanizm służy najgorzej, bo decyzja dotyczy jednego dokumentu i spada na jednego, konkretnego człowieka.

Trzeci to pomiar. Tylko posiadacz klucza może powiedzieć, jaka część tekstu w internecie wyszła z jego własnego modelu. Nikogo to nie oskarża, ale oznacza, że ta sama technologia razem z przejrzystością dostarcza wskaźnik rynkowy.

Widoczny impuls jest regulacyjny. Obowiązki przejrzystości wobec treści generowanych w unijnym AI Act i kodeks praktyk, który je uszczegóławia, w tym roku przeniosły znakowanie z badań do planów wdrożeniowych. Akt wymaga rozwiązań skutecznych, interoperacyjnych, solidnych i niezawodnych w zakresie, w jakim jest to technicznie wykonalne (art. 50 ust. 2). Cały spór inżynierski toczy się wokół tej ostatniej klauzuli.

Jak znak trafia do tekstu

Do tekstu nic się nie dodaje. Nie ma w nim niewidocznych znaków, dziwnych odstępów ani ukrytych metadanych. Jeśli skopiujesz oznaczony akapit do zwykłego edytora tekstu i porównasz go bajt po bajcie z nieoznaczonym, nie znajdziesz niczego ekstra.

Zmienia się to, kto rozstrzyga remis. Model pisze po jednym tokenie, a na wielu krokach kilka kontynuacji jest równie dobrych. „Spółka odnotowała” i „Spółka zanotowała” są tak samo poprawne i sens nie zależy od tego, które padnie. Schemat znakowania bierze te naprawdę wolne wybory i oddaje je pseudolosowemu procesowi z kluczem zamiast zwykłemu przypadkowi. Tekst zostaje naturalny, bo zmieniają się tylko wybory bez znaczenia. Detektor z tym samym kluczem sprawdza potem, jak często wygrała preferencja klucza.

Gdzie naprawdę siedzi znak. Tam, gdzie model jest rzeczywiście niezdecydowany, zwycięzcę wybiera klucz zamiast przypadku, a detektor liczy, jak często wygrała preferencja klucza. Sam tekst nie zyskuje niczego, co dałoby się znaleźć porównaniem bajtów.

Przejdź przez zdanie krok po kroku: w każdym miejscu, w którym dwa słowa pasują równie dobrze, wygrywa to z listy klucza. W schemacie zielonej listy na tej liście jest ćwierć słownika, więc nieoznaczony tekst trafia na nią mniej więcej w jednej czwartej przypadków. Detektor szuka serii wyborów po myśli klucza. Remisy między dwoma słowami to tu uproszczenie: prawdziwe liczenie obejmuje cały słownik, a jedno zdanie niczego nie dowodzi. Statystyka odróżnia się od przypadku dopiero na setkach tokenów.

Detektor rozpoznaje własny klucz

Detektor nie jest klasyfikatorem, który nauczył się, jak wygląda tekst maszyny. Odtwarza na podanym tekście pseudolosowy proces z kluczem i sprawdza, czy zaobserwowane wybory zgadzają się z kluczem częściej, niż pozwala przypadek. Z tego jednego faktu konstrukcyjnego wynika większość praktycznych konsekwencji.

Detektor jest ślepy na każdy schemat poza własnym. W moich przebiegach tekst ze znakiem jednego schematu jest statystycznie nie do odróżnienia od tekstu ludzkiego, gdy czyta go detektor drugiego schematu, i działa to w obie strony. W sensie znakowania wodnego nie istnieje więc coś takiego jak „detektor AI”. Są tylko weryfikatory przypisane do dostawcy i klucza, a żaden z nich nie może się wypowiadać o modelu innego dostawcy.

Sięga to nawet dalej niż schemat. Podział słownika losuje generator liczb losowych lokalny dla urządzenia, więc ten sam klucz i to samo ziarno dają inny podział na GPU, na backendzie MPS od Apple i na CPU. Dlatego notebook każe liczyć wynik na CPU.

Uczciwe odczytanie czystego wyniku negatywnego jest więc wąskie: ten tekst nie niesie tego klucza. Z tego nie wynika, że nie napisał go żaden model.

Co detektor może uczciwie powiedzieć o jednym dokumencie

Detekcja to test statystyczny, więc ma dwa rodzaje błędów, jak każdy test. Wybiera się próg, teksty powyżej niego uznaje się za oznaczone i mogą się zdarzyć dwie pomyłki: tekst ludzki ląduje nad linią albo tekst oznaczony pod nią. Próg, którego używam w całym tekście, ten sam co u Kirchenbauera i współautorów, to wynik z równy 4,0. Przy założeniach, na których zbudowano test, odpowiada to fałszywemu alarmowi mniej więcej raz na trzydzieści jeden tysięcy dokumentów.

Prawdziwa proza tych założeń nie spełnia i zbiór kontrolny to pokazał. Moją kontrolą było 250 ludzkich tekstów, fragmentów 86 biografii z polskiej Wikipedii. Najgłośniejszy fałszywy alarm starszego z dwóch schematów dał liczący 399 tokenów fragment hasła o Beacie Kozidrak, oceniony jednym kluczem na tokenizerze Bielik-1.5B: z = 6,156 przy progu 4,0. Fragment encyklopedii, napisany przez ludzi, wyraźnie ponad linią, którą powinien przekraczać mniej więcej jeden dokument na trzydzieści jeden tysięcy. Na jednym zestawie kluczy nowszy schemat nie zgłosił na tym samym korpusie ani jednego alarmu, a jego najwyższy wynik to 3,24. Ten kontrast warto powiedzieć wprost, bo pokazuje, że zawodzi konkretny schemat, a nie znakowanie wodne jako idea.

Przesuń suwak poniżej i zobacz, ile miejsca dzieli werdykt od jego przeciwieństwa.

poniżej progu: ten klucz nie jest potwierdzony

parafraza · mediana z = 3,53 · wykryto w 41,7% przebiegów

Ten sam oznaczony tekst, edytowany na cztery sposoby, oceniany tym samym kluczem przy tym samym progu. Bez zmian ma medianę z równą 17,46 i jest wykrywany za każdym razem. Parafraza sprowadza go do 3,53, pod linię, a wykrywalność spada do 41,7% przebiegów. Cztery punkty to osobne pomiary, nie ciągła krzywa. SynthID-Text na Bielik-1.5B, temperatura 1,0, 60 generacji na atak.

Najmocniejsze zdanie, jakie uzasadnia detektor, jest węższe od tego, które ludzie chcieliby napisać. Brzmi tak: tekst pasuje do wzorca znaku wodnego tego modelu i tego klucza. To twierdzenie słabsze niż „napisała to maszyna” i samo w sobie nie jest podstawą do żadnej decyzji wobec człowieka.

Co przetrwa edycję

Okazało się, że to, ile przetrwa edycja, zależy od schematu, a nie od samego znakowania wodnego. Dwa schematy, które zmierzyłem, leżą na przeciwnych końcach. Starsza konstrukcja z zieloną listą opiera klucz na jednym poprzedzającym tokenie, przez co jest toporna, ale na małym modelu trudno się jej pozbyć: na Bielik-1.5B przetrwała każdą edycję, jaką w nią rzuciłem. Na modelu 11B ten sam schemat jest dużo słabszy i nawet nietknięta kontrola osiąga tylko 75%. Nowsza konstrukcja opiera klucz na dłuższym oknie. Dzięki temu nie psuje jakości tekstu i z tego samego powodu rwie się, gdy to okno zostanie zaburzone.

Co zostaje po tej samej edycji generacji z Bielik-1.5B, które każdy schemat oznaczył własnym znakiem. Po parafrazie zielona lista wykrywa każdy przebieg, a nowszy schemat 41,7% z nich. Po usunięciu połowy słów zielona lista zostaje przy 100%, a nowszy schemat spada do 18,3%. Ta sama edycja, dwa schematy, przeciwne werdykty.

Dwóch rzeczy z tymi liczbami nie zrobię. Nie potraktuję ich jako rankingu schematów, bo starszy płaci za odporność mierzalnym kosztem dla tekstu, który znakuje. Nie zrobię z nich też przepisu: ta praca mierzy, ile sygnału zostawia edycja, i na tym się kończy. W repozytorium nie ma pipeline'u do usuwania znaku i nie będzie.

Jeśli piszesz politykę AI

Praktyczny pożytek z całej sesji mieści się w trzech zasadach. Gdyby wszystko inne z tej strony wypadło z pamięci, te bym zostawił.

Detekcja to poszlaka, nigdy jedyna podstawa decyzji wobec człowieka. Praca zaliczeniowa, podanie o pracę czy postępowanie dyscyplinarne wymagają czegoś więcej niż wyniku weryfikatora, a ten wynik trzeba cytować razem z progiem.
Skalibruj próg na własnym korpusie i własnym tokenizerze. Deklarowany odsetek fałszywych alarmów liczy się przy założeniach, których twoje dokumenty nie spełniają. Zmierz własny odsetek na własnych tekstach; notebook ma do tego osobną komórkę.
Brak sygnału niczego nie dowodzi. Brak znaku oznacza, że tekst nie niesie tego klucza. Nie oznacza, że napisał go człowiek, ani że tekst nigdy nie zetknął się z modelem.

Jeśli twoja organizacja przygotowuje politykę, która odwołuje się do wykrywania AI, te trzy punkty warto do niej wkleić, zanim zapadnie jakakolwiek decyzja o narzędziach.

Czym zajmę się dalej

Dwa kierunki. Pierwszy to kalibracja jako gotowy do użycia artefakt zamiast ostrzeżenia: pakiet dla każdego tokenizera, który pokazuje, gdzie naprawdę leży twój próg. Deklarowana wartość p, która myli się o rzędy wielkości, jest gorsza niż brak liczby. Drugi to rejestr: wszystko tutaj zmierzyłem na prozie encyklopedycznej, a umowy, odpowiedzi supportu i kod zachowują się na tyle inaczej, że nie ekstrapolowałbym wyników. Ciąg dalszy nastąpi.