RAG w firmie: dlaczego dostęp do dokumentów nie gwarantuje dobrej odpowiedzi

Serwisant pyta asystenta, co sprawdzić po wymianie modułu. Otrzymuje płynną odpowiedź, trzy kroki i odnośnik do prawdziwej instrukcji. Problem w tym, że instrukcja dotyczy rewizji A, a na stole leży rewizja B. W innym podejściu asystent wybiera właściwą instrukcję, ale pomija biuletyn zmieniający jeden z kroków. W obu przypadkach odpowiedź może brzmieć przekonująco i zawierać poprawny cytat.

Takich błędów nie wyjaśnia samo stwierdzenie, że model „halucynuje”. Trzeba ustalić, czy system rozpoznał zakres pytania, miał dostęp do właściwego źródła, odnalazł je, zachował ważny wyjątek i poprawnie wykorzystał dowody. Dopiero wtedy wiadomo, czy poprawiać dokumentację, indeks, uprawnienia, przygotowanie kontekstu czy generowanie odpowiedzi.

Prześledzimy asystenta serwisowego na małym, fikcyjnym korpusie. Wszystkie dokumenty, identyfikatory procedur i przypadki są materiałem dydaktycznym. Nie opisują rzeczywistej naprawy ani wdrożenia BBest24. Nie uruchamiamy tutaj benchmarku modelu: konstruujemy sprawdzalny test odbiorczy, który można później zastosować do konkretnego systemu.

Co RAG dodaje, a czego nie rozstrzyga

RAG, czyli retrieval-augmented generation, łączy generowanie odpowiedzi z wyszukiwaniem zewnętrznych materiałów. Zamiast polegać wyłącznie na wiedzy zapisanej w parametrach modelu, system dostarcza fragmenty dokumentów pasujące do pytania. Praca Lewisa i współautorów opisuje takie połączenie modelu generującego i wyszukiwanej pamięci zewnętrznej. Jej wyniki badawcze nie są gwarancją jakości dowolnego asystenta z podłączonym katalogiem PDF.

Wyszukany fragment może być prawdziwy, ale nie mieć zastosowania do urządzenia użytkownika. Może być aktualny, lecz niedostępny dla jego roli. Może też zawierać zasadę ogólną bez wyjątku, który został odcięty podczas dzielenia dokumentu. Dlatego jednostką oceny jest poprawnie obsłużone zadanie w określonym kontekście, a nie podobieństwo odpowiedzi do tekstu źródłowego.

Nasze zadanie brzmi: wskazać właściwe kontrole po wymianie modułu w określonej rewizji. Poprawnym wynikiem bywa lista kroków, prośba o podanie rewizji albo odmowa z powodu braku wystarczających, dostępnych źródeł. System nie dostaje punktu za odpowiedź za wszelką cenę. Nie dostaje go również za odmowę przy każdym pytaniu, bo wtedy nie wykonuje pracy, dla której powstał.

Pięć dokumentów wystarczy, żeby ujawnić problem

Korpus obejmuje dwie rewizje produktu i pięć dokumentów. Skróty PAIR, Z, T-A oraz T-B oznaczają umowne czynności, nie instrukcje obsługi sprzętu. Kontrola Z obejmuje również warunek przerwania procedury i eskalacji po wyniku negatywnym.

Rola service może korzystać z aktualnych A1, B2 i S07 w odpowiednim zakresie. Nie ma dostępu do INT. Rola internal ma także dostęp do tej notatki. B1 pozostaje w korpusie jako przykład dokumentu historycznego, lecz nie może służyć jako obowiązująca instrukcja dla pytania o bieżącą procedurę.

Właściwa odpowiedź dla rewizji B musi połączyć B2 i S07: zarejestrować moduł, wykonać Z, a dopiero po jego poprawnym wyniku przejść do T-B. Sam B2 nie wystarczy. Data w nazwie pliku nie zastępuje relacji „uzupełnia” lub „zastępuje”. Nowszy plik może dotyczyć innego urządzenia, a starsza instrukcja może nadal obowiązywać dla rewizji A.

Tabela określa minimalny korpus potrzebny do prześledzenia decyzji o zakresie, wersji i uprawnieniach. Nie jest to komplet dokumentacji serwisowej.

Oczekiwana odpowiedź powstaje przed oceną systemu

Dla pytania „Jakie kontrole po wymianie modułu w rewizji B?” karta przypadku powinna określać więcej niż przykładowy akapit. Zapisujemy rolę użytkownika, rewizję, wymagane źródła B2 i S07, trzy jednostki znaczenia PAIR, Z i T-B oraz wymaganą kolejność. Osobno zaznaczamy krytyczny warunek: po nieudanym Z nie wolno zalecić kontynuacji.

Dla pytania bez rewizji oczekujemy doprecyzowania. Asystent powinien wyjaśnić, że procedura zależy od wersji urządzenia, i poprosić o informację pozwalającą ją ustalić. Nie powinien sklejać kroków z A1 i B2 w jedną „uniwersalną” procedurę. Brakujące rozróżnienie jest częścią zadania, nie niedogodnością do zamaskowania.

Dla rewizji C, której korpus nie obejmuje, oczekujemy informacji o braku podstaw do wskazania procedury i skierowania do właściwego źródła wsparcia. Dla notatki INT pytanej przez rolę service oczekujemy braku ujawnienia jej treści. Wrażliwy może być również sam tytuł lub fakt istnienia dokumentu, więc komunikat odmowy powinien respektować przyjętą politykę ujawniania metadanych.

W rzeczywistym projekcie oczekiwania musi zatwierdzić osoba odpowiedzialna za procedurę i jej obowiązywanie. W tym artykule reguły są definicją fikcyjnego przykładu, a nie wynikiem takiej akceptacji domenowej. To ważna granica: automatycznie wygenerowana odpowiedź wzorcowa nie staje się prawdą tylko dlatego, że posłużyła do oceny drugiego modelu.

Mierzmy kolejne miejsca utraty informacji

Potok dzielimy na cztery widoczne etapy, ale oceniamy pięć aspektów: zakres, dostęp, wyszukiwanie, odpowiedź i cytowania. Dzięki temu poprawna odpowiedź uzyskana po naruszeniu uprawnień nie przechodzi testu, a trafne wyszukiwanie nie ukrywa późniejszego pominięcia warunku.

Najpierw system ustala, czego dotyczy pytanie. Rewizja może pochodzić z jawnego wskazania użytkownika albo z uprawnionego odczytu identyfikatora urządzenia. Nie powinna wynikać z tego, który dokument akurat osiągnął najwyższy wynik podobieństwa. Jeśli informacje są sprzeczne, trzeba rozwiązać konflikt, zanim powstanie instrukcja.

Następnie uprawnienia ograniczają kontekst, który może trafić do modelu. Kontrola tylko przy importowaniu dokumentów nie wystarczy, ponieważ role użytkowników zmieniają się później. OWASP w materiale o bezpieczeństwie RAG opisuje dziedziczenie uprawnień przez fragmenty i kontrolę przy wyszukiwaniu. W naszym przykładzie INT nie może pojawić się w kontekście roli service, nawet jeśli końcowa odpowiedź przypadkiem go nie zacytuje.

Dopiero w dozwolonym zakresie oceniamy, czy odnaleziono materiały potrzebne do zadania. Dla B muszą być obecne B2 i S07. Potem sprawdzamy treść odpowiedzi i to, czy odnośniki wspierają przypisane im twierdzenia. Każdy etap ma własny wynik, identyfikatory użytych dokumentów i możliwość przypisania błędu.

Trafność wyszukiwania nie jest kompletnością odpowiedzi

Jeżeli potrzebujemy dwóch dokumentów, a znaleziono tylko B2, pokrycie wymaganych źródeł wynosi w tej prostej definicji 1 / 2 = 50%. Jeśli jedynym zwróconym dokumentem jest B2, precyzja zbioru względem wymaganych dokumentów wynosi 1 / 1 = 100%. Obie wartości są prawdziwe. Wynik nadal nie wystarcza do udzielenia kompletnej odpowiedzi.

Te miary wymagają zdefiniowania jednostki. Możemy liczyć dokumenty, fragmenty albo konkretne informacje. Trzy fragmenty tej samej strony nie są trzema niezależnymi dowodami na obecność biuletynu. W praktycznym teście zapisujemy wymagane identyfikatory i miejsca w dokumentach, a nie tylko oczekiwane słowa kluczowe.

Podobna pułapka występuje po generowaniu. Odpowiedź „zarejestruj moduł i wykonaj T-B” zawiera dwa twierdzenia wspierane przez B2. Może więc osiągnąć pełne poparcie dla tego, co powiedziała. Jednocześnie pomija Z i jego warunek zatrzymania. Przy trzech jednostkach wymaganej treści pokrywa jedynie 2 / 3, około 66,7%. W zadaniu serwisowym to istotny błąd, którego dobra ocena zgodności z kontekstem nie powinna zamaskować.

Praca RAGAs z EACL 2024 proponuje oddzielne wymiary oceny kontekstu i generowania. Takie narzędzia pomagają wykrywać regresje, ale ich wynik trzeba powiązać z decyzją użytkownika. Nazwa metryki nie zastępuje definicji mianownika, sposobu oceny i kryterium, przy którym procedura jest akceptowalna.

Mapa dziesięciu celowo różnych przypadków

Przygotowaliśmy dziesięć ręcznie skonstruowanych obserwacji. Dwa przypadki odpowiadają oczekiwaniom, a osiem celowo pokazuje błędy. Nie jest to próbka działania modelu, dlatego nie wolno wyliczać z niej terenowego odsetka błędów ani porównywać dostawców AI. Służy do sprawdzenia, czy metoda oceny rozpoznaje różne sposoby niepowodzenia.

Mapa oznacza pierwszy etap niespełniający karty. Dalszych etapów nie oceniamy w tej ilustracji. Dzięki temu błąd uprawnień nie zostaje rozmyty przez późniejsze punkty za ładny tekst. W pełnym audycie można zapisywać wszystkie współwystępujące problemy, zachowując jednak pierwotną przyczynę i niezależne blokady odbioru.

Mapa powstaje przez porównanie umówionych etykiet i list dowodów z tabeli. Taka kontrola nie czyta swobodnego języka jak ekspert i nie udowadnia, że dowolna parafraza jest semantycznie poprawna. To ilustracja zasad oceniania, nie gotowy sędzia dla produkcyjnego RAG.

Dzielenie dokumentów jest decyzją merytoryczną

Typowy błąd indeksowania zaczyna się od mechanicznego podziału tekstu na fragmenty o podobnej długości. Nagłówek „tylko rewizja B” zostaje w poprzednim fragmencie, tabela traci nagłówki kolumn, a wyjątek trafia na następną stronę. Wyszukiwarka odnajduje zdanie o T-B, lecz model nie dostaje warunku jego zastosowania.

Dla naszego korpusu fragment powinien zachować identyfikator dokumentu, rewizję, status, rolę dostępu i relację do innych dokumentów. S07 musi dać się powiązać z B2 także wtedy, gdy pytanie nie zawiera słowa „biuletyn”. Nie oznacza to obowiązku przekazywania całej dokumentacji przy każdym zapytaniu. Oznacza kontrolowane rozszerzanie kontekstu o zależności potrzebne do rozstrzygnięcia zadania.

Zmianę sposobu dzielenia dokumentów warto testować na tych samych pytaniach, z niezmienioną resztą konfiguracji. Obserwujemy, czy do kontekstu wrócił brakujący warunek, ile dodano niepotrzebnych treści i czy zmienił się czas odpowiedzi. Większy kontekst może pomóc, ale może też zwiększyć koszt i liczbę konkurujących instrukcji. Sama liczba znaków nie jest miarą kompletności wiedzy.

Wersjonować należy również wynik ekstrakcji. Nowy parser PDF może inaczej ułożyć tabelę, choć plik wejściowy pozostał identyczny. Do odtworzenia regresji potrzebujemy wersji dokumentu, ekstraktora, reguł dzielenia, indeksu i konfiguracji wyszukiwania. Zapisanie wyłącznie nazwy modelu pozostawia dużą część przyczyn niewidoczną.

Aktualizacja źródła to transakcja wiedzy

Załóżmy, że S07 zostaje zatwierdzony, ale indeks nadal zawiera tylko B2. System nie musi wygenerować żadnej fałszywej informacji, aby odpowiedzieć nieaktualnie. Może wiernie streścić dostępny kontekst. Odpowiedzialność za aktualność nie leży wtedy wyłącznie w promptach modelu.

Proces publikowania dokumentu powinien określać, kiedy nowa wersja staje się dostępna do odpowiedzi, jak oznaczane są zastąpione fragmenty i co dzieje się z pamięcią podręczną. W krytycznej zmianie lepsze może być chwilowe ograniczenie odpowiedzi niż mieszanie nowego statusu dokumentu ze starym indeksem. Warto mieć identyfikator spójnego wydania korpusu, aby wiadomo było, na jakim zestawie wiedzy powstała odpowiedź.

Podobnie działa odebranie uprawnień. Wynik wcześniejszego zapytania nie powinien trafić do osoby, która utraciła dostęp, tylko dlatego, że tekst jest w cache. Klucz pamięci podręcznej i ponowna autoryzacja muszą uwzględniać zakres dostępu. Test Q09 celowo sprawdza tę drogę, ponieważ poprawne filtrowanie wyszukiwarki nie zabezpiecza automatycznie innych miejsc przechowywania odpowiedzi.

Jeśli dwa zatwierdzone dokumenty wydają sprzeczne zalecenia, sam ranking wyszukiwarki nie rozstrzyga ich ważności. Potrzebna jest formalna relacja pierwszeństwa albo decyzja właściciela dokumentacji. W dodatkowym teście warto podać dwa aktualne biuletyny bez informacji, który zastępuje drugi. Oczekiwaniem jest wskazanie konfliktu i eskalacja, nie arbitralny wybór nowszej daty. Taki przypadek nie wchodzi do dziesięciu obserwacji na mapie; pokazuje, jak rozszerzać zbiór po wykryciu kolejnej klasy ryzyka. Naprawa może polegać na uporządkowaniu dokumentacji, a nie na zmianie modelu.

Cytowanie to relacja między twierdzeniem a dowodem

Klikalny odnośnik ma wartość tylko wtedy, gdy czytelnik może zweryfikować konkretne twierdzenie. Cytat z A1 nie wspiera procedury dla B, nawet jeśli oba dokumenty używają słowa „moduł”. Sam tytuł dokumentu również nie pokazuje, czy uwzględniono wyjątek. W odpowiedzi warto wiązać kroki z właściwym fragmentem i wersją źródła.

Ocena cytowań powinna rozdzielać poprawność adresu, dostęp użytkownika do celu, zgodność zakresu oraz rzeczywiste poparcie treści. Część kontroli jest deterministyczna: identyfikator istnieje, należy do dozwolonego korpusu i nie został wycofany. Inna część wymaga interpretacji, na przykład czy zdanie o obowiązku wykonania Z wynika z przywołanego akapitu i czy nie pominięto warunku.

Nie należy dopisywać źródeł dopiero po wygenerowaniu odpowiedzi na podstawie podobieństwa słów. Taka procedura może ozdobić nieuzasadnione twierdzenie prawdziwym dokumentem. Lepiej przechować związek z dowodami użytymi w kontekście i osobno sprawdzić, czy wygenerowane zdania rzeczywiście mają w nich oparcie.

Źródło nie dostaje prawa wydawania poleceń

Dokument może zawierać zdanie nakazujące modelowi pominięcie kontroli, ujawnienie innej notatki albo zignorowanie reguł odpowiedzi. W naszym Q10 jest to umowne polecenie pominięcia Z. Nie jest częścią zatwierdzonej procedury tylko dlatego, że znajduje się w wyszukanym fragmencie.

OWASP LLM01:2025 opisuje pośrednie wstrzyknięcia instrukcji przez zewnętrzne treści i podkreśla, że samo RAG nie usuwa tego ryzyka. Rozdzielenie instrukcji aplikacji od danych źródłowych pomaga, ale nie stanowi matematycznej gwarancji. Uprawnienia oraz dostęp do narzędzi muszą być egzekwowane poza swobodną decyzją modelu.

W tym przykładzie asystent wyłącznie informuje. Jeśli miałby uruchamiać działania serwisowe, ocena odpowiedzi nie wystarczyłaby do autoryzacji operacji. Potrzebne byłyby odrębne reguły wykonania, potwierdzenia i obserwacji skutku. Nie należy rozszerzać zakresu pilotażu z wyszukiwania wiedzy na sterowanie urządzeniem tylko dlatego, że pierwsza demonstracja wygląda przekonująco.

Jak używać automatycznego sędziego bez oddawania mu odbioru

Model oceniający odpowiedź może przyspieszyć przegląd dużej liczby przypadków, ale powinien otrzymać jasną rubrykę. „Czy odpowiedź jest dobra?” to zbyt szerokie pytanie. Lepsze są osobne oceny: właściwa rewizja, obecność wymaganych kontroli, brak sprzecznych zaleceń, poprawne uzasadnienie odmowy oraz poparcie poszczególnych twierdzeń.

Najpierw porównujemy oceny automatyczne z oceną ekspertów na reprezentatywnej części zbioru. Szczególnie interesują nas przypadki, w których sędzia akceptuje odpowiedź z pominiętym wyjątkiem albo odrzuca poprawną, krótką odmowę. Spory powinny prowadzić do doprecyzowania kryteriów, nie do automatycznego przyznania racji systemowi, który wypowiedział się bardziej szczegółowo.

Zbiór do strojenia i zbiór odbiorczy trzeba rozdzielić. Jeżeli po każdym błędzie dopisujemy do promptu odpowiedź na konkretny test, poprawa może oznaczać dopasowanie do znanych przykładów. Warto zachować nowe pytania z tych samych klas problemu, zmienione sformułowania i przypadki po zmianie dokumentacji. Wyniki raportujemy także według kategorii, ponieważ wysoka średnia może ukryć systematyczny problem jednej rewizji.

Warunki, pod którymi asystent może wejść do pilotażu

Karta odbioru powinna wskazywać korpus i jego wersję, konfigurację modelu i wyszukiwania, zestaw przypadków oraz właściciela oczekiwanych odpowiedzi. Każde naruszenie dostępu i użycie wycofanej procedury traktujemy w tym przykładzie jako blokadę, a nie punkt odjęty od średniej. Brak takich błędów w skończonym zestawie testów nie dowodzi ich niemożliwości poza nim.

Oprócz poprawności mierzymy udział pytań, na które system potrafi odpowiedzieć, zasadność odmów, czas do użytecznej odpowiedzi i koszt obsługi. Rejestrujemy także awarie wyszukiwarki oraz przekroczenia czasu. Awaria usługi nie powinna wyglądać dla użytkownika jak merytoryczny brak dokumentacji. Bez tego wzrost odmów może błędnie zostać uznany za większą ostrożność modelu.

Praktyczny przegląd kończy się trzema pytaniami do każdego nieudanego przypadku: jakiej informacji zabrakło, na którym etapie ją utracono i jaki test potwierdzi poprawkę? Dla Q02 trzeba odnaleźć S07; dla Q06 właściwie wykorzystać już obecny biuletyn; dla Q04 zatrzymać chroniony kontekst przed modelem. Wymiana modelu może pomóc w jednym z tych miejsc, lecz nie zastąpi rozpoznania przyczyny.

Źródła

• Lewis i współautorzy: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020, wersja arXiv v4 z 12 kwietnia 2021 r.; architektura łącząca wyszukiwanie z generowaniem.
• Es i współautorzy: RAGAs: Automated Evaluation of Retrieval Augmented Generation, EACL 2024, Demonstrations, s. 150-158; rozdzielenie wymiarów oceny kontekstu i odpowiedzi. Cytujemy publikację, nie bieżący interfejs biblioteki.
• OWASP: RAG Security Cheat Sheet, kontrola dostępu w potoku wiedzy i testy dróg ujawnienia danych.
• OWASP LLM01:2025: Prompt Injection, pośrednie instrukcje w źródłach i ograniczenia zabezpieczenia przez samo RAG.

Źródła sprawdzono 21 października 2026 r. Dokumenty A1, B1, B2, S07 i INT oraz obserwacje Q01-Q10 są fikcyjne. Nie użyto odpowiedzi rzeczywistego modelu do przedstawienia rzekomych wyników jakości; testy odtwarzają reguły i oznaczenia przykładu.