Jak rozpoznać, kiedy RAG podaje prawdę - ale złą prawdę

RAG (Retrieval Augmented Generation) podobno rozwiązuje problem halucynacji w AI. System wyszukuje oficjalne dokumenty, cytuje źródła, nie wymyśla. Thomson Reuters twierdził w 2024, że RAG może zredukować halucynacje "prawie do zera".

Działa to jednak tylko w małych, stabilnych domenach. Gdy firma rośnie, dokumentacja przestaje być jednym zbiorem faktów - staje się zestawem wariantów. Wtedy pojawia się nowy typ błędu: odpowiedź prawdziwa, dobrze udokumentowana i kompletnie nietrafiona dla Twojej sytuacji.

Ten problem nazywa się applicability - stosowalność. Jeśli budujesz system RAG dla firmy, która ma więcej niż jeden region, produkt lub wersję regulaminu - musisz go rozwiązać.

Dlaczego RAG przestaje działać, gdy firma rośnie

Masz firmę sprzedającą sprzęt AGD z programem gwarancyjnym. Klient pyta chatbota:

"Mój toster nie działa - mogę go wymienić?"

W małej firmie z jednym regulaminem RAG działa świetnie. System wyszukuje fragment o wymianie tosterów, model go streszcza, klient dostaje odpowiedź. Koniec.

Teraz firma ma:

• Trzy plany gwarancyjne (podstawowy, rozszerzony, premium)
• Różne zasady dla klientów biznesowych i indywidualnych
• Regionalne warianty polityki (UE vs USA vs Azja)
• Wersje produktów z różnymi okresami gwarancji
• Zmiany regulaminu obowiązujące od konkretnych dat

Każdy dokument jest "prawdziwy". Tylko jeden ma zastosowanie do tego konkretnego klienta, w tym momencie, z tym planem.

Co się dzieje, gdy RAG nie rozróżnia kontekstu

System wyszukuje fragment o wymianie tosterów. Znajduje dokument - oficjalny, aktualny, dobrze napisany. Model cytuje źródło i odpowiada: "Tak, wymiana jest możliwa w ciągu 30 dni".

Ten dokument dotyczy planu premium. Klient ma plan podstawowy, gdzie wymiana jest możliwa tylko w ciągu 14 dni. Odpowiedź jest prawdziwa - dla kogoś innego.

To nie jest halucynacja. To coś gorszego: autorytatywna nieprawda. System nie wymyślił. Zacytował oficjalne źródło. Klient uwierzył. Firma ma problem.

Czym jest problem stosowalności w praktyce

Problem stosowalności (applicability problem) pojawia się, gdy:

1. Masz wiele wersji tej samej polityki (regionalne, czasowe, produktowe)
2. Każda wersja jest "prawdziwa" w swoim kontekście
3. System RAG nie wie, który kontekst dotyczy aktualnego zapytania

W małych firmach to marginalny problem. W dużych organizacjach - dominujący tryb awarii.

Przykłady z życia wziętych

Finanse: Bank ma różne zasady kredytowania dla klientów w różnych stanach USA. System RAG wyszukuje dokument o kredytach hipotecznych - dla stanu, w którym klient nie mieszka. Odpowiedź prawdziwa, źródło oficjalne, decyzja kredytowa błędna.

HR: Firma ma politykę urlopową zależną od kraju zatrudnienia i stażu pracy. System odpowiada na podstawie dokumentu dla pracowników z 5+ lat stażu. Pytający ma 2 lata. Konflikt.

E-commerce: Sklep ma różne zasady zwrotów dla produktów elektronicznych i odzieży. Klient pyta o zwrot laptopa - dostaje odpowiedź o zwrotach ubrań (30 dni, bez pytań). Laptop ma 14 dni i wymaga nienaruszonego opakowania.

Dlaczego to trudniejsze niż zwykłe wyszukiwanie

Możesz pomyśleć: "OK, to po prostu dodaj filtry. Wyszukuj tylko dokumenty dla danego regionu/planu/produktu".

Zmienne kontekstowe są często ukryte w pytaniu. Klient nie mówi: "Jestem w planie podstawowym, region UE, produkt kupiony 15.03.2026, pytam o wymianę". Mówi: "Mój toster nie działa".

System musi:

1. Zidentyfikować, jakie zmienne są istotne (plan, region, data zakupu, typ produktu)
2. Wydobyć je z kontekstu rozmowy lub bazy klienta
3. Użyć ich jako ograniczeń wyszukiwania
4. Dopiero wtedy wyszukać właściwy dokument

To nie jest problem retrieval (wyszukiwania). To problem scope (zakresu) - ustalenia, która część dokumentacji w ogóle powinna być brana pod uwagę.

Zmienne kontekstowe, które musisz uwzględnić

Badania Pinecone wskazują na kilka wymiarów stosowalności:

• Geografia: region, kraj, stan, miasto (różne regulacje prawne)
• Czas: data zakupu, data obowiązywania polityki, wersja produktu
• Uprawnienia: plan subskrypcji, typ klienta (B2B/B2C), staż
• Produkt: kategoria, wersja, wariant
• Organizacja: dział, zespół, rola

Jeden dokument może mieć 5-10 wymiarów stosowalności. Wszystkie muszą się zgadzać, żeby odpowiedź była trafna.

Jak zbudować RAG, który rozumie kontekst

OK, problem jasny. Jak go rozwiązać? Oto konkretne kroki.

Krok 1: Oznacz dokumenty metadanymi kontekstowymi

Każdy dokument w bazie wektorowej musi mieć metadane określające, do kogo i kiedy się stosuje:

• Region: ["EU", "US", "Asia"]
• Plan: ["basic", "premium", "enterprise"]
• Typ klienta: ["individual", "business"]
• Obowiązuje od: "2026-01-15"
• Obowiązuje do: "2026-12-31" (lub null jeśli aktualny)
• Kategoria produktu: ["appliances", "electronics"]

To nie jest opcjonalne. Bez metadanych nie masz jak filtrować.

Krok 2: Wydobądź zmienne kontekstowe z zapytania

Użyj LLM do ekstrakcji zmiennych z pytania klienta i historii rozmowy. Przykładowy prompt:

"Na podstawie pytania klienta i dostępnych danych, wydobądź: region, plan subskrypcji, typ klienta, kategorię produktu. Jeśli informacja nie jest dostępna, zwróć null dla tej zmiennej."

Jeśli zmiennych brakuje - zapytaj klienta. "Żeby odpowiedzieć precyzyjnie - jaki plan gwarancyjny masz wykupiony?"

Krok 3: Użyj zmiennych jako filtrów wyszukiwania

Większość baz wektorowych (Pinecone, Weaviate, Qdrant) pozwala na filtrowanie metadanych przed wyszukiwaniem semantycznym. Przykład w Pinecone:

query_vector = embed("Mój toster nie działa - mogę go wymienić?")
filter = {
 "region": "EU",
 "plan": "basic",
 "customer_type": "individual",
 "valid_from": {"$lte": "2026-04-15"},
 "valid_to": {"$gte": "2026-04-15"}
}
results = index.query(vector=query_vector, filter=filter, top_k=5)

Teraz wyszukujesz tylko w dokumentach, które mogą dotyczyć tego klienta.

Krok 4: Waliduj stosowalność przed odpowiedzią

Nawet po filtrowaniu - sprawdź, czy znaleziony dokument naprawdę pasuje. Dodaj krok walidacji:

"Czy ten dokument stosuje się do klienta z regionu EU, planem basic, produktem z kategorii appliances, zakupionym 15.03.2026? Odpowiedz TAK/NIE i uzasadnij."

Jeśli LLM odpowie NIE - nie generuj odpowiedzi. Zamiast tego: "Nie znalazłem dokumentu pasującego do Twojej sytuacji. Połączę Cię z konsultantem."

Krok 5: Loguj błędy stosowalności

Monitoruj przypadki, gdy:

• System nie znalazł dokumentu po filtrowaniu (luka w dokumentacji)
• LLM odrzucił dokument w walidacji (błędne metadane lub zbyt słabe filtry)
• Klient zakwestionował odpowiedź (możliwy błąd stosowalności)

To Twoje sygnały, gdzie system szwankuje. Bez logowania lecisz w ciemno.

Kiedy problem stosowalności Cię nie dotyczy

Nie każdy system RAG potrzebuje tej złożoności. Jeśli:

• Masz jedną wersję dokumentacji dla wszystkich
• Polityki nie zależą od regionu, czasu ani uprawnień
• Dokumenty nie mają wariantów ani wersji

...to standardowy RAG wystarczy. Problem stosowalności to problem skali.

Jeśli Twoja firma ma więcej niż 100 dokumentów, obsługuje więcej niż jeden region lub ma historię zmian w politykach - ten problem prędzej czy później Cię dopadnie. Lepiej go przewidzieć, niż naprawiać po pierwszym kryzysie wizerunkowym.

Co to zmienia w projektowaniu systemów RAG

Problem stosowalności przesuwa punkt ciężkości z retrieval na scope management. Nie wystarczy dobrze wyszukiwać - trzeba wiedzieć, gdzie wyszukiwać.

To zmienia architekturę:

• Metadane stają się równie ważne jak embeddingi
• Ekstrakcja kontekstu to osobny krok przed wyszukiwaniem
• Walidacja stosowalności to osobny krok po wyszukiwaniu
• Logowanie i monitoring błędów stosowalności to must-have, nie nice-to-have

Jeśli budujesz RAG dla firmy - zaprojektuj system z myślą o wariantach dokumentacji od pierwszego dnia. Dodanie tego później to refaktoryzacja całej bazy wiedzy.

Podsumowanie - co zapamiętać

RAG nie eliminuje wszystkich problemów z wiarygodnością AI. W małych systemach redukuje halucynacje. W dużych organizacjach pojawia się nowy problem: odpowiedzi prawdziwe, ale nietrafione.

Problem stosowalności to luka między "czy to prawda" a "czy to prawda dla mnie". Rozwiązanie: metadane kontekstowe, ekstrakcja zmiennych z zapytania, filtrowanie przed wyszukiwaniem, walidacja po wyszukiwaniu.

Jeśli budujesz RAG dla firmy - zaprojektuj system z myślą o wariantach dokumentacji od pierwszego dnia. Inaczej będziesz naprawiać to pod presją, gdy klient dostanie błędną odpowiedź i zacznie eskalować sprawę.

Jeden krok na start

Otwórz swoją dokumentację firmową. Policz, ile wariantów ma jeden dokument (regionalne, czasowe, produktowe). Jeśli więcej niż 1 - masz problem stosowalności. Zacznij od oznaczenia dokumentów metadanymi: region, data obowiązywania, typ klienta. To fundament pod RAG, który działa w skali.

Najczęstsze pytania

Czy problem stosowalności dotyczy tylko dużych firm?

Nie tylko, ale tam jest najbardziej widoczny. Jeśli masz więcej niż jedną wersję dokumentu (np. regulamin dla UE i USA) albo polityki zmieniały się w czasie - problem już Cię dotyczy. Małe firmy mogą go ignorować na początku, ale z czasem dokumentacja rośnie i warianty się mnożą.

Czy embeddingi AI nie wystarczą do rozróżnienia kontekstu?

Nie. Embeddingi wychwytują podobieństwo semantyczne, ale nie rozróżniają "prawda dla planu A" od "prawda dla planu B". Dwa dokumenty o wymianie produktów mogą być semantycznie identyczne, a różnić się tylko jednym szczegółem - okresem gwarancji. Bez metadanych i filtrów RAG nie ma jak tego rozróżnić.

Jak testować system RAG pod kątem stosowalności?

Stwórz zestaw testowy z pytaniami, gdzie znasz poprawną odpowiedź dla konkretnego kontekstu (region, plan, data). Sprawdź, czy system zwraca właściwy dokument po zastosowaniu filtrów. Monitoruj przypadki, gdy użytkownik kwestionuje odpowiedź - to sygnał, że coś poszło nie tak z filtrowaniem lub metadanymi.

Czy mogę użyć LLM do automatycznego tagowania dokumentów metadanymi?

Tak, to dobry sposób na start - zwłaszcza jeśli masz setki dokumentów. Użyj GPT-5 lub Claude Opus 4.7 z promptem: "Przeanalizuj ten dokument i wydobądź: region, typ klienta, okres obowiązywania, kategorię produktu". Zawsze zweryfikuj ręcznie próbkę - błędne metadane to gorsza sytuacja niż brak metadanych.

Czy problem stosowalności występuje też w systemach agentowych AI?

Tak, i tam jest jeszcze bardziej krytyczny. Agent AI podejmuje decyzje na podstawie dokumentacji - jeśli wybierze niewłaściwy wariant polityki, może wykonać akcję (np. zatwierdzić zwrot, wysłać maila) na podstawie błędnych założeń. W agentach stosowalność to nie tylko kwestia wiarygodności odpowiedzi, ale bezpieczeństwa działań.