Jak działa RAG - przewodnik po AI, która czyta Twoje dokumenty

Koleżanka z działu HR przyszła do mnie w zeszłym tygodniu z pytaniem: "Jak to jest, że ChatGPT nie zna naszych wewnętrznych procedur, ale te nowe narzędzia firmowe już tak?" Odpowiedź brzmi: RAG. I nie, to nie skrót od rage quit, tylko od Retrieval Augmented Generation.

To technologia, która sprawia, że AI potrafi rozmawiać o Twoich dokumentach, kontraktach, bazach wiedzy - jakby je faktycznie przeczytała. Bez trenowania modelu od zera. Bez wysyłania wszystkiego do OpenAI. Po prostu: wrzucasz plik, zadajesz pytanie, dostajesz odpowiedź opartą na tym, co w nim jest.

Czym właściwie jest RAG i dlaczego to nie jest magia

RAG to sposób na połączenie dwóch rzeczy: wyszukiwania informacji i generowania tekstu przez AI. Zamiast polegać wyłącznie na tym, co model "pamięta" z treningu, RAG najpierw szuka odpowiednich fragmentów w Twoich dokumentach, a potem używa ich jako kontekstu do odpowiedzi.

Ktoś pyta Cię o szczegóły umowy z 2019 roku. Zamiast polegać na pamięci, najpierw otwierasz archiwum, znajdujesz dokument, czytasz kluczowe fragmenty - i dopiero wtedy odpowiadasz. RAG działa podobnie. Robi to w ułamku sekundy.

Trzy elementy, które składają się na RAG

RAG to nie jeden algorytm, tylko system złożony z trzech części:

1. Embeddingi - matematyczna reprezentacja tekstu. Każde zdanie, akapit czy dokument zamienia się w ciąg liczb (wektor), który oddaje jego znaczenie.
2. Baza wektorowa (vector database) - miejsce, gdzie przechowujesz te embeddingi. To nie zwykła baza SQL - ona potrafi szukać "podobieństwa" między wektorami.
3. Model językowy - Claude Opus 4.7, GPT-5 czy inny LLM, który dostaje znalezione fragmenty jako kontekst i na ich podstawie generuje odpowiedź.

Kluczowa różnica między RAG a zwykłym promptem? Zwykły prompt wysyła do modelu tylko Twoje pytanie. RAG wysyła pytanie PLUS odpowiednie fragmenty z Twoich dokumentów. Model nie musi "pamiętać" - dostaje fakty na talerzu.

Jak embeddingi zamieniają tekst w liczby

Embeddingi to fundament RAG. Bez nich nie ma wyszukiwania semantycznego, a bez wyszukiwania semantycznego - nie ma sensu cały system.

Prosty przykład: masz dwa zdania. "Kot siedzi na macie" i "Zwierzę domowe odpoczywa na dywanie". Dla człowieka to podobne znaczenia. Dla komputera? Zero wspólnych słów. Embeddingi rozwiązują ten problem - zamieniają oba zdania w wektory (np. 1536 liczb), które są do siebie matematycznie bliskie, bo ZNACZĄ podobne rzeczy.

Jak to działa w praktyce

Kiedy wrzucasz dokument do systemu RAG, dzieje się to:

1. Dokument dzieli się na mniejsze kawałki (chunki) - zazwyczaj 200-500 słów. Dlaczego? Bo embeddingi działają lepiej na krótszych fragmentach.
2. Każdy chunk przechodzi przez model embeddingowy (np. text-embedding-3-large od OpenAI lub voyage-02 od Voyage AI) i zamienia się w wektor.
3. Wektory lądują w bazie wektorowej - Pinecone, Weaviate, Qdrant, ChromaDB. Każda ma swoje zalety, wszystkie robią to samo: przechowują wektory i potrafią szybko znaleźć te najbardziej podobne do zapytania.

Kiedy zadajesz pytanie, Twoje pytanie TEŻ zamienia się w wektor. Baza porównuje go z wektorami dokumentów i zwraca np. 5 najbardziej podobnych chunków. Te chunki trafiają do modelu językowego jako kontekst.

Dlaczego to lepsze niż zwykłe wyszukiwanie słów kluczowych

Tradycyjne wyszukiwanie (keyword search) szuka dokładnych dopasowań. Piszesz "umowa najmu" - znajduje dokumenty z tymi słowami. Jeśli w dokumencie jest "kontrakt wynajmu mieszkania", keyword search może go przegapić.

Wyszukiwanie wektorowe (semantic search) rozumie, że "umowa najmu" i "kontrakt wynajmu" to to samo. Znajduje dokumenty na podstawie ZNACZENIA, nie liter. To ogromna różnica w praktyce - szczególnie gdy masz tysiące dokumentów w różnych formatach i językach.

Bazy wektorowe - gdzie przechowujesz embeddingi

Zwykła baza danych (PostgreSQL, MySQL) nie nadaje się do przechowywania embeddingów. Możesz tam wrzucić wektory, nie będziesz w stanie szybko znaleźć "najbardziej podobnych". Do tego potrzebna jest baza wektorowa.

Popularne opcje na rynku

• Pinecone - managed service, płacisz za użycie. Najłatwiejszy start, droższa opcja przy dużych wolumenach.
• Weaviate - open source, możesz hostować sam lub użyć ich clouda. Dobra równowaga między kontrolą a wygodą.
• Qdrant - open source, napisany w Rust (szybki). Popularny w Europie, dobre API.
• ChromaDB - lekka opcja, idealna do prototypów i małych projektów. Działa lokalnie, zero setupu.
• pgvector - rozszerzenie PostgreSQL. Jeśli już masz Postgres, możesz dodać wektory bez nowej bazy. Wolniejsze od dedykowanych rozwiązań, wystarczające dla średnich projektów.

Która wybrać? Jeśli testujesz pomysł - ChromaDB. Jeśli budujesz produkcyjny system i nie chcesz zarządzać infrastrukturą - Pinecone. Jeśli masz devopsa w zespole i wolisz kontrolę - Weaviate lub Qdrant.

Jak zbudować prosty system RAG krok po kroku

Teoria to jedno, praktyka to drugie. Pokażę Ci, jak zbudować działający system RAG bez kodowania od zera - używając gotowych narzędzi.

Zanim zaczniesz

Potrzebujesz:

• Konto w OpenAI (lub Anthropic, jeśli wolisz Claude)
• Konto w Pinecone (darmowy tier wystarczy na start)
• Python 3.8+ zainstalowany lokalnie (lub użyj Google Colab)
• Podstawowa znajomość terminala (umiesz uruchomić skrypt)

Nie musisz być programistą. Jeśli potrafisz skopiować kod i wpisać komendy - dasz radę.

Krok 1: Przygotuj dokumenty

Zbierz dokumenty, które chcesz "podłączyć" do AI. Mogą to być:

• PDF-y (raporty, umowy, instrukcje)
• Pliki tekstowe (.txt, .md)
• Dokumenty Word (.docx)
• Strony z wiki firmowej (eksportowane do HTML)

Wrzuć je do jednego folderu na dysku. Nazwij go np. "documents". Im bardziej uporządkowane, tym łatwiej później zarządzać systemem.

Krok 2: Zainstaluj narzędzia

Otwierasz terminal i wpisujesz:

pip install langchain openai pinecone-client pypdf

LangChain to framework, który łączy embeddingi, bazy wektorowe i modele językowe. Zamiast pisać setki linii kodu, używasz gotowych bloków.

Krok 3: Podziel dokumenty na chunki i stwórz embeddingi

Kopiujesz poniższy skrypt do pliku create_embeddings.py:

from langchain.document_loaders import DirectoryLoader, PyPDFLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Pinecone
import pinecone

# Wczytujesz dokumenty z folderu
loader = DirectoryLoader('./documents', glob="**/*.pdf", loader_cls=PyPDFLoader)
documents = loader.load()

# Dzielisz na chunki po 500 znaków z 50-znakowym nakładaniem
text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = text_splitter.split_documents(documents)

# Tworzysz embeddingi przez OpenAI
embeddings = OpenAIEmbeddings(model="text-embedding-3-large")

# Łączysz się z Pinecone i wrzucasz chunki
pinecone.init(api_key="TWOJ_KLUCZ_API", environment="us-west1-gcp")
vectorstore = Pinecone.from_documents(chunks, embeddings, index_name="moje-dokumenty")

print(f"Dodano {len(chunks)} chunków do bazy wektorowej")

Zamieniasz TWOJ_KLUCZ_API na prawdziwy klucz z Pinecone (znajdziesz go w panelu po zalogowaniu). Uruchamiasz:

python create_embeddings.py

Skrypt przeczyta wszystkie PDF-y, podzieli je na kawałki, zamieni w wektory i wyśle do Pinecone. Przy 100 stronach dokumentów zajmie to 2-3 minuty.

Krok 4: Zbuduj interfejs do zadawania pytań

Teraz tworzysz drugi skrypt - query.py:

from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Pinecone
from langchain.chat_models import ChatOpenAI
from langchain.chains import RetrievalQA
import pinecone

# Łączysz się z bazą wektorową
pinecone.init(api_key="TWOJ_KLUCZ_API", environment="us-west1-gcp")
embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
vectorstore = Pinecone.from_existing_index("moje-dokumenty", embeddings)

# Tworzysz łańcuch RAG z Claude lub GPT
llm = ChatOpenAI(model="gpt-5", temperature=0)
qa_chain = RetrievalQA.from_chain_type(
 llm=llm,
 chain_type="stuff",
 retriever=vectorstore.as_retriever(search_kwargs={"k": 5})
)

# Zadajesz pytanie
question = "Jakie są warunki rozwiązania umowy?"
result = qa_chain.run(question)
print(result)

Uruchamiasz:

python query.py

System znajdzie 5 najbardziej pasujących fragmentów z Twoich dokumentów, wyśle je do GPT-5 jako kontekst i wydrukuje odpowiedź. Cały proces trwa 2-3 sekundy.

Krok 5: Przetestuj różne pytania

Zmieniasz wartość zmiennej question w skrypcie i sprawdzasz, jak system radzi sobie z różnymi zapytaniami:

• "Kto jest odpowiedzialny za utrzymanie lokalu?"
• "Jakie dokumenty są wymagane przy rozliczeniu projektu?"
• "Kiedy wchodzi w życie nowa procedura?"

Jeśli odpowiedzi są zbyt ogólne - zwiększ chunk_size do 800. Jeśli system nie znajduje odpowiedzi - zmniejsz do 300 i zwiększ k (liczba zwracanych chunków) do 8-10.

Najczęstsze problemy i jak je rozwiązać

Problem 1: System zwraca nieprecyzyjne odpowiedzi

Najczęstsza przyczyna: chunki są za duże albo za małe. Jeśli chunk ma 2000 znaków, model dostaje zbyt dużo kontekstu i gubi się. Jeśli ma 100 znaków - za mało informacji.

Rozwiązanie: testuj różne wartości chunk_size. Dla dokumentów technicznych (umowy, instrukcje) - 400-600 znaków. Dla tekstów narracyjnych (artykuły, raporty) - 600-1000 znaków.

Problem 2: Drogie koszty API

Embeddingi kosztują. Jeśli masz 1000 stron dokumentów podzielonych na chunki po 500 znaków, to około 100 000 tokenów embeddingowych. text-embedding-3-large kosztuje $0.13 za milion tokenów, więc ~$0.013. Nie dużo.

Zapytania to inna historia. Każde pytanie wysyła 5-10 chunków do GPT-5 (około 2000-4000 tokenów kontekstu). Przy $30 za milion tokenów wejściowych to $0.06-0.12 na zapytanie. 100 zapytań dziennie = $6-12 dziennie.

Rozwiązanie: użyj tańszego modelu do odpowiedzi. GPT-5-mini kosztuje $0.15/$0.60 za milion tokenów (20x taniej niż GPT-5). Dla większości przypadków wystarczy. Albo Claude Haiku 4.5 - jeszcze tańszy i szybszy.

Problem 3: System nie znajduje odpowiedzi, mimo że są w dokumentach

Dwie możliwe przyczyny:

1. Słaby model embeddingowy - jeśli używasz starszego modelu (np. text-embedding-ada-002), zamień na text-embedding-3-large. Różnica w jakości wyszukiwania jest zauważalna.
2. Za mało zwracanych chunków - zwiększ k z 5 do 10. System przeszuka więcej fragmentów i ma większą szansę trafić w odpowiedni.

Zaawansowane techniki - kiedy prosty RAG nie wystarcza

Podstawowy RAG działa dobrze dla prostych przypadków. Jeśli masz tysiące dokumentów, złożone zapytania lub potrzebujesz wysokiej precyzji - musisz użyć bardziej zaawansowanych technik.

Hybrid search - łączenie wektorowego i keyword

Czasami wyszukiwanie semantyczne przegapia dokładne dopasowania. Przykład: szukasz "artykuł 15 ust. 3" w umowie. Wyszukiwanie wektorowe może zwrócić fragmenty o podobnej TEMATYCE, nie ten konkretny artykuł.

Hybrid search łączy oba podejścia - wektorowe (semantic) i keyword (BM25). Weaviate i Qdrant mają to wbudowane. Pinecone wymaga dodatkowej warstwy (np. Elasticsearch obok).

Reranking - druga warstwa filtrowania

Baza wektorowa zwraca np. 20 chunków. Zamiast wysyłać wszystkie do modelu, używasz modelu rerankingowego (np. Cohere Rerank lub Voyage Rerank), który ocenia każdy chunk pod kątem DOKŁADNEGO dopasowania do pytania i wybiera top 5.

Koszt dodatkowy: $1 za 1000 zapytań (Cohere). Jakość odpowiedzi rośnie o 15-30% w testach.

Multi-query RAG - jedno pytanie, wiele wyszukiwań

Zamiast jednego zapytania do bazy wektorowej, system generuje 3-5 wariantów Twojego pytania i szuka osobno dla każdego. Potem łączy wyniki.

Przykład: pytasz "Jak rozwiązać umowę?". System generuje warianty: "procedura rozwiązania umowy", "warunki wypowiedzenia kontraktu", "anulowanie umowy najmu". Każdy wariant może trafić w inne fragmenty dokumentów.

Implementacja w LangChain zajmuje 10 linii kodu. Koszt rośnie (więcej zapytań embeddingowych), precyzja też.

Kiedy RAG ma sens, a kiedy nie

RAG nie jest uniwersalnym rozwiązaniem. Są sytuacje, gdzie sprawdza się świetnie - i takie, gdzie lepiej użyć czegoś innego.

RAG działa dobrze, gdy:

• Masz dużo dokumentów (dziesiątki, setki, tysiące) i potrzebujesz szybko znaleźć odpowiedzi
• Dokumenty się zmieniają - dodajesz nowe, aktualizujesz stare. RAG pozwala na to bez ponownego trenowania modelu
• Potrzebujesz źródeł - system może zwrócić nie tylko odpowiedź, też fragment dokumentu, z którego pochodzi
• Dane są prywatne i nie chcesz ich wysyłać do OpenAI do fine-tuningu

RAG NIE działa dobrze, gdy:

• Potrzebujesz rozumowania wieloetapowego - RAG zwraca fragmenty, nie "myśli" nad nimi. Do tego lepszy jest agent AI z narzędziami
• Dokumenty są krótkie (kilka stron) - łatwiej wrzucić je bezpośrednio do kontekstu modelu (Claude Opus 4.7 ma 1M tokenów kontekstu, zmieści się tam 500-700 stron)
• Potrzebujesz generowania treści, nie odpowiedzi na pytania - RAG jest do wyszukiwania, nie do tworzenia od zera

Narzędzia no-code do RAG - jeśli nie chcesz pisać kodu

Nie musisz kodować, żeby użyć RAG. Jest kilka narzędzi, które dają gotowy interfejs.

ChatGPT Enterprise - RAG wbudowany

Jeśli Twoja firma ma plan Enterprise, możesz wrzucić dokumenty do "Knowledge Base" i ChatGPT automatycznie użyje ich jako kontekstu. Zero setupu, działa od ręki. Drogie ($60/użytkownik/miesiąc) i tylko dla firm.

Notion AI - RAG dla wiki

Notion dodał funkcję AI Q&A, która przeszukuje Twoją workspace i odpowiada na pytania. Działa na zasadzie RAG, nie masz kontroli nad chunkowaniem ani modelem embeddingowym. Wystarczające dla małych zespołów.

Glean - dedykowane narzędzie do enterprise search

Glean łączy się z Google Drive, Slack, Confluence, Jira i innymi narzędziami firmowymi. Indeksuje wszystko, tworzy embeddingi i daje interfejs do pytań. Drogie (custom pricing), jeśli masz rozproszone dane w 10+ systemach - może się opłacić.

Dify.ai - open source platforma RAG

Jeśli chcesz kontrolę, nie chcesz pisać kodu od zera - Dify to złoty środek. Instalujesz lokalnie (Docker), wrzucasz dokumenty przez interfejs webowy, konfigurujesz chunking i embeddingi - gotowe. Możesz hostować sam lub użyć ich clouda.

Najczęstsze pytania

Czy RAG działa z dokumentami po polsku?

Tak, modele embeddingowe (text-embedding-3-large, voyage-02) są wielojęzyczne i radzą sobie z polskim tekstem bez problemu. Również modele językowe (GPT-5, Claude Opus 4.7) rozumieją polski kontekst. Jedyna różnica: jakość embeddingów dla polskiego jest ~5-10% niższa niż dla angielskiego, bo modele były trenowane głównie na angielskich danych. W praktyce różnica jest niezauważalna dla większości zastosowań.

Ile kosztuje uruchomienie systemu RAG dla małej firmy?

Zależy od wolumenu. Przykładowy breakdown: 500 stron dokumentów (około 250 000 tokenów) to ~$0.03 za embeddingi (jednorazowo). Pinecone free tier obsługuje do 100 000 wektorów (wystarczy na ~50 000 stron). Zapytania: jeśli używasz GPT-5-mini, to $0.15 za milion tokenów wejściowych. Przy 100 zapytaniach dziennie (każde ~3000 tokenów kontekstu) to $0.045 dziennie = ~$1.35 miesięcznie. Realistyczny koszt dla małej firmy: $5-20 miesięcznie.

Czy mogę użyć RAG offline, bez wysyłania danych do chmury?

Tak, musisz użyć lokalnych modeli. Zamiast OpenAI embeddings - użyj modelu z Hugging Face (np. sentence-transformers/all-MiniLM-L6-v2). Zamiast GPT-5 - użyj lokalnego LLM (np. Llama 4 Scout przez Ollama). Zamiast Pinecone - użyj ChromaDB lokalnie. Całość może działać na Twoim serwerze bez wysyłania czegokolwiek na zewnątrz. Jakość będzie niższa niż z komercyjnymi modelami, dla wrażliwych danych to jedyna opcja.

Jak często powinienem aktualizować embeddingi po zmianie dokumentów?

Zależy od dynamiki zmian. Jeśli dokumenty zmieniają się codziennie (np. baza wiedzy produktowej) - uruchom skrypt embeddingowy raz dziennie w nocy (cron job). Jeśli raz w tygodniu - wystarczy manualna aktualizacja. Większość baz wektorowych pozwala na inkrementalne dodawanie (nie musisz przetwarzać wszystkiego od nowa, tylko nowe/zmienione pliki). Pinecone i Weaviate mają API do usuwania starych chunków i dodawania nowych.

Czy RAG może zastąpić fine-tuning modelu?

Nie do końca. RAG daje modelowi DOSTĘP do informacji, nie zmienia jego "sposobu myślenia". Fine-tuning zmienia wagi modelu - uczy go nowego stylu, formatu odpowiedzi, specjalistycznej wiedzy. Jeśli potrzebujesz, żeby model odpowiadał w konkretnym tonie (np. formalnym języku prawniczym) - fine-tuning. Jeśli potrzebujesz, żeby znał Twoje dokumenty - RAG. Często najlepsze rozwiązanie to połączenie: fine-tuning na styl + RAG na treść.

Pierwszy krok - zbuduj prototyp dziś

RAG to nie teoria - to narzędzie, które możesz uruchomić dziś. Jeśli masz 10-20 dokumentów, z których często korzystasz (procedury, umowy, raporty), spróbuj zbudować prosty system według kroków z tego artykułu.

Zacznij od ChromaDB lokalnie - zero konfiguracji, zero kosztów. Wrzuć 5 dokumentów. Zadaj 10 pytań. Zobacz, jak system radzi sobie z różnymi sformułowaniami. Jak zobaczysz, że to działa - przejdź na Pinecone i GPT-5.

Jedna konkretna akcja na dziś: zainstaluj LangChain i ChromaDB (pip install langchain chromadb), stwórz folder "documents", wrzuć tam 3 PDF-y i uruchom pierwszy skrypt embeddingowy. Zajmie Ci to 15 minut. Za tydzień będziesz mógł zapytać swoje dokumenty o cokolwiek.