RAG: pamięć semantyczna dla agenta.

Co to jest RAG i po co

Retrieval Augmented Generation to architektura, w której LLM dostaje w prompcie fragmenty Twoich dokumentów (wybrane przez wyszukiwanie semantyczne) i odpowiada na pytanie, korzystając z tych fragmentów jako kontekstu. Schemat:

1. Embed wszystkich dokumentów (albo ich fragmentów) i zapisz wektory w bazie.
2. Gdy przychodzi pytanie, embed pytania i znajdź 3-7 najbardziej podobnych wektorów.
3. Doklej znalezione fragmenty do promptu.
4. LLM generuje odpowiedź z cytatami źródeł.

Różnica wobec prostego promptowania: LLM nie musi znać Twojej bazy danych od pamięci. Może obsługiwać 10 000 dokumentów dla każdego klienta osobno, bez fine-tuningu i bez pakowania wszystkiego do context window.

RAG vs fine-tuning vs prompt engineering

Trzy podejścia do uczynienia LLM "świadomym" Twoich danych:

• Prompt engineering: wtłaczasz wszystkie relewantne dane do promptu za każdym razem. Działa gdy dane są małe (poniżej 50 000 tokens) i rzadko się zmieniają. Nie skaluje się dla bazy 1000+ dokumentów.
• RAG: zapisujesz dane raz w vector store, wyszukujesz relewantne fragmenty dynamicznie. Działa dla baz do milionów dokumentów. Aktualizacja danych to re-embed zmienionych, reszta zostaje. 80 procent zastosowań biznesowych pasuje do RAG.
• Fine-tuning: trenujesz wariant modelu na swoich danych. Daje efekty dla specyficznego stylu pisania albo specyficznej domeny (medyczna terminologia), ale koszt setup'u i utrzymania jest wysoki. Rzadko rekomenduję jako pierwsze podejście.

Moja regułka: zacznij od prompt engineering, jak przestanie wystarczać, przejdź na RAG. Fine-tuning tylko gdy RAG nie daje rady, a masz dedicated budżet i osobę do utrzymania.

Produkcyjna architektura RAG

Pięć komponentów, które muszą współgrać:

• Document loader: skąd pobierasz dokumenty (Google Drive, SharePoint, Confluence, baza CRM). Typowo cron job z inkrementalnym sync, detekcja zmian (ETag, updated_at).
• Chunker: dzielenie dokumentów na fragmenty. Nie za duże (inaczej embedding traci ostrość), nie za małe (inaczej tracisz kontekst). Typowo 500-1500 tokens per chunk z overlap 100-200 tokens.
• Embedding model: zamienia tekst na wektor (liczbowa reprezentacja 768-3072 wymiarów). Używam textembedding-gecko z Vertex AI dla polskich tekstów (wielojęzyczny) albo all-mpnet-base-v2 dla self-hosted.
• Vector store: przechowuje wektory plus oryginalne chunki. Robię pgvector (postgres rozszerzenie) dla prostych wdrożeń, Vertex AI Vector Search dla dużych (miliony wektorów, potrzeba niskiej latencji).
• Retriever plus generator: przy pytaniu embed query, znajdź top-k chunks, doklej do promptu, LLM generuje. Cytaty w odpowiedzi linkują do oryginalnych dokumentów.

Strategia chunkingu (najczęściej źle zrobiona)

Chunking to moment, w którym większość RAG-ów się psuje. Trzy typowe strategie:

• Fixed-size chunks: dzielisz co 1000 tokens. Prosto, szybko, ale tniesz zdania i paragrafy w przypadkowych miejscach. OK dla testów, gorzej dla produkcji.
• Semantic chunks: dzielisz po nagłówkach, paragrafach, zdaniach. Używam langchain.text_splitter.RecursiveCharacterTextSplitter z hierarchią separators (\n\n, \n, ., ). Wyraźnie lepsze wyniki niż fixed-size.
• Document-aware chunking: dla PDF z tabelami, faktury, umowy, używam specjalistycznych parsers (Document AI od Vertex AI, llama_parse). Tabela zostaje jednym chunkiem, sekcja umowy zostaje jednym chunkiem. Droższe w setup'ie, ale jakość odpowiedzi znacząco rośnie.

Dla polskich tekstów zalecam testy długości chunka. Polski ma dłuższe zdania niż angielski, 1500 tokens często lepiej pasuje niż standardowe 1000. Zawsze weryfikuję empirycznie na test set pytań z expected answers.

Dlaczego Vertex AI

Cztery powody, dla których wybieram Vertex AI jako platformę do RAG u większości klientów:

• Region EU: europe-west4 (Holandia) albo europe-west3 (Frankfurt) dla RODO compliance. Dane klienta nie opuszczają UE.
• Private IP: Vertex AI integruje się z VPC klienta, workflow może odpytywać model z private subnet bez wystawiania się na publiczny internet.
• Workload Identity: autoryzacja przez GCP service accounts zamiast długoterminowych API keys. Audyt wszystkich wywołań centralnie w Cloud Logging.
• Spójny stack: embeddings, vector search, generowanie, wszystko u jednego dostawcy. Jedna umowa DPA, jeden SLA, jeden panel kosztów.

Dla klientów mocno związanych z AWS preferuję Bedrock, dla Azure OpenAI on Azure. Cross-cloud RAG (Vertex embedding plus AWS store) dodaje złożoność, ale jest możliwy jeśli klient ma dobre powody.

Ewaluacja RAG: jak mierzyć jakość

RAG ma trzy miejsca, gdzie jakość może się psuć, każde wymaga osobnego evala:

• Retrieval quality: czy top-k zwrócone chunki faktycznie zawierają odpowiedź. Mierzymy recall@k (procent pytań, dla których prawidłowa odpowiedź była w top-k) na test set.
• Generation quality: czy LLM poprawnie wykorzystał dostarczone chunki. Mierzymy manualnie (sample reviewed by human) albo przez LLM-judge (drugi model ocenia odpowiedź vs expected).
• End-to-end accuracy: czy finalna odpowiedź jest poprawna, niezależnie od źródła błędu. To metryka dla biznesu, ale maskuje, czy błąd był w retrieval czy w generation.

Test set: zbieram 30-100 realnych pytań z expected answers od klienta. Evaluacja raz na tydzień przez pierwsze 2 miesiące, potem raz w miesiącu. Alert gdy recall@5 spadnie o więcej niż 10 procent albo accuracy poniżej 80 procent.

Najczęstsze pytania

Co warto przeczytać obok