Den dyreste del af en AI-arbejdsgang er sjældent selve modelkaldet
Den dyreste del af en AI-arbejdsgang er sjældent selve modelkaldet. Det er alt det, der sker omkring det: den kontekst, der sendes med hvert eneste kald, de gentagne systeminstrukser, og de agenter der taler videre til hinanden uden nogen holder styr på, hvad der egentlig er nødvendigt at sende. Writer har bygget om på præcis dette lag og fået omkostningen per løst opgave til at falde med op mod 41 procent, uden at nøjagtigheden går ned.
Orkestrering
Orkestreringslaget er den usynlige regning
Når en virksomhed sætter en AI-agent til at løse en sammensat opgave, sådan som at trække data fra et system, vurdere dem og skrive en rapport, består arbejdet reelt af mange modelkald bundet sammen. Hvert kald bærer sin egen kontekst med: instrukser, tidligere svar, værktøjsdefinitioner. Jo længere agenten arbejder, jo tungere bliver den bagage.
Jeg kører selv agenter i produktion, og mønsteret er til at tage og føle på: regningen vokser hurtigere end det arbejde, agenterne rent faktisk løser. Det skyldes ikke, at modellerne er blevet dyrere. Det skyldes, at orkestreringslaget, det stykke software der styrer hvornår og hvordan modellen kaldes, sjældent er optimeret til at spare på konteksten.
Writers ingeniører har angrebet netop dette lag, kaldet en harness, som det centrale sted at spare. Ikke ved at bruge en billigere model, men ved at ændre hvordan og hvor ofte modellen bliver bedt om at tænke.
Fra 41 procent færre tokens til uændret præcision
Tallene er konkrete, og det er værd at holde dem adskilt. I forsøg på seks foundation-modeller og 22 låste enterprise-opgaver faldt den blandede omkostning per opgave 41 procent, fra 21 til 12 cent. Tokenforbruget per opgave faldt 38 procent. Nøjagtigheden på opgaverne holdt sig stabil.
Det er en vigtig skelnen, for den nemme vej til lavere omkostning er at skære i konteksten og bare acceptere ringere kvalitet. Writer har i stedet fjernet spild, dobbeltarbejde og unødvendige gentagelser i den information, der sendes til modellen, uden at fjerne det, agenten faktisk skal bruge for at løse opgaven korrekt.
Jeg genkender mønsteret fra vores egen drift. Beslutningen om, hvornår en delopgave kan løses isoleret uden hele den akkumulerede historik, og hvornår den fulde kontekst er nødvendig, lyder triviel. Men den er summen af tusindvis af modelkald i en produktion, og det er præcis dér, den reelle besparelse ligger.
Sub-agenter holder hovedtråden ren
En central mekanisme i forbedringen er brugen af sub-agenter, mindre specialiserede agenter der løser afgrænsede deldele af en opgave og returnerer et kort, færdigt svar til hovedagenten i stedet for at lade hovedagenten bære hele processen selv. Uden den struktur vokser konteksten i hovedagenten lineært med hvert skridt i opgaven: hvert værktøjskald, hvert mellemresultat, hver fejl der skal rettes, lægger sig oveni det, modellen allerede skal forholde sig til.
Med sub-agenter bliver hovedkonteksten holdt slank. Hovedagenten ved, hvad opgaven er, og hvad resultatet blev, men behøver ikke bære hele vejen dertil med sig. Det er samme princip som en projektleder, der beder en specialist om et kort svar i stedet for at læse hele specialistens arbejdslog.
Gevinsten er ikke kun økonomisk. Den gør også systemet mere driftssikkert, fordi en lang, rodet kontekst er en af de hyppigste årsager til, at store sprogmodeller begynder at fejle eller hallucinere midt i en opgave. Jeg har set en agent køre af sporet netop dér, og det er sjældent modellen, der er problemet. Det er konteksten, den blev bedt om at bære.
Det kræver ikke en ny model. Det kræver, at man begynder at behandle orkestreringen som noget, der aktivt kan forbedres, målt og vedligeholdt, frem for et teknisk mellemled man sætter op én gang og glemmer.
En harness er et softwareprodukt, ikke et sidelag
Det, der adskiller denne tilgang fra almindelig prompt-optimering, er, at Writer behandler selve orkestreringslaget som et produkt i sig selv, med versionering, test og målbar ydeevne, på linje med resten af softwaren. De fleste virksomheder, der bygger agentbaserede løsninger i dag, betragter stadig orkestreringen som lim mellem model og applikation, noget der bare skal virke. Det er en fejlvurdering, der koster dyrt i skala.
For mig er det den samme disciplin, jeg lægger i alt andet, der kører i produktion: versionér det, test det, mål hvad hver ændring koster og sparer. Man kan A/B-teste to versioner af, hvordan en agent strukturerer sin kontekst, og se resultatet direkte i både pris og nøjagtighed. Den disciplin bliver ofte glemt, når AI kommer ind i billedet, fordi fokus lander på modellen og ikke på det system, der bruger den.
Det praktiske råd til danske virksomheder med AI i drift
For en dansk virksomhed, der allerede kører agentbaserede løsninger i produktion, er den vigtigste lære, at besparelsespotentialet sjældent ligger i at skifte model. Det ligger i at kigge på, hvordan konteksten bygges op gennem en arbejdsgang: hvor meget der gentages unødigt, hvor mange kald der bærer overflødig historik med sig, og om opgaver reelt kan deles op i mindre, isolerede skridt frem for at blive kørt som én lang, voksende samtale.
Mit råd, fra en der selv kører det: mål tokenforbrug per løst opgave, ikke bare per kald, og se hvor forbruget stiger hurtigst i takt med opgavens kompleksitet. Ofte findes svaret i, at en enkelt lang agent kan deles op i mindre specialiserede led, der leverer korte, færdige svar tilbage. Det kræver ikke en ny model. Det kræver, at man begynder at behandle orkestreringen som noget, der aktivt kan forbedres, måles og vedligeholdes, frem for et teknisk mellemled man sætter op én gang og glemmer.