Przejdź do treści

Wiedza

RAG vs fine-tuning: czego naprawdę potrzebują firmy

RAG, fine-tuning, długi kontekst z prompt cachingiem czy structured outputs? Przystępny przewodnik po wyborze właściwego podejścia, z checklistą decyzyjną.

Zespół inżynierów sigmacode.io9 min czytania

Na tej stronie (8)
  1. Cztery narzędzia w skrzynce
  2. Kiedy pasuje które podejście
  3. Porównanie obok siebie
  4. Praktyczna checklista decyzyjna
  5. Częste pułapki
  6. Najpierw ewaluacja, potem optymalizacja
  7. Jak te wzorce pokazują nasze własne dema
  8. Wersja skrócona

Niemal każdy projekt AI, o którym rozmawiamy z klientami, zaczyna się od tego samego pytania: „Czy powinniśmy zrobić fine-tuning modelu na naszych danych?”. Czasem odpowiedź brzmi: tak. Częściej prawdziwa potrzeba jest inna: asystent, który zna Twoje aktualne dokumenty, cytuje źródła i którego można zaktualizować we wtorek po południu bez uruchamiania treningu. W tym artykule prostym językiem wyjaśniamy główne opcje, mówimy, kiedy która pasuje i jak podjąć decyzję, nie tracąc miesięcy na niewłaściwe podejście.

Cztery narzędzia w skrzynce#

Gdy ktoś mówi „nauczmy model naszego biznesu”, zwykle ma na myśli jedną z czterech różnych technik. Rozwiązują one różne problemy i można je łączyć.

Retrieval-augmented generation (RAG)#

RAG zostawia model bez zmian. Zamiast tego, gdy przychodzi pytanie, system najpierw przeszukuje Twoje własne treści (instrukcje, umowy, zgłoszenia czy katalog produktów) i przekazuje modelowi najbardziej trafne fragmenty razem z pytaniem. Model odpowiada wtedy na podstawie tych fragmentów.

Liczą się tu trzy pojęcia:

  • Retrieval: znalezienie właściwych fragmentów. Zwykle to połączenie wyszukiwania semantycznego po embeddingach z klasycznym wyszukiwaniem po słowach kluczowych, często z dodatkowym krokiem rerankingu.
  • Grounding: poinstruowanie modelu, by odpowiadał na podstawie dostarczonego materiału i mówił wprost, gdy materiał nie zawiera odpowiedzi.
  • Cytaty: wskazanie dokładnego dokumentu, strony lub fragmentu, z którego pochodzi odpowiedź, tak by człowiek mógł ją sprawdzić.

RAG sprawdza się najlepiej tam, gdzie wiedza często się zmienia, korpus jest duży, a ludzie muszą weryfikować odpowiedzi.

Fine-tuning#

Fine-tuning to dalsze trenowanie modelu na Twoich własnych przykładach, tak by zmieniło się jego zachowanie. Dobrze uczy, jak odpowiadać: spójnego tonu, ścisłego formatu wyjściowego, branżowego schematu klasyfikacji albo wąskiego zadania wykonywanego tysiące razy dziennie. Słabo uczy tego, co jest prawdą w tej chwili. Fakty wyuczone przez fine-tuning trudno zaktualizować, trudno powiązać ze źródłem, a model może je mieszać lub błędnie pamiętać.

Fine-tuning pozwala też przenieść wąskie zadanie na mniejszy, tańszy i szybszy model, co przy dużym wolumenie potrafi mieć duże znaczenie.

Długi kontekst z prompt cachingiem#

Nowoczesne modele od Anthropic, OpenAI i kilku rodzin open source przyjmują bardzo długie dane wejściowe. Jeśli Twoja baza wiedzy ma umiarkowany rozmiar (na przykład podręcznik produktu, zbiór polityk albo zestaw FAQ), często możesz umieścić ją w całości bezpośrednio w prompcie. Bez indeksu, bez pipeline’u retrievalu, bez decyzji o chunkingu.

Oczywisty zarzut to koszt i opóźnienie: wysyłanie tego samego dużego dokumentu z każdym zapytaniem to marnotrawstwo. Odpowiedzią jest prompt caching. Dostawcy potrafią cache’ować stabilny prefiks promptu, więc kolejne zapytania korzystają z już przetworzonej treści i są rozliczane oraz obsługiwane wydajniej. Przy stabilnym, ograniczonym zasobie wiedzy długi kontekst z cachingiem jest często najprostszym rozwiązaniem, które działa.

Structured outputs#

Wiele projektów „AI” to w rzeczywistości projekty ekstrakcji: przeczytać fakturę, CV, umowę albo e-mail i zwrócić czyste pola. Kluczową możliwością są tu structured outputs, czyli wymuszenie na modelu zwracania danych zgodnych ze zdefiniowanym przez Ciebie schematem, na przykład JSON-a z określonymi polami i typami. Tu w ogóle nie chodzi o wiedzę. Chodzi o niezawodność formatu, a w zadaniach ekstrakcji zwykle eliminuje to potrzebę fine-tuningu.

Kiedy pasuje które podejście#

Pomaga jedno rozróżnienie: oddziel wiedzę od zachowania.

  • Świeża lub zmieniająca się wiedza oraz odpowiedzi, które ludzie muszą weryfikować: użyj RAG albo długiego kontekstu, jeśli materiał jest wystarczająco mały. Oba podejścia pozwalają aktualizować wiedzę przez aktualizację dokumentów i oba obsługują cytaty.
  • Stabilna, ograniczona wiedza, która mieści się w oknie kontekstu: zacznij od długiego kontekstu i prompt cachingu. Przejdź na RAG, gdy materiał przestanie się mieścić albo gdy potrzebujesz szczegółowej kontroli dostępu na poziomie dokumentu.
  • Spójny styl, ton lub format w wielu odpowiedziach: najpierw wypróbuj jasne instrukcje i kilka dobrych przykładów w prompcie. Jeśli przy Twoim wolumenie to nie wystarcza, fine-tuning jest uzasadnioną opcją.
  • Wąska klasyfikacja lub routing na dużą skalę: fine-tuning mniejszego modelu albo po prostu mniejszy model ogólny z dobrze zaprojektowanym promptem to często najbardziej ekonomiczna droga.
  • Ekstrakcja pól z dokumentów: structured outputs, opcjonalnie w połączeniu z dokumentami na wejściu i cytatami, tak by każdą wyodrębnioną wartość dało się prześledzić.

Te podejścia się nie wykluczają. Dojrzały system może używać RAG do wiedzy, structured outputs do formatu odpowiedzi i małego modelu po fine-tuningu do routingu przychodzących zapytań.

Porównanie obok siebie#

KryteriumRAGDługi kontekst + cachingFine-tuningStructured outputs
Aktualność wiedzyWysoka: aktualizujesz indeksWysoka: aktualizujesz dokumentyNiska: wymaga ponownego treninguTo nie jest technika dotycząca wiedzy
Koszt aktualizacjiNiski: reindeksacja zmienionych dokumentówBardzo niski: edycja źródłaWysoki: nowy zbiór danych i treningBardzo niski: edycja schematu
Identyfikowalność i cytatyMocne, jeśli je wbudujeszMocne, z cytatami dokumentówSłabe: nie ma źródła, które można wskazaćDobre w połączeniu z cytatami
Wymagania co do danychTwoje istniejące dokumentyTwoje istniejące dokumentyWiele starannie dobranych przykładów wysokiej jakościSchemat i przykładowe dokumenty
Czas do pierwszej wersjiDni do tygodniGodziny do dniTygodnie, wliczając przygotowanie danychGodziny do dni
Główne ryzykaSłaby retrieval, nieaktualny indeks, prompt injection przez dokumentyLimity kontekstu, koszt przy braku cachinguNieaktualne fakty, overfitting, ukryte uprzedzenia w danych treningowychSchemat zbyt sztywny albo zbyt luźny

Praktyczna checklista decyzyjna#

Zanim wybierzesz architekturę, odpowiedz szczerze na te pytania:

  1. Jakie dokładnie jest zadanie? Odpowiadanie na pytania, redagowanie tekstu, klasyfikacja czy ekstrakcja? Zapisz pięć prawdziwych przykładów danych wejściowych i idealnego wyniku.
  2. Jak często zmienia się wiedza, na której to się opiera? Zmiany codzienne lub cotygodniowe mocno przemawiają przeciw fine-tuningowi.
  3. Czy użytkownicy muszą weryfikować odpowiedzi? W prawie, finansach, compliance, wsparciu klienta czy ochronie zdrowia cytaty zwykle nie podlegają negocjacji.
  4. Jak duża jest baza wiedzy? Jeśli swobodnie mieści się w oknie kontekstu, najpierw wypróbuj długi kontekst z cachingiem.
  5. Kto co może zobaczyć? Jeśli różni użytkownicy mają dostęp do różnych dokumentów, potrzebujesz retrievalu z filtrowaniem po uprawnieniach, a nie jednego wspólnego promptu ani modelu wytrenowanego na wszystkim.
  6. Jakiego wolumenu i opóźnienia się spodziewasz? Duży wolumen przy wąskim zadaniu to miejsce, w którym mniejsze modele lub modele po fine-tuningu na siebie zarabiają.
  7. Czy masz oznaczone przykłady? Fine-tuning bez pokaźnego zbioru dobrych przykładów rzadko wygrywa z dobrze napisanym promptem.
  8. Jak zmierzysz sukces? Jeśli nie umiesz na to odpowiedzieć, zatrzymaj się i najpierw zbuduj zestaw ewaluacyjny.

Jeśli większość odpowiedzi wskazuje na „zmieniającą się wiedzę, potrzebne cytaty, umiarkowany wolumen”, potrzebujesz RAG albo długiego kontekstu. Jeśli wskazują na „stabilne zadanie, ścisły format, bardzo duży wolumen”, rozważ fine-tuning albo mniejszy model.

Częste pułapki#

To problemy, które widzimy najczęściej, gdy przeglądamy systemy AI, które „prawie działają”.

  • Zły chunking. Dzielenie dokumentów na przypadkowe kawałki o stałym rozmiarze przecina tabele na pół, oddziela nagłówki od ich treści i gubi kontekst. Dziel według struktury dokumentu i zachowuj przydatne metadane, takie jak tytuł, sekcja i data.
  • Brak ewaluacji. Bez zestawu testowego każda zmiana jest zgadywaniem. Zespoły poprawiają prompty, podmieniają modele i zmieniają rozmiary chunków, nie wiedząc, czy jest lepiej, czy gorzej.
  • Nieaktualne indeksy. Dokumenty źródłowe zaktualizowano, indeksu nie. Asystent z pełnym przekonaniem cytuje zeszłoroczną politykę. Reindeksacja musi być częścią procesu pracy z treścią, a nie ręcznym dodatkiem, o którym się przypomina na końcu.
  • Halucynacje bez cytatów. Jeśli system nie pokazuje, skąd wzięła się odpowiedź, użytkownicy nie odróżnią odpowiedzi opartej na źródłach od zmyślonej. Wymagaj cytatów i naucz model mówić „nie wiem”, gdy źródła milczą.
  • Prywatność i RODO. Dane osobowe w dokumentach, promptach i logach to nadal dane osobowe. Wiedz, który dostawca je przetwarza, w jakim regionie, na podstawie jakiej umowy powierzenia przetwarzania danych i jak długo przechowywane są logi. Fine-tuning na danych osobowych wymaga szczególnej ostrożności, bo późniejsze ich usunięcie jest trudne.
  • Prompt injection z dokumentów. Pobrana treść to niezaufane dane wejściowe. Dokument może zawierać tekst, który próbuje wydawać modelowi polecenia, na przykład zignorować jego zasady albo ujawnić inne dane. Traktuj pobrany tekst jak dane, ogranicz to, co model może zrobić narzędziami, i nigdy nie pozwalaj, by treść dokumentu nadawała uprawnienia.

Najpierw ewaluacja, potem optymalizacja#

Najcenniejszy krok w każdym projekcie AI jest zarazem najmniej efektowny: zbuduj zestaw ewaluacyjny, zanim wybierzesz architekturę.

Dobry zestaw na start to po prostu od kilkudziesięciu do kilkuset prawdziwych pytań lub danych wejściowych, każde z oczekiwaną odpowiedzią albo dokumentami, które powinny zostać zacytowane. Potem mierz:

  • Jakość retrievalu: czy system znalazł właściwe fragmenty?
  • Jakość odpowiedzi: czy odpowiedź jest poprawna, kompletna i oparta na źródłach?
  • Trafność cytatów: czy cytowane fragmenty faktycznie potwierdzają stwierdzenie?
  • Zachowanie przy odmowie: czy mówi „nie wiem” wtedy, kiedy powinien?
  • Zgodność formatu: czy przy ekstrakcji każdy wynik jest zgodny ze schematem?

Gdy to masz, porównania stają się rzeczowe. Możesz zestawić długi kontekst z RAG, jeden model z drugim albo model po fine-tuningu z modelem sterowanym promptem, na własnych danych, a nie na ogólnych benchmarkach. Często okaże się, że najtańszą poprawką jest lepszy retrieval albo jaśniejszy prompt, a nie większy model czy trening.

Automatyczne ocenianie modelem może to przyspieszyć, ale sprawdzaj je wyrywkowo z udziałem ludzi, zwłaszcza na początku.

Jak te wzorce pokazują nasze własne dema#

Staramy się robić to, co polecamy, a dwa dema na tej stronie pokazują te wzorce w działaniu.

sigmacode Assistant odpowiada na pytania o nasze usługi i sposób pracy. Jego baza wiedzy jest mała i celowo zamrożona, więc zamiast pipeline’u retrievalu używa długiego kontekstu z prompt cachingiem: cała baza wiedzy siedzi w cache’owanym prefiksie promptu, a model ma polecenie odpowiadać wyłącznie na jej podstawie. Przy ograniczonym zasobie wiedzy łatwiej to zbudować i łatwiej utrzymać poprawność niż w przypadku indeksu wektorowego.

Demo „Pytania do dokumentu z cytatami” pokazuje drugą stronę. Podajesz dokument, zadajesz pytania, a każda odpowiedź przychodzi z cytatami wskazującymi fragmenty, na których się opiera. To główna obietnica AI opartej na źródłach: każde stwierdzenie da się sprawdzić w źródle.

Żadne z tych dem nie wymagało fine-tuningu. To typowe. W większości biznesowych problemów związanych z wiedzą grounding i dobra ewaluacja znaczą więcej niż trening na zamówienie.

Wersja skrócona#

  • Użyj RAG, gdy wiedzy jest dużo, często się zmienia, wymaga kontroli dostępu albo musi być cytowana.
  • Użyj długiego kontekstu z prompt cachingiem, gdy wiedza jest stabilna i mieści się w oknie.
  • Użyj fine-tuningu albo mniejszych modeli do spójnego zachowania lub wąskich zadań o dużym wolumenie, a nie do faktów.
  • Użyj structured outputs do ekstrakcji i każdego wyniku, który ma parsować system.
  • Najpierw ewaluacja, potem optymalizuj to, co wskazują liczby.

Jeśli rozważasz te opcje w prawdziwym projekcie, nasz zespół AI i automatyzacji, który prowadzi tech lead z ponad 20-letnim doświadczeniem, pomoże Ci określić zakres, zbudować zestaw ewaluacyjny i dostarczyć pierwszą wersję, którą naprawdę da się zmierzyć. Odezwij się i napisz, jaki problem chcesz rozwiązać.

Masz pomysł na projekt?

Opowiedz nam, co budujesz. Zwykle w ciągu kilku dni roboczych dostajesz uczciwą ocenę, jasny zakres i ofertę w stałej cenie albo z rozliczeniem za kamienie milowe.

Wolisz najpierw napisać? Napisz do nas

Twój rozmówca: Ing. Ismet Mesic, Tech lead.