RAG, czyli generowanie wspomagane wyszukiwaniem, polega na tym, że system najpierw znajduje pasujące fragmenty wiedzy, a potem przekazuje je modelowi do przygotowania odpowiedzi. Brzmi jak projekt dla zespołu infrastruktury. W praktyce mała firma może zacząć od uporządkowanego projektu z dokumentami i nie musi od razu kupować bazy wektorowej o imieniu greckiego boga.
Najczęstszy błąd to zaczynanie od wyboru technologii. RAG nie naprawia bałaganu. Jeśli masz cztery wersje cennika, wyszukiwanie znajdzie wszystkie cztery i model zgodnie z nimi odpowie. Nowoczesne narzędzie sprawi tylko, że błąd dotrze szybciej. Poniżej masz drogę od źródła do działającego systemu bez zbędnej architektury.
Kiedy RAG w ogóle jest potrzebny
Zacznij od pytania, które wraca często i wymaga wiedzy firmowej: warunki oferty, status projektu, instrukcja obsługi, decyzje zeszłoroczne, zasady bezpieczeństwa. Jeżeli odpowiedź znajduje się w kilku dokumentach i trzeba je wskazać, RAG ma sens.
Jeżeli dokumentów jest garść, możesz przekazać je w całości w kontekście i nie potrzebujesz osobnego wyszukiwania. Jeżeli pytanie dotyczy ogólnej wiedzy, firmowy RAG nie pomoże. Nie buduj systemu tylko dlatego, że skrót brzmi mądrze.
Sprawdź też, czy odpowiedź ma wymagać cytatu. RAG szczególnie przydaje się tam, gdzie liczy się źródło i data. Jeżeli nikt nie sprawdza odpowiedzi, możesz skończyć z płynniejszym bełkotem zamiast wiarygodną wiedzą.
Zacznij od jednego procesu
Wybierz jedno zadanie: odpowiedzi o warunkach współpracy, pomoc nowej osobie, wyszukiwanie decyzji projektowych. Zbierz tylko dokumenty potrzebne do tego procesu. Nie przenoś całego dysku. Archiwum zainteresowań może poczekać, a folder „różne” nie jest procesem.
Ustal właściciela każdego dokumentu i status: obowiązuje, roboczy, archiwum. Nadaj datę przeglądu. Dokumenty bez właściciela trafiają do porządkowania, nie do bazy. Jeśli nie wiadomo, kto zatwierdza poprawki, system będzie cyfrowym stosem dobrych intencji.
Zapisz pięć pytań testowych przed dodaniem plików. Dzięki temu sprawdzisz, czy kolejne elementy poprawiają wynik, czy tylko komplikują życie. Mały proces ma być użyteczny od pierwszego tygodnia.
Dokument, który da się znaleźć
Dobre pliki mają opisowy tytuł, jednoznaczne nagłówki i tekst możliwy do zaznaczenia. „Warunki współpracy — wersja obowiązująca od 1 listopada” jest lepsze niż „nowa umowa finalna”. Sekcja powinna odpowiadać jednemu pytaniu lub tematowi. Tabela potrzebuje podpisu, co przedstawia.
Usuń duplikaty albo oznacz je jako archiwum. Jeżeli zostawiasz historię, spraw, by wyszukiwanie preferowało aktualne źródła. Model nie powinien wybierać nowszej wersji tylko po nazwie pliku. Data i status muszą być w treści lub metadanych.
Przy skanach sprawdź OCR przy liczbach, negacjach i nazwach. Skorzystaj z zasad z przewodnika po polskich dokumentach dla AI. RAG z błędnym tekstem jest bardzo skutecznym systemem dostarczania błędów.
Chunking, czyli nie karm modelu całą biblioteką
Na prostym etapie możesz nie myśleć o chunkach w ogóle. Gdy dokumentów przybywa, system dzieli je na mniejsze fragmenty, żeby znaleźć pasujące do pytania. Zbyt małe tracą kontekst, zbyt duże wprowadzają szum. Fragment powinien zawierać pełną myśl i odniesienie do źródła.
Nie dziel w połowie warunku, wyjątku albo tabeli. Zdanie „maksymalny limit” bez informacji, czego dotyczy, jest bezużyteczne. Zachowaj nagłówek dokumentu i sekcji przy każdym fragmencie. Dzięki temu odpowiedź będzie zrozumiała i sprawdzalna.
Zacznij od podziału po nagłówkach zamiast kombinowania z dokładną liczbą tokenów. Zmieniaj tylko jeżeli wyniki pokazują problem: złe trafienia, urwane warunki, za dużo treści. Parametr ma rozwiązywać konkretny błąd.
Wyszukiwanie musi trafić przed generowaniem
Najpierw oceń, czy system znajduje właściwy dokument i fragment. Nie pytaj jeszcze o ładną odpowiedź. Przygotuj pytania z oczekiwanym źródłem. Zaznacz trafienia, nadmiar i braki. Jeśli wyszukiwanie zawodzi, lepszy prompt tylko ukryje problem.
Przykład: pytanie o limit odpowiedzialności powinno trafić do sekcji odpowiedzialności w aktualnej umowie, nie do ogólnego opisu usług. Jeżeli wraca stara wersja, sprawdź status i indeks. Jeżeli wraca zdanie bez wyjątku, popraw fragment.
Dopiero po poprawieniu trafień oceniaj generowanie. To rozróżnienie oszczędza tygodnie poprawiania promptu, kiedy winna jest baza.
Instrukcja odpowiedzi z cytowaniem
Ustal zasady: odpowiadaj na podstawie przekazanych źródeł, wskaż tytuł i datę, oddziel fakt od interpretacji, nie zgaduj przy braku. Jeżeli źródła się różnią, pokaż konflikt. Jeżeli brakuje informacji, napisz czego brakuje i kto może ją dostarczyć.
Nie wymagaj cytatu przy każdym słowie, ale przy każdej istotnej informacji. Odpowiedź ma być czytelna, nie jak praca prawna z piętnastoma przypisami na jedno zdanie. Jeden właściwy adres źródła jest lepszy niż trzy przypadkowe.
Sprawdź, czy cytat faktycznie podpiera twierdzenie. Model może podać poprawny tytuł przy złej liczbie. To jest właśnie najbardziej podstępny rodzaj błędu.
Uprawnienia nie znikają przy wyszukiwaniu
Dokument, do którego użytkownik nie ma dostępu, nie powinien trafić do kontekstu modelu. RAG musi respektować role. Nowa osoba w sprzedaży i prawnik nie muszą widzieć tych samych materiałów. Oddziel przestrzenie lub filtruj przed wyszukiwaniem.
Nie loguj pełnych treści poufnych dokumentów. Zapisuj identyfikator zapytania, źródło i wynik. Sprawdź, co dostawca przechowuje i jak wygląda usunięcie. Jeżeli dane są wrażliwe, zacznij od mniejszego zakresu lub innej architektury.
Test uprawnień wykonaj na kontach z różnym dostępem. Prośba o informację spoza roli powinna skończyć się odmową lub brakiem źródła, a nie pomocnym wyciekiem. Zasady opisujemy także w przewodniku o bezpiecznych uprawnieniach agentów.
Kiedy wystarczy projekt z plikami
Anthropic opisuje automatyczne uruchamianie RAG w projektach, kiedy zawartość zbliża się do limitu kontekstu. W praktyce oznacza to, że możesz zacząć od projektu z dobrze nazwanymi dokumentami i grupowaniem tematów. Nie musisz od razu budować indeksu.
Taka opcja jest dobra na mały zespół i ograniczony zakres. Ma mniej konfiguracji, łatwiejszy przegląd i mniejsze ryzyko techniczne. Testuj na rzeczywistych pytaniach, nie na samej obecności funkcji.
Jeżeli potrzebujesz własnych ról, integracji z systemami, dużej skali lub szczegółowej kontroli wyszukiwania, przejdź do własnej architektury. Dopiero wtedy pojawia się potrzeba bazy wektorowej i decyzji o chunkingu.
Kiedy potrzebna jest własna baza
Własna baza przydaje się przy setkach dokumentów, wielu źródłach, wymaganych uprawnieniach i potrzebie integracji. Dodaje koszt utrzymania, monitorowania i migracji. Zapisz, jaki problem rozwiązuje: skala, kontrola, format, szybkość czy odpowiedzialność.
Nie wybieraj jej na wypadek. Zmierz liczbę dokumentów i zapytań, oczekiwany czas odpowiedzi i wymagania. Może się okazać, że największym problemem nadal są cztery wersje cennika, a nie brak wektorów.
Jeżeli potrzebujesz decyzji o architekturze, Aeneia Audit pozwala najpierw zobaczyć proces i dane. Pomocne jest również podejście z Aeneia Signal do architektury wiedzy.
Test, który mówi, czy system działa
Przygotuj dziesięć pytań z odpowiedzią, dwa bez odpowiedzi, dwa konflikty wersji i jedno spoza uprawnień. Sprawdź trafienie źródła, treść, cytat i zachowanie granicy. Zapisz błędy wyszukiwania osobno od błędów generowania.
Po każdej większej zmianie powtórz zestaw. Dodanie nowych plików nie jest poprawą samą w sobie. Jeżeli odpowiedzi pogarszają się, przywróć poprzedni zakres i sprawdź przyczynę.
Praktyczny przykład konfliktu źródeł
Wyobraź sobie dwa pliki: „Cennik obowiązujący od września” i „Cennik obowiązujący od listopada”. Pytasz o cenę audytu. Model może odpowiedzieć na podstawie pierwszego, bo tekst jest podobny do pytania. Poprawna odpowiedź powinna zaczynać się od statusu i daty: listopadowa wersja obowiązuje od listopada, starsza jest archiwum.
Zapisz w instrukcji, że system ma pokazać konflikt, a nie wybierać wygodniejszy dokument. Jeżeli obie wersje mają status „obowiązuje”, nie rozstrzygaj automatycznie. Właściciel musi poprawić status. To jest przykład problemu danych, nie wyszukiwania.
Po poprawce statusu sprawdź ten sam przypadek. Odpowiedź powinna prowadzić do nowej wersji i zawierać datę. Jeżeli nadal wraca stara, sprawdź indeks i metadane. Nie zmieniaj promptu na „bądź mądrzejszy”.
Jak testować odpowiedź bez źródła
Przygotuj pytanie, którego nie ma w dokumentach. Dobry system powinien napisać, że nie znalazł podstawy i wskazać właściciela lub kanał uzupełnienia. Nie powinien składać odpowiedzi z podobnych warunków. Brak źródła jest informacją, a nie zaproszeniem do kreatywności.
Dodaj pytanie o innego klienta albo poufny projekt. Oczekiwany wynik to brak źródła i odmowa, a nie odpowiedź na podstawie podobnej nazwy. Jeżeli system zwraca dane, problem dotyczy uprawnień, nie jakości modelu. Zablokuj przypadek i popraw filtr.
Zapisz oba typy odpowiedzi w evaluacjach. Wiele testów ocenia tylko trafienie, ale bezpieczeństwo i uczciwość braku są równie ważne. Odpowiedź „nie wiem” bywa najlepszą odpowiedzią systemu.
Aktualizacja dokumentu musi zmieniać odpowiedź
Przygotuj pytanie, którego odpowiedź zależy od ceny lub terminu. Zanotuj obecny wynik i źródło. Następnie zmień dokument źródłowy, oznacz poprzedni jako archiwum i uruchom indeksowanie zgodnie z procesem. Po zakończeniu zadaj dokładnie to samo pytanie.
Odpowiedź powinna zawierać nową wartość, aktualny identyfikator i datę. Jeżeli nadal wraca stary fragment, sprawdź kolejkę indeksowania, duplikaty i pamięć podręczną. Nie wystarczy, że plik w folderze jest poprawny. System może odpowiadać z kopii utworzonej wcześniej.
Na końcu usuń dokument testowy i potwierdź, że przestał być dostępny w wynikach. To samo ćwiczenie pokazuje drogę aktualizacji i usunięcia. Przy danych osobowych taki test powinien używać wyłącznie fikcyjnych rekordów; szerszy proces opisuje przewodnik o RODO w pracy z AI.
Obserwuj koszt i tempo, nie tylko trafność
Zapisz czas odpowiedzi od pytania do cytatu oraz czas potrzebny człowiekowi na sprawdzenie. System może zwracać właściwe źródło po dwudziestu sekundach i nadal przegrywać z wyszukiwaniem w dobrze nazwanym folderze. Jeśli proces jest wolniejszy, popraw zakres zamiast dodawać funkcje.
Przy własnej architekturze mierz także koszt indeksowania i ponownego przetwarzania zmian. Dziesięć dokumentów testowych nie pokaże kosztu tysiąca aktualizacji. Zanim zwiększysz skalę, wykonaj próbę na reprezentatywnej liczbie plików i zapisz zużycie. Architektura ma wynikać z pracy, nie z ambicji diagramu.
Minimalna konfiguracja na pierwszy tydzień
Dzień pierwszy: wybierz proces i dziesięć dokumentów. Dzień drugi: popraw tytuły, statusy i właścicieli. Dzień trzeci: przygotuj pięć pytań z oczekiwanym źródłem. Dzień czwarty: sprawdź wyszukiwanie bez generowania odpowiedzi. Dzień piąty: dodaj format z cytatem i wykonaj pełny test.
Nie dodawaj kolejnych dokumentów przed poprawieniem błędów. Po tygodniu porównaj czas wyszukiwania z pracą ręczną i liczbę odpowiedzi wymagających korekty. Jeżeli nie ma poprawy, ogranicz rolę do wyszukiwania dla człowieka. Samo dobre trafienie też jest rezultatem.
Dopiero po udanym teście zdecyduj, czy potrzebna jest własna baza, integracje i większa skala. To ogranicza koszt i czas na architekturę, której może nie potrzebować.
Dobry RAG nie pokazuje swojej złożoności. Odpowiada z aktualnego źródła, przyznaje braki i nie wychodzi poza rolę. Najpierw porządek, potem wyszukiwanie, potem model. W odwrotnej kolejności powstaje tylko szybszy sposób na zgadywanie.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
