Fine-tuning, retrieval, nebo prompt? Rozhoduje ekonomika

„Máme fine-tunovat?“ se pokládá, jako by šlo o otázku o modelu. Je to otázka o rozpočtu, s tvarem, na který žádný benchmark neodpoví: co se platí jednou, co se platí za otázku a co se platí znovu pokaždé, když se svět posune.

Ty tři cesty také nejsou tři způsoby, jak dělat jednu věc, a dodavatelé to říkají jasněji než většina blogových článků. Vlastní tabulka OpenAI toho, k čemu je supervised fine-tuning nejlepší, uvádí čtyři použití: klasifikaci, nuancovaný překlad, generování obsahu ve specifickém formátu a opravu selhání v následování instrukcí.¹ Nic z toho není „naučit model něco, co neví“. Shrnutí přínosu říká, že „můžete používat kratší prompty s méně příklady a kontextovými daty, což ve škále šetří náklady na tokeny a může snížit latenci“ — argument o faktuře od firmy, která tu funkci prodává.

Takže:

• Fine-tuning učí formu a chování. Tón, formát, tvar odpovědi, hranici, kterou umíte předvést, ale ne popsat. Nejsilnější publikovanou verzí je hypotéza Superficial Alignment z LIMA: znalosti pocházejí z pretrainingu, alignment většinou učí, v jaké sub-distribuci formátů má model mluvit — proto tam stačilo tisíc kurátorovaných příkladů.²
• Retrieval dodává fakta, která se mění. Je jedinou z těch tří možností, kde se úprava vaší dokumentace dostane do odpovědi bez zásahu do modelu.
• Prompting pokrývá většinu skutečných případů a je poctivý baseline. In-context learning je výchozí přístup od Language Models are Few-Shot Learners: úloha je předvedena uvnitř promptu a žádná váha se nepohne.³

Dva měřené články zavírají dveře chybě uprostřed. Ovadia a kolegové porovnali vkládání znalostí pomocí unsupervised fine-tuning proti vkládání pomocí retrieval a retrieval konzistentně vyhrál, včetně faktů, které base model už viděl v pretrainingu.⁴ Gekhman a kolegové změřili škodu: příklady zavádějící nové znalosti se fitují pomalu, a když je model konečně fituje, jeho míra halucinací u jiných otázek roste.⁵ Učit fakta pomocí fine-tuning nejenže selhává; zhoršuje odpovědi, na kterých jste netrénovali.

Tahle polovina je vyřešená. Ekonomická polovina ne, a tvoří zbytek kapitoly.

Jeden případ, spuštěný třemi způsoby: technická podpora nad vaší vlastní dokumentací, která se mění každý týden.

Korpus je skutečný a leží na tomto disku: 23 Markdown dokumentů, které jeden fungující softwarový repozitář drží jako interní dokumentaci — build guide, pravidla značky, translation brief, deset servisních manuálů, poznámky k výkonu a bezpečnosti. Měřeno pomocí o200k_base, encodingu z kapitoly 7:

documents                              23
characters                        159,223
words                              22,194
tokens (o200k_base)                42,921
tokens with per-file headers       43,158

Třiačtyřicet tisíc tokenů je pro toto rozhodnutí pohodlná velikost: vejde se do každého moderního okna, takže všechny tři cesty jsou skutečně dostupné. U deseti milionů je rozhodnutí učiněno za vás, a je to retrieval.

Teď práce, kterou odvádí slovo „týdně“. O obrátkovosti dokumentace se obvykle tvrdí; tady je spočítaná z historie verzí toho repozitáře:

Dokumenty se hýbou zhruba každý druhý týden. Uživatelsky viditelné řetězce — tedy to, na co se support desk skutečně ptají — se hýbaly každý týden své existence, asi dvaceti commity týdně. Ať zvolíme jakoukoli cestu, musí to přežít, a „jak často se mění věc, na které jste trénovali?“ se ukáže jako číslo ve vašem vlastním repozitáři, ne názor.

Proti tomuto korpusu bylo napsáno dvacet realistických otázek podpory, jedna na téma, a každé číslo níže je vypočteno nad těmito dvaceti.

Nejjednodušší věc, která funguje: dát celý korpus do system promptu, otázku na konec a nechat model, ať si ji najde.

system instructions                       140 tokens
the 23 documents                       43,158 tokens
the question (median of 20 measured)       13 tokens
the answer (the one assumption)           150 tokens

Každé číslo tam bylo spočítáno kromě posledního: 150 output tokenů je předpoklad, zvolený uvnitř rozsahu odpovědí asistenta, které kapitola 16 účtovala. Je to jediné číslo zde, které nebylo spuštěno, používá se identicky pro všechny tři cesty a sekce o break-even přesně ukazuje, jak moc se závěr pohne, když jej změníte.

Při sazbách přečtených ze stránky poskytovatele 7. září 2026 — $1.50 za milion input tokenů, $9.00 za milion output⁶ — je to $0.066317 za otázku. Platíte za opětovné přečtení třiačtyřiceti tisíc tokenů, abyste odpověděli třinácti.

Oprava z kapitoly 16 platí přímo: korpus je stabilní a je na začátku, takže je to dokonalý cache prefix, a jeho zpětné čtení stojí desetinu — $0.007864 za otázku, snížení o 88 %. Platí i varování z kapitoly 16, ve formě, kterou tato kapitola označila, ale nenacenila. Tento poskytovatel neúčtuje příplatek za zápis; účtuje nájem. Explicitní cache stojí $0.000001 za uložený token za hodinu,⁶ takže udržovat 43,298 tokenů teplých stojí

ať se někdo ptá, nebo ne. To je $189.78 za šest měsíců, za prázdnou místnost. Vydělte nájem úsporou na otázku a podmínka vyjde na jeden řádek: caching tohoto korpusu se zaplatí nad 0.74 otázky za hodinu — 546 měsíčně, když se započítá i týdenní přestavba cache. Pod tím funkce, kterou jste zapnuli, abyste šetřili peníze, peníze prodělává.

Stejná cesta, stejný kód, jeden flag, pětkrát vyšší účet. Kapitola 16 našla verzi tohoto problému způsobenou timestampem na špatném místě; tady není špatně nic kromě návštěvnosti. Cache je sázka na objem a u tohoto poskytovatele ji uzavíráte po hodinách.

Retriever z kapitoly 19 beze změny: rozřezat na hranicích sekcí s kontextovou hlavičkou, indexovat, dát do promptu čtyři nejlepší výňatky. Měřeno nad dvaceti otázkami:

chunks produced from the corpus              330
mean tokens of a chunk's own text          124.9
mean tokens of the four retrieved extracts   884
prompt per question (140 + 884 + 13)       1,037
one-off embedding of every chunk        46,823 tokens

Dvaačtyřicetkrát méně prompt tokenů než cesta jedna, za $0.002906 za otázku. Index stojí $0.0070 na sestavení při $0.15 za milion embedding tokenů⁶ — méně než tři otázky — a stejných $0.0070 na přestavbu od nuly pokaždé, když se dokumentace změní. Přestavět celý index každý týden po šest měsíců stojí osmnáct centů.

U jedné věci stojí za to se zastavit. Retrieval ničí prompt caching. Stabilní prefix je teď 140tokenová system instrukce; od tokenu 141 se prompt při každém volání liší, protože výňatky se vybírají podle otázky. A 140 tokenů je pod každým minimem cache, které kapitola 16 citovala. Cesta dvě tedy nejde cachovat vůbec, což zní špatně a není: necachovat 1,037 tokenů je levnější než cachovat 43,298.

To je obecné pravidlo, které stojí za zapamatování: dvě velké techniky šetření tokenů se na stejném obsahu vzájemně vylučují a vyhrává ta, která odstraní více tokenů. Retrieval jich odstraní 97.6 %.

Natrénujte na dvou stech příkladech v domácím stylu a pak pokládejte otázky bez jakékoli připojené dokumentace.

training examples                            200
training tokens                           24,389
epochs                                         3
prompt per question (15 + 13)                 28

Trénování stojí 24,389 × 3 × $10.00 za milion = $0.7317. To je celá konstrukční cena, méně než šálek kávy, což je přesně důvod, proč ji tolik týmů zaplatí dřív, než ověří, zda to pomáhá.

Teď past, a právě kvůli ní tato kapitola existuje. Fine-tuned model nestojí na provoz stejně jako jeho base model. Cenová stránka to říká jednou větou: „for model inference starting from Gemini 3, tuned model endpoint prediction price will be 1.5 times of the base model.“⁶ Ne trénování. Inference, na každém tokenu, po celou dobu života modelu.

Dejme to tedy do vzorce. Nechť $p_i$ a $p_o$ jsou základní input a output ceny, $m$ tuned násobek, $L_R$ délka promptu cesty, kterou nahrazujete, $L_F$ délka promptu po fine-tuning a $O$ délka odpovědi. Fine-tuning je levnější za otázku pouze tehdy, když

První člen je zřejmý: váš nový krátký prompt s přirážkou. Druhý ne, a právě tam mizí peníze — příplatek za odpověď, který nemá nic společného s vaším promptem a který trénování nemůže zkrátit. S naměřenými čísly — $m = 1.5$, $L_F = 28$, $O = 150$, $p_o/p_i = 6$ — je práh

answer   50 tokens -> the prompt it replaces must exceed   192 tokens
answer  150 tokens -> the prompt it replaces must exceed   492 tokens
answer  400 tokens -> the prompt it replaces must exceed 1,242 tokens
answer 1000 tokens -> the prompt it replaces must exceed 3,042 tokens

Při naměřené délce odpovědi 492 tokenů — z toho 450 je příplatek za odpověď, ne prompt. Nahrazovat kratší prompt než tohle je dražší za otázku, navždy, při jakémkoli objemu; a práh roste lineárně s tím, kolik váš asistent říká, takže ten, který píše dlouhé odpovědi, se pomocí fine-tuning nikdy nedostane k levnějšímu tokenu, ať smaže z promptu cokoli.

Stejná věc z druhého konce je věta k zapamatování. Z $0.002088 za otázku u fine-tuned cesty je 97.0 % odpověď. Fine-tuning optimalizuje zbývající tři procenta.

Čtyři čísla popisují každou z těchto cest: co platíte jednou, co platíte, když se dokumentace změní, co platíte hodinově bez ohledu na provoz a co platíte za otázku. To rozšiřuje computeCost z kapitoly 16, aniž by ji upravovalo.

import { computeCost, type Pricing, type Usage } from "./cost";   // Chapter 16

export interface Route {
  name: string;
  setupUSD: number;            // paid once, before the first question
  perRefreshUSD: number;       // paid every time the documentation changes
  standingUSDPerHour: number;  // paid per hour whatever the traffic
  pricing: Pricing;
  usage: Usage;                // one question and its answer
}

export const perQueryUSD = (r: Route) => computeCost(r.pricing, r.usage);

const HOURS_PER_MONTH = (24 * 365.25) / 12;

export function totalUSD(
  r: Route, months: number, queriesPerMonth: number, refreshesPerMonth: number,
) {
  return r.setupUSD
       + months * refreshesPerMonth * r.perRefreshUSD
       + months * HOURS_PER_MONTH * r.standingUSDPerHour
       + months * queriesPerMonth * perQueryUSD(r);
}

/** Monthly volume at which `b` overtakes `a`. null = it never does. */
export function crossover(
  a: Route, b: Route, months: number, refreshesPerMonth: number,
): number | null {
  const fixed = (r: Route) =>
      r.setupUSD
    + months * refreshesPerMonth * r.perRefreshUSD
    + months * HOURS_PER_MONTH * r.standingUSDPerHour;
  const dFixed = fixed(b) - fixed(a);                     // b's extra fixed cost
  const dVar = perQueryUSD(a) - perQueryUSD(b);           // b's per-question saving
  if (dVar <= 0) return null;                             // b is never cheaper
  return Math.max(0, dFixed / dVar / months);
}

Tuned model není jiný ceník, je to tentýž vynásobený:

const TUNED_MULTIPLIER = 1.5;   // read from the provider's pricing page, 2026-09-07

const scale = (p: Pricing, k: number): Pricing => ({
  input: p.input.map(t => ({ ...t, price: t.price * k })),
  cachedInput: p.cachedInput!.map(t => ({ ...t, price: t.price * k })),
  output: p.output.map(t => ({ ...t, price: t.price * k })),   
});

Ten jeden zvýrazněný řádek je celý argument předchozí sekce zapsaný jako kód: násobek dopadne i na output.

Šest měsíců, s týdenně obnovovanou dokumentací:

A průsečíky, tedy čtyři čísla, která rozpočet skutečně potřebuje:

retrieval -> fine-tune, documentation never changes:     148 questions / month
retrieval -> fine-tune, documentation refreshed weekly: 3,989 questions / month
prompt (no cache) -> retrieval:                            1 question / month
prompt (no cache) -> prompt (cached):                    546 questions / month

Čtěte první dvě dohromady, protože to je pointa kapitoly. Stacionární korpus způsobí, že se fine-tuning zaplatí ve sto padesáti otázkách; korpus, který se mění týdně, posune stejný průsečík sedmadvacetkrát, a na modelu se nezměnilo nic — jen to, jak často za něj platíte znovu. Konstrukční cena je poznámka pod čarou; rozhodnutí je cena údržby.

Pokud teď dojdete k závěru, že vytížený support desk by měl fine-tunovat, aritmetika s vámi souhlasí. Pořád je to špatně, a další sekce vysvětluje proč.

Nákladový list má jeden sloupec, který neumí spočítat, takže tato sekce fine-tune skutečně spustí: lokálně, na malém open modelu, s adaptérem napsaným ručně místo staženým z knihovny. Kapitola 11 postavila LoRA; tady je, na q_proj a v_proj všech 24 vrstev Qwen2.5-0.5B-Instruct s rank 8:

class LoRALinear(nn.Module):
    def __init__(self, base: nn.Linear, r=8, alpha=16):
        super().__init__(); self.base = base
        for p in self.base.parameters():
            p.requires_grad = False              # the model is frozen  
        self.A = nn.Parameter(torch.zeros(r, base.in_features))
        nn.init.normal_(self.A, std=1 / r)
        self.B = nn.Parameter(torch.zeros(base.out_features, r))
        self.s = alpha / r
        self.on = True                           # so the same run can compare both

    def forward(self, x):
        y = self.base(x)
        return y + (x @ self.A.T @ self.B.T) * self.s if self.on else y

Dvě stě trénovacích příkladů pochází mechanicky z korpusu, takže se reprodukují: otázka je nadpis sekce převedený na otázku, odpověď je vlastní text této sekce v pevném domácím stylu — jeden řádek začínající Short answer:, jeden řádek začínající Source: s cestou k souboru. Formát je forma, která se učí; cesta je fakt. Potom dvě čísla nad dvaceti held-out otázkami: vyjde odpověď v domácím stylu a jmenuje soubor, který na otázku skutečně odpovídá?

Tabulku zpřehledňují dva baselines a oba vycházejí z důrazu kapitoly 4, ne z dodatečného nápadu. Deset z dvaceti správných odpovědí je stejný soubor, takže model, který otázku ignoruje a vždy odpoví CLAUDE.md, získá skóre 10/20. A retriever má vlastní strop: napříč těmito dvaceti otázkami jeho čtyři výňatky obsahují správný soubor 14krát a řadí jej první 7krát, takže 14/20 je maximum, kterého může jakýkoli reader při jeho použití dosáhnout.

LoRA modules 48   trainable parameters 540,672 (0.109 % of the model)
400 steps, 2 epochs, 0.76 s/step on 16 CPU threads, 304 s in total
mean loss over the first 50 steps 3.7363 -> over the last 50 steps 2.4197

                                        house style   correct source
always answer the most common file             --          10 / 20
the retriever's own ceiling                    --          14 / 20
base model, closed book                    0 / 20           0 / 20
fine-tuned, closed book                   19 / 20           8 / 20
base model, four retrieved extracts       13 / 20           2 / 20
fine-tuned, four retrieved extracts        1 / 20           1 / 20

Forma se naučila, úplně a rychle. Z nuly na devatenáct z dvaceti, z adaptéru s 540,672 parametry — 0.109 % modelu — za pět minut trénování na procesoru bez grafické karty v dohledu.

Fakta ne. Osm z dvaceti není odlišitelné od deseti, které dostanete, když otázku úplně ignorujete, a interval z kapitoly 4 na dvaceti vzorcích to říká nahlas. Ty cesty k souborům byly v trénovacích datech třikrát; ven vyšel návyk končit věrohodně vypadajícím řádkem Source:. Na otázku z úvodu této kapitoly fine-tuned model odpověděl Short answer: 10.x . . . a citoval CLAUDE.md. Správná odpověď, která je v CLAUDE.md, je 18.17.0.

A pak se forma rozbila, což je řádek, který experiment ospravedlňuje. Dejte fine-tuned modelu tisíc tokenů retrieved výňatků — tvar promptu, který nikdy neviděl, protože každý trénovací prompt měl osmadvacet tokenů — a domácí styl se zhroutí z 19/20 na 1/20. Na otázku z úvodu této kapitoly odpoví 18.17.0 — správně a bez jakéhokoli formátu, na který byl trénován. Fine-tuning tedy nenaučil formát; naučil formát podmíněný prompty v trénovací sadě, a první prompt, který vypadal jinak, vzal formát s sebou. Cokoli použijete pro fine-tuning, stane se jedinou vstupní distribucí, ve které je váš model dobrý, a to do tabulky nikdo nepíše.

Poslední poznámka k metrice, mířící přímo na kapitolu 29: „správný zdroj“ hodnotí formu a fakt dohromady, proto oba retrieval řádky vypadají hrozně, i když oba modely odpověděly fakt této otázky správně. Jedno end-to-end číslo schovávalo tři věci — retriever s recall 14/20, 0.5B reader a citační formát — a rozhodnout, co opravit, znamená oddělit je před měřením, ne po něm.

Teď sloupec, který za vás vyplní dodavatelé. Fine-tuned model není aktivum, které vlastníte; je to pronájem cizího base modelu s vytištěným datem konce. 7. září 2026 nesla fine-tuning sekce cenové stránky OpenAI toto oznámení v plném znění:

OpenAI is winding down the fine-tuning platform. The platform is no longer accessible to new users, but existing users of the fine-tuning platform will be able to create training jobs for the coming months. All fine-tuned models will remain available for inference until their base models are deprecated.⁷

Časová osa je datovaná na den: 7. května 2026 zavřeno organizacím, které nikdy nefine-tunovaly; 2. července 2026 zavřeno těm, které nespustily inference na fine-tuned modelu šedesát dní; 6. ledna 2027 už žádné nové joby.⁸ Stejná stránka plánuje vypnutí samotných fine-tuned modelů — ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano, ft-babbage-002, ft-davinci-002 — na 23. října 2026, každý s recommended replacement base model, což je zdvořilý způsob, jak říct: natrénujte to znovu.

Druhý frontier dodavatel vám pronájem nikdy neprodal. Index dokumentace Anthropic uvádí 699 stránek a ani jedna není o fine-tuning; sekce modelové customizace na cenové stránce Bedrock pokrývají Amazon Nova, Amazon Titan, Cohere, Meta a OpenAI open-weight modely, a žádný Claude.⁹¹⁰ Pokud vaše architektura závisí na fine-tune, jedna ze tří frontier rodin je pro vás prostě nedostupná za jakýkoli rozpočet.

Self-hosting nahrazuje pronájem modelu pronájmem stroje a AWS tuto aritmetiku dělá na vlastní stránce: jedna model unit provisioned throughput pro customizovaný model, závazek na jeden měsíc, je „1 model unit × $21.18 × 24 hours × 31 days = $15,757.92“ měsíčně.¹⁰ Pronajmout kov přímo je levnější a ne zdarma — $3.99 za GPU hodinu on demand pro H100, $1.99 preemptible¹¹ — zhruba $2,900 měsíčně za jednu kartu, která musí běžet, ať se někdo ptá, nebo ne. Celá retrieval cesta při deseti tisících otázkách měsíčně stojí $174.52 za šest měsíců.

Tady si LoRA zaslouží místo jako rozpočtový argument, ne technický. Měřeno na stejném modelu, rank-16 adaptér přes attention a feed-forward vrstvy má 8,798,208 parametrů — 1.781 % modelu, 17.6 MB v bfloat16 — proti 0.988 GB základních vah, a jeho optimiser a gradient state je 140.77 MB tam, kde full fine-tuning potřebuje 7.90 GB, faktor 56. Důsledkem není levnější trénování, ale to, že jeden načtený base model může obsluhovat mnoho adaptérů, což je jediný způsob, jak se pevná cena GPU rozdělí na něco užitečného. Managed training to odráží: $0.48 za milion tokenů low-rank do 16B proti $0.54 full, s minimem $4.00 za job.¹¹ Ten floor je důležitý detail. Při 24,389 tokenech za tři epochy se každé přetrénování na tomto korpusu účtuje jako $4.00 místo $0.04, na které vychází výpočet — $104 minim napříč šestadvaceti týdenními běhy, za devadesát jedna centů aritmetiky.

Dva další sloupce, které se objeví jen na faktuře.

Data residency stojí asi deset procent a dva poskytovatelé se na tom čísle shodují. OpenAI účtuje „a 10 % uplift“ na data-residency endpointy pro modely vydané 5. března 2026 nebo později;⁷ Vertex oceňuje non-global endpointy na $1.65 proti $1.50, stejných deset procent.⁶ Postavte to proti padesáti procentům, která stojí tuned endpoint, a folklór se převrátí: residency je levná a fine-tuning ne — a fine-tuning stejně není soukromá možnost, protože korpus se k poskytovateli dostane tak jako tak, jen jednou při trénování místo jednou při každém volání.

Nejexplicitnější cena, která kdy byla na vaše data nalepena, je na téže stránce, která uvádí jeden fine-tuned model dvakrát: se zapnutým sdílením dat je inference přesně poloviční — $2.00 proti $4.00 input, $8.00 proti $16.00 output.⁷ Nechat poskytovatele ponechat si to, co jste poslali, má hodnotu 50% slevy, což vám říká, jakou hodnotu to má pro něj.

Distillation — trénování vlastního malého modelu na odpovědích velkého — se obvykle nabízí jako cesta z obojího. Naceňte ji a není, protože teacher je systém, který jste se snažili nahradit: vyrobit dvě stě trénovacích příkladů dotázáním retrieval cesty na dvě stě otázek stojí 200 × $0.002906 = $0.58, navrch k $0.73 za trénování na nich. Distillation děláte poté, co retrieval pipeline funguje, aby byla levnější, a zdědí každý fakt, který retriever spletl.

Peníze jsou viditelná polovina. Druhá přichází jako čekání, se stejnou příčinou jako účet: model přečte celý prompt, než řekne slovo. Kapitola 13 měřila prefill proti decode na modelu, na který jste si mohli sáhnout; tady je stejné měření, jeden běh, jeden stroj, proti délce promptu:

Absolutní čísla patří 0.5B modelu na šestnácti CPU vláknech a neříkají nic o hostovaném frontier modelu. Tvar se přenáší přesně: prefill roste s délkou promptu a cena za token se plíživě zvyšuje, jak se začíná projevovat kvadratický člen z kapitoly 9 — 4.79 ms při tisíci tokenech proti 6.04 ms při osmi tisících, 26% penalizace jen za to, že je prompt delší.

Důsledek pro tři cesty je přímý. Cesta jedna dělá prefill třiačtyřiceti tisíc tokenů na otázku a cache hit je to, co z toho dělá snesitelné — kapitola 16 vysvětlila proč: čtení z cache nahrazuje práci prefill, takže kupuje latenci i peníze jednou transakcí. Cesta dvě dělá prefill tisíce tokenů a nejdřív přidá round trip do indexu. Cesta tři dělá prefill osmadvaceti a nepřidává nic, takže je měřitelně nejrychlejší ze tří v odpovídání. Jen odpovídá na špatnou věc.

Tři selhání, která vypadají jako problémy modelu, ale nejsou — deset minut tady ušetří měsíc později:

A požadavek přes to všechno: toto rozhodnutí nelze udělat bez evaluační sady a dodavatel, který fine-tune prodává, to říká také. Průvodce OpenAI začíná větou „Only invest in fine-tuning after setting up evals. You need a reliable way to determine whether your fine-tuned model is performing better than a base model“ a dodává, že pokud padesát dobrých příkladů nic nezmění, problém je v úloze nebo promptu, ne v objemu dat.¹ Dvacet otázek, což tato kapitola použila, ukazuje mechanismus a neumí vybrat dodavatele — kapitola 4 změřila proč, a co dělat, když dvacet případů je vše, co máte — opakovat je, párovat je a měřit rozptyl mezi běhy — je kapitola 29.

Čtyři sloupce a rozhoduje jen ten poslední:

Pravidlo, které z toho vypadne, je dost krátké na zapamatování: začněte promptem; přidejte retrieval, když se fakta hýbou; fine-tune použijte jen tehdy, když jste změřili, že to, co vám stále chybí, je tvar, ne fakt — a než to uděláte, naceňte odpověď, ne prompt.

Nepříjemná verze pro každého, kdo přišel s už hotovým rozhodnutím: v měřeném případě této kapitoly je fine-tuning nad čtyři tisíce otázek měsíčně nejlevnější cesta, a na faktech pořád nedokáže porazit odpovídání CLAUDE.md na všechno.

Každá cena tady byla za token a každá cesta byla jiný způsob uspořádání tokenů. To teď přestane platit.

Kapitola 21 opouští text. Obrázek vstupující do modelu není řetězec, ale mřížka patchů s počtem tokenů, který jste si nevybrali; mluvená minuta se u jednoho poskytovatele účtuje po sekundách a u jiného audio tokenem; syntetická řeč se prodává po znacích, transkripce po minutách, raw compute po GPU sekundách. Otázka, na kterou tato kapitola odpověděla jednou nákladovou funkcí — co je levnější? — se nedá ani položit, dokud jednotky nesedí, a žádná kalkulačka na internetu je nenormalizuje.

Je to také místo, kde se trénování znovu objeví: obrazový adaptér se trigger word a hlas klonovaný ze vzorku. Což vyvolává otázku, kterou příští kapitola otevírá, a není rétorická: pokud je fine-tuning jazykového modelu téměř vždy špatný nákup, proč je fine-tuning obrazového modelu téměř vždy správný?

Každá cena, práh a násobek v této kapitole byly přečteny z vlastní stránky poskytovatele 7. září 2026 a jsou citovány s tímto datem, protože všechny se budou hýbat. Naměřené hodnoty — počty tokenů, velikosti chunků, velikosti retrieval, training loss, skóre, latence a počty z historie verzí — byly vyrobeny na jednom stroji téhož dne a jsou reprodukovatelné z výše popsaného korpusu.

Lokální experimenty používaly Qwen/Qwen2.5-0.5B-Instruct s greedy decoding, takže se reprodukují přesně; adaptér je dvanáctiřádková třída vytištěná výše, na rank 8 přes q_proj a v_proj. Korpus je trackovaná Markdown dokumentace jednoho fungujícího softwarového repozitáře, bez dvou append-only logů, a její míra změn byla spočítána z historie verzí tohoto repozitáře.