Z jakich dokumentów powinien korzystać twój asystent RAG?

Najpierw zbierz prawdziwe pytania

Kuszący pierwszy krok to skierowanie indeksera na witrynę SharePoint albo przestrzeń w wiki i sprawdzenie, co z tego wyjdzie. Powstaje indeks wszystkiego, łącznie ze szkicami i nieaktualnymi procedurami, a przy złej odpowiedzi nikt nie wie, czy właściwego dokumentu brakowało, czy był nieaktualny, czy zginął wśród innych.

Wytyczne Microsoftu dla projektów RAG zakładają równoległe zbieranie treści i pytań testowych, bo na pytania musi dać się odpowiedzieć na podstawie treści, a treści muszą odpowiadać na istotne pytania. Prosimy zespół, który będzie korzystał z asystenta, o 30 do 50 pytań, którymi zajmował się ostatnio, wziętych z ticketów, wątków na czacie albo maili. Prawdziwe pytania pokazują słownictwo, przypadki brzegowe i dokumenty, które mają znaczenie.

Dodaj kilka pytań, na które dokumenty nie powinny odpowiadać, żeby testy odróżniały pewną siebie błędną odpowiedź od słusznej odmowy.

Inwentarz źródeł: jeden wiersz na źródło

Dla każdego źródła, które bierzesz pod uwagę, zapisz kilka faktów. Od nich zależy reszta projektu, a wystarczy do tego arkusz.

• Właściciel: osoba lub zespół, który wie, czy treść jest aktualna, i odpowiada, gdy jest błędna
• System i lokalizacja: gdzie leżą dokumenty, na przykład w przestrzeni wiki, bibliotece dokumentów albo systemie ticketowym
• Status: czy źródło jest wersją zatwierdzoną, roboczym szkicem czy nieformalnymi notatkami
• Oznaczenie wersji: po czym odróżnisz aktualny dokument od starszego, na przykład po polu statusu, dacie albo regule nazewnictwa
• Reguły dostępu: kto może je czytać w systemie źródłowym i czy konektor potrafi te reguły odczytać
• Format i stan: tekst, zeskanowany PDF, arkusz albo slajdy, oraz czy da się faktycznie wyciągnąć z nich tekst
• Tempo zmian: jak często dokumenty są dodawane, edytowane albo wycofywane

Źródło bez właściciela nie powinno trafić do pierwszego indeksu. Gdy da błędną odpowiedź, nikt nie poprawi dokumentu, a asystent będzie powtarzał błąd, dopóki ktoś tego nie zauważy.

Przypisz każdemu pytaniu fragment, który na nie odpowiada

Do każdego pytania znajdź fragment, który na nie odpowiada, i zapisz dokument, sekcję i wersję. Przewodnik Microsoftu opisuje taki sam rekord dla zestawu testowego RAG: pytanie, tekst źródłowy z lokalizacją i poprawną odpowiedź. Rozpoczęcie od małej próbki przygotowanej ręcznie to bezpośredni sposób, żeby sprawdzić, na co pozwalają twoje dokumenty.

Każde pytanie kończy w jednym z czterech stanów.

1. 1

   Odpowiedź w jednym zatwierdzonym źródle

   Gotowe do testów. Zapisz fragment jako oczekiwany dowód.

2. 2

   Odpowiedź jest, ale w sprzecznych źródłach

   Dwa dokumenty sobie przeczą, często stara i nowa wersja. Ktoś musi przed indeksowaniem zdecydować, która jest obowiązująca, bo inaczej zdecyduje za ciebie wyszukiwanie.

3. 3

   Odpowiedź tylko w nieformalnym miejscu

   Odpowiedź jest w wątku na czacie albo w czyjejś notatce. Albo właściciel przeniesie ją do zatwierdzonego dokumentu, albo pytanie na razie wypada z zakresu.

4. 4

   Brak odpowiedzi gdziekolwiek

   To luka w dokumentacji i żadne ustawienie wyszukiwania jej nie naprawi. Asystent powinien odmówić odpowiedzi, a luka trafia do właściciela danego tematu.

Hipotetyczny audyt dla wewnętrznego helpdesku IT

Załóżmy, że zespół IT chce asystenta do pytań pracowników i zbiera 40 ostatnich ticketów. Liczby są zmyślone na potrzeby przykładu.

Dwadzieścia dwa pytania prowadzą do aktualnej strony w wiki IT. Siedem prowadzi zarówno do wiki, jak i do starszego podręcznika w PDF, który wciąż leży na dysku sieciowym i w kwestii konfiguracji VPN przeczy wiki. Na pięć odpowiedź jest tylko na kanale zespołu na czacie. Na sześć nie ma odpowiedzi nigdzie, głównie w sprawie modelu laptopa wprowadzonego w zeszłym kwartale.

Decyzja wynika z tych wierszy. Wiki wchodzi do indeksu. Podręcznik PDF zostaje poza nim, dopóki właściciel go nie wycofa albo nie poprawi rozdziału o VPN. Pięć odpowiedzi z czatu zamienia się w dwie nowe strony wiki napisane przez osobę, która tych odpowiedzi udzieliła. Sześć pytań o laptopa staje się przypadkami testowymi, w których asystent musi powiedzieć, że nie ma udokumentowanej odpowiedzi.

Sprawdzenie samych plików

Gdy wiadomo już, które źródła wchodzą w zakres, otwórz pliki. Niektóre problemy psują wyszukiwanie na długo przed tym, zanim znaczenie będzie miał rozmiar chunków czy wybór modelu.

• Zeskanowane PDF-y bez warstwy tekstowej wymagają OCR albo ekstrakcji obsługującej obrazy, zanim indeks tekstowy będzie mógł z nich korzystać, inaczej zostają poza nim
• Nagłówki, stopki, spisy treści i zastrzeżenia powtarzają się na każdej stronie i wypierają właściwą treść
• Długie tabele po podzieleniu tracą wiersz nagłówka, więc wartości pod nim tracą znaczenie
• Identyfikatory, takie jak numery części czy kody błędów, wymagają dokładnego dopasowania, z którym samo wyszukiwanie semantyczne radzi sobie słabo

Żadnego z tych problemów nie trzeba rozwiązywać w trakcie audytu. Zapisz je, bo każdy zmienia sposób budowy ingestii i jej koszt.

Gdy audyt pokazuje, że wystarczy mniej niż RAG

Czasem przydatnego materiału jest niewiele: kilka zatwierdzonych polityk, które rzadko się zmieniają. Artykuł Anthropic z września 2024 roku sugerował, że bazę wiedzy poniżej około 200 000 tokenów, czyli mniej więcej 500 stron, można umieścić wprost w prompcie, a prompt caching obniży koszt i opóźnienie. Sprawdź, czy to się sprawdza przy oknie kontekstu i cenniku wybranego modelu. Tak czy inaczej pytania i oczekiwane fragmenty z audytu staną się zestawem testowym.

Zdarza się też wynik odwrotny. Jeśli większość pytań kończy jako luka albo sprzeczność, pierwszym projektem jest praca nad dokumentacją, bo asystent zbudowany na takich źródłach głównie odmawiałby odpowiedzi albo przeczył sam sobie.

Praktyczny następny krok: zbierz w tym tygodniu 30 prawdziwych pytań i ręcznie przypisz dziesięć z nich do źródeł.

Tworzenie systemów RAG