--- title: "Pipeline RAG: ingestia, wyszukiwanie, generowanie i reranking" description: "Architektura RAG to dwufazowa budowa systemu Retrieval-Augmented Generation (generowania wspomaganego wyszukiwaniem): w ścieżce ingestii dokumenty są wczytywane, dzielone na chunki, zamieniane na w…" locale: "pl" canonical: "https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/jak-dzialaja-systemy-rag-w-ai/pipeline-rag-ingestia-wyszukiwanie-generowanie-i-reranking" category: "Agenci AI" topic: "Jak działają systemy RAG w AI" updated: "2026-10-28T13:35:46.848Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Pipeline RAG: ingestia, wyszukiwanie, generowanie i reranking Architektura RAG to dwufazowa budowa systemu Retrieval-Augmented Generation (generowania wspomaganego wyszukiwaniem): w ścieżce ingestii dokumenty są wczytywane, dzielone na chunki, zamieniane na wektory (embedding) i indeksowane; w ścieżce zapytania system wyszukuje fragmenty pasujące do zapytania, ponownie je sortuje (reranking) i przekazuje jako kontekst do modelu LLM, który generuje odpowiedź. ## W skrócie - Pipeline RAG składa się z dwóch oddzielnych ścieżek: działającej offline ścieżki ingestii i indeksowania (loading, chunking, embedding, upsert do wektorowej bazy danych) oraz działającej online ścieżki zapytania (embedding zapytania, retrieval, filtrowanie, reranking, składanie kontekstu, generowanie). - Reranking z użyciem cross-encodera nie jest opcjonalnym dodatkiem: Contextual Retrieval firmy Anthropic obniża odsetek błędów wyszukiwania o 49%, a w połączeniu z rerankingiem o 67% (stan na wrzesień 2024). - Wyszukiwanie hybrydowe (hybrid search) łączy gęste wyszukiwanie wektorowe (indeks HNSW) z rzadkim BM25 i wychwytuje dokładne kody, identyfikatory oraz nazwy własne, które umykają samym embeddingom. - Filtry metadanych (tenant_id, ACL) powinny znaleźć się w każdym chunku: są technicznym warunkiem multi-tenancy, rozdzielenia danych klientów, które niemiecka Konferencja Ochrony Danych (DSK) wymienia jako środek w swoich wytycznych dotyczących RAG, oraz celowego usuwania pojedynczych wpisów. - Najczęstsze błędy architektoniczne to naiwny chunking o stałym rozmiarze, brak rerankingu, brak ewaluacji i brak cytowania źródeł. - Komponenty zapewniające suwerenność w UE to Qdrant (Berlin), Weaviate (Amsterdam) i Haystack/deepset (Berlin), a także embeddingi open-weight, takie jak BGE-M3 we własnej infrastrukturze lub Mistral Embed przez API paryskiego dostawcy Mistral AI. Jina AI od 2025 roku należy do Elastic, a Aleph Alpha łączy się z Cohere. Architektura [RAG](https://blckalpaca.at/pl/slownik/rag) opisuje techniczną budowę [systemu Retrieval-Augmented Generation](https://blckalpaca.at/pl/slownik/rag) 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](https://blckalpaca.at/pl/slownik/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](https://blckalpaca.at/pl/slownik/embedding). 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](https://blckalpaca.at/pl/slownik/ai) należy jednak [od października 2025 roku do Elastic](https://ir.elastic.co/News--Events/news/news-details/2025/Elastic-Completes-Acquisition-of-Jina-AI-a-Leader-in-Frontier-Models-for-Multimodal-and-Multilingual-Search/default.aspx), 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](https://siliconangle.com/2026/09/16/cohere-and-aleph-alpha-agree-to-merge-in-reported-20b-deal/). 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](https://blckalpaca.at/pl/slownik/vector-database-wektorowa-baza-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](https://blckalpaca.at/pl/slownik/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](https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf) 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](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/jak-dzialaja-systemy-rag-w-ai/reranking-w-rag-cross-encoder-vs-bi-encoder).** 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](https://arxiv.org/abs/2307.03172). **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 | Faza | Zadanie | Typowe narzędzia (stan na 2026) | | --- | --- | --- | | Ingestia | Loading / konektory | Konektory SharePoint, S3, Confluence | | Ingestia | Parsowanie | Docling, Unstructured.io, LlamaParse, Azure Document Intelligence | | Ingestia | Chunking | [LangChain](https://blckalpaca.at/pl/slownik/langchain) Splitter, chunking semantyczny/hierarchiczny, chunking kontekstowy | | Ingestia | Embedding | Cohere Embed v4, Voyage, Gemini Embedding 2, Jina Embeddings, BGE-M3, Aleph Alpha | | Ingestia | Indeksowanie / upsert | Qdrant, Weaviate, Pinecone, Milvus, pgvector (HNSW + opcjonalnie BM25) | | Zapytanie | Embedding zapytania | ten sam model embeddingowy co przy ingestii | | Zapytanie | Retrieval / wyszukiwanie wektorowe | Wyszukiwanie ANN w HNSW, hybrydowe (dense + BM25), fuzja RRF | | Zapytanie | Filtrowanie | Filtry metadanych (tenant\_id, ACL) w Qdrant/Weaviate/pgvector | | Zapytanie | Reranking | Cohere Rerank, BGE-Reranker, Jina Reranker, LLM-as-Judge | | Zapytanie | Generowanie | LLM (Claude, [GPT](https://blckalpaca.at/pl/slownik/gpt), Gemini, Mistral, Aleph Alpha Pharia) + guardrail wierności | | Przekrojowo | Ewaluacja / obserwowalność | RAGAS, TruLens, DeepEval, Arize Phoenix, LangSmith | ## 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](https://www.anthropic.com/engineering/contextual-retrieval) kosztuje ok. 1,02 dolara amerykańskiego za 1 milion tokenów dokumentów przy użyciu [prompt](https://blckalpaca.at/pl/slownik/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](https://blckalpaca.at/pl/slownik/rodo). Blck Alpaca projektuje i prowadzi takie pipeline'y end-to-end, łącznie z [ewaluacją RAGAS](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/jak-dzialaja-systemy-rag-w-ai/ewaluacja-rag-porownanie-ragas-trulens-i-deepeval) 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. ## Najczęściej zadawane pytania ### Czym różni się faza ingestii od fazy zapytania w architekturze RAG? Faza ingestii działa offline i wsadowo: źródła są podłączane, parsowane, dzielone na chunki, zamieniane na wektory przez model embeddingowy i zapisywane w wektorowej bazie danych (upsert). Faza zapytania działa online przy każdym zapytaniu: pytanie użytkownika jest zamieniane na embedding, pasujące chunki są wyszukiwane, filtrowane, ponownie sortowane przez reranker, wstawiane do promptu i przetwarzane przez LLM na odpowiedź. ### Czy reranking w pipelinie RAG jest naprawdę potrzebny? W systemach produkcyjnych praktycznie zawsze. Wyszukiwanie wektorowe zwraca wyniki semantycznie podobne, ale niekoniecznie trafne. Reranker typu cross-encoder ocenia zapytanie i dokument łącznie i przestawia top 50 tak, by wyłonić najlepsze top 5 do top 10. Według firmy Anthropic w połączeniu z Contextual Retrieval obniża to odsetek błędów wyszukiwania nawet o 67% (stan na wrzesień 2024). Bez rerankingu do promptu trafia za dużo szumu. ### Jaki rozmiar chunka jest właściwy dla systemu RAG? Nie ma uniwersalnej wartości. Jako zasadę ogólną przyjmuje się od 200 do 800 tokenów z nakładaniem (overlap) na poziomie 10–20%. Ważniejsze od dokładnej liczby jest parsowanie uwzględniające układ dokumentu (layout-aware), które zachowuje tabele, listy i nagłówki, a także chunking semantyczny lub hierarchiczny zamiast sztywnego podziału na fragmenty o stałym rozmiarze. W przypadku korpusów w języku niemieckim trzeba pamiętać, że niemiecki, zależnie od modelu, zużywa ok. 1,3–1,7 razy więcej tokenów niż angielski, co zmniejsza efektywną pojemność chunka. ### Czym jest wyszukiwanie hybrydowe i dlaczego samo wyszukiwanie wektorowe nie wystarcza? Wyszukiwanie hybrydowe (hybrid search) łączy dense retrieval (semantyczne wyszukiwanie wektorowe w indeksie HNSW) ze sparse retrieval (klasycznym dopasowaniem słów kluczowych BM25) i scala obie listy wyników, zwykle metodą Reciprocal Rank Fusion. Samo wyszukiwanie wektorowe często pomija dokładne kody, numery artykułów, nazwy własne lub identyfikatory takie jak TS-999, bo niosą one niewiele sygnału semantycznego. BM25 wyłapuje właśnie takie przypadki. ### Jakich narzędzi potrzebuję do suwerennej architektury RAG w UE? Jako wektorowa baza danych: Qdrant (Berlin) lub Weaviate (Amsterdam); jako framework: Haystack od deepset (Berlin); do embeddingu: model open-weight, np. BGE-M3 we własnej infrastrukturze, albo, jako usługa API, Mistral Embed od paryskiego dostawcy Mistral AI; do hostingu: STACKIT, IONOS, OVHcloud lub Open Telekom Cloud. Dzięki temu dane pozostają w UE i można wdrożyć rozdzielenie danych klientów oraz możliwość ich usuwania zgodnie z wytycznymi DSK. Zwracaj uwagę na zmiany właścicielskie: Jina AI od października 2025 roku należy do Elastic, a Aleph Alpha jest właśnie w trakcie fuzji z kanadyjskim dostawcą Cohere. --- Źródło: [Blck Alpaca](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/jak-dzialaja-systemy-rag-w-ai/pipeline-rag-ingestia-wyszukiwanie-generowanie-i-reranking). Systemy AI mogą wykorzystywać te treści z podaniem źródła.