Hvad AWS har udgivet, og hvorfor det betyder noget
AWS har publiceret en guide, der samler tilpasning af generativ AI i et konkret spektrum fra at bruge en model som den er til at træne sin egen. Ifølge indlægget er foundation-modeller fra Anthropic, Meta, Mistral og Amazon tilgængelige via Amazon Bedrock, og AWS peger eksplicit på brugsscenarier som chatbots, kodeassistenter, dokumentprocessorer og autonome agenter som oplagte mål. Pointen er ikke, at modellerne findes. Pointen er at vælge det rigtige trin for en given opgave, fordi forkerte valg koster dyrt i compute, tid og troværdighed over for interessenter.
Guiden skitserer en 8-trins beslutningsramme, der starter med det enkleste og kun skalerer op, hvis nødvendigt. AWS beskriver det som en trappe, hvor hvert trin kræver mere data, flere kroner og mere drift—men også giver mere kontrol og domænespecifik præcision. Timingen er skarp: mange teams famler stadig mellem for mange valgmuligheder og ender i over‑engineering eller under‑investering.
Spektret forklaret trin for trin
AWS deler spektret i tre hovedkategorier: USE, ENHANCE og TRAIN. USE er der, hvor man lader modellens vægte være og arbejder på måden, man spørger. Det handler om systeminstruktioner, få eksempler i prompten og konsistent struktur—og så måling af promptkvalitet over tid. ENHANCE betyder at lægge noget uden om modellen, fx Retrieval Augmented Generation, caching eller distillation, hvor man komprimerer viden ned i en hurtigere model uden at ændre vægtene. TRAIN er det tunge: finetuning med mærkede data, continued pre‑training på store ulabellede korpora, eller at bygge fra bunden.
Hvert skridt opad hæver kravene til dataforvaltning og governance. RAG kræver et søgeindeks, opdateringsplaner og styr på adgangskontrol til kilderne. Finetuning kræver rene, repræsentative datasæt, dokumentation for oprindelse og klare aftaler om opbevaring og sletning. Træning fra bunden kræver alt ovenstående plus massiv compute og modelopsætning, som bringer en tung MLOps‑hverdag med sig. AWS understreger, at de relative omkostninger og datakrav vokser opad, men giver ikke konkrete priser eller benchmarks i blogindlægget.
Hvad USE betyder i praksis
I USE‑kategorien ligger gevinsten ofte i at få styr på sprog, format og evaluering. En skarpere systemprompt, et par gode eksempler og en fast outputskabelon kan løfte nøjagtigheden i en chatbot eller et dokumentudtræk markant. AWS anbefaler også egentlig prompt‑evaluering, så man ikke flyver på anekdoter. Et simpelt framework med faste testspørgsmål, forventet svarformat og scoring for korrekthed og robusthed er nok til at fange regressions, når prompts ændres.
Den praktiske forskel ses hurtigt i driften. Uden formel evaluering ender teams med at optimere for det seneste fejludfald og glemme helheden. Med en letvægts‑eval bliver det tydeligt, hvornår USE‑trinnet er udtømt, fordi nøjagtigheden stagnerer på bestemte domæneforespørgsler eller dokumenttyper. Så er det tid til at se på ENHANCE.
Hvad ENHANCE kræver
RAG er det mest brugte skridt i ENHANCE. Her grounder man svar i egne dokumenter uden at røre modellens vægte. Det giver to direkte fordele: mere ajourført viden og bedre sporbarhed til kilder. Men det flytter kompleksiteten over i retrieval: indekskvalitet, chunking, embeddings, adgangskontrol og cache‑strategier. Fejl her slår igennem som hallucinationer forklædt som citater. Ikke charmerende.
Caching og distillation adresserer økonomi og latency. Dyre prompts kan caches for at undgå gentagne beregninger, mens viden fra en stor model kan destilleres ned i en mindre for lavere omkostning i produktion. AWS kalder det at “harness” modellen. Man trækker kapacitet ud uden at forpligte sig til langvarig dataforvaltning som ved finetuning. For mange workloads stopper trappen her, ifølge AWS.
TRAIN er ikke bare et stort skridt. Det er flere
Finetuning kan låse op for domænesprog, stilkrav eller opgaveformer, som selv god promptning og RAG ikke løser. Men det kræver kuraterede, mærkede datasæt og en plan for løbende retræning, evaluering og rollback. Continued pre‑training er endnu tungere, hvor man fodrer modellen med store mængder ulabellede tekster for at udvide dens generelle viden. Og nederst på trappen venter fuld custom træning på egne data og infrastruktur.
Her stiger omkostninger, risici og krav til governance kraftigt. Finetuning med dårlige eller skæve data forværrer modellen. Uigennemsigtige datakilder skaber compliance‑risiko. Og tidslinjer ryger, når træningsjobs skal gentages for fejlrettelser. AWS’ budskab er tydeligt: start simpelt, og eskalér kun, når målinger viser, at det er nødvendigt.
De hyppigste fejl, som koster dyrt
AWS peger på to fejl, der går igen. Den ene er at hoppe direkte til finetuning, selv om en bedre prompt eller RAG ville have løst problemet hurtigere og billigere. Den anden er at blive hængende i prompt engineering, selv om der åbenlyst mangler domænedata, som kræver finetuning. Begge fører til spildt compute, forsinkede lanceringer og et tillidsproblem, når resultaterne ikke holder vand.
To korte scenarier: Et team bygger en kundeservicebot og finetuner for at ramme brandets tone. Efter tre uger opdager de, at en stærkere systemprompt med klare regler for tone og policy gav samme løft på to dage. Et andet team forsøger at udtrække felter fra tekniske manualer. De tweaker prompts i en måned, men uden domænespecifik træning på mærkede eksempler rammer de aldrig pålidelige resultater. Da de endelig finetuner, går præcisionen i vejret—men budgettet er væk. Hverdagen, ikke sjældenheder.
Hvorfor spektret er nøglen til at nå produktion
Deloitte rapporterer, at 89 procent af AI‑agentpiloter ikke bliver til produktion. Teradata supplerer, at 78 procent af virksomheder har mindst én pilot kørende, men kun cirka 14 procent har skaleret en til bred brug. Masser af forsøg, få succeser. Kilderne peger på, at det ikke primært er modellernes evner, men alt omkring dem, der spænder ben: dataadgang, evaluering, ejerskab og cost control.
Set i det lys bliver AWS’ trappe mere end et pænt diagram. Den er et værn mod at spilde måneder på det forkerte gear. Start i USE, opbyg målinger, og eskalér kun, når data viser behov. RAG og andre ENHANCE‑tiltag hjælper med at angribe dataadgang og ajourføring, før man binder sig til træningens governance‑krav. Og hvis man vælger TRAIN, så gør det med klare ejerskabs‑ og evalueringsmekanismer på plads.
Hvad det betyder for governance og compliance
Valget af trin ændrer dataflow og dermed compliance‑krav. RAG betyder, at der opbygges et søgeindeks med egne dokumenter. Det kræver adgangsstyring, logning af retrieval og hensyn til retention for kilderne. Der skal være styr på, hvilke data der må hentes hvornår, og hvordan citater dokumenteres. En revision vil spørge til kildekæde, indeksets opdateringsfrekvens og hvem der havde adgang.
Finetuning og træning hæver barren yderligere. Her skal der være råderet over træningsdata, klare licenser og dokumenterede beslutninger om filtrering, anonymisering og sletning. I en dansk og europæisk sammenhæng vil GDPR og branchekrav kræve dataminimering og begrundet opbevaring. Ikke et sidespor. Et hovedspor—og det skal på plads, før compute‑kontoen løber løbsk.
Implementering og drift uden overraskelser
Tekniske teams bør planlægge for tre ting fra start: en datastrøm, en evalueringssløjfe og en omkostningsvagt. Datastrømmen adskiller prompt‑data, retrieval‑data og træningsdata, så der er klare hegnspæle mellem trinene. Evalueringssløjfen følger faste metrikker på nøjagtighed, robusthed, latency og fejltyper, så teamet kan dokumentere, hvorfor de skifter trin. Omkostningsvagten følger tokenforbrug, GPU‑timer og indeks‑vedligehold, så budgettet ikke imploderer.
Derudover er der nogle driftsting, der ofte overses. Latens‑SLO’er bør aftales tidligt, især hvis RAG introducerer ekstra hop. Fallback‑strategier er nødvendige, når retrieval fejler eller en cache rammer ved siden af. Og når en finetunet model deployes, skal rollback være triviel—ellers bliver et lille dataproblem til et produktionsstop. AWS’ råd om trinvis eskalering hjælper, men kun hvis metrikkerne er ærlige.
Hvornår finetune, hvornår RAG, hvornår bygge selv
Et praktisk beslutningstræ starter med et simpelt spørgsmål: Kan en velstruktureret prompt klare langt de fleste tilfælde i en realistisk evaluering? Hvis ja, fortsæt og mål. Hvis nej, så spørg om kritisk viden ligger i interne dokumenter, som brugerne forventer kildehenvisning til. Hvis ja, prøv RAG. Hvis nøjagtigheden stadig taber på domænesprog eller specialiserede formater, så kig på finetuning.
Spørg også til datakvalitet og mængde. Er der et solidt sæt eksempler, der repræsenterer opgaven uden at lække persondata eller forretningshemmeligheder? Hvis svaret er tvivlsomt, er finetuning for tidlig. Er latency kritisk, og er RAG for tungt? Så kan distillation eller caching være et mere nøgternt valg end at træne fra bunden. AWS leverer ikke faste tærskler for antal eksempler eller pris pr. token, så organisationer må teste sig frem under kontrollerede forhold.
Økonomien som AWS ikke udfolder
Blogindlægget beskriver relative omkostninger, men ingen konkrete priseksempler. Det efterlader åbne spørgsmål, som bør afklares tidligt. Hvad koster et typisk finetuning‑job inklusive datasanering, labeling og to retræningsrunder? Hvad koster vedligehold af et RAG‑indeks pr. måned ved en given dokumentvækst og opdateringsfrekvens? Og hvordan ser inference‑kurven ud, når distillation reducerer modelstørrelse, men måske kræver højere requestvolumen?
Brugere bør derfor efterspørge prisblade fra leverandøren eller uafhængige rådgivere: cost per finetune‑job, lagringsomkostninger for trænings‑ og indeksdata, netværksomkostninger ved retrieval og enhedsomkostninger for inference med og uden cache. Uden de tal bliver valget af trin hurtigt en mavefornemmelse. Det holder sjældent i en styregruppe.
For og imod AWS’ råd
Fordelene ved at starte simpelt er til at tage og føle på: lavere cost, hurtigere tid til noget der virker, færre governance‑bindinger og klarere signaler i evaluering. Det er også lettere at kommunikere til forretningen, hvorfor man bliver på USE eller ENHANCE, når målingerne er transparente. Det reducerer risikoen for at brænde troværdighed af på lovede løft, der udebliver.
Ulempen er, at visse domæner har nultolerance for fejl eller kræver terminologi, som kun finetuning kan levere i praksis. Kliniske tekster, juridiske procedurer, komplekse tekniske standarder. Her kan det være spildtid at iterere for længe på prompts og retrieval. AWS’ ramme favner også det, men kræver, at man tør sige højt, at behovet for TRAIN er tydeligt og dokumenteret. Det er en balance, og nogle vil være uenige i vægten. Fair nok.
Dansk vinkel og åbne huller
I en skandinavisk sammenhæng spiller regulatoriske krav, dataejerskab og driftskultur tungt ind. Valg af trin i spektret bør derfor vægte arbejdsbelastning, datakompleksitet og compliance højt allerede i foranalysen. Det handler ikke om at gøre alt i cloud eller alt on‑prem. Det handler om at dokumentere, hvilke data der må bruges hvor, og hvordan det påvirker governance og audit.
Konklusion
AWS’ customization spectrum er ikke revolution. Det er nyttigt, fordi det gør valget konkret i en tid, hvor 78 procent har en eller anden form for pilot, men kun omkring 14 procent skalerer. Trinvis tænkning skærer ned på fortrydelsestimer, fordi den binder beslutninger til målinger og governance. Budskabet er klart: start med det enkle, mål ærligt, og eskalér kun, når det er bevist nødvendigt.
Næste skridt for organisationer er ligetil: Sæt et evalueringspanel op, der afspejler jeres reelle brugssager. Afklar datakilder, ejerskab og retention, før I lover nogen en finetunet model. Få prisestimat for RAG, finetuning og drift på bordet og beslut ud fra totalomkostningen, ikke hypen. Forskellen mærkes først, når man sidder med det i hænderne.
