Szybka odpowiedź
Baza wiedzy, która nie zmyśla, potrzebuje trzech bezpieczników. Po pierwsze, model pisze tylko z dostarczonych fragmentów i przy każdym zdaniu wskazuje źródło, a przypis prowadzi do konkretnego zdania w dokumencie, nie do sąsiedniego akapitu. Po drugie, wyszukiwanie ma próg trafności: gdy po rerankingu żaden fragment go nie przekracza, system odpowiada „nie wiem”, zamiast składać odpowiedź z przypadkowych trafień. Po trzecie, filtr uprawnień działa w samym indeksie, więc model nie widzi dokumentów, do których pytający nie ma dostępu. Próg trzeba skalibrować na własnych pytaniach, także na takich, na które w dokumentach nie ma odpowiedzi.
Dlaczego RAG zmyśla, mimo że ma dokumenty?
RAG (Retrieval-Augmented Generation) to technika, w której model przed odpowiedzią wyszukuje fragmenty w bazie dokumentów i odpowiada na ich podstawie. Jak działa w podstawowej wersji, opisujemy w artykule jak RAG czyni AI mądrzejszym. Tu zajmujemy się tym, co dzieje się, gdy wyszukiwanie przyniesie za mało albo nie to, co trzeba.
Dokumenty w kontekście nie wystarczą, żeby model mówił prawdę. Pokazują to badania:
- Cytaty, które nie popierają tezy. Zespół ze Stanfordu sprawdził odpowiedzi popularnych wyszukiwarek generatywnych. Tylko 51,5% wygenerowanych zdań było w pełni popartych cytatami, a 74,5% cytatów popierało zdanie, przy którym stało (Liu, Zhang, Liang, 2023). Co czwarty przypis wyglądał wiarygodnie, ale nie potwierdzał tego, co obok niego napisano.
- Brak pełnego pokrycia nawet u najlepszych. W benchmarku ALCE najlepsze modele na zbiorze ELI5 w połowie przypadków nie miały pełnego poparcia w cytatach (Gao i in., 2023).
- Odpowiadanie zamiast odmowy. Badacze Google pokazali, że duże modele dobrze odpowiadają, gdy kontekst wystarcza, ale gdy nie wystarcza, często podają błędną odpowiedź zamiast się wstrzymać (Joren i in., 2024).
- Specjalistyczne narzędzia też się mylą. Komercyjne narzędzia do researchu prawniczego oparte na RAG halucynowały w od 17 do 33% przypadków, mniej niż ogólny GPT-4, ale wyraźnie więcej niż zero (Magesh i in., 2025).
Wniosek jest prosty: sam fakt, że model ma dokumenty, nie wystarczy. Potrzebne są mechanizmy, które wymuszą pisanie ze źródeł, pozwolą to sprawdzić i dadzą systemowi prawo do odmowy.
Pierwszy bezpiecznik: przypis przy każdym zdaniu
W naszej bazie wiedzy model pisze tylko z fragmentów, które dostał w kontekście, i przy każdym zdaniu wskazuje źródło. Klik w cytat otwiera dokument i podświetla zdanie, z którego pochodzi. Tak wygląda to w opowieści na stronie Bazy wiedzy, gdzie przykładem jest fikcyjna kancelaria.
Dlaczego przypis przy zdaniu, a nie lista źródeł pod odpowiedzią?
- Da się go sprawdzić. Lista „źródła: umowa.pdf, regulamin.pdf” nie mówi, które zdanie skąd pochodzi. Przypis przy zdaniu pozwala zweryfikować każdą tezę osobno, w kilka sekund.
- Wymusza dyscyplinę modelu. Gdy model musi przypiąć każde zdanie do fragmentu, trudniej mu dopisać zdanie „od siebie”. Zdanie bez przypisu od razu rzuca się w oczy.
- Wskazuje miejsce, nie plik. Przypis prowadzi do konkretnego zdania w dokumencie. To wymaga, żeby przy przetwarzaniu dokumentu zachować pozycję każdego fragmentu (strona, paragraf, przesunięcie w tekście), a nie tylko jego treść.
Przypis to dopiero deklaracja modelu. Że cytowany fragment rzeczywiście popiera zdanie, trzeba sprawdzić osobno. Ten krok nazywa się kontrolą ugruntowania (ang. groundedness lub attribution). W literaturze robi się to na dwa sposoby: modelem wnioskowania (NLI), który ocenia, czy fragment implikuje zdanie, albo drugim przebiegiem modelu językowego w roli sędziego (Rashkin i in., 2021; metryka faithfulness w RAGAS). Zdanie, które nie przejdzie kontroli, można usunąć, oznaczyć albo wysłać odpowiedź do ponownego wygenerowania.
U nas ten krok nie jest jednym filtrem, tylko zestawem bramek. Bramka precyzji sprawdza, czy zdanie ma pokrycie w cytowanym fragmencie, a bramka halucynacji wyłapuje twierdzenia, których nie ma w żadnym źródle. Zdanie, które nie przejdzie bramek, nie trafia do odpowiedzi jako fakt. Nad całością zawsze stoi człowiek (human in the loop): odpowiedzi w sprawach wrażliwych zatwierdza osoba z zespołu klienta. Zbieramy też trajektorie, czyli zapis tego, co system wyszukał, co odrzucił i co odpowiedział. Grupujemy je w zbiory danych i oceniamy na dwa sposoby: modelem w roli sędziego (LLM as a judge) i ręcznie. Dzięki temu progi bramek ustawiamy na podstawie ocenionych przypadków, a nie na wyczucie.
Drugi bezpiecznik: próg trafności i odpowiedź „nie wiem”
Wyszukiwanie zawsze coś zwraca. Nawet gdy w bazie nie ma odpowiedzi, wyszukiwarka wektorowa poda pięć „najbliższych” fragmentów, bo najbliższe są zawsze. Jeśli model dostanie je bez ostrzeżenia, zrobi to, co robią modele: ułoży z nich wiarygodnie brzmiącą odpowiedź.
Dlatego w naszym łańcuchu wyszukiwanie wygląda tak: pytanie jest klasyfikowane, równolegle przeszukujemy wektory i pełny tekst, łączymy obie listy, a model rerankingowy czyta każdą parę pytanie i fragment i ustala ostateczną kolejność. Gdy nic nie przekracza progu, odpowiedź brzmi „nie wiem”.
Dlaczego próg na rerankerze, a nie na podobieństwie wektorów?
| Sygnał | Co mierzy | Czy nadaje się na próg |
|---|---|---|
| Podobieństwo wektorów (cosinus) | Jak blisko leżą pytanie i fragment w przestrzeni znaczeń, liczone osobno dla każdego tekstu | Słabo. Wartości zależą od modelu i długości tekstu, a temat podobny to nie to samo co odpowiedź |
| Wynik BM25 | Pokrycie słów kluczowych | Nie. Skala zależy od zapytania i korpusu |
| Pozycja po fuzji list (RRF) | Kolejność, nie siła dopasowania | Nie. RRF celowo patrzy tylko na pozycje (Cormack i in., 2009) |
| Wynik rerankera (cross-encoder) | Czy ten fragment odpowiada na to pytanie, oceniane na parze czytanej razem | Tak, po kalibracji na własnych danych |
Reranker czyta pytanie i fragment razem, więc ocenia, czy fragment odpowiada, a nie tylko, czy jest „o tym samym”. Popularne rerankery dają wynik, który da się sprowadzić do przedziału 0 do 1. Na przykład BGE-reranker-v2-m3 przepuszcza wynik przez sigmoidę (karta modelu), a Qwen3-Reranker liczy prawdopodobieństwo odpowiedzi „yes” (karta modelu). To nadal nie jest skalibrowane prawdopodobieństwo poprawnej odpowiedzi, ale to dobry sygnał do progu.
Jak dobrać próg
Próg dobiera się na danych, nie na wyczucie:
- Zbierz pytania z odpowiedzią w dokumentach, każde z oczekiwanym źródłem.
- Zbierz pytania bez odpowiedzi w dokumentach: podobne tematycznie, ale takie, na które baza nie zna odpowiedzi. Bez nich nie zmierzysz, czy system umie odmówić.
- Przepuść oba zestawy przez wyszukiwanie i zapisz najwyższy wynik rerankera dla każdego pytania.
- Wybierz próg tak, żeby pogodzić dwa błędy: fałszywe „nie wiem” na pytaniach z odpowiedzią i odpowiedzi bez pokrycia na pytaniach bez odpowiedzi.
| Próg | Co się dzieje | Objaw u użytkowników |
|---|---|---|
| Za wysoki | System odmawia, mimo że odpowiedź jest w dokumentach | „Ta baza nic nie wie”, użytkownicy wracają do szukania ręcznie |
| Za niski | System odpowiada z fragmentów, które tylko przypominają temat | Pewne siebie, błędne odpowiedzi z przypisami, które nie pasują |
| Dobrany na zestawie testowym | Odmowa tam, gdzie brak źródła, odpowiedź tam, gdzie źródło jest | „Nie wiem” jest rzadkie i zwykle uzasadnione |
Wysoki odsetek fałszywych „nie wiem” to rzadko problem progu. Zwykle to sygnał, że zawodzi coś wcześniej: OCR, podział na fragmenty albo wyszukiwanie pełnotekstowe bez polskiej odmiany. O przetwarzaniu dokumentów piszemy w artykule o nowoczesnym OCR.
Jak powinno wyglądać dobre „nie wiem”
Samo „nie wiem” bywa frustrujące. Dobra odmowa mówi więcej:
- że w dostępnych dokumentach nie znaleziono fragmentu, który odpowiada na pytanie;
- jakie dokumenty były najbliżej, jeśli użytkownik chce sprawdzić sam;
- jak przeformułować pytanie albo do kogo się zwrócić.
Odmowa nie powinna przy tym zdradzać, że odpowiedź istnieje w dokumentach, do których pytający nie ma dostępu. To prowadzi do trzeciego bezpiecznika.
Trzeci bezpiecznik: filtr działów w samym indeksie
Każdy fragment w naszej bazie ma w metryczce dział, do którego należy. Filtr działa w samym indeksie, zanim cokolwiek zostanie wyszukane, więc akta innego działu nie trafią ani do rankingu, ani do kontekstu modelu. Każde pytanie zostaje w dzienniku audytu: kto pytał, kiedy i na jakich źródłach oparto odpowiedź.
Dlaczego filtr przed wyszukiwaniem, a nie po?
- Model nie widzi tego, czego nie powinien. Jeśli filtrujemy dopiero wyniki, dokument zastrzeżony mógł już wpłynąć na ranking albo trafić do kontekstu. Model może coś z niego „przemycić” w odpowiedzi.
- Próg działa uczciwie. Gdy jedyny pasujący fragment należy do innego działu, pytający dostaje „nie wiem”, tak samo jak przy braku dokumentu. Nie dowiaduje się, że odpowiedź gdzieś istnieje.
- Audyt ma sens. Dziennik pokazuje, na jakich źródłach oparto odpowiedź, a te źródła na pewno były dostępne dla pytającego.
Szerzej o uprawnieniach w RAG piszemy w artykule o bezpiecznym dostępie RAG do danych.
Co każdy mechanizm załatwia, a czego nie
| Mechanizm | Przed czym chroni | Czego nie załatwi |
|---|---|---|
| Model pisze tylko z fragmentów | Odpowiedzi z wiedzy ogólnej modelu, często nieaktualnej | Złego doboru fragmentów |
| Przypis przy każdym zdaniu | Tezom, których nie da się sprawdzić | Przypisom, które wskazują niepasujący tekst |
| Kontrola ugruntowania | Przypisom, które nie popierają zdania | Błędom w samych dokumentach źródłowych |
| Próg trafności i „nie wiem” | Odpowiedziom składanym z przypadkowych fragmentów | Słabemu wyszukiwaniu (wtedy rośnie liczba fałszywych odmów) |
| Filtr działów w indeksie | Wyciekom między działami przez ranking i kontekst | Złym uprawnieniom nadanym w źródłowym systemie |
| Dziennik audytu | Braku śladu, kto o co pytał i skąd wzięła się odpowiedź | Niczemu sam z siebie, jeśli nikt go nie czyta |
Żaden z tych mechanizmów nie jest wystarczający osobno. Razem sprawiają, że odpowiedź albo ma sprawdzalne źródło, albo jej nie ma.
Lista kontrolna: baza wiedzy, która nie zmyśla
- Prompt każe modelowi pisać wyłącznie z dostarczonych fragmentów i odmawiać, gdy ich brakuje.
- Każde zdanie odpowiedzi ma przypis do konkretnego fragmentu.
- Przypis otwiera dokument w miejscu, z którego pochodzi zdanie (pozycja zachowana przy przetwarzaniu).
- Po wygenerowaniu działa kontrola ugruntowania: czy fragment popiera zdanie.
- Wyszukiwanie jest hybrydowe (wektory i pełny tekst z polską odmianą), z rerankingiem.
- Próg trafności jest ustawiony na wyniku rerankera i skalibrowany na zestawie testowym.
- Zestaw testowy zawiera pytania bez odpowiedzi w dokumentach.
- Filtr uprawnień działa w indeksie, przed wyszukiwaniem.
- Odmowa nie zdradza istnienia dokumentów niedostępnych dla pytającego.
- Każde pytanie, odpowiedź i źródła trafiają do dziennika audytu.
- Po każdej zmianie modelu, progu lub przetwarzania dokumentów zestaw testowy przechodzi ponownie.
Jak to sprawdzić na własnych dokumentach
Najszybciej na próbce. Bierzemy kilkaset dokumentów z jednego działu i listę pytań, które ludzie zadają naprawdę, razem z oczekiwanym źródłem. Budujemy bazę, a wynikiem jest raport: gdzie odpowiedź trafia w źródło, gdzie system mówi „nie wiem” i dlaczego. Cały łańcuch, czyli OCR, indeksy, model embeddingów, reranker i model językowy, działa na serwerze w sieci firmy, na GPU NVIDIA Blackwell.
Jeśli pytania wymagają kilku wyszukiwań albo łączenia wielu dokumentów, kolejnym krokiem jest agentic RAG, w którym agent sam decyduje, czy znalazł dość. Zasada pozostaje ta sama: bez źródła nie ma odpowiedzi. Jak wygląda cały łańcuch od skanu do cytatu, pokazujemy na stronie Bazy wiedzy, a próbną bazę na Twoich dokumentach można zamówić przez demo.
Źródła
- Liu, Zhang, Liang: Evaluating Verifiability in Generative Search Engines (arXiv, 2023)
- Gao i in.: Enabling Large Language Models to Generate Text with Citations (EMNLP 2023)
- Joren i in.: Sufficient Context: A New Lens on Retrieval Augmented Generation Systems (arXiv, 2024)
- Magesh i in.: Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools (Journal of Empirical Legal Studies, 2025)
- Rashkin i in.: Measuring Attribution in Natural Language Generation Models (arXiv, 2021)
- Es i in.: RAGAS: Automated Evaluation of Retrieval Augmented Generation (arXiv, 2023)
- Cormack, Clarke, Büttcher: Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods (SIGIR 2009)
- BAAI: karta modelu bge-reranker-v2-m3 (Hugging Face)
- Qwen: karta modelu Qwen3-Reranker-8B (Hugging Face)
