RAG działa tak, że zanim LLM odpowie, system najpierw wyszukuje w zewnętrznej bazie wiedzy najbardziej pasujące fragmenty tekstu. Zapytanie i dokumenty są zamieniane na embeddingi (wektory), retriever wybiera top-k chunków, a potem LLM dostaje prompt z kontekstem i generuje odpowiedź „uziemioną” w źródłach.
Jak wygląda ogólna architektura RAG?
RAG to architektura „z pamięcią zewnętrzną”: LLM nie polega wyłącznie na tym, co ma zapisane w parametrach, tylko dostaje świeży kontekst z bazy wiedzy. W praktyce oznacza to pipeline: indeksowanie dokumentów → retrieval → dołączenie kontekstu do promptu → generacja. To właśnie ta pętla decyduje, czy odpowiedź jest trafna, a nie „ładna”.
Jakie są „dwa mózgi” RAG: model i baza wiedzy?
Klasyczny LLM ma pamięć parametryczną: wzorce i fakty „wtopione” w wagi po treningu. RAG dodaje pamięć nieparametryczną: zewnętrzny zbiór dokumentów (np. polityki firmy, instrukcje, artykuły, notatki), który można aktualizować bez trenowania modelu. To podejście stoi u źródeł koncepcji RAG: łączenia generacji z retrieval z indeksu wektorowego.
Co dokładnie znaczy pipeline end-to-end?
W praktycznym RAG masz dwa tryby pracy:
- Indexing (offline / batch):
- dzielisz dokumenty na fragmenty (chunking),
- liczysz embeddingi dla chunków,
- zapisujesz je w vector DB / indeksie.
- Querying (online):
- użytkownik zadaje pytanie,
- liczysz embedding pytania,
- retriever znajduje top-k podobnych chunków,
- (opcjonalnie) reranker przetasowuje wyniki,
- budujesz prompt z kontekstem,
- LLM generuje odpowiedź.
LlamaIndex pokazuje to jako „workflow” RAG, często z rerankingiem jako osobnym etapem dla jakości.
Czym jest retriever i dlaczego to on decyduje o jakości odpowiedzi?
Retriever jest bramkarzem: jeśli nie wpuści do kontekstu właściwych fragmentów, LLM nie ma z czego odpowiedzieć — nawet jeśli jest genialny. W RAG jakość odpowiedzi bardzo często ogranicza retrieval, a nie generacja: złe top-k, słaba metryka, brak filtrów lub brak rerankingu skutkują „pewną siebie” odpowiedzią na podstawie złych źródeł.
Na czym polega similarity search i vector database?
Similarity search to wyszukiwanie „po znaczeniu”, nie po słowach kluczowych. Tekst zamieniasz na wektor (embedding), a potem porównujesz wektory (np. cosinus). Vector database przechowuje wektory chunków i potrafi szybko znaleźć najbliższe sąsiedztwo dla wektora zapytania. To jest fundament retrievalu w RAG.
Co oznacza top-k i gdzie ginie recall albo precision?
top-k to liczba fragmentów, które wciągasz do kontekstu (np. 5, 10, 20). Tu zaczyna się klasyczny trade-off:
- większe k zwykle zwiększa recall (większa szansa, że „trafisz” w dobre źródło),
- ale może obniżyć precision (w kontekście pojawiają się śmieci), a do tego rośnie koszt i ryzyko rozmycia instrukcji.
W praktyce: jeśli LLM „nie wie”, choć dokumenty to zawierają — to często problem z recall (za małe k, zły indeks, złe embeddingi, złe chunki). Jeśli LLM miesza fakty — to często precision (w kontekście są fragmenty podobne tematycznie, ale nie odpowiadające na pytanie).
Po co jest reranking i dlaczego bywa game-changerem?
Retriever (pierwszy etap) ma być szybki. Reranker (drugi etap) ma być dokładny: bierze listę kandydatów i przelicza trafność droższym modelem, po czym zmienia kolejność wyników. Dokumentacje Weaviate opisują reranking jako typowy „drugi stopień” po wstępnym retrievalu, bo pełne, dokładne porównanie dla wszystkich dokumentów byłoby za wolne.
Jak powstają embeddingi w RAG?
Embeddingi to wspólny język dla zapytań i dokumentów: oba zamieniasz na wektory w tej samej przestrzeni, żeby dało się policzyć podobieństwo. W RAG embeddingi powstają w dwóch momentach: podczas indeksowania (dla chunków) i podczas zapytania (dla user query). Jeśli embeddingi są źle dobrane, retriever będzie „pewnie mylił się szybko”.
Jak modele embeddingowe zamieniają tekst na wektory?
Model embeddingowy bierze tekst i zwraca wektor liczb (np. setki lub tysiące wymiarów). Intuicja jest prosta: teksty o podobnym znaczeniu mają wektory blisko siebie. OpenAI opisuje embeddingi jako reprezentację numeryczną służącą m.in. do wyszukiwania semantycznego i rankingu wyników.
Co to jest przestrzeń semantyczna i dlaczego „działa” podobieństwo?
„Przestrzeń semantyczna” to sposób ułożenia znaczeń w geometrii: podobne pojęcia są blisko. To nie magia, tylko efekt uczenia na wielkich korpusach: model uczy się, które fragmenty języka zachowują się podobnie w kontekście. W RAG to kluczowe, bo retrieval zależy od geometrii tej przestrzeni — a nie od elokwencji LLM.
W praktyce wybór modelu embeddingowego powinien zależeć od: języka (PL/EN), domeny (prawo/medycyna/IT), długości tekstów i budżetu latencji. I tu jest pułapka: świetny LLM + średni embedding = średni RAG.
Na czym polega chunking i łączenie kontekstu?
Chunking to podział dokumentów na fragmenty, które retriever umie trafnie odnaleźć i które zmieszczą się w kontekście LLM. Zbyt duże chunki „rozmywają” podobieństwo, zbyt małe gubią sens i zależności. Overlap (nakładka) bywa prostym trikiem na urywanie definicji, tabel i akapitów.
Jaki rozmiar chunków ma sens i kiedy overlap ratuje wynik?
Nie ma jednej liczby dla wszystkich, ale są heurystyki:
- Dokumenty instrukcyjne / FAQ: mniejsze chunki (bo pytania są precyzyjne).
- Dokumenty narracyjne / raporty: większe chunki (bo kontekst rozciąga się na kilka akapitów).
- Overlap ma sens, gdy kluczowe zdanie bywa na granicy chunków (np. definicja kończy się w następnym akapicie).
Najczęstszy błąd: „tnę co 1000 znaków i jedziemy”. RAG nie lubi równego cięcia bez szacunku dla struktury: nagłówków, list, tabel, definicji, przypisów.
Jak buduje się kontekst wejściowy LLM?
Na końcu i tak lądujesz w prompt engineeringu: musisz wstawić kontekst tak, żeby model:
- rozumiał, że to źródła,
- wiedział, że ma się na nich oprzeć,
- nie mieszał źródeł ze swoimi domysłami.
Typowy układ to: instrukcja → pytanie → sekcja „KONTEKST” z chunkami (często z identyfikatorami i metadanymi) → format odpowiedzi. Im lepiej opiszesz zasady cytowania/odmowy („jeśli brak w źródłach, powiedz że brak”), tym mniej „kreatywnej pewności”.
Jak LLM korzysta z danych dostarczonych przez RAG?
LLM nie „czyta bazy” bezpośrednio — on czyta prompt. RAG działa więc wtedy, gdy kontekst jest trafny i podany w sposób, który wymusza grounding: odpowiedź ma być uziemiona w dostarczonych fragmentach. To ogranicza halucynacje, ale nie gwarantuje prawdy: jeśli retrieval przyniesie bzdury albo nie to, co trzeba, LLM nadal może brzmieć przekonująco.
Jak wygląda grounding w praktyce?
Grounding to praktyka „przywiązywania” odpowiedzi do źródeł. Najprostsze mechanizmy:
- instrukcja systemowa: „Odpowiadaj tylko na podstawie kontekstu”,
- wymóg cytowania fragmentów/ID chunków,
- reguła odmowy: „Jeśli kontekst nie zawiera odpowiedzi — powiedz, że nie wiesz”.
To nie jest kosmetyka. To jest różnica między RAG jako „search + chat” a RAG jako narzędzie pracy.
Czy RAG zawsze zapobiega halucynacjom?
Nie zawsze. RAG zmniejsza halucynacje głównie wtedy, gdy problemem jest brak świeżej/konkretnej wiedzy w parametrach modelu i da się ją dostarczyć w kontekście. Ale są przypadki, gdy halucynacje wracają:
- kontekst jest zbyt długi i model „gubi” priorytety,
- kontekst jest sprzeczny (różne wersje dokumentu),
- pytanie wymaga rozumowania poza tekstem,
- retrieval przynosi fragmenty podobne tematycznie, ale nie odpowiadające na pytanie.
Wtedy RAG jest jak latarka: świeci tylko tam, gdzie ją skierujesz. I właśnie retriever trzyma rękę.
Jak wygląda pełny przepływ zapytania krok po kroku?
Jeśli masz zapamiętać jedną rzecz: RAG to nie „LLM z PDF-em”, tylko sekwencja transformacji danych. Zapytanie staje się wektorem, wektor staje się listą źródeł, źródła stają się kontekstem, a dopiero potem LLM generuje tekst. Każdy etap ma swoje metryki jakości i swoje typowe awarie.
User query → embedding → retrieval → context → answer (schemat)
Oto prosty, praktyczny schemat:
- User query: „Jak skonfigurować X w naszej aplikacji?”
- Query embedding: model embeddingowy zamienia pytanie na wektor.
- Retrieval: vector DB znajduje np. 20 najbliższych chunków (top-k=20).
- (Opcjonalnie) Reranking: droższy model przestawia kolejność i wybiera top-n=5 najbardziej trafnych.
- Context assembly: budujesz prompt, doklejasz 5 chunków (z tytułami, datą, linkiem, ID).
- LLM generation: LLM generuje odpowiedź, najlepiej z odwołaniami do chunków.
Jeżeli chcesz „produkcyjnej” stabilności, dodajesz jeszcze: filtrowanie metadanych (np. tylko dokumenty z działu X), deduplikację chunków, kontrolę wersji dokumentów, cache dla embeddingów i ewaluację jakości retrievalu.
Dlaczego RAG bywa nieskuteczny mimo poprawnej architektury?
RAG psuje się najczęściej nie dlatego, że ktoś „źle rozumie teorię”, tylko dlatego, że drobne ustawienia systemowe kumulują błędy: embeddingi niedopasowane do języka/domeny, chunking bez struktury, top-k ustawione zbyt nisko, brak rerankingu i brak filtrów metadanych. Efekt: system działa, ale odpowiada „prawie dobrze” — czyli najgorzej, bo budzi zaufanie.
Złe embeddingi: jak to rozpoznać?
Objawy:
- wyszukujesz pojęcie A, a dostajesz dokumenty „około A”,
- podobne pytania raz trafiają, raz nie (niestabilność),
- polski język miesza się z angielskimi skrótami i retriever głupieje.
Naprawy:
- test A/B modeli embeddingowych,
- normalizacja tekstu (nagłówki, stopki, boilerplate),
- osobne indeksy dla różnych typów treści.
Zły chunking: klasyczne symptomy
- chunk zawiera pół definicji i pół innego tematu,
- chunk jest tak duży, że podobieństwo łapie „ogólny temat”,
- chunk jest tak mały, że traci sens bez sąsiadów.
Naprawy:
- chunking po strukturze (nagłówki/sekcje),
- overlap tam, gdzie definicje i procedury „przechodzą przez granice”.
Zbyt małe top-k i brak rerankingu
Top-k=3 wygląda tanio i szybko, ale może dramatycznie obniżyć recall. Bardzo częsty wzorzec produkcyjny to: większe top-k w retrieverze (np. 20–50) + reranker do top-n (np. 5–10). Weaviate opisuje reranking właśnie jako drugi etap poprawy trafności po wstępnym wyszukaniu.
Brak filtrów metadanych i wersjonowania źródeł
Jeśli indeksujesz wszystko „do jednego worka”, retrieval potrafi mieszać:
- stare i nowe wersje dokumentu,
- różne działy firmy,
- treści publiczne i wewnętrzne.
W produkcji metadane to nie luksus, tylko hamulec bezpieczeństwa.
Co warto zapamiętać?
Jeśli traktujesz RAG jak architekturę, a nie trik, zaczynasz myśleć o jakości na każdym etapie: embedding → retrieval → reranking → kontekst → generacja. LLM jest na końcu łańcucha i nie naprawi błędów wejścia. Najlepszy upgrade jakości zwykle nie polega na „większym modelu”, tylko na lepszym retrieverze, chunkingu i rerankingu.
FAQ
1) Jak działa RAG krok po kroku?
Najpierw indeksujesz dokumenty (chunking + embeddingi), potem przy pytaniu liczysz embedding zapytania, robisz similarity search w vector DB (top-k), ewentualnie rerankujesz wyniki, budujesz prompt z kontekstem i dopiero wtedy LLM generuje odpowiedź.
2) Czym różni się retriever od LLM?
Retriever wyszukuje źródła (fragmenty wiedzy) na podstawie podobieństwa wektorów, a LLM generuje tekst na podstawie promptu i dostarczonego kontekstu. Jeśli retriever da złe fragmenty, LLM zwykle „ładnie uzasadni” złą odpowiedź.
3) Dlaczego embeddingi są kluczowe w RAG?
Bo embeddingi determinują geometrię podobieństwa: to one decydują, czy „znaczeniowo podobne” teksty wylądują blisko siebie. Bez dobrych embeddingów similarity search wybiera nie te źródła, co trzeba.
4) Czy RAG zawsze zapobiega halucynacjom?
Nie zawsze. RAG ogranicza halucynacje, gdy kontekst jest trafny i wymuszasz grounding (np. regułą cytowania/odmowy). Jeśli retrieval przyniesie śmieci albo kontekst jest sprzeczny, halucynacje wracają.
5) Jakie elementy RAG najczęściej psują jakość odpowiedzi?
Najczęściej: złe embeddingi, źle dobrany chunking, zbyt małe top-k (niski recall), brak rerankingu oraz brak filtrów metadanych i kontroli wersji dokumentów.
Źródła
rtykuły naukowe o RAG (NeurIPS / arXiv, Lewis i in. 2020) arXiv
Dokumentacja embeddingów i wyszukiwania semantycznego (OpenAI) OpenAI Platform
Dokumentacje baz wektorowych i rerankingu (Weaviate) Weaviate Documentation
Przykładowe workflow RAG z rerankingiem (LlamaIndex) LlamaIndex+