RAG - co to jest i jak zbudować własny

Zapytałem kiedyś ChatGPT o wewnętrzną procedurę zamknięcia miesiąca. Dostałem odpowiedź piękną, szczegółową i całkowicie zmyśloną, bo tej procedury model nigdy w życiu nie widział. Właśnie w tym miejscu wchodzi RAG.

W tym artykule tłumaczę od podstaw, czym RAG jest naprawdę, co się dzieje pod maską, jak zbudować własny w jeden weekend i w których miejscach to podejście się wykłada.

Czytanie: ~13 min

Model językowy wie prawie wszystko poza tym, co Twoje

Duże modele językowe uczą się na tekstach z internetu. Wikipedia, dokumentacje, książki, fora, kod z GitHuba. Dzięki temu GPT czy Claude bez problemu wytłumaczą Ci amortyzację środków trwałych albo napiszą zapytanie SQL.

Czego nie wiedzą? Wszystkiego, co jest wyłącznie u Ciebie. Twoich umów, procedur, dokumentacji projektowej, historii korespondencji z klientem, cennika, notatek ze spotkań. Model nie miał do tego dostępu podczas treningu i nie ma go teraz.

Dochodzi druga sprawa: data odcięcia wiedzy. Każdy model ma moment, w którym jego wiedza się kończy. Zmiany w przepisach z zeszłego kwartału mogą po prostu dla niego nie istnieć.

I trzecia, najbardziej wredna: model nie mówi „nie wiem". Model generuje najbardziej prawdopodobny ciąg słów. Jeśli nie zna Twojej procedury, wygeneruje coś, co brzmi jak procedura. Halucynacja nie wygląda jak błąd, tylko jak pewna siebie odpowiedź.

Można to obejść na kilka sposobów. Można model douczyć na własnych danych (fine-tuning), można wkleić dokumenty do okna czatu, można zbudować agenta z załączonymi plikami. RAG jest tą metodą, która w większości firmowych zastosowań wygrywa stosunkiem efektu do kosztu.

RAG to otwarta książka na egzaminie

RAG to skrót od Retrieval-Augmented Generation, czyli generowanie wzbogacone wyszukiwaniem. Nazwa brzmi groźnie, mechanizm jest banalny.

Wyobraź sobie egzamin z zamkniętą książką. Zdajesz z pamięci i jeśli czegoś nie pamiętasz, zgadujesz. To jest zwykły model językowy.

Teraz ten sam egzamin, ale możesz korzystać z materiałów. Czytasz pytanie, znajdujesz w skrypcie właściwe dwie strony, czytasz je i dopiero potem odpowiadasz. To jest RAG.

Cały mechanizm sprowadza się do trzech rzeczy dziejących się w ułamku sekundy przed odpowiedzią modelu:

Bierzemy pytanie użytkownika
Szukamy w Twoich dokumentach fragmentów, które mogą zawierać odpowiedź
Wklejamy te fragmenty do promptu razem z pytaniem i instrukcją „odpowiedz wyłącznie na podstawie poniższego kontekstu"

Model nadal nie zna Twoich danych. Po prostu dostaje je pod nos w momencie, w którym są potrzebne.

To rozróżnienie jest ważne, bo bardzo dużo osób myśli, że RAG „uczy" model. Nie uczy. Model po zakończeniu rozmowy nie pamięta nic. Wiedza siedzi w Twojej bazie, a nie w modelu, i to jest zaleta, bo zmieniasz dokument i od razu masz aktualne odpowiedzi, bez żadnego przetrenowywania.

Co się dzieje pod maską, krok po kroku

Tu wchodzimy głębiej. Nie musisz tego umieć napisać od zera, ale musisz to rozumieć, bo każdy problem z jakością odpowiedzi bierze się z któregoś z tych etapów.

Proces dzieli się na dwie fazy. Pierwsza to indeksowanie, robione raz (i powtarzane przy zmianie dokumentów). Druga to zapytanie, robione przy każdym pytaniu użytkownika.

Krok 1: dzielenie dokumentów na kawałki

Nie wrzucasz do bazy całych plików. Wrzucasz fragmenty, po angielsku chunki.

Powód jest prozaiczny. Jeśli Twoja procedura ma 40 stron, a odpowiedź na pytanie siedzi w jednym akapicie, to podanie modelowi całych 40 stron jest marnowaniem miejsca i pieniędzy. Chcesz podać ten jeden akapit i jego okolice.

W praktyce chunki mają zwykle od 300 do 800 tokenów, czyli mniej więcej od pół strony do półtorej strony tekstu. Do tego dokłada się zakładkę (overlap) rzędu 50-100 tokenów, żeby zdanie przecięte na granicy dwóch kawałków nie zgubiło sensu.

Sposób cięcia ma ogromne znaczenie. Cięcie co 500 znaków na sztywno jest najgorszym możliwym wyborem, bo rozwala tabele i listy w połowie. Dużo lepiej ciąć po strukturze dokumentu: po nagłówkach, po sekcjach, po paragrafach umowy. Jeśli pracujesz na Markdownie albo HTML-u, masz tę strukturę za darmo.

Do każdego kawałka dokładasz metadane: z jakiego pliku pochodzi, z której strony, z jakiej sekcji, jaka jest data dokumentu. Bez tego nie zrobisz przypisów do źródeł, a przypisy są tym, co odróżnia użyteczny system od generatora ładnie brzmiących zdań.

Krok 2: zamiana tekstu na liczby

Teraz najciekawszy fragment. Każdy kawałek tekstu przepuszczasz przez model embeddingowy, który zamienia go w wektor, czyli listę liczb. Model text-embedding-3-small od OpenAI produkuje wektory o 1536 wymiarach. Brzmi abstrakcyjnie, więc przetłumaczę.

Wyobraź sobie mapę. Na tej mapie każdy fragment tekstu dostaje swoje współrzędne, przy czym mapa ma nie dwa wymiary, tylko półtora tysiąca. Fragmenty o podobnym znaczeniu lądują blisko siebie. „Faktura nie została opłacona w terminie" i „przeterminowana należność od kontrahenta" trafią w podobne miejsce, mimo że nie mają ani jednego wspólnego słowa.

To jest cała magia wyszukiwania semantycznego. Klasyczne wyszukiwanie po słowach kluczowych szuka dopasowania znaków. Wyszukiwanie wektorowe szuka dopasowania znaczenia. Użytkownik może zapytać własnymi słowami, a system i tak znajdzie właściwy fragment.

Ważne: ten sam model embeddingowy musi obsłużyć zarówno dokumenty przy indeksowaniu, jak i pytanie przy wyszukiwaniu. Wektory z dwóch różnych modeli są ze sobą kompletnie nieporównywalne, więc zmiana modelu embeddingowego oznacza przeliczenie całej bazy od nowa.

Krok 3: baza wektorowa

Wektory muszą gdzieś leżeć i muszą dawać się szybko przeszukiwać. Do tego służą bazy wektorowe.

Wyborów jest sporo i większość początkujących spędza tu za dużo czasu. Krótka ściąga:

pgvector - rozszerzenie do PostgreSQL. Jeśli masz już Postgresa, to jest najrozsądniejszy start. Zero nowej infrastruktury.
Qdrant - postawisz w Dockerze w minutę, szybki, dobre filtrowanie po metadanych.
Chroma - najprostszy do prototypu w Pythonie, działa lokalnie z pliku.
Azure AI Search - jeśli siedzisz w Azure, ma wyszukiwanie hybrydowe i semantic ranker w standardzie.
Pinecone - w pełni zarządzany, płacisz i nie myślisz o utrzymaniu.

Przy 10 tysiącach dokumentów różnica w wydajności między nimi jest dla Ciebie niewidoczna. Wybierz to, co najmniej komplikuje Twój stack, i wróć do tematu, gdy naprawdę urośnie.

Krok 4: wyszukanie i doklejenie do promptu

Użytkownik zadaje pytanie. Pytanie przechodzi przez ten sam model embeddingowy i zamienia się w wektor. Baza znajduje kilka najbliższych mu fragmentów, zwykle od 3 do 10.

Te fragmenty trafiają do promptu, który wygląda mniej więcej tak:

Odpowiadaj wyłącznie na podstawie poniższego kontekstu.
Jeśli w kontekście nie ma odpowiedzi, napisz „nie znalazłem tego w dokumentach".
Przy każdej informacji podaj nazwę pliku źródłowego.

KONTEKST:
[fragment 1 - procedura_zakupowa.pdf, s. 12]
[fragment 2 - procedura_zakupowa.pdf, s. 13]
[fragment 3 - regulamin_2026.docx, s. 4]

PYTANIE:
Kto zatwierdza zamówienie powyżej 50 tysięcy złotych?

Model dostaje wszystko, czego potrzebuje, i generuje odpowiedź. Instrukcja o „nie znalazłem" jest tu absolutnie obowiązkowa, bo bez niej model wróci do zgadywania z własnej pamięci.

Dwa usprawnienia, o których warto wiedzieć od początku. Pierwsze to wyszukiwanie hybrydowe: łączysz wyszukiwanie wektorowe z klasycznym po słowach (BM25). Wektory świetnie łapią znaczenie, ale gubią numery umów, symbole i nazwy własne. Hybryda ratuje sytuację, gdy ktoś pyta o „umowę 2024/PL/117".

Drugie to reranker. Baza zwraca 30 kandydatów, a osobny, mniejszy model ocenia, które z nich faktycznie odpowiadają na pytanie, i zostawia 5 najlepszych. Cohere Rerank albo dowolny cross-encoder. To zwykle najtańsza poprawa jakości, jaką da się dołożyć do gotowego RAG-a.

Dlaczego nie wrzucić po prostu wszystkiego do promptu

Modele mają dziś ogromne okna kontekstu. 200 tysięcy tokenów u Claude, milion u Gemini. Naturalne pytanie brzmi: po co ta cała maszyneria, skoro można wkleić całą dokumentację i pytać?

Czasem faktycznie można i za chwilę napiszę, kiedy. Ale są cztery powody, dla których przy większych zbiorach to przestaje działać.

Pieniądze. Płacisz za każdy token wejściowy przy każdym pytaniu. Jeśli wklejasz 150 tysięcy tokenów dokumentacji do każdego zapytania, a pytań masz 500 dziennie, rachunek robi się absurdalny. RAG podaje 2 tysiące tokenów zamiast 150 tysięcy.

Czas. Przetworzenie ogromnego kontekstu trwa. Różnica między odpowiedzią w 2 sekundy a w 25 sekund decyduje o tym, czy ktokolwiek będzie z tego narzędzia korzystał.

Jakość. Zjawisko „lost in the middle" jest dobrze udokumentowane: modele najlepiej wykorzystują informacje z początku i końca kontekstu, a to, co siedzi w środku, potrafią zwyczajnie przeoczyć. Im więcej szumu dokoła właściwej informacji, tym większa szansa, że model się pogubi.

Skala. Firmowa dokumentacja to często gigabajty. To się nie zmieści w żadnym oknie kontekstu, choćby nie wiem jak rosło.

RAG jest więc formą filtra. Zamiast wysypywać modelowi na biurko całe archiwum, podajesz mu trzy właściwe kartki.

RAG, fine-tuning i CustomGPT - co do czego

Te trzy podejścia mieszają się początkującym najczęściej, a rozwiązują zupełnie inne problemy.

RAG daje modelowi wiedzę. Aktualizujesz dokument i w następnej sekundzie odpowiedzi są aktualne. Dostajesz przypisy do źródeł, więc możesz zweryfikować, skąd wzięła się odpowiedź. Wdrożenie liczy się w dniach, nie w tygodniach.

Fine-tuning daje modelowi zachowanie. Uczysz go stylu, formatu odpowiedzi, specyficznego żargonu branżowego, konsekwentnej struktury wyjścia. Fine-tuning nie jest dobrym sposobem na wtłoczenie faktów, bo model i tak potrafi je pomieszać, a każda zmiana danych oznacza kolejny trening.

CustomGPT albo Projects w Claude to gotowy, uproszczony RAG w interfejsie przeglądarki. Wrzucasz pliki, piszesz instrukcję, masz agenta. Świetne do 20 dokumentów i jednego użytkownika. Kiepskie, gdy masz 5 tysięcy plików, potrzebujesz kontroli uprawnień albo integracji z własną aplikacją.

Moja rekomendacja dla kogoś, kto zaczyna: zrób najpierw CustomGPT. Serio. W godzinę sprawdzisz, czy pomysł ma sens biznesowy, zanim wydasz tydzień na własną infrastrukturę. Dopiero gdy ograniczenia zaczną uwierać, buduj własny RAG.

Jak zbudować pierwszy RAG w weekend

Przejdźmy do konkretów. Pokażę dwie ścieżki, bo nie każdy chce pisać kod.

Ścieżka na dwie godziny: bez kodu

Potrzebujesz n8n (lub Make) i konta OpenAI.

Postaw Supabase z rozszerzeniem pgvector albo użyj Qdrant Cloud w darmowym planie
W n8n zbuduj przepływ indeksujący: trigger z folderu Google Drive, node do wyciągania tekstu, node Text Splitter, node Embeddings OpenAI, node Vector Store Insert
Zbuduj drugi przepływ: webhook z pytaniem, node Vector Store Retrieval, node z modelem czatu i promptem trzymającym się kontekstu
Podepnij pod formularz, Slacka albo Teamsy

n8n ma te nody gotowe, więc składasz to jak klocki. Ograniczenie tego podejścia zobaczysz przy trudniejszych PDF-ach i przy potrzebie własnej logiki, ale do walidacji pomysłu jest w zupełności wystarczające.

Ścieżka na weekend: własny kod

Ja siedzę w .NET, więc opiszę to z tej strony, ale w Pythonie odpowiedniki są jeden do jednego.

W .NET najkrótsza droga to Semantic Kernel razem z Kernel Memory. Kernel Memory ogarnia za Ciebie parsowanie dokumentów, chunking, embeddingi i zapis do bazy wektorowej, a Ty dostajesz dwie metody: ImportDocumentAsync i AskAsync. Konfiguracja to kilkadziesiąt linii.

W Pythonie masz LlamaIndex (bliżej dokumentów) albo LangChain (bliżej agentów i przepływów). Do prototypu wolę LlamaIndex, bo mniej abstrakcji stoi między Tobą a tym, co się faktycznie dzieje.

Kolejność prac, którą polecam:

Zacznij od 20 dokumentów, nie od 5 tysięcy. Chcesz szybkiej pętli zwrotnej, a nie dwugodzinnego indeksowania przy każdej zmianie parametrów.
Napisz zestaw 15-20 pytań testowych razem z poprawnymi odpowiedziami. To najważniejszy krok, który wszyscy pomijają. Bez tego nie masz jak stwierdzić, czy zmiana rozmiaru chunka cokolwiek poprawiła, czy tylko tak Ci się wydaje.
Uruchom najprostszą możliwą wersję. Chunki po 500 tokenów, top 5 wyników, jeden prompt. Zmierz, ile pytań system trafia.
Poprawiaj po jednej rzeczy naraz. Rozmiar chunka, liczba zwracanych fragmentów, hybryda, reranker. Po każdej zmianie przelicz swoje pytania testowe.
Dodaj przypisy do źródeł od pierwszego dnia. Odpowiedź bez informacji, z którego pliku pochodzi, jest w zastosowaniach biznesowych bezwartościowa, bo nikt nie zaryzykuje decyzji, której nie może zweryfikować.

Na parsowanie PDF-ów przygotuj osobny budżet czasu. Zwykły ekstraktor tekstu przy dokumentach z tabelami zwróci Ci sieczkę. Do trudniejszych plików sprawdza się Azure Document Intelligence albo modele multimodalne czytające strony jak obrazki. To zwykle najbardziej pracochłonny fragment całego przedsięwzięcia i mało kto o tym uprzedza.

Ile to kosztuje

Liczby są mniej straszne, niż większość zakłada.

Embeddingi: text-embedding-3-small kosztuje około 0,02 dolara za milion tokenów. Pięćset stron dokumentacji to jakieś 250 tysięcy tokenów, czyli koszt zaindeksowania wynosi pół centa. Nie pomyliłem się o rząd wielkości.

Zapytania: przy 2 tysiącach tokenów kontekstu i modelu ze średniej półki jedno pytanie kosztuje ułamek grosza. Tysiąc pytań miesięcznie zamyka się w kilku dolarach.

Baza wektorowa: pgvector na własnym Postgresie jest za darmo. Qdrant w Dockerze też. Zarządzane usługi startują od kilkudziesięciu dolarów miesięcznie.

Realnym kosztem nie są tokeny, tylko czas na parsowanie dokumentów i strojenie jakości. Zaplanuj proporcję mniej więcej 20 procent na infrastrukturę i 80 procent na to, żeby odpowiedzi faktycznie były dobre.

Pięć miejsc, w których RAG się wykłada

Teraz część, której nie znajdziesz w materiałach marketingowych.

Pytania agregujące. „Ile mamy umów wygasających w tym kwartale?" RAG zwróci pięć najbardziej pasujących fragmentów i model policzy z pięciu, choć umów jest czterdzieści. Wyszukiwanie po podobieństwie z definicji nie widzi całego zbioru. Do liczenia potrzebujesz bazy danych i zapytania SQL, nie RAG-a.

Tabele i skany. Tabela pocięta na chunki traci nagłówki kolumn, więc wartość „12 500" przestaje cokolwiek znaczyć. Skan bez porządnego OCR nie wnosi nic. To wąskie gardło większości wdrożeń w firmach, które trzymają dokumenty jako PDF-y z drukarki.

Numery, symbole, nazwy własne. Wyszukiwanie semantyczne uważa, że „umowa 2024/PL/117" i „umowa 2024/PL/171" są niemal identyczne. Bez wyszukiwania hybrydowego dostaniesz odpowiedź o niewłaściwym dokumencie i będzie ona brzmiała absolutnie wiarygodnie.

Sprzeczne wersje dokumentów. W bazie leży procedura z 2023 i jej nowelizacja z 2026. Obie pasują do pytania, obie trafiają do kontekstu, model skleja z nich odpowiedź, której nie ma w żadnej z nich. Ratunkiem są metadane z datą i filtrowanie po wersji, ale trzeba o tym pomyśleć przy projektowaniu, nie po wdrożeniu.

Pytania wymagające połączenia informacji z wielu miejsc. „Czy nasza polityka rabatowa jest zgodna z warunkami umowy z klientem X?" wymaga zestawienia dwóch odległych dokumentów i wnioskowania. Zwykły RAG poda fragmenty i będzie liczył na to, że model sobie poradzi. Czasem poradzi, czasem nie. Do takich rzeczy potrzebujesz podejścia agentowego, w którym model sam decyduje o kolejnych wyszukiwaniach.

Do tego dochodzi rzecz, która potrafi zaboleć najbardziej: RAG nie eliminuje halucynacji, tylko je ogranicza. Model nadal potrafi dopowiedzieć coś, czego w kontekście nie było, zwłaszcza gdy kontekst jest częściowy. Dlatego przypisy do źródeł nie są ozdobnikiem, tylko mechanizmem kontroli.

Kiedy RAG nie jest odpowiedzią

Zdarza mi się odradzać RAG i to częściej, niż mogłoby się wydawać.

Jeśli masz 20-30 stron dokumentów, wklej je do promptu albo zrób CustomGPT. Budowanie bazy wektorowej dla trzech plików to inżynieria dla samej inżynierii.

Jeśli Twoje dane siedzą w tabelach bazy danych, potrzebujesz text-to-SQL, a nie RAG. Pytania w stylu „pokaż sprzedaż per region za czerwiec" rozwiązuje się zapytaniem, nie wyszukiwaniem semantycznym.

Jeśli dane zmieniają się co sekundę, na przykład stany magazynowe albo kursy walut, podepnij API. Indeksowanie zawsze będzie o krok w tyle.

Jeśli problemem jest styl albo format odpowiedzi, popraw prompt albo rozważ fine-tuning. RAG nie zmieni sposobu, w jaki model pisze.

I najważniejsze: jeśli Twoje dokumenty są chaotyczne, nieaktualne i sprzeczne, RAG tego nie naprawi. Zwróci Ci ten sam bałagan, tylko szybciej i w pełnych zdaniach. Widziałem to na tyle razy, żeby traktować przegląd źródeł jako pierwszy etap projektu, a nie jako formalność.

Od czego zacząć

RAG jest mechanizmem prostym w idei i wymagającym w szczegółach. Idea to podanie modelowi właściwych fragmentów Twoich dokumentów w momencie zadania pytania. Szczegóły to parsowanie, cięcie, metadane, wyszukiwanie hybrydowe i uczciwe mierzenie jakości.

Konkretna kolejność na start, jeśli chcesz sprawdzić to u siebie:

Wybierz jeden obszar, który generuje najwięcej powtarzalnych pytań. Procedury, dokumentacja techniczna, baza wiedzy wsparcia.
Zbierz 20 dokumentów i zrób CustomGPT albo projekt w Claude. Godzina pracy.
Zapisz 15 realnych pytań i sprawdź, ile odpowiedzi jest użytecznych. To Twoja linia odniesienia.
Jeśli wynik jest obiecujący, buduj własny RAG. Jeśli nie, problem prawie na pewno leży w jakości dokumentów, a nie w technologii.

Największy błąd, jaki widuję, to zaczynanie od wyboru bazy wektorowej. Baza jest najmniej istotną decyzją w całym projekcie. Najistotniejsze jest to, czy Twoje dokumenty w ogóle zawierają odpowiedzi, których szukają ludzie.

Jeśli chcesz sprawdzić, czy RAG ma sens w Twojej firmie, albo masz stertę dokumentacji i nie wiesz, od której strony ją ugryźć, napisz do mnie przez mwozniczka.net/kontakt. Robię prototypy, które da się przetestować na prawdziwych danych, zanim ktokolwiek podpisze budżet na duży projekt.