Claude Haiku 5.5 på AWS: 75 % lavere pris

I en agentopsætning er arbejdet sjældent fordelt jævnt. En orkestrerende model planlægger og træffer beslutninger i få kald, mens subagenterne udfører de mange små opgaver. Det er dér, tokenforbruget hober sig op.

Hvis subagenterne står for størstedelen af forbruget, slår et prisfald på cirka 75 procent næsten direkte igennem på driftsregningen. Samme arbejde koster en fjerdedel, eller du får fire gange så meget kørsel for de samme penge. Det gør mønstre realistiske, som før var for dyre at lade køre døgnet rundt, for eksempel at sende hver indkommende sag gennem flere små kontroltrin i stedet for ét stort.

Men tallet kommer med et forbehold. Anthropic skriver, at besparelsen gælder til de fleste opgaver, ikke alle, så jeg ville ikke love mig selv præcis 75 procent på egen regning. Og besparelsen gælder kun den del af trafikken, der faktisk flytter til Haiku 5.5. Kører orkestratoren på en større model, er det stadig den, der sætter bunden for regningen. Jeg har ikke et rent tal for, hvordan det fordeler sig i din opsætning, og det har du heller ikke, før du har målt det.

Den hurtige model er bedst, når opgaven er afgrænset, og svaret kan kontrolleres. Det gælder klassificering og routing af henvendelser, mails og tickets. Det gælder udtræk af strukturerede felter fra tekst, fakturaer og formularer. Det gælder resuméer af enkeltdokumenter, hvor kilden ligger i selve kaldet, og formatering af værktøjskald med validering mod et skema. Og det gælder en første sortering, hvor en større model eller et menneske tager de uklare tilfælde bagefter.

Omvendt er jeg tilbageholdende, hvor fejl er dyre, eller hvor modellen skal holde en lang og uklar ræsonnementskæde sammen. Planlægning på tværs af mange trin, afvejning af modstridende krav og den endelige afgørelse i en følsom sag hører stadig til på en større model. Et lavere prispunkt gør ikke en dårlig opgavefordeling god.

Den enkleste struktur er to lag. En stærkere model, for eksempel Claude Sonnet 5.5 på AWS, står for planlægning og den endelige vurdering. Haiku 5.5 tager de mange parallelle delopgaver. Orkestratoren giver subagenterne snævre instrukser og tydelige outputformater, så resultaterne let kan samles og kontrolleres. Det er i praksis dynamisk model-routing.

Tilføj en eskaleringsregel. Hvis en subagent returnerer et svar, der ikke består valideringen, eller melder lav sikkerhed, sendes opgaven videre til den større model. Så betaler du kun for den dyre model, når den faktisk behøves, og kvaliteten falder ikke i de svære tilfælde.

Hold også modelvalget adskilt fra forretningslogikken. Når modelnavnet ligger i konfiguration og ikke i koden, kan du flytte en opgave frem og tilbage mellem modeller uden at bygge om, og du kan måle effekten opgave for opgave.

• Mål nuværende forbrug pr. opgavetype, så du kender udgangspunktet i kroner og i kvalitet.
• Byg et testsæt af rigtige eksempler fra jeres egen trafik, inklusive de besværlige tilfælde. Se evalueringssæt fra egen trafik.
• Kør Haiku 5.5 på testsættet og sammenlign med den model, I bruger i dag, opgave for opgave.
• Fastsæt en tærskel for, hvornår et svar eskaleres til en større model.
• Log pris pr. gennemført opgave, ikke kun pris pr. kald. Gentagne forsøg kan æde besparelsen.
• Behold en fallback, så en opgave kan flyttes tilbage, hvis kvaliteten skuffer i drift.

Modellen er tilgængelig via Amazon Bedrock og Claude Platform on AWS, så den kan bruges med de samme konti, roller og den samme logning, som du allerede har. Tjek, at modellen er åben i den region, du kører i, og giv adgang på kontoen, før du bygger videre.

Mit råd er at starte småt. Vælg ét afgrænset flow med mange gentagelser, for eksempel sortering af indkommende henvendelser, og flyt kun det over. Mål kvalitet og pris i et par uger, og udvid først, når tallene holder.