Fine-tunen, retrieval of prompt? De beslissing is economisch

“Moeten we fine-tunen?” wordt gesteld alsof het een vraag over een model is. Het is een vraag over een budget, met een vorm waarop geen benchmark antwoord geeft: wat wordt één keer betaald, wat wordt per vraag betaald, en wat wordt opnieuw betaald telkens wanneer de wereld beweegt.

De drie routes zijn ook niet drie manieren om één ding te doen, en de leveranciers zeggen dat duidelijker dan de meeste blogposts. OpenAI’s eigen tabel met waar supervised fine-tuning het best voor is noemt vier toepassingen: classificatie, genuanceerde vertaling, content genereren in een specifiek format, en fouten in instruction-following corrigeren.¹ Geen daarvan is “het model iets leren wat het niet weet”. De samenvatting van het voordeel is dat “je kortere prompts kunt gebruiken met minder voorbeelden en contextdata, wat op schaal token-kosten bespaart en lagere latency kan opleveren” — een argument over de factuur, van het bedrijf dat de feature verkoopt.

Dus:

• Fine-tuning leert vorm en gedrag. Toon, format, de vorm van een antwoord, een grens die je kunt demonstreren maar niet beschrijven. De sterkste gepubliceerde versie is LIMA’s Superficial Alignment Hypothesis: kennis komt uit pretraining, alignment leert vooral welke sub-distributie van formats het model moet spreken — daarom waren duizend gecureerde voorbeelden daar genoeg.²
• Retrieval levert feiten die veranderen. Het is de enige van de drie waarbij een wijziging in je documentatie het antwoord bereikt zonder het model aan te raken.
• Prompting dekt de meeste echte gevallen, en is de eerlijke baseline. In-context learning is sinds Language Models are Few-Shot Learners de standaard: de taak wordt in de prompt gedemonstreerd en geen enkel weight beweegt.³

Twee gemeten papers sluiten de deur voor de fout in het midden. Ovadia en collega’s vergeleken kennis injecteren via unsupervised fine-tuning met kennis injecteren via retrieval, en retrieval won consequent, ook bij feiten die het base model al in pretraining had gezien.⁴ Gekhman en collega’s maten de schade: voorbeelden die nieuwe kennis introduceren worden langzaam gefit, en wanneer het model ze uiteindelijk fit, stijgt het hallucination-percentage op andere vragen.⁵ Feiten leren via fine-tuning faalt niet alleen; het verslechtert antwoorden waarop je niet trainde.

Die helft is beslecht. De economische helft niet, en dat is de rest van het hoofdstuk.

Eén case, op drie manieren uitgevoerd: technische support over je eigen documentatie, die elke week verandert.

Het corpus is echt en staat op deze schijf: de 23 Markdown-documenten die een werkende softwarerepository als interne documentatie bewaart — de build guide, de merkregels, de vertaalbrief, tien servicehandleidingen, de performance- en security-notities. Gemeten met o200k_base, de encoding uit Hoofdstuk 7:

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

Drieënveertigduizend tokens is een comfortabele grootte voor deze beslissing: het past in elk modern window, dus alle drie routes zijn echt beschikbaar. Bij tien miljoen is de beslissing al voor je genomen, en is het retrieval.

Nu het werk dat het woord “wekelijks” doet. Documentatieverloop wordt meestal beweerd; hier wordt het geteld, uit de versiegeschiedenis van die repository:

De documenten bewegen ongeveer om de week. De user-visible strings — waar een supportdesk in de praktijk vragen over krijgt — bewogen in elke week dat ze bestaan, met ongeveer twintig commits per week. Welke route we ook kiezen, die moet dat overleven, en “hoe vaak verandert het ding waarop je trainde?” blijkt een getal in je eigen repository te hebben in plaats van een mening.

Twintig realistische supportvragen werden tegen dit corpus geschreven, één per onderwerp, en elk getal hieronder is over die twintig berekend.

Het eenvoudigste dat werkt: zet het hele corpus in de system prompt, de vraag aan het einde, en laat het model het vinden.

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

Elk getal daar is geteld behalve het laatste: 150 output tokens is een aanname, gekozen binnen de range van assistant-turns die Hoofdstuk 16 factureerde. Het is het enige getal hier dat niet is uitgevoerd, het wordt identiek toegepast op alle drie routes, en de break-even-sectie laat precies zien hoeveel de conclusie beweegt wanneer je het verandert.

Tegen de tarieven die op 7 september 2026 van de providerpagina zijn gelezen — $1.50 per miljoen input tokens, $9.00 per miljoen output⁶ — is dat $0.066317 per vraag. Je betaalt om drieënveertigduizend tokens opnieuw te lezen om dertien te beantwoorden.

De fix uit Hoofdstuk 16 is direct toepasbaar: het corpus is stabiel en staat vooraan, dus het is een perfecte cache-prefix, en teruglezen kost een tiende — $0.007864 per vraag, een besparing van 88 %. De waarschuwing uit Hoofdstuk 16 geldt ook, in de vorm die dat hoofdstuk signaleerde maar niet prijste. Deze provider rekent geen write-premium; hij rekent huur. Een expliciete cache kost $0.000001 per opgeslagen token per uur,⁶ dus 43,298 tokens warm houden kost

of iemand nu iets vraagt of niet. Dat is $189.78 over zes maanden, voor een lege kamer. Deel de huur door de besparing per vraag en de voorwaarde komt in één regel uit: dit corpus cachen verdient zichzelf terug boven 0,74 vragen per uur — 546 per maand zodra de wekelijkse cache-rebuild ook is meegerekend. Daaronder verliest de feature die je aanzette om geld te besparen juist geld.

Zelfde route, zelfde code, één flag, vijf keer de rekening. Hoofdstuk 16 vond een versie hiervan die werd veroorzaakt door een timestamp op de verkeerde plek; hier is niets verkeerd behalve het verkeer. Een cache is een weddenschap op volume, en bij deze provider plaats je die per uur.

De retriever uit Hoofdstuk 19, onveranderd: knippen op section boundaries met een contextuele header, indexeren, de vier beste fragmenten in de prompt zetten. Gemeten over de twintig vragen:

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

Tweeënveertig keer minder prompt tokens dan route één, voor $0.002906 per vraag. De index kost $0.0070 om te bouwen tegen $0.15 per miljoen embedding tokens⁶ — minder dan drie vragen waard — en dezelfde $0.0070 om elke keer dat de documentatie verandert helemaal opnieuw te bouwen. De volledige index elke week zes maanden lang rebuilden kost achttien cent.

Eén ding is het waard om bij stil te staan. Retrieval vernietigt prompt caching. De stabiele prefix is nu de system instruction van 140 tokens; vanaf token 141 verschilt de prompt bij elke call, omdat de fragmenten per vraag worden gekozen. En 140 tokens ligt onder elk cacheminimum dat Hoofdstuk 16 citeerde. Route twee kan dus helemaal niet worden gecached, wat slecht klinkt en dat niet is: 1,037 tokens niet cachen is goedkoper dan 43,298 cachen.

Dat is een algemene regel om mee te nemen: de twee grote token-besparende technieken sluiten elkaar op dezelfde content uit, en degene die wint is degene die meer tokens verwijdert. Retrieval verwijdert 97,6 % ervan.

Train op tweehonderd voorbeelden in de huisstijl, stel daarna vragen zonder enige documentatie eraan vast.

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

Training kost 24,389 × 3 × $10.00 per miljoen = $0.7317. Dat zijn de volledige bouwkosten, minder dan een kop koffie, en dat is precies waarom zoveel teams betalen voordat ze controleren of het helpt.

Nu de val, en de reden dat dit hoofdstuk bestaat. Een fine-tuned model kost niet hetzelfde om te draaien als zijn base model. De pricing page zegt het in één zin: “for model inference starting from Gemini 3, tuned model endpoint prediction price will be 1.5 times of the base model.”⁶ Niet de training. De inference, op elke token, zolang het model leeft.

Zet het dus in een formule. Laat $p_i$ en $p_o$ de base input- en outputprijzen zijn, $m$ de tuned multiplier, $L_R$ de promptlengte van de route die je vervangt, $L_F$ de promptlengte na fine-tuning, en $O$ de antwoordlengte. Fine-tuning is per vraag alleen goedkoper wanneer

De eerste term is duidelijk: je nieuwe korte prompt, met opslag. De tweede niet, en daar gaat het geld heen — de opslag op het antwoord, die niets met je prompt te maken heeft en die training niet kan verkorten. Met de gemeten getallen — $m = 1.5$, $L_F = 28$, $O = 150$, $p_o/p_i = 6$ — is de drempel

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

Bij de gemeten antwoordlengte: 492 tokens — waarvan 450 de antwoordopslag zijn, niet de prompt. Een kortere prompt dan dat vervangen is per vraag duurder, voor altijd, bij elk volume; en de drempel groeit lineair met hoeveel je assistant zegt, dus een assistant die lange antwoorden schrijft kan zich nooit via fine-tuning naar een goedkopere token trainen, hoeveel prompt hij ook verwijdert.

Hetzelfde feit van de andere kant is de zin om te onthouden. Van de $0.002088 per vraag van de fine-tuned route is 97,0 % het antwoord. Fine-tuning optimaliseert de resterende drie procent.

Vier getallen beschrijven elk van deze routes: wat je één keer betaalt, wat je betaalt wanneer de documentatie verandert, wat je per uur betaalt ongeacht gebruik, en wat je per vraag betaalt. Dat breidt Hoofdstuk 16’s computeCost uit zonder die te wijzigen.

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);
}

Het tuned model is geen andere prijslijst, het is dezelfde prijslijst vermenigvuldigd:

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 })),   
});

Die ene gemarkeerde regel is het hele argument uit de vorige sectie als code geschreven: de multiplier landt ook op output.

Zes maanden, met de documentatie wekelijks ververst:

En de crossovers, de vier getallen die een budget echt nodig heeft:

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

Lees de eerste twee samen, want zij zijn het punt van het hoofdstuk. Een stationair corpus laat fine-tuning zichzelf in honderdvijftig vragen terugverdienen; een corpus dat wekelijks verandert verschuift dezelfde crossover met een factor zevenentwintig, en niets aan het model is veranderd — alleen hoe vaak je er opnieuw voor betaalt. Bouwkosten zijn een voetnoot; onderhoudskosten zijn de beslissing.

Als je nu concludeert dat een drukke supportdesk moet fine-tunen, geeft de rekenkunde je gelijk. Het is nog steeds verkeerd, en de volgende sectie legt uit waarom.

Het kostenblad heeft één kolom die het niet kan berekenen, dus deze sectie draait de fine-tune: lokaal, op een klein open model, met de adapter met de hand geschreven in plaats van uit een library gehaald. Hoofdstuk 11 bouwde LoRA; hier is hij, op de q_proj en v_proj van alle 24 lagen van Qwen2.5-0.5B-Instruct op 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

De tweehonderd trainingsvoorbeelden komen mechanisch uit het corpus, dus ze reproduceren: de vraag is een section heading die is omgezet in een vraag, het antwoord is de eigen tekst van die sectie in een strikte huisstijl — één regel beginnend met Short answer:, één regel beginnend met Source: met het bestandspad. Het format is de vorm die wordt geleerd; het pad is het feit. Daarna twee getallen over twintig held-out vragen: komt het antwoord in de huisstijl naar buiten, en noemt het het bestand dat de vraag echt beantwoordt?

Twee baselines maken de tabel leesbaar, en beide zijn Hoofdstuk 4’s nadruk in plaats van een nagedachte. Tien van de twintig juiste antwoorden zijn hetzelfde bestand, dus een model dat de vraag negeert en altijd CLAUDE.md antwoordt scoort 10/20. En de retriever heeft zijn eigen plafond: over deze twintig vragen bevatten de vier fragmenten 14 keer het juiste bestand en ranken ze het 7 keer als eerste, dus 14/20 is de hoogste score die een reader ermee zou kunnen halen.

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

De vorm werd volledig en snel geleerd. Nul naar negentien van de twintig, met een adapter van 540,672 parameters — 0,109 % van het model — in vijf minuten training op een processor zonder videokaart in zicht.

De feiten niet. Acht van de twintig is niet te onderscheiden van de tien die je krijgt door de vraag volledig te negeren, en Hoofdstuk 4’s interval op twintig samples zegt dat hardop. Die bestandspaden zaten drie keer in de training data; wat eruit kwam was de gewoonte om te eindigen met een plausibel ogende Source:-regel. Op de vraag bovenaan dit hoofdstuk antwoordde het fine-tuned model Short answer: 10.x . . . en citeerde het CLAUDE.md. Het juiste antwoord, dat in CLAUDE.md staat, is 18.17.0.

En daarna brak de vorm, en dat is de rij die het experiment rechtvaardigt. Geef het fine-tuned model duizend tokens aan opgehaalde fragmenten — een prompt-vorm die het nooit had gezien, omdat elke training prompt achtentwintig tokens was — en de huisstijl zakt van 19/20 naar 1/20. Op de vraag bovenaan dit hoofdstuk antwoordt het 18.17.0 — correct, en zonder enig format waarvoor het was getraind. Fine-tuning leerde dus geen format; het leerde een format conditioneel op de prompts in de trainingsset, en de eerste prompt die er anders uitzag nam het format mee. Waarop je fine-tunet wordt de ene inputdistributie waarin je model goed is, en niemand zet dat in de spreadsheet.

Een laatste opmerking over de metric, recht vooruit wijzend naar Hoofdstuk 29: “correct source” scoort vorm en feit samen, en daarom zien beide retrieval-rijen er verschrikkelijk uit, ook al hadden beide modellen het feit van die vraag goed. Eén end-to-end getal verborg drie dingen — een retriever met 14/20 recall, een 0.5B reader en een citation format — en kiezen wat je moet fixen betekent ze scheiden voordat je meet, niet erna.

Nu de kolom die leveranciers voor je invullen. Een fine-tuned model is geen asset die je bezit; het is een lease op iemand anders’ base model, met een einddatum erop gedrukt. Op 7 september 2026 stond in de fine-tuning-sectie van OpenAI’s pricing page deze volledige melding:

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.⁷

De tijdlijn is op de dag gedateerd: 7 mei 2026, gesloten voor organisaties die nooit hadden gefine-tuned; 2 juli 2026, gesloten voor organisaties die in zestig dagen geen inference op een fine-tuned model hadden gedraaid; 6 januari 2027, helemaal geen nieuwe jobs meer.⁸ Dezelfde pagina plant de shutdown van de fine-tuned models zelf — ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano, ft-babbage-002, ft-davinci-002 — op 23 oktober 2026, elk met een recommended replacement base model, wat een beleefde manier is om te zeggen: train het opnieuw.

De andere frontier-leverancier heeft je de lease nooit verkocht. Anthropic’s documentatie-index telt 699 pagina’s en geen enkele gaat over fine-tuning; de model-customisation-secties van de Bedrock-pricing page behandelen Amazon Nova, Amazon Titan, Cohere, Meta en OpenAI open-weight models, en geen Claude.⁹¹⁰ Als je architectuur van een fine-tune afhangt, is één van de drie frontier-families simpelweg bij geen enkel budget beschikbaar.

Self-hosting vervangt de lease op een model door een lease op een machine, en AWS doet die rekenkunde op zijn eigen pagina: één model unit aan provisioned throughput voor een customized model, commitment van één maand, is “1 model unit × $21.18 × 24 hours × 31 days = $15,757.92” per maand.¹⁰ De metal direct huren is goedkoper en niet gratis — $3.99 per GPU-uur on demand voor een H100, $1.99 preemptible¹¹ — ongeveer $2,900 per maand voor één kaart die aan moet staan of iemand nu iets vraagt of niet. De hele retrieval-route bij tienduizend vragen per maand is $174.52 voor zes maanden.

Hier verdient LoRA zijn plek, als budgetargument in plaats van technisch argument. Gemeten op hetzelfde model is een rank-16 adapter over attention en de feed-forward layers 8,798,208 parameters — 1,781 % van het model, 17,6 MB in bfloat16 — tegenover 0,988 GB aan base weights, en zijn optimiser- en gradient-state is 140,77 MB waar full fine-tuning 7,90 GB nodig heeft, een factor 56. Het gevolg is niet goedkopere training maar dat één geladen base model veel adapters kan bedienen, wat de enige manier is waarop de vaste kosten van een GPU door iets worden gedeeld. Managed training weerspiegelt dat: $0.48 per miljoen tokens low-rank tot 16B tegenover $0.54 full, met een minimum van $4.00 per job.¹¹ Die ondergrens is het detail. Bij 24,389 tokens voor drie epochs wordt elke retraining op dit corpus als $4.00 gefactureerd in plaats van de $0.04 waar de berekening op uitkomt — $104 aan minimums over zesentwintig wekelijkse runs, voor een rekenkundige eenennegentig cent.

Nog twee kolommen die alleen op de factuur verschijnen.

Data residency kost ongeveer tien procent, en twee providers zijn het eens over dat getal. OpenAI rekent “a 10 % uplift” op data-residency endpoints voor modellen die op of na 5 maart 2026 zijn uitgebracht;⁷ Vertex prijst zijn non-global endpoints op $1.65 tegenover $1.50, dezelfde tien procent.⁶ Zet dat naast de vijftig procent die een tuned endpoint kost en de folklore draait om: residency is goedkoop en fine-tuning niet — en fine-tuning is sowieso niet de private optie, omdat het corpus de provider hoe dan ook bereikt, één keer tijdens training in plaats van één keer per call.

De meest expliciete prijs die ooit op je data is gezet staat op dezelfde pagina, die één fine-tuned model twee keer vermeldt: met data sharing ingeschakeld is inference precies de helft — $2.00 tegenover $4.00 input, $8.00 tegenover $16.00 output.⁷ De provider laten bewaren wat je stuurde is een korting van 50 % waard, wat je vertelt wat het voor hen waard is.

Distillation — een klein eigen model trainen op antwoorden van een groot model — wordt meestal aangeboden als uitweg uit allebei. Prijs het en dat is het niet, omdat de teacher het systeem is dat je probeerde te vervangen: tweehonderd trainingsvoorbeelden produceren door de retrieval-route tweehonderd vragen te stellen kost 200 × $0.002906 = $0.58, boven op de $0.73 om erop te trainen. Distillation doe je nadat de retrieval-pipeline werkt, om die goedkoper te maken, en het erft elk feit dat de retriever verkeerd had.

Geld is de zichtbare helft. De andere komt als wachten, met dezelfde oorzaak als de rekening: het model leest de hele prompt voordat het een woord zegt. Hoofdstuk 13 mat prefill tegenover decode op een model dat je kon aanraken; hier is dezelfde meting, één run, één machine, tegenover promptlengte:

De absolute getallen horen bij een 0.5B-model op zestien CPU-threads en zeggen niets over een gehost frontier model. De vorm draagt exact over: prefill groeit met promptlengte, en de kosten per token kruipen omhoog zodra de kwadratische term uit Hoofdstuk 9 zichtbaar wordt — 4.79 ms bij duizend tokens tegenover 6.04 ms bij achtduizend, een penalty van 26 % alleen omdat het langer is.

Het gevolg voor de drie routes is direct. Route één prefills drieënveertigduizend tokens per vraag, en een cache hit maakt dat draaglijk — Hoofdstuk 16 legde uit waarom: een cache read vervangt prefill-werk, dus koopt hij latency en geld in één transactie. Route twee prefills duizend en voegt eerst een round trip naar de index toe. Route drie prefills achtentwintig en voegt niets toe, wat hem meetbaar de snelste van de drie maakt in antwoorden. Hij beantwoordt alleen het verkeerde ding.

Drie failures die op modelproblemen lijken en dat niet zijn — tien minuten hier bespaart later een maand:

En de eis boven alles: deze beslissing kan niet worden genomen zonder evaluation set, en de leverancier die de fine-tune verkoopt zegt dat zelf. OpenAI’s guide opent met “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”, en voegt toe dat als vijftig goede voorbeelden niets veranderen, het probleem de taak of de prompt is, niet de hoeveelheid data.¹ Twintig vragen, wat dit hoofdstuk gebruikte, tonen een mechanisme en kunnen geen leverancier kiezen — Hoofdstuk 4 mat waarom, en wat je doet wanneer twintig cases alles zijn wat je hebt — ze herhalen, pairen en de spreiding tussen runs meten — is Hoofdstuk 29.

Vier kolommen, en alleen de laatste beslist:

De regel die eruit valt, en hij is kort genoeg om te bewaren: begin met de prompt; voeg retrieval toe wanneer de feiten bewegen; fine-tune alleen wanneer je hebt gemeten dat wat je nog mist een vorm is, geen feit — en prijs het antwoord, niet de prompt, voordat je dat doet.

De ongemakkelijke versie, voor iedereen die aankwam met de beslissing al genomen: in de gemeten case van dit hoofdstuk is fine-tuning de goedkoopste route boven vierduizend vragen per maand, en op de feiten kan hij nog steeds niet beter dan overal CLAUDE.md op antwoorden.

Elke prijs hier was per token, en elke route een andere manier om tokens te rangschikken. Dat houdt nu bijna op waar te zijn.

Hoofdstuk 21 verlaat tekst. Een image dat een model binnenkomt is geen string maar een grid van patches met een token-aantal dat je niet hebt gekozen; een gesproken minuut wordt bij de ene provider per seconde gefactureerd en bij een andere per audio token; synthetic speech wordt per karakter verkocht, transcription per minuut, raw compute per GPU-seconde. De vraag die dit hoofdstuk met één kostenfunctie beantwoordde — wat is goedkoper? — kan niet eens worden gesteld totdat de eenheden overeenkomen, en geen calculator op het internet normaliseert ze.

Daar verschijnt ook training weer: een image adapter met een trigger word, en een voice cloned uit een sample. Wat de vraag oproept waarmee het volgende hoofdstuk opent, en die is niet retorisch: als fine-tuning van een language model bijna altijd de verkeerde aankoop is, waarom is fine-tuning van een image model dan bijna altijd de juiste?

Elke prijs, drempel en multiplier in dit hoofdstuk is op 7 september 2026 van de eigen pagina van de provider gelezen en met die datum geciteerd, omdat ze allemaal zullen bewegen. De gemeten getallen — token counts, chunk sizes, retrieval sizes, training loss, scores, latencies en version-history counts — zijn op dezelfde dag op één machine geproduceerd en zijn reproduceerbaar uit het hierboven beschreven corpus.

De lokale experimenten gebruikten Qwen/Qwen2.5-0.5B-Instruct met greedy decoding, dus ze reproduceren exact; de adapter is de hierboven afgedrukte twaalfregelige class, op rank 8 over q_proj en v_proj. Het corpus is de tracked Markdown-documentatie van één werkende softwarerepository, exclusief twee append-only logs, en de change rate is geteld uit de versiegeschiedenis van die repository.