AI i drift: mål svartid og pris pr. godkendt opgave

Definér først, hvad en godkendt opgave er

En AI-løsning er ikke billig, blot fordi et enkelt modelkald koster lidt. Hvis medarbejderen bagefter skal rette svaret, gentage kørslen eller undersøge en forkert opdatering, ligger en del af omkostningen uden for API-regningen. Vælg derfor en afsluttet forretningsopgave som jeres primære måleenhed.

Brug eksempelvis en kundemail, der bliver kategoriseret og får et korrekt svarudkast klar til vurdering. Beskriv, hvad der gør opgaven godkendt: korrekt kategori, nødvendige oplysninger, ingen opdigtede løfter og en tydelig markering af det, der kræver et menneske. Et teknisk gyldigt JSON-svar er ikke i sig selv en løst kundeserviceopgave.

Hold flere tal ved siden af hinanden. Modelomkostning pr. godkendt opgave viser, hvordan det målte API-forbrug fordeles på brugbare resultater. Samlet omkostning med kontroltid, integration og drift viser noget bredere. Bland dem ikke i samme beløb uden at forklare, hvad der er med.

Fastlæg også, hvad der tæller som et forsøg. Hvis ét forløb kalder tre modeller og derefter genstarter, skal alle kald knyttes til samme opgave-id. Mislykkede og afbrudte forsøg skal med i forbruget. Ellers kommer løsningen til at se billigere ud, netop når den bliver mere ustabil.

Denne guide viser en målemetode og illustrative regneeksempler. Den påstår ikke, at en bestemt model eller et bestemt optimeringstrin giver samme effekt i jeres drift.

Mål både første tegn, færdigt svar og hele forløbet

Svartid er flere forskellige oplevelser. Tid til første token beskriver, hvornår genereringen begynder at vise indhold. Samlet genereringstid beskriver, hvornår svaret er færdigt. Den samlede opgavetid kan desuden omfatte kø, opslag, værktøjskald, validering og menneskelig kontrol. Vælg målepunkter, som passer til brugerens arbejde.

For en chat kan et hurtigt første tegn gøre ventetiden mere forståelig. For en integration, der først må arbejde videre med et fuldt valideret objekt, er første token sjældent det afgørende. Her er tiden til et brugbart og kontrolleret resultat vigtigere. Streaming kan forbedre oplevelsen uden at gøre den samlede behandling hurtigere.

Registrér start og slut omkring hvert meningsfuldt trin. Et enkelt samlet tidsstempel fortæller ikke, om en langsom opgave skyldes modellen eller et CRM-opslag. Brug en konsistent målemetode, og undgå at sammenligne browserens tid med serverens tid, hvis deres ure ikke er afstemt.

Rapportér median og en højere percentil sammen med antal observationer. Medianen viser en typisk kørsel; de langsomme tilfælde kan være dem, der skaber kø eller får en bruger til at give op. Små datasæt giver usikre percentiler, så oplys testens størrelse og periode.

Sæt et tydeligt timeoutforløb. Når ventetiden overskrider den aftalte grænse, skal systemet kunne vise status, stoppe eller sende opgaven videre uden at miste det allerede udførte arbejde.

Byg et regnskab, der følger opgaven gennem alle kald

Gem modelnavn og version, tokenforbrug, varighed, status og en reference til den opgave, kaldet tilhører. Notér også, om input blev faktureret som cache, og om kørslen benyttede batch eller en anden prisklasse. Brug leverandørens faktiske brugsfelter, når de er tilgængelige, og markér beregnede eller manglende oplysninger tydeligt.

En enkel tokenberegning er inputtokens gange inputpris plus outputtokens gange outputpris, med den korrekte enhedsomregning. Men leverandørens regning kan også omfatte værktøjer, billedbehandling, lyd, lagring eller andre poster. Hold disse uden for tokenestimatet, indtil de er medtaget udtrykkeligt. Prisberegneren i vores benchmarkbibliotek viser sit afgrænsede grundlag.

Undgå at gemme personoplysninger og hele prompts alene for at kunne følge forbruget. Et internt opgave-id og et begrænset sæt tekniske målinger er ofte tilstrækkeligt til økonomioversigten. Hvis fejlundersøgelse kræver indhold, bør adgang og opbevaring aftales særskilt.

Fastfrys den prisliste og dato, der blev brugt til en sammenligning. Hvis prisen ændres senere, skal det kunne ses, om et gammelt resultat er beregnet igen eller stadig bruger den oprindelige sats. Sammenlign heller ikke beløb i forskellige valutaer uden en oplyst kurs og dato.

Det vigtigste er sporbarhed: Kan I forklare, hvorfor en dyr opgave blev dyr, og hvilke resultater forbruget faktisk gav?

Brug et regneeksempel, der også medtager afviste resultater

Forestil jer to opsætninger, der hver behandler de samme 100 tænkte opgaver. Opsætning A bruger 40 kr. i det afgrænsede modelregnskab og leverer 80 godkendte resultater. Opsætning B bruger 30 kr. og leverer 50 godkendte resultater. Tallene er udelukkende illustrative og er ikke aktuelle priser eller måleresultater.

For A bliver modelomkostningen 40 divideret med 80, altså 0,50 kr. pr. godkendt opgave. For B bliver den 30 divideret med 50, altså 0,60 kr. Den billigere samlede modelkørsel er dermed dyrere pr. godkendt resultat i dette eksempel. Hvis kontrollen desuden tager forskellig tid, ændrer det den samlede økonomi yderligere.

Oplys begge tællere sammen med forholdstallet. En pris uden antal godkendte opgaver skjuler kvaliteten; en godkendelsesandel uden totalforbrug skjuler økonomien. Hvis ingen opgaver godkendes, er pris pr. godkendt opgave ikke et meningsfuldt endeligt tal. Vis i stedet, at forsøget ikke leverede et godkendt resultat.

Brug samme acceptkriterier og opgaver i sammenligningen. Ellers kan en opsætning se bedre ud, fordi den fik lettere input eller blev vurderet mildere. Medtag et eksempel, hvor løsningen korrekt afstår fra at svare. Hvis dette er det aftalte korrekte udfald, kan det være en godkendt opgave, selv om brugeren ikke fik et automatisk svar.

Fjern unødigt arbejde, før I skifter model

Begynd med målingerne. Hvis et langsomt databaseopslag dominerer forløbet, løser et modelskifte ikke nødvendigvis problemet. Hvis prompten indeholder dokumenter, som aldrig bruges, kan bedre udvælgelse mindske input uden at ændre selve modelvalget. Kontrollér først, hvor arbejdet faktisk ligger.

Hold output tæt på opgaven. Et kort struktureret resultat kan være tilstrækkeligt til kategorisering, mens en rådgivende forklaring kræver mere tekst. En vilkårlig lav outputgrænse kan afkorte vigtige oplysninger og give flere genforsøg. Test derfor ændringen på både almindelige og vanskelige input.

Brug faste regler til entydige kontroller. Et manglende obligatorisk felt eller et ugyldigt id kræver ikke nødvendigvis et modelkald. Det kan være mere forståeligt at afvise det tidligt med en præcis årsag. Bevar dog den nødvendige fleksibilitet dér, hvor input skal fortolkes.

Uafhængige opslag kan nogle gange køre samtidig, mens afhængige handlinger må vente på resultatet fra det forrige trin. Parallelisering kræver også grænser for samtidighed og leverandørernes belastning. En hurtigere enkeltkørsel er ikke en forbedring, hvis den under normal trafik giver flere fejl eller en uforudsigelig regning.

Gentest kvalitet efter hver ændring. Besparelser i tokens eller millisekunder er først nyttige, når de aftalte resultater stadig holder. Gem den forrige opsætning, så en dårlig ændring kan tilbageføres uden at rekonstruere den fra hukommelsen.

Vælg cache, batch og streaming efter arbejdsgangen

Cache er relevant, når genbrug kan ske på et gyldigt og tilstrækkeligt identisk grundlag. Skeln mellem leverandørens promptcache og jeres egen genbrug af et færdigt svar. De har forskellige betingelser. Et gemt svar kan blive forkert, hvis kundens adgang, kilderne eller virksomhedens vilkår har ændret sig.

Dokumentér derfor, hvad en cachepost afhænger af, og hvornår den udløber. Brug ikke alene spørgsmålets ordlyd som nøgle, hvis svaret også afhænger af brugerens rettigheder eller aktuelle data. Mål faktisk cachehit og kvalitet frem for at regne med, at alle gentagelser bliver genbrugt.

Batch passer til opgaver, der kan vente på asynkron behandling, eksempelvis en aftalt natlig klassifikation. Det kræver jobstatus, håndtering af enkeltfejl og en måde at genoptage arbejdet på. En kundeservicehandling med kort svartidskrav kan have en helt anden tidsramme. Kontroller den konkrete leverandørs aktuelle vilkår i dokumentationen.

Streaming passer til visning af et løbende svar, men kræver en særskilt beslutning om, hvornår output må bruges. Et delvist objekt må ikke udløse en skrivning, fordi de første felter ser rigtige ud. Vis gerne status undervejs, men vent med handlingen, til det nødvendige resultat er samlet og valideret.

Afprøv hvert greb separat før en samlet konfiguration. Så kan I se, om forbedringen kom fra genbrug, kørselsform eller brugeroplevelsen.

Brug routing og kaskader med målbar eskalation

Routing vælger en model eller behandlingsvej ud fra opgaven. En kaskade forsøger først én vej og eskalerer derefter efter et resultat eller en kontrol. Begge kan være relevante, men de tilføjer beslutninger, som også kan fejle. En billig model, der ikke opdager sin egen fejl, kan sende et forkert svar videre uden eskalation.

Definér eskalationsreglen med uafhængige signaler, hvor det er muligt. Manglende kilder, afvist datastruktur eller en opgave uden for det aftalte område er mere kontrollerbare end modellens egen påstand om at være sikker. Nogle opgaver bør fra begyndelsen sendes til en fagperson.

Medregn alle trin. Hvis mange opgaver først bruger den lille model og derefter den store, kan både pris og samlet svartid blive dårligere end ved et direkte kald. Opgave-id'et i måleskemaet gør det muligt at se, hvor ofte denne dobbelte behandling sker.

RouteLLM og FrugalGPT beskriver forskningsbaserede tilgange til modelvalg og kaskader. De er baggrund for metoden, ikke en garanti for den samme besparelse i jeres virksomhed. Test jeres router på et tilbageholdt sæt opgaver, og sammenlign med en enkel reference, der altid bruger én valgt model.

Sæt en grænse for antal forsøg og eskalationer. Et system må ikke blive ved med at spørge nye modeller, indtil et svar ser behageligt ud. Et kontrolleret stop med en tydelig årsag er også en nødvendig afslutning.

Lav en sammenligning, der kan gentages

Fastlæg testmateriale, acceptkriterier, modelversioner og måleperiode, før kørslen starter. Bland lette og vanskelige opgaver efter en dokumenteret plan. Hvis hver kandidat får helt forskellige opgaver, bliver det svært at vide, om forskellen skyldes modellen eller materialet.

Lad en faglig vurdering af resultatet være adskilt fra prisoversigten, når det er praktisk muligt. Det mindsker fristelsen til at acceptere flere fejl hos en billig kandidat. Brug en fælles rubric med konkrete eksempler på korrekt, delvist korrekt og afvist. Gennemgå uenighed, så acceptkriterierne bliver anvendt konsistent.

Registrér afvisninger, rate limits, timeouts og tekniske fejl. Oplys også samtidighed, fordi en måling med ét kald ad gangen ikke nødvendigvis beskriver et system under normal belastning. En gentest på et andet tidspunkt kan vise, hvor stabilt resultatet er, men må ikke bruges til kun at vælge den pæneste kørsel.

Opdel resultatet efter opgavetype og konsekvens. Et gennemsnit kan skjule, at en kandidat klarer korte beskeder fint, men fejler på lange dokumenter eller sjældne undtagelser. Vælg derfor ud fra de krav, der betyder noget i driften.

En leverandørs offentlige benchmark er nyttig til at finde kandidater. Jeres eget testforløb skal afgøre, om modellen passer til netop jeres data, godkendelse og svartidskrav.

Gør målingerne til en konkret driftsbeslutning

Opsummér forsøget med godkendte opgaver, samlet forbrug, kontroltid, svartidsfordeling og de vigtigste fejl. Beskriv derefter, hvilken opsætning I vil bruge til hvilke opgaver, og hvilke opgaver der fortsat skal behandles manuelt. En beslutning er mere brugbar end en løs rangliste med én vinder.

Aftal et budget og relevante forbrugsgrænser. Et pludseligt hop kan skyldes mere trafik, længere input, en fejl i genforsøg eller en ændret integration. Overvåg derfor både totalbeløb og forbrug pr. opgave. Grænserne bør give en forståelig reaktion, eksempelvis kø, begrænset funktion eller manuel håndtering.

Gentest ved ændringer, der kan påvirke resultatet: ny modelversion, nye kilder, ændret prompt, nye værktøjer eller en anden opgavetype. Bevar et lille fast regressionssæt og supplér med nye fejl fra driften. Målemetoden skal være stabil nok til at opdage en forringelse.

Hvis I vil have hjælp, kan Mosel Studio begynde med at gennemgå én konkret arbejdsgang og de målinger, I allerede har. Vi kan afklare, hvilke kvalitetskrav og prisposter der mangler, og hvordan et afgrænset forsøg bør se ud. I behøver ikke kende den rigtige model på forhånd; det er netop dét, et ordentligt beslutningsgrundlag skal hjælpe med.