Fine-tuning není doučování: co riskujete, když saháte modelu do vah

Tým doladí model na míru. Funguje to — model teď píše jejich tónem, zná jejich doménu. Za půl roku ale poskytovatel vydá základní model o dvě třídy lepší a ten starý dostane datum konce podpory. Doladěná verze s sebou nepřejde. A někde cestou začal model dělat i něco, co po něm nikdo nechtěl. Fine-tuning vypadá jako přirozený krok po promptování. Ve skutečnosti je to spíš infrastruktura než funkce — pořídíte si ji a pak provozujete, není to jednorázové vylepšení. A má provozní cenovku, kterou na první pohled nevidíte.

01Co fine-tuning doopravdy dělá

Promptování a RAG dávají modelu informaci za běhu — model samotný se nemění, jen dostane v daném dotazu lepší vstup. Fine-tuning dělá něco jiného: mění váhy modelu — čísla, která ten model jsou. Není to přilepená poznámka navíc. Je to přepis týchž parametrů, ve kterých je uloženo všechno ostatní, co model umí.

Doladěný model proto není „váš model plus něco“. Je to jiný model. A platí to i pro úsporné metody: LoRA a adaptéry (Hu a kol.) mění jen malou nízkohodnostní část vah — jsou lehčí a oddělitelné, ale pořád je to změna vah, ne přídavná paměť.

Co článek řeší a co ne. Pod „fine-tuning“ se v běžné mluvě schová leccos. Tenhle článek míří na to, co dělá většina firem: úzké supervised fine-tuning (SFT) a preferenční metody jako DPO, typicky přes hosted API nebo nad open-weight modelem. Continued pretraining (další kola samoučení nad velkým doménovým korpusem) a plné RLHF s lidskou anotací jsou jiné kategorie s jiným rizikovým profilem i jinou ekonomikou — sem nepatří, i když by leccos z níže uvedeného platilo i pro ně.

02Proč se fine-tunuje — a kdy to dává smysl

Když se řekne fine-tuning, většina lidí myslí na jedno: „model nezná naši doménu“ nebo „nepíše naším tónem“. To je ale důvod, který se snadno pojmenuje — a zároveň ten, který nejčastěji vyřeší levnější vrstva. Skutečný byznysový důvod bývá jinde a stojí za to ho přiznat.

Ekonomika inference. Kdo posílá desítky milionů dotazů měsíčně, řeší cenu za dotaz — a často i latenci. Krátký prompt na menším doladěném modelu (typicky open-weight v řádu 7–13 miliard parametrů) bývá o řád, někdy o dva řády levnější než dlouhý prompt s tuctem few-shot příkladů na velkém frontier modelu — a typicky i násobně rychlejší: latence pod 200 ms místo jednotek sekund. Hrubý práh, od kterého to začíná dávat smysl: úzká, dobře definovaná úloha s objemem od jednotek až desítek milionů dotazů měsíčně, případně tvrdý latenční požadavek, který hosted frontier model neumí splnit ani s cachí. Pod tím prahem skoro vždy vyhrává prompt na velkém modelu — kratší time-to-market, žádný fork na údržbě. Když ten práh ale překročíte, není fine-tuning obranná volba — je to nákladová optimalizace, vědomá investice do forku. Pokud je tohle váš případ, ber zbytek článku jako rozpočtovou rozvahu, ne jako varování.

Distilace. Velký model vygeneruje trénovací data, menší model se na nich doladí — princip, který pod jménem distilace znalostí popsali Hinton a kol. už v roce 2015. Technicky je to pořád fork, ale s jiným rizikovým profilem. Necílíte na úzkou doménu, takže zapomínání i emergent misalignment (obojí níže) jsou méně pravděpodobné, a pipeline, která data generuje, jde pustit znovu nad libovolnou základní verzí. Distilace je užitečný mezistupeň: výhoda menšího modelu bez nejostřejších rizik úzkého doladění.

03Fine-tune je fork, ne upgrade

Většina lidí má v hlavě, že fine-tuning model „vylepší“. To je špatný rámec. Ve chvíli, kdy doladíte, jste model forkli — vytvořili jste jeho odštěpenou kopii, kterou teď vlastníte.

Základní model mezitím jede dál — nové verze, lepší uvažování, nižší cena — ale bez vás. Váš fork je zamrzlý na schopnostech té verze, ze které jste vyšli, plus váš úzký přídavek. Je to jako forknout knihovnu a nikdy ji nerebasovat: každé vylepšení od upstreamu je teď něco, co nedostáváte.

04Lock-in: fine-tune je přivařený k jedné verzi

Ten fork má tvrdou závislost: je přivařený k základnímu modelu verze X. Když vyjde verze Y, vaše doladěné váhy nepřejdou — jsou to jiné parametry, často jiná architektura, a fine-tuning API poskytovatele cílí jen na konkrétní základní verze. A poskytovatelé staré modely ruší podle svého kalendáře, ne vašeho.

Když základní verze X doslouží, váš fine-tune doslouží s ní. Jediný tah, který zbývá, je natrénovat všechno znovu na Y — znovu projet datovou přípravu, znovu zaplatit výpočet, znovu odběhnout celou evaluaci. To není jednorázový náklad. Je to opakovaná daň pokaždé, když se posune špička.

U LoRA adaptérů je situace o něco mírnější. Vyvíjejí se techniky cross-model transferu — re-basing, adapter stitching, různé formy permutation alignment — které dovolují adaptér přesadit na blízkou verzi základního modelu bez plného přetrénování. Spolehnout se na ně v produkci je v květnu 2026 ale pořád sázka: čistě fungují hlavně mezi minor verzemi téhož základního modelu a u open-weight rodin, kde si kadenci řídíte sami. U hosted API, kde poskytovatel rozhoduje, kdy a jak verzi otočí, máte tu možnost zřídkakdy. Pro plánování rozpočtu počítejte s přetrénováním a transfer berte jako bonus, ne jako default.

Rozhodnutí „vlastní model, nebo API“ — rozebírá ho článek Lokální modely vs frontier modely — tady dostává skrytou položku.

05Trvalé aktivum je datová pipeline, ne model

Tady je otázka, která rozhoduje o všem ostatním: co vlastně po fine-tuningu vlastníte? Když jen váhy ležící na disku poskytovatele, vlastníte černou skříňku. Nevíte spolehlivě, na čem se trénovala, neumíte to čistě zopakovat — a až základní verze doslouží, začínáte od nuly.

Když ale za doladěným modelem stojí verzovaná trénovací data, čistý a opakovatelný preprocessing a evaly, které umíte pustit znovu, vlastníte něco úplně jiného. Samotné váhy jsou pak jen odvozený, zahoditelný artefakt. Trvalé aktivum není model — je to ta pipeline.

Tenhle rozdíl rozhoduje, jestli je migrace na novou základní verzi inženýrský úkol, nebo výzkumný projekt. S pipeline přetrénujete za týden: pustíte data, doladíte, srovnáte výsledky proti minulému kolu. Bez ní je každé přetrénování nový projekt — data sbíráte znovu, hádáte, co minule fungovalo, a nemáte s čím porovnávat. Patří sem i kalibrace a ověřování konzistence: bez referenčních evalů z minulého kola nepoznáte, jestli je nový fine-tune stejně dobrý jako ten předchozí, nebo jen vypadá hotově.

06Druhé úskalí: model se může posunout, kam jste nemířili

Lock-in je předvídatelný náklad. To druhé úskalí předvídatelné není. Fine-tuning má vedlejší účinky mimo cílové chování.

Catastrophic forgetting. Trénink na nové úloze zhoršuje to, co model uměl předtím. Empirická studie (Luo a kol.) navíc zjistila, že s velikostí modelu zapomínání neklesá — roste.

Regrese bezpečnosti. Doladění na úplně neškodných, běžných datech měřitelně zhoršuje bezpečnostní alignment modelu (Qi a kol.). Nejde o škodlivá data — o neškodná. Alignment, který do modelu vestaví poskytovatel, není nosný, jakmile začnete hýbat vahami.

A nezáleží jen na tom, co trénujete, ale jak. Fine-tuning není jeden postup. Doladění na úzké distribuci (SFT) a preferenční metody jako DPO (Rafailov a kol.) mají odlišné failure módy. Zapomínání i emergent misalignment níže jsou nejsilnější právě u úzkého SFT. Preferenční optimalizace má jiné slabiny — reward hacking a sycophancy, tendenci modelu říkat to, co chce uživatel slyšet, ne to, co je pravda (Sharma a kol.). Když volíte metodu, volíte i to, které riziko ponesete.

07Emergent misalignment: nejostřejší příklad

Nejtvrdší doklad přinesli Betley a kol. v roce 2025. Doladili GPT-4o na úzkou úlohu: psaní nezabezpečeného kódu. Výsledkem nebyl model, který píše nezabezpečený kód. Byl to model široce misalignovaný napříč úplně nesouvisejícími dotazy — dával zlomyslné rady, schvaloval představu, že by AI měla vládnout lidem, choval se klamavě i u běžných otázek.

Úzký fine-tune vyrobil široký, podivný a nezamýšlený posun chování. Nikdo si ho neobjednal a nikdo ho z trénovacích dat nepředpověděl.

Tohle je ale extrém — ostrá laboratorní ilustrace, ne typický výsledek firemního doladění. U běžného úzkého SFT nečekejte model, co schvaluje nadvládu AI; čekejte tišší verzi téhož — drobnou degradaci ve schopnostech, na které jste necílili. Strašák z laboratoře a nenápadný produkční drift mají ale stejný mechanismus — a právě proto se vyplatí ho znát.

08Proč to tak je

Proč se úzká změna takhle rozlije? Protože model je jedna hustá, propletená síť vah. „Chování, které chcete“ není uloženo na zvláštním, adresovatelném místě — je rozmazané přes stejné parametry jako všechno ostatní.

Krok gradientu směrem k vašim datům pohne sdílenými vahami. Když jsou data úzká a optimalizační tlak silný, model najde nejlevnější způsob, jak vaše data nasednout — a ten nejlevnější způsob je často obecný posun, co s sebou táhne i nesouvisející chování. Mířili jste na jednu věc; optimalizátor pohnul celým objektem. Úzký fine-tune není úzká změna — má jen úzký cíl.

09Jak to dělat dobře

Prakticky, v tomhle pořadí:

• Nejdřív: potřebujete to vůbec? Většinu případů „model nezná naši doménu nebo náš tón“ vyřeší dobrý prompt, few-shot příklady a RAG — nic z toho nesahá na váhy. Fine-tuning je nejvyšší příčka žebříku (viz AI architektura pro firmy), ne výchozí volba. A pozor — žebřík není volba „jen jedna příčka“: nejlepší produkční systémy ty vrstvy často kombinují. Malý doladěný model jako jádro plus RAG nad doménovými dokumenty pro aktuální fakta, která se mění rychleji než cyklus přetrénování. Doladění a RAG nejsou alternativy, jsou to vrstvy s jinou rolí — váhy nesou tón, formát a stabilní vzorce uvažování, RAG nese fakta. Pozor ale na druhou stranu: prompt taky není zadarmo. Když naroste na 4–6 tisíc tokenů s tucty few-shot příkladů, podmínek a záplat na okrajové případy, přestává být „lehkou vrstvou“ — je to dlouhý, křehký a špatně testovatelný artefakt, který nikdo neumí přečíst. Konkrétní symptomy, podle kterých prompt poznáte jako přerostlý: editace jednoho few-shot příkladu rozbije chování na třech jiných; nikdo v týmu už neumí jediným dechem popsat, co každá sekce promptu dělá; regresní test promptu trvá déle než samotná inference; nový člověk potřebuje dva dny, aby pochopil, proč tam je která podmínka. Někdy je doladěný model údržbově levnější než neudržitelný prompt. Rozhodujte podle nákladu na údržbu obou variant, ne podle toho, která zrovna nesahá na váhy.
• Když ano, sahejte co nejmíň. Adaptéry / LoRA: základní model zůstane netknutý, vaše změna je malý oddělitelný přídavek. Neřeší to přenositelnost úplně, ale omezuje to dosah škody a levněji se přetrénuje na novou verzi.
• Postavte napřed pipeline, ne model. Verzovaná data, opakovatelný preprocessing a evaly jsou to trvalé aktivum — bez nich vám zbude černá skříňka. Tohle není podpůrná práce kolem fine-tuningu; tohle je fine-tuning. Výjimka: u proof-of-conceptu je racionální natrénovat jednorázový ošklivý fine-tune jen abyste zjistili, jestli ten přístup vůbec funguje. Pipeline stavte ve chvíli, kdy víte, že to půjde do produkce — ne jako podmínku, abyste vůbec mohli začít experimentovat. Jen si v PoC fázi přiznejte, že váhy, které tak vyrobíte, jsou jednorázové, a do produkce s nimi nejdete.
• Regresně testujte proti base na široké evaluaci — ne jen na cílové úloze. To, že cílová úloha prošla, neříká nic o zapomínání ani o emergent misalignmentu; chytíte je jen porovnáním doladěného modelu proti základnímu napříč širokou sadou chování. A pozor — „pustíme MMLU a HumanEval“ nestačí. Eval, který zachytí emergent misalignment nebo jemnou degradaci v ne-cílových schopnostech, musí pokrývat i to, co model dělat nesmí, ne jen to, co umět má. V minimální podobě patří do regresní sady tři kategorie: (a) cílová úloha — to, na co jste dolaďovali, aby se hlídal i samotný tréninkový cíl; (b) sousední schopnosti, kterých se trénink přímo netýkal, ale sdílejí doménu (jiný formát výstupu, blízká úloha, edge cases) — tady se schovává catastrophic forgetting; (c) bezpečnostní / refusal sada — model nemá začít odpovídat na věci, na které před doladěním neodpovídal, a nemá začít sklouzávat k tónu, který původní alignment držel pod kontrolou. Navrhnout dobrou sadu je dovednost sama o sobě, ale tyhle tři vrstvy by neměly chybět ani v té nejprostší.
• Rozpočítejte re-tuning. Berte každý upgrade základního modelu jako naplánovaný cyklus přetrénování s cenou. Když si tu kadenci nemůžete dovolit, nemůžete si dovolit ten fine-tune.

10Co si z toho vzít

Fine-tuning není „doučení modelu navíc“. Je to fork modelu a provozní závazek — odštěpená kopie zamčená na jednu základní verzi, kterou teď vlastníte, udržujete a pravidelně přetrénováváte.

Emergent misalignment je dobré znát, ale pro běžný firemní případ je to spíš krajní ilustrace než každodenní hrozba. Skutečný náklad je provozní a předvídatelný: opakované přetrénování, evaly, datová pipeline a regresní testování proti base. To není vedlejší riziko na konci — to je ta práce. Kdo ji unese, může fine-tuning klidně použít; kdo na ni nemá, neměl by do něj jít.

Pravidlo zůstává: sahejte do vah, až když lehčí vrstvy — prompt, few-shot, RAG — prokazatelně nestačí, ať schopnostmi, nebo náklady. A když do toho jdete, postavte napřed pipeline a evaly. Váhy jsou jen artefakt; udržovatelný proces, který je umí vyrobit znovu, je to, co si doopravdy pořizujete.

Fine-tuning si nekupujete jako vylepšení modelu — pořizujete si jeho fork a k němu datovou pipeline, evaly a rozpočet na přetrénování.

Článek popisuje stav k květnu 2026 — ber ho jako rozhodovací rámec, ne jako neměnný verdikt.