Fine tuning modeli LLM: kiedy ma sens i ile to kosztuje

Po co w ogóle dostrajać modele LLM

Różnica między modelem bazowym a modelem dostrojonym

Model bazowy LLM to uniwersalny „generalista”. Zna język, wiele faktów, potrafi programować, podsumowywać teksty, tłumaczyć. Jednak jego zachowanie jest ogólne: nie zna Twojej domeny, procesów, tonu marki, specyficznych ograniczeń prawnych czy produktowych.

Fine tuning LLM polega na dodatkowym trenowaniu istniejącego modelu na Twoich danych i Twoich przykładach zadań. Efekt to model, który ma wyuczony konkretny sposób reagowania: inną strukturę odpowiedzi, bardziej precyzyjny język, dopasowanie do logiki procesów biznesowych.

Intuicyjnie: model bazowy to „dobrze wykształcony pracownik na rynku”, a model dostrojony to ta sama osoba po intensywnym onboardingu i szkoleniu wewnętrznym. Zna żargon firmy, rozumie, czego nie wolno obiecać klientowi i jakiej terminologii używać.

Kluczowe cele biznesowe dostrajania modeli językowych

Dostrajanie modeli językowych ma sens tylko wtedy, gdy przekłada się na konkretne wskaźniki biznesowe. Typowe cele:

• Skrócenie czasu pracy ludzi – agent supportu szybciej odpowiada, analityk szybciej analizuje dokumenty, prawnik dostaje lepiej przygotowane drafty umów.
• Poprawa jakości odpowiedzi – mniej błędów merytorycznych, większa precyzja, lepsza zgodność z dokumentacją produktową.
• Standaryzacja stylu i tonu – model zawsze pisze w stylu marki, zachowuje odpowiedni poziom formalności, stosuje właściwą terminologię.
• Automatyzacja powtarzalnych zadań – generowanie raportów, klasyfikacja zgłoszeń, ekstrakcja pól z dokumentów.
• Zmniejszenie ryzyka – model domyślnie zachowuje ostrożność prawną, nie obiecuje niemożliwych rzeczy, ma przypisane bezpieczne ramy zachowania.

Jeśli nie da się zdefiniować, jak dostrajanie obniży koszty, zwiększy przychód albo zmniejszy ryzyko – koszty trenowania LLM zwykle nie będą się spinały.

Kiedy wystarczy prompt engineering, a kiedy potrzebny jest fine tuning

Prompt engineering i dobra instrukcja systemowa często rozwiązują 70–80% problemów bez konieczności trenowania modelu. Ustawienie jasnych reguł, przykładów odpowiedzi, formatu outputu oraz dopasowanie długości odpowiedzi bywa zaskakująco skuteczne.

Przykładowo, jeśli potrzebujesz po prostu:

• zmienić ton wypowiedzi (bardziej formalny/nieformalny),
• utrzymać strukturę (np. punktowe listy, sekcje),
• podawać odpowiedzi po polsku zamiast po angielsku,
• dorzucić parę reguł typu „nie odpowiadaj na pytania spoza tematu X” –

– zazwyczaj wystarczy dobrze przygotowany prompt systemowy + parę przykładów (few-shot learning).

Fine tuning zaczyna mieć sens, gdy:

• nawet przy bardzo dopracowanym promcie odpowiedzi są niestabilne (raz świetne, raz słabe),
• trzeba uczyć model bardzo specyficznych schematów reakcji, których nie chwyta z samych promptów,
• konieczna jest skrajna spójność stylu i struktury (np. generowanie ofert, pism procesowych, odpowiedzi do klientów),
• zachowanie modelu musi być „automatycznie poprawne”, bez liczenia na to, że użytkownik zawsze poda dobry prompt.

Przykładowe zastosowania, gdzie dostrajanie naprawdę pomaga

Kilka typowych scenariuszy, gdzie fine tuning LLM na własnych danych przynosi wyraźny zysk:

• Support i helpdesk – model uczony na prawdziwych konwersacjach z klientami, z poprawkami agentów. Efekt: bardziej trafne odpowiedzi, mniejsza liczba eskalacji do drugiej linii.
• Dokumentacja techniczna – dostrojony na bazie wewnętrznej dokumentacji i ticketów serwisowych, generuje odpowiedzi dokładnie w stylu knowledge base, zamiast ogólnych porad.
• Generowanie kodu – model dostrojony na repozytoriach firmy, konwencjach kodowania, typowych wzorcach projektowych; generuje kod bliższy temu, jak pisze zespół.
• Analiza tekstu – klasyfikacja zgłoszeń, tagowanie maili, ekstrakcja pól z faktur/umów. Tu dostrajanie na dobrych etykietach znacznie przewyższa „goły” model.

W tych obszarach różnica między „ogólnym” LLM a dobrze dostrojonym modelem często przekłada się wprost na liczbę godzin pracy ludzi. To dobry punkt startu do kalkulacji opłacalności.

Jakie są opcje personalizacji LLM oprócz fine tuningu

Prompt engineering, system messages i narzędzia

Najtańszą formą personalizacji są techniki bez trenowania modelu:

• System message / instrukcja systemowa – opis roli, zasad, tonu, ograniczeń. To fundament zachowania modelu.
• Prompt engineering – precyzyjne instrukcje, przykłady, formaty. Dobrze zaprojektowany prompt potrafi uporządkować nawet skomplikowane zadania.
• Tool calling / funkcje – model nie musi „znać wszystkiego”, może wywoływać narzędzia: bazy wiedzy, API CRM, kalkulatory. Zamiast uczyć model liczyć raty kredytu, daje się mu funkcję do obliczeń.

Wiele rzeczy, które intuicyjnie wydają się wymagające dostrajania, można załatwić przez kombinację: dobra instrukcja + narzędzia + kontrola kontekstu.

RAG kontra fine tuning – dwa różne problemy

Retrieval-Augmented Generation (RAG) polega na tym, że przed wygenerowaniem odpowiedzi system szuka powiązanych dokumentów (np. w wektorowej bazie danych), a następnie podaje je modelowi jako kontekst. Model bazowy pozostaje bez zmian, ale ma dostęp do aktualnych informacji.

RAG jest idealny, gdy chcesz:

• dodać wiedzę domenową, która często się zmienia (cenniki, regulaminy, dokumentacja produktowa),
• mieć łatwą aktualizację – zmieniasz dokumenty, nie trenowanie modelu,
• zachować kontrolę nad źródłami, do których model się odwołuje.

Fine tuning służy raczej do zmiany nawyków i sposobu reagowania modelu niż do dodawania świeżej wiedzy. Jeśli problem polega na tym, że model nie zna nowych produktów, podatków, procedur – RAG zwykle będzie lepszym (i tańszym) rozwiązaniem niż dostrajanie.

Profile użytkownika i pamięć jako alternatywa

Coraz więcej platform oferuje profile użytkownika i kontekst długoterminowy. Model nie jest trenowany na nowo, ale ma dostęp do zapisanych preferencji i historii interakcji.

To podejście ma sens, gdy:

• ważniejsze jest indywidualne dopasowanie (np. ulubiony format raportu, preferowana terminologia),
• brak potrzeby modyfikowania samego modelu – wystarczy podać mu stałe instrukcje i historię.

Przykład: konsultant finansowy bazujący na LLM pamięta profil ryzyka klienta, jego cele i wcześniejsze decyzje. Nie trzeba trenować nowego modelu – wystarczy mądrze podawać mu kontekst.

Prosta macierz decyzyjna: kiedy co wybrać

Kiedy fine tuning ma sens, a kiedy jest przerostem formy

Najważniejsze kryteria decyzyjne

Decyzja o dostrajaniu modelu LLM powinna opierać się na kilku twardych kryteriach:

• Częstotliwość zadania – im więcej interakcji dziennie obsługuje model, tym bardziej opłaca się inwestować w jego dopasowanie.
• Skala użytkowników – czy to narzędzie dla 3 osób w zespole, czy dla setek pracowników / tysięcy klientów.
• Krytyczność jakości – błędy w mało istotnych zadaniach są akceptowalne, w prawie czy medycynie – nie.
• Wymóg spójnego stylu i formatu – im większe znaczenie ma identyczna struktura odpowiedzi, tym więcej korzyści z dostrajania.
• Stabilność wiedzy domenowej – jeśli wiedza szybko się zmienia, częsty retraining będzie bardzo kosztowny.

Dobrym filtrem jest pytanie: „Czy różnica 10–20% w jakości odpowiedzi przełoży się na realne pieniądze lub ryzyko?”. Jeśli nie – najpierw warto wycisnąć maksimum z prompt engineeringu i RAG.

Sygnały, że sam prompt już nie wystarcza

Istnieje kilka powtarzalnych symptomów, że osiągnięto granicę tego, co da się zrobić promtem:

• Niestabilność odpowiedzi – ten sam prompt + ten sam kontekst dają znacząco różne jakościowo odpowiedzi.
• Mieszanie języków – mimo jasnej instrukcji o używaniu wyłącznie polskiego lub firmowego żargonu, model czasem „przeskakuje” na angielski lub używa niepożądanych terminów.
• Brak stylu marki – każde wygenerowane pismo brzmi inaczej, mimo że podano konkretny styl w instrukcjach.
• Trudność z restrykcyjnym formatem – mimo podawania przykładów model nie trzyma bardzo ścisłej struktury (np. narzucone pola JSON, konkretne paragrafy w umowie).

Jeśli powyższe problemy występują systematycznie, a testowano już różne warianty promptów i kontekstu – to dobry moment, by rozważyć dostrajanie na własnych danych.

Scenariusze, gdzie fine tuning zwykle szkodzi

Są sytuacje, w których dostrajanie modeli LLM jest nie tyle zbędne, co wręcz szkodliwe lub ekonomicznie absurdalne:

• Bardzo mało danych – kilkadziesiąt przykładów nie wystarczy. Model może „przeuczyć się” na tych danych, tracąc ogólną jakość (overfitting w LLM).
• Dynamiczna wiedza domenowa – gdy treści zmieniają się co tydzień (promocje, oferty), lepiej użyć RAG i aktualizować dokumenty niż trenować model co chwilę.
• Mały ruch / niska skala – jeśli rozwiązanie dotyczy kilku użytkowników, koszt projektu fine tuningu może nigdy się nie zwrócić.
• Brak dojrzałego procesu danych – gdy firma nie ma porządku w danych, brak etykiet, brak ludzi do walidacji, fine tuning generuje koszt i chaos bez trwałej poprawy.

W takich przypadkach lepszym kierunkiem jest inwestycja w jakość promptów, logikę aplikacji, dobre filtrowanie i konstrukcję kontekstu.

Przykłady decyzji: mały startup vs duża korporacja

Mały startup z kilkoma osobami tech i ograniczonym budżetem:

• Najpierw wyciska z modelu bazowego ile się da: silny prompt, RAG, prosty system feedbacku.
• Fine tuning rozważa dopiero wtedy, gdy produkt zaczyna mieć poważną trakcję, a ograniczenia modelu blokują rozwój.

Duża korporacja z własnym działem ML i wysokimi wymaganiami compliance:

• Wybiera często modele open source + własną infrastrukturę lub dedykowany fine tuning przez API dostawcy, ze względu na kontrolę nad danymi.
• Inwestuje w dostrajanie, bo nawet 2–3% poprawy jakości w skali tysięcy interakcji dziennie oznacza ogromne oszczędności.

Ten sam problem techniczny – np. klasyfikacja wiadomości od klientów – może w startupie zostać rozwiązany przez sprytny prompt, a w korporacji uzasadnić pełnoprawny projekt ML z fine tuningiem i MLOps dla LLM.

Co dokładnie zmienia fine tuning w modelu LLM

Intuicyjne ujęcie: nowy nawyk reagowania

Jak fine tuning „przekręca gałki” w modelu

Model po dostrojeniu to nie jest zupełnie nowa sieć neuronowa, tylko ten sam organizm z przesuniętymi akcentami. Technicznie modyfikowane są wagi, ale w praktyce dzieje się kilka rzeczy naraz:

• Zmiana priorytetów zachowań – model częściej wybiera odpowiedzi podobne do przykładów z treningu, a rzadziej „improwizuje”.
• Wzmocnienie określonych wzorców – jeśli 10 tys. razy pokazałeś, że e-mail ma zaczynać się od „Dzień dobry,” i kończyć „Z poważaniem,”, model zaczyna traktować to jako normę, a nie tylko sugestię.
• Ograniczenie przestrzeni możliwych odpowiedzi – nadal ma ogólną wiedzę, ale w kontekście dostrojonego zadania ma „ciasny korytarz”, którym zwykle idzie.
• Lekkie przesunięcie języka i żargonu – częściej występują słowa, skróty i zwroty z danych treningowych, zwłaszcza jeśli są spójne.

Dlatego po mocnym fine tuningu model może radykalnie zmienić styl na zadaniach, na których był trenowany, a jednocześnie nadal działać zupełnie normalnie na ogólnych rozmowach.

Granice modyfikacji: czego fine tuning nie zrobi

Fine tuning bywa przeceniany jako remedium na wszystko. Są obszary, gdzie praktycznie nie pomoże albo wręcz pogorszy sytuację:

• Nie zamieni GPT-3.5 w GPT-4 – nie podniesie magicznie „inteligencji” modelu. Może lepiej ustawić priorytety, ale nie dorobi mu głębszego rozumowania.
• Nie naprawi fundamentalnych ograniczeń architektury – np. bardzo krótkiego kontekstu, ograniczeń co do długości wejścia/wyjścia.
• Nie zastąpi RAG dla szybko zmieniacej się wiedzy – model po treningu „zamraża” informacje, których się nauczył.
• Nie usunie całkowicie halucynacji – może zmniejszyć ich liczbę w konkretnych scenariuszach, ale nie wyeliminuje mechanizmu sam w sobie.

Jeżeli problem wynika z tego, że model „nie ogarnia” skomplikowanego rozumowania wieloetapowego, to lepszym rozwiązaniem często będzie zmiana modelu na silniejszy + lepszy chain-of-thought / narzędzia, a nie fine tuning słabszego.

Wpływ fine tuningu na bezpieczeństwo i „cenzurę” modelu

Dostrajając model, wchodzisz również w obszar zachowań bezpieczeństwa i filtrów. Można:

• wzmocnić konserwatywne odpowiedzi (np. zawsze odmawiaj porad medycznych poza schematem),
• przekalibrować reakcje na trudne treści (np. agresja, wulgaryzmy, przestępstwa),
• niechcący osłabić mechanizmy bezpieczeństwa, jeśli dane treningowe są źle dobrane.

Przykład z praktyki: zespół trenuje model prawniczy na realnych mailach z ostrzejszym językiem, żeby lepiej rozumiał kontekst sporów. Po treningu model zaczyna akceptować dużo bardziej „toksyczny” styl, bo nauczył się, że to norma. Przy braku testów bezpieczeństwa może to wyciec na zewnątrz.

Dlatego do fine tuningu zawsze warto dołożyć oddzielny pakiet danych bezpieczeństwa – zestaw sytuacji, w których model ma jasno reagować: odmawiać, przekierowywać, cytować procedury.

Jak fine tuning wpływa na różne typy zadań

Reakcja modelu na dostrajanie jest inna w zależności od typu zadania. Inaczej zachowuje się przy kreatywnym pisaniu, inaczej przy klasyfikacji czy ekstrakcji pól.

• Generowanie długich tekstów – fine tuning urealnia styl, struktury, ulubione zwroty. Trzeba pilnować, by model nie stał się „sztywny” i nie powielał ciągle tych samych szablonów.
• Klasyfikacja / tagging – tu efekty bywają spektakularne. Kilka tysięcy dobrze opisanych przykładów potrafi zmniejszyć liczbę błędnych klasyfikacji o rząd wielkości.
• Ekstrakcja danych – model uczy się ignorować „szum” dokumentu i skupia się na polach, które pokazałeś w treningu.
• Konwersacyjne interfejsy – drobny fine tuning tonuje styl (np. mniej „AI-owego” gadania, więcej konkretu) i stabilizuje zachowanie w długich dialogach.

Wymagania dotyczące danych do fine tuningu

Jak zdefiniować „dobry przykład” do dostrajania

Dane do fine tuningu to w praktyce zbiór rozmów lub par wejście–wyjście, które chcemy, by model naśladował. Dobry przykład ma kilka cech:

• Realność – bazuje na prawdziwych przypadkach lub bardzo bliskich symulacjach, a nie sztucznie wymyślonych dialogach „pod tezę”.
• Kompletność – wejście zawiera wszystkie informacje, jakie użytkownik miałby w realnym systemie, a nie „magicznie” ukryte dane.
• Spójny styl – odpowiedzi są w jednym tonie, strukturze i poziomie szczegółowości. Mieszanka „trochę tak, trochę inaczej” osłabia efekt treningu.
• Brak sprzeczności – jeśli w połowie przykładów odpowiedź A jest poprawna, a w drugiej połowie B, model dostaje sygnał chaosu.

Przy prostych zadaniach (np. klasyfikacja) dobra zasada: jeśli człowiek-ekspert nie potrafi wytłumaczyć dlaczego dana odpowiedź jest taka, a nie inna – model też będzie miał problem.

Minimalne i rozsądne wolumeny danych

Liczba potrzebnych przykładów zależy od złożoności zadania. Orientacyjne widełki:

• Proste klasyfikacje / tagowanie: 500–2 000 przykładów na etykietę to często wystarczy, jeśli etykiety są klarowne.
• Formatowanie odpowiedzi / styl pisania: 1 000–5 000 par wejście–wyjście, im bardziej zróżnicowane przypadki, tym lepiej.
• Złożone dialogi, agent konwersacyjny: 5 000–50 000 tur rozmów (lub ich fragmentów), dobrze opisanych i oczyszczonych.

Nie trzeba od razu dziesiątek tysięcy przykładów. Często rozsądna strategia to iteracje: zacząć od 500–1 000 przykładów, sprawdzić efekt, dobrać kolejne tam, gdzie model nadal się myli.

Jakość nad ilość: typowe błędy w przygotowaniu danych

Najczęstsze problemy nie wynikają z zbyt małej liczby przykładów, tylko z ich jakości. Typowe wpadki:

• Brak ujednoliconego stylu – część odpowiedzi pisana skrótowo, część superformalnie; model potem miksuje oba style.
• Niejasne etykiety – w klasyfikacji nazwy kategorii są podobne lub nakładają się znaczeniowo. Ludzie w zespole sami się mylą.
• Niewidoczne założenia – anotator wie coś z kontekstu firmy, czego nie ma w danych wejściowych. Model tego nie ma skąd wiedzieć, więc „zgaduje”.
• Brak przykładów „trudnych przypadków” – trening wyłącznie na prostych, idealnych danych, a potem produkcja zalewa model złożonymi kombinacjami.

Lepsze 2 000 solidnych, przemyślanych przykładów niż 20 000 szybko „naklikanych” bez kontroli jakości.

Bezpieczeństwo danych i anonimizacja

Przy projektach komercyjnych temat danych do fine tuningu wchodzi od razu w obszar compliance. Kilka praktycznych zasad:

• Anonimizacja w pierwszej kolejności – imię, nazwisko, numer klienta, PESEL, NIP, adres – wszystko, co da się usunąć lub zsyntetyzować, usuń. Często wystarczy zachować strukturę (np. „[ID_KLIENTA]”, „[KONTO_BANKOWE]”).
• Oddzielne zbiory dla dostawcy chmurowego – jeśli fine tuning odbywa się u zewnętrznego dostawcy, używaj tylko danych, które możesz tam legalnie wysłać.
• Dokumentacja źródła danych – skąd pochodzą: helpdesk, CRM, ERP, e-maile. Ułatwia to odpowiadanie audytorom i powtórne trenowanie.
• Versioning zestawów treningowych – każda nowa iteracja danych powinna mieć wersję i opis zmian. Umożliwia porównywanie rezultatów i powrót do poprzednich modeli.

Proces anotacji: kto, jak i na jakich narzędziach

Dane „same z siebie” rzadko nadają się do fine tuningu. Potrzebny jest proces anotacji lub przynajmniej weryfikacji. Trzy poziomy organizacji tego procesu:

1. Eksperci domenowi + prosty arkusz
   Dla małych projektów wystarczy Excel/Google Sheets z kolumnami: input, ideal_output, notes. Eksperci wypełniają go na bazie realnych przypadków.
2. Panel anotacyjny
   Dedykowane narzędzia (np. Label Studio, doccano, własny panel) pomagają rozdzielać pracę, kontrolować jakość i przeprowadzać podwójną anotację (dwóch ludzi na ten sam przykład).
3. „Human in the loop” z modelem bazowym
   Model generuje wstępne odpowiedzi, anotator je poprawia zamiast pisać od zera. Przyspiesza proces, ale wymaga dyscypliny, żeby nie przepuszczać „prawie dobrych” odpowiedzi.

W praktyce dobrze działa miks: model podpowiada, człowiek koryguje, a drugi człowiek robi wyrywkowy audyt jakości.

Koszty fine tuningu – z czego się naprawdę składają

Pięć głównych kategorii kosztów

Budżet na fine tuning to nie tylko „GPU i API”. W każdym realnym projekcie pojawiają się co najmniej następujące pozycje:

• Przygotowanie danych – zbieranie, czyszczenie, anonimizacja, anotacja.
• Infrastruktura i compute – GPU / CPU, storage, koszty chmury lub klastrów on-premise.
• Praca specjalistów – ML engineer, data engineer, eksperci domenowi, ops (monitoring, wdrożenie).
• Eksperymenty i iteracje – kilka–kilkanaście cykli: trening, ewaluacja, poprawki danych.
• Utrzymanie i retraining – aktualizacje modelu, poprawki po zmianach w biznesie lub prawie.

Jeżeli w kalkulacji budżetu uwzględniasz wyłącznie koszty GPU lub faktury za API, wynik będzie kompletnie nierealistyczny.

Koszt danych: największa, ale ukryta pozycja

Nawet przy tanim compute przygotowanie danych potrafi być najdroższą częścią projektu. Składają się na to:

• czas ludzi, którzy zbierają i czyszczą dane z systemów źródłowych,
• czas ekspertów domenowych, którzy opisują przykłady lub weryfikują generatywne dane,
• koszt narzędzi anotacyjnych (jeśli kupujesz komercyjne rozwiązania).

Przykład z życia: zespół planował tydzień na przygotowanie danych. Ostatecznie spędzili miesiąc na samej anonimizacji i dopinaniu formatu, bo treści pochodziły z kilku różnych systemów, każdy z innym schematem.

Compute: różnica między API a własnym klastrem

Dwa główne modele kosztowe:

• Fine tuning przez API dostawcy (OpenAI, Anthropic, itp.)
  Płacisz za:
  • wejściowe tokeny treningowe (przesyłanie danych),
  • tokeny użyte do właściwego treningu,
  • czasami za przechowywanie modelu i ew. retrening.

  Plusy: prostota, brak zarządzania sprzętem. Minusy: ograniczona kontrola, limity, polityka danych dostawcy.

• Własna infrastruktura / chmura IaaS
  Płacisz za:
  • godziny GPU (czasem także storage SSD / NVMe),
  • utrzymanie klastrów (Kubernetes, Slurm, itp.),
  • time-box pracy inżynierów na konfigurację i debugging.

  Opłacalne przy większej skali, kilku–kilkunastu projektach rocznie lub wymaganiach compliance.

Koszt ludzi: kogo realnie trzeba zaangażować

Bez ludzi fine tuning nie pojedzie. Typowy skład minimalny:

• ML engineer – prowadzi eksperymenty, dobiera parametry, analizuje wyniki.
• Data engineer – zaciąga dane z systemów, dba o pipeline, wersjonowanie.
• Ekspert domenowy – weryfikuje, czy odpowiedzi modelu są faktycznie poprawne biznesowo.
• Product owner / analityk – pilnuje, by projekt odpowiadał na realne potrzeby, a nie był R&D dla R&D.

Przy mniejszych projektach role łączą się w 2–3 osoby. Przy większych – każda z nich potrafi zająć kogoś na dłużej niż miesiąc.

Ukryte koszty iteracji i eksperymentów

Na papierze fine tuning to „jedno szkolenie modelu”. W praktyce rzadko kiedy pierwszy eksperyment daje używalny wynik. Typowy cykl wygląda tak:

• przygotowanie pierwszej wersji danych,
• 1–3 eksperymenty z parametrami (learning rate, liczba epok, rozmiar batcha),
• analiza błędów, poprawki danych,
• kolejne 1–2 eksperymenty z odświeżonym zbiorem.

Każda iteracja to:

• czas GPU lub kolejne wywołania API,
• czas inżyniera, który przygotowuje run,
• czas eksperta domenowego na ocenę wyników.

Jeśli budżet nie uwzględnia tych pętli, projekt zatrzymuje się na „pierwszym w miarę działającym” modelu, który potem i tak frustruje użytkowników.

Utrzymanie: model to nie jest „raz i koniec”

Po wdrożeniu zaczynają pojawiać się nowe przypadki, zmiany w produktach, nowe regulacje. Model, który dziś działa dobrze, za pół roku może być przestarzały. Typowe koszty utrzymania:

• zbieranie nowych przykładów z produkcji (logi, feedback użytkowników),
• okresowy re-trening lub „doszkalanie” na nowych danych,
• monitoring jakości (drifty w rozkładzie danych, spadek accuracy / satysfakcji).

W praktyce opłaca się od razu założyć budżet na 2–4 rundy odświeżenia modelu w roku, zamiast traktować projekt jako jednorazowy strzał.

Przegląd praktycznych opcji fine tuningu (open source i komercyjne)

Trzy główne ścieżki techniczne

W większości projektów wybór sprowadza się do jednej z trzech dróg:

• Fine tuning przez API dużego dostawcy – minimalna operacyjność, mniejsza kontrola.
• Fine tuning modelu open source w chmurze – więcej swobody, nadal relatywnie prosto.
• Fine tuning na własnej infrastrukturze – największa kontrola, najwyższy próg wejścia.

Komercyjni dostawcy z fine tuningiem przez API

Dla wielu zespołów to najszybsza droga do produkcji. Standardowy schemat wygląda podobnie u większości vendorów:

1. Przygotowujesz zestaw par input–output w konkretnej strukturze JSON.
2. Wgrywasz dane do usługi (CLI, SDK lub panel www).
3. Konfigurujesz parametry (typ bazowego modelu, budżet, liczba epok).
4. Czekasz na zakończenie treningu i dostajesz identyfikator własnego wariantu modelu.

Plusy takiego podejścia:

• brak potrzeby zarządzania GPU,
• zazwyczaj gotowe metryki i logi z treningu,
• łatwe skalowanie wywołań w produkcji (te same endpointy co dla modelu bazowego).

Minusy:

• ograniczona możliwość modyfikacji architektury czy niższego poziomu hiperparametrów,
• zależność od polityki danych dostawcy (co się dzieje z danymi treningowymi, gdzie są przechowywane),
• często wyższy koszt jednostkowy za token niż przy własnym klastrze przy dużej skali.

Modele open source – kiedy mają przewagę

Open source jest atrakcyjny, gdy:

• polityka firmy wymaga pełnej kontroli nad modelem i danymi,
• chcesz wdrożyć model on-premise lub w prywatnej chmurze,
• masz niestandardowe wymagania (np. specyficzny kontekst, własne tokenizery, integracje).

Popularne rodziny modeli (stan na dziś):

• LLaMA / Meta – wiele wariantów, bogaty ekosystem narzędzi.
• Mistral / Mixtral – efektywne, często dobre parametry koszt/jakość.
• Qwen, Gemma, inne nowsze architektury – zwykle dobrze udokumentowane, z gotowymi przykładami fine tuningu.

Do fine tuningu open source używa się najczęściej:

• Hugging Face Transformers + peft (LoRA / QLoRA),
• narzędzi typu vLLM, Axolotl, Lit-GPT, które upraszczają trening i serving.

Własna infrastruktura vs chmura pod open source

Gdy wybór padł na open source, zostaje pytanie: własne GPU czy chmura?

• Chmura (AWS, GCP, Azure, lokalni dostawcy)
  Dobra dla zespołów, które nie chcą inwestować w sprzęt. Płacisz za godziny GPU, ale łatwo skalujesz w górę i w dół. Sprawdza się przy nieregularnym obciążeniu (kilka projektów rocznie).
• Własne GPU / on-premise
  Ma sens, gdy:
  • projekty są ciągłe, a GPU będą używane blisko 24/7,
  • polityka bezpieczeństwa blokuje wyjście danych do publicznej chmury,
  • masz zespół, który faktycznie utrzyma klastry, storage i sieć.

Częsta pułapka: kupno „mocnej karty” do jednego serwera, a potem walka z tym, że nie ma kto tego monitorować, backupować i aktualizować. Wtedy „tanie GPU” szybko robi się drogie.

LOPS, adaptery i QLoRA – praktyczne triki obniżające koszty

Pełny fine tuning wszystkich wag dużego modelu jest drogi i często zbędny. Większość projektów biznesowych korzysta dziś z technik parametrycznej adaptacji:

• LoRA / QLoRA – do modelu dodaje się małą liczbę dodatkowych parametrów, które są trenowane, a oryginalne wagi pozostają zamrożone.
• Adaptery – osobne, wpinane „warstwy” między istniejące bloki modelu, uczone na nowych danych.

Korzyści:

• mniej pamięci GPU potrzebnej do treningu,
• krótszy czas treningu,
• możliwość utrzymywania kilku wariantów dostrojonych do różnych zastosowań (np. „support PL”, „support EN”, „doradztwo prawne”) na bazie jednego modelu.

W projektach z ograniczonym budżetem QLoRA na modelu 7–13B często daje całkiem dobry kompromis między jakością a kosztami.

Jak krok po kroku zaplanować fine tuning LLM

Krok 1: Zweryfikuj, czy fine tuning jest w ogóle potrzebny

Zanim powstanie pierwszy zestaw danych treningowych, warto zrobić prosty test:

1. Weź 50–100 realnych przypadków (pytania klientów, zadania użytkowników).
2. Przetestuj bazowy model z dobrze zaprojektowanym promptem i ewentualnym RAG.
3. Oceń wyniki z ekspertem domenowym w skali np. 1–5 (jakość, bezpieczeństwo, kompletność).

Jeżeli po dopracowaniu promptów i kontekstu (RAG) jakość jest akceptowalna, a błędy są rzadkie i łatwe do wychwycenia – fine tuning może się nie zwrócić. Jeśli mimo wysiłków wciąż masz:

• systematyczne błędy,
• problem z trzymaniem struktury odpowiedzi,
• za duży rozrzut w stylu i długości,

wtedy jest argument za wejściem w dostrajanie.

Krok 2: Zdefiniuj precyzyjną metrykę sukcesu

„Ma działać lepiej” to nie jest cel projektu. Ustal, co konkretnie ma się poprawić:

• procent poprawnych klasyfikacji (np. F1 > 0.9),
• średni czas obsługi zgłoszenia (SLA) z pomocą modelu,
• ocena satysfakcji użytkownika (NPS, CSAT z ankiet po odpowiedzi),
• odsetek przypadków wymagających interwencji człowieka.

Równolegle określ granice akceptowalnego ryzyka – np. brak halucynacji w obszarach prawnych lub finansowych. Bez tego „lekko lepszy” model może wciąż być nie do użycia produkcyjnie.

Krok 3: Zaprojektuj format danych treningowych

Zanim zaczniesz zbierać przykład za przykładem, ustal szablon. Dla chatbotów może to być np.:

{
  "input": "Pytanie klienta + kontekst (np. historia rozmowy)",
  "system_prompt": "Instrukcja roli i stylu asystenta",
  "ideal_output": "Odpowiedź modelu w docelowym formacie",
  "meta": {
    "language": "pl",
    "category": "reklamacja",
    "difficulty": "hard"
  }
}

Stały format ułatwia:

• automatyczne walidowanie danych,
• filtrowanie przykładów (np. tylko trudne przypadki),
• późniejsze analizy błędów (które kategorie sprawiają największy problem).

Krok 4: Zbuduj minimalny, ale reprezentatywny zbiór

Celem pierwszej iteracji nie jest kompletność, tylko uchwycenie najważniejszych typów przypadków. Dobra praktyka:

• 20–30% przykładów z „happy path” – typowe, proste scenariusze,
• 50–60% przykładów z trudniejszymi przypadkami (edge cases),
• 10–20% przykładów z negatywnymi przykładami (czego model ma nie robić: odmowa, przekierowanie, brak odpowiedzi zamiast halucynacji).

Do tego od razu przygotuj osobny zestaw walidacyjny i testowy, którego model nie zobaczy w treningu. Jeśli tych zbiorów nie oddzielisz, wyniki będą zbyt optymistyczne.

Krok 5: Wybierz model bazowy i strategię dostrajania

Tu przydaje się prosta macierz decyzyjna:

• Wysoka wrażliwość danych + silne ograniczenia prawne → raczej model open source on-premise lub w prywatnej chmurze.
• Szybki time-to-market + mniejsza wrażliwość danych → fine tuning przez API dużego dostawcy.
• Ograniczony budżet compute → mniejszy model (7–13B) + LoRA/QLoRA zamiast pełnego fine tuningu.

Jeśli nie ma jasnej preferencji, rozsądne podejście to:

1. przetestować 1–2 gotowe modele przez API (bez fine tuningu),
2. na małym zbiorze porównać je z otwartym modelem wstępnie dostrojonym LoRA,
3. podjąć decyzję na bazie jakości i prognozy kosztów.

Krok 6: Przygotuj pipeline eksperymentów

Chaos w eksperymentach zabija czas. Nawet prosty pipeline robi ogromną różnicę:

• skrypt / notebook do konwersji surowych danych w format treningowy,
• konfiguracje eksperymentów w plikach YAML/JSON (model, hiperparametry, użyty zbiór danych),
• narzędzie do logowania wyników (np. MLflow, Weights & Biases, albo po prostu tabelka z wersjami modeli).

Nawet jeżeli eksperymentów będzie „tylko kilka”, po miesiącu nikt nie pamięta, na jakich dokładnie danych i parametrach powstał „ten lepszy” model.

Krok 7: Pierwsze treningi i szybka ewaluacja

Na starcie lepiej zrobić kilka szybkich, tańszych eksperymentów niż jeden „idealny” wielogodzinny run. Praktyczny schemat:

1. Ustaw umiarkowaną liczbę epok (np. 1–3), mniejszy batch size.
2. Przetrenuj model na pierwszym zbiorze.
3. Oceń:
   • metryki automatyczne (accuracy, F1, BLEU, zależnie od zadania),
   • 20–50 przykładów ręcznie z ekspertem domenowym.

Najcenniejsza na tym etapie jest analiza jakościowa błędów: w jakich kategoriach model się myli, gdzie halucynuje, kiedy odmawia odpowiedzi zbyt często lub zbyt rzadko. To wyznacza plan poprawy danych.

Krok 8: Iteracje na danych zamiast „kręcenia gałkami”

Łatwo wpaść w pułapkę ciągłego zmieniania hiperparametrów, podczas gdy problem leży w danych. Dobry rytm iteracji:

• runda 1–2: drobne zmiany hiperparametrów + identyfikacja brakujących typów przykładów,
• runda 3: rozszerzenie zbioru o trudne przypadki i przykłady, gdzie model się mylił,
• runda 4+: optymalizacja i balans danych (np. niedoreprezentowane kategorie).

Po każdej rundzie dobrze jest:

• odłożyć model do „freezera” (z wersją i opisem),
• zapisać listę obserwacji z testów,
• sprecyzować, co ma być celem następnej iteracji (np. mniej halucynacji, lepsza struktura odpowiedzi).

Krok 9: Walidacja z użytkownikami i scenariusze awaryjne

Najczęściej zadawane pytania (FAQ)

Kiedy fine tuning LLM naprawdę ma sens, a kiedy to przesada?

Fine tuning ma sens wtedy, gdy model obsługuje dużo powtarzalnych interakcji i od jego zachowania zależą konkretne wskaźniki: czas pracy ludzi, liczba błędów, ryzyko prawne, jakość obsługi klienta. Jeśli model odpowiada setki lub tysiące razy dziennie, każdy procent poprawy jakości szybko przekłada się na pieniądze.

Jest przerostem formy, gdy problem da się rozwiązać dobrym promptem, RAG-iem lub prostym profilem użytkownika. Jeśli narzędzie ma używać mały zespół, scenariusze nie są ustandaryzowane, a nie da się jasno policzyć zwrotu z inwestycji, dostrajanie zwykle nie zwróci kosztów.

Czym różni się fine tuning LLM od samego prompt engineeringu?

Prompt engineering to pisanie lepszych instrukcji i przykładów, bez zmiany parametrów modelu. Zmieniasz „co mówisz do modelu”, ale nie „co ma w środku”. To wystarcza, gdy chodzi o ton, format odpowiedzi, język czy kilka prostych zasad zachowania.

Fine tuning to dodatkowe trenowanie modelu na Twoich danych. Uczysz go konkretnego nawyku reagowania: specyficznej struktury, języka branżowego, logiki procesów, większej ostrożności prawnej. Stosuje się go, gdy mimo dopracowanego promptu odpowiedzi są niestabilne lub zbyt ogólne.

Kiedy wybrać RAG, a kiedy fine tuning modelu LLM?

RAG wybierz, gdy problemem jest brak aktualnej wiedzy: nowe produkty, częste zmiany regulaminów, rozrastająca się dokumentacja. Wtedy lepiej podpiąć wektorową bazę wiedzy i przekazywać modelowi odpowiednie dokumenty jako kontekst. Aktualizujesz pliki, nie model.

Fine tuning jest lepszy, gdy chodzi o sposób reakcji, a nie o nowe fakty. Przykład: model ma zawsze pisać w stylu Twojej marki, używać konkretnego szablonu oferty, nie obiecywać nierealnych rzeczy klientowi. To zmiana nawyków, nie tylko dołożenie wiedzy domenowej.

Jakie typowe zadania najbardziej zyskują na fine tuningu LLM?

Największe efekty widać tam, gdzie zadanie jest powtarzalne i dobrze zdefiniowane. Typowe przykłady:

• support i helpdesk – odpowiedzi na podstawie historii ticketów i poprawek agentów,
• dokumentacja techniczna – odpowiedzi w dokładnie takim stylu, jak wewnętrzna knowledge base,
• generowanie kodu – dopasowanie do konwencji, wzorców i stacku technologicznego firmy,
• analiza tekstu – klasyfikacja zgłoszeń, tagowanie maili, ekstrakcja pól z umów i faktur.

W tych przypadkach różnica między modelem bazowym a dostrojonym często oznacza dziesiątki godzin pracy mniej dla zespołu w skali miesiąca.

Jak oszacować, czy fine tuning LLM będzie opłacalny biznesowo?

Najprościej policzyć: ile interakcji miesięcznie obsłuży model oraz ile czasu oszczędzi pojedyncza, lepsza odpowiedź. Jeśli jedna poprawna odpowiedź skraca pracę agenta o 1–2 minuty, a takich odpowiedzi są tysiące, łatwo przekuć to na roboczogodziny i koszt.

Drugi krok to określenie, jaki cel ma projekt: mniej eskalacji do drugiej linii, mniej błędów merytorycznych, krótszy czas obsługi zgłoszenia, niższe ryzyko prawne. Jeśli nie da się tego zapisać jako oszczędności, wzrostu przychodu albo spadku ryzyka, fine tuning zwykle jest zbyt drogi względem efektu.

Czy zawsze trzeba trenować własny model, żeby mieć „firmowego” asystenta?

Nie. W wielu przypadkach wystarcza kombinacja: dopracowana instrukcja systemowa, porządny prompt, RAG z bazą wiedzy i profile użytkowników. Taki zestaw pozwala stworzyć asystenta, który zna produkty, działa na aktualnych dokumentach i pamięta preferencje użytkownika, bez trenowania nowego modelu.

Fine tuning ma sens dopiero wtedy, gdy mimo tych technik model wciąż nie zachowuje się wystarczająco stabilnie lub musi działać „poprawnie z pudełka”, bez polegania na tym, że użytkownik poda idealny prompt.

Ile danych potrzeba, żeby sensownie dostroić model LLM?

To zależy od typu zadania, ale w praktyce liczy się jakość, spójność i dobre etykiety. Dla prostych zadań klasyfikacji czy ekstrakcji pól wystarczą setki lub kilka tysięcy dobrze oznaczonych przykładów. W generowaniu dłuższych treści (np. odpowiedzi supportowych, ofert) im więcej poprawnych, reprezentatywnych konwersacji i dokumentów, tym lepiej.

Dobrym punktem startu jest zebranie materiału, na którym już dziś pracuje zespół: realne maile do klientów, poprawione odpowiedzi agentów, istniejące szablony pism i raportów. Z tego można zbudować pierwszy, sensowny dataset do dostrajania.

Kluczowe Wnioski

• Fine tuning ma sens tylko wtedy, gdy da się go powiązać z twardymi efektami biznesowymi: oszczędnością czasu pracy, wyższą jakością odpowiedzi lub niższym ryzykiem (np. mniej eskalacji, mniej błędów prawnych).
• Model dostrojony to „przeszkolony pracownik”: zna żargon firmy, procesy, ograniczenia prawne i produktowe, trzyma konkretny format odpowiedzi i styl komunikacji, zamiast działać jak ogólny „chatbot z internetu”.
• Zanim ktoś zainwestuje w fine tuning, powinien wycisnąć maksimum z prompt engineeringu: dobra instrukcja systemowa, przykłady (few-shot), precyzyjny format outputu – to często rozwiązuje 70–80% problemów bez trenowania modeli.
• Fine tuning jest potrzebny głównie tam, gdzie wymagana jest bardzo wysoka spójność zachowania: stabilna jakość odpowiedzi mimo słabszych promptów, powtarzalne schematy reakcji (oferty, pisma, maile do klientów), „automatycznie poprawne” zachowanie bez ręcznej kontroli.
• Najbardziej opłacalne zastosowania to m.in. support/helpdesk, dokumentacja techniczna, generowanie kodu pod konwencje firmy oraz analityka tekstu (klasyfikacja, tagowanie, ekstrakcja danych) – tu różnica między modelem bazowym a dostrojonym przekłada się bezpośrednio na godziny pracy zespołu.
• RAG i tool calling często są lepszym (i tańszym) wyborem, gdy problemem jest brak aktualnej wiedzy domenowej: zamiast „uczyć” model nowych produktów i procedur, podaje się mu świeże dokumenty i narzędzia, a sam fine tuning zostawia na zmianę stylu i nawyków odpowiedzi.