RAG (retrieval-augmented generation) to sposób pracy, w którym model przed udzieleniem odpowiedzi pobiera fragmenty dokumentów firmy i odpowiada na ich podstawie, podając źródła. Zamiast polegać na tym, co model „wie" z treningu, system najpierw wyszukuje właściwy fragment, a dopiero potem generuje odpowiedź.
Dlaczego kontekst decyduje o wszystkim
Model językowy generuje odpowiedź, przewidując kolejne fragmenty tekstu. Bez dostępu do Twoich danych odpowie ogólnie — i zrobi to płynnie, niezależnie od tego, czy trafił. W sprzedaży B2B to problem praktyczny: pytania dotyczą konkretnej oferty, konkretnych warunków i konkretnych wdrożeń.
RAG przenosi ciężar z „pamięci" modelu na wyszukiwanie: jakość odpowiedzi zależy odtąd głównie od tego, co jest w bazie wiedzy i jak dobrze da się w niej znaleźć właściwy fragment.
Jakie źródła wiedzy mają sens
| Źródło | Co daje | Na co uważać |
|---|---|---|
| Oferty i cenniki | konkretne warunki, zakresy, wyłączenia | wersjonowanie — nieaktualna oferta to najgorszy możliwy kontekst |
| Opisy usług i materiały produktowe | spójny język, granice zakresu | rozjazd z tym, co mówi zespół |
| Notatki z CRM | historia ustaleń z klientem | dane osobowe i uprawnienia |
| Case studies | dowód i przykłady | rozróżnienie danych źródłowych od wniosków |
| Dokumentacja techniczna | odpowiedzi na pytania szczegółowe | aktualność |
| Wewnętrzne FAQ i onboarding | powtarzalne pytania zespołu | duplikaty i sprzeczne wersje |
Dobra praktyka: zacznij od dwóch–trzech źródeł, które są aktualne i mają właściciela. Baza wiedzy złożona z wszystkiego, co firma kiedykolwiek napisała, odpowiada równie pewnie na podstawie dokumentu sprzed trzech lat.
Uprawnienia: najczęstszy błąd projektowy
Wspólna baza wiedzy bez odwzorowania uprawnień sprawia, że system odpowiada każdemu na podstawie wszystkiego. W praktyce oznacza to, że przez pytanie można wyciągnąć treść, do której pytający nie ma dostępu w źródłowym systemie.
Zasady, które stosujemy:
- Uprawnienia sprawdzane przy wyszukiwaniu, a nie po wygenerowaniu odpowiedzi.
- Metadane dostępu przy każdym fragmencie — kto może go zobaczyć, z jakiego systemu pochodzi.
- Dane osobowe tylko wtedy, gdy są potrzebne do zadania — notatki z CRM da się indeksować z pominięciem danych kontaktowych.
- Rozdzielenie baz dla różnych grup odbiorców zamiast jednej z filtrowaniem na końcu.
Aktualność
Baza wiedzy starzeje się szybciej niż dokumentacja, bo oferty i warunki zmieniają się częściej niż strony produktowe. Minimalna higiena:
- każdy fragment ma datę i wersję źródła;
- zmiana dokumentu unieważnia jego starszą wersję w indeksie, zamiast dokładać kolejną;
- dokumenty bez właściciela nie wchodzą do bazy;
- odpowiedź pokazuje, z czego korzystała, żeby dało się sprawdzić, czy źródło jest aktualne.
Ryzyko zmyślonych odpowiedzi
RAG ogranicza zmyślanie, ale go nie eliminuje. Typowe sytuacje, w których system odpowiada błędnie mimo poprawnej architektury:
- Brak fragmentu w bazie — model odpowiada „z siebie", jeśli nie zabroniono mu tego wprost.
- Fragment nie na temat — wyszukiwanie zwróciło coś podobnego językowo, ale nie merytorycznie.
- Dwa sprzeczne źródła — system wybiera jedno, nie sygnalizując konfliktu.
- Pytanie o wniosek, nie o fakt — „czy im się opłaci" nie jest pytaniem, na które odpowiada dokument.
Przeciwdziała się temu projektowo: jawna instrukcja „odpowiadaj tylko na podstawie źródeł, w przeciwnym razie powiedz, że nie wiesz", obowiązkowe cytowanie fragmentów, wykrywanie odpowiedzi bez pokrycia i — przy wyższej stawce — akceptacja człowieka.
Praktyczna architektura
Minimalny, sprawdzony układ dla zastosowań sprzedażowych:
- Zbieranie — konektory do źródeł (dysk, CRM, repozytorium ofert) z zachowaniem metadanych i uprawnień.
- Przygotowanie — podział dokumentów na fragmenty o sensownej długości, z nagłówkami i kontekstem dokumentu.
- Indeks — wyszukiwanie semantyczne uzupełnione o wyszukiwanie po słowach kluczowych; nazwy własne, numery ofert i symbole wypadają w czystym wyszukiwaniu semantycznym.
- Wyszukiwanie z filtrem uprawnień — zawsze przed generowaniem.
- Generowanie z cytowaniem — odpowiedź plus odnośniki do fragmentów.
- Ewaluacja — zestaw pytań z oczekiwanymi odpowiedziami, uruchamiany po każdej zmianie bazy, promptu lub modelu.
- Monitoring — jakość, koszt i odsetek odpowiedzi „nie wiem" (nagły spadek zwykle oznacza, że system zaczął zgadywać).
Kiedy RAG nie jest odpowiedzią
- Gdy wiedza mieści się na jednej stronie — wystarczy wkleić ją do polecenia.
- Gdy pytania dotyczą danych strukturalnych z jednego systemu — zapytanie do bazy jest tańsze i pewniejsze.
- Gdy dokumenty są nieaktualne i nikt ich nie porządkuje — wtedy najpierw porządek, potem indeks.
Jeśli baza wiedzy ma obsługiwać zadania wieloetapowe, a nie pojedyncze pytania, wchodzi w grę agent AI — z tymi samymi uprawnieniami i tym samym śladem audytowym.
Najczęstsze pytania
Czy RAG to to samo co dotrenowanie modelu?
Nie. Dotrenowanie zmienia zachowanie modelu, RAG dostarcza mu treści w momencie odpowiedzi. W zastosowaniach sprzedażowych zwykle wystarcza RAG — i łatwiej go aktualizować, bo zmiana dokumentu działa od razu.
Czy nasze dokumenty trafią do treningu modelu?
To zależy od warunków dostawcy modelu i wybranego trybu przetwarzania. Te warunki są opisane w jego dokumentacji i trzeba je przeczytać przed wdrożeniem; kwestie umowne warto potwierdzić z prawnikiem.
Jak duża musi być baza wiedzy, żeby to miało sens?
Nie chodzi o rozmiar, tylko o powtarzalność pytań. Kilkanaście dokumentów, o które ktoś pyta co tydzień, daje więcej niż tysiąc, do których nikt nie zagląda.
Skąd wiadomo, że system odpowiada dobrze?
Z zestawu pytań kontrolnych z oczekiwanymi odpowiedziami, uruchamianego po każdej zmianie. Bez niego ocena opiera się na wrażeniu z kilku zapytań.
Powiązana usługa:AI & LLM Systems — RAG i systemy wiedzy, integracje, guardraile oraz monitoring jakości i kosztów.