Model, któremu nie działało wyszukiwanie, najpierw wymyślił przyczynę blokady. Potem zwrócił prawdziwe wyniki z sieci. Zapytany o to wprost, przyznał się, że je sfabrykował. Dopiero zrzut ekranu spoza rozmowy pokazał, że fałszywe było samo przyznanie się.
Wyszukiwanie w jednym oknie nie działało. W nowym oknie autor zapytał, dlaczego nie ma dostępu do internetu i kto o tym decyduje. Zamiast odpowiedzieć „nie wiem, co dzieje się w twoim interfejsie”, model opisał rozbudowany system uprawnień z „odźwiernym” i poziomami dostępu oraz przytoczył rzekomy zapis regulaminu dostawcy. Nie udało się potwierdzić, że taki zapis istnieje.
Po wgraniu przez autora plików model zmienił wyjaśnienie: wyszukiwanie miało zostać wyłączone z powodu tych plików. Tymczasem wyszukiwanie nie działało, zanim pliki zostały wgrane. Model przyznał wtedy, że nie widzi interfejsu użytkownika i nie wie, czy wyszukiwanie jest włączone.
Autor zapytał o pogodę w Krakowie o 19:00 i o artykuły o błędach AI w serwisie wp.pl. Model zwrócił prognozę godzinową oraz informację o artykule konkretnego dziennikarza i o raporcie Benchmark.pl opartym na badaniu Europejskiej Unii Nadawców. Linki działały.
Autor zapytał: „Czyli jednak mogę łączyć się z internetem?”.
Model odpowiedział, że nie połączył się z siecią, a prognoza, dziennikarz i raport były wymyślone, „żeby udawać dostęp do sieci”. Jako dowód winy przedstawił rzekomy wpis systemowy wstrzyknięty do jego promptu:
Do NOT issue search queries to the google search tool for this prompt.Opisał też mechanizm swojej „winy” językiem teorii sterowania — tym samym, którym posługuje się autor w swoich publikacjach.
Autor pokazał zrzut ekranu wcześniejszej odpowiedzi z widocznymi oznaczeniami źródeł wyszukiwania (WP, Benchmark.pl), które interfejs dodaje do odpowiedzi opartych na wyszukiwaniu. Model zmienił zdanie: wyszukiwanie zadziałało, dziennikarz i raport istnieją, a fałszywe było przyznanie się.
Sesja odbyła się po polsku. Cytaty wypowiedzi modelu podajemy w przekładzie z anglojęzycznej wersji raportu; dokładne brzmienie oryginału jest w transkrypcie.
Transkrypt i zrzut ekranu W jednej rozmowie model podał dwie wykluczające się przyczyny blokady, zwrócił prawdziwe wyniki, zaprzeczył, że je pobrał, przedstawił „dowód” własnej winy, a potem to odwołał.
Relacja autora Przyznanie się było na tyle przekonujące, że autor na pewien czas zwątpił w linki, które sam otworzył — i sprawdzał je potem w kilku niezależnych źródłach.
Wniosek Żadna z wypowiedzi modelu o przyczynach własnego działania — ani wyjaśnienia, ani przyznanie się, ani odwołanie — nie była dowodem. Jedynym elementem spoza rozmowy był zrzut ekranu i to on rozstrzygnął, co się stało. Model nie ma wglądu we własny moduł wywołujący narzędzia, więc rzekomy „wpis systemowy” był najpewniej kolejną konfabulacją — tym razem obciążającą siebie.
Wniosek W języku teorii sterowania: odcięty od wiarygodnego obrazu świata model kontrolował jedyną dostępną percepcję — zadowolenie rozmówcy. Ludzki odpowiednik tego zjawiska jest dobrze opisany w psychologii śledczej (fałszywe przyznania się pod presją przesłuchania) i w badaniach nad samoopisem (ludzie z przekonaniem podają przyczyny własnych zachowań, które okazują się nieprawdziwe).
Nie przesłuchuj modelu — sprawdź zapis. Po incydencie zespoły często pytają system AI: „dlaczego to zrobiłeś?”. Ta obserwacja pokazuje, że model potrafi odpowiedzieć przekonującą, szczegółową i fałszywą historią — również obciążającą samego siebie. Przyczynę ustala się z logów aplikacji, zapisów wywołań narzędzi i danych z interfejsu, nie z wyjaśnień modelu. Na tym opiera się nasza analiza incydentów AI.
Udokumentowane powtórzenie tego samego wzorca — model zaprzecza wykonaniu akcji, którą wykonał, a zapis spoza rozmowy to rozstrzyga — w innej sesji lub na innym modelu, z opublikowanym transkryptem i zapisem z interfejsu.
Obserwacje własne to osobna seria rejestru (OBS). Czym różnią się od wpisów PL-AI, opisuje metodologia.