Det korte svar først: Fine‑tuning lever. I 2026 er det bare sjældent førstevalg i enterprise. Det er ikke vores kæphest; Towards AI’s analyse 29. maj 2026 skriver det direkte i “Why 1M‑Token Windows Changed the Math” og “What Context Orchestration Actually Is”. Vi kan genkende det i projekter, vi har kørt i produktion.
Bygger I en produktionsassistent nu, så start med konteksten. Lag for lag, målbart og styrbart. Gem finetuning til de få, snævre tilfælde, hvor den faktisk er billigere eller mere stabil i drift. Det er også linjen i “When Fine‑Tuning Still Wins”.
Fra modeldyrkelse til systemtænkning
I årevis blev finetuning brugt til to ting på én gang: bage viden ind i modellen og styre adfærd. Det virkede i en prototype. Indtil verden flyttede sig, og man sad med et frossent checkpoint og en tung releasecyklus. Towards AI peger på, at problemet “få modellen til at vide og gøre det rigtige” ofte løses bedre af kontekst‑orkestrering end af monolitiske finetunes (se “Form vs Facts”).
Det er et arkitekturskifte i praksis. Ikke flere modelvarianter for hver nye regel eller dokumentopdatering. Men et system, der tildeler den rigtige viden i det rigtige øjeblik – og måler, om det faktisk hjælper.
Hvor regnestykket tippede
I “Why 1M‑Token Windows Changed the Math” beskriver Towards AI, hvordan store kontekstvinduer ændrede balancen: Når modellen kan tage meget mere struktureret kontekst ind, falder behovet for at bage viden ind i vægtene. Mindre retraining. Færre regressions. Der er stadig omkostninger – lange vinduer koster hukommelse og latency – men valget står ikke længere mellem “finetune alt” eller “lev med tom kontekst”.
Hvad betyder det i hverdagen? At I kan holde viden opdateret uden en træningsrunde hver gang produktet ændrer sig. At latency skal styres strammere, fordi lange prompts er dyre. Og at performance flyttes fra træningsskripter til orkestreringen af kontekst. Vi har set det i virkeligheden: Da vi fjernede unødvendige tool‑hops i en produktion, faldt svartiderne mærkbart. Internt datapunkt, ikke eksternt dokumenteret.
Hvad kontekst‑orkestrering faktisk er
Orkestrering er ikke “bedre prompts”. Det er samspil mellem lag. Towards AI’s lagbeskriveler matcher vores manual på de centrale punkter (krydshenvisning: “The Four Layers of Context…” + Snillds interne manualbrief):
- Dokumentforståelse og retrieval, så svar kan spores til kilder og citater.
- Graf og relationer, så entiteter og tidslig kontekst hænger sammen.
- Værktøjer og API’er, så modellen slår op og handler i stedet for at gætte.
- Hukommelse, både kort og lang, til sessioner og gentagelser.
- Policy‑motor, der håndhæver regler og tilladelser i praksis.
- Eval og telemetri, så kvalitet, regressions og cost bliver synlige over tid.
Terminologien varierer lidt mellem kilderne, men byggestenene – og ideen om at starte med kontekst før modelændringer – er konsistente (Towards AI + Snillds manualbrief).
En dag i drift
Sådan ser det ud, når det spiller. En bruger spørger til et produktkrav. Retrieval trækker tre relevante dokumentrevisioner. Graf‑laget lægger relationer på: releasedatoer, afhængigheder, ansvarlig teamleder. Policy‑motoren tjekker adgang og fjerner det, der er for internt. Modellen formatterer svaret og henviser til kilder. Et værktøj kalder et internt system for status. Eval‑harness gemmer hele kæden og scorer svaret mod en fast eval‑sætning.
Det afgørende for drift er, at vi kan rulle et lag tilbage uden at røre resten. Og vi kan se, hvor fejlen opstod. Det er forskellen på system og modelvariant.
Et mønster vi bruger i praksis
Vi bygger det som en LLMOps‑pipeline: indtag, normalisering, berigelse, evaluering. Kontekstkilder versioneres. Grafen opdateres inkrementelt. Logs fra værktøjskald går tilbage i eval‑harness’et. Vi kører face‑offs: orkestreret variant A vs. A + lille finetune på samme datasnit og latencybudget. Vinderen går videre. Dette er vores praksis – interne metoder, ikke eksternt bevis.
I en anonymiseret bankcase skar et relationslag og en stram policy‑motor hallucinationer i sagsresuméer med cirka en tredjedel. Målt i faste eval‑kørsler før og efter ændringen. Internt datapunkt, markeret som sådant.
Når finetuning stadig vinder
Fine‑tuning har fortsat stærke, smalle cases – det fremgår også af “When Fine‑Tuning Still Wins”.
- Tone og stil, hvor en lille instruct‑tilpasning stabiliserer udtryk uden prompthacks.
- Edge og on‑prem, hvor latency og datasuverænitet kræver en mindre, målrettet model.
- Call‑routing og klassifikation, klart afgrænsede beslutninger med lav TCO.
- Lavressource‑sprog: AWS’ SageMaker‑blog om azerbajdjansk LLM beskriver i produktion 23 procent højere træningsthroughput, 58 procent lavere peak GPU‑hukommelse via kernetilpasninger og cirka 2× tokens per word med en specialiseret tokenizer – i en telco‑case. Kilde: “Training Azerbaijani language models on Amazon SageMaker AI”.
Fejltilstande og risici du kan teste for
Orkestrering har egne brist. Towards AI kalder “context poisoning” for den glemte fejlkilde: forurenet kontekst giver selvsikre, forkerte svar (“Context Poisoning — The Failure Mode Nobody Talks About”). Alle systemer med dynamisk viden risikerer det. Vi har set en mild version: et fejlbehæftet dokument i et bibliotek gav forkerte svar, indtil kilden blev rettet. Internt eksempel.
Hvad gør man så?
- Kildeversionering og signering, så svar kan spores til præcis dokumentrevision.
- Policy‑tests, der blokerer værktøjskald på tværs af følsomhedsniveauer.
- Eval‑suiter, der bevidst injicerer forældede eller falske dokumenter og måler effekten.
- Telemetri med alarmer på usædvanlige ruter, spikes i afvisninger og ændret værktøjsadfærd.
Økonomien bag valget
Fine‑tuning ligner en engangsinvestering. Men hver opdatering kræver ny træning, validering, sign‑off og release. Rollback? Ikke altid trivielt med frosne checkpoints. Lav latency, ja. Lav fleksibilitet, også. Towards AI gennemgår de skjulte omkostninger i “The Hidden Costs Nobody Puts in Their Blog Post”.
Orkestrering har flere dele, men de kan skiftes lagvist: forbedr retrieval uden at røre policy; opdatér graf uden at røre modellen. Skift foundation‑model bag et stabilt API og eval‑harness. Når drift, compliance og forbedringstempo regnes med, tipper TCO ofte til orkestrering i brede, skiftende problemrum. Det er også hovedlinjen i Snillds interne manual.
Ulempen ved orkestrering, lad os være ærlige
Ja, det kan blive komplekst. Mange integrationer, flere versioner, flere logs. Hvis man bygger et Frankenstack, brænder man tid og budget. Vi har prøvet det én gang. Det gør vi ikke igen. Modstykket er disciplin: klare grænseflader mellem lag, streng versionering, eval tæt på koden og få, vigtige værktøjer i stedet for tyve halvbrugte. Mere system. Mindre roulette med modelvarianter.
Og cost? Der er løbende drift. Men prisen for mange finetunede varianter, der hver kræver compliance og change‑kontrol, er sjældent lavere over tid. Her er vi på linje med Towards AI’s beslutningsramme.
Et beslutningsframework der sparer måneder
Start her – og hold jer til det, også når presset stiger:
- Vælg orkestrering først, hvis problemet er bred, skiftende viden, krav om citater, varierende regler og hyppige ændringer (krydshenvisning: Towards AI’s decision framework).
- Mål fra dag ét: nøjagtighed med kildehenvisning, hallucinationsrate, latency p50 og p95, værktøjs‑success rate, retriever‑precision/recall, cost per løst sag og regressions efter opdatering. Gem ruter og mellemtrin.
- Vælg finetune, når fejlen er stabil og i formen (tone, fast skema, klassifikation), når I skal på on‑prem med mindre modeller, eller når low‑resource sprog kræver specialiseret tokenizer og domænelag (jf. AWS‑casen).
Sådan gør vi det målbart
Opsæt face‑offs tidligt: definer et datasnit pr. use case, fastlæg p50/p95‑latencybudget, og kør A vs. A+finetune over samme kilder og værktøjsadgang. Lås versionsnumre for kilder, model og værktøjer i hver run. Evaluer på nøjagtighed med kilde, afvisningsrate, værktøjsfejl og omkostning pr. svar. Vinderens konfiguration rykker videre i pipeline. Interne metoder – beskrevet her for reproducerbarhedens skyld.
Vi har også et data‑flywheel i drift: hver fejl rutes enten til kontekstforbedring (nyt dokument, ny relation, skarpere policy) eller en lille finetune, hvis mønstret er stabilt. Det holder tempoet i forbedringer oppe, uden at splitte modellen i varianter.
Kildenoter og metode
Kerneanalysen bygger på Towards AI’s “Fine‑Tuning is Dead: Why Context Orchestration Won in 2026” af Mehul Ligade/Editorial Team, 29. maj 2026. Vi henviser særligt til afsnittene “What Context Orchestration Actually Is”, “The Four Layers of Context Every Production System Needs”, “Why 1M‑Token Windows Changed the Math”, “The Hidden Costs Nobody Puts in Their Blog Post”, “Context Poisoning — The Failure Mode Nobody Talks About” og “When Fine‑Tuning Still Wins”.
Som teknisk reference for arkitektur og drift bruger vi Snillds interne manualbrief fra 2026. Den beskriver lagdelt kontekst (RAG 2.0, graf/ relationer, værktøjer, hukommelse, policy‑motor, eval/ telemetri) i en LLMOps‑pipeline og en selektiv hybridtilgang. De nævnte bankmålinger, latency‑observationer og eval‑praksis er interne erfaringer og markeret som sådanne.
Til dokumentation af finetuning i produktion for lavressource‑sprog henviser vi til AWS’ “Training Azerbaijani language models on Amazon SageMaker AI”, der rapporterer 23 procent højere træningsthroughput, 58 procent lavere peak GPU‑hukommelse og cirka 2× tokens per word via en specialiseret tokenizer i en telco‑case.
Hvad I bør gøre nu
Drop jagten på den “perfekte model”. Invester i systemet rundt om den: eval‑harness, referencearkitektur, versionerede kontekstkilder og en lille, disciplineret policy‑motor. Lav en smal finetune, når eval viser, at formen – ikke viden – er den vedvarende fejl, og ROI‑vinduet er tydeligt. Resten er at få det til at køre. Man mærker først forskellen, når det står i produktion.
