Claude Sonnet 5.5 på AWS - ny

Forskellen fra tidligere Sonnet-versioner er, ifølge AWS' blogindlæg, ikke en ny funktion, jeg skal lære at bruge. Det er et bedre forhold mellem pris, hastighed og kvalitet. Modellen er bygget til at håndtere lange kodebaser og flertrins-ræsonnement uden at kræve den dyreste model i familien. Hos Agent Enterprise har jeg flere agenter, der laver kodereview og dokumentanalyse på Sonnet-niveau i stedet for den tungeste model, og den slags opgaver er dem, der rykker mest, når en mellemklassemodel bliver bedre.

Jeg ser ofte i mit arbejde med danske virksomheder, at valget af model fylder for meget i de indledende samtaler. Den egentlige værdi ligger i at matche opgaven til den rigtige model og bygge en solid driftsproces omkring den. Det er kedeligt at sige højt, men det er der, pengene faktisk ligger.

Det, der adskiller denne lancering fra en almindelig modelopdatering, er priseffekten, som AWS selv fremhæver i blogindlægget. Når en model bliver billigere per token og samtidig svarer hurtigere, påvirker det direkte driftsøkonomien for alt, der kører i stor skala: kundeservice-chatbots, automatiseret kodegennemgang, batch-behandling af dokumenter. Jeg har set tilfælde, hvor en virksomhed, der betaler for tusindvis af daglige forespørgsler, kan mærke en besparelse uden at skulle ændre en linje kode, blot ved at pege den eksisterende integration mod den nye modelversion.

Hastigheden har en lignende praktisk effekt. Kortere svartider betyder, at AI-assistenter i udviklerværktøjer eller kundeservicesystemer føles mere responsive. Det er i sidste ende det, der afgør, om medarbejdere og kunder rent faktisk bruger værktøjet i stedet for at falde tilbage på manuelle processer. Jeg har set agenter blive forladt, ikke fordi de tog fejl, men fordi de var for langsomme til at være værd at vente på.

For virksomheder, der allerede kører på Amazon Bedrock, er Sonnet 5.5 oftest mit standardvalg til kodeassistance, dokumentbehandling og intern videnssøgning, hvor opgaven kræver god ræsonnementskvalitet, men ikke den absolut tungeste model i Claude-familien. Det er modellen, jeg vælger, når jeg vil have hastighed og pris i balance uden at gå på kompromis med nøjagtighed på strukturerede opgaver som kodegennemgang eller dataudtræk.

Der er stadig opgaver, hvor en tungere model giver mere mening, typisk hvor kravet til dybde i ræsonnementet er højt, og volumen er lav nok til, at prisen per forespørgsel ikke er afgørende. Det gælder for eksempel komplekse strategiske analyser eller juridisk tekstfortolkning, hvor fejlmarginen skal være minimal. De virksomheder, jeg arbejder med, der har flere sikkerhedslag i deres AI-opsætning, har allerede et modelhierarki at navigere i, og Sonnet 5.5 finder sin plads som arbejdshesten i midten, ikke som enten den letteste eller den tungeste løsning.

Den praktiske fordel ved, at Sonnet 5.5 lanceres direkte på Amazon Bedrock, er, at virksomheder, der allerede har en AWS-infrastruktur, kan skifte model uden at flytte data eller bygge en ny integration fra bunden. Det er en opdatering af modelparameteren i den eksisterende opsætning, ikke et nyt projekt.

Jeg anbefaler altid det samme lavthængende frugt-tjek: test den nye model på de samme opgaver, I kører i dag, og mål forskellen i svartid og pris direkte mod den gamle version, før I beslutter jer for en fuld migrering. Den slags sammenligning er ofte det, der afgør, om en modelopgradering reelt betaler sig, i stedet for blot at antage det ud fra en prisliste.

For danske virksomheder, der allerede har investeret i AI-drevne processer, er budskabet enkelt. Modellandskabet bevæger sig hurtigt, og den model, I byggede jeres løsning på for seks måneder siden, er ikke nødvendigvis den bedste eller billigste i dag. Sonnet 5.5 er, ifølge AWS' eget blogindlæg, et konkret eksempel på, at prisfaldet og hastighedsforbedringerne i AI-industrien fortsætter, og at virksomheder, der holder deres modelvalg statisk, efterlader penge og performance på bordet.

Den mest værdifulde vane, en organisation kan opbygge lige nu, er derfor ikke at vælge en model én gang for alle, men at have en proces for løbende at revurdere, om den opgave, man har automatiseret, stadig kører på den mest fordelagtige model. Det kræver ikke et stort projekt. Det kræver, at nogen i organisationen faktisk holder øje med udviklingen og tester nye versioner mod de konkrete opgaver, I har i drift. Hos mig er det en fast del af driften, ikke en engangsbeslutning.