Co to jest RAG? Jak działa retrieval augmented generation w agentach AI

Co to jest RAG (Retrieval Augmented Generation)

RAG to skrót od Retrieval Augmented Generation, czyli generowania wzbogaconego wyszukiwaniem. Model językowy sam z siebie korzysta tylko z wiedzy zapamiętanej podczas treningu. RAG dokłada krok wcześniej: system najpierw szuka potrzebnych informacji w zewnętrznym źródle (bazie dokumentów, procedurach firmowych, przepisach prawa), a dopiero potem generuje odpowiedź na podstawie tego, co znalazł. W praktyce oznacza to jedno: model przestaje zgadywać i zaczyna sprawdzać fakty.

Bez RAG model odpowiada z pamięci, a ta ma datę odcięcia i nie zna wewnętrznych dokumentów konkretnej firmy. Zapytany o regulamin urlopowy albo najnowszą fakturę, potrafi zmyślić odpowiedź, która brzmi wiarygodnie, ale nijak się ma do rzeczywistości. To zjawisko nazywa się halucynacją. RAG je ogranicza, bo model odpowiada na podstawie realnych dokumentów, nie domysłów.

W praktyce RAG to dziś standardowy element architektury agentów AI. Każdy system, który ma odpowiadać na pytania klientów czy pracowników w oparciu o wiedzę firmową, potrzebuje jakiejś formy wyszukiwania w dokumentach, zanim model zacznie pisać odpowiedź. Widzę to w każdym projekcie, który prowadzę. Klient rzadko pyta wprost o RAG, ale niemal zawsze potrzebuje mechanizmu, dzięki któremu agent odpowie zgodnie z jego dokumentami, a nie z ogólną wiedzą modelu.

Jak działa RAG krok po kroku

Proces zaczyna się od pytania użytkownika, na przykład pracownika piszącego na WhatsApp "ile dni urlopu mi zostało" albo klienta pytającego o status zamówienia. System zamienia to pytanie na wektor liczbowy, czyli embedding, i szuka w bazie wektorowej fragmentów dokumentów o zbliżonym znaczeniu. Model embeddingowy tłumaczy tekst na punkt w wielowymiarowej przestrzeni. Zdania o podobnym sensie leżą więc blisko siebie, nawet gdy używają zupełnie innych słów.

Znalezione fragmenty, zwykle kilka do kilkunastu kawałków tekstu, trafiają razem z oryginalnym pytaniem do modelu językowego jako kontekst. To etap augmentacji. Model dostaje pytanie i materiał źródłowy, z którego ma korzystać przy odpowiedzi. W dobrze zaprojektowanym systemie działa tu jeszcze reranker, dodatkowy model, który przelicza znalezione kawałki i układa je od najbardziej do najmniej trafnych.

Ostatni krok to generowanie odpowiedzi. Dobrze zaprojektowany RAG każe modelowi cytować źródło: numer artykułu ustawy, nazwę dokumentu, datę, żeby odpowiedź dało się zweryfikować, a nie tylko jej uwierzyć na słowo. To trzeba wymusić świadomie w promptcie systemowym, bo domyślnie model nie zawsze poda źródło.

RAG kontra fine-tuning i zwykły prompt systemowy

Fine-tuning polega na doszkoleniu modelu na własnych danych, czyli zmianie jego wewnętrznych wag. To podejście kosztowne, czasochłonne i statyczne. Każda zmiana w dokumentach firmowych wymaga ponownego treningu. Do wiedzy, która zmienia się co tydzień, jak stawki, procedury czy dokumenty kadrowe, fine-tuning po prostu słabo pasuje.

Wrzucenie wszystkich dokumentów do jednego długiego prompta też ma swoje granice. Nawet duże okna kontekstu mają limit, a im więcej tekstu, tym trudniej modelowi znaleźć w nim właściwy fragment i tym wyższy koszt każdego zapytania.

RAG jest gdzieś pośrodku i w większości firmowych przypadków wygrywa. Baza wiedzy aktualizuje się przez dodanie albo podmianę dokumentu, bez dotykania samego modelu, a do promptu trafiają tylko fragmenty faktycznie potrzebne do odpowiedzi na dane pytanie. Te podejścia często się łączy: RAG do faktów, prompt systemowy do tonu odpowiedzi, a osobna warstwa reguł biznesowych do spraw, które nie powinny podlegać interpretacji modelu.

Wyszukiwanie hybrydowe: semantyka plus dokładne słowa kluczowe

Samo wyszukiwanie semantyczne, przez embeddingi, czasem gubi dokładne frazy, na przykład numer artykułu ustawy albo nazwę własną, które trzeba trafić dosłownie, a nie tylko znaczeniowo. Dlatego w praktyce łączy się je z klasycznym wyszukiwaniem pełnotekstowym typu BM25, które dobrze radzi sobie właśnie z dosłownymi dopasowaniami. W polskim ten problem jest trudniejszy niż w angielskim, bo odmiana przez przypadki wymaga uwzględnienia form fleksyjnych, nie tylko dokładnego ciągu znaków.

Takie podejście hybrydowe zbudowałem w Janinie, asystentce kadrowej działającej w produkcji od 2026 roku. Przeszukuje ponad 900 dokumentów i 40 aktów prawnych, w tym orzecznictwo Sądu Najwyższego, łącząc wyszukiwanie semantyczne z BM25. Każda odpowiedź ma wskazany numer artykułu ustawy, na którym się opiera, więc dział kadr może ją zweryfikować, zamiast wierzyć modelowi na słowo. Wagi między wynikiem semantycznym a pełnotekstowym dobiera się eksperymentalnie, na realnych pytaniach. Uniwersalne ustawienie po prostu nie istnieje.

Ta sama zasada dotyczy każdej branży z gęstą, sformalizowaną dokumentacją: prawo pracy, procedury ISO, regulaminy wewnętrzne. Im więcej dosłownych odniesień, czyli numerów, dat, nazw, tym bardziej opłaca się wyszukiwanie hybrydowe zamiast czysto semantycznego. W branżach z mniej sformalizowaną wiedzą, jak wsparcie klienta, samo wyszukiwanie semantyczne zwykle wystarcza.

RAG w agentach AI - od odpowiedzi do działania

Sam RAG odpowiada na pytania. Połączony z agentem AI potrafi też działać: sprawdzić coś w CRM, zaplanować spotkanie, wygenerować dokument. Tym właśnie zajmuję się w usłudze agentów AI. Odbierają zgłoszenia z WhatsApp, maila, telefonu albo aplikacji, szukają odpowiedzi w dokumentach firmy dzięki RAG i wykonują zadania w systemach klienta, korzystając z modeli Anthropic, OpenAI, protokołu MCP i mechanizmu tool use.

Przy prostszych scenariuszach, jeden kanał, jedno pytanie, jedna odpowiedź z bazy wiedzy, wystarczy pojedynczy agent z RAG-iem. Przy procesach wieloetapowych, gdzie trzeba przejść przez kilka systemów i podjąć po drodze kilka decyzji, dokładam orkiestrację, subagentów, evale i observability. To już systemy wieloagentowe, osobna usługa, ale zbudowana na tym samym fundamencie wyszukiwania w wiedzy firmy.

Przykład z pogranicza obu podejść: agent obsługujący zgłoszenia serwisowe sprawdza w RAG-u, czy problem jest opisany w bazie wiedzy technicznej. Jeśli tak, odpowiada od razu, cytując procedurę. Gdy nie znajdzie pasującego fragmentu, przekazuje sprawę do człowieka razem z podsumowaniem tego, czego się dowiedział, zamiast zmyślać rozwiązanie. Ta decyzja, czy odpowiedzieć samodzielnie, czy eskalować, jest równie ważna jak samo wyszukiwanie.

Najczęstsze błędy przy wdrażaniu RAG

Najczęstszy błąd to złe dzielenie dokumentów na fragmenty, czyli chunking. Zbyt duże kawałki tekstu rozmywają trafność wyszukiwania, zbyt małe tracą kontekst zdania czy paragrafu. Dobry podział uwzględnia naturalną strukturę dokumentu, nagłówki, punkty, paragrafy, a nie sztywny limit znaków.

Drugi błąd to brak cytowania źródeł w odpowiedzi. Wtedy nikt nie może zweryfikować, czy model naprawdę oparł się na dokumencie, czy zaczął zmyślać. Trzeci to traktowanie bazy wiedzy jako projektu na raz, zrobione i zapomniane. Dokumenty się zmieniają, a bez procesu re-indeksacji RAG szybko zaczyna odpowiadać na podstawie nieaktualnych danych.

Czwarty błąd to pomijanie ewaluacji i observability. Bez sposobu, żeby zmierzyć, ile odpowiedzi jest trafnych, zanim system trafi do prawdziwych użytkowników, trudno cokolwiek ocenić. Bez zestawu pytań testowych ciężko sprawdzić, czy zmiana w chunkingu w ogóle coś poprawiła.

Piąty, częsty w polskich wdrożeniach z danymi wrażliwymi jak kadry, medycyna czy finanse, to zignorowanie tematu RODO i lokalizacji danych na starcie projektu, zamiast zaplanować pseudonimizację i miejsce przetwarzania danych od pierwszego dnia. Wiąże się z tym kwestia uprawnień. RAG przeszukujący dokumenty różnych działów musi respektować, kto ma prawo widzieć jaki dokument.

Ile kosztuje i ile trwa wdrożenie RAG - orientacyjne widełki

Koszt wdrożenia RAG zależy od liczby i złożoności dokumentów, od tego, czy potrzebne jest wyszukiwanie hybrydowe, oraz od tego, czy dane mają zostać w chmurze klienta, chmurze UE, czy on-premise. To orientacyjne widełki rynkowe dla małych i średnich firm w Polsce w 2026 roku, nie sztywny cennik. Dokładną wycenę ustala się zawsze po rozmowie o konkretnym przypadku.

Mój proces wygląda tak samo, niezależnie od skali. Najpierw rozmowa, 60 minut, w której Ty mówisz, co zjada czas Twojego zespołu, a ja mówię, co da się zautomatyzować. Potem prototyp, dwa tygodnie, działający agent z RAG-iem na prawdziwych danych Twojej firmy, nie na przykładowych. Dopiero po jego weryfikacji przechodzimy do uruchomienia produkcyjnego z kontrolą kosztów, logami i zgodnością z RODO od pierwszego dnia, a potem do bieżącej opieki, tak długo, jak jest potrzebna.

Dwutygodniowy prototyp na realnych danych to celowy wybór, nie skrót. Dokumenty klienta prawie zawsze mają swoje osobliwości: niespójne formatowanie, skany zamiast tekstu, nieaktualne wersje obok aktualnych. To wychodzi dopiero przy pracy z prawdziwym zbiorem, nie z próbką przygotowaną pod demo.