Dlaczego Twój system RAG halucynuje
Twój system RAG ma 34% dokładności wyszukiwania. Przeszedłeś każdy tutorial. Użyłeś odpowiednich bibliotek. Wybrałeś rozmiar fragmentu (chunk size) z wpisu na blogu. A mimo to system wciąż zawodzi.
To nie jest problem z narzędziami. To problem z fundamentami.
Kiedy nakładasz na siebie biblioteki, nie rozumiejąc warstw znajdujących się pod nimi, tworzysz dług abstrakcji. Zyskujesz szybkość, ale tracisz możliwość debugowania. Budujesz czarną skrzynkę.
Aby naprawić swój potok (pipeline) RAG, musisz opanować trzy warstwy:
Strategia chunkingu Rozmiar fragmentu (chunk size) to decyzja semantyczna. Jeśli Twoje fragmenty mają 512 tokenów, wyszukujesz akapity. Jeśli Twoje pytania wymagają łączenia idei z wielu akapitów, Twoje fragmenty są zbyt małe. Musisz zdecydować, jak dużo kontekstu przepływa między fragmentami.
Modele embeddingów Gęste embeddingi (dense embeddings) wyłapują znaczenie, ale tracą dokładną składnię. Model może traktować „error 403” i „error 404” jako niemal identyczne. Musisz wiedzieć, co Twój model wyłapuje. Umowa prawna wymaga innych embeddingów niż repozytorium kodu.
Retrieval vs. Recall (Wyszukiwanie vs. Pełność) Wyszukiwanie wektorowe znajduje wszystko, co jest potencjalnie istotne. To jest recall. Produkcyjny RAG wymaga precyzji (precision). Potrzebujesz dokładnej odpowiedzi, a nie dziesięciu podobnych akapitów. Dlatego potrzebujesz wyszukiwania hybrydowego (hybrid search).
Wyszukiwanie hybrydowe łączy gęste wektory z dopasowaniem słów kluczowych (BM25).
- Czyste wyszukiwanie semantyczne pomija dokładne kody lub identyfikatory.
- Czyste wyszukiwanie słów kluczowych pomija znaczenie koncepcyjne.
- Wyszukiwanie hybrydowe nadaje wagi obu metodom, aby znaleźć prawdę.
Odpowiednia waga nie znajduje się w instrukcji. Znajdziesz ją, testując swoje specyficzne dane.
Przestań polegać na magii. Jeśli nie potrafisz zbudować podstawowego potoku RAG od zera, nie jesteś gotowy na Agentic RAG. Złożoność mnoży się, gdy nie rozumiesz podstaw.
Zrób te cztery rzeczy przed swoim kolejnym projektem:
- Przeprowadź benchmark chunkingu. Przetestuj trzy różne rozmiary. Zmierz precyzję (precision) dla top-1 i top-5.
- Przetestuj embeddingi na rzeczywistych danych. Nie używaj testów syntetycznych. Użyj rzeczywistych zapytań użytkowników.
- Loguj błędy. Przez dwa tygodnie loguj każde zapytanie, które zawodzi. Szukaj wzorców w tym, co Twoje wyszukiwanie pomija.
- Wdróż BM25 przynajmniej raz. Nawet jeśli później będziesz używać biblioteki, musisz zrozumieć bazę (baseline) opartą na słowach kluczowych.
Biblioteki kupują Ci czas. Zrozumienie kupuje Ci niezawodność.
Optional learning community: https://t.me/GyaanSetuAi