Po fine-tuningu macie nowy model. Benchmark na zadaniu treningowym wzrósł. Zespół się cieszy. Jednak gdy wdrożycie model na produkcję, klienci zaczynają zgłaszać dziwne odpowiedzi w przypadkach, które przed treningiem działały bezbłędnie. Co się stało? Stało się to, co widzimy raz po raz: model był ewaluowany tylko na tym, czego go uczyliśmy — nie na tym, czego przypadkowo go oduczyliśmy.
Eval modelu po fine-tuningu to inna dyscyplina niż eval produkcyjnego systemu LLM. Nie porównujecie, czy Państwa pipeline RAG zwraca właściwe chunks — porównujecie, co konkretna zmiana wag zrobiła z modelem jako całością. Ten artykuł omawia, jak podejść do tego systematycznie: od task-specific eval setu przez porównanie base vs. fine-tuned aż po wykrywanie regresji na ogólnych umiejętnościach.
Dlaczego „loss spadł" nie wystarczy
Strata treningowa (training loss) mówi Państwu, jak dobrze model dopasował się do danych treningowych. Nie mówi nic o tym, czy zachowanie modelu w praktyce się poprawiło. I z całą pewnością nie mówi, co stało się z modelem poza domeną, na której trenowaliście.
W praktyce widzimy trzy częste błędy:
- Ewaluacja wyłącznie na danych treningowych — model zapamiętał wzorce, zamiast się uogólnić
- Testowanie tylko zadania docelowego — ignorowanie ogólnych umiejętności, które fine-tuning mógł uszkodzić
- Brak porównania z modelem bazowym — nie wiecie, co jest przyrostem fine-tuningu, a co było możliwością modelu bazowego
Katastroficzne zapominanie (catastrophic forgetting) to realny zjawisko, udokumentowane empirycznie na wielu rodzinach modeli. Fine-tuning na wąskich danych może degradować umiejętności, które model nabył podczas pretrainingu — logiczne rozumowanie, formatowanie, przestrzeganie instrukcji, wiedzę spoza domeny. Metody PEFT, takie jak LoRA, zmniejszają to ryzyko, ale go nie eliminują.
Trzy warstwy frameworku ewaluacji
Solidny eval modelu po fine-tuningu opiera się na trzech warstwach. Każda wychwytuje inne ryzyko.
1. Task-specific eval set
To jest Państwa podstawowy sygnał. Mierzy, czy model opanował to, do czego go trenowaliście.
Kluczowa zasada: held-out test set. Część oznaczonych danych, której model nigdy nie widział podczas trenowania, musi być zarezerwowana wyłącznie do finalnej ewaluacji. Jeśli użyjecie tych samych danych do treningu i ewaluacji, pomiar jest bezwartościowy — model mógł zapamiętać, zamiast się nauczyć.
Praktyczny sposób postępowania: 1. Przed treningiem podzielcie dataset na trening / walidacja / test (np. 80 / 10 / 10) 2. Zbiór walidacyjny służy do monitorowania podczas treningu (early stopping, dobór hiperparametrów) 3. Zbiór testowy użyty jest raz, dopiero gdy trening jest gotowy — nie wielokrotnie do strojenia
Do samego pomiaru potrzebujecie ewaluacji z zdefiniowaną poprawną odpowiedzią dla Państwa zadania. Formaty różnią się w zależności od typu zadania:
- Klasyfikacja / routing — dokładność (accuracy), wynik F1, macierz pomyłek
- Ekstrakcja encji / ustrukturyzowane wyjście — token-level F1, exact match lub własny parser
- Zadania generatywne — tu sprawa się komplikuje: BLEU/ROUGE mają niską korelację z ludzką oceną jakości dla LLM; lepsze są LLM-as-judge (model frontier ocenia odpowiedź) lub własne rubryki
Dla większości doménowych przypadków użycia B2B zalecamy stworzenie 100–500 pytań z odpowiedziami referencyjnymi opracowanych ręcznie i zweryfikowanych przez eksperta dziedzinowego. To jest Państwa złoty standard. Ilość nie jest kluczowa — liczy się pokrycie typów przypadków i edge cases, które w praktyce są najważniejsze.
2. Porównanie base vs. fine-tuned
Model po fine-tuningu ewaluujcie zawsze w porównaniu z modelem bazowym, nie tylko w wartościach absolutnych. Powód: musicie wiedzieć, co fine-tuning rzeczywiście dodał ponad to, co dostaliście za darmo.
Typowa tabela wyników powinna zawierać:
- Model bazowy (bez fine-tuningu) na Państwa task-specific teście
- Model po fine-tuningu na tym samym teście
- Delta (poprawa lub pogorszenie)
Jeśli model po fine-tuningu wyprzedza model bazowy o marginalnie 2–3 %, krytycznie rozważcie, czy wart jest kosztów utrzymania. Jeśli delta jest ujemna, macie problem — albo z jakością danych, albo z ustawieniami treningu.
Porównanie ujawnia też, kiedy fine-tuning nie jest rozwiązaniem. Widzieliśmy przypadki, gdzie model bazowy z dobrze ustawionym promptem (system prompt, przykłady few-shot) osiągał 90 % tego, co model po fine-tuningu — przy zerowych kosztach treningu i bez ryzyka regresji. Dla takich przypadków zalecamy klientom decyzję RAG vs fine-tuning jako pierwszy krok przed treningiem.
3. Regresja na ogólnych umiejętnościach
To warstwa, którą większość zespołów pomija — a najczęściej właśnie tu ukrywają się problemy, które ujawniają się dopiero na produkcji.
Fine-tuning na wąskiej domenie może uszkodzić:
- Przestrzeganie instrukcji — model zaczyna ignorować części promptu, zmieniać format odpowiedzi
- Odmowę odpowiedzi na pytania spoza domeny — model próbuje odpowiadać domenowo nawet na pytania, na które powinien powiedzieć „nie wiem"
- Logiczne rozumowanie — wyniki na zadaniach reasoning mogą spaść
- Umiejętności językowe — jeśli trenowaliście na jednym języku, inne języki mogą ulec degradacji
Do wykrywania regresji stosujemy kombinację podejść:
a) Standardowe benchmarki jako sanity check
lm-evaluation-harness od EleutherAI pozwala uruchomić model na standardowych benchmarkach (MMLU i podobne). Nie oczekujcie, że model po fine-tuningu będzie lepszy na MMLU niż bazowy — to nie jest cel. Śledzicie, czy znacząco nie spadł (spadek o więcej niż kilka punktów to powód do zbadania sprawy).
b) Behavioral regression set
Stwórzcie własny zestaw przykładów, który obejmuje umiejętności ważne dla Państwa aplikacji, ale niezwiązane bezpośrednio z domeną treningową. Na przykład: - Formatowanie wyjścia (JSON, Markdown, tabele) - Odmowa odpowiedzi na bezsensowne pytania - Przestrzeganie instrukcji (spełnianie wielu warunków jednocześnie w promptcie) - Dokładność faktyczna w obszarach spoza domeny
Ten zestaw możecie złożyć raz i używać go przy każdej kolejnej rundzie fine-tuningu. Inwestycja zwraca się przy trzeciej i czwartej rundzie, gdy bez niego tracicie orientację.
c) Porównanie rozkładu odpowiedzi
Pragmatyczne podejście: weźcie 200–500 rzeczywistych wejść z produkcji (lub stagingu), uruchomcie na nich model bazowy i po fine-tuningu, a następnie porównajcie rozkład długości odpowiedzi, częstotliwość odmów i — jeśli macie ustawiony LLM-as-judge — rozkład ocen. Odchylenia statystyczne sygnalizują problem zanim zgłoszą go użytkownicy.
Konfiguracja held-out test setu: co robimy źle
Held-out test set brzmi prosto, ale w praktyce psuje się w kilku miejscach.
Kontaminacja dystrybucyjna: Jeśli generowaliście dane treningowe syntetycznie (model nauczyciel), a test set wygenerowaliście tym samym procesem, mierzycie tylko to, jak dobrze model naśladuje nauczyciela — nie jak dobrze rozwiązuje realne zadanie. Test set musi pochodzić z rzeczywistych przypadków lub być zweryfikowany przez eksperta dziedzinowego.
Separacja czasowa: W systemach produkcyjnych z regularnym fine-tuningiem kluczowe jest, aby test set był czasowo oddzielony od zbioru treningowego. Jeśli trenujecie na danych z Q1 i testujecie na danych z Q1 (nawet wydzielonym zbiorze), możecie nie dostrzec przesunięcia dystrybucji, które nastąpi w Q2. Idealnie, test set powinien pochodzić z innego okna czasowego niż trening.
Rozmiar i reprezentatywność: Test set z 50 przykładami jest zbyt mały dla statystycznie wiarygodnych wniosków dla większości zadań. W przypadku klasyfikacji binarnej potrzebujecie rzędu 300–500 przykładów, żeby 95% przedział ufności był wystarczająco wąski do podejmowania decyzji. W przypadku zadań generatywnych z LLM-as-judge mniejsze zbiory są użyteczne, ale interpretujcie z ostrożnością.
Wyciek przez augmentację: Jeśli do augmentacji danych treningowych używaliście parafraz lub wariantów rzeczywistych przykładów, sprawdźcie, że żaden wariant nie dostał się do test setu.
Praktyczny pipeline ewaluacji krok po kroku
Dla zespołów, które robią fine-tuning po raz pierwszy lub sporadycznie, zalecamy następujące minimalistyczne podejście:
- 1.Przed treningiem: Wydzielcie test set (minimum 10 % danych, nigdy nie używajcie go przy treningu), zarejestrujcie baseline score modelu bazowego zarówno na task-specific eval, jak i na behavioral regression secie.
- 1.Podczas treningu: Monitorujcie stratę walidacyjną (val loss) — powinna spadać razem ze stratą treningową. Jeśli val loss stagnuje lub rośnie, gdy train loss spada, przeuczacie model. Zatrzymajcie trening i spróbujcie mniejszej liczby epok lub większego
rankadaptera.
- 1.Po treningu: Uruchomcie model na task-specific test secie. Porównajcie z modelem bazowym. Uruchomcie behavioral regression set. Porównajcie z modelem bazowym.
- 1.Przed wdrożeniem: LLM-as-judge na próbce rzeczywistych wejść (jeśli macie). Ręczna recenzja co najmniej 20–30 konkretnych przypadków — liczby kłamią, a czytanie odpowiedzi ujawnia wzorce, których metryki nie widziały.
Cały ten pipeline możecie oprawić narzędziami takimi jak lm-evaluation-harness, własnym skryptem Pythona nad vLLM lub Ollama, albo platformami do ewaluacji w chmurze. Dla większości projektów B2B na miarę własny skrypt jest wystarczający — nie przeceniajcie infrastruktury, gdy potrzebujecie tylko wiarygodnej odpowiedzi na pytanie „czy model jest lepszy".
Kiedy regresja jest zbyt duża, żeby ją zaakceptować
Nie istnieje uniwersalna granica. Zależy od przypadku użycia. Kilka orientacyjnych reguł:
Poprawa task-specific musi przeważać nad regresją na ogólnych umiejętnościach. Jeśli fine-tuning poprawił dokładność domenową o 15 punktów, ale przestrzeganie instrukcji spadło o 20 %, wynik jest ujemny — nieodpowiedni format odpowiedzi czyni model mniej użytecznym nawet w tej samej domenie, którą ulepszyliście.
Zerowa poprawa na task-specific teście to powód, żeby się zatrzymać. Jeśli model bazowy z promptem few-shot osiąga takie same wyniki jak model po fine-tuningu, fine-tuning nie był potrzebny. Widzimy to u klientów częściej niż można by się spodziewać — nie doceniają, co potrafi dobry prompt.
Znacząca regresja w odmowie odpowiedzi na pytania spoza domeny to poważny problem. Model, który był trenowany do odpowiadania na techniczne zapytania o konkretny produkt, nie może zacząć z halucynacjami odpowiadać na pytania, gdzie poprawną odpowiedzią byłoby „tego nie wiem". Ta regresja to bezpośrednie ryzyko bezpieczeństwa w regulowanych branżach. Temat ten wiąże się z zagadnieniem guardrails dla agentów AI, gdzie mechanizm odmowy stanowi pierwszą linię obrony.
Ciągła ewaluacja: gdy fine-tuning powtarzacie
Modele domenowe nie są tunowane raz — jeśli robicie to prawidłowo, każda nowa runda danych przyniesie nową rundę fine-tuningu. W tym przypadku systematyczna ewaluacja jest jeszcze ważniejsza, ponieważ musicie śledzić trend przez iteracje, nie tylko wartości absolutne.
Zalecamy prowadzenie prostej dokumentacji każdej rundy: - Data treningu i wersja modelu (bazowy + po fine-tuningu) - Rozmiar zbioru treningowego i źródło danych - Wynik task-specific (bazowy / po fine-tuningu / delta) - Wynik behavioral regression - Notatki o anomaliach lub ręcznej recenzji
Ta dokumentacja to inwestycja, która zwróci się przy debugowaniu regresji w produkcyjnym systemie. Bez niej bywa, że zespół wie „coś się zmieniło po ostatnim treningu" — ale nie wie co, kiedy ani dlaczego.
Dla zespołów planujących regularny fine-tuning z cyklem krótszym niż miesiąc warto rozważyć zautomatyzowany pipeline ewaluacji — każdy commit nowego modelu uruchamia task-specific eval i regression set automatycznie, a wyniki są logowane. Ten poziom inwestycji ma sens w systemach produkcyjnych, gdzie model jest bezpośrednio we flocie interakcji z klientami.
Najczęstsze pytania
Ile przykładów potrzebuję w test secie?
Dla większości doménowych zadań B2B zalecamy minimum 100–300 ręcznie zweryfikowanych przykładów. Poniżej 100 wiarygodność statystyczna jest niska — mały zbiór utrudnia odróżnienie rzeczywistej poprawy od losowego rozrzutu. W przypadku klasyfikacji binarnej 300–500 to rozsądna dolna granica dla 95% przedziału ufności. W przypadku zadań generatywnych z LLM-as-judge można pracować z mniejszym zbiorem, ale interpretujcie z większą ostrożnością.
Co to jest LLM-as-judge i kiedy go stosować?
LLM-as-judge to technika, w której model frontier (np. z rodziny Claude Sonnet lub GPT) ocenia odpowiedzi modelu po fine-tuningu według zdefiniowanych kryteriów — dokładność, trafność, format, ton. Jest przydatny przy zadaniach generatywnych, gdzie nie istnieje jednoznaczna „poprawna odpowiedź". Wady: dodaje koszty (wywołania API), a judge może mieć własne odchylenia (preferuje dłuższe odpowiedzi, formalny styl). Dla domenowych aplikacji B2B zalecamy kombinację: LLM-as-judge do ogólnej jakości + deterministyczne metryki (exact match, parser) dla krytycznych pól.
Jak wykryć katastroficzne zapominanie bez złożonego zestawu benchmarków?
Pragmatyczne podejście: weźcie 50–100 rzeczywistych promptów, które model obsługiwał poprawnie przed fine-tuningiem, i sprawdźcie, czy radzi sobie z nimi też po treningu. Jeśli macie dostęp do logów systemu produkcyjnego, przejrzyjcie przykłady z wysokimi ocenami użytkowników — to dobry materiał na behavioral regression set. Kombinacja z szybkim ręcznym przejrzeniem 20–30 odpowiedzi ujawni większość problemów zanim dotrą do klienta.
Dlaczego val loss spada, ale jakość odpowiedzi się nie poprawia?
Klasyczny przypadek overfittingu lub niezgodności dystrybucji między treningiem a rzeczywistym użyciem. Strata walidacyjna spada, gdy model lepiej dopasowuje się do zbioru walidacyjnego — ale jeśli zbiór walidacyjny nie odzwierciedla rzeczywistych wejść, ta strata jest złym przybliżeniem rzeczywistej jakości. Inny powód: zbyt niski learning rate lub rank adaptera, przez co model nauczył się tylko powierzchownych wzorców. Spróbujcie zwiększyć rank (np. z 8 do 16 lub 32) i sprawdzić, czy zbiór walidacyjny jest reprezentatywny. Powiązany temat: dlaczego fine-tuning zawodzi.
Kiedy warto powtarzać fine-tuning zamiast stosować RAG?
Powtarzajcie fine-tuning, jeśli domena ustabilizowała się i macie stały dopływ nowych oznaczonych przykładów z produkcji. Jeśli wiedza domenowa zmienia się szybko (nowe produkty, zmienione regulacje), RAG jest elastyczniejszy — zmianę zapisujecie w bazie wiedzy, nie w wagach modelu. W kwestii decyzji o łączeniu obu podejść zajrzyjcie do artykułu dataset do fine-tuningu — ile i jakiej jakości.
*Jeśli rozważają Państwo fine-tuning własnego modelu i nie są pewni, jak ustawić proces ewaluacji, chętnie przyjrzymy się Państwa konkretnemu przypadkowi użycia. W MP Industrial Solutions pomagamy firmom zaprojektować cały pipeline od danych przez trening aż po ewaluację — tak, aby przed wdrożeniem na produkcję wiedzieli Państwo, co model naprawdę potrafi.*