Dwa lata temu wdrażaliśmy system RAG dla przedsiębiorstwa produkcyjnego zarządzającego obszerną biblioteką dyrektyw technicznych i instrukcji serwisowych. System odpowiadał płynnie, brzmiał pewnie i operatorzy szybko go polubili. Problem pojawił się przy pierwszym audycie wewnętrznym: inżynier bezpieczeństwa zapytał, z którego konkretnego dokumentu pochodzi procedura zatrzymania linii. System odpowiedział — ale nikt w sali nie był w stanie zweryfikować, czy to prawda, czy jedynie przekonująco brzmiąca halucynacja. Audyt zakończył się zaleceniem tymczasowego wycofania systemu.
Ten scenariusz nie jest wyjątkiem. Dla każdego, kto wdraża RAG w środowisku regulowanym lub odpowiedzialnościowo wrażliwym — produkcja, energetyka, budownictwo, prawo, ochrona zdrowia — grounding (zakorzenienie odpowiedzi w konkretnych źródłach) i attribution (przypisanie odpowiedzi do cytowanego źródła) są równie ważne jak sama dokładność odpowiedzi. Ten artykuł wyjaśnia, dlaczego tak jest, jakie techniki istnieją i gdzie leżą ich ograniczenia.
Dlaczego cytowania to nie jest tylko detal UX
Większość zespołów zajmuje się cytowaniami późno — jako ostatnim krokiem przed produkcją, gdy okazuje się, że „trzeba jakieś odniesienie". To błąd. Grounding i attribution to decyzje architektoniczne, nie warstwa kosmetyczna.
Trzy powody, dla których ma to znaczenie:
Compliance i audytowalność. W sektorach regulowanych (normy ISO, REACH, dyrektywa maszynowa, dokumentacja medyczna) każdy wynik wpływający na decyzję musi być odtwarzalny. System, który powie „postępuj zgodnie z normą EN ISO 13849" bez odniesienia do konkretnej sekcji i wersji dokumentu, nie spełnia wymagań audytora.
Zaufanie i onboarding. Nowy operator, który widzi cytowanie „Dyrektywa bezpieczeństwa BS-2024, sekcja 4.3, strona 12", może zweryfikować odpowiedź. Odpowiedź bez cytowania wymaga ślepego zaufania do systemu — a większość ekspertów słusznie tego odmawia.
Diagnozowanie błędów. Gdy odpowiedź jest niepoprawna, cytowanie natychmiast pokazuje, gdzie w pipeline wystąpił problem: retrieval wczytał zły dokument, albo generacja go niepoprawnie zacytowała. Bez cytowania debugowanie jest znacznie wolniejsze. (Więcej o diagnostyce pipeline w Jak oceniać RAG: RAGAS, faithfulness, context precision.)
Co dokładnie oznacza „grounding"
Grounding to właściwość odpowiedzi: każde twierdzenie w niej opiera się na konkretnym fragmencie wczytanego kontekstu. Przeciwieństwem jest odpowiedź zahalucynowana lub swobodnie interpolowana, którą model wygenerował z własnej wiedzy parametrycznej zamiast z dostarczonych dokumentów.
Attribution to operacyjna realizacja groundingu: przypisanie konkretnego identyfikatora (nazwa pliku, ID dokumentu, URL, numer strony, numer sekcji) do każdego twierdzenia lub całej odpowiedzi.
Ważne rozróżnienie: grounding i attribution różnią się od faktycznej poprawności. Odpowiedź może być w pełni ugruntowana — każde twierdzenie pochodzi z dostarczonego kontekstu — a mimo to błędna, jeśli retrieval wczytał zły lub przestarzały dokument. Faithfulness (spójność z kontekstem) to nie to samo co accuracy (faktyczna poprawność). Na tę różnicę zwraca uwagę również framework RAGAS.
Techniki osiągania groundingu
1. Systemowy prompt z jawnym zakazem
Najprostsza technika: w systemowym prompcie jawnie zakazujesz modelowi odpowiadania z własnej wiedzy i nakazujesz mu cytować.
Przykładowy systemowy prompt:
Odpowiadaj wyłącznie na podstawie dostarczonego kontekstu.
Jeśli odpowiedź nie znajduje się w kontekście, powiedz: "Tej informacji nie znalazłem w dostępnych dokumentach."
Każde twierdzenie podawaj w formacie: [Źródło: {doc_id}, strona {page}].
Nie wymyślaj treści, które nie ma w kontekście.Zalety: proste, szybkie, zerowe koszty infrastrukturalne.
Ograniczenia: modele nie zawsze stosują się do tej zasady niezawodnie — szczególnie przy długich kontekstach, gdzie relewantny fragment ginie wśród innych dokumentów. Position bias (model preferuje początek lub koniec kontekstu) to realny problem, udokumentowany we wszystkich modelach frontier.
2. Strukturalny wynik z referencją per twierdzenie
Zamiast wolnego tekstu prosisz model o strukturalny wynik (structured outputs / JSON mode), gdzie każde twierdzenie zawiera referencję do źródła:
{
"answer": "Maksymalna temperatura robocza wynosi 85 °C.",
"citations": [
{
"claim": "Maksymalna temperatura robocza wynosi 85 °C.",
"source_id": "manual-v3.2.pdf",
"page": 47,
"section": "4.2 Limity temperaturowe",
"quote": "Operating temperature must not exceed 85 °C under continuous load."
}
]
}To podejście umożliwia automatyczną weryfikację: po generacji możesz programowo sprawdzić, czy cytowany quote rzeczywiście istnieje w dokumencie na podanej stronie. Jeśli nie — odpowiedź oznaczasz jako niemożliwą do zweryfikowania.
Zalety: cytowanie jest czytelne maszynowo i automatycznie weryfikowalne.
Ograniczenia: zwiększa długość wyjścia i wymagania dotyczące context window; przy niektórych modelach dokładność cytowania spada przy bardziej złożonych pytaniach.
3. Weryfikacja post-generacyjna (grounding check)
Bardziej solidne podejście oddziela generację od weryfikacji. Po wygenerowaniu odpowiedzi uruchamiasz drugi call LLM, który otrzymuje oryginalny kontekst i wygenerowaną odpowiedź, a następnie weryfikuje każde twierdzenie:
Dla każdego twierdzenia w odpowiedzi podaj:
- claim: cytat twierdzenia
- supported: true/false
- evidence: fragment z kontekstu, który potwierdza twierdzenie (lub null)Wynik wykorzystujesz do filtrowania: twierdzenia oznaczone supported: false albo usuwasz, albo flagowasz w UI czerwoną flagą.
To jest myślowy fundament metryki faithfulness w RAGAS — mierzy, jaki odsetek twierdzeń w odpowiedzi jest poparty wczytanym kontekstem.
Zalety: cytowania są niezależnie weryfikowane, nie tylko wygenerowane przez model; znacząco zmniejsza odsetek twierdzeń niemożliwych do zweryfikowania.
Ograniczenia: dwukrotne koszty LLM na każdą odpowiedź; latencja rośnie. Dla aplikacji real-time kompromisem jest: generacja online, weryfikacja asynchroniczna z flagowaniem w logu.
4. Multi-vector retrieval i grounding na poziomie fragmentu
Zaawansowana technika: zamiast wczytywania całych dokumentów retrieval zwraca konkretne fragmenty wraz z ich identyfikatorami. Model otrzymuje nie tylko tekst, ale też metadane każdego chunka:
[DOC: safety-manual-v2.pdf | SEC: 4.3 | PAGE: 31 | CHUNK_ID: sm-v2-431]
Urządzenie nie może być uruchamiane w temperaturze poniżej -10 °C...
[DOC: iso-13849-2023.pdf | SEC: 6.1.2 | PAGE: 88 | CHUNK_ID: iso-13849-612]
Kategoria funkcji bezpieczeństwa jest określana zgodnie z...Model ma w kontekście bezpośrednio identyfikatory i ma znacznie prostsze zadanie: podczas odpowiadania jedynie odwołuje się do CHUNK_ID, który zawiera daną informację. Backend tłumaczy następnie CHUNK_ID na pełne odniesienie.
Zalety: grounding jest wewnętrznie prostszy, bo model cytuje identyfikatory zamiast rekonstruować ścieżkę do dokumentu.
Ograniczenia: wymaga dokładnego wzbogacenia metadanych w ingestion pipeline; przy złym chunkingu chunk_id może być mylący. Więcej o ingestion i chunkingu w RAG pipeline — 3 ustawienia jakości.
Gdzie grounding zawodzi mimo RAG
RAG znacząco redukuje halucynacje, ale ich nie eliminuje. W praktyce widzimy cztery wzorce błędów, które pojawiają się nawet przy poprawnie skonfigurowanym groundingu:
Position bias. Modele poświęcają więcej uwagi początkowi i końcowi okna kontekstowego. Relewantny fragment w środku wśród dziesiątek innych dokumentów może zostać zignorowany, nawet jeśli retrieval poprawnie go wczytał. Rozwiązanie: reranker przesuwa najistotniejsze chunki na początek kontekstu.
Interpolacja na poziomie tokenów. Model niekiedy łączy informacje z kilku fragmentów i tworzy twierdzenie, którego dosłownie nie ma w żadnym z nich — choć każda połowa twierdzenia pochodzi z innego dokumentu. To subtelna forma halucynacji, którą grounding check wykryje tylko wtedy, gdy jest naprawdę granularny.
Cytowanie istniejącego, ale nierelewantnego źródła. Model może zacytować dokument, który istnieje w kontekście, ale dana konkretna informacja w nim nie ma. Jeśli robisz jedynie powierzchowną kontrolę (czy źródło istnieje w kontekście?), to przejdzie. Głębsza weryfikacja musi sprawdzać, czy cytowany quote rzeczywiście jest w dokumencie.
Przestarzały dokument w bazie wiedzy. Grounding jest spójny z kontekstem — ale jeśli baza wiedzy jest nieaktualna, odpowiedź będzie ugruntowana, a jednocześnie faktycznie błędna. To nie jest błąd modelu ani pipeline — to problem zarządzania bazą wiedzy. Rozwiązanie: dokumenty muszą mieć wersje i daty ważności; przy wyszukiwaniu filtruj według aktualności.
Grounding w sektorach regulowanych
Dla firm, w których wyniki systemów AI są używane przy decyzjach mających wpływ bezpieczeństwa lub prawny, techniczny grounding nie wystarcza — potrzebny jest audytowalny zapis.
W praktyce oznacza to:
- Każda odpowiedź jest przechowywana z pełnym śladem cytowań (document ID, wersja dokumentu, numer strony, timestamp).
- Baza wiedzy posiada wersjonowane rekordy — możesz powiedzieć, która wersja normy była aktywna w dniu, gdy system wygenerował odpowiedź.
- Zmiana dokumentu w bazie wiedzy unieważnia zależne odpowiedzi z cache — nowy dokument, nowa odpowiedź.
- Odmowy odpowiedzi są logowane — gdy system powie „nie znalazłem informacji", rejestrowane jest pytanie i powód odmowy.
Akt UE w sprawie AI w kontekście systemów AI wysokiego ryzyka (np. systemów stosowanych w bezpieczeństwie przemysłowym) wymaga logowania, identyfikowalności i możliwości nadzoru ludzkiego. Ślad cytowań to jeden z konkretnych sposobów spełnienia tych wymogów. Więcej o obowiązkach firm w Ustawa o AI UE — obowiązki firmy.
Praktyczna implementacja — od czego zacząć
Jeśli budujecie pipeline RAG od zera lub refaktoryzujecie istniejący, proponujemy trzystopniową kolejność:
- 1.Zacznij od metadanych przy ingestion. Każdy dokument przy wgrywaniu otrzymuje
doc_id,version,valid_from,section_path. Bez tego późniejsze cytowania to jedynie pełne nazwy plików bez struktury.
- 1.Wbuduj identyfikatory w szablon promptu. Retrieval zwraca chunki z metadanymi; szablon promptu formatuje je do kontekstu widocznego dla modelu. Dzięki temu model ma identyfikatory bezpośrednio dostępne.
- 1.Dodaj asynchroniczny grounding check. W pierwszej iteracji nie musi być synchroniczny — wystarczy asynchroniczna weryfikacja po generacji, wynik loguj i flaguj w dashboardzie monitoringu. Synchroniczny grounding check dodaj wtedy, gdy compliance tego jawnie wymaga.
Narzędzia, których używamy w praktyce: LlamaIndex do pipeline retrievalu z wzbogacaniem metadanych, Qdrant jako baza wektorowa z filtrami payload (co umożliwia filtrowanie według wersji dokumentu lub daty ważności), RAGAS do regularnego offline pomiaru faithfulness. Do orkiestracji wieloetapowej weryfikacji LangGraph.
Najczęstsze pytania
Czy grounding to to samo co faktyczna poprawność odpowiedzi?
Nie. Grounding oznacza, że odpowiedź jest spójna z wczytanym kontekstem — każde twierdzenie pochodzi z dostarczonych dokumentów. Faktyczna poprawność zależy również od jakości samej bazy wiedzy. Jeśli w bazie wiedzy znajduje się nieaktualny lub błędny dokument, odpowiedź może być w pełni ugruntowana, a jednocześnie faktycznie błędna. To dlatego zarządzanie bazą wiedzy (wersje, daty ważności, aktualizacje) jest równie ważne jak sam pipeline RAG.
Który model najlepiej stosuje się do instrukcji cytowania?
Modele frontier (Claude 4 Sonnet/Opus, GPT-4.1, Gemini 2.5 Pro) mają znacznie lepsze instruction following niż mniejsze modele. W przypadku modeli open-weight (Llama, Qwen3, Mistral) niezawodność przestrzegania instrukcji cytowania jest niższa, szczególnie przy długich kontekstach. Dla systemów produkcyjnych z wymogami compliance zalecamy kombinację: mniejszy model do generacji + weryfikacyjny call post-generacyjny. Więcej o wyborze modelu w Jak wybrać model LLM w 2026.
Czy post-generacyjny grounding check spowalnia czas odpowiedzi systemu?
Tak — synchroniczny call weryfikacyjny podwaja latencję generacji. Dla UI real-time standardowym kompromisem jest weryfikacja asynchroniczna: odpowiedź jest wyświetlana natychmiast, weryfikacja przebiega w tle, a wynik pojawia się jako odznaka „zweryfikowane / niezweryfikowane" lub jest logowany do audytu. Dla batch processingu lub systemów raportowych (gdzie latencja nie jest krytyczna) synchroniczny grounding check jest preferowany.
Jak sprawdzić, jaką faithfulness ma nasz system RAG?
Najprostszy sposób: utwórz golden set — zbiór pytań z referencyjnymi odpowiedziami i dokumentami — i uruchom ewaluację RAGAS. Wynik faithfulness powie ci, jaki odsetek twierdzeń w odpowiedziach jest spójny z wczytanym kontekstem. Do ciągłego monitorowania w produkcji integracja z Langfuse lub LangSmith umożliwia mierzenie faithfulness na próbce rzeczywistych zapytań. Szczegółowy opis procedury w Jak oceniać RAG: RAGAS, faithfulness, context precision.
Czy każdy chunk musi być cytowany, czy wystarczy jedno źródło na odpowiedź?
Zależy od przypadku użycia. Dla prostych pytań faktycznych (jedna odpowiedź pochodzi z jednego miejsca) jedno źródło wystarczy. Dla złożonych pytań, gdzie odpowiedź syntetyzuje wiele fragmentów z różnych dokumentów, granularne cytowanie per twierdzenie jest dokładniejsze i bardziej audytowalne. Systemy dla środowisk regulowanych powinny domyślnie cytować na poziomie twierdzenia — nawet jeśli zwiększa to objętość wyjścia.
*Jeśli wdrażacie system RAG, przy którym musicie wiedzieć nie tylko to, co model odpowiedział, ale również skąd to wie, chętnie przyjrzymy się waszej konkretnej sytuacji. Grounding i architektura cytowań są częścią każdego wdrożenia, które realizujemy w MP Industrial Solutions — skontaktujcie się z nami w celu wstępnej oceny.*