RAG, fine-tuning czy RAFT: jak wybrać

RAG, fine-tuning i RAFT rozwiązują różne problemy. RAG dostarcza aktualną wiedzę podczas zapytania. Fine-tuning zmienia zachowanie modelu na podstawie przykładów. RAFT uczy model pracować z domenowym retrieval i rozpraszającymi dokumentami. Wybór zaczyna się od diagnozy błędu, nie od popularności techniki.

Matryca decyzji

Problem	Pierwszy wybór	Dlaczego
aktualne procedury i cytowania	RAG	wiedza pozostaje poza parametrami
stały format lub zachowanie	fine-tuning	przykłady uczą wzorca odpowiedzi
domenowy RAG z trudnymi distractorami	eksperyment RAFT	trening zachowania wobec retrieval
złe dokumenty lub uprawnienia	porządek w danych	żadna technika nie naprawia źródła

Koszt danych i zmian

RAG wymaga utrzymania źródeł, indeksu i retrieval. Fine-tuning wymaga wysokiej jakości przykładów, treningu i ponownej walidacji. RAFT łączy wymagania treningowe z eksploatacją RAG. Dla szybko zmiennej wiedzy parametry modelu nie są dobrym repozytorium faktów.

Zbuduj wspólny zestaw testowy i porównaj najprostsze konfiguracje. Nie przypisuj poprawy wyłącznie technice, jeśli jednocześnie zmieniłeś model, prompt i dane. Mierz trafność retrieval, ugruntowanie, zachowanie, koszt i opóźnienie. Kontroluj odpowiedzi bez podstawy oraz przypadki, w których model powinien odmówić.

Decyzja może łączyć podejścia: fine-tuning dla formatu i polityki odpowiedzi, RAG dla wiedzy. RAFT ma sens jako świadomy eksperyment, gdy podstawowy pipeline jest zmierzony, a zespół potrafi przygotować oraz utrzymać dane treningowe.

Bramka jakości przed produkcją

Nie zaczynaj od wyboru usługi. Zapisz pytania użytkowników, źródła prawdy, dopuszczalny czas odpowiedzi, wymagania dostępu i koszt błędnej odpowiedzi. Przygotuj zestaw ewaluacyjny przed optymalizacją. Powinien obejmować pytania typowe, rzadkie, niejednoznaczne, pozbawione odpowiedzi oraz próby wyłudzenia danych. Każdy przypadek potrzebuje oczekiwanego źródła, kryterium poprawności i informacji, czy system powinien odmówić.

Warstwa pomiaru	Pytanie	Przykładowy dowód
dane	czy właściwa treść istnieje i jest aktualna?	właściciel, wersja i data przeglądu
retrieval	czy właściwy fragment znalazł się w wynikach?	recall@k oraz ręczna ocena trafności
odpowiedź	czy odpowiedź wynika z kontekstu?	poprawność, kompletność i cytowanie
bezpieczeństwo	czy użytkownik widzi tylko dozwolone dane?	testy ról, filtrów i prób obejścia
operacje	czy rozwiązanie spełnia budżet czasu i kosztu?	percentyle opóźnienia, tokeny i koszt zapytania

Oddziel błędy wyszukiwania od błędów generowania. Jeżeli właściwy fragment nie dotarł do modelu, zmiana promptu nie naprawi problemu. Jeżeli fragment był obecny, lecz odpowiedź go zniekształciła, pracuj nad instrukcją, modelem i regułami odpowiedzi. Jeżeli dokument źródłowy jest błędny, napraw źródło zamiast stroić system do nieprawdy.

Przyjmij punkt odniesienia. Najprostszy wariant powinien działać przed dodaniem agentów, dodatkowych modeli i kolejnych etapów rankingu. Każdą zmianę oceniaj na tym samym zbiorze i mierz skutki uboczne. Poprawa średniej nie wystarcza, jeśli rośnie liczba odpowiedzi bez podstawy w przypadku pytań wysokiego ryzyka.

Bezpieczeństwo, dostęp i odpowiedzialność

Uprawnienia muszą działać w retrieval, a nie dopiero w interfejsie. Indeks, filtr lub źródło wiedzy powinny zwracać wyłącznie treść dostępną dla danego użytkownika i celu. Cytowanie nie naprawia wycieku: może jedynie pokazać, skąd wyciek pochodzi. Testuj zmiany ról, usunięcie dokumentu i wygaśnięcie dostępu.

Traktuj dokumenty jako niezaufane wejście. Mogą zawierać błędne instrukcje, prompt injection albo tekst podszywający się pod polecenie systemowe. Oddziel treść od instrukcji, ogranicz narzędzia, waliduj wyniki i wymagaj zatwierdzenia człowieka przed działaniem o skutku finansowym, prawnym lub operacyjnym.

Ryzyko	Kontrola projektowa	Test odbiorczy
nieaktualne źródło	właściciel i cykl życia treści	pytanie o wycofaną procedurę
brak podstawy	odmowa przy niewystarczającym kontekście	pytanie spoza korpusu
wyciek uprawnień	filtrowanie przed pobraniem treści	ta sama kwerenda dla dwóch ról
prompt injection	izolacja instrukcji i ograniczenie narzędzi	dokument z poleceniem dla modelu
pozorne cytowanie	sprawdzenie zgodności tezy ze źródłem	cytat trafny tematycznie, lecz bez odpowiedzi
niekontrolowany koszt	limity kroków, tokenów i czasu	złożone pytanie oraz seria ponowień

Wskaż właściciela produktu, danych, indeksu, modelu i incydentu. Rejestruj wersje konfiguracji oraz zależności. Bez tego nie odtworzysz, dlaczego odpowiedź zmieniła się po aktualizacji dokumentu, modelu albo usługi. Inteligentny System Operacyjny Firmy wymaga takiego śladu decyzji: AI proponuje, ale człowiek i organizacja odpowiadają za reguły, dane oraz skutek.

Koszt i eksploatacja

Koszt zapytania nie kończy się na tokenach modelu. Obejmuje indeksowanie, przechowywanie, wyszukiwanie, ranking, generowanie, obserwowalność, ewaluację i pracę właścicieli treści. Mierz koszt pełnej ścieżki dla typów pytań. Średnia może ukryć drogie zapytania wieloetapowe i powtórzenia po nieudanej odpowiedzi.

Zdefiniuj budżet opóźnienia dla każdego etapu. Użytkownik może zaakceptować dłuższą analizę złożonego przypadku, lecz nie prostego wyszukania procedury. Buforuj tylko tam, gdzie nie łamie to aktualności i uprawnień. Ustal procedurę degradacji: prostsze wyszukiwanie, brak syntezy albo jasny komunikat, zamiast niekontrolowanej odpowiedzi.

Monitoruj rozkład jakości, nie tylko dostępność usługi. Losuj odpowiedzi do przeglądu, grupuj błędy według przyczyny i dodawaj incydenty do zestawu regresji. Nie zapisuj w telemetrii poufnych promptów i dokumentów bez uzasadnienia, kontroli dostępu oraz retencji.

Pilotaż i decyzja

Pilotaż powinien obejmować jedną domenę, znanych właścicieli i mierzalny proces. Porównaj rozwiązanie z obecną pracą: czas znalezienia informacji, liczbę korekt, jakość decyzji i liczbę eskalacji. Nie przeliczaj automatycznie czasu na oszczędność finansową; sprawdź, czy uwolniona zdolność została wykorzystana.

Przed produkcją zapisz kryteria: minimalna jakość retrieval, dopuszczalny odsetek odpowiedzi bez podstawy, budżet kosztu i czasu, zasady odmowy oraz właściciel działania naprawczego. Udokumentuj ograniczenia użytkownikom. B195 nie daje gwarancji prawdy; jest kontrolowanym mechanizmem pracy z modelami i wiedzą.

Kolejnym logicznym krokiem jest następny element architektury. W poniedziałek wybierz dwadzieścia realnych pytań, przypisz źródła oraz właścicieli, uruchom najprostszy wariant i oznacz każdy błąd jako problem danych, retrieval albo generowania. Dopiero ten podział daje podstawę do decyzji o inwestycji.

Źródło techniczne: dokumentacja pierwotna.

Cykl rozwoju rozwiązania

Inwentaryzacja źródeł

Zbuduj rejestr źródeł zanim utworzysz indeks lub dane treningowe. Dla każdego zapisz właściciela, odbiorców, częstotliwość zmian, klasyfikację, język, format i zasady usuwania. Nie indeksuj folderu tylko dlatego, że jest dostępny. Obecność wielu wersji tej samej procedury sprawia, że system może znaleźć dokument trafny semantycznie, lecz nieobowiązujący.

Ustal hierarchię źródeł. Gdy instrukcja, regulamin i wpis w bazie wiedzy sobie przeczą, pipeline potrzebuje reguły pierwszeństwa albo eskalacji. Metadane powinny zachować datę obowiązywania, jednostkę organizacyjną i uprawnienia. Sam tekst fragmentu zwykle nie wystarcza do bezpiecznej decyzji.

Kontrakt odpowiedzi

Zdefiniuj strukturę wyniku przed wyborem modelu. Określ, kiedy odpowiedź ma zawierać cytat, kiedy krótkie wyjaśnienie, kiedy pytanie doprecyzowujące, a kiedy odmowę. Rozdziel informację od rekomendacji i działania. Użytkownik powinien rozumieć, czy system odnalazł zapis, zinterpretował go czy zaproponował następny krok.

W procesie regulowanym pokaż datę i wersję źródła. W procesie operacyjnym podaj właściciela lub ścieżkę eskalacji. Nie ukrywaj niepewności za płynnym językiem. Jeśli dwa wiarygodne dokumenty są sprzeczne, system powinien wskazać konflikt, a nie arbitralnie wybrać wygodniejszy fragment.

Eksperymenty kontrolowane

Prowadź rejestr eksperymentów. Jedna zmiana może dotyczyć chunkingu, modelu embeddingów, parametrów wyszukiwania, rankera, promptu albo modelu generującego. Zmieniaj jeden główny element naraz. Zapisuj wersję danych oraz kodu, aby wynik dało się odtworzyć.

Ocenę automatyczną kalibruj ręcznym przeglądem. Model oceniający może być użyteczny do skalowania, ale ma własne preferencje i błędy. Ustal rubrykę: poprawność względem źródła, kompletność, istotność, jakość cytowania i zachowanie przy braku danych. Dla krytycznych przypadków ostateczny werdykt powinien należeć do eksperta domenowego.

Uruchomienie etapowe

Zacznij od trybu doradczego dla ograniczonej grupy. Użytkownik widzi źródła i zgłasza błąd. Następnie rozszerzaj zakres domeny, a nie tylko liczbę użytkowników. Każda nowa domena ma inne słownictwo, właścicieli, uprawnienia i konsekwencje błędu, dlatego wymaga własnego zestawu testowego.

Przed szerszym uruchomieniem przeprowadź test obciążenia i test wycofania. Sprawdź, jak system zachowuje się przy braku modelu, indeksu, jednego źródła i usługi uwierzytelniania. Użytkownik powinien otrzymać kontrolowany komunikat, a operacje alarm zawierający identyfikator ścieżki bez ujawniania poufnej treści.

Utrzymanie i zmiany

Modele, API i funkcje chmurowe mają cykl życia. Subskrybuj komunikaty o wycofaniu, zapisuj zależności i utrzymuj test zgodności dla następcy. Nazwa modelu nie jest trwałym kontraktem biznesowym. Aplikacja powinna potrafić porównać nową wersję na zamrożonym zestawie przed przełączeniem ruchu.

Treść także ma cykl życia. Usunięcie dokumentu źródłowego powinno skutkować usunięciem lub unieważnieniem fragmentów w indeksie. Aktualizacja wymaga kontroli, czy nie pozostały duplikaty. Okresowo pytaj właścicieli o potwierdzenie aktualności; brak odpowiedzi może oznaczać wyłączenie treści z zastosowań wysokiego ryzyka.

Analizuj błędy w stałej taksonomii: brak źródła, zły fragment, konflikt dokumentów, przekroczenie uprawnień, błędna synteza, nieskuteczna odmowa i problem operacyjny. Dla każdej kategorii wyznacz właściciela. Raport „model odpowiedział źle” nie prowadzi do korekty, ponieważ miesza kilka niezależnych mechanizmów.

Rachunek decyzji

Porównaj rozwiązanie nie z idealnym ekspertem, lecz z obecnym procesem. Zmierz czas znalezienia informacji, jakość wyniku, koszt korekty i ryzyko pominięcia. Uwzględnij przygotowanie źródeł, ewaluację, bezpieczeństwo i utrzymanie. Tani prototyp może wymagać drogiego procesu redakcyjnego, który jest jednak wartościowy także dla ludzi i innych systemów.

Ustal warunek zatrzymania eksperymentu. Jeśli po kilku iteracjach retrieval nie osiąga progu dla krytycznych pytań, ogranicz domenę albo popraw źródła. Jeśli koszt kontroli przewyższa korzyść, pozostaw wyszukiwanie bez generowania. Technologia powinna zmniejszać koszt poprawnej decyzji, a nie jedynie zwiększać liczbę wygenerowanych odpowiedzi.

Dokument decyzji architektonicznej

Na koniec pilotażu zapisz krótką decyzję architektoniczną. Powinna zawierać problem, rozważone warianty, wybrany zakres, dowody z ewaluacji, ograniczenia, koszt oraz warunek ponownego przeglądu. Dołącz identyfikatory zestawu testowego i konfiguracji, ale nie kopiuj do dokumentu poufnych danych.

Wypisz założenia, które mogą się zestarzeć: dostępność modelu, region, status funkcji, cennik, wolumen zapytań i tempo aktualizacji źródeł. Każde założenie otrzymuje właściciela oraz sygnał wyzwalający nową ocenę. Dzięki temu zmiana oferty dostawcy nie zaskakuje zespołu w produkcji.

Udokumentuj również wariant odrzucony. Wyjaśnij, dlaczego nie spełnił kryterium i co musiałoby się zmienić, aby wrócił do oceny. To zapobiega powtarzaniu tych samych eksperymentów oraz pozwala następnemu zespołowi odróżnić świadomy kompromis od przeoczenia.

Decyzję akceptują wspólnie właściciel biznesowy, danych, bezpieczeństwa i operacji. Architektura AI nie jest wyłącznie wyborem technicznym: ustala, kto może zobaczyć dane, kto odpowiada za aktualność i co dzieje się po błędzie. Brak przypisanej odpowiedzialności jest ważniejszym ryzykiem niż różnica kilku punktów w benchmarku.