Każdy ma własną opinię na temat fine-tuningu w porównaniu z RAG. Przeglądając dowolne forum poświęcone AI, natkniesz się na gorące dyskusje pełne diagramów architektury i twierdzeń opartych na benchmarkach. Większość osób piszących te komentarze nigdy nie trenowała modelu na własnych danych ani nie widziała, jak pipeline RAG po cichu zawodzi w środowisku produkcyjnym.

Spędziłem miesiące na przeprowadzaniu eksperymentów. Dokładnie dwunastu. Robiłem fine-tuning LLM-ów. Robiłem fine-tuning embedderów. Zbudowałem sześć różnych konfiguracji RAG. Obszarem były prognozy finansowe, a konkretnie próba przewidywania zaszumionych wyników rynkowych na podstawie nieuporządkowanych danych historycznych. Przyjąłem rygorystyczne standardy statystyczne, ponieważ chciałem realnych odpowiedzi, a nie twierdzeń z wpisów na blogach.

Większość eksperymentów zakończyła się niepowodzeniem. Te porażki okazały się znacznie bardziej przydatne niż jakikolwiek szczęśliwy sukces.

Gorzka prawda o sygnale

Zanim przejdziemy do szczegółów, oto lekcja, która spaja wszystko w całość. Fine-tuning i RAG to narzędzia służące do zmiany tego, co model wie lub co widzi. Nie są to magiczne różdżki, które wytwarzają sygnał z niczego. Jeśli twoje dane podstawowe nie zawierają realnego, możliwego do wykorzystania wzorca, te techniki go nie stworzą. Pomogą ci jedynie zbudować bardziej przekonującą opowieść wokół losowego szumu.

W prognozowaniu finansowym ta pułapka jest szczególnie niebezpieczna. Rynki są z natury zaszumione. Gdy podepniesz potężny model LLM pod historyczne dane cenowe i dodasz retrieval lub fine-tuning, nie zyskasz automatycznie przewagi. Zyskasz jedynie bardziej elokwentny sposób racjonalizowania rzutu monetą. Jeśli sygnału nie ma, model stanie się bardzo dobry w okłamywaniu cię. Musisz to sprawdzić w pierwszej kolejności.

Kiedy większy model zamiast się uczyć, zapamiętuje

Moim pierwszym poważnym błędem było założenie, że skala naprawi wszystko. Przetestowałem model o 14 miliardach parametrów przeciwko modelowi o 7 miliardach parametrów na dokładnie 777 przykładach treningowych. Większy model osiągnął zauważalnie lepszy eval_loss. Jego perplexity spadło. Na papierze uczył się wzorców.

Następnie spojrzałem na win rate, czyli rzeczywisty współczynnik, z jakim model trafiał w poprawne prognozy. Model 14B radził sobie znacznie gorzej niż model 7B. Zapamiętał szum treningowy. Przy mniej niż 3000 przykładach większy model miał wystarczającą pojemność, aby dopasować się (overfit) do pozornych korelacji i losowych wahań w danych. W zasadzie zbudował lookup table szumu.

Model 7B, ograniczony mniejszą pojemnością, został zmuszony do nauki szerszych wzorców. Nie mógł pozwolić sobie na zapamiętanie każdej anomalii. Jeśli pracujesz z małymi zbiorami danych, zacznij od mniejszych modeli. Skala nie jest darmowa. Może ci aktywnie zaszkodzić, gdy danych jest mało.

Nie ufaj krzywej straty

Nauczyłem się przestać wpatrywać się w krzywe straty. Model może poprawiać swoją cross-entropy na poziomie tokenów, jednocześnie stając się gorszym w podejmowaniu rzeczywistych decyzji biznesowych, na których ci zależy. Dzieje się tak dlatego, że strata modelowania języka nagradza dokładne przewidywanie następnego tokena. W wielu dziedzinach, zwłaszcza w finansach, poprawna decyzja i najbardziej prawdopodobny następny token to nie to samo.

Widziałem modele, które pięknie odtwarzały tekst treningowy, ale za każdym razem wybierały błędną stronę zakładu. Strata spadała. Kapitał spadał wraz z nią. Wybieraj metrykę ewaluacji na podstawie rzeczywistego zadania. Jeśli dokonujesz rankingu dokumentów, mierz jakość rankingu. Jeśli prognozujesz wyniki, mierz dokładność decyzji. Nigdy nie pozwól, aby eval_loss wybierał model za ciebie.

Fine-tuning błyszczy tylko przy obcym słownictwie

Przeprowadziłem próby fine-tuningu embedderów na dwóch różnych typach tekstu. Pierwszy wykorzystywał standardowe wiadomości finansowe i publiczne raporty. Fine-tuned embedder i wersja gotowa (off-the-shelf) działały identycznie. Model bazowy już znał ten język. Dostrajałem go na znanym mi gruncie.

Drugi zbiór danych był pełen prywatnego żargonu, wewnętrznych kryptonimów i specyficznych dla danej dziedziny skrótów, które nigdy nie pojawiły się w otwartym internecie. Tutaj fine-tuning poprawił dokładność retrieval o 79 procent. Model bazowy po prostu nie wiedział, co oznaczają te terminy. Fine-tuning nauczył go lokalnego słownictwa.

To zmieniło moje podejście do całego zadania. Fine-tuning nie polega na czynieniu modelu inteligentniejszym w ogólnym sensie. Chodzi o nauczenie go nowego słownictwa, nowego formatu lub stylu redakcyjnego. Jeśli twoje dane wyglądają jak internet, odpuść sobie fine-tuning. Jeśli twoje dane mówią językiem, którego model bazowy nigdy nie widział, fine-tuning staje się niezbędny.

RAG daje ci pewność, a nie prawdę

Przetestowałem osiem oddzielnych konfiguracji RAG do zadań predykcyjnych. W każdym przypadku dodanie retrieval zmieniło około 30 procent decyzji modelu. Brzmi to znacząco. Tak nie było. Te zmiany były czystym szumem. Ogólna dokładność nie uległa poprawie. Zmieniła się jedynie pewność modelu. RAG sprawił, że system brzmiał pewniej, cytował więcej źródeł i generował dłuższe uzasadnienia. Wszystko to przy tym, że model wciąż mylił się tak samo często.

Ta nadmierna pewność siebie to ryzyko produktowe. Użytkownik widzi cytaty i zakłada, że model odrobił lekcje. W rzeczywistości wykonywał jedynie wyrafinowane zgadywanie.

Najbardziej bolesna lekcja płynęła z backtestingu jednej wariacji RAG. Wykazała ona 11-procentowy roczny zysk. Na pierwszy rzut oka wygląda to na zwycięską strategię. Jednak jej AUC, czyli pole pod krzywą ROC będące miarą umiejętności klasyfikacji, wynosiło 0,486. To wynik gorszy niż rzut monetą, który wynosi 0,500. Zysk był dziełem przypadku w konkretnym okresie rynkowym, a nie powtarzalną przewagą. Używanie samego P&L jako metryki jest niebezpieczne. Rynki nieustannie oferują szczęśliwe passy. Potrzebujesz statystycznych miar umiejętności, aby odróżnić przypadki od kompetencji.

Dowiedz się, co tak naprawdę robi każde narzędzie

Co nam to mówi? Stosuj fine-tuning, gdy model musi nauczyć się nowych słów, konkretnych formatów lub charakterystycznego stylu. Używaj RAG, gdy model potrzebuje dostępu do faktów, repozytoriów kodu lub pamięci instytucjonalnej, która znajduje się poza jego wagami. Nie używaj żadnego z tych narzędzi, aby szukać sygnału w danych, w których go nie ma. Jeśli podstawowy wzorzec nie istnieje, retrieval i fine-tuning pomogą ci jedynie ubrać szum w bardziej elegancki garnitur.

Prawdziwe wąskie gardło

Infrastruktura dla fine-tuningu i RAG nigdy nie była łatwiejsza do skonfigurowania. Możesz postawić pipeline w jedno popołudnie. Technika nie jest już wąskim gardłem. Jest nim ewaluacja. Większość zespołów pomija trudną pracę statystyczną, świętując zamiast tego vanity metrics. Wdrażają systemy, które brzmią inteligentnie, ale po cichu zawodzą.

Przeprowadzaj uczciwe testy, zanim wydasz pieniądze. Kwestionuj swoje metryki. Sprawdzaj pod kątem overfittingu. Upewnij się, że model jest rzeczywiście lepszy,