Kiedy RAG nie wystarczy w firmowym archiwum?

Firma może mieć tysiące umów, instrukcji, prezentacji, zdjęć i nagrań, a mimo to nadal tracić godziny na znalezienie właściwej informacji. Naturalną reakcją jest pomysł: „podłączmy archiwum do AI i pytajmy je zwykłym językiem”.

To może zadziałać, ale nie każde pytanie wymaga tego samego mechanizmu. RAG dobrze wyszukuje pasujące fragmenty. Nie jest jednak bazą danych, kalkulatorem ani sposobem na zobaczenie tego, czego nie opisano w tekście.

Dlatego projekt wyszukiwarki AI warto zacząć od podziału pytań, a nie od wyboru modelu.

Najpierw zbierz prawdziwe pytania użytkowników

Zanim firma zacznie indeksować całe archiwum, powinna zebrać kilkadziesiąt rzeczywistych pytań. Szybko okaże się, że należą do różnych grup.

Przykłady:

• „Jaki jest okres wypowiedzenia w umowie z dostawcą?” — pytanie o konkretny fragment dokumentu;
• „Które umowy wygasają w następnym kwartale?” — filtrowanie wielu rekordów;
• „Jaka jest łączna wartość aktywnych umów?” — obliczenie na całym zbiorze;
• „Znajdź nagrania, na których produkt jest używany na zewnątrz” — wyszukiwanie po obrazie, a nie tylko po nazwie pliku;
• „Pokaż moment, w którym klient mówi o problemie z dostawą” — wyszukiwanie wewnątrz nagrania i transkrypcji;
• „Które instrukcje opisują ten sam wyjątek inaczej?” — porównanie kilku źródeł i wykrywanie konfliktu.

Jeżeli wszystkie te pytania trafią do jednego mechanizmu RAG, odpowiedzi mogą brzmieć przekonująco, ale część z nich będzie oparta na niepełnym zestawie danych.

Do czego RAG nadaje się dobrze?

RAG, czyli generowanie odpowiedzi z wykorzystaniem odnalezionych materiałów, zwykle dzieli dokumenty na fragmenty i wyszukuje te, które są najbardziej podobne do pytania. Model otrzymuje wybrane fragmenty jako kontekst i na ich podstawie buduje odpowiedź.

To dobre rozwiązanie, gdy użytkownik pyta:

• o zapis w jednej umowie;
• o instrukcję wykonania konkretnej czynności;
• o definicję stosowaną w firmie;
• o warunki opisane w znanym dokumencie;
• o źródła dotyczące jednego zagadnienia.

W takich przypadkach system powinien zwrócić nie tylko odpowiedź, lecz także dokument, wersję i możliwie dokładny fragment. Dzięki temu użytkownik może sprawdzić, czy wynik rzeczywiście wynika ze źródła.

Dlaczego RAG może zgubić sumę albo termin?

Typowa wyszukiwarka RAG nie przekazuje modelowi całego archiwum. Pobiera ograniczoną liczbę fragmentów najbardziej pasujących do pytania.

Jeżeli użytkownik zapyta o łączną wartość 250 umów, mechanizm może odnaleźć kilka dokumentów z polami kwotowymi, ale pominąć pozostałe. Model policzy wtedy poprawną sumę niepełnego zestawu i przedstawi ją jak odpowiedź na pytanie o całość.

Lepszy prompt nie usuwa tego ograniczenia. Problem nie polega na sposobie sformułowania pytania, lecz na tym, że do obliczenia potrzebne są wszystkie właściwe rekordy.

W materiale AWS dotyczącym analizy portfela umów zaproponowano rozdzielenie dwóch zadań:

1. pytania o pojedynczy dokument obsługuje wyszukiwanie w treści;
2. kluczowe pola z każdej umowy są wyodrębniane do bazy danych, która wykonuje filtrowanie, porównania i obliczenia.

Opis jest architekturą referencyjną dostawcy, a nie niezależnie zmierzonym wdrożeniem klienta. Mimo to dobrze pokazuje trwałą zasadę: model może pomóc zamienić dokument w dane, ale matematykę i zapytania przekrojowe warto zostawić mechanizmowi zaprojektowanemu do pracy na pełnym zbiorze rekordów.

Kiedy potrzebna jest ekstrakcja do danych strukturalnych?

Ekstrakcja ma sens, gdy te same informacje powtarzają się w wielu dokumentach i mają być później filtrowane, sumowane albo porównywane.

W przypadku umów mogą to być:

• nazwa kontrahenta;
• data podpisania;
• data rozpoczęcia i zakończenia;
• okres wypowiedzenia;
• wartość i waluta;
• status podpisu;
• właściciel biznesowy;
• termin odnowienia;
• rodzaj zobowiązania.

Nie oznacza to, że firma powinna przepisywać do tabeli każdy akapit. Strukturyzuje się pola potrzebne do decyzji przekrojowych, a oryginalny dokument pozostaje źródłem szczegółów i dowodem.

Taki podział daje dwie warstwy odpowiedzi:

• baza odpowiada na pytanie „które, ile i kiedy”;
• dokument odpowiada na pytanie „z jakiego zapisu to wynika”.

Samo wyodrębnienie pola nie wystarcza

Model może pomylić kwotę, datę, stronę umowy albo status podpisu. Dlatego rekord nie powinien automatycznie stawać się wiarygodny tylko dlatego, że został zapisany w bazie.

W architekturze referencyjnej AWS osobny agent wydobywa pola, a drugi niezależnie je sprawdza. Przy rozbieżności dotyczącej podpisu używany jest mechanizm deterministyczny, a przypadki nierozstrzygnięte mają trafiać do człowieka.

W firmowym rozwiązaniu kontrola może być prostsza, ale powinna obejmować co najmniej:

• odwołanie każdego pola do dokumentu i strony;
• format i dopuszczalny zakres wartości;
• porównanie przez drugi mechanizm lub regułę;
• oznaczenie poziomu pewności;
• kolejkę niezgodności do ręcznej oceny;
• historię korekt;
• ponowne sprawdzenie po zmianie dokumentu lub modelu.

Najważniejsze dane można dodatkowo zatwierdzić przed użyciem w raporcie finansowym, przypomnieniu o odnowieniu albo innym działaniu o skutku biznesowym.

Co zrobić z obrazem, dźwiękiem i wideo?

Nazwy plików i ręczne opisy często nie mówią, co rzeczywiście znajduje się w materiale. Film zatytułowany „IMG_4821” może zawierać właściwy produkt, wypowiedź klienta albo scenę potrzebną w kampanii, ale zwykła wyszukiwarka tego nie zobaczy.

W takim przypadku potrzebne jest wyszukiwanie multimodalne. System tworzy reprezentację nie tylko tekstu, lecz także obrazu, dźwięku i transkrypcji. Dzięki temu pytanie może dotyczyć tego, co widać, słychać albo zostało powiedziane.

Condé Nast i AWS opisały produkcyjny system przeszukujący ponad 140 tysięcy filmów po obrazie, dźwięku i transkrypcji. Według pomiaru Condé Nast z warsztatu benchmarkingowego w maju 2026 średni czas zadania wyszukiwawczego spadł z 250 minut do około 2 minut. To wynik konkretnej organizacji i samoopis klienta oraz dostawcy, a nie obietnica dla innej firmy.

Ważniejszy od samej liczby jest sposób rozwiązania problemu: użytkownicy otrzymują nie tylko nazwę filmu, ale też dokładny moment, w którym występuje szukana treść.

Rozdziel indeksowanie od obsługi pytań

Przy większym archiwum kosztowne przygotowanie materiałów nie powinno blokować bieżącego wyszukiwania.

Wdrożenie Condé Nast rozdziela:

• warstwę przyjmowania, dzielenia i indeksowania nowych filmów;
• warstwę odpowiadającą na pytania użytkowników.

Dzięki temu ponowne przetwarzanie archiwum może działać w tle, a wyszukiwarka nadal obsługuje zapytania. Ten wzorzec przydaje się także przy dokumentach: import i ponowne indeksowanie powinny być odseparowane od codziennej pracy użytkownika.

Trzeba też znać stan każdego materiału. Użytkownik powinien móc ustalić, czy plik:

• czeka na przetworzenie;
• został poprawnie zindeksowany;
• ma błąd;
• wymaga ponownej analizy;
• został wycofany;
• pochodzi z nieaktualnej wersji.

Jak wybrać właściwą architekturę?

Pomocna jest prosta mapa decyzji.

Pytanie o fragment jednego lub kilku dokumentów

Użyj wyszukiwania w treści i odpowiedzi opartej na źródłach. Wymagaj cytowania dokumentu oraz fragmentu.

Pytanie o sumę, liczbę, ranking lub termin w całym zbiorze

Wyodrębnij potrzebne pola do bazy. Obliczenia wykonuj na pełnym zestawie rekordów, a nie na kilku fragmentach zwróconych przez wyszukiwarkę.

Pytanie o to, co widać lub słychać

Zastosuj indeks multimodalny obejmujący obraz, dźwięk i transkrypcję. Zwracaj dokładny moment lub fragment materiału.

Pytanie prowadzące do działania

Oddziel odpowiedź od wykonania. Sprawdź uprawnienia, poziom pewności i reguły procesu. W przypadku dużego skutku wymagaj zatwierdzenia.

Pytanie obejmujące kilka typów informacji

Połącz mechanizmy. Jedna odpowiedź może korzystać z bazy do obliczeń, dokumentu do uzasadnienia i indeksu multimodalnego do odnalezienia właściwego nagrania.

Zacznij od małego zbioru i mierzalnego testu

Nie trzeba od razu przetwarzać całego archiwum. Lepszy pilot obejmuje jeden rodzaj materiałów, jeden zespół i jasno określone pytania.

Przed wdrożeniem zapisz punkt odniesienia:

• ile trwa znalezienie informacji dzisiaj;
• jaki odsetek odpowiedzi jest poprawny;
• ile wyników wymaga ręcznego sprawdzenia;
• ile materiałów pozostaje nieodnalezionych;
• jak często brakuje kluczowego pola;
• ile kosztuje przetwarzanie i utrzymanie zbioru.

Następnie sprawdź system na zamkniętym zestawie pytań z odpowiedziami znanymi wcześniej. Osobno oceniaj trafność wyszukania, poprawność wyodrębnionych pól, obliczenia oraz jakość wskazanego źródła.

Najważniejsze pytanie brzmi: jaki rodzaj odpowiedzi jest potrzebny?

Firmowa wyszukiwarka AI nie powinna być jednym czarnym pudełkiem do wszystkich danych. Inny mechanizm jest najlepszy do znalezienia klauzuli, inny do policzenia wartości portfela, a jeszcze inny do odnalezienia sceny w nagraniu.

Dlatego przed wyborem narzędzia podziel pytania na typy, a potem dobierz do nich właściwą warstwę danych i kontroli. RAG jest częścią rozwiązania — nie zastępuje bazy danych, reguł walidacji ani indeksu treści, której nie ma w tekście.