Architektura przeciwdziałająca nasilaniu się halucynacji w grafach agentów
Naucz się projektować architekturę płaszczyzny sterowania za pomocą narzędzi typowanych, rejestrów cytatów oraz bram schematowych, które zapobiegają nasilaniu się halucynacji w systemach LLM z wieloma agentami.
Instynktownym rozwiązaniem jest dodanie kolejnego agenta krytycznego. W ten sposób właśnie powiększasz zakres oszustwa zamiast je naprawić.
Jeśli kiedykolwiek wprowadziłeś do użycia chatbota RAG z jednym agentem, już rozpoznajesz ten problem: model odpowiada na coś, czego nie stwierdzają pobrane dokumenty, i przedstawia tę fałszywą informację z takim samym tonem pewności, jakiego używa, gdy cytat jest prawdziwy.
W pipeline z wieloma agentami ten sam błąd jest wzmacniany, ponieważ nie mamy już do czynienia z wynikiem jednego modelu — mamy do czynienia z całym grafem takich modeli. Planista wymyśla podcelę. Badacz tworzy źródło, które ma ją wspierać. Analityk pobiera z tego wymyślonego źródła liczbę. Autor przekształca tę liczbę w rekomendację. Następnie agent wywołujący narzędzia realizuje tę rekomendację w systemie rozliczeniowym. Przy każdej przekazce istnieje możliwość, by domysł został przedstawiony jako coś, co wygląda na potwierdzony fakt.
Zespoły tworzące systemy wielu agentów w stylu LangGraph do zastosowań prawniczych, finansowych i operacyjnych napotykają powtarzający się problem. Problem nie leży w tym, że podstawowy model jest nierozumny – chodzi o to, że sam proces pracy nie posiada kontraktu epistemicznego. Nic w grafie nie zmusza żadnego agenta do ujawnienia, skąd pochodzi dane roszczenie, jakie dowody mogłyby je obalić lub co powinno się stać, gdy takich dowodów po prostu nie ma. Dlatego system robi to, co modele językowe zawsze robią w obliczu luki: generuje coś wiarygodnego, aby ją wypełnić.
Poniżej przedstawiono architekturę, którą warto zastosować, gdy wynik może przenieść pieniądze, wpłynąć na dokumentację prawną lub trafić do skrzynki pocztowej klienta. To nie jest krótki przewodnik, a jeśli szukasz jednego pakietu do zainstalowania, który sprawi, że twoi agenci będą godni zaufania, nie znajdziesz go tutaj.
Problem kumulatywny, na który nikt nie buduje budżetu
Każde pojedyncze wezwanie LLM ma pewien podstawowy wskaźnik niepotwierdzonych twierdzeń — nazwijmy go p. Połącz pięć etapów realizacji przez agenty, a jeśli każdy z tych etapów może wprowadzić lub wzmocnić niepotwierdzoną twierdzenie, wasz rzeczywisty wskaźnik błędów nie będzie już równy p. Staje się on iloczynem prawdopodobieństw warunkowych, co jest pogłębiane przez drugi problem charakterystyczny dla grafów wieloagentowych: przenoszenie uprawnień pomiędzy agentami.
Agent B traktuje wynik działania Agenta A jako ustalony fakt tylko dlatego, że przybył on w formie zstrukturyzowanego obiektu JSON o nazwie podobnej do research_findings. Schemat jest sprawdzony, typy pól są poprawne. Jednak rzeczywista treść jest wymyślona. Przepuszczenie weryfikacji schematu nie oznacza, że informacja jest prawdziwa, a mimo to większość zespołów skupia się wyłącznie na egzekwowaniu pierwszego warunku.
W rzeczywistych implementacjach częściej występują trzy konkretne wzorce awarii, niż przyznają większość opracowań:
- Symulowane wywołania narzędzi. Model wytwarza wezwanie funkcji, które wygląda składniowo poprawnie — na przykład
search_matters(client_id=…)— ale jest skierowane do narzędzia, którego nie istnieje, lub zawiera argumenty, które spowodowałyby błąd, gdyby rzeczywiście stosowano jego schemat. Warstwy orkiestracji, które w tajemnicy przymuszają do używania niepasujących typów lub pozwalają modelowi spróbować ponownie z lekko zmodyfikowanymi argumentami, w rzeczywistości uczą system na to, by ignorować braki w danych zamiast je ujawniać. - Oczyszczanie informacji pomiędzy agentami. Badacz używa sformułowania „zgodnie z plikiem sprawy”. Analityk poniżej w łańcuchu przetwarzania nigdy tak naprawdę nie otwiera tego pliku. Następnie autor cytuje analityka jako źródło. Zanim człowiek przejrzy ostateczny podsumowanie, pierwotne określenie całkowicie znika. W ten właśnie sposób niepewne „może” przekształca się w pewnie stwierdzony fakt, który można uwzględnić w rachunku.
Generowanie wzbogacone o wyszukiwanie nie ratuje cię przed tym problemem. Wyszukiwanie dostarcza jedynie informacje wstępne. Jeśli agent planujący nigdy nie sformułuje właściwego zapytania, albo jeśli proces dzielenia tekstu rozdzieli jeden akapit, który mógłby obalić daną tezę, na dwa oddzielne embeddingi, agent badawczy i tak znajdzie coś brzmiącego płynnie i tematycznie powiązanego. Bycie powiązanym z właściwą odpowiedzią to nie to samo, co bycie przez nią logicznie wynikającym.
Czym musi być „uzasadnione”, inaczej nie ma żadnego znaczenia
„Uzasadnione” nie powinno być luźnym opisem nastroju lub tonu. Twierdzenie w systemie wielu agentów uznaje się za uzasadnione tylko wtedy, gdy spełnione są wszystkie następujące warunki:
- Twierdzenie ma określony typ. Jest oznaczone jako
Assertion,Conjecture,QuotelubActionIntent. Mieszanie tych kategorii w jedno pole tekstowe bez określenia typu jest dokładnie tym, co powoduje rozpad ścieżek audytowych. - Każda
Assertionodwołuje się do zapisu pochodzenia – wybranego fragmentu tekstu, wyniku działania narzędzia lub faktu bezpośrednio podanego przez człowieka. To odwołanie ma postać hasza treści, a nie URL-u stworzonego samodzielnie przez model. - Deterministyczna, niezależna od LLM weryfikacja potwierdziła, że odnoszony zapis pochodzenia rzeczywiście istnieje gdzieś w rejestrze procesu. Potwierdzenie istnienia jest tanie; potwierdzenie implikacji – nie. Obie weryfikacje są konieczne i muszą być przeprowadzone w tym właśnie kolejności.
Architektura niezdolna do odmowy udzielenia odpowiedzi nie może być wiarygodnie prawdziwa. Generowanie jest domyślnie najłatwiejszą drogą; wstrzymanie się musi być wprowadzone jako wyraźny, pierwszorzędny stan w grafie — i musi być tańsze do osiągnięcia niż proste ponowne wysłanie zapytania z innym promptem.
To jest cała podstawa. Wszystko inne to aspekty inżynieryjne niezbędne, aby te cztery zasady funkcjonowały po wprowadzeniu LangGraph, rzeczywistych wywołań narzędzi oraz menedżera produktu, który domaga się, by demo zawsze dostarczało odpowiedź.
Płaszczyzna sterowania, a nie prompt
Traktuj swoich agentów jak niezaufany środowisko wykonywania i umieść ich w płaszczyźnie sterowania. Płaszczyzna ta składa się z sześciu komponentów. Jeśli pominąć jeden z nich, reszta będzie stopniowo tracić funkcjonalność.
1. Typowany bus narzędzi
Każde narzędzie otrzymuje wersjonowaną specyfikację JSON Schema zarówno dla danych wejściowych, jak i wyjściowych, przechowywaną w rejestrze, którego model nie ma uprawnień do modyfikacji. Model może zaproponować wywołanie, ale deterministyczny walidator musi je zaakceptować lub odrzucić *przed* tym, zanim dojdzie do jakichkolwiek działań. Brak przymusowego przekształcania typów, brak mapowania „dostatecznie dobrego” między wartością z typu enum a tym, co wygenerował model. Jeśli wywołanie jest nieważne, wraca ono do planeru jako ustrukturyzowany błąd — nigdy w postaci upomnienia werbalnego.
To wydaje się oczywistym wymogiem, a jednak jest to element, który najczęściej pomija się w demonstracjach CrewAI lub AutoGen, ponieważ w takich demonstracjach nigdy nie występują narzędzia, które faktycznie zapisują dane do trwałego rejestru.
Dla każdego narzędzia o nieodwracalnych konsekwencjach — wysyłania czegoś, zapisywania pliku, wdrażania lub aktualizowania systemu przechowywania danych — mechanizm powinien wymagać podwójnej kontroli: ClaimSet, który już przeszedł weryfikację, oraz albo zatwierdzenia przez człowieka, albo wyraźnego upoważnienia zgodnie z polityką. W takim układzie agent operacyjny nigdy nie ma bezpośredniego dostępu do tych narzędzi.
2. Rejestr cytowań dołączanych wyłącznie
Każdy wynik wyszukiwania, każdy wyjście narzędzia oraz każdy fakt podany przez człowieka jest zapisywany w bazie danych dołączanej wyłącznie, indeksowanej za pomocą run_id i hasza treści. Agentom nie wolno po prostu „pamiętać” źródła w swoim osobistym notatniku — muszą zamiast tego cytować identyfikatory rejestru.
Jeśli agent pisarza tworzy zdanie bez dołączonego identyfikatora rejestru, to zdanie w ogóle nie stanowi stwierdzenia. Jest to tekst bez etykiety i nigdy nie powinien przechodzić przez bramkę schematu. To chyba najskuteczniejsze rozwiązanie, jakie można zastosować w istniejącej strukturze agentów: należy przestać pozwalać na wyjście prozy w swobodnej formie z systemu pod przykrywką danych.
Tutaj również ma znaczenie haszowanie. Model może cytować doc:matter-4421#p3, a mimo to błędnie przytaczać treść zapisaną na stronie 3. Rejestr musi przechowywać dokładny tekst — lub przynajmniej wskaźnik do niezmiennej bazy danych — aby weryfikator mógł sprawdzić dokładnie te bajty, a nie to, co model o nich pamięta.
3. Bramka schematu (nie-LLM)
Zanim jakikolwiek artefakt trafi dalej do następnego agenta — podsumowanie badań, obliczona wartość, zalecane działanie — musi przejść weryfikację według schematu, który obejmuje:
- tablica
claims[], z której każdy element zawieratype,text,ledger_ids[]oraz wartośćconfidence, która jest kalibrowana później, zamiast być po prostu uznawana przez model za „wysoką” - tablica
open_questions[], którą planer musi albo rozwiązać, albo wyraźnie przekazać do dalszej obróbki - tablica
action_intents[], która odnosi się do konkretnego narzędzia, a nie do ogólnikowego opisu sugerującego „powinniśmy chyba...”
To rozwiązanie musi być zwykłym kodem — Pydantic, JSON Schema, polityka CEL lub Rego, wybierz to, co preferujesz. Nie może to być model językowy typu LLM. Jeśli umieścisz tu model językowy, po prostu ponownie wdrożysz mechanizm krytyki i działania na niższym poziomie.
4. Weryfikator twierdzeń z innym dostępem do informacji
Tutaj kryje się rzeczywisty koszt. Weź każdą Assertion i podziel ją na najmniejsze, sprawdzalne elementy, tak aby każdy z nich odnosił się do jednego podmiotu, jednej relacji lub właściwości oraz jednego momentu lub okresu w czasie. Dla każdego z tych elementów pobierz dowody potwierdzające tylko z rejestru, nigdy z bieżących wyników wyszukiwania w internecie ani z parametrów samego modelu.
Następnie przeprowadź sprawdzenie implikacji: czy pobrany fragment potwierdza daną tezę, jest z nią sprzeczny, czy w ogóle nic o niej nie mówi? Możesz to zrealizować za pomocą małego modelu NLI, ograniczonego dekodera, który może kopiować tylko z tego fragmentu, lub człowieka sprawdzającego. Nie możesz jednak powierzyć tego zadania temu samemu dużemu modelowi do rozmów, używając tego samego promptu systemowego, i zapytać go, czy twierdzenie „wygląda prawidłowo”.
Gdy żądanie zostaje odrzucone, nikt po cichu nie poprawia sformułowania, aby przeszło przy następnej próbie. Wraca w formie Unsupported{proposition, missing_evidence}, a zadaniem osoby odpowiedzialnej za planowanie jest znalezienie dodatkowych dowodów, a nie tylko przeformułowanie problemu.
To kroku pozwala również wykryć subtelniejsze błędy: zastąpienie niejasnego, niepodważalnego stwierdzenia takim, które tylko wydaje się precyzyjne. Stwierdzenie, że faktura jest przeceniona, samo w sobie nie stanowi żądania podlegającego weryfikacji. Dopiero określenie konkretnych wartości — nazwa pozycji, ustalony w umowie limit, kwota przekraczająca ten limit oraz wpisy księgowe potwierdzające wszystko to — przekształca to w coś, co może zostać faktycznie potwierdzone lub odrzucone przez osobę sprawdzającą. Schemat, który akceptuje pierwszą, bardziej niejasną formę, ostatecznie będzie weryfikował ton tekstu zamiast faktów.
5. Wykorzystuj narzędzie eval do analizy konkretnych danych, a nie tylko intuicji
Potrzebujesz zamrożonego zestawu punktów odniesienia: danych wejściowych, zrzutów stanu księgi, oczekiwanych twierdzeń oraz oczekiwanych wstrzymań się od odpowiedzi. Każda zmiana w grafie — edycja promptu, zamiana modelu, inny narzędzie do dzielenia tekstu na fragmenty, nowe narzędzie — jest oceniana pod kątem:
- wierności: jaka część wypowiedzianych twierdzeń jest faktycznie implikowana przez księgę
- objętości: jaka część oczekiwanych twierdzeń została faktycznie wygenerowana przez graf, ponieważ milczenie samo w sobie może stanowić porażkę
- dokładności wstrzymywania się: gdy system odmówił odpowiedzi, czy ta odmowa była rzeczywiście uzasadniona
- higieny efektów ubocznych: brak wykonywanych nieodwracalnych wywołań narzędzi bez ważnego upoważnienia
Jeśli spadek wierności o dwa punkty nie może przeszkodzić w wdrożeniu, to nie masz płaszczyzny sterowania — masz jedynie panel kontrolny, który wygląda przekonująco.
Niezależnie od tego, co robisz, nie twórz tego zestawu oceny na podstawie wcześniejszych wyników modelu. To jedynie koduje obecny wzorzec halucynacji jako prawdę obiektywną. Dane referencyjne powinny pochodzić z oryginalnych dokumentów źródłowych oraz rzeczywistego systemu przechowywania danych, a następnie graf powinien być przeprowadzony wobec nich niezależnie. Taki sposób jest wolniejszy, ale to jedyna wersja tej miary, która rzeczywiście coś znaczy.
6. HITL na krawędzi nieodwracalności
Człowiek pełniący rolę recenzenta nie ma za zadanie uczynić agentów mądrzejszymi. Jego rolą jest znajdowanie się dokładnie w momencie, gdy system ma zamiar wysłać e-mail, zapisać dokument lub wpisać informację do bazy danych. Interfejs recenzji powinien pokazywać zestaw twierdzeń, odpowiednie okresy w księgach rachunkowych oraz planowaną funkcję narzędzia — a nie tylko ścianę historii rozmów. Jeśli ktoś musi analizować, dlaczego agent wierzył w dany fakt, projekt już nie spełnia swojego zadania.
W przypadku procesów o dużej przepustowości — weryfikacja faktur jest dobrym przykładem — ludzka kontrola powinna być stosowana wybiórczo i tylko w sytuacjach wyjątkowych, a nie we wszystkich przypadkach. System powinien automatycznie zatwierdzać dokumenty, gdy wszystkie twierdzenia są w pełni potwierdzone, a odchylenia finansowe mieścią się w akceptowalnym zakresie. Wszystko inne jest oznaczane jako wymagające sprawdzenia, a uwzględniane są tylko konkretne, niepotwierdzone roszczenia, a nie cały dokument.
Szkic umowy, a nie implementacja
Oto, jak powinien wyglądać obiekt przekazywany pomiędzy agentami. Logika orkiestracji, warstwa weryfikacji NLI, warstwa przechowywania księgi rachunkowej oraz komponent wydający zezwolenia są celowo pomijane — dotyczą one konkretnej implementacji i powinny znajdować się w kodzie produkcyjnym, a nie w artykule na blogu.
{
"run_id": "run_7f3c",
"from_agent": "analyst",
"claims": [
{
"id": "c_19",
"type": "Assertion",
"text": "Line item 14 exceeds the engagement-letter hourly cap.",
"propositions": [
{
"id": "p_19a",
"pred": "exceeds_cap",
"args": {"line_id": "14", "cap_source": "engagement_letter"},
"ledger_ids": ["led_aa12", "led_bb90"],
"entailment": null
}
]
}
],
"open_questions": [],
"action_intents": [
{
"tool": "flag_invoice_line",
"args": {"invoice_id": "INV-4421", "line_id": "14"},
"requires_grant": true,
"depends_on": ["c_19"]
}
]
}
Zwróć uwagę na to, czego brakuje: nie ma pola summary, które następny agent mógłby bezpośrednio skopiować. W tych streszczeniach właśnie giną wszelkie określenia i zastrzeżenia. Jeśli agent poniżej w łańcuchu potrzebuje tekstu opisowego, musi go stworzyć wyłącznie na podstawie zweryfikowanych twierdzeń, a dopóki człowiek nie zatwierdzi go jako tekstu przeznaczonego dla klienta, jest on oznaczony jako Conjecture.
Zauważ także, że wartość entailment jest ustawiona na null. Agent, który sformułował daną twierdzenie, nie ma prawa samodzielnie wypełniać tego pola – może to zrobić tylko osoba sprawdzająca. Pozwalanie agentowi oceniać własne twierdzenia jest jak pozwalanie firmie przeprowadzać własną audytę zgodności i nazywanie jej niezależnym nadzorem.
Dlaczego „po prostu dodaj cytaty” nadal nie działa
Najczęstszym fałszywym zabezpieczeniem jest wynik, który jedynie wygląda na cytowany. Model dodaje [1] lub [2], czasami nawet wskazując na rzeczywisty pobrany fragment tekstu. Następnie otwieramy ten fragment i okazuje się, że w rzeczywistości nie potwierdza on twierdzenia.
Sam cytat nic nie dowodzi. Prawdziwy dowód wygląda tak: ten konkretny fragment tekstu, ta dokładna sekwencja bajtów, przypisana do określonej tezy, z etykietą implikacji oraz regulowana wyraźną polityką dotyczącą tego, co dzieje się, gdy ta etykieta ma wartość neutral. Bez całego tego łańcucha „cytat” to po prostu wybór formatowania udający dowód.
Drugim fałszywym zabezpieczeniem jest ustawienie temperatury na 0. To nie sprawia, że wynik będzie bardziej prawdziwy — po prostu sprawia, że błędna odpowiedź pozostaje spójna. Stabilna halucynacja zawsze przejdzie testy typu snapshot. Nie przetrwa jednak właściwie utrzymywanej księgi rejestrowej.
Ile to naprawdę kosztuje
Rozruch pipeline demo w narzędziu takim jak LangGraph zajmuje zwykle kilka dni. Budowa rzeczywistej warstwy sterującej – rejestru narzędzi, księgi cytowań, mechanizmów weryfikacji schematów, narzędzia weryfikującego opartego na NLI, ocen typu gold-trace, przeglądu przez człowieka każdej ścieżki umożliwiającej zapis danych oraz logów wystarczająco szczegółowych, by prawnik mógł je przeanalizować – to właśnie odróżnia działający prototyp od systemu, któremu można zaufać przy podejmowaniu rzeczywistych decyzji biznesowych.
Nie istnieje jedna stała liczba, która odnosiłaby się we wszystkich przypadkach. Rzeczywisty koszt zależy od tego, ile z Twoich narzędzi powoduje skutki uboczne, czy źródło prawdy jest już ustrukturyzowane i dostępne do zapytań, oraz jak wysoki jest faktycznie koszt niepopartej twierdzenia w Twojej konkretnej dziedzinie. Rachunkowość prawna i raportowanie finansowe znajdują się na końcu tego spektrum o wysokich kosztach i dużym ryzyku. Narzędzie do burzy mózgów stworzone na bazie zespołu agentów znajduje się na przeciwległym końcu, a wymuszanie na nim obsługi tak dużej infrastruktury byłoby przesadą.
Pierwsze pytanie, które warto zadać, to nie to, na jakiej ramie programowej budować – lecz określenie tego, gdzie w tym spektrum znajduje się Twój własny proces pracy.
Jeśli to rzeczywiście jest Twój problem
Taki rodzaj płaszczyzny sterowania jest najważniejszy dla zespołów, które nie mogą zaakceptować odpowiedzi brzmiącej pewnie, ale błędnej: generalnie w pracy prawniczej, finansach oraz operacjach wymagających dużych ilości dokumentów. Oznacza to grafy agentów budowane za pomocą narzędzi takich jak LangGraph, pipeline’y do wyszukiwania, które są rzeczywiście weryfikowane, a nie zakładane jako działające, oraz systemy ekstrakcji, które muszą wytrzymać audyt.
Jeśli wasz własny graf sprawdza się przekonująco podczas demonstracji, ale po wdrożeniu zaczyna generować fałszywe twierdzenia, przyczynę niemal zawsze można odnaleźć w jednym z sześciu komponentów omawianych tutaj — a ustalenie, który to jest oraz czy opłaca się zainwestować wysiłki inżynierskie w jego naprawę, stanowi prawdziwy punkt wyjścia do określenia zakresu pracy.
Literatura pokrewna
- Projektowanie wydolnych grafów agentów SI: ponawianie prób, rozwiązania awaryjne i GraphRAG — Dowiedz się, jak budować odporną na błędy architekturę procesów agentów SI przy użyciu specjalnych ścieżek obsługi awarii, logiki ponawiania prób, LangGraph oraz kiedy GraphRAG przewyższa zwykły RAG lub pętle agentów.
- Co ujawnia 10-minutowe budowanie agenta o rzeczywistej architekturze — Analizuje, dlaczego szybkie narzędzia do tworzenia agentów, takie jak TrueForge, mogą ukrywać decyzje architektoniczne, z którymi musisz się zmierzyć przy użyciu ręcznych frameworków, takich jak Deep Agents.