Co to jest RAG na dokumentach firmy: możliwości i granice

RAG może znajdować fragmenty dokumentów firmowych i przygotowywać odpowiedzi powiązane ze źródłami, ale nie jest trenowaniem modelu, maszyną prawdy ani zamiennikiem kontroli dostępu.

W poniedziałek rano kierowniczka działu HR pyta wewnętrznego asystenta, jak długo należy przechowywać dane kandydatów, i otrzymuje przekonującą odpowiedź z linkiem do polityki firmy; jest tylko jeden problem — znaleziona wersja przestała obowiązywać osiem miesięcy wcześniej. Taki system RAG oparty na dokumentach firmowych dobrze pokazuje, co to jest RAG w praktyce, a technicznie mógł zrobić wszystko, czego od niego wymagano: znaleźć semantycznie podobny fragment, umieścić go w kontekście modelu i napisać płynną odpowiedź; nie sprawdził jednak, czy plik jest najnowszą zatwierdzoną wersją, jeżeli status wersji nie został wiarygodnie oznaczony w indeksie.

Skrót RAG oznacza retrieval-augmented generation, czyli generowanie wspomagane wyszukiwaniem, w którym do odpowiedzi dołącza się pobrany zewnętrzny kontekst; nie jest to zapisywanie dokumentów firmy w wagach modelu ani osobna „warstwa inteligencji”, która automatycznie wie, który dokument mówi prawdę; bardziej przypomina bibliotekę z bardzo szybkim bibliotekarzem i utalentowanym redaktorem: bibliotekarz może przynieść niewłaściwy tom, a redaktor i tak napisze przekonujący akapit. Pierwotna praca opisująca RAG wyraźnie odróżnia parametryczną pamięć modelu od pobieranego z zewnątrz, nieparametrycznego źródła.

Praktyczna korzyść może być znaczna, jeżeli granice rozwiązania zostaną nazwane uczciwie: system potrafi znaleźć odpowiednie fragmenty w zarządzanym zbiorze dokumentów, ułożyć je w kontekst właściwy dla pytania i przygotować wersję roboczą z możliwym do sprawdzenia wskazaniem źródła. Granica odpowiedzialności musi być widoczna również dla użytkownika: interfejs nie powinien sugerować, że samo istnienie źródła stanowi zatwierdzenie prawne, a zgłoszenie błędu lub wątpliwości powinno być równie proste jak zadanie pytania. System nie naprawi złej dokumentacji, nie zagwarantuje zgodności odpowiedzi z faktami, sam nie wdroży uprawnień dostępu ani nie zastąpi deterministycznego procesu i zatwierdzenia przez człowieka tam, gdzie błąd stwarza ryzyko prawne, finansowe, związane z bezpieczeństwem lub prawami człowieka; ta granica określa zarówno architekturę, jak i to, co warto mierzyć w pilotażu.

Dlaczego nieaktualna polityka może zostać pobrana jako bieżąca

Incydent z nieaktualną polityką zaczyna się nie w modelu językowym, lecz w zarządzaniu dokumentami: na współdzielonym dysku znajdują się pliki „Dane_osobowe_final.docx”, „Dane_osobowe_final2.docx” i zatwierdzony PDF, ale żaden z nich nie ma spójnie oznaczonej daty wejścia w życie, statusu ani identyfikatora wersji, którą zastępuje. Indeks widzi trzech podobnych treściowo kandydatów, a wyszukiwanie semantyczne może wysoko ocenić stary dokument, ponieważ jego sformułowania dokładniej pasują do pytania. Model nie widzi decyzji podjętej na zebraniu organizacji, jeżeli nie ma jej w danych, a słowo „final” w nazwie pliku nie jest mechanizmem zarządzania.

Konsekwencje są podstępne, ponieważ odpowiedź może wyglądać lepiej niż zwykły wynik wyszukiwania: jest krótka, poprawna gramatycznie, odwołuje się do prawdziwego dokumentu i dlatego sprawia wrażenie, że weryfikacja już się odbyła. Link do źródła dowodzi jedynie, że określony plik został pokazany lub powiązany z odpowiedzią; nie dowodzi jeszcze, że każde twierdzenie wynika z cytowanego fragmentu, że fragment nie został wyrwany z części opisującej wyjątki ani że dokument ma status źródła obowiązującego; profil NIST GenAI nie uznaje tak wiarygodnego wyglądu za wystarczającą kontrolę ryzyka i podkreśla potrzebę zarządzania w całym cyklu życia systemu.

Rozwiązaniem są status publikacji, łańcuch wersji i reguły pierwszeństwa, a nie dłuższy prompt: każdy dokument w indeksie potrzebuje właściciela, daty początku i końca obowiązywania, statusu, wskazania zastąpionego dokumentu, działu, klasy poufności oraz terminu przeglądu; filtr wyszukiwania powinien domyślnie wykluczać wersje robocze i nieobowiązujące; jeżeli źródła są sprzeczne, system powinien pokazać konflikt i powstrzymać się od udawania jednej pewnej odpowiedzi, a odpowiedzialny właściciel powinien otrzymać zadanie uporządkowania zbioru dokumentów. RAG może ujawnić chaos, lecz nie potrafi zamienić chaosu w politykę.

W takiej sytuacji interfejs odpowiedzi powinien pokazywać nie tylko nazwę dokumentu, ale także jego wersję, status obowiązywania, fragment i ostrzeżenie o konflikcie; w dzienniku trzeba zachować informację, których kandydatów znaleziono i dlaczego wybrano jednego z nich, aby błąd można było odtworzyć po zmianie indeksu. Jeżeli system później zacznie udzielać innej odpowiedzi, zespół musi umieć ustalić, czy zmienił się dokument, sposób dzielenia treści na fragmenty, konfiguracja wyszukiwania czy model; bez takiej identyfikowalności incydent jakościowy staje się zgadywaniem na temat „zachowania AI”, zamiast usterką systemu, którą można naprawić.

Co to jest RAG i jak działa na dokumentach firmowych?

Proces RAG zaczyna się od pobrania danych, a nie od okna czatu: pliki są pobierane z określonych repozytoriów, wydobywa się z nich tekst, tabele i dostępną strukturę, natomiast zeskanowane dokumenty wymagają optycznego rozpoznawania znaków, czyli OCR; następnie treść dzieli się na sensowne fragmenty, zachowując dla każdego link do dokumentu, strony, sekcji i metadanych zarządczych. Wytyczne Microsoftu opisują fragmentowanie jako wybór wpływający na użyteczność wyszukiwania: zbyt mały fragment gubi myśl, zbyt duży wprowadza dużo szumu, a mechaniczne cięcie po określonej liczbie znaków może rozdzielić tabelę lub warunek wyjątku.

Na etapie indeksowania fragmenty otrzymują reprezentację nadającą się do wyszukiwania, zwykle łączącą wyszukiwanie słów kluczowych z porównaniem semantycznym opartym na wektorach liczbowych; gdy użytkownik zadaje pytanie, system może przekształcić je w kilka zapytań wyszukiwawczych, zastosować filtry działu, daty i dostępu, pobrać kandydatów oraz ponownie ustalić ich kolejność; dopiero wtedy wybrane fragmenty trafiają do okna kontekstowego modelu wraz z zadaniem: odpowiedzieć na podstawie dostępnych dowodów, wskazać źródła i powiedzieć, kiedy dowodów brakuje. Na tym etapie nic nie zostaje „nauczone na zawsze”; kontekst dotyczy konkretnego zapytania.

Ostatnim etapem jest generowanie, podczas którego wcześniej wytrenowany model językowy zamienia fragmenty w zrozumiałą odpowiedź, dlatego może również niezręcznie parafrazować, łączyć niepasujące do siebie źródła albo dodawać wiarygodnie brzmiący szczegół ze swojej wiedzy ogólnej; wynik powinien zachować powiązanie między fragmentem a twierdzeniem, a nie tylko ozdobną listę źródeł na końcu odpowiedzi; jeżeli pytanie wymaga działania — na przykład zmiany ceny w CRM — model nie powinien otrzymywać swobody wykonania: ustrukturyzowane żądanie użycia narzędzia sprawdzają kod aplikacji, uprawnienia i etap zatwierdzania. Wyszukiwanie pomaga znaleźć uzasadnienie; nie daje uprawnienia do działania.

W praktyce dobrze sprawdza się wyszukiwanie hybrydowe, w którym dokładny kod produktu lub numer polityki jest wyszukiwany jako słowo kluczowe, a znaczenie pytania — semantycznie; następnie ponowne szeregowanie wybiera fragmenty najlepiej odpowiadające na całe pytanie. Tę sekwencję trzeba sprawdzić na prawdziwych skrótach, błędnie zapisanych kodach, formach fleksyjnych i dokumentach wielojęzycznych, ponieważ pytanie demonstracyjne jest zwykle zbyt czyste. Jeżeli potrzebny fragment nie znajdzie się wśród kandydatów, model generatywny nie odzyska go dzięki elokwencji, dlatego błąd wyszukiwania należy naprawić przed zmianą treści promptu.

Do jakich zastosowań w pracy z dokumentami nadaje się RAG

Najlepszymi kandydatami są pytania, na które odpowiedź znajduje się już w wielu zarządzanych dokumentach, lecz człowiek traci zbyt dużo czasu na jej wyszukanie: procedury wewnętrzne, instrukcje produktów, instrukcje techniczne, dokumentacja jakościowa, objaśnienia wzorów umów i baza wiedzy działu obsługi klienta. Zadaniem RAG nie jest tu wymyślenie nowej decyzji, lecz znalezienie właściwej części dokumentacji, połączenie kilku zgodnych fragmentów i przygotowanie wersji roboczej. Dobre pytanie brzmi „w której instrukcji opisano ten błąd i jakie kroki kontrolne w niej wskazano?”, a nie „jak firma powinna postąpić w dowolnej sytuacji awaryjnej?”. Przydatna jest również warstwa przeglądania dokumentów poprzedzająca pracę człowieka: kierownik projektu może znaleźć w umowach warunki dostawy, specjalista ds. zamówień — wzmianki o wymaganiach, a pracownik serwisu — wcześniejsze rozwiązania podobnego problemu z urządzeniem. W takich przypadkach odpowiedź powinna otwierać właściwe miejsce w źródle, aby użytkownik mógł sprawdzić kontekst, a system powinien zapisywać zapytanie, znalezione fragmenty i wykorzystaną wersję. Dzięki temu RAG staje się narzędziem do nawigacji i przygotowywania wersji roboczych, a nie anonimowym wydawcą wyroków, którego toku decyzji nie da się później odtworzyć.

Złymi kandydatami są zadania bez stabilnej podstawy dokumentacyjnej, wymagające dokładnej arytmetyki lub egzekwowania reguł, a także takie, w których jeden błąd automatycznie powoduje nieodwracalne działanie. Obliczanie wynagrodzeń, nadawanie dostępu, wykonywanie płatności i pilnowanie terminów prawnych powinny podlegać kodowi i możliwym do sprawdzenia regułom biznesowym; RAG może znaleźć wyjaśnienie procedury, ale nie zastąpi silnika obliczeniowego ani łańcucha upoważnień. Jeżeli rzeczywistym celem jest połączenie systemów i przewidywalne przenoszenie danych, warto rozważyć automatyzację procesów biznesowych, zamiast czynić generowaną odpowiedź głównym przełącznikiem procesu.

O przydatności decyduje również odpowiedzialny właściciel: każdy zbiór dokumentów potrzebuje osoby, która zatwierdza źródła, rozstrzyga konflikty i decyduje o usuwaniu treści z indeksu, a każde zastosowanie — zespołu analizującego błędy i zmieniającego zbiór testowy; jeżeli nikt nie podejmie się tej pracy, po kilku miesiącach pilotaż staje się lustrem starych dokumentów, choć sam model się nie zmienił; dlatego prosty technicznie, lecz dobrze zarządzany przewodnik dla działu wsparcia jest lepszym pierwszym projektem niż podłączenie całego firmowego dysku w jeden wieczór.

Co RAG może zrobić z dokumentami firmy w codziennej pracy

RAG może skrócić czas, który pracownik spędza na odgadywaniu właściwego folderu i słów kluczowych, ponieważ wyszukiwanie semantyczne potrafi znaleźć fragment nawet wtedy, gdy słowa użyte w pytaniu nie pokrywają się z terminologią dokumentu. Może połączyć w odpowiedzi kilka zgodnych źródeł, wyjaśnić skomplikowaną instrukcję prostszym językiem, przygotować wersję roboczą wiadomości e-mail lub raportu i pokazać strony, z których pochodzi każde istotne twierdzenie. Wyszukiwanie plików OpenAI i architektura wyszukiwania Microsoftu są konkretnymi przykładami narzędzi, ale wybór produktu nie usuwa potrzeby zdefiniowania własnych statusów dokumentów, filtrów i kontroli jakości. System może też ujawnić problemy w dokumentacji, które zwykłe przeglądanie folderów ukrywa: jedno pytanie prowadzi do dwóch sprzecznych instrukcji, częste pytania nie mają źródła albo jeden dział dominuje w wynikach, ponieważ jego pliki mają lepszą strukturę. Takie przypadki są wartościowe tylko wtedy, gdy nie ukrywa się ich za jedną gładką odpowiedzią; brak źródła i konflikt powinny stać się mierzalnymi zdarzeniami widocznymi dla właściciela dokumentu. Dziennik jakości RAG staje się wtedy listą zadań z zakresu zarządzania wiedzą, a nie tylko wykresem wydajności modelu.

Inną realną możliwością jest dostosowanie do roli i kontekstu: technik otrzymuje szczegółową instrukcję z kodami, a doradca klienta — krótsze wyjaśnienie, pod warunkiem że obaj mają prawo widzieć te same źródła. Zmienia się sposób przedstawienia, nie prawda, a każda rola musi zachować ten sam status źródła i zakaz wymyślania brakujących informacji. Nasza praca nad rozwiązaniami AI dla firm zaczyna się od zdefiniowania zastosowania i granicy ryzyka, a nie od prezentacji modelu, ponieważ dobry prototyp dowodzi konkretnej korzyści w pracy na Państwa dokumentach i jednocześnie pokazuje pytania, na które system musi odpowiedzieć „nie wiem”.

W codziennej pracy największa korzyść pojawia się wtedy, gdy człowiek widzi, co system zrobił w jego imieniu, a co nadal wymaga sprawdzenia. Wersja robocza odpowiedzi może wyróżniać twierdzenia o niepełnym uzasadnieniu, proponować powiązane dokumenty i pozwalać jednym działaniem zgłosić nieprawidłową wersję; taka informacja zwrotna jest cenniejsza niż prosta ikona kciuka. Korektę należy powiązać z pytaniem, fragmentem i rodzajem błędu, aby zespół mógł odróżnić brak znalezionego źródła od niezręcznego języka lub błędnej reguły biznesowej i wybrać odpowiednie rozwiązanie.

Czego RAG nie potrafi, choć odpowiedź brzmi przekonująco

RAG nie może zagwarantować prawdziwości, ponieważ błąd może powstać przed generowaniem, w jego trakcie lub po nim: źródło może zawierać błędny fakt, wyszukiwanie może wybrać nieodpowiedni fragment, kontekst może zgubić wyjątek, a model — niewłaściwie połączyć poprawne akapity. Cytat ogranicza ryzyko ślepego zaufania tylko wtedy, gdy użytkownik może otworzyć dokładne miejsce i sprawdzić, czy twierdzenie rzeczywiście z niego wynika, lecz link do prawdziwego pliku PDF nie jest znakiem jakości, podobnie jak bibliografia w błędnym raporcie sama nie czyni jego wniosku poprawnym.

RAG nie potrafi również sam wdrożyć kontroli dostępu: jeżeli warstwa wyszukiwania przed pobraniem nie filtruje dokumentów według zweryfikowanej tożsamości użytkownika i uprawnień do dokumentu, model może otrzymać fragment, którego użytkownik nie ma prawa zobaczyć, a późniejsze wpisanie w prompcie „nie ujawniaj tajnych informacji” nie naprawi tego błędu architektonicznego. Wytyczne Microsoftu dotyczące dostępu na poziomie dokumentu przewidują dane o uprawnieniach i filtry bezpieczeństwa w samej ścieżce wyszukiwania; przycisk ukryty w interfejsie użytkownika nie stanowi zabezpieczenia, jeśli zapytanie można wywołać w inny sposób.

RAG nie czyni też niezaufanej treści bezpieczną: dokument, strona internetowa lub wiadomość e-mail może zawierać instrukcję próbującą zmienić zachowanie systemu — iniekcję promptu — a OWASP wskazuje ją jako odrębne ryzyko, którego nie usuwa całkowicie prosty zakaz w prompcie systemowym; dlatego treść zewnętrzną trzeba traktować jako dane, a nie polecenia, wywołania narzędzi muszą być ograniczone do wąsko określonego zakresu i walidowane, natomiast działanie wysokiego ryzyka powinno nadal podlegać deterministycznej regule i zatwierdzeniu przez człowieka. Model może proponować; uprawnienia nadaje system.

Na liście ograniczeń trzeba uwzględnić również dostępność i ciągłość działania: gdy indeks wyszukiwania jest niedostępny, bezpieczny system nie udaje, że nadal ma źródła firmowe, lecz wyraźnie przechodzi w stan błędu lub tryb ograniczony; w przeciwnym razie użytkownik nie potrafi odróżnić odpowiedzi opartej na źródłach od swobodnej improwizacji modelu. Należy też zaplanować limity kosztów i zapytań, awaryjne zatrzymanie oraz przywrócenie poprzedniej konfiguracji; produkt RAG jest łańcuchem kilku usług, a każda cicha awaria może zmienić znaczenie odpowiedzi, nawet gdy okno czatu nadal działa.

Gotowość dokumentów: OCR, metadane i kontrola wersji

Objętość folderu z dokumentami nie jest miarą gotowości: zeskanowana umowa z przekrzywioną stroną, tabela bez czytelnego nagłówka, PDF z niewłaściwą kolejnością tekstu lub zdjęcie o niskim kontraście mogą wyglądać zrozumiale dla człowieka, ale w wyniku OCR stracić cyfrę, relację między kolumnami albo granicę akapitu; opis ograniczeń OCR Microsoftu wyraźnie wiąże wynik z jakością skanu, rozdzielczością, kontrastem, oświetleniem, obrotem i właściwościami tekstu. Dlatego reprezentatywne dokumenty należy sprawdzić po wydobyciu treści, porównując tekst, tabele, odwołania do stron i istotne pola z oryginałem, zamiast ufać komunikatowi, że plik został „przetworzony pomyślnie”.

Metadane nadają fragmentowi kontekst organizacyjny: typ dokumentu, jednostka organizacyjna, produkt, język, właściciel, zatwierdzający, poufność, data wejścia w życie i status wersji pozwalają zawęzić zapytanie przed oceną podobieństwa semantycznego. Bez nich wyszukiwarka porównuje zdania, lecz nie wie, że instrukcja magazynowa dotyczy tylko Litwy albo że aneks do umowy został zastąpiony nowszym. Najważniejsze pola powinny pochodzić z zaufanego systemu lub zostać sprawdzone przez człowieka; wygenerowane przypuszczenie o statusie dokumentu nie może stać się filtrem, który decyduje o kolejnej odpowiedzi.

Aktualizacja również jest częścią produktu, a nie jednorazowym zadaniem importu: zespół musi wiedzieć, jak szybko zatwierdzona zmiana trafia do indeksu, jak usuwa się wycofany fragment, co dzieje się po zmianie adresu pliku oraz czy w razie awarii system nadal pokazuje starą wersję. Wytyczne Microsoftu dotyczące indeksowania rozróżniają aktualizacje przyrostowe od ponownego indeksowania, dlatego każde źródło potrzebuje udokumentowanej metody synchronizacji i kontroli błędów; przed rozpoczęciem projektu RAG warto uporządkować jeden autorytatywny obieg dokumentów; w przeciwnym razie szybkie wyszukiwanie jedynie przyspieszy skutki niejasnego zarządzania.

Przed pierwszym indeksowaniem przydaje się próbka gotowości dokumentów: należy wybrać różne typy i wiek plików, języki, tabele, skany oraz klasy dostępu, a następnie dla każdego elementu sprawdzić wydobyty tekst, granice fragmentów, metadane i link do źródła. Odsetka błędów nie należy sprowadzać do jednej średniej liczby, ponieważ koszt brakującego przecinka w instrukcji różni się od kosztu brakującej kwoty w umowie. Próbka daje podstawę do rozstrzygnięcia, które formaty przyjmować automatycznie, które wymagają kontroli człowieka, a których na razie nie indeksować; taka praca często poprawia jakość bardziej niż wybór innego modelu językowego.

Uprawnienia dostępu, prywatność i wybór sposobu wdrożenia

Bezpieczna architektura zaczyna się od tożsamości: kto zadaje pytanie, do jakiej organizacji i jakiego działu należy, jakie klasy dokumentów może zobaczyć oraz czy te uprawnienia są sprawdzane przy każdym żądaniu wyszukiwania. Filtr uprawnień musi zadziałać, zanim fragmenty trafią do kontekstu modelu, a w dziennikach należy unikać zbędnego kopiowania pełnych pytań, odpowiedzi i wrażliwych fragmentów; trzeba również testować przypadki brzegowe — pracownik zmienia rolę, dokument zostaje objęty ograniczeniem, dostęp zostaje cofnięty albo jeden klient próbuje znaleźć treść innego klienta; „czat wymaga zalogowania” nie jest wystarczającym kryterium odbioru.

Na pytanie „czy moje dane zostaną wykorzystane do trenowania modelu?” nie ma uczciwej, uniwersalnej odpowiedzi bez wskazania dostawcy, produktu, konta i ustawień. Materiały OpenAI dotyczące produktów biznesowych i API podają, że dane z odpowiednich produktów biznesowych nie są domyślnie wykorzystywane do trenowania modeli, natomiast dokumentacja kontroli danych API osobno opisuje przechowywanie, monitorowanie nadużyć i wyjątki dotyczące punktów końcowych; Anthropic podobnie rozróżnia przetwarzanie w produktach komercyjnych, świadomą zgodę na ulepszanie i warunki przechowywania. Dlatego umowa i projekt techniczny muszą weryfikować konkretną usługę, zamiast opierać się na określeniu „biznesowe API”.

Wdrożenie w regionie UE lub we własnej infrastrukturze może pomóc spełnić określone wymagania dotyczące lokalizacji danych, kontroli albo integracji, lecz samo w sobie nie dowodzi zgodności z RODO ani bezpieczeństwa. Nadal trzeba określić cel i podstawę prawną przetwarzania, minimalizację danych, okresy przechowywania, podmioty podprzetwarzające, usuwanie, proces obsługi incydentów i audyt dostępu; zasady RODO dotyczą całego łańcucha, nie tylko kraju, w którym stoi serwer modelu. Czasem właściwą decyzją jest niewłączanie określonych dokumentów do RAG albo usunięcie przed indeksowaniem pól, których odpowiedź nie potrzebuje.

Model zagrożeń powinien sprawdzać nie tylko ciekawskiego pracownika, lecz również błędną synchronizację grup, udostępniony link, rolę administratora, zachowaną pamięć podręczną i dokument zawierający złośliwą instrukcję; użytkownicy testowi powinni obejmować każdą rolę i niedozwoloną kombinację ról, próbując pytań bezpośrednich, synonimów oraz pośrednich próśb o podsumowanie; wynik nie może ujawnić ani fragmentu, ani nazwy dokumentu, ani poufnego szczegółu możliwego do wywnioskowania z odpowiedzi; po zmianie uprawnień test trzeba powtórzyć, ponieważ w pamięci podręcznej może pozostać filtr, który był bezpieczny wczoraj. Te kontrole są kryteriami odbioru, a nie ozdobą późniejszego audytu bezpieczeństwa.

Jak mierzyć wyszukiwanie, oparcie na źródłach i poprawność

Jeden wskaźnik „dokładności” dla systemu RAG przypomina jedną średnią ocenę szpitala: liczba może wyglądać dobrze, podczas gdy krytyczna klasa błędów pozostaje ukryta. Najpierw trzeba osobno zmierzyć wyszukiwanie — czy wymagany fragment pojawił się w określonej liczbie najwyższych wyników i czy nieistotne fragmenty go nie wyparły. Następnie mierzy się adekwatność kontekstu do pytania, oparcie odpowiedzi na przekazanych fragmentach, zgodność z faktami względem zatwierdzonego wzorca, to, czy każde wskazanie źródła potwierdza konkretne twierdzenie, oraz zdolność systemu do powstrzymania się od odpowiedzi, gdy brakuje źródła albo źródła są sprzeczne.

Dokumentacja Microsoftu dotycząca ewaluatorów RAG rozdziela te wymiary, a praca badawcza ARES podobnie odróżnia adekwatność kontekstu, wierność odpowiedzi i jej adekwatność. W praktycznym zbiorze testowym każde prawdziwe pytanie potrzebuje więc nie tylko „poprawnej odpowiedzi”, ale także wymaganego źródła, dopuszczalnych sformułowań, zakazanych twierdzeń, roli, wersji dokumentu i oczekiwanego zachowania w sytuacji, gdy dowody są niewystarczające. Część przykładów powinna pochodzić z częstych pytań, a część — z kosztownych wyjątków i celowo przygotowanych pułapek.

Próg akceptacji powinien zostać ustalony dla każdego wymiaru i każdej klasy ryzyka przed poznaniem wyników; w przeciwnym razie po prezentacji zespół wybierze wskaźnik, który wygląda najlepiej. Pomiary pilotażu powinny również zachowywać rozkład błędów według typu dokumentu, działu, języka i rodzaju pytania, ponieważ średnia ogólna może ukryć, że instrukcje działają dobrze, a tabele w umowach — źle. Automatyczny ewaluator oparty na modelu pomaga skalować testy, lecz próbkę powinien przejrzeć człowiek, a odpowiedzi krytyczne trzeba porównać z autorytatywnym źródłem, nie z pewnością innego modelu.

Po uruchomieniu należy mierzyć te same wymiary na kontrolowanej próbce produkcyjnej i z użyciem dzienników chroniących prywatność, natomiast zmiana zbioru dokumentów, algorytmu fragmentowania, modelu wektorowego, ponownego szeregowania lub modelu generatywnego może poprawić jedną grupę pytań, a pogorszyć inną, dlatego każda wersja potrzebuje testu regresji i porównywalnej wartości bazowej przy niezmiennych regułach oceny dla całego zbioru testowego. Alarm powinien być wywoływany nie tylko spadkiem wyniku ogólnego, ale również pojawieniem się błędu krytycznego, na przykład niedozwolonego fragmentu lub wymyślonej odpowiedzi tam, gdzie oczekiwano powstrzymania się od odpowiedzi.

RAG, wyszukiwanie, długi kontekst, dostrajanie i agenci

Zwykłe wyszukiwanie pełnotekstowe jest lepsze, gdy użytkownik zna dokładną nazwę, kod lub frazę i potrzebuje dokumentu, a nie ułożonej odpowiedzi; jest tańsze, bardziej przewidywalne i łatwiejsze do audytowania. Wyszukiwanie semantyczne pomaga przy synonimach i nieprecyzyjnych pytaniach, ale generowanie należy dodawać tylko tam, gdzie podsumowanie daje rzeczywistą wartość; RAG nie jest konieczny w każdym firmowym narzędziu wyszukiwawczym: czasem właściwym produktem jest dobra strona wyszukiwania z filtrami, podglądem fragmentu i statusem wersji, ponieważ użytkownik może sam wyciągnąć wniosek z pełnego dokumentu.

Umieszczenie całego dokumentu w długim oknie kontekstowym może być proste w przypadku małego, stabilnego zbioru materiałów, lecz w dużym korpusie zwiększa koszty, szum i ryzyko, że istotny akapit zginie wśród nieistotnej treści. Dodatkowe dostrajanie modelu, czyli fine-tuning, może utrwalić format, styl lub zachowanie przy konkretnym zadaniu, ale nie jest wygodnym sposobem przechowywania często zmieniających się cen, polityk i instrukcji, ponieważ aktualizowanie i cytowanie źródła staje się mniej przejrzyste. RAG pozwala zmieniać zbiór dokumentów niezależnie od trenowania wag modelu, lecz za tę elastyczność płaci się koniecznością zarządzania indeksem, wersjami i jakością wyszukiwania.

Automatyzacja wykonuje wcześniej zdefiniowane kroki, natomiast agent AI może wybrać narzędzie i następny krok, dlatego taka swoboda wymaga ściślejszych granic uprawnień, walidacji i zatrzymania; RAG może dać agentowi informacje, ale nie prawa: jeżeli model znajdzie politykę urlopową, nadal nie może sam zatwierdzić nieobecności ani zmienić systemu płacowego; ustrukturyzowane wywołanie funkcji jest jedynie propozycją dla aplikacji, która sprawdza schemat, tożsamość, dozwolone działanie, kwotę lub inne limity oraz wymagane zatwierdzenie przez człowieka. Porównanie technologii zaczyna się od ryzyka procesu, a nie od chęci użycia najnowszej etykiety.

Wybór można ująć w prostym teście: jeśli trzeba znaleźć i otworzyć plik, należy zacząć od wyszukiwania; jeśli trzeba podsumować kilka zmieniających się źródeł wraz z odwołaniami, warto rozważyć RAG; jeśli trzeba utrzymać stały format lub zachowanie klasyfikacyjne, odpowiednie może być dostrajanie; jeśli należy wykonać przewidywalną sekwencję działań, trzeba zbudować automatyzację; agenta warto dodać dopiero wtedy, gdy następnego kroku nie da się bezpiecznie zaprogramować, a korzyść przewyższa dodatkowe ryzyko. Podejścia te można łączyć, ale każda warstwa musi mieć własne zadanie, pomiar i granicę zatrzymania, inaczej przyczyna błędu znika za słowem „AI”.

Jak zbudować ograniczony pilotaż na prawdziwych pytaniach

Pilotaż zaczyna się od jednego zbioru dokumentów, jednej grupy użytkowników i jednej granicy decyzyjnej, na przykład instrukcji wsparcia technicznego, przy których system jedynie znajduje źródła i przygotowuje wersję roboczą odpowiedzi. Przed rozpoczęciem prac zespół zbiera prawdziwe pytania z dzienników wyszukiwania, wiadomości e-mail i rozmów z pracownikami, dodaje poprawne źródła oraz celowo uwzględnia przypadki niemożliwe do odpowiedzi, nieaktualne, sprzeczne i niedozwolone. Dla każdego przypadku określa się, co jest wynikiem akceptowalnym: potrzebny fragment został znaleziony, twierdzenie opiera się na źródle, cytat prowadzi do właściwego miejsca, odpowiedź jest zgodna z faktami, a system bezpiecznie powstrzymuje się od wymyślania brakujących informacji.

Progi należy ustalić przed prezentacją i rozdzielić według ryzyka: poprawialna wersja robocza może wystarczyć przy częstym pytaniu informacyjnym, ale pytanie o dane osobowe, umowę, bezpieczeństwo lub płatność wymaga ściślejszej kontroli i zatwierdzenia przez człowieka. W pilotażu trzeba również mierzyć czas odpowiedzi, koszt zapytania, działanie filtrów dostępu, opóźnienie aktualizacji indeksu oraz częstotliwość, z jaką pracownik otwiera źródło lub poprawia odpowiedź. Jeżeli system poprawia tylko przykłady demonstracyjne, lecz nie sprawdza się na wcześniej ukrytym zbiorze testowym, nie dowiedziono wyniku produktu; dowiedziono jedynie, że zespół potrafi przygotować prezentację.

Tworzenie naszych rozwiązań AI kosztuje od 3500 € i zwykle trwa 3–8 tygodni, natomiast działający pilotaż na Państwa własnych danych możemy dostarczyć w ciągu 2–3 tygodni; liczby te określają cenę początkową usługi i ogólny harmonogram, a nie stałą wycenę nieznanego zakresu. Wynikiem pilotażu powinno być coś więcej niż okno czatu: wersjonowany zbiór dokumentów, pytania testowe, osobne pomiary jakości, dziennik błędów, kontrole dostępu oraz decyzja o tym, czego rozwiązanie nie może robić. Późniejsze wymagania integracyjne warto zapisać równie jasno jak w każdym innym projekcie cyfrowym, zgodnie z zasadą opisaną w artykule o najczęstszych błędach przy zamawianiu strony internetowej: kryteria odbioru i właścicieli należy określić przed pełnym wdrożeniem, a nie po pierwszym efektownym ekranie.

Pilotaż powinien być kontynuowany tylko wtedy, gdy osiągnie wcześniej ustalone progi na niewidzianej części zbioru testowego, bezpiecznie obsłuży niedozwolone pytania i pytania bez odpowiedzi oraz przyniesie mierzalną korzyść w pracy człowieka. Jeżeli wyszukiwanie systematycznie nie znajduje właściwego źródła, najpierw należy poprawić dokumenty, metadane i indeks; jeżeli źródło jest poprawne, ale generowanie je zniekształca, trzeba zmienić kontekst, prompt lub model; jeśli błąd występuje tylko przy decyzjach wysokiego ryzyka, decyzje te należy pozostawić systemowi deterministycznemu i człowiekowi. Zatrzymany pilotaż nie jest porażką — to uzyskany niskim kosztem dowód, że w danym procesie ograniczenia RAG są ważniejsze niż efekt demonstracyjny.