Fine-tuning modelu: kiedy warto go przeprowadzić

Fine-tuning modelu ma sens dopiero wtedy, gdy dobrze zdefiniowane zadanie przegrywa powtarzalnie mimo poprawnego promptu, przykładów i dostępu do potrzebnej wiedzy. Nie jest skrótem do „nauczenia AI naszej firmy”. Zmienia sposób wykonywania zadania, lecz nie zastępuje bazy aktualnych dokumentów ani kontroli jakości. Właściciel produktu powinien najpierw zmierzyć punkt odniesienia, rozdzielić problem wiedzy od problemu zachowania i dopiero potem zdecydować, czy koszt danych treningowych, testów i utrzymania własnego wariantu modelu jest uzasadniony.

Najpierw nazwij błąd, który chcesz usunąć

„Model odpowiada słabo” nie jest wymaganiem. Trzeba ustalić, czy odpowiedź jest nieaktualna, niezgodna z formatem, zbyt długa, napisana niewłaściwym tonem, czy merytorycznie błędna w określonej klasie przypadków. Każdy z tych problemów prowadzi do innej interwencji.

Jeżeli odpowiedź ma korzystać z bieżących cenników, instrukcji, umów lub kart produktów, potrzebujesz mechanizmu pobierania wiedzy w chwili zapytania. Fine-tuning utrwala wzorce obecne w zbiorze treningowym; nie tworzy wygodnej, audytowalnej bazy faktów. Jeśli problemem jest natomiast stały format klasyfikacji, konsekwentny styl albo wykonywanie wąskiego zadania według wielu przykładów, dostrojenie może być właściwym narzędziem.

Dokumentacja Microsoft Foundry opisuje fine-tuning jako dalsze uczenie modelu bazowego na danych właściwych dla zadania. Wskazuje też, że projekt wymaga reprezentatywnego zbioru oraz osobnych kosztów treningu i hostowania. Omówienie warunków fine-tuningu w Microsoft Foundry podkreśla korzyści z krótszych promptów, ale nie obiecuje poprawy bez dobrych danych.

Objaw w aplikacji	Pierwsza interwencja	Kiedy rozważyć fine-tuning
Model nie zna aktualnego regulaminu	RAG lub narzędzie odczytujące źródło	Zwykle nie; wiedza szybko się zmienia
Wynik nie trzyma ustalonego formatu	Schemat odpowiedzi, walidator, przykłady w prompcie	Gdy błędy pozostają częste w wielu wariantach
Ton jest niespójny	Instrukcja stylu i kilka przykładów	Gdy masz dużo zaakceptowanych wzorców
Klasyfikacja myli konkretne kategorie	Lepsza definicja etykiet i test	Gdy granice klas są stabilne i dane są reprezentatywne
Model wykonuje złą operację	Reguły aplikacji, uprawnienia i zatwierdzenie	Fine-tuning nie zastępuje kontroli działania

Prompt, RAG i fine-tuning rozwiązują różne problemy

Prompt ustawia cel, kontekst i ograniczenia dla pojedynczego wywołania. Jest najtańszy w zmianie, dlatego od niego warto zacząć. Kilka dobrych przykładów w prompcie pozwala sprawdzić, czy model potrafi wykonać zadanie bez budowy procesu treningowego. Wadą jest rosnąca długość wejścia i trudność utrzymania wielu wyjątków.

RAG wyszukuje odpowiednie fragmenty dokumentów i dołącza je do zapytania. Nadaje się do wiedzy, którą trzeba aktualizować, cytować i kontrolować. Jego wynik zależy jednak od jakości dokumentów, podziału treści, wyszukiwania oraz instrukcji określającej, co model ma zrobić przy braku dowodu. RAG może dostarczyć prawidłowe źródło, lecz model nadal może źle wykonać polecenie.

Fine-tuning modyfikuje parametry modelu na podstawie przykładów. Supervised fine-tuning wykorzystuje pary wejście–oczekiwane wyjście. Microsoft opisuje także DPO, oparte na parach odpowiedzi preferowanej i niepreferowanej, oraz reinforcement fine-tuning dla zadań z wiarygodnym sygnałem oceny. Dostępność technik zależy od konkretnego modelu i regionu, dlatego nie warto wpisywać nazwy wersji modelu na stałe do strategii produktu. Aktualna lista znajduje się w dokumentacji fine-tuningu Microsoft Foundry.

Mechanizm	Co zmienia	Mocna strona	Główne ograniczenie
Prompt	Instrukcję dla bieżącego żądania	Szybka iteracja i łatwe wycofanie	Długi prompt podnosi koszt i może być kruchy
RAG	Kontekst wiedzy przekazany modelowi	Aktualność, źródła i kontrola dokumentów	Nie naprawia automatycznie sposobu wykonania zadania
Fine-tuning	Zachowanie modelu w określonym rozkładzie zadań	Spójność i możliwość skrócenia promptu	Potrzebuje danych, ewaluacji i utrzymania wersji
Reguła w kodzie	Deterministyczny fragment procesu	Przewidywalność i audytowalność	Nie radzi sobie z niejednoznacznym językiem

W praktyce te elementy mogą współpracować. Dostrojony model może generować wynik w ustalonym formacie, RAG dostarczać bieżące fakty, a kod blokować niedozwolone działania. Błędem jest oczekiwanie, że jedna technika przejmie wszystkie trzy role.

Warunki wejścia do eksperymentu

Zanim uruchomisz zadanie treningowe, potrzebujesz wersji bazowej i zbioru testowego. Wersja bazowa to ten sam przypadek użycia wykonany przez model bez dostrojenia, z najlepszym rozsądnym promptem. Bez niej nie wiadomo, czy nowa wersja przynosi poprawę, czy tylko wygląda inaczej.

Zbiór testowy musi pozostać poza treningiem. Powinien obejmować typowe przypadki, rzadkie wyjątki, niepełne dane oraz wejścia, które aplikacja ma odrzucić. Ocena nie może sprowadzać się do wrażenia po kilku rozmowach. Dla klasyfikacji można mierzyć trafność poszczególnych klas i koszt pomyłki. Dla odpowiedzi tekstowej potrzebna jest rubryka: zgodność z faktem, wykonanie instrukcji, format, kompletność, bezpieczeństwo i decyzja „akceptuj / popraw / odrzuć”.

Drugim warunkiem jest jakość przykładów treningowych. Jeżeli osoby przygotowujące dane nie zgadzają się, jaka odpowiedź jest poprawna, model przejmie tę niespójność. Najpierw dopracuj instrukcję dla człowieka etykietującego. Usuń duplikaty i dane, których nie wolno użyć. Oddziel przykłady pochodzące z rzeczywistego procesu od syntetycznych, a te drugie poddaj dodatkowej kontroli.

Trzecim warunkiem jest stabilność zadania. Dostrajanie do regulaminu zmienianego co miesiąc tworzy cykl ponownego treningu. Dostrajanie do stabilnego formatu ekstrakcji albo tonu odpowiedzi może mieć dłuższy okres użyteczności. W podejściu do transformacji AI decyzja o modelu jest częścią systemu danych, odpowiedzialności i procesu, a nie osobnym zakupem technicznym.

Jak przeprowadzić próbę bez zakłamywania wyniku

Zacznij od jednej mierzalnej czynności. Przykładem może być przypisanie zgłoszenia do jednej z dwunastu kategorii oraz wygenerowanie krótkiego uzasadnienia. Nie łącz w pierwszym teście klasyfikacji, odpowiedzi dla klienta, aktualizacji CRM i decyzji o rabacie. Każda dodatkowa czynność utrudnia wskazanie źródła błędu.

Podziel dane przed rozpoczęciem pracy. Zbiór treningowy służy do uczenia, walidacyjny do obserwacji procesu, a testowy do końcowego porównania. Nie poprawiaj przykładów testowych pod wyniki kolejnych prób, bo test przestaje być niezależny. Rejestruj wersję modelu bazowego, zbioru, parametrów i kodu oceniającego.

Przykład syntetyczny: zespół ma 900 zaakceptowanych zgłoszeń. Odkłada 180 do zamkniętego testu, 120 do walidacji, a 600 przeznacza na trening. To nie jest uniwersalna proporcja ani gwarancja jakości. Pokazuje jedynie, że wszystkie trzy role danych muszą zostać zaplanowane przed treningiem. Jeśli rzadka, kosztowna klasa ma tylko kilka przykładów, losowy podział może usunąć ją z testu. Wtedy trzeba zastosować podział warstwowy i oceniać klasy oddzielnie.

Etap	Pytanie kontrolne	Artefakt decyzji
Punkt odniesienia	Jak działa najlepszy prompt bez treningu?	Raport błędów dla zamkniętego testu
Dane	Czy przykłady są poprawne, dozwolone i reprezentatywne?	Wersjonowany zbiór i instrukcja etykietowania
Trening	Czy można odtworzyć konfigurację?	Identyfikator modelu, parametry i dziennik zadania
Porównanie	Czy poprawa dotyczy ważnych przypadków?	Wyniki bazowe i dostrojone według tej samej rubryki
Wdrożenie	Co stanie się po błędzie lub zmianie modelu?	Progi, monitoring, procedura wycofania

Dokumentacja Microsoft opisuje praktyczny przepływ: przygotowanie danych treningowych i walidacyjnych, wybór modelu bazowego, przesłanie danych, trening, wdrożenie oraz analizę dopasowania. Sam fakt zakończenia zadania treningowego nie oznacza gotowości produkcyjnej. Model trzeba jeszcze porównać na danych, których nie widział.

Koszt obejmuje więcej niż trening

Budżet powinien uwzględniać przygotowanie i przegląd danych, eksperymenty, ewaluację, hosting, zapytania produkcyjne, monitoring oraz migrację po wycofaniu wersji bazowej. Microsoft rozdziela koszty treningu i użycia wdrożonego modelu, a szczegóły zależą od metody oraz aktualnego cennika. Wytyczne zarządzania kosztami fine-tuningu zalecają korzystanie z bieżącej strony cenowej zamiast utrwalania stawek w dokumentacji projektu.

Fine-tuning może zmniejszyć liczbę przykładów dołączanych do każdego promptu i pozwolić mniejszemu modelowi wykonać wąskie zadanie. Taka oszczędność jest hipotezą do pomiaru. Trzeba zestawić koszt całego wariantu z bazą: cena pojedynczego żądania, opóźnienie, odsetek odpowiedzi wymagających poprawy oraz praca potrzebna do utrzymania danych. Tańsze wywołanie nie pomoże, jeśli częściej wymaga interwencji człowieka.

Do kosztu należy dodać cykl życia. Modele i ich wersje są wycofywane, a dostępność treningu i wdrożenia może kończyć się w różnych terminach. Polityka cyklu życia modeli Microsoft Foundry rozróżnia zakończenie możliwości treningu od zakończenia działania wdrożenia. Produkt musi mieć właściciela migracji i test regresji dla następnej wersji.

Ryzyka, których dostrojenie nie usuwa

Dostrojony model nadal jest modelem generatywnym. Może podać fałszywą informację, źle zinterpretować nietypowe wejście albo ujawnić niepożądany wzorzec z danych. NIST opisuje konfabulacje jako naturalne następstwo generowania odpowiedzi na podstawie rozkładu statystycznego, dlatego zaleca zarządzanie ryzykiem w całym cyklu życia. Profil ryzyka generatywnej AI NIST nie traktuje jakości treningu jako zamiennika walidacji wyników.

Szczególnej kontroli wymagają dane osobowe, tajemnice firmy, treści licencjonowane oraz decyzje o istotnym skutku dla człowieka. Minimalizacja danych zaczyna się przed wysłaniem zbioru do usługi. Po wdrożeniu potrzebujesz filtrowania wejścia, ograniczeń wyjścia, logów zgodnych z polityką prywatności oraz ścieżki eskalacji. Działanie w systemie, takie jak wysłanie wiadomości lub zmiana rekordu, powinno mieć odrębne uprawnienie i zatwierdzenie.

Uważaj też na pogorszenie przypadków, które wcześniej działały. Model może lepiej trzymać ton, lecz gorzej odpowiadać na rzadkie pytania. Dlatego raport powinien pokazywać wynik całkowity i wyniki segmentów. Średnia ukrywa klasę błędu, która biznesowo kosztuje najwięcej.

Monitoring po wdrożeniu powinien rozróżniać zmianę zachowania modelu od zmiany danych wejściowych. Jeśli pracownicy zaczynają przesyłać dłuższe dokumenty, nowe języki albo inną strukturę zgłoszeń, spadek jakości nie musi oznaczać awarii modelu. Jest sygnałem, że produkcyjny rozkład danych odszedł od zbioru treningowego. Zapisuj kategorię zadania, wersję modelu, decyzję walidatora i wynik kontroli człowieka, ale nie przechowuj bez potrzeby pełnej treści wrażliwych zapytań.

Ustal też moment zatrzymania. Kolejne treningi nie powinny trwać do chwili, gdy demonstracja wygląda dobrze. Eksperyment kończy się po osiągnięciu wcześniej zapisanego progu jakości albo po wykorzystaniu budżetu prób. W drugim przypadku poprawnym wynikiem jest decyzja o pozostaniu przy prompcie, RAG lub regule w kodzie. Brak wdrożenia dostrojonego modelu może być oszczędnością, jeśli dowód nie potwierdził przewagi.

Bramka decyzyjna dla właściciela produktu

Przed zgodą na fine-tuning odpowiedz „tak” na pięć pytań: zadanie jest wąskie i stabilne; masz mierzalny punkt odniesienia; dysponujesz prawidłowymi przykładami, których wolno użyć; zamknięty test obejmuje ważne wyjątki; zespół ma budżet i właściciela utrzymania. Jedna odpowiedź „nie” nie przekreśla produktu, lecz wskazuje wcześniejszą pracę.

W poniedziałek wybierz 30 reprezentatywnych wejść i oceń je na modelu bazowym przy użyciu jednej rubryki. Oznacz każdy błąd jako problem wiedzy, instrukcji, formatu, danych wejściowych albo kontroli procesu. Jeśli dominują braki wiedzy, zaplanuj RAG. Jeśli dominują powtarzalne błędy zachowania mimo dobrego promptu, przygotuj kontrolowany eksperyment z dostrojeniem. Szersze porównanie tych dróg znajdziesz w materiale o RAG, fine-tuningu i RAFT.