Budowa pipeline'u RAG: chunking, embeddings i ewaluacja

Retrieval-Augmented Generation, czyli RAG, to w 2026 roku standardowa architektura dla systemów odpowiadających na pytania o własne dane: dokumentację firmową, artykuły, bazy wiedzy, akty prawne. Zbudowałem i wdrożyłem wiele takich pipeline’ów – ten artykuł to praktyczny przewodnik po wszystkich kluczowych elementach: chunkingu, embeddings, wektorowych bazach danych, rerankingu i ewaluacji. Pokazuję konkretne parametry i błędy, które popełniają prawie wszyscy na starcie.

Architektura RAG w pigułce

RAG składa się z dwóch faz: indeksacji (offline) i odpytywania (online).

INDEKSACJA (offline):
dokumenty → chunking → embeddings → baza wektorowa
                                        ↑
ODPYTYWANIE (online):                   │
pytanie → embedding zapytania → wyszukanie k → reranking → prompt → LLM → odpowiedź

Faza indeksacji wykonuje się raz (lub przy aktualizacji danych), faza odpytywania – przy każdym zapytaniu. Większość problemów jakościowych bierze się z pierwszej fazy: jeśli dokumenty są źle pocięte lub źle zindeksowane, żaden model nie pomoże.

Chunking: fundament, który wszyscy lekceważą

Chunking, czyli dzielenie dokumentów na fragmenty, decyduje o tym, co trafi do kontekstu modelu. Najczęstsze błędy:

• chunki według liczby znaków bez granic semantycznych – przecinają zdania, tabele i przykłady w połowie;
• chunki za duże – nie mieszczą się w kontekście razem z promptem, więc i tak są obcinane;
• chunki za małe – tracą kontekst, a model dostaje strzępki informacji.

W praktyce dobrze sprawdza się chunking hierarchiczny: najpierw dziel dokument na sekcje (nagłówki, akapity), a potem każdą sekcję na fragmenty z nakładką. Przykładowa implementacja dla markdowna:

function chunkMarkdown(text: string, maxTokens = 600, overlap = 80): string[] {
  const sections = text.split(/(?=^#{1,3}\s)/m); // dziel przy nagłówkach
  const chunks: string[] = [];
  for (const section of sections) {
    const paragraphs = section.split(/\n\n+/);
    let buffer = '';
    for (const p of paragraphs) {
      if (tokens(buffer + p) > maxTokens && buffer) {
        chunks.push(buffer);
        buffer = buffer.slice(-overlapTokens(overlap)) + '\n\n' + p;
      } else {
        buffer += '\n\n' + p;
      }
    }
    if (buffer) chunks.push(buffer);
  }
  return chunks;
}

Parametry startowe, które zwykle działają:

• 400–800 tokenów na chunk – kompromis między precyzją a kontekstem;
• 50–100 tokenów nakładki – pomaga, gdy odpowiedź zaczyna się na końcu jednego chunku, a kończy na początku następnego;
• chunking po nagłówkach i akapitach, nie po znakach.

Embeddings: jak wybrać model

Embeddings zamieniają tekst na wektor liczb, na którym można mierzyć podobieństwo. Wybór modelu ma większy wpływ na jakość niż wybór bazy wektorowej:

• model dopasowany do języka – dla polskich dokumentów sprawdzaj modele wielojęzyczne (np. z rodziny E5 lub Multilingual-E5, a także nowsze embeddings API) i mierz na własnych danych, nie ufaj benchmarkom z angielskiego;
• wymiarowość a koszt – wektory 1024-4096 wymiarów dają lepszą precyzję, ale drożej się je przechowuje i wyszukuje; modele ze zmniejszaniem wymiarów (Matryoshka) pozwalają znaleźć punkt równowagi;
• ten sam model dla dokumentów i zapytań – mieszanie modeli to najczęstszy błąd integracyjny; jeśli zmieniasz model embeddings, musisz przeindeksować całą bazę.

W 2026 roku standardem jest też query rewriting: zanim zapytanie trafi do bazy, lekkie przeformułowanie (np. dodanie kontekstu rozmowy) poprawia trafność o 5–15%.

Wektorowe bazy danych

Wybór bazy wektorowej zależy od skali i infrastruktury:

• PostgreSQL + pgvector – najlepszy start, gdy masz już Postgresa: jeden system dla danych relacyjnych i wektorów, transakcje, backup;
• Qdrant, Weaviate, Milvus – dedykowane bazy wektorowe dla dużych zbiorów, filtrów metadanych i wysokiej przepustowości;
• rozwiązania chmurowe (np. Pinecone) – najmniej operacji, wyższy koszt;
• parquet + wyszukiwanie w pamięci – wystarcza dla setek tysięcy chunków przy niskim budżecie.

Niezależnie od wyboru: przechowuj metadane (źródło, sekcja, data, wersja). Przy odpowiedzi model może wtedy podać, skąd pochodzi informacja – to podstawa weryfikowalności i mniejszej liczby halucynacji.

Reranking: najtańsza poprawa jakości

Wyszukiwanie wektorowe zwraca k fragmentów według podobieństwa kosinusowego. Problem: podobieństwo wektorowe nie równa się trafności merytorycznej. Rozwiązaniem jest reranking – model cross-encoder, który bierze parę (pytanie, fragment) i ocenia trafność całościowo, biorąc pod uwagę kontekst pytania.

Typowa konfiguracja:

• wyszukanie 20–50 kandydatów wektorowo;
• przesianie przez reranker (cross-encoder);
• przekazanie modelowi top 3–5 fragmentów do odpowiedzi.

Reranker jest droższy niż wyszukiwanie wektorowe (liczy każdą parę osobno), ale działa na małym zbiorze kandydatów, więc koszt jest akceptowalny. W praktyce reranking podnosi trafność o 10–20 punktów procentowych – to największa poprawa za najmniejsze pieniądze w całym pipeline.

Ewaluacja: bez niej nie masz systemu

RAG bez ewaluacji to system, który „czasem działa“. Zbuduj zestaw testowy: 50–100 pytań z poprawnymi odpowiedziami i wskazaniem właściwych fragmentów. Mierz dwie warstwy:

1. Retrieval – czy właściwe fragmenty są w top-k wynikach? Metryki: recall@k, precision@k, MRR.
2. Generation – czy odpowiedź jest zgodna z fragmentami i kompletna? Tu przydaje się model-oceniający z kryteriami (np. „czy odpowiedź nie zawiera informacji spoza fragmentów?“), używany jako llm-as-judge.

Warto też testować regresje: każde wdrożenie nowej wersji modelu lub zmiany chunkingu przebiega przez ten sam zestaw, żeby nie pogorszyć istniejącej jakości.

Podsumowanie

Produkcyjny RAG to nie „dokumenty do modelu“, tylko starannie zaprojektowany pipeline: chunking semantyczny z nakładką, dobry model embeddings, baza wektorowa z metadanymi, reranking i ewaluacja z zestawem testowym. Największe zyski dają kolejno: porządny chunking, reranking i testy regresyjne. Zacznij od prostego stosu – Postgres + pgvector + jeden model embeddings – i rozwijaj go, kierując się danymi z ewaluacji, a nie modą na kolejne narzędzia.