Jak działa RAG i kiedy warto połączyć AI z dokumentami firmy?

Jaki problem rozwiązuje RAG?

Pracownik pyta, jak obsłużyć reklamację po zmianie procedury. Sam model językowy nie zna aktualnych ustaleń tej firmy. Może udzielić ogólnej, poprawnie brzmiącej odpowiedzi, która nie odpowiada przyjętym zasadom. RAG pozwala oprzeć odpowiedź na odnalezionych materiałach zamiast polegać wyłącznie na wiedzy zapisanej w parametrach modelu.

W publikacji wprowadzającej RAG połączono model generujący tekst z zewnętrznym indeksem informacji. W firmowym zastosowaniu istotne jest to samo rozróżnienie: model formułuje odpowiedź, a dokumenty dostarczają wiedzy, którą można aktualizować i wskazać czytelnikowi. Samo dołączenie wyszukiwarki nie rozstrzyga jednak, czy odnaleziony dokument jest właściwy.

Źródła: Lewis i in.: Retrieval-Augmented Generation

Najpierw porządek w dokumentach, potem wyszukiwanie

Materiały trzeba przygotować do odczytu, podzielić na użyteczne fragmenty i powiązać z informacją o źródle. Wyszukiwanie może łączyć dopasowanie słów z podobieństwem znaczenia. To pomaga, gdy pracownik używa innego określenia niż autor instrukcji. Źle odczytany skan lub fragment pozbawiony kontekstu nadal może prowadzić do błędnej odpowiedzi.

Praktyczny punkt startu to jeden proces i ograniczony zbiór zatwierdzonych dokumentów. Każdy powinien mieć właściciela, wersję, datę obowiązywania i określoną grupę odbiorców. Dwie sprzeczne instrukcje nie stają się spójną procedurą tylko dlatego, że trafiły do wspólnego indeksu. Trzeba ustalić, która jest aktualna, oraz co system ma zrobić, kiedy nie umie tego rozstrzygnąć.

Źródła: Microsoft: przygotowanie treści i wyszukiwanie w RAG

Przykład: odpowiedź o terminie reklamacji

Załóżmy, że wewnętrzna instrukcja w wersji 3 opisuje termin odpowiedzi na zgłoszenie, a starsza wersja 2 podaje inny termin. To przykład organizacyjny, nie interpretacja przepisów. Dobra odpowiedź wskazuje obowiązującą wersję, przytacza sens właściwego fragmentu i pozwala otworzyć źródło. Jeśli data obowiązywania nie jest znana, powinna ujawnić tę niepewność.

Test odbiorowy nie polega wyłącznie na zadaniu pytania, na które znamy odpowiedź. Usuwamy potrzebny dokument, zmieniamy jego wersję i pytamy o sytuację nieobjętą instrukcją. Sprawdzamy, czy system potrafi odmówić rozstrzygnięcia. Wiarygodne „brak podstaw w dostępnych dokumentach” jest lepsze niż dopisanie nieistniejącej zasady.

Czy dokument może zmienić polecenia dla AI?

Takie ryzyko istnieje. Plik może zawierać instrukcję próbującą skłonić model do ujawnienia danych lub pominięcia ograniczeń. OWASP opisuje to jako pośredni prompt injection. RAG nie usuwa tego zagrożenia: odnaleziona treść pozostaje materiałem do analizy, a nie upoważnieniem do zmiany zasad działania.

Dlatego prawa do dokumentów sprawdza aplikacja, nie sam model. Użytkownik bez dostępu do akt innego działu nie powinien otrzymać ich fragmentów również przez wyszukiwarkę. Osobno kontrolujemy indeks, logi i kopie. Model lokalny może ograniczyć wysyłanie danych do zewnętrznego dostawcy, ale nie zastępuje uprawnień ani polityki przechowywania.

Źródła: OWASP: prompt injection i ograniczanie uprawnień

Co sprawdzić przed udostępnieniem pracownikom?

Przygotuj zestaw pytań wraz z dokumentem i fragmentem, na którym powinna opierać się odpowiedź. Oceniaj osobno trafność wyszukiwania oraz zgodność końcowej odpowiedzi ze źródłem. Zapisuj wersję dokumentów i modelu, aby po aktualizacji móc powtórzyć tę samą próbę. Nie przedstawiaj wyniku na kilku wygodnych przykładach jako skuteczności dla całej firmy.

• Poprawna odpowiedź zawiera właściwe źródło i aktualną wersję.
• Brak danych oraz sprzeczne instrukcje kończą się jawną informacją o ograniczeniu.
• Próby odczytu materiałów innego zespołu są odrzucane.
• Wycofany dokument znika z wyników, a awaria źródła nie jest ukrywana.
• Czas odpowiedzi, koszt oraz liczba ręcznych poprawek mieszczą się w uzgodnionych granicach.