RAG dla firm – vector stores, embeddings i koszty w produkcji (2026)

RAG (Retrieval-Augmented Generation) to wzorzec architektoniczny, w którym LLM otrzymuje kontekst z zewnętrznej bazy wiedzy PRZY KAŻDYM zapytaniu, zamiast trenowania na waszych danych raz na zawsze (fine-tuning). Schemat: user query → embedding query → retrieval relevantnych dokumentów z vector DB → injection do prompt → LLM generuje odpowiedź z kontekstem.

Dlaczego dominuje w 2026: (1) aktualne dane bez retreningu modelu — nowy dokument w bazie wiedzy jest dostępny natychmiast; (2) audytowalność — wiecie z których dokumentów pochodzi odpowiedź (compliance + AI Act); (3) tańsze niż fine-tuning — typowy RAG to 50-500 tys. zł vs fine-tuning 500 tys. – 2 mln zł; (4) wymienialne modele — same dane zostają, model można zmieniać.

Kiedy RAG NIE jest najlepszym wyborem: gdy macie bardzo wyspecjalizowany domain language (medyczny, prawniczy, finansowy ekstremalnie specyficzny) który wymaga 'wbudowania' w model — wtedy fine-tuning może być lepszy. Gdy macie bardzo małą bazę wiedzy (poniżej 1000 dokumentów) — wtedy long-context prompting może wystarczyć bez infrastruktury RAG.

Architektura RAG ma 6 warstw: (1) Ingestion pipeline — dokumenty wchodzą do systemu (PDF, Word, web, API); (2) Chunking — dokumenty są dzielone na chunki o określonym rozmiarze; (3) Embedding generation — każdy chunk dostaje wektor numeryczny; (4) Vector storage — wektory zapisane w vector DB z metadata; (5) Query pipeline — query usera embedded, retrieval, ranking; (6) LLM generation — kontekst + query → LLM → odpowiedź.

Każda warstwa ma własne wybory techniczne i typowe błędy. Najczęściej organizacje uczą się na własnych błędach po 3-6 miesiącach produkcji. Niżej pokazujemy które wybory są krytyczne.

Pełen production stack 2026: LangChain lub LlamaIndex jako framework, Pinecone/Weaviate/pgvector jako vector DB, OpenAI text-embedding-3-large lub Cohere embed-v4 jako embedder, GPT-4o lub Claude 3.7 jako generator. LangSmith dla observability. Wszystko ostatnie 2 lata znacznie się ustabilizowało.

Chunking to dzielenie długich dokumentów na mniejsze fragmenty, które trafiają do vector DB jako osobne wpisy. Wydaje się trywialne — w praktyce 60% problemów jakości RAG pochodzi z złego chunkingu.

Trzy główne strategie: (1) Fixed-size chunking — najprostsze, dzieli co 500-1500 tokens. Działa źle dla strukturyzowanych dokumentów (faktury, umowy). (2) Semantic chunking — dzieli na granicach sensu (nagłówki, paragrafy). Lepsze dla naturalnego języka. (3) Document-structure aware — używa struktury dokumentu (sekcje, tabele). Wymagane dla dokumentów technicznych.

Praktyczna rekomendacja: zacznijcie od recursive text splitter z chunk_size=800-1200 tokens, overlap=100-200 tokens. To działa dla 70% scenariuszy. Dla strukturyzowanych dokumentów (compliance, finanse) — semantic lub structure-aware. Investujcie w evaluation, żeby zmierzyć efekt chunkingu na jakość.

Najgorętszy decyzyjny w architekturze RAG. Cztery opcje dominują w 2026: Pinecone (managed SaaS), Weaviate (open-source + cloud), pgvector (PostgreSQL extension), Azure AI Search.

Pinecone wygrywa dla MVP i małej skali — najprostszy setup, dobre API, świetny developer experience. Cena rośnie szybko: dla 5M embeddings to ~1500-2500 USD/m-c (zależnie od pod tier). Powyżej tej skali nieefektywny ekonomicznie.

Weaviate self-hosted wygrywa dla średniej skali — pełna kontrola, niskie koszty operacyjne (głównie hosting GPU/CPU), pełne hybrid search out-of-the-box. Wymaga DevOps capacity. Typowe TCO dla 50M embeddings: 1000-2500 USD/m-c.

pgvector wygrywa, gdy macie już PostgreSQL — najprostsza operational story (jedna baza, jeden backup, jeden monitoring). Performance lepsze niż się wydaje (do 50M wektorów działa świetnie). Nie ma wszystkich features Pinecone/Weaviate, ale dla większości use case'ów wystarczy.

Azure AI Search wygrywa dla Microsoft ecosystem — natywne integracje z Azure OpenAI, Microsoft Entra ID, SharePoint connectorami. Premium pricing, ale zwykle organizacje już mają Azure subscription.

Czysty vector search ma słabość: nie rozumie exact match. Pytanie 'Co napisano w polityce o KSeF' znajdzie chunki o e-fakturach (semantically similar) ale może pominąć dokument który dosłownie ma 'KSeF' w nagłówku.

Hybrid retrieval kombinuje vector search (semantic) z BM25 (keyword). Każdy zwraca top-K, system łączy wyniki i reranking. Typowy gain: 15-30% improvement na recall@10 dla domain-specific zapytań.

W praktyce 2026: hybrid retrieval standard, nie opcja. Weaviate i Pinecone mają hybrid out-of-box. Dla pgvector trzeba implementować osobno, ale to ~50 linii kodu. Plus Cohere Rerank jako finalna warstwa (cost ~2 USD per 1M tokens) podnosi quality jeszcze o 10-15%.

Embeddings są często niedoszacowanym kosztem RAG. OpenAI text-embedding-3-large cost ~0.13 USD per 1M tokens. Dla 1M dokumentów × średnio 500 tokens każdy = 500M tokens = ~65 USD JEDNORAZOWO. Brzmi tanio.

Ale: każda zmiana embedder modelu = regeneracja całej bazy. Zmienienie z OpenAI v3 large na Cohere embed-v4 dla 50M dokumentów = ~3,250 USD jednorazowo plus engineering time. Praktycznie zostajecie z wybranym modelem przez 1-2 lata.

Drugi koszt: query-time embeddings. Każde user query embedded. Przy 10k queries/dzień × 30 tokens query = 300k tokens/dzień = ~12 USD/m-c. Skalibruje proporcjonalnie do skali.

RAG bez evaluation to flying blind. Trzy kluczowe wymiary do mierzenia: (1) Retrieval quality — czy retrieved chunki są relevant; (2) Answer quality — czy generated odpowiedź jest poprawna; (3) Faithfulness — czy odpowiedź jest oparta na retrieved kontekście (nie halucynowała).

Praktyczny stack: RAGAS (open-source evaluation framework), LangSmith (production observability), własny test set 100-500 pytań z gold standard answers. Cykl: zmiana w systemie → re-run evaluation → comparison z baseline → decision.

Production monitoring: każda response logowana z (query, retrieved chunks, answer, user feedback). LLM-as-a-judge dla automatycznej oceny faithfulness. Human review 5-10% odpowiedzi dla validation. Bez tych metryk nie zoptymalizujecie quality.