Odpowiedzi oparte na dokumentach firmy — jak działa RAG
RAG to układ, w którym system najpierw wyszukuje fragmenty Twoich dokumentów pasujące do pytania, a dopiero potem formułuje odpowiedź wyłącznie na ich podstawie. Rozwiązuje w ten sposób podstawowy problem modeli językowych: nie znają Twojej firmy, a zapytane wprost wygenerują odpowiedź brzmiącą wiarygodnie i najczęściej nieprawdziwą.
Krótka odpowiedź: RAG (Retrieval-Augmented Generation) to połączenie dwóch kroków — wyszukania właściwych fragmentów w bazie dokumentów oraz wygenerowania odpowiedzi na ich podstawie, ze wskazaniem źródła.
Praktyczna konsekwencja: jakość odpowiedzi zależy przede wszystkim od jakości wyszukiwania. Jeśli krok pierwszy znajdzie niewłaściwy fragment, najlepszy model wygeneruje na jego podstawie niewłaściwą odpowiedź.
Dlaczego nie wystarczy sam model
Model językowy działa na wiedzy, którą przyswoił podczas uczenia. Nie zna Twojego cennika, terminów realizacji ani zapisów regulaminu. Zapytany o nie, nie odpowie „nie wiem" — wygeneruje najbardziej prawdopodobną odpowiedź, czyli taką, która brzmi jak odpowiedź typowej firmy z Twojej branży.
Druga możliwość to wkleić całą dokumentację do treści pytania. Działa przy kilku stronach, przestaje przy kilkuset: koszt rośnie z każdym znakiem, a jakość spada, bo model gubi się w nadmiarze materiału.
RAG rozwiązuje oba problemy. Do modelu trafia wyłącznie kilka fragmentów faktycznie związanych z pytaniem — jest tanio, szybko i precyzyjnie.
Jak przebiega odpowiedź
| Krok | Co się dzieje | Gdzie bywają problemy |
|---|---|---|
| 1. Przygotowanie bazy | Dokumenty dzielone na fragmenty i indeksowane | Zły podział rozrywa sens w pół zdania |
| 2. Pytanie użytkownika | Zapytanie zamieniane na formę porównywalną z fragmentami | Pytanie ogólne pasuje do wszystkiego i do niczego |
| 3. Wyszukanie | System znajduje kilka najbardziej pasujących fragmentów | Trafność wyszukiwania decyduje o całości |
| 4. Generowanie | Model formułuje odpowiedź wyłącznie na podstawie fragmentów | Model uzupełnia luki własną wiedzą, jeśli mu na to pozwolisz |
| 5. Wskazanie źródła | Odpowiedź wraca razem z odnośnikiem do dokumentu | Pominięcie tego kroku uniemożliwia weryfikację |
Podział na fragmenty — decyzja o największych skutkach
Dokument trzeba pociąć, bo do modelu trafiają fragmenty, nie całość. Sposób cięcia przesądza o jakości bardziej niż wybór modelu.
Fragment zbyt krótki traci kontekst — zdanie „termin wynosi czternaście dni" nie mówi, czego dotyczy. Fragment zbyt długi rozmywa dopasowanie: zawiera treść z kilku tematów, więc pasuje do wielu pytań powierzchownie.
- Tnij po nagłówkach, nie po liczbie znaków. Sekcja dokumentu jest naturalną jednostką znaczeniową.
- Zachowaj nagłówek w treści fragmentu, żeby wyrwany z kontekstu wiedział, czego dotyczy.
- Stosuj zakładkę między fragmentami — kilka zdań powtórzonych na styku zapobiega rozcięciu myśli w pół.
- Nie rozdzielaj tabel. Tabela rozcięta na pół traci sens w obu częściach.
- Dołącz nazwę dokumentu do każdego fragmentu — pozwala odróżnić regulamin od oferty.
Uwaga praktyczna: gdy odpowiedzi są nietrafne, pierwszym odruchem bywa zmiana modelu na lepszy. W praktyce w zdecydowanej większości przypadków przyczyną jest krok wyszukiwania — system podaje modelowi niewłaściwe fragmenty. Sprawdź, co faktycznie trafia na wejście, zanim zaczniesz zmieniać cokolwiek innego.
Dwa sposoby wyszukiwania
Wyszukiwanie znaczeniowe
Fragmenty i pytanie zamieniane są na reprezentację liczbową oddającą sens, a system szuka najbliższych. Zaleta: znajduje treść pasującą znaczeniowo, nawet gdy użyto innych słów — pytanie o „oddanie towaru" trafi do sekcji o zwrotach.
Wada: gubi dopasowania dosłowne. Zapytanie o konkretny numer artykułu albo symbol produktu bywa pomijane, bo znaczeniowo nie wyróżnia się z tła.
Wyszukiwanie po słowach
Klasyczne dopasowanie tekstowe. Doskonałe przy symbolach, numerach i nazwach własnych, bezradne przy synonimach.
Połączenie obu
W praktyce najlepiej sprawdza się układ hybrydowy: system wykonuje oba wyszukiwania i łączy wyniki. Przy dokumentacji zawierającej zarówno opisy, jak i symbole — a taka jest większość dokumentacji firmowej — różnica w trafności bywa wyraźna.
Gdzie ten układ zawodzi
RAG nie jest rozwiązaniem uniwersalnym. Warto znać przypadki, w których zawodzi systematycznie.
- Pytania wymagające policzenia. „Ilu mamy klientów w województwie" wymaga zapytania do bazy, nie wyszukania fragmentu tekstu.
- Pytania obejmujące cały zbiór. „Które umowy kończą się w tym kwartale" wymaga przejrzenia wszystkiego, a system pobiera kilka fragmentów.
- Porównania między dokumentami. „Czym różni się wariant A od B" działa tylko wtedy, gdy oba opisy trafią do wyszukania jednocześnie.
- Pytania o to, czego nie ma. Brak informacji w dokumentach powinien dać odpowiedź „nie znalazłem", a nie próbę wnioskowania.
- Wiedza rozproszona po wielu miejscach. Odpowiedź wymagająca złożenia pięciu fragmentów z różnych dokumentów bywa niekompletna.
Przy pytaniach pierwszego i drugiego typu właściwym rozwiązaniem jest zapytanie do bazy danych, ewentualnie formułowane przez model — ale to już inny mechanizm niż RAG.
Jak zmierzyć jakość przed wdrożeniem
Bez pomiaru wdrożenie opiera się na wrażeniu z kilku przypadkowych pytań. To za mało, żeby wypuścić system do klientów.
- Przygotuj zestaw testowy — kilkadziesiąt realnych pytań z prawidłowymi odpowiedziami i wskazaniem, w którym dokumencie się znajdują.
- Mierz osobno wyszukiwanie — czy właściwy fragment w ogóle znalazł się wśród pobranych. To najważniejszy pojedynczy wskaźnik.
- Mierz osobno odpowiedź — czy jest poprawna i czy trzyma się dostarczonych fragmentów.
- Sprawdź zachowanie przy braku danych. Zadaj pytania, na które dokumenty nie odpowiadają, i sprawdź, czy system się przyzna.
- Powtórz pomiar po każdej zmianie bazy albo konfiguracji. Poprawa w jednym miejscu bywa pogorszeniem w innym.
Koszty i wydajność
Każda odpowiedź to koszt przetworzenia pytania wraz z dołączonymi fragmentami. Rachunek rośnie z liczbą zapytań i z ilością materiału podawanego modelowi.
Praktyczne sposoby ograniczania: podawaj mniej fragmentów, ale trafniejszych; zapamiętuj odpowiedzi na pytania powtarzalne; ustaw limity zużycia i alert przy przekroczeniu progu. Warto też rozróżnić zapytania proste od złożonych i kierować je do modeli o różnej wydajności — nie każde pytanie wymaga najmocniejszego dostępnego rozwiązania.
Od czego zacząć
Kolejność ma znaczenie, bo najczęstszą przyczyną nieudanych wdrożeń jest rozpoczęcie od technologii zamiast od materiału.
- Uporządkuj dokumenty — to warunek wstępny, opisany szerzej w materiale o bazie wiedzy firmowej.
- Zbierz pytania testowe od osób obsługujących klientów.
- Zbuduj najprostszą wersję i zmierz trafność wyszukiwania.
- Popraw podział na fragmenty, jeśli trafność jest niska — to zwykle tu leży problem.
- Dodaj wskazywanie źródła od pierwszej wersji, nie jako element opcjonalny.
- Uruchom dla zespołu wewnętrznie, zanim system zobaczy klient.
Co poprawić, gdy trafność jest niska
Gdy system odpowiada nietrafnie, warto przechodzić poniższe punkty po kolei. Kolejność odpowiada temu, jak często dana przyczyna okazuje się właściwa.
1. Sprawdź, co trafia na wejście modelu
Zapisz fragmenty pobrane przy konkretnym nietrafnym pytaniu i przeczytaj je. W większości przypadków od razu widać, że właściwej treści wśród nich nie ma — a wtedy problem leży w wyszukiwaniu, nie w generowaniu.
2. Przyjrzyj się podziałowi dokumentów
Czy właściwy fragment istnieje w bazie w sensownej postaci? Częsty przypadek: odpowiedź jest rozcięta między dwa fragmenty, więc żaden z nich nie zawiera jej w całości i żaden nie wygrywa dopasowania.
3. Rozszerz zapytanie
Pytanie użytkownika bywa krótkie i nieprecyzyjne. Pomaga wygenerowanie kilku wariantów tego samego pytania i wyszukanie każdego z nich, a następnie połączenie wyników. Kosztuje jedno dodatkowe wywołanie, a wyraźnie poprawia trafność przy pytaniach potocznych.
4. Dołóż wyszukiwanie po słowach
Jeśli dokumentacja zawiera symbole, numery katalogowe albo nazwy własne, samo wyszukiwanie znaczeniowe będzie je gubić. Układ hybrydowy rozwiązuje ten problem.
5. Przefiltruj wyniki
Pobranie większej liczby fragmentów, a następnie ocenienie ich przydatności i przekazanie modelowi tylko najlepszych, poprawia jakość odpowiedzi kosztem jednego dodatkowego kroku.
6. Dopiero teraz rozważ zmianę modelu
Jeśli właściwe fragmenty trafiają na wejście, a odpowiedź nadal jest zła, przyczyną może być model albo sposób sformułowania polecenia. To jednak ostatnia rzecz do sprawdzenia, nie pierwsza.
Jak system rozwija się w czasie
Wdrożenie RAG nie kończy się w dniu uruchomienia. Baza dokumentów żyje, pytania użytkowników się zmieniają, a jakość odpowiedzi wymaga stałej obserwacji.
Najcenniejszym źródłem informacji o tym, co poprawić, są pytania, na które system nie znalazł odpowiedzi. Zapisywane systematycznie tworzą po miesiącu listę realnych braków w dokumentacji — opartą na tym, czego ludzie faktycznie szukają, a nie na przypuszczeniach zespołu.
Drugim źródłem są odpowiedzi ocenione przez użytkowników jako nietrafne. Warto dać prostą możliwość zgłoszenia takiej sytuacji jednym kliknięciem i przeglądać te zgłoszenia raz w tygodniu. Powtarzający się wzorzec wskazuje zwykle na konkretny dokument wymagający poprawy albo na fragment podzielony w niewłaściwym miejscu.
Podsumowanie
RAG jest dziś standardowym sposobem budowania systemów odpowiadających na pytania o wiedzę firmową — nie dlatego, że jest wyrafinowany, lecz dlatego, że pozwala zweryfikować każdą odpowiedź przez wskazanie źródła. Ta jedna właściwość odróżnia system użyteczny od takiego, któremu nie sposób zaufać.
Jeśli planujesz wdrożenie, największą uwagę poświęć dwóm rzeczom: jakości dokumentów i trafności wyszukiwania. Wybór modelu jest decyzją odwracalną i najmniej istotną z całej trójki. O tym, gdzie taki system ma sens, a gdzie nie, pisaliśmy przy okazji granic AI w obsłudze klienta, a szerszy kontekst znajdziesz na stronie AI w firmie.
Najczęstsze pytania
To układ łączący wyszukiwanie z generowaniem: system najpierw znajduje w bazie dokumentów fragmenty pasujące do pytania, a następnie formułuje odpowiedź wyłącznie na ich podstawie, wskazując źródło. Dzięki temu odpowiada na pytania o wiedzę firmową, której model sam z siebie nie zna.
Działa przy kilku stronach, przestaje przy kilkuset. Koszt przetwarzania rośnie z każdym znakiem, a jakość odpowiedzi spada, bo model gubi się w nadmiarze materiału. RAG podaje modelowi tylko kilka fragmentów faktycznie związanych z pytaniem, co jest tańsze i precyzyjniejsze.
W zdecydowanej większości przypadków przyczyną jest krok wyszukiwania, który podaje modelowi niewłaściwe fragmenty. Zanim zaczniesz zmieniać model, sprawdź, co faktycznie trafia na jego wejście. Częstym źródłem problemu jest zły podział dokumentów na fragmenty.
Wymagających policzenia lub przejrzenia całego zbioru danych — na przykład ilu jest klientów w danym regionie albo które umowy kończą się w tym kwartale. System pobiera kilka fragmentów tekstu, więc do takich zadań właściwe jest zapytanie do bazy danych, a nie wyszukiwanie w dokumentach.
Przygotuj kilkadziesiąt realnych pytań z prawidłowymi odpowiedziami i wskazaniem dokumentu źródłowego. Mierz osobno trafność wyszukiwania i poprawność odpowiedzi, a dodatkowo sprawdź, czy system przyznaje się do niewiedzy przy pytaniach, na które dokumenty nie odpowiadają.
Bezpłatna wycena Twojego projektu
Opisz w kilku zdaniach, co chcesz zbudować — stronę, aplikację czy sklep. Odpowiadamy w ciągu 24 godzin roboczych konkretną propozycją zakresu i harmonogramu. Konsultacja i wycena są bezpłatne, bez zobowiązań.