RAG czy dostrajanie? Czego rzeczywiste projekty dla klientów nauczyły nas o wyborze

Niemal każda rozmowa o AI w przedsiębiorstwach, w której uczestniczę, już w ciągu pierwszej godziny dochodzi do tego samego dylematu. Klient ma duży model językowy, który robi imponujące wrażenie podczas prezentacji, ale nie zna jego produktów ani zasad i nie potrafi pisać w jego stylu. Ktoś z zebranych pyta: czy powinniśmy dostroić model na naszych danych, czy zbudować wokół niego system generowania wspomaganego wyszukiwaniem (RAG)?

Uczciwa odpowiedź brzmi: pytanie jest zwykle źle postawione. RAG i dostrajanie służą do rozwiązywania różnych problemów. Zespoły, które traktują je jako konkurencyjne rozwiązania, często przez całe miesiące wydają duże środki na GPU, próbując naprawić nie to, co trzeba. Oto, jak podejmujemy decyzje w praktyce i co — jak się przekonaliśmy — może pójść dobrze lub źle.

Zacznij od ustalenia, czego brakuje modelowi

Gdy model źle wykonuje zadanie biznesowe, brakuje mu jednej z dwóch rzeczy.

Brakuje mu wiedzy. Nie zna najnowszego cennika, klauzuli z umowy z dostawcą na 2025 rok ani instrukcji rozwiązywania problemów dotyczących produktu wprowadzonego na rynek w zeszłym miesiącu. To problem z faktami.

Brakuje mu odpowiedniego sposobu działania. Wie wystarczająco dużo, ale nie odpowiada tak, jak tego potrzebujesz. Ignoruje wymagany format odpowiedzi, pisze w niewłaściwym tonie, błędnie odczytuje wewnętrzne kody albo nie potrafi wykonywać wąskiego, powtarzalnego zadania, takiego jak przypisywanie zgłoszeń do jednej z 40 kategorii. To problem z umiejętnościami.

RAG jest narzędziem do rozwiązania pierwszego problemu. Dostrajanie służy do rozwiązania drugiego. Większość nieporozumień, z którymi się spotykam, wynika z prób wykorzystania dostrajania do nauczania faktów.

Dlaczego dostrajanie to kiepski sposób na poszerzanie wiedzy

Kusi, by sądzić, że jeśli wytrenujesz model na swoich dokumentach, będzie je „znał”. W praktyce znacznie lepiej przyswaja styl tych dokumentów niż zawarte w nich fakty. Badacze z Microsoftu bezpośrednio porównali oba podejścia w zadaniach wymagających rozległej wiedzy i odkryli, że RAG konsekwentnie przewyższał dostrajanie bez nadzoru zarówno w przypadku faktów, z którymi model zetknął się podczas treningu, jak i zupełnie nowych informacji.

Są też problemy praktyczne. Fakty się zmieniają. Za każdym razem, gdy zmienia się Twoja polityka lub katalog, dostrojony model nie jest już aktualny, dopóki nie przeprowadzisz ponownego treningu. Tracisz również możliwość prześledzenia źródła informacji: gdy dostrojony model podaje jakąś wartość, nie możesz wskazać dokumentu, z którego ją zaczerpnął. W przypadku klientów z regulowanych branż, takich jak ubezpieczenia i ochrona zdrowia, to zwykle wystarczy, by zakończyć dyskusję.

RAG, po raz pierwszy opisany w artykule z 2020 r. autorstwa Lewisa i in., pozwala przechowywać wiedzę poza modelem. W chwili zadania pytania wyszukujesz odpowiednie fragmenty i przekazujesz je modelowi jako kontekst. Aktualizacja wiedzy wymaga zaktualizowania indeksu, a nie ponownego treningu. Każda odpowiedź może też zawierać odwołanie do źródła.

Dobrym przykładem jest jeden z naszych klientów z branży logistycznej. Jego klienci chcieli od razu otrzymywać informacje o lokalizacji przesyłek i brakujących dokumentach. Dane te zmieniają się co kilka minut. Żaden trening nie zapewniłby modelowi aktualnych informacji, dlatego zbudowany przez nas asystent w chwili zadania pytania odpowiada na podstawie bieżących danych śledzenia przesyłek i danych IoT, zamiast polegać na pamięci. Jedynym rozwiązaniem, które mogło się sprawdzić, było wyszukiwanie informacji.

Kiedy dostrajanie się sprawdza

Dostrajanie nie wyszło z użycia. Ma po prostu węższe zastosowanie, niż wielu osobom się wydaje. Sięgamy po nie w trzech sytuacjach:

• Ścisłe, powtarzalne formaty odpowiedzi. Gdy model musi tysiące razy dziennie generować ten sam ustrukturyzowany wynik — na przykład wyodrębniać pola z faktur według ustalonego schematu JSON — dostrojony mały model często działa niezawodniej i jest znacznie tańszy niż duży model, któremu przekazuje się instrukcje w promptach.
• Język specjalistyczny. W niektórych dziedzinach używa się skrótów, które model bazowy błędnie odczytuje. Typowe przykłady to kody statusu przesyłek w logistyce, skróty kliniczne i wewnętrzne kody produktów. Można to naprawić, dostrajając model w niewielkim zakresie.
• Koszty i opóźnienia przy dużej skali. Gdy zadanie jest dobrze zdefiniowane, dostrojony mały model może zastąpić duży model ogólnego przeznaczenia. Metody takie jak LoRA sprawiają, że jest to przystępne cenowo, ponieważ trenuje się niewielki zestaw dodatkowych wag, a nie cały model.

Zwróć uwagę, że żadna z tych sytuacji nie dotyczy faktów. Chodzi o nauczenie modelu, jak wykonywać zadanie, które już dobrze rozumiesz.

Większość problemów z RAG wynika z błędów wyszukiwania

Gdy ktoś z zespołu mówi mi: „Próbowaliśmy RAG, ale nie zadziałał”, problemem rzadko jest model. Zwykle chodzi o etap wyszukiwania. Jakość odpowiedzi modelu zależy od jakości przekazanych mu fragmentów.

Rozwiązania nie są efektowne, ale działają:

• Dziel tekst według znaczenia, a nie liczby znaków. Podział umowy co 500 znaków rozcina klauzule na pół. Podział według sekcji i nagłówków pozwala zachować kontekst.
• Dodawaj kontekst do każdego fragmentu. Fragment z informacją „limit wynosi 30 dni” jest bezużyteczny, jeśli nie wiadomo, jakiej polisy dotyczy. Anthropic podał, że dodanie do każdego fragmentu krótkiego kontekstu z dokumentu przed jego zindeksowaniem — podejście nazwane przez firmę wyszukiwaniem kontekstowym — ograniczyło liczbę nieudanych wyszukiwań o 49%, a po połączeniu z ponownym szeregowaniem wyników — o 67%.
• Łącz wyszukiwanie słów kluczowych z wyszukiwaniem wektorowym. Wyszukiwanie wektorowe dobrze wychwytuje znaczenie, ale gorzej radzi sobie z dokładnymi określeniami, takimi jak numery części. Wyszukiwanie hybrydowe łączy obie metody.
• Osobno przetestuj wyszukiwanie. Przygotuj zestaw rzeczywistych pytań z poprawnymi fragmentami źródłowymi, które są już znane, i sprawdź, czy właściwy fragment pojawia się wśród najlepszych wyników, zanim ocenisz odpowiedzi końcowe.

Kiedy stosować oba rozwiązania

W środowisku produkcyjnym najskuteczniejsze systemy często łączą oba podejścia. RAG dostarcza fakty. Lekko dostrojony model odpowiada za format, ton i język danej dziedziny. Badania zmierzają w tym samym kierunku: podejście RAFT z UC Berkeley polega na dostrajaniu modelu specjalnie po to, by lepiej wykorzystywał pobrane dokumenty i pomijał te nieistotne.

Kolejność ma jednak znaczenie. Niemal zawsze najpierw wdrażamy RAG, mierzymy jego niedociągnięcia i dopiero wtedy decydujemy, czy warto dostroić model. Rozpoczęcie od dostrajania oznacza poniesienie kosztów treningu, zanim wiadomo, na czym polega problem.

Prosta lista kontrolna ułatwiająca podjęcie decyzji

1. Czy zadanie zależy od faktów, które zmieniają się częściej niż raz na kwartał? Zastosuj RAG.
2. Czy użytkownicy lub audytorzy muszą wiedzieć, skąd pochodzi odpowiedź? Zastosuj RAG.
3. Czy problem dotyczy formatu, tonu lub słownictwa odpowiedzi, a nie zawartych w nich faktów? Rozważ dostrojenie modelu.
4. Czy chodzi o wąskie zadanie wykonywane na dużą skalę, w przypadku którego liczą się koszty lub szybkość? Rozważ dostrojenie mniejszego modelu.
5. Czy jakość wyszukiwania została zmierzona niezależnie? Jeśli nie, zrób to, zanim zajmiesz się czymkolwiek innym.

Najważniejsze wnioski

RAG i dostrajanie modelu nie są konkurencyjnymi rozwiązaniami. Jedno dostarcza modelowi właściwych informacji, drugie kształtuje jego zachowanie. Ustal, z jakim problemem naprawdę się mierzysz, popraw wyszukiwanie, zanim obwinisz model, i traktuj dostrajanie jako optymalizację, na którą trzeba sobie zapracować, gdy system już działa, a nie jako skrót do jego uruchomienia.