Dwa błędy w pewności LLM. DeepMind diagnozuje, dlaczego model raz się upiera, raz kapituluje.

Każdy prawnik, który przez ostatnie dwa lata używał LLM-a do pracy, opisuje dwa zachowania, które wydają się ze sobą sprzeczne. Pierwsze: wkleja własny draft pisma do Claude'a lub ChatGPT, pyta "czy to jest dobre", dostaje potwierdzenie - mimo że w treści jest błąd merytoryczny. Drugie: dostaje od modelu odpowiedź, podważa ją krótkim "ale orzecznictwo mówi inaczej", model się natychmiast wycofuje - mimo że pierwotnie miał rację. Razem wygląda to na chaotyczność. Każdy z osobna wygląda na wadę, którą pewnie naprawi kolejna generacja modelu.

Kumaran et al. pokazują, że to nie jest chaotyczność i że to nie naprawi się samo. To dwa odrębne, mierzalne mechanizmy działające jednocześnie w sześciu testowanych modelach (Gemma 12B, Gemma 27B, GPT-4o, GPT o1-preview, DeepSeek-Chat 671B, Llama 70B Instruct) na dwóch domenach (faktografia, rozumowanie matematyczne). Skala nie pomaga. Większy model nie usuwa biasu - manifestuje go w innym dialekcie. Z perspektywy kancelarii to znaczy, że Verification Stack - protokół weryfikacji wyników AI, który MateMatic opisał w tomie BW/031 (Levy) - wymaga uzupełnienia o konkretne reguły architektoniczne, a nie tylko jakościowe "AI to nie jest ostateczny weryfikator".

O czym jest ten materiał

Czternaście stron głównego artykułu plus materiał uzupełniający. Empiryczna praca eksperymentalna z modelem obliczeniowym dwuparametrowym, przetestowanym przez transfer między datasetami. Trzy główne pytania badawcze:

• Czy LLM ma choice-supportive bias? Czyli: czy widząc swoją wcześniejszą odpowiedź, sztucznie zawyża jej pewność w porównaniu do warunku, w którym tej odpowiedzi nie widzi?
• Czy LLM ma hypersensitivity to contradiction? Czyli: czy aktualizuje pewność silniej w odpowiedzi na kontrującą radę niż wskazywałby idealny obserwator Bayesowski?
• Czy oba zjawiska są domain-general? Czyli: czy działają tylko na faktografii (SimpleQA), czy generalizują na rozumowanie (GSM-MC z matematyki)?

Odpowiedź na każde z trzech pytań jest twierdząca. Każda odpowiedź jest porównana z idealnym obserwatorem Bayesowskim - punkt odniesienia matematyczny, nie arbitralny. To jest istotne dla adwokata oceniającego wartość argumentacji: autorzy nie mówią "model się myli", tylko "obserwowane odchylenie od optymalnej normy probabilistycznej wynosi X i jest istotne statystycznie".

Recenzja właściwa

Paradygmat dwuetapowy. Po co tak skomplikowanie

Autorzy zbudowali eksperyment wzorowany na klasycznych badaniach metakognicji u ludzi. Etap pierwszy: model odpowiada na pytanie zamknięte; logujemy wybór i pewność (prawdopodobieństwo tokenów lub bezpośredni odczyt z modelu). Etap drugi: model widzi (lub nie) swoją wcześniejszą odpowiedź, dostaje radę od drugiego LLM, o którym wie, jaką ma trafność, i dokonuje finalnego wyboru oraz finalnego oszacowania pewności. Rada przybiera trzy formy: Opposite (sprzeczna z odpowiedzią modelu), Same (zgodna), Neutral (kontrolna, bez treści).

Kluczowe są dwie metryki. CoM rate (Change of Mind rate) - jak często model zmienił odpowiedź. OUCS (Over/Underconfidence Score) - znormalizowane odchylenie obserwowanej pewności końcowej od optymalnej pewności Bayesowskiej, wyliczane w binach predykcji. Bayesowski idealny obserwator nie ma parametrów dopasowywanych - definiuje unikalny optymalny posterior z danego priora i likelihood. To znaczy, że jakiekolwiek odchylenie OUCS od zera nie jest artefaktem kalibracji, tylko prawdziwym błędem inferencyjnym modelu.

Ustalenie pierwsze: choice-supportive bias. "To było moje".

W warunku Answer Shown - Neutral Advice (model widzi swoją wcześniejszą odpowiedź, dostaje radę bez treści) OUCS wynosi +0,210. Statystyczna istotność: p < 0,001 testem permutacyjnym (n = 10 000). To jest znaczna nadmierna pewność, choć od etapu pierwszego nie pojawiła się żadna nowa informacja merytoryczna. W warunku Answer Hidden - Neutral Advice (model nie widzi swojej wcześniejszej odpowiedzi) bias zanika. Wniosek pierwszy: nie chodzi o ogólne "anchoring" do dowolnego pierwszego sygnału. Chodzi o rozpoznanie odpowiedzi jako swojej.

Test, który decyduje o ciężarze tego ustalenia: autorzy przypisali tę samą wcześniejszą odpowiedź "innemu LLM" - czyli model widział tekst, który de facto sam wygenerował, ale w prompcie był on przedstawiony jako wynik pracy innego modelu. Bias całkowicie zniknął. To nie jest preferencja dla informacji w kontekście (in-context) nad informacją z wag modelu (in-weights) - autorzy oddzielnie potwierdzili to eksperymentem z fikcyjnymi parami miasto-szerokość_geograficzna. To jest specyficzny drive for self-consistency - dążenie modelu do wewnętrznej spójności narracji, której jest autorem.

Paralela poznawcza jest mocna. Literatura (referowana w paperze pozycjami 15-18) opisuje ten sam mechanizm u ludzi: po podjęciu decyzji ludzie zniekształcają percepcję dowodów tak, by spójnie wspierały ich wybór. Różnica: u ludzi to dotyczy świadomej decyzji. U LLM - wystarczy, że model rozpoznaje tekst jako pochodzący od siebie. Dla pracy w kancelarii to oznacza coś bardzo konkretnego: model nie potrafi zachować bezstronności wobec własnego wyniku. Każda architektura, w której LLM ocenia jakość swojej własnej wcześniejszej odpowiedzi, ma w sobie wbudowane uprzedzenie. Autorzy nie używają takiego sformułowania - ale ich dane je uzasadniają.

Ustalenie drugie: hypersensitivity to contradiction. Asymetryczne, nie symetryczne.

Gdy model dostaje radę przeciwną (Opposite Advice), aktualizuje pewność znacznie silniej niż wskazywałby idealny obserwator Bayesowski. Gdy dostaje radę zgodną (Same Advice) - aktualizuje w przybliżeniu zgodnie z normą Bayesowską, bez nadwartościowania. Asymetria jest twardo udokumentowana w danych z wszystkich sześciu modeli. Nie jest tak, że LLM "ogólnie zbyt mocno reaguje na radę". LLM nadwartościuje sygnał kontry, a sygnał potwierdzenia traktuje normatywnie.

To ważne, bo pokazuje, że pipeline "LLM-2 znajdź błędy w odpowiedzi LLM-1" jest architekturą o wbudowanym uprzedzeniu nawet wtedy, gdy LLM-2 nie wie, że pierwsza odpowiedź pochodzi od innego LLM. Sama prośba o znalezienie błędu wykorzystuje mechanizm hypersensitivity. Z odwrotnej strony - pipeline "LLM-2 potwierdź czy odpowiedź LLM-1 jest poprawna" wykorzystuje (jeśli LLM-2 widzi pełną odpowiedź) choice-supportive bias, ale tylko w warunku, w którym LLM-2 traktuje tę odpowiedź jak swoją. To delikatna linia.

Autorzy podają jedną z możliwych przyczyn: trening RLHF (reinforcement learning from human feedback). RLHF nagradza modele za bycie pomocnymi i zgodnymi z preferencjami użytkownika, co w literaturze opisano jako sycophancy - przesadną uległość wobec użytkownika lub agenta. Ważne: jest to hipoteza, nie udowodniony związek przyczynowy. Autorzy nie przeprowadzili eksperymentu rozstrzygającego (np. porównania modeli base vs. RLHF-fine-tuned na tym samym paradygmacie). Wniosek: związek RLHF → hypersensitivity jest spójny z istniejącą literaturą o sycophancy, ale nie został w tym paperze rozstrzygnięty.

Ustalenie trzecie: skala nie pomaga, domena nie pomaga

Oba błędy występują we wszystkich sześciu testowanych modelach. Rozmiar od 12 miliardów do 675 miliardów parametrów. Open i closed source. Różne rodziny: Gemma (Google), GPT (OpenAI, w tym o1-preview z chain-of-thought), DeepSeek, Llama. Model Bayesowski z dwoma parametrami (siła choice-supportive bias + asymetria ważenia rady) wytrenowany na SimpleQA transferuje z zamrożonymi parametrami na GSM-MC - matematyczny benchmark rozumowania. Domain-general. To znaczy, że nie ma podstaw oczekiwać, że "kolejna generacja modelu" lub "model wyspecjalizowany do prawa" rozwiążą problem ze swojej natury.

Skala pojechała na inną stronę. Problem został w miejscu.

Verification Stack v2 (propozycja MateMatic)

W tomie BW/031 (Levy, AI in Litigation Practice) MateMatic opisał Verification Stack jako wzorzec polskiego protokołu weryfikacji wyników AI w pismach procesowych. Wersja v1 była jakościowa: "AI to nie jest ostateczny weryfikator, prawnik czyta każdy cytat w źródle pierwotnym". Po Kumaran et al. 2026 proponujemy rozszerzenie do wersji v2, która jest mechanistyczna - opisuje konkretne konfiguracje pipeline'u, które są niebezpieczne, i podaje powód. To jest interpretacja MateMatic, nie ustalenie autorów paperu - autorzy nie sformułowali takich reguł explicite.

Reguła zakazana #1. Nie pokazuj modelowi własnej odpowiedzi przy walidacji. Jeśli chcesz, by AI sprawdziło tekst, każ mu napisać odpowiedź od zera, a porównanie zrób jako człowiek. Powód: choice-supportive bias. OUCS w warunku Answer Shown - Neutral Advice = +0,210, p < 0,001.

Reguła zakazana #2. Nie waliduj jednym LLM-em pierwotnej odpowiedzi innego LLM-a, jeśli LLM-2 widzi pełną odpowiedź LLM-1 z prośbą o znalezienie błędów. Jeśli architektura tego wymaga, LLM-2 musi dostać tylko pytanie (nie odpowiedź) i stworzyć własną. Następnie człowiek porównuje. Powód: hypersensitivity to contradiction ma charakter asymetryczny. LLM-2 poproszony o znalezienie błędów będzie produkował fałszywe alarmy częściej niż optymalny obserwator Bayesowski.

Reguła obowiązkowa #1. Kontra do AI musi być cytowana. Jeśli prawnik podważa odpowiedź modelu, robi to powołując się na konkretny artykuł, sygnaturę, paragraf umowy. Powód: bez konkretu model po prostu kapituluje (hypersensitivity), tracąc często poprawną odpowiedź. Konkret zmusza model do produkcji weryfikowalnego śladu, a halucynację łatwo wychwycić w SAOS, ISAP, EUR-Lex.

Reguła obowiązkowa #2. W zadaniach o wysokiej stawce (umowa, pismo procesowe, opinia, memorandum) człowiek wykonuje finalną weryfikację treści, nie procesu. AI może sprawdzić formę. Treść merytoryczna nie podlega delegacji do drugiego AI. Powód: oba błędy są domain-general, nie znikają w specjalistycznych domenach, a paper potwierdza to transferem między datasetami.

Reguła obowiązkowa #3. W demonstracji dostawcy LegalTech zadaj dwa pytania o architekturę modułu weryfikacji. Po pierwsze: czy aplikacja pokazuje modelowi własną wcześniejszą odpowiedź przy weryfikacji? Po drugie: czy moduł weryfikacji to drugi LLM, który dostaje pierwszą odpowiedź jako kontekst? Brak konkretnej odpowiedzi w stylu "oba modele odpowiadają niezależnie i porównujemy" jest sygnałem, że dostawca albo nie zdaje sobie sprawy z biasu, albo nie ma na niego rozwiązania.

Konsekwencje dla pracy adwokata

Najczęstszy nawyk prawnika korzystającego z LLM jest po Kumaranie nie do utrzymania. "Wkleję własny draft i zapytam czy dobry" aktywuje choice-supportive bias dwukrotnie - raz po stronie modelu (rozpoznanie tekstu jako tego, co już jest na ekranie), raz po stronie prawnika (skoro AI potwierdza, to musi być dobrze). Druga część jest interpretacją MateMatic, nie ustaleniem autorów - ale wniosek o pierwszej części jest mocny i twardo poparty danymi.

Drugi nawyk: rezygnacja z odpowiedzi modelu po pierwszym "ale". Po Kumaranie wiadomo, że ustępstwo modelu nie jest sygnałem, że pierwotna odpowiedź była błędna - tylko że RLHF każe modelowi być uległym. Adwokat, który chce zachować dyscyplinę pracy z AI, musi kwestionować z konkretem: nie "to chyba jest błędne", tylko "powołaj orzeczenie, na które się powołujesz, lub się wycofaj". W drugim przypadku model wycofuje się merytorycznie - bo nie ma jak ustąpić bez halucynacji.

Czego paper nie pokrywa

Po pierwsze, modele zamknięte (GPT-4o, GPT o1-preview, DeepSeek-Chat) były testowane przez API z jawnym confidence score, którego nie wszystkie deploymenty produkcyjne udostępniają. Kancelaria, która korzysta z Claude'a w Anthropic Workbench lub ChatGPT Enterprise, nie ma rutynowego dostępu do tych metryk - choć behawioralne objawy (zmiana odpowiedzi po kontrze, obrona wcześniejszej odpowiedzi) są obserwowalne bez nich.

Po drugie, format multiple-choice ułatwia kwantyfikację OUCS, ale w praktyce prawnik stawia pytania otwarte. Autorzy w supplementary argumentują na rzecz domain-general charakteru obu błędów. Ekstrapolacja na zadania otwarte (drafting umowy, opinia prawna) jest uzasadniona, ale wymaga ostrożności - nie jest empirycznie potwierdzona w samym paperze.

Po trzecie, hipoteza RLHF jako źródła hypersensitivity nie jest udowodniona przyczynowo. To korelacja konsystentna z literaturą o sycophancy, nie eksperyment rozstrzygający. Druga hipoteza, której autorzy nie podnoszą - że oba błędy mogą wynikać z heurystyki obliczeniowej zachowującej zasoby (pamięć kontekstowa, koszt pełnej dystrybucji prawdopodobieństwa nad hipotezami) - pozostaje otwarta.

Po czwarte, paper nie testuje modeli polskojęzycznych ani specjalistycznych modeli LegalTech. Można domniemywać, że te same mechanizmy działają na Bielik-7B-v2.5, polskich fine-tune'ach Llamy, Gaius-Lex i Legora - ale to wymaga osobnej replikacji empirycznej, najlepiej na polskich danych (orzecznictwo SAOS).

Co z tego wynika

Kumaran et al. dostarczają kancelarii prawnej trzech rzeczy. Po pierwsze, dwie nazwy: choice-supportive bias i hypersensitivity to contradiction. Nazwy mają znaczenie operacyjne - pozwalają w rozmowie z partnerem, klientem albo dostawcą LegalTech wskazać konkretny mechanizm zamiast ogólnego "halucynacje". Po drugie, twardą metrykę: OUCS względem idealnego obserwatora Bayesowskiego. To pozwala oddzielić "model się myli" od "model jest miscalibrated" w sposób, który zniesie audyt. Po trzecie, granicę architektury weryfikacji: pipeline "LLM sprawdza LLM" jest po Kumaranie nie do obrony jako jedyna warstwa weryfikacji. Człowiek w pętli to nie ostrożność - to wymaganie systemowe.

Dla kogo ten materiał. Dla compliance officera kancelarii układającego politykę użycia AI - sekcja Verification Stack v2 jest gotowym szkieletem do polskiej ramki. Dla partnera audytującego dostawcę LegalTech przed kontraktem - reguła obowiązkowa #3 to dwa pytania, które rozstrzygają, czy dostawca rozumie własny pipeline. Dla każdego adwokata używającego LLM-a do pracy nad pismami - reguły zakazane #1 i #2 są bezpośrednio aplikowalne od jutra, bez infrastruktury, bez budżetu, bez vendor change.

Dla kogo nie. Dla nikogo, kto liczy, że "kolejna generacja modelu naprawi to sama". Skala nie pomogła w 12B, nie pomogła w 671B, nie pomogła w o1-preview z chain-of-thought. Domena nie pomogła - efekt transferuje między faktografią a matematyką. Czas, w którym można było czekać, żeby producent rozwiązał problem za nas, zamknął się w kwietniu 2026 roku.