RAG nie jest dodatkiem, który automatycznie „uziemia” model. Jest systemem dwóch zależnych etapów: retrieval musi znaleźć właściwy materiał, a generator musi użyć go zgodnie z treścią i zakresem pytania. Cytat może prowadzić do dokumentu, który nie popiera odpowiedzi; większy model może płynniej opisać błędny kontekst. Dlatego jakość trzeba oceniać osobno dla wyszukiwania, generacji i zachowania całego produktu.
Punktem wyjścia jest decyzja produktowa: na jakie pytania system ma odpowiadać, kiedy ma odmówić i kto ponosi koszt błędu. Dopiero z takiego kontraktu wynikają wymagania wobec korpusu, pipeline’u, ewaluacji i interfejsu. Governance ma zapewnić możliwość odtworzenia odpowiedzi oraz bezpiecznego wycofania zmiany, a nie produkować dokumentację po wdrożeniu.
Zdefiniuj zadanie i koszt pomyłki
Asystent wyszukujący procedurę urlopową ma inny profil ryzyka niż system wspierający diagnozę, decyzję kredytową lub reakcję na incydent. Dla każdego zastosowania trzeba opisać dozwolone źródła, oczekiwaną aktualność, użytkownika, możliwe skutki błędu i warunek przekazania sprawy człowiekowi. Odpowiedź może być językowo poprawna, a jednocześnie niedopuszczalna w danym procesie.
Kontrakt powinien rozróżniać brak odpowiedzi od odpowiedzi negatywnej. Jeśli korpus nie zawiera polityki dotyczącej danego przypadku, model ma wskazać brak podstaw, nie wnioskować z podobnego dokumentu. Wysokie ryzyko wymaga wyraźniejszej abstencji, dodatkowej weryfikacji i ograniczenia działania systemu do rekomendacji. Nie należy opierać tej decyzji na pojedynczym, niekalibrowanym wyniku „confidence”.
Zarządzaj korpusem jak produktem
Każde źródło powinno mieć właściciela, zakres odbiorców, datę obowiązywania, regułę aktualizacji, prawa użycia i status publikacji. Indeks nie może mieszać zatwierdzonych instrukcji z roboczymi notatkami bez oznaczenia ich autorytetu. Gdy dwa dokumenty są sprzeczne, retrieval powinien uwzględnić wersję i pierwszeństwo, zamiast pozostawiać generatorowi wybór wygodniejszego fragmentu.
Pipeline ingestii musi zachowywać lineage od pliku źródłowego przez parsowanie, chunk, embedding i indeks. Właściciel produktu powinien móc odpowiedzieć, które wersje dokumentów oraz modeli uczestniczyły w konkretnej odpowiedzi. Retencja indeksu i logów musi uwzględniać poufność danych; kopiowanie całego repozytorium wiedzy do zewnętrznej usługi nie może być nieudokumentowanym skutkiem architektury.
Mierz retrieval niezależnie od generacji
Najpierw potrzebny jest reprezentatywny zestaw pytań z oczekiwanymi źródłami lub fragmentami. Powinien zawierać sformułowania użytkowników, skróty, błędy, pytania wieloczęściowe, przypadki bez odpowiedzi i dokumenty o podobnych nazwach. Eksperci domenowi zatwierdzają oczekiwany materiał, ale nie powinni oceniać wyłącznie pytań przygotowanych przez zespół budujący system.
Dla retrieval można mierzyć, czy właściwy fragment znalazł się w pierwszych wynikach, ile nieistotnego kontekstu dołączono oraz czy system wybrał obowiązującą wersję. Latencja jest ważna dopiero obok trafności. Zmiana chunkingu, embeddera, rerankera lub filtrów metadanych wymaga ponowienia testu. Pierwotna praca Retrieval-Augmented Generation wskazywała między innymi na możliwość aktualizacji wiedzy i wskazywania pochodzenia; implementacja musi te własności rzeczywiście zachować.
Oceniaj wierność i użyteczność odpowiedzi
Generator trzeba sprawdzać na kontekście, który otrzymał, oraz na pytaniu użytkownika. Osobne kryteria obejmują: czy każde istotne twierdzenie ma oparcie w źródle, czy cytat wskazuje właściwy fragment, czy odpowiedź nie pomija ważnego wyjątku, czy rozróżnia fakty od wniosków i czy wykonuje instrukcję produktu. Framework RAGAS jest jednym z pierwotnych punktów odniesienia dla rozdzielenia jakości retrieval, wierności wobec kontekstu i jakości odpowiedzi.
Automatyczny sędzia modelowy pomaga skalować regresję, lecz sam również popełnia błędy. Zespół powinien kalibrować go na próbie ocenionej przez ekspertów i analizować rozbieżności. Ocena binarna bywa zbyt uboga: błędny wyjątek w poprawnej instrukcji może mieć większe znaczenie niż kilka drobnych niedokładności stylistycznych.
Zestaw testowy powinien mieć część stałą i część zmienną. Stała pozwala porównywać wydania, a zmienna przechwytuje nowe pytania, błędy produkcyjne i zmiany korpusu. Przypadki używane do strojenia nie powinny być jedynym materiałem odbiorowym, bo wynik szybko przestaje odzwierciedlać zachowanie na nieznanych pytaniach. Dla kategorii o dużym wpływie warto utrzymywać próbę ukrytą przed osobami strojącymi retrieval i prompt.
Analiza błędu musi wskazywać warstwę odpowiedzialną za wynik: brak źródła, błędny parser, niewłaściwy chunk, ranking, filtr dostępu albo generację. Bez tej diagnozy zespół może zmieniać prompt, choć właściwy dokument nigdy nie dotarł do modelu.
Zabezpiecz granicę między dokumentem a instrukcją
Treść znaleziona w korpusie jest danymi, nie zaufanym poleceniem dla modelu. Dokument może zawierać prompt injection nakazujący ujawnienie sekretu, zmianę reguł albo pobranie zasobu z sieci. Pipeline powinien ograniczać narzędzia, separować instrukcje systemowe od kontekstu, filtrować niedozwolone źródła i testować ataki umieszczone w dokumentach.
Kontrola dostępu musi działać przed retrieval. Nie wystarczy poprosić model, by nie cytował poufnego fragmentu, który już dostał. Filtry tenantów, ról i klasyfikacji danych należy egzekwować na zapytaniu do indeksu, a ich wynik logować. NIST AI 600-1 zaleca dla generatywnej AI między innymi zarządzanie pochodzeniem treści, testy przed wdrożeniem, monitoring i proces ujawniania incydentów.
Wprowadź bramkę wydania i obserwowalność
Każde wydanie powinno zapisywać wersję modelu, promptu, indeksu, embeddera, rerankera i konfiguracji filtrów. Bramka porównuje wyniki na stałym zestawie regresyjnym oraz na nowych przypadkach z produkcji. Przekroczenie ustalonych granic dla krytycznych kategorii blokuje zmianę albo wymaga jawnej akceptacji ryzyka.
Telemetria produkcyjna powinna pozwalać analizować zapytanie, identyfikatory zwróconych fragmentów, cytaty, odmowę, latencję i feedback użytkownika bez gromadzenia danych ponad potrzebę. Trzeba monitorować brak wyników, zmianę rozkładu tematów, spadek aktualności źródeł, nietypowe próby dostępu i wzrost eskalacji. Surowa ocena użytkownika nie wystarczy: łatwość czytania bywa mylona z poprawnością.
Przypisz decyzje i procedurę incydentową
Właściciel korpusu odpowiada za aktualność i autorytet źródeł; zespół platformy za pipeline i izolację; właściciel produktu za zachowanie oraz progi; ekspert domenowy za kryteria merytoryczne; bezpieczeństwo i privacy za nadużycia oraz dane. Jedna osoba nie musi wykonywać wszystkich kontroli, ale każda ma mieć adresata.
Incydent RAG może oznaczać nie tylko wyciek. Zatrucie indeksu, masowe błędne cytowania, wykorzystanie wycofanej procedury albo systematyczne pomijanie grupy przypadków również wymaga reakcji. Runbook powinien umożliwiać zatrzymanie ingestii, wycofanie indeksu lub modelu, identyfikację dotkniętych odpowiedzi, powiadomienie właścicieli oraz test przed wznowieniem. To właśnie powtarzalna ocena i kontrola zmian, zgodna z funkcjami Govern, Map, Measure i Manage z NIST AI RMF, odróżnia produkcyjny system od demonstracji.