RAG bez halucynacji: chunking, retrieval i co decyduje o jakości odpowiedzi

Czas czytania: ok. 8 minut

Krótka odpowiedź: RAG halucynuje rzadziej niż goły model, bo odpowiada z Waszych dokumentów, ale nie halucynuje wcale tylko wtedy, gdy dobrze zaprojektujecie trzy rzeczy: podział dokumentów na fragmenty (chunking), skuteczność wyszukiwania (retrieval) i uczciwe zachowanie, gdy podstawy brakuje. Najczęstsza przyczyna błędnych odpowiedzi to nie „głupi model", tylko to, że właściwy fragment nie został znaleziony, albo znaleziono fragment podobny słowami, lecz nietrafny. Poniżej po kolei, co realnie decyduje o jakości.

Skąd biorą się błędy w RAG

Model generujący tekst zawsze stara się ułożyć spójną, wiarygodnie brzmiącą odpowiedź. Jeśli system wyszukiwania poda mu dobre, trafne fragmenty, odpowiedź będzie oparta na faktach. Jeśli poda fragmenty luźno powiązane albo nie poda nic, model może skleić coś, co brzmi dobrze, a jest błędne. Dlatego w RAG walka o jakość toczy się przede wszystkim na etapie wyszukiwania, zanim model w ogóle zacznie pisać.

Chunking: jak dzielicie dokumenty

Dokumentów nie wrzuca się do systemu w całości. Dzieli się je na fragmenty, które potem są przeszukiwane. To wbrew pozorom jedna z najważniejszych decyzji.

• Zbyt duże fragmenty mieszają kilka tematów naraz, przez co wyszukiwanie traci precyzję, a model dostaje dużo szumu.
• Zbyt małe fragmenty gubią kontekst. Sam parametr bez informacji, której maszyny i której procedury dotyczy, jest bezużyteczny.
• Dobry podział idzie za strukturą dokumentu: sekcja, procedura, tabela jako całość. W dokumentacji technicznej warto zachować nagłówki i przynależność fragmentu do konkretnej maszyny czy wersji.

Zasada praktyczna: dziel po sensie, nie po sztywnej liczbie znaków. Fragment powinien być samowystarczalną odpowiedzią na jedno pytanie.

Retrieval: jak system znajduje właściwy fragment

Wyszukiwanie w RAG opiera się zwykle na embeddingach, czyli zamianie tekstu na reprezentację, która pozwala szukać po znaczeniu, a nie tylko po dokładnych słowach. Dzięki temu pytanie „jak zresetować blokadę" znajdzie fragment mówiący o „kasowaniu alarmu", nawet bez wspólnych słów.

To działa dobrze, ale ma granice. Skróty, oznaczenia katalogowe i żargon zakładowy bywają trudne, bo wyglądają podobnie do siebie. Dlatego często łączy się dwa podejścia: wyszukiwanie po znaczeniu i klasyczne po słowach kluczowych. To pierwsze łapie parafrazy, drugie łapie dokładne symbole i numery części.

Reranking: kiedy pomaga, a kiedy tylko kosztuje

Reranking to dodatkowy krok, w którym osobny model przegląda znalezione fragmenty i układa je od najtrafniejszego. Potrafi zauważalnie poprawić jakość, ale nie zawsze jest wart swojej ceny.

• Pomaga, gdy baza jest duża i zaszumiona, a pierwsze wyszukiwanie zwraca dużo „prawie trafnych" fragmentów. Reranking oddziela ziarno od plew.
• Bywa zbędny, gdy baza jest mała i dobrze pocięta, a wyszukiwanie i tak zwraca właściwy fragment na górze. Wtedy dokłada tylko opóźnienie i koszt.

Wniosek: nie dokładajcie rerankingu z zasady. Dodajcie go, gdy testy pokażą, że pierwsze wyszukiwanie gubi trafne fragmenty w szumie.

Projektowanie odpowiedzi „nie wiem"

To najbardziej niedoceniany element jakości. System, który potrafi powiedzieć „nie znalazłem podstawy w dokumentacji", jest w pracy technicznej cenniejszy niż taki, który zawsze coś odpowie. Puste pole to informacja: albo brakuje dokumentu, albo pytanie jest źle zadane. Odpowiedź pewna i błędna to koszt, bo ktoś może na jej podstawie działać. Wymuszenie cytowania źródła i dopuszczenie „nie wiem" to dwie decyzje, które najbardziej ograniczają halucynacje.

Jak zmierzyć jakość, zanim zaufacie

Nie zaufacie systemowi na czuja. Prosty, tani sposób na ewaluację:

1. Zbierzcie zestaw realnych pytań, na które znacie prawidłowe odpowiedzi i wiecie, w którym dokumencie są.
2. Sprawdźcie dwie rzeczy osobno: czy system znalazł właściwy fragment (trafność wyszukiwania) i czy odpowiedź jest poprawna (trafność odpowiedzi).
3. Zapisujcie przypadki, w których się pomylił, i patrzcie, na którym etapie: nie znalazł fragmentu, czy znalazł, ale źle odpowiedział.

To rozdzielenie jest kluczowe, bo naprawia się co innego. Zły retrieval poprawia się chunkingiem, lepszym wyszukiwaniem albo rerankingiem. Zła odpowiedź przy dobrym fragmencie to kwestia modelu i sposobu formułowania odpowiedzi.

Najczęstsze błędy

• Wrzucenie surowych skanów bez OCR. System nie widzi treści, więc nie znajdzie odpowiedzi.
• Brak oznaczania wersji. System miesza starą i nową procedurę.
• Chunking po sztywnej liczbie znaków. Fragmenty tną zdania i tabele w połowie.
• Brak procesu „nie wiem". System zawsze coś odpowiada, więc nie da się mu ufać.
• Brak ewaluacji. Nikt nie wie, jak dobrze to działa, więc jakość cicho się degraduje.

Czego ten post nie pokrywa

Nie wchodzę tu w dobór konkretnego modelu embeddingów ani w architekturę infrastruktury. Nie omawiam też, skąd brać wiedzę i jak ją utrzymywać w czasie, bo to osobny temat o zarządzaniu wiedzą serwisową. Tu chodziło o jedno: dlaczego RAG się myli i które decyzje projektowe najbardziej ograniczają halucynacje.

Powiązane notatki

• RAG do dokumentacji technicznej: jak AI korzysta z DTR i instrukcji maszyn
• AI do zarządzania wiedzą serwisową: jak zasilić system i gdzie są granice