Dlaczego asystent od dokumentów wciąż zmyśla i jak to ukrócić

Asystent podpięty do firmowych dokumentów odpowiada na pytanie o procedurę trzema gładkimi zdaniami. Tego stwierdzenia nie ma nigdzie w zbiorze. To pierwszy problem, na jaki natykają się zespoły, i rozpada się on na dwa osobne: model zmyśla treść od zera albo poprawnie streszcza niewłaściwy znaleziony fragment. Jest jeszcze trzeci przypadek, który prawie wszyscy przeoczają. Odpowiedź jest trafna, ale podane przy niej źródło jej nie potwierdza, a to podkopuje zaufanie szybciej niż zwykła pomyłka. Wyszukiwanie zawęża to, z czego model może korzystać. Nie sprawia, że zmyślanie staje się niemożliwe. Większość konfabulacji, na jaką traficie, to problem instalacji, a dopiero potem problem modelu.

Wyszukiwanie zawodzi wcześniej niż model

Model odpowiada na podstawie tego, co dostał, więc zła odpowiedź zwykle zaczyna się od złego zestawu fragmentów. Podobieństwo semantyczne to słabe sito na dokładne identyfikatory, numery katalogowe, daty i oznaczenia wersji procedur. A odcięcie top-k po cichu odrzuca ten jeden akapit, który miał znaczenie, zwłaszcza w długich, powtarzalnych dokumentach, gdzie wszystko wygląda trochę jak wszystko.

• Odpowiedź przeczy obecnej praktyce: nieaktualny dokument wypadł wyżej niż obowiązujący.
• Odpowiedź trafia w temat, ale mija się z faktami: embeddingi dopasowały temat, pominęły konkretny obiekt.
• Odpowiedź ucina zasadę: chunk przeciął tabelę albo zapis w połowie.
• Odpowiedź jest zmyślona w całości: zbiór po prostu jej nie zawiera.

Decyzje o chunkingu i metadanych podejmujesz raz i z nimi żyjesz

Granice chunków kodują założenia o tym, jak czyta się dokument. Umowy, instrukcje i zgłoszenia serwisowe wymagają różnego traktowania. Zostaw przy nich kontekst strukturalny - nagłówek sekcji, tytuł dokumentu, datę obowiązywania - żeby model wiedział, co trzyma w ręku. Filtry po metadanych, czyli po dziale, typie dokumentu, okresie ważności i poziomie dostępu, obcinają pulę kandydatów jeszcze przed jakimkolwiek scoringiem, a to tańsze i pewniejsze niż liczenie na to, że ranker sam sobie z tym poradzi.

Wskazówka: zapisuj datę i status dokumentu jako pola do filtrowania, a nie jako tekst zakopany w środku chunka, żeby "tylko obowiązujące procedury" stało się warunkiem zapytania, a nie pobożnym życzeniem.

Odpowiedź zakotwiczona we fragmencie, nie w modelu

Instruujemy asystenta, żeby odpowiadał wyłącznie z podanych fragmentów i mówił wprost, kiedy nie obejmują one pytania. "Nie wiem" musi być dopuszczalnym wynikiem, a nie stanem, przed którym system wykręca się, jak może. Podpięcie źródeł zmienia też zachowanie czytelnika: ludzie sprawdzają, a błędne cytowanie od razu rzuca się w oczy. Wskazanie konkretnego fragmentu jest lepsze niż odesłanie do 60-stronicowego PDF-a. Pytania o wyciągnięcie faktu są bezpieczniejsze niż synteza z wielu dokumentów, a synteza zasługuje na ostrzejsze zabezpieczenia.

Warstwy weryfikacji, zanim odpowiedź trafi do użytkownika

1. Czy każde stwierdzenie da się przypisać do znalezionego fragmentu?
2. Czy przytoczone liczby występują w źródle dosłownie?
3. Czy wskazany chunk faktycznie zawiera zdanie, które to potwierdza?
4. Czy pewność wyszukiwania przekracza próg pozwalający w ogóle odpowiadać?

Kiedy najlepszy fragment wypada słabo, oddanie samych dokumentów bez wygenerowanej odpowiedzi jest lepszą decyzją produktową. Sprawdzanie w drugim przebiegu kosztuje czas i tokeny, więc uzasadniaj je dla konkretnego zastosowania, zamiast włączać wszędzie odruchowo.

Wskazówka: zapisuj w logu identyfikatory znalezionych fragmentów obok każdej odpowiedzi. Bez tego śladu nie odróżnisz chybionego wyszukiwania od błędu generowania, gdy ktoś zgłosi złą odpowiedź kilka tygodni później.

Jak zmierzyć, czy naprawdę jest lepiej

Zbuduj zestaw ewaluacyjny z prawdziwych pytań użytkowników, łącznie z tymi, na które zbiór nie potrafi odpowiedzieć. Oceniaj wyszukiwanie i generowanie osobno. Jedna liczba z całości ukrywa sytuację, w której jedno się pogarsza, a drugie poprawia, i przez tydzień będziesz szukać w złej warstwie. Śledź też odsetek odmów odpowiedzi i to, czy były trafne, bo asystent, który nigdy nie odmawia, nie jest uczciwy. Wracaj z poprawkami użytkowników do zestawu i przepuszczaj go ponownie po każdej zmianie chunkingu, embeddingów, parametrów wyszukiwania albo promptów. Te rzeczy oddziałują na siebie w sposób trudny do przewidzenia.

Miejsce działania systemu decyduje o tym, co możesz naprawić

Wdrożenie w chmurze i on-premise ograniczają co innego. Działanie w całości na infrastrukturze klienta trzyma dokumenty regulowane albo poufne wewnątrz organizacji, co w części branż przesądza o architekturze, zanim ktokolwiek zdąży zacząć rozmowę o trafności. Instalacja u siebie daje też pełny dostęp do logów, indeksu i pętli ewaluacyjnej, przez co konfabulację o wiele łatwiej zdiagnozować wprost. Jedna rzecz nie podlega negocjacji: kontrola dostępu musi działać już na etapie wyszukiwania. Odpowiedź z dokumentu, którego użytkownik nie może czytać, to poważniejsza wpadka niż halucynacja.

Najczęściej zadawane pytania

Czy retrieval augmented generation likwiduje halucynacje?

Nie. Zawęża grunt, po którym stąpa model, i pozwala sprawdzać błędy dzięki podpiętym źródłom, choć model wciąż może źle odczytać fragment albo zszyć ze sobą dwa niepowiązane. Zysk polega na tym, że takie błędy stają się wykrywalne zamiast niewidocznych.

Dlaczego asystent odpowiada pewnym tonem, choć dokumenty milczą?

Modele językowe produkują gładkie ciągi dalsze, a powstrzymanie się od odpowiedzi nie jest ich domyślnym zachowaniem. Dopóki odmowa nie jest wprost nakazana, nagradzana i wymuszona progiem pewności, system woli odpowiedzieć niż odmówić.

Może zamiast poprawiać wyszukiwanie, lepiej dostroić model?

Rzadko jako pierwszy krok. Fine-tuning uczy tonu, formatu i słownictwa branżowego, ale nie utrzyma asystenta na bieżąco, gdy dokumenty się zmieniają, a wiedzy wtrenowanej w model nie da się przypisać do źródła.

Co naprawilibyśmy w pierwszej kolejności

Konfabulacja w asystencie od dokumentów to zwykle wyszukiwanie, chunking i brak odmowy odpowiedzi, a nie wadliwy model. Dlatego przy pytaniach, które zawodzą, zajrzyj najpierw do znalezionych fragmentów, zanim ruszysz prompt. Potem popraw chunking i metadane, dodaj odmowę i weryfikację, i mierz. To, co czyni system godnym zaufania w codziennym użyciu, to widoczne źródła i uczciwa odmowa, a nie wyższy wynik w benchmarku. Zbuduj ślad i zestaw ewaluacyjny wcześnie, bo każda późniejsza poprawka zależy od tego, czy wiesz, która warstwa zawiodła.