RAG (Retrieval‑Augmented Generation): wzbogacanie modeli o zewnętrzną wiedzę

Retrieval‑Augmented Generation (RAG) to podejście łączące generatywne modele językowe z modułem wyszukiwania w zewnętrznych repozytoriach wiedzy. Zamiast polegać wyłącznie na parametrycznej pamięci modelu, RAG dociąga aktualne, kontekstowe dane i włącza je do procesu generacji. Dzięki temu systemy są bardziej aktualne, wiarygodne i lepiej kontrolowalne z punktu widzenia źródeł.

Klucz do skutecznego RAG leży w poprawnym przygotowaniu korpusu, jakości embeddings, doborze bazy wektorowej i precyzyjnym sterowaniu łańcuchem zapytań. Poniżej omówiono architekturę, fundamenty wektorowe, implementację z lokalnymi modelami oraz studium przypadku chatbota dla dokumentów firmowych.

Architektura systemów RAG

Typowy system RAG składa się z kilku warstw, które tworzą przepływ od danych surowych do odpowiedzi końcowej:

• Ingest: pozyskanie dokumentów (PDF, HTML, DOCX, e‑maile, bazy wiedzy). Normalizacja, czyszczenie, optyczne rozpoznawanie znaków (OCR) dla skanów i ekstrakcja metadanych.
• Chunking: dzielenie dokumentów na segmenty (np. – tokenów) z nadkładką kontekstową (overlap), aby zachować spójność semantyczną.
• Embedding: przekształcanie segmentów i zapytań użytkownika w wektory w przestrzeni semantycznej. Kluczowe są jakość modelu embeddingów i zgodność językowa/branżowa.
• Indeks wektorowy: baza do szybkiego wyszukiwania podobieństwa (ANN – Approximate Nearest Neighbors). Wspiera filtrowanie po metadanych (np. dziale, dacie, wersji dokumentu).
• Retriever: strategia wyszukiwania: top‑k, MMR (Maximal Marginal Relevance), hybrydowe (słowa kluczowe + wektorowe), re‑ranking z cross‑encoderem.
• Augmentacja promptu: łączenie zapytania z kontekstem (najlepszymi fragmentami), zasadami cytowania i instrukcjami, jak model ma korzystać z materiałów.
• Generator (LLM): model językowy generuje odpowiedź na podstawie promptu z kontekstem. Może być wzmocniony narzędziami (Toolformer/Function Calling) do dodatkowych akcji.
• Post‑processing: cytowanie źródeł, walidacja typów odpowiedzi, redakcja, podsumowanie, wykrywanie halucynacji (np. regułami lub klasyfikatorem).
• Observability: logi zapytań, embeddingów i trafień; śledzenie jakości (latencja, precision@k, faithfulness), audyt źródeł.

W praktyce architektura bywa warstwowa: pipeline ingestujący (batch/stream), warstwa wyszukiwania (API do retrieva), warstwa LLM (lokalna lub chmurowa) oraz gateway z politykami i cache’ami. Ważna jest idempotencja przetwarzania, wersjonowanie indeksów oraz polityka TTL dla dokumentów dynamicznych.

Vector databases i embeddings

Embeddings kodują tekst w wektory, tak aby semantycznie podobne fragmenty były blisko siebie. Wybór modelu embeddingów ma krytyczne znaczenie dla jakości retrieva:

• Język i domena: dla polskiego i kontekstów wielojęzycznych sprawdzają się modele wielojęzyczne lub dedykowane PL; w domenach technicznych lepiej radzą sobie modele uczone na dokumentacji/FAQ.
• Rozmiar wektora: – wymiarów to typowy zakres; większe wektory poprawiają rozróżnialność, ale podnoszą koszty pamięci i wyszukiwania.
• Normalizacja: L‑norm, centrowanie i ewentualna redukcja wymiarów (PCA) mogą poprawić szybkość i stabilność metryk podobieństwa.
• Negative mining i hard negatives: przy własnym trenowaniu lub dostrajaniu (fine‑tune) zwiększają precyzję retrieva w “trudnych” przypadkach.

Bazy wektorowe oferują indeksy ANN (np. HNSW, IVF, PQ) i filtrację metadanych. Typowe opcje:

• FAISS (biblioteka C++/Python): szybkie indeksy na własnej infrastrukturze; wymaga opakowania w serwis i samodzielnego zarządzania.
• Qdrant i Milvus: otwarte silniki baz wektorowych z API, replikacją i filtrowaniem; dobre do środowisk produkcyjnych on‑prem.
• Weaviate: wektorowa baza z bogatym ekosystemem pluginów; wsparcie hybrydowych zapytań.
• Elasticsearch/OpenSearch: hybrydowe podejście – BM25 + wektorowe; dobre do scenariuszy, gdzie keywordy i filtry są równie ważne jak semantyka.

Metryki podobieństwa dobiera się do charakteru wektorów. Dla znormalizowanych embeddingów popularna jest kosinusowa; dla nieznormalizowanych – L. W hybrydach łączy się scoring BM25 i kosinusowy (np. late fusion lub uczenie wag).

Strategie retrieva wpływają na jakość kontekstu:

• Top‑k: najprostsze; ryzyko powtarzalności lub wąskiego kontekstu.
• MMR: równowaga między trafnością a różnorodnością, ogranicza redundancję.
• Re‑ranking: cross‑encodery (np. modele bi‑encoder + cross‑encoder) precyzyjnie porządkują top‑N kandydatów kosztem większej latencji.
• Hybrydowe: łączą keywordy (BM25) z semantyką; skuteczne, gdy zapytania zawierają terminy właściwe (np. symbole, kody, nazwy własne).

Implementacja z lokalnymi modelami

Wykorzystanie lokalnych LLM i embeddingów zwiększa kontrolę nad danymi i kosztami, ale wymaga odpowiedniej inżynierii:

• Wybór modelu: mniejsze modele (‑B–‑B) działają na pojedynczych GPU klasy konsumenckiej z quantization (np. ‑bit), większe (‑B–‑B) wymagają wielogPU lub CPU z dużą pamięcią. Dla polskiego – modele wielojęzyczne lub fine‑tuning na korpusie PL.
• Quantization i optymalizacje: GGUF/GGML dla CPU, AWQ/GPTQ dla GPU; low‑rank adapters (LoRA) dla dostrajania w domenie. Dla inference: paged attention, KV‑cache, batchowanie zapytań.
• Pipeline: lokalny serwis embeddingów (np. sentence‑transformers), serwis retrieva (Qdrant/Milvus), LLM server (llama.cpp, vLLM, text‑generation‑inference). Koordynacja przez warstwę aplikacyjną (Python/Go/Node).
• Bezpieczeństwo i prywatność: pełny on‑prem (dane nie opuszczają sieci), kontrola dostępu per dokument (ACLS), szyfrowanie w spoczynku i w tranzycie.
• Monitorowanie: metryki jakości (hit rate, precision@k), kosztów (GPU hours), latencji (p‑p), awaryjności indeksów i driftu danych.

Przykładowy przepływ implementacyjny:

• Ingest dokumentów do kolejki (np. Kafka) i pipeline’u ekstrakcji + chunkingu.
• Generowanie embeddingów i zapis do bazy wektorowej z metadanymi (tytuł, dział, wersja, uprawnienia).
• Endpoint /search zwraca top‑N fragmentów; endpoint /chat zestawia prompt (instrukcje, kontekst, żądanie cytatów) i deleguje do LLM.
• Walidator odpowiedzi sprawdza obecność cytowań i zgodność z polityką; logi trafiają do systemu obserwowalności.

Najważniejsze praktyki – jakość i niezawodność

Jakość RAG zależy od wielu “gałek” konfiguracyjnych. Najistotniejsze praktyki:

• Dobry chunking: zbyt krótkie fragmenty gubią kontekst, zbyt długie zwiększają szum; warto testować rozmiar i overlap per typ dokumentu.
• Konsekwentne metadane: precyzyjne tagowanie działów, wersji, języka, typów dokumentów umożliwia skuteczne filtrowanie i polityki dostępu.
• Hybrydowy retrieve: łączenie BM25 i wektorów często podnosi recall, zwłaszcza przy żargonie branżowym.
• Re‑ranking: gdy top‑k zwraca treści bliskie, ale nieoptymalne, cross‑encoder zauważalnie poprawia trafność kosztem ms.
• Kontrola halucynacji: wymuś cytaty i “odpowiadaj tylko na podstawie dostarczonego kontekstu”; jeśli brak kontekstu – komunikat o braku danych i propozycja źródeł.
• Aktualność: automatyczny re‑ingest przy zmianach plików, TTL i wersjonowanie indeksu; diff‑ing zamiast pełnych przebudów.
• Testy offline: zbiór golden‑set zapytań z oczekiwanymi odpowiedziami i metrykami (exact match, faithfulness, helpfulness); porównanie różnych konfiguracji retrieva.

Case study: chatbot z dokumentami firmy

Cel: chatbot dla działów sprzedaży i wsparcia, odpowiadający na pytania o produkty, procedury i umowy, z pełnym on‑prem i kontrolą dostępu.

Dane wejściowe: PDF (specyfikacje), Confluence/Markdown (procedury), e‑maile (FAQ), arkusze Excel (cenniki), bazy biletów (Jira/ServiceNow). Wrażliwe pola (np. dane klientów) podlegają maskowaniu przy ingest.

Ingest i normalizacja:

• OCR dla skanów, ekstrakcja tabel (np. z PDF), konwersja do HTML/Markdown dla lepszej segmentacji.
• Chunking: – tokenów, overlap –; osobno dla tabel (wydzielone segmenty z nagłówkami kolumn i jednostkami).
• Metadane: dział, właściciel dokumentu, wersja, data, poziom jawności, język, typ (specyfikacja/polityka/FAQ).

Embeddings i indeks:

• Model wielojęzyczny dopasowany do polskiego i angielskiego.
• Qdrant/Milvus jako baza wektorowa z filtrowaniem metadanych i replikacją HA.
• Hybrydowy retrieve: BM25 przez OpenSearch + wektorowy; late fusion score z wagą regulowaną w testach A/B.

Warstwa LLM:

• Lokalny model ‑B z quantization ‑bit na GPU serwerowym; dla zapytań długich – możliwość offloadu na CPU.
• Instrukcje systemowe: ograniczenie do kontekstu, obowiązkowe cytaty z identyfikatorami dokumentów i numerami sekcji.
• Szablony promptów per persona (sprzedaż/wsparcie/prawny) różnicujące ton i zakres odpowiedzi.

Bezpieczeństwo i uprawnienia:

• ACL na poziomie segmentów; retriever filtruje po metadanych zgodnie z tożsamością użytkownika (OIDC/LDAP).
• Szyfrowanie danych w spoczynku, TLS w tranzycie, audyt dostępu, logi tylko z hashami treści.
• Maskowanie PII podczas indeksacji; opcjonalne “unmask on display” dla uprawnionych użytkowników.

Obsługa zapytania (runtime):

• Normalizacja zapytania (język, wykrywanie intencji, ewentualny rewrite).
• Retrieve top‑ (np. ––) + re‑ranking do top‑.
• Budowa promptu: instrukcje, kontekst (fragmenty z cytowaniem), prośba o precyzyjne odpowiedzi i wskazanie niepewności.
• Generacja i post‑processing: weryfikacja cytatów, skrócenie i formatowanie, detekcja halucynacji (jeśli brak cytatu – odpowiedź odmowna).

Metryki i jakość:

• Precision@k i Recall@k na golden‑secie pytań firmowych.
• Faithfulness (zgodność ze źródłami) oceniana półautomatycznie: czy każde zdanie ma źródło?
• Latencja p‑p, współczynnik “no answer”, odsetek eskalacji do człowieka.
• A/B testy: wagi hybrydowego retrieva, skala chunku, wybór cross‑encodera.

Rezultaty: skrócenie czasu odpowiedzi na zapytania klientów, w pilotażu, spadek liczby błędnych odpowiedzi dzięki restrykcyjnym cytatom i re‑rankerowi. Wdrożenie on‑prem zniosło bariery prawne związane z danymi wrażliwymi. Dalsze usprawnienia obejmują automatyczną ekstrakcję encji do lepszego filtrowania oraz funkcje akcyjne (wyliczenia, generowanie ofert) uruchamiane z poziomu chatbota.

Warianty architektoniczne RAG

W zależności od potrzeb można zastosować różne warianty RAG:

• Na poziomie zdań vs. dokumentów: indeksowanie drobnoziarniste poprawia precyzję, ale wymaga lepszego łączenia kontekstu; dokumentowe – szybsze, mniej fragmentacji.
• Multi‑vector RAG: wiele reprezentacji tego samego fragmentu (np. treść, tytuł, streszczenie, słowa kluczowe) zwiększa szanse trafienia.
• Graph‑RAG: wzbogacenie o graf wiedzy (relacje między pojęciami); dobre dla compliance i nawigacji po złożonych domenach.
• Agentic RAG: model steruje dodatkowymi krokami: reformułuje zapytania, iteracyjnie dociąga kolejne fragmenty, sprawdza spójność.
• Programmatic RAG: włączenie narzędzi (funkcje, API) do wykonywania obliczeń i walidacji liczb zamiast czystej generacji tekstu.

Najczęstsze problemy i sposoby ich rozwiązania

• Niska trafność retrieva: poprawić jakość embeddingów (dopasowany model), zwiększyć k, dodać hybrydę BM25, wdrożyć re‑ranking, dostroić chunking.
• Halucynacje mimo kontekstu: rygorystyczne instrukcje “odpowiadaj tylko na podstawie kontekstu”, penalizacja fragmentów bez cytatów, reguły odrzucania odpowiedzi bez źródła.
• Latencja: cache embeddingów, wstępne obliczanie streszczeń, szybsze indeksy (HNSW), batching zapytań, krótsze konteksty, quantization LLM.
• Drift danych: mechanizmy incremental update indeksu, alerty przy zmianach źródeł, wersjonowanie i roll‑back indeksów.
• Kontrola dostępu: filtrowanie po metadanych w retrieverze, rzutowanie uprawnień na segmenty, testy penetracyjne ścieżek bocznych.

Praktyczne zastosowania

RAG jest szczególnie efektywny tam, gdzie wiedza szybko się zmienia lub jest rozproszona:

• Wsparcie klienta: odpowiedzi z aktualnych baz wiedzy, zmian w produktach, statusów SLA; integracja z ticketingiem i CRM.
• Compliance i prawo: przytaczanie polityk i paragrafów z cytowaniem; śledzenie wersji dokumentów i interpretacji.
• Inżynieria i DevOps: wyszukiwanie w logach, runbookach, post‑mortemach; szybkie diagnozowanie incydentów z odniesieniami do źródeł.
• Sprzedaż i presales: generowanie odpowiedzi RFP na podstawie referencji i kart produktowych z kontrolą spójności i cytatami.
• Finanse i analizy: streszczenia raportów rynkowych, porównania metryk z wyliczeniami w narzędziach; unikanie halucynacji dzięki programmatic RAG.

Wskazówki wdrożeniowe – od POC do produkcji

• Zacznij od precyzyjnego celu: pytań reprezentatywnych, jasne metryki i próg sukcesu (np. faithfulness ≥ , na golden‑secie).
• Iteruj na retrieverze: testuj różne embeddingi, rozmiary chunków, hybrydę i re‑ranking; wczesny zysk jakości zwykle pochodzi właśnie stamtąd.
• Standardyzuj metadane: bez spójnych tagów filtracja i kontrola dostępu będą zawodne.
• Zapewnij observability: śledzenie pełnej ścieżki (query → wyniki retrieva → kontekst → output) i audyt cytatów to podstawa utrzymania.
• Planuj koszty: lokalne LLM obniżają koszty jednostkowe, ale wymagają inwestycji w sprzęt i utrzymanie; chmura daje elastyczność kosztem opłat.
• Bezpieczeństwo by design: wąskie uprawnienia, szyfrowanie, maskowanie PII, testy wycieku danych na poziomie promptów i logów.

Przykładowa tabela: decyzje techniczne w RAG

Podsumowanie

RAG w praktyce zmienia sposób budowy asystentów i aplikacji wiedzo‑intensywnych: zamiast “większego modelu” liczy się “lepsze dane + lepszy retrieve”. Kluczowe decyzje obejmują dobór embeddings (język/domena), strategii retrieva (hybryda + re‑ranking), architekturę bazy wektorowej oraz dyscyplinę w metadanych i bezpieczeństwie. Wdrożenia on‑prem z lokalnymi modelami są realne i dojrzałe, przy odpowiednim pipeline’ie i observability dają przewidywalność, zgodność z regulacjami i mierzalne oszczędności czasu zespołów. Case study chatbota firmowego pokazuje, że największy zysk pochodzi z jakości ingestu, metadanych i re‑rankingu oraz z egzekwowania cytatów.

Źródła

• Dense Passage Retrieval for Open-Domain Question Answering
• Real-Time Open-Domain Question Answering with Dense-Sparse Phrase Index
• ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction
• Qdrant: Vector Database
• Milvus: Open-Source Vector Database
• Weaviate: Vector Database
• FAISS: A library for efficient similarity search
• Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks
• BERT: Pre-training of Deep Bidirectional Transformers
• OpenSearch: Hybrid search and vector capabilities