Dlaczego model językowy kłamie z pełnym przekonaniem

Komitet techniczny zatwierdził wdrożenie systemu AI do komunikacji wychodzącej. Maile wychodzą regularnie, proces wygląda na zautomatyzowany i efektywny. Nikt jednak nie wie, że jeden na kilkanaście komunikatów zawiera błędne dane techniczne, które brzmią jak rekomendacja eksperta. Agencje wysyłają maile brzmiące jak prymitywny bot, które nasi klienci – twardzi inżynierowie i szefowie utrzymania ruchu – natychmiast wrzucają do spamu. Problem nie polega jednak na tym, że mail brzmi jak bot. Problem polega na tym, że brzmi jak ekspert, który się myli.

Głośny przypadek prawnika, który zacytował przed sądem nieistniejące orzeczenia wygenerowane przez ChatGPT, pokazuje skalę zagrożenia. Model przedstawił fikcyjne wyroki z pełną pewnością, a prawnik powołał się na nie w oficjalnym dokumencie procesowym. Jeśli system AI może wygenerować nieistniejące orzeczenia sądowe z taką pewnością, z równą pewnością wygeneruje błędne parametry techniczne produktu, nieistniejące certyfikaty normy lub zmyślone dane referencyjne w mailu do szefa utrzymania ruchu. Ile takich maili wysłał już twój system, zanim ktokolwiek to zauważył?

Mechanizm generowania tokenów jako źródło problemu

Model językowy nie posiada żadnego wewnętrznego stanu wiedzy ani niewiedzy. Każdy token powstaje wyłącznie na podstawie rozkładu prawdopodobieństwa uzyskanego poprzez funkcję softmax z logitów, bez żadnej weryfikacji faktów z rzeczywistością. Logit to surowy wynik sieci neuronowej, a softmax normalizuje te wartości tak, aby tworzyły rozkład prawdopodobieństwa sumujący się do jeden. Wysokie prawdopodobieństwo tokena oznacza jedynie statystyczną spójność z danymi treningowymi, a nie zgodność z rzeczywistością, co strukturalnie uniemożliwia modelowi odróżnienie faktu od zmyślenia.

W praktyce oznacza to, że pewność odpowiedzi AI nie koreluje z jej poprawnością. Gdy model generuje sekwencję, oblicza pełne rozkłady dla całego słownika i wybiera tokeny zgodnie ze strategią dekodowania. Greedy decoding wybiera token o najwyższym prawdopodobieństwie w każdym kroku. Beam search przeszukuje wiele ścieżek jednocześnie, a temperatura oraz parametry top-k i top-p kontrolują poziom kreatywności modelu. Każdy z tych mechanizmów wpływa bezpośrednio na ryzyko halucynacji. Model oblicza pełne rozkłady dla całego słownika w każdym kroku generacji – to jest jedyny sygnał wewnętrzny, jaki posiada, i nie ma w nim żadnej informacji o zgodności z rzeczywistością.

Nawet gdy użytkownik prosi o werbalizację poziomu pewności, deklaracja ta wynika z optymalizacji stylu językowego, a nie z rzeczywistej kalibracji wiedzy, co czyni ją niewiarygodnym wskaźnikiem ryzyka. W klasycznej statystyce kalibracja modelu oznacza, że deklarowany poziom pewności odzwierciedla rzeczywistą częstość poprawnych odpowiedzi – jeśli system mówi 90 procent pewności, to w 90 przypadkach na 100 ma rację. To jest standard, do którego dąży każdy system ekspercki z sygnalizacją niepewności. W LLM werbalizowana pewność zależy od sposobu zadania pytania, jest silnie zależna od promptu i wymaga ostrożnej inżynierii, żeby miała jakikolwiek sens jako wskaźnik ryzyka.

Na czym polega optymalizacja RLHF

Optymalizacja procesu RLHF (Reinforcement Learning from Human Feedback) w modelach LLM opiera się na wydajniejszym zbieraniu danych o preferencjach oraz stabilizacji algorytmu. Używa się do tego bibliotek takich jak TRL (Transformer Reinforcement Learning) i struktur typu PEFT z technikami LoRA, które pozwalają na uruchomienie procesu w środowiskach wielokartowych (np. przy użyciu OpenRLHF).

🐶 Najprostsza analogia: > Działa to dokładnie tak, jak tresowanie młodego pieska. Kiedy dasz psu komendę „siad”, a on usiądzie – dajesz mu smakołyk. Piesek szybko łapie, że za dobre zachowanie jest nagroda. W RLHF „smakołykami” dla robota są punkty i pochwały od ludzi! Wpływ RLHF na ton odpowiedzi Optymalizacja RLHF sprawia, że modele przyjmują ton stanowczy i pomocny nawet przy wysokiej entropii rozkładu prawdopodobieństwa, maskując brak weryfikacji faktów. Model, który wewnętrznie waha się między kilkoma tokenami o zbliżonym prawdopodobieństwie, nadal konstruuje zdanie brzmiące jak pewna rekomendacja eksperta – bo tak został nauczony przez RLHF, bo ludzie oceniający odpowiedzi preferowali pewny ton nad wahający się. Efekt ten zwiększa prawdopodobieństwo, że błędne dane trafią do twardych odbiorców B2B i natychmiast trafią do spamu.

Brak wewnętrznego stanu wiem/nie wiem powoduje, że model produkuje błędne odpowiedzi z taką samą pewnością jak poprawne, narażając firmy na roszczenia prawne i utratę reputacji przed wykryciem błędu. Widziałem to wielokrotnie w testach – model generuje błędny parametr techniczny z taką samą pewnością tonu, jak poprawny. Różnica nie jest widoczna w tekście – jest widoczna w rozkładzie tokenów. Klasyczne systemy eksperckie oparte na regułach i bazach wiedzy posiadały wbudowany mechanizm sygnalizacji ignorancji – jeśli zapytanie wykraczało poza zakres bazy wiedzy, system odpowiadał brak danych lub poza zakresem kompetencji. To był fundamentalny element architektury, nie opcjonalna funkcja. LLM nie posiada odpowiednika tego mechanizmu – dla każdego promptu generuje odpowiedź, chyba że zostanie explicite zaprojektowany, żeby tego nie robić.

Badania nad asocjacjami podsekwencji pokazują, że halucynacje nie są losowe, lecz wynikają z przewidywalnych wzorców w mechanizmie generowania tokenów. Dekoderowe transformatory można postrzegać jako modele osadzające podsekwencje – gdy dana podsekwencja ma w danych treningowych silne skojarzenia z określonym typem odpowiedzi, model idzie za tym skojarzeniem, ignorując resztę kontekstu. Jeśli w danych treningowych nazwa konkretnej normy technicznej często współwystępuje z określonymi parametrami, model może dociągnąć te parametry do odpowiedzi, nawet jeśli pytanie dotyczy innej wersji normy lub innego produktu. Algorytm SAT osiąga o 26 procent wyższy współczynnik reprodukowalności halucynacji niż klasyczne metody atrybucji, identyfikując konkretne podsekwencje wyzwalające błędy w odpowiedziach modeli. Te trigger subsequences systematycznie prowadzą do halucynacji w różnych kontekstach, co wyjaśnia, dlaczego tradycyjne heurystyki oparte na pojedynczych prawdopodobieństwach zawodzą. Halucynacje nie są losowym szumem, który można uśrednić przez wysłanie wielu maili – są systematycznym błędem wywoływanym przez konkretne wzorce w tekście wejściowym.

Pełna sekwencja rozkładów jako narzędzie kontroli

Pełna sekwencja rozkładów tokenów, określana jako LLM Output Signature, może być wykorzystana przez niezależne detektory do identyfikacji halucynacji z wyższą skutecznością niż proste heurystyki oparte na pojedynczych prawdopodobieństwach. Prosta heurystyka patrzy tylko na prawdopodobieństwo wybranego tokena w danym kroku – to jest jak ocenianie jakości decyzji inżynierskiej tylko po jej wyniku, bez patrzenia na proces. LOS patrzy na pełną sekwencję rozkładów dla wszystkich kroków generacji – zarówno na prawdopodobieństwa faktycznie wybranych tokenów (ATP), jak i na kształt całego rozkładu w każdym kroku (TDS). Modele atencyjne (LOS-Net) traktują tę sekwencję jako dane wejściowe i uczą się rozpoznawać wzorce charakterystyczne dla halucynacji – analogicznie do tego, jak system IDS w cyberbezpieczeństwie nie patrzy na pojedynczy pakiet, ale na wzorzec ruchu sieciowego. Mechanizm ten wskazuje konkretne miejsce w architekturze, gdzie można wprowadzić kontrolę bez modyfikacji samego modelu. Kiedy budowałem architekturę systemu komunikacji wychodzącej dla AGAPE, pierwszym pytaniem było – gdzie w przepływie danych możemy sprawdzić, czy model wie, co generuje. Odpowiedź leży w pełnej sekwencji rozkładów tokenów – nie w samym tekście odpowiedzi.

Architektury oparte na zewnętrznych sygnałach pewności i human-in-the-loop pozwalają kontrolować ryzyko halucynacji na poziomie przepływu danych, a nie wewnątrz wag sieci neuronowej. Taki układ daje CTO punkt wyjścia do decyzji architektonicznych ograniczających odpowiedzialność prawną. Organizacja, która analizuje pełną sekwencję rozkładów tokenów i bramkuje odpowiedzi przed wysłaniem do klienta, kontroluje ryzyko halucynacji na poziomie przepływu danych – bez modyfikacji samego modelu i bez angażowania wewnętrznych zespołów developerskich.

Konsekwencje dla wdrożeń w MŚP

Wdrożenie AI bez walidacji generuje błędne dane wychodzące do klientów, niszczy reputację marki i naraża spółkę na odpowiedzialność prawną. Ryzyko prawne obejmuje błędne informacje w materiałach ofertowych i komunikacji wychodzącej, które mogą stanowić podstawę roszczeń. EU AI Act wprowadza klasyfikację wysokiego ryzyka i wymogi dokumentacyjne dla systemów AI w określonych zastosowaniach. Ryzyko RODO polega na tym, że zautomatyzowane przetwarzanie danych osobowych w komunikacji wychodzącej wymaga przejrzystości i możliwości zakwestionowania decyzji. System AI generujący maile bez walidacji może naruszać zasadę minimalizacji danych i wymóg DPIA. Ryzyko reputacyjne oznacza, że twardy inżynier lub szef utrzymania ruchu, który otrzyma mail z błędnymi parametrami technicznymi, nie tylko wrzuci go do spamu, ale zapamięta nadawcę jako źródło niesprawdzonych informacji – i to skojarzenie jest trudne do odwrócenia. Presja regulacyjna wynikająca z RODO oraz EU AI Act dodatkowo wzmacnia potrzebę zrozumienia, że modele językowe w B2B nie sygnalizują niepewności, gdy nie wiedzą. Integralność danych firmowych, bezpieczeństwo infrastruktury IT i polityka prywatności danych stają się bezpośrednio zależne od zdolności do oddzielenia statystycznej spójności od faktycznej poprawności.

Punkt wyjścia do decyzji architektonicznych

Zrozumienie, dlaczego model produkuje błędy z pełnym przekonaniem, pozwala precyzyjnie określić, w którym miejscu architektury to zjawisko można kontrolować. Komitet techniczny przestaje pytać czy AI się myli i zaczyna pytać w którym miejscu przepływu danych możemy to sprawdzić – to jest zmiana perspektywy, która przekłada się na konkretne decyzje architektoniczne. CTO, który rozumie, gdzie w architekturze leży źródło problemu, może podjąć decyzję o bramkowaniu odpowiedzi bez angażowania wewnętrznych developerów – i bez modyfikowania samego modelu.

Opisz w komentarzu sytuację, w której system AI wygenerował odpowiedź, która brzmiała bardziej przekonująco niż poprawna – błędny parametr techniczny, nieistniejące źródło, zmyślona referencja. Nie musisz podawać nazwy systemu ani klienta. Każda taka sytuacja to konkretny wzorzec – i wzorce są przewidywalne, co pokazuje algorytm SAT z 26 procent wyższym współczynnikiem reprodukowalności halucynacji niż klasyczne metody atrybucji. Im więcej wzorców zebranych z realnych środowisk operacyjnych, tym precyzyjniejsza ocena ryzyka wdrożeniowego. Jeśli chcesz ocenić ryzyko w swoim konkretnym środowisku – zacznij od opisania jednego przypadku.