Własna baza wiedzy dla AI: jak zbudować RAG, z którego model naprawdę korzysta

Mam folder z umowami, notatkami ze spotkań, opisami procesów i starymi ofertami, a model i tak odpowiada ogólnikami albo dopowiada sobie rzeczy, których tam nie ma. Problem prawie nigdy nie leży w modelu, tylko w tym, w jakiej formie dostaje moje materiały. Pokażę, jak zbudować bazę wiedzy, z której AI faktycznie czyta, i jak to sprawdzić zamiast wierzyć na słowo.

Dlaczego wklejanie wszystkiego naraz nie działa

Pierwszy odruch jest zawsze ten sam: wrzucę do czatu pięćdziesiąt stron i zapytam. Czasem zadziała, ale to najgorszy możliwy sposób pracy z własnymi dokumentami i warto wiedzieć, dlaczego.

• Okno kontekstu to nie pamięć. Wszystko, co wkleisz, znika po zamknięciu rozmowy. Za tydzień robisz to samo od nowa, tyle że z nowszą wersją pliku (albo starszą, bo pomyliłeś załączniki).
• Model gubi środek. Przy długim wklejeniu najlepiej pamięta początek i koniec. Zdanie ukryte w trzydziestej stronie ma realną szansę zostać zignorowane.
• Szum topi sygnał. Osiem akapitów o niczym i jeden z odpowiedzią oznacza, że zamiast cytatu dostaniesz ładne podsumowanie tematu ogólnie.
• Mieszasz wersje. Stara oferta i nowy cennik wyglądają dla modelu identycznie wiarygodnie. Odpowie średnią z obu i zabrzmi przy tym bardzo pewnie.
• Model woli odpowiedzieć niż przyznać, że nie wie. Jeśli nie zmusisz go strukturą i poleceniem, żeby oparł się wyłącznie na podanym materiale, wypełni lukę wiedzą ogólną.

RAG po ludzku: trzy klocki i jeden bibliotekarz

RAG (retrieval augmented generation, czyli generowanie wspomagane wyszukiwaniem) brzmi groźnie, a jest prostym pomysłem: zanim model odpowie, ktoś podsuwa mu właściwe fragmenty Twoich dokumentów. Model nie dostaje biblioteki, tylko pięć zakładek, które bibliotekarz uznał za trafne.

Składa się to z trzech klocków:

1. Magazyn kawałków. Twoje dokumenty pocięte na fragmenty, każdy z opisem, skąd pochodzi.
2. Wyszukiwarka. Mechanizm, który na podstawie pytania wybiera kilka najbardziej pasujących kawałków. To ona decyduje o jakości całości, nie model.
3. Model. Dostaje pytanie plus wybrane kawałki i ma napisać odpowiedź wyłącznie z nich, z podaniem źródła.

Najważniejsze zdanie tego tekstu: o jakości RAG decyduje krok drugi i to, co włożyłeś do pierwszego. Ludzie tygodniami zmieniają model, kiedy problemem jest to, że wyszukiwarka podaje nie te fragmenty.

Krok 1: zdecyduj, co w ogóle wchodzi do bazy

Największy błąd na starcie to wrzucenie wszystkiego, co jest na dysku. Baza wiedzy nie jest archiwum. Archiwum ma być kompletne, baza wiedzy ma być aktualna i jednoznaczna. Każdy dokument, który mówi coś innego niż sąsiedni, obniża jakość wszystkich odpowiedzi, nie tylko własnych.

Przy każdym pliku odpowiadam sobie na cztery pytania: czy to jest aktualne, czy to jedyne źródło tej informacji, czy ktoś zadaje o to pytania, czy wolno mi to tam wrzucić. Jedno „nie” i plik zostaje poza bazą.

Prompt, którym przepuszczam listę plików, zanim cokolwiek zacznę ciąć:

Jestem jednoosobową firmą i buduję bazę wiedzy dla asystenta AI.
Poniżej wklejam listę dokumentów: nazwa pliku, data modyfikacji, jedno zdanie o zawartości.

Dla każdego dokumentu zwróć wiersz tabeli:
1. Nazwa
2. Decyzja: DO BAZY / ARCHIWUM / POMIŃ
3. Powód decyzji w maksymalnie 12 słowach
4. Ryzyko konfliktu: z którym innym dokumentem z listy może się kłócić
5. Jakie realne pytanie użytkownika ten dokument obsługuje

Nie proponuj dodawania dokumentów, których nie ma na liście.
Jeśli dwa dokumenty wyglądają na różne wersje tego samego, oznacz to wprost.

LISTA:
[wklej]

Punkt czwarty jest tu najcenniejszy. Konflikty wersji to najczęstsza przyczyna odpowiedzi, które brzmią dobrze i są nieprawdziwe.

Krok 2: posprzątaj dokumenty, zanim je pokroisz

Wyszukiwarka pracuje na tekście, więc wszystko, co nie jest tekstem, jest dla niej niewidzialne albo szkodliwe. Kilka rzeczy robię zawsze:

• Zamieniam na zwykły tekst z nagłówkami. PDF ze skanu bez rozpoznanego tekstu to w praktyce pusta strona.
• Wyrzucam powtarzalne śmieci. Stopki, numery stron, klauzule poufności. Powtórzone sto razy potrafią przykryć treść w wynikach wyszukiwania.
• Rozwijam skróty i wewnętrzny żargon. Klient zapyta pełną nazwą, nie skrótem.
• Opisuję tabele zdaniem. Sama siatka liczb po pocięciu przestaje cokolwiek znaczyć.
• Dopisuję daty. Na górze dokumentu: czego dotyczy, od kiedy obowiązuje, kto odpowiada. Bez tego model nie rozstrzygnie, która wersja jest nowsza.

Przygotuj poniższy dokument do bazy wiedzy dla asystenta AI.

Zasady:
- Zachowaj WSZYSTKIE fakty, liczby, nazwy i warunki. Nic nie skracaj merytorycznie.
- Nie dodawaj informacji, których w tekście nie ma. Jeśli czegoś brakuje,
  dopisz na końcu listę BRAKI zamiast zgadywać.
- Usuń elementy powtarzalne: stopki, numery stron, nagłówki drukarskie.
- Nadaj strukturę nagłówków ## i ###, jeden temat na sekcję.
- Przy pierwszym użyciu skrótu podaj pełną nazwę w nawiasie.
- Nad każdą tabelą dopisz jedno zdanie: czego dotyczy i co znaczą kolumny.
- Na samej górze wstaw blok: Tytuł, Czego dotyczy, Obowiązuje od,
  Status (aktualne/archiwum), Dla kogo.

DOKUMENT:
[wklej]

Krok 3: dzielenie na kawałki, czyli miejsce, gdzie większość ludzi się przewraca

Narzędzia domyślnie tną tekst co iluś znaków. To działa na prozie i psuje wszystko inne: ucina tabelę w połowie, oddziela warunek od wyjątku, rozdziela pytanie od odpowiedzi. Moja zasada jest prosta: jeden kawałek to jedna kompletna myśl, którą człowiek zrozumie bez czytania sąsiadów.

Praktycznie oznacza to cztery reguły:

1. Tnij po nagłówkach, nie po znakach. Sekcja jest naturalną jednostką sensu. Jeśli wyszła bardzo długa, podziel ją na podsekcje w źródle, a nie na ślepo w narzędziu.
2. Nie rozdzielaj rzeczy, które tracą sens osobno. Tabela, lista kroków procedury, warunek razem z wyjątkiem, pytanie razem z odpowiedzią.
3. Dopisz nagłówek kontekstowy do każdego kawałka. To najtańsza poprawa jakości, jaką znam. Fragment zaczyna się linijką w stylu „Dokument: Regulamin zwrotów, sekcja: Termin odstąpienia, status: aktualne” i przestaje być anonimowy.
4. Zrób lekkie zakładki. Niech kolejne kawałki nachodzą na siebie o jedno, dwa zdania. Zdanie na styku nie ginie.

Metadane, czyli opis, dzięki któremu kawałek daje się znaleźć

Do każdego fragmentu dopisuję krótki opis wygenerowany przez model. Chodzi o to, żeby fragment zawierał także słowa, których użyje pytający, a których w oryginale nie ma. Dokument pisany językiem prawnika ma być znajdowany pytaniem zadanym językiem klienta.

Dla poniższego fragmentu dokumentu wygeneruj metadane. Nie streszczaj całego
dokumentu, tylko ten fragment. Nie dodawaj faktów spoza fragmentu.

Zwróć dokładnie w tej formie:
STRESZCZENIE: jedno zdanie, co ten fragment ustala
PYTANIA: 5 pytań, na które ten fragment odpowiada, zadanych językiem
  zwykłego użytkownika, nie językiem dokumentu
SŁOWA POTOCZNE: 5 określeń, których ludzie używają na to, co tu opisano,
  a które nie padają w tekście
CZEGO NIE ZAWIERA: jedno zdanie o tym, czego w tym fragmencie NIE ma,
  a ktoś mógłby się spodziewać

FRAGMENT:
[wklej]

Pole „czego nie zawiera” wygląda na fanaberię, a ratuje przed najgorszym rodzajem błędu: model dostaje fragment blisko tematu, zakłada, że to odpowiedź, i dopowiada resztę.

Krok 4: prompt systemowy, który wymusza odpowiedź ze źródła

Nawet z idealną bazą model domyślnie „pomoże”. Trzeba mu odebrać tę możliwość wprost. Ten prompt systemowy trzymam w jednym pliku i wklejam do każdego narzędzia, którego używam:

Jesteś asystentem odpowiadającym WYŁĄCZNIE na podstawie fragmentów
dostarczonych w sekcji MATERIAŁY. Twoja wiedza ogólna nie jest źródłem.

ZASADY:
1. Każde zdanie odpowiedzi musi wynikać z MATERIAŁÓW. Po każdym twierdzeniu
   podaj w nawiasie nazwę dokumentu i sekcję.
2. Jeśli w MATERIAŁACH nie ma odpowiedzi, napisz dokładnie:
   „Nie ma tego w bazie” i dopisz, jakiego dokumentu brakuje.
3. Nie uzupełniaj luk wiedzą ogólną. Nie szacuj. Nie podawaj typowych
   wartości rynkowych ani standardowych terminów.
4. Jeśli fragmenty są ze sobą sprzeczne, NIE wybieraj. Pokaż oba,
   z datami, i napisz, że wymaga to rozstrzygnięcia przez człowieka.
5. Jeśli fragment ma status „archiwum”, oznacz to w odpowiedzi.
6. Na końcu każdej odpowiedzi dopisz linijkę:
   PEWNOŚĆ: wysoka / średnia / niska oraz jedno zdanie dlaczego.

FORMAT:
Odpowiedź (zwięźle, maksymalnie 6 zdań)
ŹRÓDŁA (lista dokumentów z sekcjami)
PEWNOŚĆ

PYTANIE:
[pytanie]

MATERIAŁY:
[fragmenty]

Zasada czwarta bywa niewygodna, bo zamiast gotowej odpowiedzi dostaję zadanie do odrobienia. Ale to jest dokładnie ta informacja, której potrzebuję: w bazie leży sprzeczność i trzeba ją usunąć u źródła.

Krok 5: jak sprawdzić, czy model odpowiada z Twoich materiałów, a nie z pamięci

To jest część, którą prawie wszyscy pomijają, a bez niej cała reszta jest wiarą. Model potrafi odpowiedzieć poprawnie, mimo że wyszukiwarka nie podała mu niczego sensownego, po prostu dlatego, że temat jest popularny. Wtedy masz sprawny wygląd i niedziałający mechanizm. Używam czterech testów.

Test kanarka

Do kilku dokumentów wpisuję informację, której nie da się znać z zewnątrz: wewnętrzny kod procedury, nietypowy próg, nazwę własną mojego procesu. Potem pytam o nią wprost. Jeśli model nie zwraca kanarka, wyszukiwarka do tego dokumentu nie dociera, a dotychczasowe trafne odpowiedzi brały się z wiedzy ogólnej. To jedyny test, który dowodzi, że baza w ogóle jest czytana.

Test pustej bazy

Zadaję pytanie z dziedziny, której celowo w bazie nie ma, ale która jest popularna w internecie. Poprawny wynik to „Nie ma tego w bazie”. Rozbudowana, sensowna odpowiedź znaczy, że prompt systemowy nie trzyma.

Test cytatu

Biorę odpowiedź, otwieram wskazany dokument i szukam w nim kluczowej frazy. Nie sprawdzam, czy brzmi prawdziwie, tylko czy da się ją odnaleźć w źródle.

Test parafrazy

Zadaję to samo pytanie na trzy sposoby: językiem dokumentu, językiem klienta i z literówką. Jeśli działa tylko pierwszy wariant, wyszukiwarka dopasowuje słowa zamiast sensu i trzeba wzmocnić metadane z kroku trzeciego.

Żeby to nie było jednorazową zabawą, robię stały zestaw pytań kontrolnych i przepuszczam go po każdej większej zmianie w bazie:

Na podstawie poniższych dokumentów ułóż 20 pytań testowych do mojej bazy wiedzy.

Podział:
- 10 pytań, na które odpowiedź JEST w materiałach (podaj też oczekiwaną
  odpowiedź i dokument źródłowy)
- 5 pytań z tej samej dziedziny, na które odpowiedzi NIE MA w materiałach
  (oczekiwany wynik: „Nie ma tego w bazie”)
- 5 pytań podchwytliwych: zadanych potocznym językiem, z błędnym założeniem
  albo dotyczących dwóch dokumentów naraz

Nie wymyślaj treści dokumentów. Pytania mają wynikać z tego, co wkleiłem.
Zwróć tabelę: numer, pytanie, typ, oczekiwana odpowiedź, źródło.

DOKUMENTY:
[wklej]

Do oceny wyników używam drugiej rozmowy, w której model występuje jako sprawdzający i nie widzi mojej sympatii do własnego systemu:

Oceń odpowiedź asystenta pod kątem oparcia na źródle. Nie oceniaj,
czy jest prawdziwa w świecie, tylko czy wynika z podanych fragmentów.

Zwróć:
WERDYKT: W PEŁNI ZE ŹRÓDŁA / CZĘŚCIOWO / SPOZA ŹRÓDŁA
ZDANIA BEZ POKRYCIA: wypisz dosłownie te zdania odpowiedzi,
  których nie da się wyprowadzić z fragmentów
BŁĘDNE ŹRÓDŁO: czy wskazany dokument faktycznie zawiera to twierdzenie
JEDNO ZDANIE UZASADNIENIA

FRAGMENTY:
[wklej]

ODPOWIEDŹ ASYSTENTA:
[wklej]

Kiedy RAG jest niepotrzebny

Nie każdy problem z dokumentami wymaga bazy wiedzy. Jeden dokument czytany raz na miesiąc wystarczy wkleić do czatu. Przy pytaniach o wiedzę powszechną baza tylko przeszkadza. Przy materiale zmieniającym się co godzinę potrzebujesz połączenia z systemem źródłowym, a nie kopii sprzed doby. Baza zarabia na siebie wtedy, gdy masz kilkadziesiąt dokumentów, powtarzalne pytania i realną cenę za błędną odpowiedź.

Pułapki, na których traciłem najwięcej czasu

• Stare wersje obok nowych. Numer wersji w nazwie pliku nic nie da, bo wyszukiwarka patrzy na treść. Status i data muszą być w tekście kawałka.
• Skany bez rozpoznanego tekstu. Plik waży megabajty i wnosi zero. Sprawdzaj, czy da się w nim zaznaczyć tekst.
• Za małe kawałki. Dwa zdania wyrwane z procedury brzmią jak odpowiedź, a są połową warunku. Za duże to znowu wklejanie wszystkiego, tylko w mniejszej skali.
• Jeden zbiór na wszystko. Notatki prywatne, dokumenty klientów i materiały publiczne w jednym worku to pytanie o czas, kiedy coś wypłynie w odpowiedzi nie dla tych oczu.
• Brak właściciela aktualizacji. Baza, której nikt nie odświeża, po trzech miesiącach jest gorsza niż jej brak, bo ludzie już jej ufają.

Plan na jeden weekend

Tak to układam, gdy zaczynam od zera i nie chcę utonąć:

1. Sobota rano. Wypisuję dwadzieścia pytań, które naprawdę padają. Nie zaczynam od dokumentów, tylko od pytań. Dopiero potem szukam plików, które na nie odpowiadają.
2. Sobota w południe. Audyt plików promptem z kroku pierwszego. Pięć do dziesięciu dokumentów, reszta czeka.
3. Sobota po południu. Czyszczenie i nadawanie struktury. Najnudniejszy i najbardziej opłacalny etap.
4. Niedziela rano. Cięcie na kawałki i metadane. Wstawiam kanarki.
5. Niedziela po południu. Prompt systemowy, zestaw dwudziestu pytań testowych, przebieg i tabela wyników.

Jeśli po pierwszym przebiegu trafność jest słaba, prawie zawsze winne są trzy rzeczy w tej kolejności: dokument nie wszedł do bazy, kawałek został źle pocięty, metadane nie zawierają języka, którym pytają ludzie. Zmiana modelu jest ostatnią rzeczą, którą warto próbować, a pierwszą, o której się myśli.

Baza wiedzy to nie projekt, który się kończy, tylko nawyk: nowy dokument wchodzi w tym samym formacie co poprzednie, stary dostaje status archiwum zamiast znikać po cichu, a raz na miesiąc przepuszczam zestaw kontrolny.

Tekst powstał z pomocą AI i został zredagowany przez człowieka.