AWS skriver i sin guide, at “data preparation determines the ceiling of any supervised fine-tuning (SFT) project.” Det er kernen i indlægget og sætter retningen for arbejdet, før nogen åbner en træningspipeline. Pointen er praktisk: kvaliteten af eksemplerne afgør, hvor langt man kan komme med SFT, jf. AWS.
Guiden rammesætter tre efter-træningsgreb, der dækker forskellige behov: Continued pre-training (CPT), Supervised fine-tuning (SFT) og Reinforcement fine-tuning (RFT). AWS beskriver også et mønster, hvor man ofte starter med CPT, går videre til SFT og slutter med RFT, afhængigt af om der mangler viden, adfærd eller finjustering via feedback. Ifølge AWS bruges CPT i praksis sjældnere og typisk kun, når basis-modellen mangler kritisk domæneviden; hyppigheden på tværs af sektorer kvantificeres ikke i indlægget.
Hvad AWS faktisk siger
I AWS-indlægget defineres CPT sådan: “Continued pre-training (CPT) ingests large volumes of unstructured domain text to expand the model’s knowledge base. Use CPT when the model lacks familiarity with your domain’s terminology, concepts, or data patterns.” SFT afgrænses tilsvarende: “Supervised fine-tuning (SFT) trains on curated input-output pairs to reshape the model’s behavior… It doesn’t inject new knowledge.” Det vil sige, SFT former hvordan modellen svarer, ikke hvad den ved, ifølge AWS.
Om RFT skriver AWS: “Reinforcement fine-tuning (RFT) optimizes behavior through reward signals… when you can programmatically evaluate output quality but can’t easily demonstrate the reasoning path at scale.” AWS peger samtidig på et produktionsmønster: “A production pattern is CPT, then SFT, then RFT,” og tilføjer, at CPT i praksis bruges mindre ofte og kun når domæneviden mangler. AWS anfører også, at foundation-modeller som Amazon Nova er trænet på brede korpora, så SFT fulgt af RFT ofte rækker langt uden CPT.
Hvorfor dataforberedelse kommer først
AWS fremhæver dataforberedelse som første skridt for SFT: “Every response in your dataset should be a gold-standard answer…” Svage eksempler bliver imiteret. SFT lærer mønstre fra input–output-par, så ujævn kvalitet viser sig i adfærden. Derfor sætter forberedelsen loftet – ikke mængden alene, ifølge AWS’ formulering.
Guidens første del dækker fundamentet: kvalitetstjek, formateringskrav og train\/eval-splits. Den funktion er eksplicit beskrevet af AWS for at hjælpe teams med at undgå typiske faldgruber, inden selve træningen kører.
Formatering og kvalitet i praksis
AWS viser kodeeksempler fra Amazon Bedrock-dokumentationen, der illustrerer, hvordan man strukturerer input–output-par og opstiller train\/eval-splits. Pointen er at gøre format og validering eksplicit, så datasættet kan inspiceres, og fejl opdages tidligt, jf. AWS.
Konkrete principper fra AWS’ beskrivelse: brug gold-standard svar, som matcher den kvalitet, man ønsker i produktion; definér og håndhæv et klart output-format, når modellen skal levere strukturerede outputs; og adskil træning og evaluering, så man kan vurdere generalisering frem for hukommelse. Det er ifølge AWS det niveau, SFT kan lære stabil adfærd på.
Hvornår CPT er nødvendigt
AWS’ beslutningsregel er tydelig: vælg CPT, når basis-modellen mangler domæneordforråd, begreber eller datamønstre, som opgaven kræver. CPT udvider viden ved at indtage store mængder ustruktureret domænetekst. SFT kan derimod ikke indsprøjte ny viden, men forme adfærd, ifølge AWS’ definitioner.
AWS tilføjer, at CPT ofte kan undværes, fordi foundation-modeller som Amazon Nova er trænet på brede korpora. I de tilfælde rækker SFT – og eventuelt RFT – langt. CPT bliver relevant, når der dokumenterbart mangler domæneviden, som opgaven afhænger af, jf. AWS’ indlæg.
Konsekvenser for workflow og drift
Ifølge Snillds manualbrief handler stabil SFT-drift om en data-centreret proces: klare output-skemaer understøttet af annotator-guides, så mennesker producerer konsistente eksempler; automatiserede valideringspipelines, der tjekker skema, typer og forretningsregler; samt løbende evaluering mod forretningsmål. Anbefalingerne fra manualbriefen sigter mod at gøre SFT til et reproducerbart trin i en stabil produktion, ikke et ad hoc-eksperiment.
Det supplerer AWS’ fokus på forberedelse: når data er kvalitetssikret og formatet er tydeligt, bliver finetuning mere forudsigelig. Både AWS og Snillds manualbrief prioriterer dataenes kvalitet som den vigtigste investering før compute i SFT-forløb, jf. de to kilder.
Risici og begrænsninger
Unite.ai fremfører en kritisk kommentar om, at modeller stadig fejler på komplekse opgaver og professionel dømmekraft, på trods af en udbredt fortælling om det modsatte. Det modsiger ikke AWS’ vejledning, men indrammer den: datapræparation og SFT former adfærd, men er ikke et bevis for, at komplekse ræsonneringsopgaver er løst på tværs af domæner. Unite.ai-stykket skal læses som perspektiv, ikke som systematisk dokumentation.
Hands-on tjek før SFT
På baggrund af AWS’ guide og Snillds manualbrief er de praktiske forberedelser klare: gennemfør et data-audit og fjern eksempler, der ikke lever op til gold-standard (jf. AWS’ krav); fastlæg et entydigt output-format, når modellen skal levere struktureret output; opstil en annotator-guide, så mennesker følger samme regler; automatisér basale datatjek, så brud på skema og typer fanges før træning; og lav et tydeligt train\/eval-split, så resultater kan verificeres over tid.
AWS’ indlæg inkluderer kodeeksempler med Amazon Bedrock, som viser de centrale trin for formatering og splits samt, hvordan kvalitet kan håndhæves før træning. Det gør det lettere at etablere en gentagelig proces, jf. AWS.
Hvornår SFT alene rækker
Når opgaven handler om adfærd – at følge instruktioner, holde en bestemt tone, levere strukturerede outputs eller efterleve et skema – beskriver AWS, at SFT adresserer disse behov. Her kan RFT efterfølgende optimere adfærd gennem belønningssignaler, når kvalitet kan vurderes programmatisk, men hvor man ikke nemt kan demonstrere en korrekt fremgangsmåde i stor skala, ifølge AWS.
Når opgaven derimod er tung på domæneviden, og modellen mangler terminologi eller mønstre, anbefaler AWS CPT først. Valget afhænger altså af, om problemet er viden eller adfærd, jf. AWS’ ramme.
Prioritering mellem data og compute
AWS formulerer, at dataforberedelsen sætter loftet for SFT. Snillds manualbrief lægger sig på samme linje med fokus på gold-standard eksempler, klare skemaer, annotator-guides, automatiserede valideringer og løbende evaluering mod forretningsmål. Når data og format er på plads, bliver valget mellem SFT alene, SFT+RFT eller CPT et mere kontrolleret kompromis, ifølge de to kilder.
Hvad kilderne ikke besvarer
AWS skriver, at CPT bruges sjældnere og typisk kun, når basis-modellen mangler kritisk domæneviden. Hvor ofte det gælder på tværs af brancher, er ikke kvantificeret i AWS’ indlæg. Det peger på et behov for tidlig afklaring af domænedækning, før man planlægger et større forløb, jf. kilderne her.
Næste skridt
En nøgtern rækkefølge, i tråd med AWS’ vejledning og Snillds manualbrief: Start med at kvalitetssikre data og format, opbyg en enkel valideringspipeline, lav et stabilt train\/eval-split og finetunér først derefter. Viser evalueringen mangler i domæneviden, er CPT relevant. Ellers rækker SFT – og eventuelt RFT – langt, ifølge kilderne.
