Fem stikord skal blive til et kort samtalenotat. Skal den største tilgængelige sprogmodel arbejde ved hver forespørgsel? Ofte kan det betale sig først at afgrænse opgaven tydeligt og teste en mindre model.
Det ønskede resultat kan stå på få linjer.
Et fiktivt opkald registreres med disse stikord: »Kunden spørger til leveringstid, tilbud foreligger, intern afklaring mangler, tilbagemelding i morgen.« Beskeden skal sammenfatte indholdet forståeligt. Den må hverken opfinde en leveringsdato eller gøre stikordene til en bestilling eller et pristilsagn.
For denne opgave er fuldstændighed, korrekt tilknytning og håndtering af manglende oplysninger afgørende. En særlig udførlig argumentation eller et stort kontekstvindue kan medføre ekstra arbejde uden at gøre notatet mere nyttigt.
Først acceptkriterierne, så modelvalget.
Et testsæt indeholder ikke kun velskrevne eksempler. Forkortelser, slåfejl, modstridende tidsangivelser og manglende kontaktpersoner hører også med. For hvert eksempel er det fastlagt, hvad der må overtages, og hvornår et opklarende spørgsmål er nødvendigt.
En mindre model er egnet, hvis den opfylder disse krav pålideligt. Hvis ikke undersøges årsagen: uklar inddata, uegnet klargøring, manglende validering eller reelt utilstrækkelige evner hos modellen. En større model kan hjælpe, men er ikke det mest økonomiske svar på enhver fejl.
En kontrolleret router kan behandle opgaver forskelligt.
Et kort samtalenotat kan følge en anden behandlingsvej end en kompleks kontraktanalyse eller kodegennemgang. Valget tager hensyn til beskyttelsesbehov, godkendte udbydere, kvalitet og svartid. Ved et utilstrækkeligt resultat følger et opklarende spørgsmål eller en defineret eskalation.
En reservemodel må ikke udløse en ny, ikke-tilladt dataoverførsel. Faglig kontrol og budgetgrænser gælder fortsat, selv når den først valgte API ikke er tilgængelig.
Tokenprisen er kun én linje i regnestykket.
Et billigt kald kan blive dyrt, hvis medarbejderne ofte skal rette resultaterne. Omvendt kan en dyrere model samlet være fornuftig, hvis den afslutter en krævende opgave med væsentligt færre rettelser. Det er samme opgave med samme kvalitetskrav, der sammenlignes.
- Forbrug
- Ind- og outputforbrug, ekstra værktøjskald og nødvendige gentagelser.
- Kvalitet
- Andelen af reelt brugbare resultater og følgerne af fagligt kritiske fejl.
- Efterarbejde
- Tid til kontrol, rettelser, opklarende spørgsmål og ny behandling.
- Drift
- Integration, overvågning, opdateringer, grænser og håndtering af udfald.
Også inddata kan forbedres.
Til notatet gives de nødvendige stikord, ikke for en sikkerheds skyld hele kundehistorikken. Et klart outputformat letter kontrollen. Hvor tjenesten understøtter det, kan gentagne dele af inputtet drage fordel af prompt caching. Det skal måles, om der opstår et cachetræf, og hvilken virkning det har.
Asynkron batchbehandling er en anden mulighed for opgaver uden krav om et øjeblikkeligt svar. Den passer eksempelvis bedre til et forberedt dokumentgrundlag end til et notat, der skal bruges under samtalen.
En eksisterende fastpris gør ikke ventetid gratis.
Allerede betalte kvoter kan påvirke beslutningen. Unødige inddata, menneskeligt efterarbejde og optaget kapacitet er dog stadig relevante. En økonomisk arkitektur måler omkostningen pr. vellykket afsluttet opgave og kontrollerer den igen efter ændringer i model eller produkt.
Den faglige side AI-omkostningsoptimering forklarer modelrouting, gateways og lokal infrastruktur. Til vurdering af hele arbejdsgange supplerer Script, workflow eller AI-agent? beslutningsgrundlaget.
Kilder: OpenAI: omkostningsoptimering · OpenAI: prompt caching · OpenAI: batchbehandling. Ingen generelle besparelses- eller prisløfter.
