Konsensus agentów LLM to nie weryfikacja, tylko wspólne echo

„Głosowanie” trzech instancji modelu nad jednym fragmentem kodu to żadna weryfikacja. Wygląda solidnie: zadanie leci do trzech agentów, agenci porównują wyniki, a jeśli się zgadzają, odhaczamy „potwierdzony fakt”. Na demo robi to wrażenie. Tyle że pewność, którą wtedy czujesz, jest pozorna. I właśnie ta pozorność jest groźna, bo skłania cię do wypuszczenia wyniku dalej bez kolejnego sprawdzenia.

Schemat, który tylko udaje weryfikację

Spotykam ten wzorzec po raz setny. Zawsze wygląda tak samo:

1. Zadanie trafia do trzech instancji modelu. Ten sam prompt, ten sam kontekst, trzy osobne przebiegi.
2. Agenci porównują odpowiedzi. Szukają miejsc, w których się różnią.
3. Jeśli się zgadzają, wynik ląduje jako „potwierdzony fakt”. I idzie dalej w głąb systemu.

Niby wszystko działa. Ale „działa na ekranie” to nie to samo co „daje pewność”. Konsensus agentów wygląda na niezależną kontrolę. Nie jest. Trzy przebiegi tego samego modelu to nie trzy niezależne źródła, tylko jedno źródło uruchomione trzy razy.

Agenci nie szukają prawdy, tylko prawdopodobieństwa

To sedno pułapki konsensusu. Model nie zmierza do prawdy, zmierza do najbardziej prawdopodobnej kontynuacji. Jeśli w danych treningowych drzemie błąd, albo w załadowanym kontekście przeoczono ważny plik, każdy z trzech agentów popełni go w ten sam sposób.

Zgodnie utrwalą tę samą halucynację, bo tak podpowiada im statystyka. Trzy modele mylące się identycznie nie dają ci trzech niezależnych głosów. Dają jeden głos powtórzony trzy razy, tylko głośniej.

Na demo tego nie widać. Trzy zgodne odpowiedzi wyglądają jak potrójna kontrola, więc nikt nie drąży. Problem wychodzi dopiero na produkcji, gdzie ten sam błąd powtarza się przy każdym wywołaniu i za każdym razem brzmi równie pewnie. Im gładsza odpowiedź, tym trudniej komukolwiek się przy niej zatrzymać.

Konsensus to echo, nie dowód

Wracamy tu do problemu, który rozłożyłem we wpisie o samoocenie modelu. Model oceniający własną pracę nie umie wyjść poza własne założenia. Zwiększenie liczby agentów z jednego do trzech niczego nie naprawia, jeśli wszyscy patrzą na świat tym samym rozkładem prawdopodobieństwa.

Traktowanie zgodności modeli jako dowodu to proszenie się o kłopoty. Na produkcji taki system przepuszcza błędy, które brzmią wyjątkowo przekonująco, bo trzy modele zgodnie podpisały się pod tym samym fałszem.

„Zgoda to nie weryfikacja. Weryfikacja potrzebuje zewnętrznego ciężarka — czegoś, co nie głosuje razem z modelami.”

Konfrontacja zamiast koła wzajemnej adoracji

Zamiast budować „koło wzajemnej adoracji”, zbuduj konfrontację. Tu zaczyna się weryfikacja adwersaryjna. Agenci dostają jawną instrukcję: wytykać sobie błędy, zmieniać role, szukać dziur w całym. To naprawdę pomaga. Model w roli krytyka znajduje to, czego ten sam model w roli autora bronił chwilę wcześniej.

Różnica jest subtelna, ale zmienia wszystko. W kole wzajemnej adoracji każdy agent ma interes w tym, żeby się zgodzić. W panelu adwersaryjnym ma interes w tym, żeby drugiemu coś udowodnić. Nie chodzi o kłótnię dla zasady, tylko o to, żeby trzeci i czwarty rzut oka faktycznie patrzył pod innym kątem niż pierwszy.

• Role adwersaryjne. Jeden agent pisze, drugi ma jedno zadanie: to rozbić.
• Wymuszona zmiana ról. Autor zostaje recenzentem, recenzent autorem.
• Mandat na niezgodę. Nagradzasz znalezioną dziurę, nie potakiwanie.

Konfrontacja między modelami to wciąż za mało, żeby spać spokojnie. W kolejnym wpisie z tej serii o inżynierii agentowej rozłożę na części, jak projektować panel adwersaryjny i jak rozbroić position bias panelu sędziów — czyli to, że sędzia faworyzuje odpowiedź przez samą jej kolejność na liście.

Co właściwie jest tym „zewnętrznym ciężarkiem”

Zewnętrzny ciężarek to coś, czego model nie przegada. Kod albo się kompiluje, albo nie. Testy przechodzą albo nie. Typy się zgadzają albo build wywala błąd. To nie jest kolejna opinia w rozkładzie prawdopodobieństwa, tylko mechaniczny wyrok, którego nie obchodzi, jak przekonująco brzmi odpowiedź.

Dlatego deterministyczna bramka bije trzy zgodne modele. Trzy modele mogą wspólnie się mylić. Kompilator nie głosuje. Test integracyjny nie szuka kompromisu. Albo czerwone, albo zielone. To jest ten punkt odniesienia, którego konsensus nigdy sam z siebie nie dostarczy.