Pipeline RAG: ingestia, wyszukiwanie, generowanie i reranking

Architektura RAG opisuje techniczną budowę systemu Retrieval-Augmented Generation w dwóch wyraźnie oddzielonych fazach. Pierwsza faza, ingestia (inaczej indeksowanie), działa offline i przekształca dokumenty źródłowe w przeszukiwalny indeks. Druga faza, obsługa zapytań (query time), działa online przy każdym zapytaniu: pobiera pasujące treści, ponownie je porządkuje i przekazuje modelowi językowemu do wygenerowania odpowiedzi. Jeśli chcesz używać RAG produkcyjnie, musisz rozumieć obie ścieżki osobno i osobno nimi zarządzać.

• Dwie ścieżki, nie jedna: ingestia (loading, chunking, embedding, upsert) działa wsadowo; ścieżka zapytania (embedding, retrieval, filtrowanie, reranking, generowanie) działa przy każdym zapytaniu.
• Reranking to obowiązek, nie dodatek: cross-encoder po wstępnym wyszukiwaniu mierzalnie obniża odsetek błędów wyszukiwania (nawet o 67% w połączeniu z Contextual Retrieval, stan na wrzesień 2024).
• Metadane decydują o zgodności z przepisami: tenant_id, ACL i odwołanie do źródła w każdym chunku to techniczna podstawa multi-tenancy, rozdzielenia danych klientów i możliwości usuwania danych.

Faza 1: ingestia / indeksowanie (offline)

Ścieżka ingestii to praca przygotowawcza, która z góry przesądza o jakości i opóźnieniach późniejszego działania systemu. Składa się z czterech lub pięciu kroków:

1. Loading / konektory. Źródła takie jak SharePoint, S3, Confluence czy baza danych są podłączane przez konektory. Już na tym etapie dla każdego dokumentu rejestruje się stabilne identyfikatory i metadane (źródło, znacznik czasu, klient, uprawnienia dostępu).

2. Parsowanie. Surowe dokumenty, przede wszystkim pliki PDF i umowy, są przekształcane w ustrukturyzowany tekst. Parsery uwzględniające układ dokumentu (layout-aware) zachowują strukturę tabel, list i nagłówków, co później zapobiega halucynacjom. Narzędzia do tego to m.in. Docling (IBM, open source), Unstructured.io, LlamaParse czy Azure Document Intelligence.

3. Chunking. Tekst jest dzielony na jednostki, które można wyszukiwać. Naiwny chunking o stałym rozmiarze (np. 512 tokenów, overlap 50) jest prosty, ale rozcina zdania i tabele. Lepszy jest chunking rekurencyjny/semantyczny (cięcie przy dryfie podobieństwa cosinusowego między zdaniami) lub hierarchiczny chunking parent-child (małe chunki do wyszukiwania, duże chunki nadrzędne jako kontekst). Zasada ogólna: od 200 do 800 tokenów, 10–20% overlapu.

4. Embedding. Każdy chunk jest zamieniany na wektor przez model embeddingowy. W przypadku korpusów niemieckojęzycznych dominują modele wielojęzyczne, takie jak Cohere Embed v4, modele Voyage, Gemini Embedding 2 czy BGE-M3. Suwerennie można korzystać przede wszystkim z modeli open-weight, takich jak BGE-M3 lub Jina Embeddings, on-premise albo u europejskiego dostawcy hostingu. Jina AI należy jednak od października 2025 roku do Elastic, a przed komercyjnym wdrożeniem musisz sprawdzić licencję danej wersji modelu. Mistral Embed pochodzi od paryskiego dostawcy Mistral AI. Aleph Alpha z Heidelbergu łączy się z kanadyjskim dostawcą Cohere. W momencie podpisania umowy we wrześniu 2026 roku wciąż brakowało zgody organów regulacyjnych. Ważne: niemiecki, zależnie od tokenizera, zużywa ok. 1,3–1,7 razy więcej tokenów niż angielski.

5. Indeksowanie / upsert. Wektory wraz z metadanymi są zapisywane w wektorowej bazie danych. Standardowym algorytmem indeksowania jest niemal wszędzie HNSW (Malkov & Yashunin 2016) z parametrami M, ef_construction i ef_search, które równoważą recall i szybkość. Opcjonalnie równolegle buduje się indeks BM25 do wyszukiwania hybrydowego, a na początku każdego chunka umieszcza się wygenerowany przez LLM nagłówek kontekstowy (Contextual Retrieval).

Faza 2: obsługa zapytań (online)

Ścieżka zapytania uruchamia się przy każdym pojedynczym zapytaniu użytkownika. Embedding zapytania, retrieval, filtrowanie i reranking zajmują łącznie orientacyjnie ok. 100–800 milisekund, zależnie od wielkości indeksu i rerankera. Opcjonalne przetwarzanie wstępne oparte na LLM, takie jak HyDE czy query rewriter, wymaga dodatkowego wywołania modelu. Końcowe generowanie przez LLM trwa zwykle od jednej do kilku sekund, w zależności od długości odpowiedzi. Poszczególne kroki:

1. Przetwarzanie wstępne zapytania (opcjonalnie). Query rewriter, HyDE lub decomposer przeformułowują złożone pytania albo rozbijają je na części. W systemach multi-tenant na tym etapie odbywa się dodatkowo AuthN/Z i rozpoznanie tenanta.

2. Embedding zapytania. Pytanie jest zamieniane na wektor tym samym modelem embeddingowym co chunki. Równolegle powstaje zapytanie BM25.

3. Retrieval / wyszukiwanie wektorowe. Wektorowa baza danych zwraca najbardziej podobne chunki (zwykle top_k = 50–100). W wyszukiwaniu hybrydowym wyszukiwanie gęste i rzadkie działają równolegle, a ich wyniki są scalane przez rank fusion (Reciprocal Rank Fusion).

4. Filtrowanie. Filtry metadanych (tenant_id, ACL, data) zawężają listę kandydatów. Dotyczy to także zgodności z przepisami: wytyczne DSK dotyczące systemów generatywnej AI wykorzystujących metodę RAG (październik 2025) wymieniają rozdzielenie danych klientów oraz koncepcję uprawnień i ról jako środki zapewniające poufność i ograniczenie celu.

5. Reranking. Cross-encoder (Cohere Rerank, BGE-Reranker, Jina Reranker) ocenia zapytanie i dokument łącznie i zawęża 50–100 kandydatów do najtrafniejszych top_k = 5–10. Cross-encodery są dokładniejsze, ale wolniejsze niż bi-encodery używane we wstępnym wyszukiwaniu, dlatego uruchamia się je dopiero po tanim etapie recall.

6. Składanie kontekstu & prompting. Ostateczne chunki są wstawiane wraz z odwołaniami do źródeł do szablonu promptu. Ważne fragmenty powinny znaleźć się na początku, aby uniknąć problemu lost in the middle.

7. Generowanie przez LLM. Model językowy tworzy odpowiedź, najlepiej z wymuszaniem cytowania źródeł (citation forcing) i następującym po nim guardrailem wierności (faithfulness), który sprawdza, czy odpowiedź znajduje potwierdzenie w źródłach.

Tabela: pipeline RAG według fazy, zadania i narzędzi

Przepływ danych opisany słowami

Dokument przechodzi offline przez loader, parser i chunker, zostaje zwektoryzowany przez model embeddingowy i trafia wraz z metadanymi jako rekord do wektorowej bazy danych. Gdy online pojawia się pytanie, jest ono zamieniane na embedding tym samym modelem, porównywane przez indeks HNSW ze wszystkimi wektorami chunków i daje wstępną selekcję. Filtry metadanych usuwają to, czego użytkownik nie powinien widzieć. Reranker zawęża wstępną selekcję do najlepszych wyników. Te są wstawiane do promptu wraz z odwołaniami do źródeł, LLM generuje na ich podstawie odpowiedź, a guardrail sprawdza wierność wobec źródła. Kluczowe: embedding przy ingestii i przy zapytaniu musi korzystać z tego samego modelu, inaczej wektory nie są porównywalne.

Konkretny przykład z liczbami

Bot wsparcia dla produktu SaaS indeksuje 50 000 dokumentów. Przy chunkingu semantycznym z ok. 500 tokenami na chunk powstaje ok. 300 000 wektorów. Według firmy Anthropic indeksowanie z Contextual Retrieval kosztuje ok. 1,02 dolara amerykańskiego za 1 milion tokenów dokumentów przy użyciu prompt cachingu (stan na wrzesień 2024). W działaniu każde zapytanie pobiera top_k = 50 kandydatów; reranker Cohere zawęża je do top_k = 5.

Ewaluacja Anthropic pokazuje wpływ poszczególnych komponentów na odsetek błędów wyszukiwania w top 20: bez optymalizacji wynosił on 5,7%. Same Contextual Embeddings obniżyły go do 3,7% (spadek o 35%), pełny Contextual Retrieval (embeddingi plus Contextual BM25) do 2,9% (spadek o 49%), a dodatkowy reranking do 1,9% (spadek o 67%). Zapytanie z hybrydowym wyszukiwaniem i rerankingiem mieści się pod względem opóźnienia w przedziale ok. 100–800 milisekund.

Pseudokod ścieżki zapytania:

```
q_vec = embed(query) # ten sam model co przy ingestii
dense = vdb.search(q_vec, top_k=50, filter={tenant_id})
sparse = bm25.search(query, top_k=50, filter={tenant_id})
cands = rrf_fuse(dense, sparse) # wyszukiwanie hybrydowe
top5 = rerank(query, cands)[:5] # Cross-Encoder
prompt = template(query, top5, cite=True)
answer = llm.generate(prompt)
assert faithfulness(answer, top5) > 0.8 # Guardrail
```

Częste błędy architektoniczne

• Naiwny chunking o stałym rozmiarze ignoruje granice zdań i tabel, co prowadzi do brakujących treści i halucynacji.
• Model embeddingowy niedopasowany do języka (embeddingi angielskie dla korpusu niemieckiego) niszczy recall przy zapytaniach po niemiecku.
• Brak rerankingu: wyniki są semantycznie podobne, ale nietrafne.
• Lost-in-the-chunks: bez nagłówka kontekstowego chunk w rodzaju „Wzrósł o 12%” nie wie, o czym mowa.
• Sama semantyka bez BM25: dokładne kody i identyfikatory nie zostają znalezione.
• Brak filtrów metadanych: brak ochrony multi-tenant i ACL; chunk klienta A może zostać pobrany dla klienta B.
• Zbyt duże top_k przekazywane do LLM: lost in the middle i wyższe koszty.
• Brak ewaluacji i cytowania źródeł: cicha regresja jakości i ryzyko braku zgodności z przepisami.
• Dryf embeddingów przy zmianie modelu: bez identyfikatora wersji i pełnej reindeksacji stare i nowe wektory są niekompatybilne.

Dla agencji i B2B

Dobrze zaprojektowana architektura RAG to pipeline z ingestią, wyszukiwaniem hybrydowym, rerankingiem, ewaluacją i koncepcją usuwania danych. Dla agencji wartość leży w strategii danych, chunkingu i rozdzieleniu danych klientów. Dla decydentów B2B w Europie liczy się dodatkowo suwerenność: Qdrant, Weaviate, Haystack i hosting w UE to dobra podstawa działania zgodnego z RODO. Blck Alpaca projektuje i prowadzi takie pipeline'y end-to-end, łącznie z ewaluacją RAGAS i pipeline'em usuwania danych zgodnym z wytycznymi DSK. Odezwij się do nas, jeśli chcesz, aby pilotażowy projekt AI stał się produkcyjnym, weryfikowalnym systemem wiedzy.