Jak ograniczyć halucynacje agenta AI w firmie: tak budujemy agenta, który najpierw sprawdza, a potem mówi

Jest taka scena, którą zna każdy, kto wdrażał agenta AI w firmie. Agent obsługujący zapytania dostaje pytanie o wysokość rabatu dla stałego klienta i odpowiada pewnym głosem: "standardowo udzielamy 15 procent". Brzmi wiarygodnie. Jest gładko sformułowane. I jest kompletnie zmyślone, bo taka reguła w tej firmie nigdy nie istniała. Nikt tego nie zauważa, dopóki klient nie zaczyna się rabatu domagać.

To jest halucynacja i to nie jest usterka, którą naprawia się przez podmianę modelu na mądrzejszy. Mądrzejszy model zmyśla równie pewnie, tylko ładniejszym językiem. Dobra wiadomość jest taka, że halucynacje da się realnie ograniczyć, i to nie magią, tylko inżynierią. Trzeba dać agentowi pamięć zamiast kazać mu zgadywać. Poniżej opisujemy, jak budujemy agentów AI dla firm, krok po kroku, wraz z decyzjami, które w praktyce okazują się najważniejsze, i z tymi, które wyglądają na drobiazgi, a rozstrzygają o wszystkim.

Dlaczego agent w ogóle zmyśla

Model językowy nie zna Twoich dokumentów. Ma to, czego nauczył się z internetu, plus to, co wkleisz mu do zapytania. Kiedy pytasz go o rzecz specyficzną dla firmy, a nie dostał żadnego dokumentu na ten temat, robi dokładnie to, do czego został wytrenowany: produkuje najbardziej prawdopodobnie brzmiące zdanie. Nie kłamie ze złej woli. Uzupełnia lukę statystycznie najładniejszą odpowiedzią, bo nie umie inaczej.

Stąd bierze się zasada nadrzędna, którą powtarzamy klientom jak mantrę: halucynacja to nie wada modelu, to brak dowodu pod ręką w chwili odpowiedzi. Jeśli w momencie pytania agent ma przed sobą właściwy fragment procedury, odpowie z niego. Jeśli nie ma nic, wymyśli. Całe ograniczanie halucynacji sprowadza się więc do jednego: zadbać, żeby w chwili odpowiedzi właściwy dowód leżał agentowi na biurku. Fachowo nazywa się to grounding, czyli ugruntowanie odpowiedzi w faktach. Po ludzku: agent najpierw sprawdza, potem mówi.

Z tej jednej zasady wynikają cztery reguły, które mają pierwszeństwo przed każdą inną decyzją projektową. Agent odpowiada wyłącznie z dostarczonych dowodów. Każde twierdzenie wskazuje konkretny dokument. Kiedy dowody są słabe, agent mówi "nie wiem" i kieruje do człowieka. I czwarta, najczęściej pomijana: świeżość dowodu jest jego cechą, bo zacytowanie procedury nieaktualnej od półtora roku to też halucynacja, tylko znacznie trudniejsza do wykrycia, skoro dokument istnieje naprawdę.

Dwie decyzje, które ustawiają całą resztę

Zamiast szukać "lepszego" modelu, budujemy agentowi pamięć: firmową bazę wiedzy, którą przeszukuje przed każdą odpowiedzią. Dwie decyzje zapadają od razu i to one determinują koszt całego wdrożenia.

Pierwsza: spotykamy dane tam, gdzie żyją. Klasyczny pomysł na porządek w firmie brzmi "przenieśmy wszystko do jednego systemu, żeby była jedna prawda". Ten sen prawie nigdy się nie spełnia, bo ludzie i tak piszą tam, gdzie im wygodnie: ustalenia w dokumencie, zgłoszenie w mailu, dyskusja na czacie. Każde z tych narzędzi jest dopracowane pod swoje zadanie i dyskusja o umowie w arkuszu kalkulacyjnym byłaby udręką. Zamiast walczyć z przyzwyczajeniem, pobieramy dane z każdego z tych miejsc osobno i zostawiamy je na swoim miejscu. Zero migracji treści, zero uczenia ludzi nowego narzędzia do pisania.

Druga: jedna wspólna tabela na wszystko. Niezależnie od tego, czy wiedza przyszła z dysku, z maila czy z wewnętrznej bazy, ląduje jako wiersz o tym samym kształcie: treść w oryginale, jej oczyszczona wersja, reprezentacja liczbowa do wyszukiwania po znaczeniu, metadane, link do źródła i znaczniki czasu. Dzięki temu odpytywanie wygląda tak samo dla każdego źródła, a podłączenie nowego nie wymaga przebudowy systemu, tylko dopisania małego konektora, który potrafi z tego źródła czytać i zwracać wiersze w umówionym formacie.

To brzmi jak detal organizacyjny, a jest testem, czy architektura jest zdrowa. Kryterium brzmi tak: podłączenie kolejnego źródła to jeden plik i wpis w konfiguracji, bez dotykania wyszukiwania, odpowiadania i interfejsu. Jeśli kiedykolwiek przestaje to być prawda, znaczy, że system zaczął się zaplątywać we własne wyjątki. To zresztą ta sama dyscyplina, którą stosujemy w automatyzacjach procesów: jeden kształt danych, dowolnie wiele wejść.

Świadomie odpuszczamy przy tym w małej firmie całą warstwę uprawnień znaną z korporacji: kto ma prawo zobaczyć które dane, audyt dostępów, analitykę. Tam, gdzie wszyscy i tak korzystają z tej samej wiedzy, budowanie tego na starcie to koszt bez zwrotu. Dokładamy ją, gdy część wiedzy musi zostać zamknięta. Odpuszczamy też przetwarzanie w czasie rzeczywistym, bo wiedza odświeżana wsadowo co kilka godzin w zupełności wystarcza, a nikt nie odczuwa różnicy. Zostaje to, co naprawdę odpowiada za brak halucynacji. Przejdźmy przez to po kolei.

Krok pierwszy: zapisuj całości, nie strzępki

Pierwsza pokusa przy pobieraniu danych to zapisywać zdarzenia: nową wiadomość, nowy komentarz, nową wersję akapitu. To najkrótsza droga do korpusu złożonego z sierot bez kontekstu.

Dlatego jednostką, którą zapisujemy, jest zawsze kompletna całość: cały dokument, cały wątek korespondencji, cała rozmowa. Kiedy w wątku pojawia się nowa odpowiedź, nie dopisujemy jej z boku, tylko pobieramy wątek od nowa i zapisujemy w całości jeszcze raz. Dzięki temu zapisana treść, lista uczestników i data ostatniej aktywności zawsze opisują kompletną rozmowę, a nie jej przypadkowy wycinek.

Powód jest praktyczny i wraca potem w każdej odpowiedzi agenta. Fragment "zwróć zaliczkę" wyrwany z kontekstu jest gorszy niż brak odpowiedzi, jeśli zdanie wyżej brzmiało "chyba że umowa trwała krócej niż dwa tygodnie". Wiedza firmowa prawie zawsze ma warunki, a warunki mieszkają w sąsiedztwie.

Krok drugi: streszczaj, zanim zapiszesz

Druga pokusa jest taka, żeby wziąć surowy dokument, pociąć na kawałki i zapisać jak leci. To działa słabo, bo surowa firmowa komunikacja jest gęsta od szumu. Wątek zgłoszenia ma dwadzieścia wiadomości, z czego istotne są dwie, a osiemnaście to "dzięki", "jasne" i "spojrzę na to jutro".

Rzecz w tym, że wyszukiwanie po znaczeniu opiera się na uśrednieniu sensu całego tekstu. Jeśli tekst w osiemdziesięciu procentach jest uprzejmościami, to jego reprezentacja liczbowa leży bliżej uprzejmości niż problemu, który ten wątek rozwiązał. Zapisanie surowca to więc nie oszczędność, tylko zatrucie własnej wyszukiwarki.

Dlatego przed zapisaniem przepuszczamy treść przez model, który wyciąga z niej strukturę: jakie pytanie ten materiał realnie rozwiązuje, krótkie streszczenie, konkretne fakty, rozstrzygnięcie, wymienione osoby i systemy, a osobno warunki i wyjątki, które to rozstrzygnięcie ograniczają. Dopiero ten oczyszczony artefakt zapisujemy jako reprezentację do wyszukiwania po znaczeniu. Surowy tekst też zostaje, ale służy wyszukiwaniu po słowach.

Jest tu jeden niepozorny szczegół, który robi zaskakująco dużo dobrego: wśród wyciąganych pól jest pytanie, którego ktoś realnie by szukał, a nie opis dokumentu. Użytkownik przychodzi do agenta z pytaniem, więc jeśli w bazie leżą pytania, obie strony mówią tym samym językiem. To drobiazg w implementacji i wyraźna różnica w trafności.

Do każdego wyciętego fragmentu doklejamy jeszcze dwa, trzy zdania kontekstu z dokumentu nadrzędnego: o czym jest całość i w którym miejscu ten fragment się znajduje. Koszt jednorazowy, symboliczny, a fragment przestaje być anonimowym akapitem. W badaniach nad tym zabiegiem sama ta zmiana ścina liczbę nietrafionych wyszukiwań o około jedną trzecią, a w połączeniu z krokami opisanymi niżej o dwie trzecie. Rzadko kiedy jedna decyzja projektowa daje taki zwrot.

Krok trzeci: kilka wyszukiwań naraz i głosowanie

Tu jest sedno i tu popełnia się najczęstszy błąd, czyli oparcie wszystkiego na wyszukiwaniu po znaczeniu. Gdyby szukać wyłącznie tak, agent regularnie gubiłby rzeczy, które trzeba trafić dosłownie, i uzupełniałby je z głowy. Wyobraź sobie pytanie z wklejonym numerem zamówienia albo kodem błędu. Wyszukiwanie po znaczeniu zwróci coś "podobnego w klimacie", ale niekoniecznie ten jeden dokument, w którym ten dokładny numer występuje. A stąd już tylko krok do pewnej siebie, błędnej odpowiedzi.

Dlatego uruchamiamy kilka niezależnych wyszukiwań równolegle i pozwalamy im się nawzajem korygować, bo żadne z nich nie zasługuje na zaufanie w pojedynkę. Wyszukiwanie po słowach łapie dokładne ciągi znaków: numery, nazwy plików, kody, symbole. Kiedy ktoś wkleja literalny fragment, dokładne trafienie jest najlepszym możliwym dowodem i żadne "podobieństwo w klimacie" nie ma prawa go przebić. Wyszukiwanie po znaczeniu łapie z kolei parafrazę, czyli sytuację, w której pytający i osoba, która kiedyś odpowiedziała, użyli zupełnie innych słów o tym samym. Trzecie wyszukiwanie premiuje rzadkie słowa, bo krótka wiadomość zbudowana wokół jednego nietypowego terminu bywa cenniejsza niż długi elaborat, a jednocześnie właśnie ten mechanizm zbija do zera uprzejme "jasne, dzięki", które w przestrzeni znaczeń podejrzanie często wygląda na pasujące do wszystkiego.

Czwarte to świeżość. Gdy dwa dokumenty pasują tak samo dobrze, wygrywa nowszy, bo spora część firmowych halucynacji to w rzeczywistości uczciwe cytowanie procedury, która była aktualna półtora roku temu. Jest przy tym pułapka, w którą łatwo wpaść: świeżość trzeba liczyć od daty powstania treści, a nie od daty jej zaimportowania. Pomylenie tych dwóch dat sprawia, że po każdym większym imporcie cała baza wygląda na świeżą i cały mechanizm przestaje działać, nie dając po sobie znać.

Te osobne listy wyników trzeba połączyć w jedną. Robi to prosta metoda liczenia głosów, w której dokument zyskuje tym więcej, im wyżej pojawia się na wielu listach naraz. Efekt jest taki, że dokument znajdujący się w środku stawki na czterech listach spokojnie wygrywa z dokumentem, który jest pierwszy na jednej i nie ma go nigdzie indziej. Wygrywa konsensus, a nie pojedynczy mocny, ale przypadkowy strzał jednej metody. To kilka linijek kodu, nie żadne osobne, drogie narzędzie, a przy okazji rozwiązuje kłopot, o którym mało kto pamięta: wyniki różnych wyszukiwarek są w zupełnie nieporównywalnych skalach, a liczenie głosów po miejscach w rankingu jest na to odporne.

Na koniec tego etapu robimy jeszcze jedną rzecz, która wygląda na kosmetykę, a bywa ratunkiem: scalamy powtórki i ograniczamy, ile fragmentów może wnieść jeden dokument. Bez tego jeden gadatliwy regulamin pocięty na dwadzieścia kawałków zajmuje całą przestrzeń i agent odpowiada z jednego źródła, które akurat było długie, a nie z tego, które było trafne.

Krok czwarty: przesortuj, dopiero potem dokładaj kontekst

Nawet po połączeniu list na górze ląduje czasem dokument, który dzieli z pytaniem słowa, ale odpowiada na zupełnie inne pytanie. Dlatego bierzemy kilkanaście najlepszych kandydatów i przepuszczamy je przez wyspecjalizowany model przesortowujący, który ocenia każdy pod kątem konkretnego pytania i zostawia najlepszą garstkę. Warto zauważyć, że to inne pytanie niż wcześniej: wyszukiwanie pyta "co jest podobne", a przesortowanie pyta "co odpowiada właśnie na to". To tani filtr, który wyłapuje "podobne, ale nie na temat", zanim trafi do odpowiedzi.

Dopiero teraz, kiedy kolejność jest już ostateczna, do zwycięskich fragmentów doklejamy ich sąsiadów, żeby agent zobaczył także nagłówek, warunek i wyjątek rozdzielone przez cięcie dokumentu. Kolejność tych dwóch czynności jest kluczowa i bardzo łatwo ją odwrócić. Gdyby dokładać kontekst wcześniej, płacilibyśmy za niego przy każdym z kilkudziesięciu kandydatów, a przy okazji zaburzyli ocenę, bo dłuższy fragment wygląda na bogatszy.

Krok piąty: mniej dowodów, lepiej ułożonych

Intuicja podpowiada, że skoro model ma duże okno kontekstu, to im więcej dokumentów mu podamy, tym lepiej. Intuicja jest tu fałszywa i to jest jedna z najlepiej udokumentowanych rzeczy w całym temacie.

Trafność modelu zależy od tego, gdzie w podanym materiale leży właściwy dowód. Najwyższa jest, gdy dowód jest na samym początku, prawie tak samo wysoka, gdy jest na samym końcu, a najniższa, gdy ląduje w środku. Przy dwudziestu, trzydziestu dokumentach z dowodem schowanym w środku model odpowiada nie lepiej, niż gdyby nie dostał żadnych dokumentów w ogóle. Innymi słowy, dosypywanie kontekstu bez sortowania potrafi aktywnie szkodzić, a powiększanie okna niczego samo z siebie nie naprawia.

Dlatego do odpowiedzi podajemy kilka najlepszych dowodów, nie kilkadziesiąt, ułożonych malejąco, z najlepszym na samej górze i drugim najlepszym na samym dole. Każdy dowód dostaje swój numer, źródło i datę, wyraźnie oddzielone od instrukcji i od pytania. To wygląda na formatowanie, a jest różnicą między odpowiedzią z dowodu a odpowiedzią obok dowodu.

Krok szósty: bramka, czyli prawo do "nie wiem"

Teraz najważniejsza część i jednocześnie ta, o której najczęściej się zapomina, bo nie widać jej w demo. Zanim agent w ogóle zacznie formułować odpowiedź, sprawdzamy, czy zebrane dowody są wystarczająco dobre.

Jeśli najlepszy znaleziony dowód jest słaby, jeśli jest tylko jeden, albo jeśli wszystko, co znaleźliśmy, pochodzi sprzed dwóch lat i nic nowszego tego nie potwierdza, odpowiedź się nie odbywa. Agent mówi wprost, że nie ma na to pokrycia w wiedzy firmy, pokazuje najbliższe tematycznie dokumenty jako tropy i podpowiada, kogo zapytać, wskazując osobę, która najczęściej jest autorem dokumentów w tym obszarze.

Jest w tym rozwiązaniu przyjemna symetria: odmowa jest tańsza niż odpowiedź, bo w ogóle nie wołamy dużego modelu. Bezpieczne zachowanie jest jednocześnie tańszym zachowaniem, a to zdrowa struktura zachęt, w odróżnieniu od systemów, w których ostrożność trzeba wymuszać wbrew ekonomii.

Progi tej bramki ustawia się na danych, a nie z sufitu, i przy ich dobieraniu obowiązuje świadoma asymetria. Fałszywa odmowa kosztuje jedno pytanie zadane człowiekowi. Fałszywa odpowiedź kosztuje zaufanie do całego systemu, a odbudowuje się je miesiącami. Dlatego próg zawsze przesuwamy w stronę ostrożności. To brzmi banalnie, a jest najtrudniejsze, bo domyślnie model woli powiedzieć cokolwiek niż przyznać się do niewiedzy. Zespół, który pierwszy raz widzi uczciwe "nie wiem" zamiast wymyślonego rabatu, zaczyna agentowi ufać. A o to zaufanie toczy się cała gra.

Krok siódmy: cytowania i sprawdzanie cytowań

Reguła dla samej odpowiedzi jest twarda: agent odpowiada wyłącznie na podstawie dostarczonych dowodów i przy każdym twierdzeniu wskazuje źródło. Nie ma dowodu, nie ma zdania. Sam wymóg cytowania działa jak smycz, bo modelowi znacznie trudniej zmyślić fakt, kiedy musi zaraz obok wskazać dokument, z którego on rzekomo pochodzi.

Tylko że wymóg to za mało, bo model potrafi też zacytować dokument, który z odpowiedzią nie ma wiele wspólnego, i to jest najpodstępniejszy wariant halucynacji: wygląda na zweryfikowany. Dlatego po wygenerowaniu odpowiedzi przepuszczamy ją przez prosty, mechaniczny sprawdzian. Czy każde odwołanie wskazuje na istniejący dowód. Czy każdy akapit z twierdzeniem faktycznym w ogóle ma odwołanie. Czy liczby, kwoty i daty użyte w odpowiedzi faktycznie występują w zacytowanym fragmencie, bo akurat one są najczęstszym przedmiotem zmyślenia i najłatwiej je zweryfikować maszynowo. Odpowiedź, która tego nie przechodzi, zamienia się w odmowę.

Ta kontrola nie wymaga żadnego modelu, jest natychmiastowa i praktycznie darmowa. Trudno o lepszy stosunek nakładu do efektu.

Zdarza się też sytuacja, w której dwa dobre dowody mówią coś przeciwnego. Agent nie wybiera wtedy po cichu nowszego i nie udaje, że problemu nie ma. Pokazuje obie wersje z datami, wskazuje, która jest świeższa, i sygnalizuje, że dokumenty wymagają uporządkowania. To jeden z ładniejszych efektów ubocznych całego wdrożenia: system zaczyna wykrywać sprzeczności w firmowej dokumentacji, co bywa cenniejsze niż sama odpowiedź.

Narzędzia, które wystarczą

Dobra wiadomość jest taka, że nie trzeba do tego infrastruktury rodem z wielkiej korporacji. Cały rdzeń składamy z rzeczy dostępnych od ręki, zwykle w wariancie na serwerze klienta, tak by firmowe dokumenty w ogóle nie wychodziły na zewnątrz.

Sercem jest jedna baza danych z rozszerzeniem wektorowym, bo trzyma w jednym miejscu i reprezentacje liczbowe, i wyszukiwanie po słowach, czyli obie połowy hybrydy. Reprezentacje generuje model wielojęzyczny, który dobrze radzi sobie z polskim i który stawiamy lokalnie. Podobnie z modelem przesortowującym. Pobieranie danych z dysku, poczty czy innych systemów biorą na siebie gotowe biblioteki z setką konektorów, a odświeżanie co kilka godzin ogarnia zwykły harmonogram zadań. Całość spina agent, który decyduje, czego i kiedy szukać.

Jest tu jeden szczegół specyficzny dla polskiego, o który bardzo łatwo się potknąć, bo nie objawia się błędem, tylko cichą słabością wyników. Wyszukiwanie po słowach musi rozumieć odmianę, inaczej "faktury" nie trafi w "fakturę". Standardowa konfiguracja bazy tego dla polskiego nie robi i trzeba jej dołożyć słownik. Wszystko wtedy "działa", a po prostu połowa hybrydy jest wyłączona i nikt tego nie widzi.

Kwestię bezpieczeństwa i RODO w agentach zostawiamy na osobny tekst, bo przy firmowych danych zasługuje na własne miejsce. Tutaj wystarczy powiedzieć, że postawienie całego zestawu lokalnie jest świadomą decyzją, a nie przypadkiem, i że pomaga jej sposób, w jaki dzielimy system: warstwa wyszukiwania jest prosta i sama z siebie nie korzysta z modelu, więc wrażliwe dokumenty nie muszą w całości przepływać przez model, żeby agent mógł z nich skorzystać.

Jak to mierzyć, żeby nie oceniać na oko

Bez tego cała reszta wisi w powietrzu, bo każda zmiana ustawienia staje się kwestią wrażeń. Dlatego od pierwszego dnia utrzymujemy zestaw pytań kontrolnych, w którym są cztery grupy: pytania z jasną odpowiedzią w wiedzy firmy, pytania z wklejonym numerem albo kodem, pytania o rzeczy, które w firmie się zmieniły, i, co najważniejsze, pytania spoza wiedzy firmy, na które poprawną odpowiedzią jest odmowa. Ta ostatnia grupa jest zwykle pomijana, a jest jedyną, która sprawdza to, na czym najbardziej nam zależy.

Mierzymy cztery rzeczy: jaki procent odpowiedzi ma poprawne cytowanie, jak często agent trafnie mówi "nie wiem", jak często odmawia niepotrzebnie oraz jak często cytuje dokument nieaktualny. Ta ostatnia metryka jest w praktyce najrzadziej liczona, a wyłapuje halucynację najtrudniejszą do zauważenia, bo formalnie wszystko się zgadza: dokument istnieje, cytat się zgadza, tylko świat poszedł dalej. To są liczby, które można pokazać zarządowi i które mówią więcej niż wrażenie, że "asystent jakoś mądrzej gada".

Od czego zacząć, żeby nie utonąć

Największy błąd to próba podłączenia wszystkiego naraz. Wchodzimy małym, ale kompletnym krokiem. Jedno źródło, które boli najbardziej, i na nim pełny łańcuch: pobranie całości, streszczenie, zapis do jednej tabeli, kilka wyszukiwań z głosowaniem, bramka pewności i odpowiedź z cytowaniem albo uczciwa odmowa. Celem pierwszej rundy nie jest imponujący zakres, tylko garść typowych pytań, na które agent odpowiada z dowodem, i pytania spoza wiedzy, na które grzecznie odmawia zgadywania.

Dopiero potem dokładamy jakość i kolejne źródła: model przesortowujący, wagę świeżości, dociąganie sąsiedztwa, drugie i trzecie źródło tym samym schematem. Rzeczy, które w dużych wdrożeniach wyglądają imponująco, czyli przetwarzanie w czasie rzeczywistym, dzielenie wiedzy na projekty czy indeksowanie repozytoriów kodu, świadomie odkładamy i umawiamy się z góry, co ma się wydarzyć, żeby wróciły do gry. Bo najdroższe w takich systemach nie jest to, czego brakuje, tylko to, co zbudowano za wcześnie.

Co z tego ma firma

Agent, który najpierw sprawdza, a potem mówi, przestaje być efektowną zabawką, a zaczyna być narzędziem, któremu zespół ufa. Zamiast pewnej siebie odpowiedzi bez pokrycia dostajesz odpowiedź z linkiem do źródła, którą można w dwie sekundy zweryfikować, albo uczciwe przyznanie, że tej wiedzy w firmie nie ma. Halucynacja nie znika dlatego, że model nagle zmądrzał. Znika, bo w chwili odpowiedzi na biurku leży właściwy dokument, a kiedy nie leży, agent ma prawo się do tego przyznać.

Takie systemy budujemy w ramach wdrożeń agentów AI. Jeśli Twojemu agentowi zdarza się zmyślać albo dopiero planujesz wdrożenie i nie chcesz, żeby to robił, napisz na hello@mtzn.pl. Pokażemy na Twoich danych, ile z pytań, które dziś kończą się zgadywaniem, dałoby się oprzeć o twardy dowód. Spoiler: agent, który umie powiedzieć "nie wiem", jest znacznie bardziej przekonujący niż taki, który wie zawsze.