Wyjaśnienie RAG: Jak powstrzymać chatboty przed wymyślaniem faktów o firmie

Zwykłe wczesne zadanie dotyczące chatbotów wygląda tak: odpowiadanie na pytania z dokumentów firmy. Szybki prototyp często brzmi profesjonalnie — a jednocześnie wymyśla fakty. Może twierdzić, że oferuje „wsparcie 24/7 w 12 krajach”, podczas gdy wsparcie istnieje tylko w jednym kraju, wyłącznie w godzinach pracy i tylko wtedy, gdy jest dostępna określona osoba IT.

To właśnie ten problem stanowi sedno technologii RAG (Retrieval-Augmented Generation): model, który może udzielić odpowiedzi, nie jest tym samym co model, który ma rzeczywiste dane organizacji. Bez takiego uzasadnienia modele zachowują się jak pewny siebie krewny, który na weselu wymyśla historię rodziny — około czterdzieści procent informacji jest prawdziwych, a sto procent — pewnych.

Część 1: Czym właściwie jest RAG?

RAG oznacza Retrieval-Augmented Generation. Idea jest prosta.

Zamiast prosić model o odpowiedź wyłącznie na podstawie pamięci treningowej, system najpierw pobiera odpowiednie materiały, a następnie żąda odpowiedzi opartej wyłącznie na tych materiałach.

Traktuj model tekstu jak biegłego, ale zbyt pewnego siebie stażystę: doskonałego w pisaniu, ale słabego w przywoływaniu zasad HR z 2023 roku. Zadaniem RAG jest dostarczenie właściwej strony stażystzie przed rozpoczęciem odpowiedzi.

Bez RAG: odpowiedzi opierają się na pamięci (przestarzałej, ogólnej lub nieodpowiadającej specyfice firmy). Z RAG: odpowiedzi opierają się na pamięci oraz plikach pobranych specjalnie dla tego pytania.

Kompaktowa formuła, która się sprawdza:

Prawidłowe informacje × Prawidłowy kontekst × Prawidłowy prompt = Prawidłowa odpowiedź

Część 2: Proces RAG

Rozszerzanie poprzez pobieranie danych to nie jedna magiczna operacja. To wieloetapowa ścieżka: jeśli któryś z etapów zawiedzie, odpowiedzi przychodzą późno lub są błędne.

Stopień 1 — Źródła wiedzy

Gdzie znajduje się materiał? Pliki PDF, pliki Word, strony w Notion, tabele SQL, eksporty z Slacka oraz zapomniane arkusze kalkulacyjne – wszystko to stanowi źródła wiedzy.

Stopień 2 — Załadunek dokumentów (wprowadzanie danych)

Proces przetwarzania zamienia pliki PDF/HTML/CSV itp. na czysty, jednolity format – zazwyczaj coś w rodzaju:

Document(
  page_content="The quick brown fox...",
  metadata={"source": "annual_report.pdf", "page": 12, "author": "Finance Team"}
)

Pomijanie starannego załadunku i bezpośrednie wprowadzanie surowych bajtów PDF do strumienia danych często powoduje, że nagłówki i stopki traktowane są jako „fakty” („Zgodnie z stroną 47 z 92…”). Nikt nie prosił o te dodatkowe elementy.

Lekcja: brudne przetwarzanie danych prowadzi do brudnego wyszukiwania i błędnych odpowiedzi. Trzeba dbać o czystość na wstępie.

Stopień 3 — Dzielenie na fragmenty (inaczej: krojenie pizzy)

200-stronicowy plik PDF nie może zostać po prostu włożony do zapytania. Okna kontekstowe są ograniczone, a przepełnianie modelu całym przewodnikiem kulinarnym, gdy poproszono tylko o jedną recepturę, pogarsza dokładność wyników.

Dokumenty są zatem dzielone na segmenty.

Powszechne strategie:

• Dzielenie o stałej wielkości — dzielenie co N tokenów. Szybkie, ale dochodzi do cięć w środku zdań.
• Dzielenie o stałej wielkości z nakładaniem się — te same cięcia z niewielkim nakładaniem się, dzięki czemu kontekst graniczny zostaje zachowany. Powszechny standard.
• Dzielenie hierarchiczne/recyrtyczne — uwzględnianie sekcji i akapitów przed dokonaniem cięć.
• Dzielenie semantyczne — grupowanie zdań o tym samym temacie za pomocą embeddingów. Mniej efektywne, ale wymagające większych zasobów obliczeniowych.
• Dzielenie oparte na modelach LLM / Agentic — pytanie modelu o to, gdzie powinny nastąpić cięcia. Drogie, przydatne w tekstach prawniczych lub medycznych.

Praktyczna zasada po obserwowaniu, jak w umowie po wyrażeniu „shall” następuje cięcie po frazie „shall NOT be liable”: najpierw stosuj dzielenie o stałej wielkości z nakładaniem się; dodawaj większą złożoność tylko wtedy, gdy jakość wydobywania informacji jest rzeczywiście słaba.

Stopień 4 — Embeddingi (przekształcanie słów w współrzędne GPS)

Embedding przekształca zdanie w listę liczb, która odzwierciedla znaczenie, a nie pisownię. Zdania o podobnym znaczeniu znajdują się blisko siebie, nawet jeśli nie mają żadnych wspólnych słów.

Zdania „Jak można sprostować hasło?” i „Zapomniano dane logowania” nie mają prawie żadnych wspólnych elementów, a mimo to oznaczają niemal to samo. Wyszukiwanie według słów kluczowych pomija tę zależność; embeddingi ją wykrywają poprzez porównywanie znaczeń.

Historia rozwoju przechodziła od modelu Bag-of-Words (liczącego tylko występowanie słów) → TF-IDF → Word2Vec → BERT → nowoczesnych interfejsów do embeddingów oraz otwartych modeli (OpenAI, Cohere, BGE, E5 i inne), które uwzględniają kontekst.

Analogia: Model Bag-of-Words to tłumaczenie maszynowe słowo po słowie. Nowoczesne embeddingi przypominają kogoś, kto żył w obu kulturach i potrafi zrozumieć intencję.

Stopień 5 — Magazyny wektorowe (baza danych, w której przechowuje się wszystkie te listy liczb)

Gdy segmenty stają się wektorami, potrzebują szybkiego przechowywania i wyszukiwania: Pinecone, Qdrant, Weaviate, Milvus, ChromaDB, FAISS oraz podobne systemy.

Dla danej zapytania należy zwrócić najlepsze K segmentów, których wektory znajdują się najbliżej wektora zapytania. Opcje indeksowania obejmują:

• Siła bruta — porównanie wszystkiego. Dokładne, ale wolne w dużych skali.
• ANN (Approximate Nearest Neighbor) — nieco mniej dokładne, ale znacznie szybsze. Solidny standard domyślny.
• IVF — najpierw tworzenie klastrów; wyszukiwanie tylko w obiecujących klastrach.
• HNSW — szybkie przemieszczanie się po grafie sąsiedztwa. Powszechne w produkcji RAG.

Zastosowanie siły bruty do milionów wektorów „dla doskonałej dokładności” może przekształcić zapytania trwające kilka milisekund w opóźnienia na poziomie przerwy na herbatę. Dobieraj indeks do wielkości danych, a nie do dumy.

Krok 6 — Wyświetlanie wyników (Wyszukiwanie podobieństwa)

Gdy pojawia się pytanie, należy je włączyć za pomocą tego samego modelu używanego do plików — mieszanie modeli to klasyczny błąd — a następnie pobrać najbardziej podobne segmenty z grupy top-K.

Podobieństwo kosinowe jest standardowym miernikiem: pokazuje, na jak dobrze dwa wektory są zgodne pod względem kierunku, ignorując ich długość. Jest to stabilny standard przy różnych długościach tekstu.

Krok 7 — Wzbogacanie (przekazanie internowi odpowiedniego pliku)

Pobrane segmenty są wstawiane do promptu razem z pytaniem użytkownika. To właśnie jest krok „Wzbogacania”:

System: You are a helpful assistant. Only answer using the context below.
Context: [retrieved chunk 1] [retrieved chunk 2] [retrieved chunk 3]
Question: What is our refund policy?

Krok 8 — Generowanie (LLM w końcu mówi)

Dopiero wtedy model tworzy ostateczną odpowiedź — opartą na pobranych danych kontekstowych, a nie na innych czynnikach.

Część 3: Czym różni się „działa” od „działa dobrze”

Przewodniki często kończą się na opisie podstawowego procesu. Jakość systemów w warunkach rzeczywistych zazwyczaj wymaga czegoś więcej.

Ponowna klasyfikacja — ponieważ pierwszy wynik wyszukiwania nie zawsze jest najlepszym

Metoda bi-encoderów do wyszukiwania jest szybka, ale mało precyzyjna: zapytanie i dokument są kodowane oddzielnie, a następnie porównywane. Doskonale nadaje się do ograniczenia milionów elementów do około 50 kandydatów.

„Szybko i mniej więcej poprawnie” nie zawsze oznacza „faktycznie poprawnie”, dlatego wolniejszy cross-encoder do ponownej klasyfikacji ocenia zapytanie i dokument razem, uwzględniając niuanse, negacje i kontekst. Działa tylko na wybranej liście i podnosi jakość prawdziwie najlepszych wyników.

Analogia: bi-encodery przeglądają rezyumé w celu stworzenia krótkiej listy; cross-encodery przeprowadzają rozmowy kwalifikacyjne.

W botie FAQ medycznym bez ponownego rankowania pytanie dotyczące interakcji z alkoholem może wyświetlić inne lek, który jedynie dzieli ze sobą słownictwo. Ponowny ranker oparty na kodowaniu krzyżowym często natychmiast to naprawia. Gdy ważna jest precyzja (w kwestiach prawniczych, medycznych czy finansowych), ponowne rankowanie jest obowiązkowe, a nie opcjonalne.

Połączone wyszukiwanie — ponieważ zarówno wyszukiwanie leksykalne, jak i wektorowe są samodzielnie nieco nieskuteczne

Wyszukiwanie wektorowe uchwytuje znaczenie, ale może pominąć dokładne tokeny — kody SKU, identyfikatory błędów, nazwy własne. Wyszukiwanie leksykalne BM25 precyzyjnie znajduje dokładne ciągi znaków, ale pomija synonimy.

Połączone wyszukiwanie łączy metodę BM25 z odzyskiwaniem informacji wektorowymi: precyzję słów kluczowych z semantycznym odzyskiwaniem informacji. Gdy nie ma pewności, połączone rozwiązanie stanowi solidny standard — rzadko jest gorsze, często lepsze.

Fuzja RAG — łączenie kilku opinii jak w projekcie grupowym (ale tym razem naprawdę działa)

Wielokrotne narzędzia wyszukiwania (gęste, oparte na słowach kluczowych, specyficzne dla domeny) generują kilka uporządkowanych list. RAG Fusion łączy je z Reciprocal Rank Fusion (RRF).

Idea jest prosta, mimo że formuła wydaje się formalna: dokument, który zajmuje wysokie miejsce w kilku niezależnych metodach, jest prawdopodobnie istotny. RRF nagradza spójność pomiędzy listami, a nie surowe wyniki, które nie są porównywalne pomiędzy różnymi narzędziami wyszukiwania.

RRF(d) = Σ  1 / (k + rank_i(d))

Tutaj k zazwyczaj wynosi 60 – to konwencja branżowa, a nie stała wyprowadzona matematycznie.

Metryki — etykiety, które później uratują ci życie

Metryki to dane o danych: tytuł, autor, data, źródło, poziom dostępu. Wydają się nudne, dopóki nie pojawi się reguła dostępu – „nigdy nie pokazywać wewnętrznych dokumentów HR użytkownikom z zewnątrz” – i wtedy tagi access_level: internal nagle stają się istotne.

Metryki umożliwiają stosowanie filtrów, wzmocnienia rankingu, kontrolę dostępu oraz debugowanie („dlaczego dokument z 2019 roku odpowiedział na pytanie z 2026 roku?” → brak filtrów datowych).

Pamięć i buforowanie — ponieważ nikt nie chce dwa razy płacić za tę samą obliczanie

Dwie koncepcje, które są często mylone:

• Pamięć = długoterminowe przechowywanie preferencji, poprzednich interakcji oraz trwałych faktów.
• Buferowanie = krótkoterminowe ponowne wykorzystanie kosztownych wyników (odpowiedzi modelu, wyniki wyszukiwania) przy powtarzających się zapytaniach.

Pamięć sprawia, że asystenci zachowują spójność. Buforowanie sprawia, że są szybcy i tanie w obsłudze. Mieszanie tych dwóch elementów — na przykład buforowanie preferencji z czasem ważności dziesięciu minut — może spowodować usunięcie imienia użytkownika w trakcie rozmowy. Trzymaj te koncepcje oddzielnie.

Część 4: Kiedy nie należy używać RAG?

Rozszerzanie poprzez wyodrębnianie danych nie jest uniwersalnym rozwiązaniem.

Pomijaj RAG w następujących sytuacjach:

• Pytanie dotyczy wiedzy ogólnej, z którą model już radzi sobie („stolica Francji” nie wymaga indeksu wektorowego).
• Fakty ciągle się zmieniają (ceny, wyniki na żywo) – lepiej użyć API.
• Zadanie ma charakter wyłącznie kreatywny (poezja, burza mózgów) – wyszukiwanie rzadko pomaga.
• Korpus jest na tyle mały, że można go umieścić bezpośrednio w instrukcji.
• Bardzo niska latencja nie toleruje dodatkowego kroku wyszukiwania.

Czasami rozwiązaniem jest dostosowanie instrukcji lub drobna kalibracja modelu, a nie pełny proces wektorowy. Wybierz narzędzie przed rozpoczęciem pracy.

Część 5: Najlepsze praktyki nabyte na błędach

1. Dziel treść mądrze, a nie na małe fragmenty. Małe segmenty tracą kontekst; duże segmenty tracą precyzję. Lepiej zachować nakładanie się fragmentów.
2. Używaj jednego narzędzia do embedowania plików i zapytań. Mieszanie modeli oznacza pomiar w mieszanych jednostkach.

Dodaj ponowną klasyfikację, gdy ważna jest dokładność. Niewielka opóźniona reakcja przy dużych ulepszeniach jakości.

Oznacz metadane od samego początku. Przyszłe filtry będą tego potrzebować.

Ewaluuj stale. Śledź Recall@k / Precision@k oraz wierność/relewność generowanych treści. Nastrój nie jest miarą.

Zachowuj cache drogich, stabilnych obliczeń; odświeżaj tylko to, co się zmienia. Nie zamykaj w lodówce szybko zmieniających się faktów; nie obliczaj ponownie tych statycznych.

Zachowuj zasady bezpieczeństwa. Moderacja, cytaty oraz sprawdzanie halucynacji zapobiegają kłamstwom w demonstracjach.

Zespoły, które traktują proces wydobywania informacji jako kwestię drugorzędną, zazwyczaj ponownie napotykają te same problemy: cichą zmianę schematu w narzędziach ładowania, granice fragmentów, które dzielą negacje, niezgodności modeli w procesach indeksowania offline i wyszukiwania online, oraz panele kontrolne, które mierzą jedynie „opóźnienie odpowiedzi”, ignorując przy tym jej dokładność. Skuteczna praktyka RAG traktuje każdy etap procesu jako odrębną powierzchnię produktową z określonymi odpowiedzialnymi, testami oraz planami odwracania działań — szczególnie gdy asystent pracuje z klientami lub w środowiskach podlegających regulacjom.

Przy ocenie zmian należy preferować eksperymenty parowe: ten sam zestaw pytań, ta sama rubryka oceny, porównanie wskaźników Recall@k i groundedness przed i po modyfikacjach dotyczących dzielenia na fragmenty lub zmian w algorytmach rankowania. Niewielkie ulepszenia w procesie wydobywania informacji często przewyższają większe zmiany dotyczące samego promptu, ponieważ generator nie może powołać się na to, co nigdy nie trafiło do okna kontekstowego.

Mantra RAG

Prawidłowe informacje → Prawidłowy kontekst → Prawidłowy prompt → Prawidłowa odpowiedź.

RAG to technologia, a nie magia. Czyste źródła danych, rozsądne wydobywanie informacji, uczciwe wzbogacanie treści oraz precyzyjny prompt sprawiają, że zbyt pewny siebie „kuzyn” staje się dobrze poinformowanym specjalistą, który najpierw przeczyta plik — i przestaje wymyślać nieistniejącą całodobową obsługę klienta.