Jak działają systemy RAG w AI

Czym jest RAG? Jasna definicja

Retrieval-Augmented Generation (RAG), czyli generowanie wspomagane wyszukiwaniem, to metoda, w której duży model językowy (Large Language Model, LLM) przed wygenerowaniem odpowiedzi celowo pobiera zewnętrzne treści z bazy wiedzy (retrieval) i osadza je w prompcie (augmentation), aby oprzeć generowanie na weryfikowalnych źródłach. Oryginalną definicję podali Lewis i in. (Facebook AI Research, NeurIPS 2020); opisuje ona RAG jako połączenie pamięci parametrycznej (wytrenowanego modelu językowego) i pamięci nieparametrycznej (zewnętrznego, przeszukiwalnego indeksu).

Porównując różne kanoniczne definicje, można ustalić minimalny wspólny mianownik. System RAG składa się z trzech obowiązkowych elementów: (i) zewnętrznego magazynu wiedzy z indeksem, (ii) retrievera, który znajduje odpowiednie fragmenty, oraz (iii) generującego LLM, którego prompt jest uzupełniany o znalezione treści. Główna korzyść: RAG dostarcza odpowiedzi oparte na źródłach i możliwe do prześledzenia, mierzalnie ogranicza halucynacje i utrzymuje aktualność wiedzy bez konieczności ponownego trenowania modelu.

Dlaczego RAG? Problem, który rozwiązuje

Modele LLM mają trzy strukturalne słabości: halucynują, ich wiedza jest zamrożona na stanie z treningu, a ich odpowiedzi nie da się prześledzić. RAG odpowiada na wszystkie trzy. Zamiast trenować model na nowych danych w kosztownym procesie fine-tuningu, odpowiednią wiedzę dociąga się w czasie działania, osobno dla każdego zapytania. Aktualizacja jest więc tak prosta jak ponowna indeksacja; podawanie źródeł (citations) jest możliwe natywnie dzięki identyfikatorom chunków, a odpowiedź pozostaje powiązana z weryfikowalnym materiałem.

Właśnie te cechy sprawiają, że RAG jest de facto standardowym wzorcem dla AI w przedsiębiorstwach w Europie, gdzie identyfikowalność, aktualność i kontrola nad danymi nie są opcjonalne, lecz wymagane zarówno przez regulacje, jak i ze względu na zaufanie.

Pipeline RAG: ścieżka indeksowania i ścieżka zapytań

Produkcyjny system RAG ma dwie ścieżki. Ścieżka indeksowania (offline/batch) przetwarza źródła wiedzy: konektory ładują dokumenty z SharePointa, S3, Confluence lub baz danych; parser (np. Docling) wyodrębnia tekst, tabele i struktury z zachowaniem układu; chunker dzieli treści na fragmenty; model embeddingowy generuje wektory, a upsert zapisuje je wraz z metadanymi (ID tenanta, ACL, źródło, znacznik czasu) w wektorowej bazie danych; opcjonalnie towarzyszy temu równoległy indeks BM25.

Ścieżka zapytań (online) zaczyna się od zapytania użytkownika, opcjonalnie przeformułowanego (query rewriting, HyDE). Następnie działa wyszukiwanie hybrydowe (zwykle top_k = 50–100), a po nim reranker, który zawęża wynik do 5–10 najistotniejszych fragmentów. Trafiają one do szablonu promptu z cytowaniem źródeł i są przekazywane do LLM; kontrola wierności (faithfulness check) może sprawdzić odpowiedź pod kątem zgodności ze źródłami.

Embeddingi i wektorowe bazy danych

Embeddingi to numeryczne, wektorowe reprezentacje tekstu, w których bliskość semantyczna jest odwzorowana jako bliskość geometryczna (domyślną miarą dla znormalizowanych wektorów jest podobieństwo cosinusowe). Dla korpusów niemieckojęzycznych obowiązuje ważna zasada: pozycja w angielskim rankingu MTEB to nie pozycja w rankingu niemieckim. Modele, które prowadzą po angielsku, często tracą 5–15 punktów nDCG@10 na niemieckich złożeniach, języku specjalistycznym i długich słowach. Miarodajne są benchmarki niemieckie lub wielojęzyczne (MMTEB, MIRACL-de, MTEB-DE). Niemieckie złożenia generują też więcej tokenów; reguła praktyczna: w zależności od modelu niemiecki zużywa ok. 1,3–1,7× więcej tokenów niż angielski.

Wektorowe bazy danych przechowują embeddingi i odpowiadają na zapytania o podobieństwo za pomocą indeksów przybliżonych najbliższych sąsiadów (Approximate Nearest Neighbour). Standardowym algorytmem jest HNSW (Hierarchical Navigable Small World, Malkov & Yashunin 2016), który działa w niemal wszystkich systemach produkcyjnych: od Qdrant, przez Weaviate, Milvus i pgvector, aż po SAP HANA. Praktyczna wartość orientacyjna: HNSW zapewnia 95–99% recall i komfortowo radzi sobie do ~100 mln wektorów; powyżej tej skali pomagają kwantyzacja (halfvec, SQ8) lub metody dyskowe, takie jak DiskANN.

Dla MŚP poniżej ~10–50 mln wektorów pragmatycznym, suwerennym rozwiązaniem domyślnym jest pgvector na zarządzanym Postgresie (IONOS, STACKIT, OTC, Hetzner): jedna baza danych, jedna strategia kopii zapasowych, jeden łańcuch umów powierzenia przetwarzania danych. Duże koncerny zwykle utrzymują równolegle dwa lub trzy magazyny: SAP HANA Vector dla danych przechowywanych w SAP oraz dedykowaną bazę wektorową (Qdrant, Weaviate) dla dokumentów nieustrukturyzowanych.

Chunking: jak dzieli się wiedzę na fragmenty

Chunking w dużej mierze decyduje o jakości retrievalu. Naiwny chunking o stałym rozmiarze (np. 512 tokenów, 50 tokenów nakładania) jest odporny, ale rozcina zdania, tabele i listy; to częsty antywzorzec. Lepsze strategie:

• Chunking rekurencyjny/semantyczny respektuje strukturę dokumentu lub tnie w miejscach, w których zmienia się treść.
• Chunking hierarchiczny (parent-child) używa małych chunków do wyszukiwania, a dużych chunków nadrzędnych jako kontekstu dla generatora.
• Contextual Retrieval (Anthropic, 09/2024) przed utworzeniem embeddingu dodaje na początku każdego chunka krótki nagłówek kontekstowy wygenerowany przez LLM. Efekt: −49% błędów retrievalu, −67% z dodatkowym rerankerem. Ceną jest jedno wywołanie LLM na chunk na etapie ingestii.
• Late Chunking (Jina, 2024) odwraca kolejność: najpierw cały dokument jest osadzany za pomocą embeddera z długim kontekstem, a potem embeddingi tokenów są uśredniane w granicach poszczególnych chunków; dzięki temu wektory chunków zachowują kontekst dokumentu. Late chunking jest na etapie ingestii praktycznie darmowy (bez dodatkowego wywołania LLM), a w badaniu Jiny wypada o ~24% lepiej niż naiwny chunking. W projektach DACH, w których liczy się dyscyplina kosztowa, late chunking z Jina v3/v4 lub BGE-M3 jest często bardziej opłacalnym rozwiązaniem domyślnym.

W przypadku PDF-ów o rozbudowanym układzie (umowy, korespondencja z urzędami, sprawozdania MSSF) wygrywają parsery uwzględniające układ (Docling, Marker), a w dalszej perspektywie podejścia multimodalne, takie jak ColPali/ColQwen czy Jina v4, które renderują każdą stronę jako obraz i w ten sposób omijają błędy OCR i układu.

Wyszukiwanie hybrydowe i reranking

Wyszukiwanie hybrydowe łączy dense retrieval (embeddingi, bliskość semantyczna) ze sparse retrieval (BM25 lub wyuczone modele rzadkie, takie jak SPLADE/ELSER) i scala wyniki, zwykle metodą Reciprocal Rank Fusion (RRF). Powód: same embeddingi nie trafiają w dokładne kody, identyfikatory, sygnatury akt, numery materiałów SAP czy numery IBAN, czyli dokładnie te tokeny, które liczą się w praktyce B2B w regionie DACH. BM25 je wyłapuje. W przypadku niemieckiego ze złożeniami i językiem specjalistycznym podejście hybrydowe daje konsekwentnie o 5–15 punktów nDCG@10 więcej niż samo dense retrieval.

Reranking to drugi, precyzyjniejszy etap sortowania: cross-encoder przetwarza zapytanie i dokument łącznie i na nowo ocenia najlepszych kandydatów. To pojedyncze usprawnienie o najwyższym ROI w całym pipelinie: zwykle +5–15 punktów procentowych recall@5. Badanie Anthropic (09/2024) mierzy efekt na podstawie odsetka błędów przy retrievalu top-20: same Contextual Embeddings obniżają go o 35%, Contextual Embeddings w połączeniu z Contextual BM25 (razem Contextual Retrieval) o 49%, a z dodatkowym rerankerem o 67%. Sam krok rerankera obniża przy tym odsetek błędów z 2,9% do 1,9%.

Budżet opóźnień dla standardowego pipeline'u (10 mln wektorów): pierwszy etap BM25 i dense po 10–50 ms, RRF poniżej 1 ms, reranker cross-encoder (np. BGE Reranker M3 na GPU) 100–300 ms; łącznie 150–500 ms przed generowaniem przez LLM. Przy rygorystycznych SLA poniżej 100 ms reranker jest pierwszym kandydatem do usunięcia, kosztem utraty 5–15 punktów recall.

RAG a alternatywy: co wybrać i kiedy?

RAG nie jest jedyną strategią. Wybór między nim a fine-tuningiem, długim kontekstem i prompt engineeringiem zależy od celu:

Otwartą, choć coraz lepiej rozstrzygniętą debatą jest długi kontekst vs RAG. Obecne modele przetwarzają ok. 1 mln tokenów kontekstu, np. Gemini 3.1 Pro (preview) i aktualne modele Claude. W klasycznym teście single-needle już Gemini 1.5 Pro osiągał ponad 99,7% recall przy 1 mln tokenów; gdy model szuka jednocześnie 100 „igieł”, wartość spada do nieco ponad 60% (raport Gemini 1.5, arXiv:2403.05530). Do tego dochodzą ~30–60× większe opóźnienia i o rzędy wielkości wyższe koszty na zapytanie w porównaniu z pipeline'em RAG (według szacunku Tiana Pana, 2026). Konsensus w 2026 roku: długi kontekst uzupełnia RAG przy wąsko zdefiniowanych obciążeniach, ale rzadko zastępuje go w scenariuszach multi-needle, multi-tenant i wrażliwych na koszty.

RODO i suwerenna eksploatacja w Europie

Uwaga: poniższe informacje mają charakter informacyjny i nie stanowią porady prawnej.

Jedno z merytorycznie najważniejszych pytań dotyczących RODO w latach 2025/2026 brzmi: Czy embeddingi są danymi osobowymi? Uczciwa odpowiedź to: „najprawdopodobniej tak, jeśli pochodzą z danych osobowych”. Ataki inwersyjne odtwarzają dokładnie do 92% 32-tokenowych danych wejściowych (Morris i in., EMNLP 2023), więc embedding nie jest bezpieczną pseudonimizacją. Opinia EROD 28/2024 wymaga oceny ryzyka ponownej identyfikacji w każdym przypadku z osobna; wyrok TSUE C-413/23 P (wrzesień 2025) doprecyzowuje, że dane spseudonimizowane nie są automatycznie danymi osobowymi dla każdego odbiorcy, ale jedynie zawęża obowiązki, a nie je znosi.

Praktyczne konsekwencje dla architektur RAG, w oparciu o wytyczne dotyczące RAG niemieckiej Konferencji Ochrony Danych (DSK) oraz zalecenia EROD:

• Prawo do usunięcia danych (art. 17): również embeddingi i chunki muszą dać się usunąć. Grafy HNSW w różnym stopniu obsługują usuwanie pojedynczych punktów; semantyka usuwania jest twardym kryterium zakupowym (pgvector i Qdrant usuwają efektywnie).
• Separacja tenantów: ID tenanta i ACL w metadanych, filtr przy każdym zapytaniu, defense-in-depth (uwierzytelnianie + filtr + ponowna weryfikacja + log audytowy). Współdzielony indeks bez filtra tenanta to incydent RODO, który tylko czeka na swój moment.
• Rezydencja danych: preferować hosting w regionie UE; u dostawców chmury z USA ocenić ryzyko rezydualne związane z CLOUD Act/FISA 702 (SCC + TIA). Przesłanie embeddingów do bazy wektorowej hostowanej w USA to transfer do państwa trzeciego.
• Minimalizacja przed embeddingiem: w miarę możliwości usuwać imiona i nazwiska, adresy e-mail i identyfikatory przed utworzeniem embeddingu albo zastępować je stabilnymi pseudonimami; szyfrować wektory kluczami zarządzanymi przez klienta (CMK/BYOK).

W przypadku regulowanych obciążeń obowiązuje zasada: każda warstwa musi być wdrażalna w sposób suwerenny. W UE dotyczy to np. sektora finansowego objętego DORA (w Niemczech dodatkowo MaRisk), wyrobów medycznych i wyrobów do diagnostyki in vitro objętych MDR/IVDR, podmiotów kluczowych i ważnych objętych krajowym wdrożeniem NIS2 (w Austrii NISG 2026) oraz, w Niemczech, sektora publicznego objętego OZG. W Szwajcarii obowiązuje znowelizowana federalna ustawa o ochronie danych (revDSG), zaprojektowana z myślą o zgodności z RODO.

Suwerenna infrastruktura w regionie DACH (Niemcy, Austria, Szwajcaria) i w UE jest w 2026 roku solidna: Qdrant (Berlin), Weaviate (Amsterdam), Haystack/deepset (Berlin), SAP HANA Cloud Vector Engine oraz pgvector na STACKIT/IONOS/OTC/Hetzner. Wśród dostawców modeli obraz się zmienił. Firma Aleph Alpha (Heidelberg) odeszła od własnych modeli frontier i oferuje m.in. platformę PhariaAI. W kwietniu 2026 roku Cohere ogłosiło połączenie z Aleph Alpha, a 16 września 2026 roku obie firmy podpisały umowę o fuzji. Połączona firma ma działać jako Cohere z siedzibami w Toronto i Berlinie, a lokalizacja w Heidelbergu ma skupić się na badaniach. Finalizacja transakcji wymaga jeszcze zgód organów regulacyjnych. Jina AI (Berlin), dostawca modeli embeddingowych i rerankerów, należy od października 2025 roku do Elastic.

Uwaga dotycząca EU AI Act (stan na 10/2026): Digital Omnibus dotyczący AI, czyli rozporządzenie (UE) 2026/1744, obowiązuje od 27 lipca 2026 r. Obowiązki dotyczące systemów wysokiego ryzyka z załącznika III mają więc zastosowanie od 2 grudnia 2027 r., a w przypadku AI wysokiego ryzyka w produktach z załącznika I od 2 sierpnia 2028 r. Obowiązki w zakresie przejrzystości z art. 50 obowiązują od 2 sierpnia 2026 r. Jedynie w przypadku oznaczania w formacie nadającym się do odczytu maszynowego zgodnie z art. 50 ust. 2 dostawcy systemów, które były na rynku już przed tą datą, mają czas do 2 grudnia 2026 r.

Zapewnianie jakości z RAGAS

System RAG bez ewaluacji po cichu traci na jakości. Standardem de facto jest RAGAS z kluczowymi metrykami Faithfulness (wierność źródłu), Answer Relevancy, Context Precision i Context Recall, uzupełniany przez TruLens („RAG Triad”) lub DeepEval. Sensowne jest połączenie zbioru referencyjnego (gold set), LLM-as-Judge i testów A/B na produkcji, na stałe osadzone w pipelinie CI. Wymuszanie cytowań (citation forcing), guardraile wierności i odmowa odpowiedzi przy niskim wyniku to standardowe środki przeciwko halucynacjom, które występują mimo RAG.

Perspektywy i wskazówka praktyczna

Wektorowe bazy danych i modele embeddingowe na poziomie API w dużej mierze się utowarowiły: HNSW jest wszędzie, wyszukiwanie hybrydowe to standard, a multimodalność (ColPali, Jina v4) to nowa granica. Równolegle RAG rozwija się przez kolejne etapy Naive → Advanced → Modular → Agentic RAG, a retrieval coraz częściej jest rozumiany jako dynamiczne narzędzie agenta (Singh i in. 2025).

Pragmatyczny start dla projektu w Europie: zacznij od BM25 + Dense (BGE-M3) + reranker cross-encoder (BGE Reranker M3) na suwerennej bazie Postgres/pgvector, sklasyfikuj dane osobowe przed utworzeniem embeddingów i mierz jakość od pierwszego dnia za pomocą RAGAS. W 2026 roku o architekturze nie decyduje już surowa wydajność, lecz pytanie, gdzie leżą embeddingi, kto ma do nich dostęp i czy w razie potrzeby da się przenieść stack on-premise. Suwerenny, przygotowany pod język niemiecki i oparty na open source stack RAG to solidna odpowiedź.