RAG — jak zbudować AI, które mniej zmyśla odpowiedzi (2026)

Słyszę to regularnie. I za każdym razem odpowiedź jest ta sama: potrzebujesz RAG.

RAG — Retrieval-Augmented Generation — to architektura, która sprawia, że AI odpowiada na podstawie Twoich dokumentów, a nie tego, co "pamięta" z treningu. Zamiast hallucynować, szuka odpowiedzi w Twojej bazie wiedzy.

I nie, nie jest to rocket science. Pokażę Ci jak to zbudować.

{% youtube "AGmEtnYE9bQ" %}

Dlaczego LLM hallucynuje?

Żeby zrozumieć RAG, trzeba zrozumieć problem.

Duże modele językowe (GPT-4, Claude, Gemini) mają ogromną wiedzę z treningu, ale:

• Nie znają Twoich wewnętrznych dokumentów — regulaminów, procedur, oferty
• Mają zamrożoną wiedzę — nie wiedzą co się zmieniło wczoraj
• "Wymyślają" gdy nie wiedzą — brzmi pewnie, ale mówi nieprawdę

Dla firmy to katastrofa. Chatbot, który podaje klientowi złą cenę lub nieistniejącą procedurę, jest gorszy niż brak chatbota.

Jak działa RAG?

Idea jest prosta jak budowa cepa:

1. Wrzucasz swoje dokumenty (PDF-y, strony wiki, baza FAQ)
2. System dzieli je na fragmenty (chunking — kawałki po 300-500 słów)
3. Każdy fragment zamieniasz na wektor (embedding — numeryczna reprezentacja znaczenia)
4. Wektory lądują w bazie wektorowej (pgvector, Chroma, Pinecone)
5. Gdy przychodzi pytanie: szukasz najbardziej podobnych fragmentów
6. LLM dostaje pytanie + znalezione fragmenty i odpowiada na ich podstawie

Kluczowy moment: LLM nie zgaduje. Dostaje konkretne fragmenty dokumentów i na nich bazuje odpowiedź. Jeśli informacji nie ma w dokumentach — mówi "nie wiem" zamiast wymyślać.

Budujemy RAG krok po kroku

Krok 1: Przygotowanie dokumentów

Python
Kopiuj
1
2
3
4
5
6
7
8
9
10
11
12
13
14
from langchain.document_loaders import DirectoryLoader, PyPDFLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter

# Załaduj dokumenty
loader = DirectoryLoader("./docs", glob="**/*.pdf", loader_cls=PyPDFLoader)
documents = loader.load()

# Podziel na fragmenty
splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50,  # nakładka żeby nie tracić kontekstu
)
chunks = splitter.split_documents(documents)
print(f"Dokumentów: {len(documents)}, fragmentów: {len(chunks)}")

Chunking to sztuka. Za małe fragmenty — brakuje kontekstu. Za duże — za dużo szumu. 300-500 tokenów to dobry start.

Krok 2: Embeddingi i baza wektorowa

Python
Kopiuj
1
2
3
4
5
6
7
8
9
10
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Chroma

# Stwórz embeddingi i zapisz w Chroma
embeddings = OpenAIEmbeddings()  # lub HuggingFace dla self-hosted
vectorstore = Chroma.from_documents(
    documents=chunks,
    embedding=embeddings,
    persist_directory="./chroma_db"
)

Chroma to najprostszy start — działa lokalnie, zero konfiguracji. Na produkcję polecam pgvector (jeśli masz PostgreSQL) lub Pinecone (managed).

Krok 3: Retrieval + LLM

Python
Kopiuj
1
2
3
4
5
6
7
8
9
10
11
12
13
14
from langchain.chat_models import ChatAnthropic
from langchain.chains import RetrievalQA

llm = ChatAnthropic(model="claude-haiku-4-5-20251001")

qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",  # wstaw fragmenty do promptu
    retriever=vectorstore.as_retriever(search_kwargs={"k": 4}),
)

# Pytaj!
result = qa_chain.invoke("Jaka jest polityka zwrotów?")
print(result["result"])

I to jest cały RAG w 30 liniach kodu. Serio.

Najczęstsze błędy przy budowie RAG

1. Za duże chunki

Wrzucasz cały dokument jako jeden fragment? Retrieval nie zadziała — zwróci za dużo nieistotnych informacji. Dziel na logiczne sekcje.

2. Brak overlap

Chunki bez nakładki tracą kontekst na granicach. "Cena wynosi" w jednym chunku, "250 zł" w następnym — i retrieval nie łączy tego w całość. Overlap 50-100 tokenów rozwiązuje problem.

3. Złe embeddingi

Nie każdy model embeddingów jest równy. Dla polskich tekstów sprawdź modele wielojęzyczne (multilingual-e5-large) lub dedykowane polskie. OpenAI text-embedding-3-small/large działa dobrze dla PL.

4. Brak ewaluacji

Skąd wiesz, że Twój RAG odpowiada poprawnie? Potrzebujesz zestawu pytań testowych z oczekiwanymi odpowiedziami. Bez tego optymalizujesz w ciemno.

RAG w produkcji — na co uważać

Aktualizacja dokumentów — gdy zmieniasz dokumenty, musisz przeindeksować bazę wektorową. Zrób pipeline, który automatycznie wykrywa zmiany i reindeksuje.

Bezpieczeństwo — RAG z dostępem do dokumentów poufnych musi mieć kontrolę uprawnień. Nie każdy user powinien widzieć wszystkie dokumenty.

Koszty — embeddingi i wywołania LLM kosztują. Haiku/mini modele do odpowiadania, cacheowanie popularnych pytań, limity per user.

Monitoring — loguj pytania, zwrócone fragmenty i odpowiedzi. Zobaczysz gdzie RAG się myli i co poprawić.

Kiedy RAG, a kiedy fine-tuning?

Dla 90% przypadków biznesowych RAG jest lepszym wyborem.

Podsumowanie

• RAG = LLM + wyszukiwanie w dokumentach — AI odpowiada na podstawie Twoich danych
• Budowa: chunking → embeddingi → baza wektorowa → retrieval → LLM z kontekstem
• 30 linii kodu w Pythonie z LangChain — to nie jest trudne
• Kluczowe: dobry chunking, overlap, odpowiedni model embeddingów
• Na produkcję: ewaluacja, monitoring, aktualizacja indeksu, kontrola dostępu

Jeśli budujesz chatbota firmowego, integrację z bazą wiedzy albo asystenta do dokumentacji — RAG to Twoja odpowiedź.

Chcesz zobaczyć jak to wygląda w praktyce? Na moim kursie n8n pokazuję jak zbudować RAG pipeline bez pisania kodu — od zera do działającego asystenta firmowego.