Vurder en proof of concept (PoC) for en AI-agent ud fra succeskriterier, der blev skrevet, før den blev bygget, på et fast sæt rigtige sager, som også omfatter de svære. Mål nøjagtighed, omkostning pr. opgave og latens, tjek, hvilke data og værktøjer den kan nå, og hvordan den fejler, og skalér først, når resultaterne holder uden for demoen.
En overbevisende demo er ikke et bevis
En demo viser en AI-agent fra dens bedste side, fordi den kører på eksempler, som udviklerne har valgt og øvet. Spørgsmålet før opskalering er et andet: hvor ofte løser agenten det rigtige arbejde korrekt, hvad koster hver opgave, og hvad sker der de dage, hvor den tager fejl?
Behandl PoC'en som et eksperiment, der ender med en beslutning: skalér, ændr eller stop. Den beslutning kræver kriterier, der er skrevet ned, før resultaterne kommer ind; ellers kan næsten ethvert resultat læses som lovende.
Skriv succeskriterierne, før agenten bygges
Definér, hvad der er godt nok for forretningen, og omsæt det til tal, du kan måle. For en agent, der sorterer supporthenvendelser, kan det være andelen af henvendelser, der sendes til det rigtige team, andelen, den med rette afviser at håndtere, og den tid, et menneske bruger på at kontrollere hver af dem.
- Succesrate for opgaven på realistiske sager med en skriftlig definition af et korrekt resultat
- De fejl, du kan tåle, og dem, du ikke kan, for eksempel et forkert svar sendt til en kunde
- Omkostning pr. udført opgave, inklusive modelforbrug og tiden for den person, der kontrollerer arbejdet
- En svartid, der passer til arbejdsgangen, afhængigt af om nogen venter på svaret
- Udgangspunktet: hvor lang tid opgaven tager for medarbejderne i dag, og hvor ofte de løser den korrekt
Test på et fast evalueringssæt bygget af rigtige sager
Saml rigtige input fra din egen historik, notér det korrekte udfald for hvert, og hold sættet fast. Tag lette sager med, tvetydige, sjældne og nogle få, som agenten bør afvise. Et mindre sæt velvalgte sager fortæller dig mere end et stort sæt lette.
Kør agenten på hele sættet, hver gang prompten, modellen, værktøjerne eller dataene ændres, og sammenlign resultaterne med den forrige kørsel. Modellernes output varierer fra kørsel til kørsel, så kør hver sag mere end én gang, og se på konsistensen, ikke kun på det bedste svar. Hold sagerne ude af prompten og ude af de eksempler, agenten ser, ellers bliver scoren for flatterende.
Tjek også, hvordan du giver point. Automatiske kontroller fungerer til strukturerede output. Fritekst kræver som regel et menneske eller en anden model, hvis vurderinger du har sammenlignet med et menneskes på en stikprøve.
Mål omkostning og latens ved den volumen, du forventer
En PoC, der håndterer nogle få dusin henvendelser om dagen, kan skjule omkostninger, der betyder noget ved tusinder. Registrér modelkald, tokens og værktøjskald pr. opgave og den tid, hver opgave tager. Agenter, der kører i ring, prøver igen eller læser lange dokumenter, kan koste langt mere end gennemsnittet på nogle input, så undersøg de langsomste og dyreste sager, ikke kun gennemsnittet.
Fremskriv derefter omkostningen ved den forventede volumen, og sammenlign den med, hvad arbejdet koster i dag, inklusive den tid, medarbejderne stadig vil bruge på gennemgang. Sæt faste grænser pr. opgave for trin, tokens og tid, så ét dårligt input ikke kan løbe op i en stor regning. OWASP Top 10 for LLM Applications opfører denne risiko som »unbounded consumption«, altså ubegrænset forbrug.
Design den menneskelige gennemgang bevidst, og mål den
Menneskelig gennemgang er en del af designet, ikke et midlertidigt sikkerhedsnet. Beslut, hvilke handlinger agenten må udføre på egen hånd, hvilke den kun må foreslå, og hvilke den aldrig må udføre. Alt, der ikke kan gøres om eller er synligt for kunderne, som at sende en besked, ændre en post eller bruge penge, bør vente på et menneskes godkendelse, indtil agenten har bevist sit værd over lang tid.
Mål selve gennemgangen: hvor lang tid den tager, hvor ofte reviewerne ændrer outputtet, og hvor ofte de godkender uden reelt at kontrollere. Hvis gennemgangen tager næsten lige så lang tid som at udføre opgaven, sparer agenten endnu ikke tid. Hvis din anvendelse kan regnes som højrisiko efter EU's AI-forordning, er effektivt menneskeligt tilsyn et lovkrav efter artikel 14 og ikke en designpræference, så inddrag dine juridiske rådgivere tidligt.
Fastlæg grænser for data og sikkerhed, før du skalerer
Opskalering bringer flere data, flere brugere og flere værktøjer, og det er dér, svage grænser begynder at få betydning. OWASP Top 10 for LLM Applications placerer prompt injection øverst: tekst, som agenten læser, for eksempel en e-mail, en supportsag eller en webside, kan indeholde instruktioner, der leder den i en anden retning. Listen nævner også »excessive agency«, altså flere funktioner, rettigheder eller mere autonomi, end opgaven kræver. Afklar disse punkter, før piloten vokser.
- Hvilke data agenten kan læse, og om personlige eller fortrolige data sendes til en modeludbyder, og i så fald på hvilke vilkår for kontrakt og opbevaring
- Hvilke værktøjer den kan kalde, med de snævrest mulige rettigheder og separate adgangsoplysninger for hver agent
- Hvad den kan ændre, og om hver ændring kan spores og rulles tilbage
- Hvad der logges: hvert værktøjskald med input og output, uden at persondata slipper ud
- Hvordan hver kundes eller hvert teams data holdes adskilt fra de andres
Undersøg, hvordan den fejler, og træf så beslutningen
Læs fejlene, før du beslutter dig, ikke kun scoren. Sortér dem efter type: selvsikre forkerte svar, korrekte afvisninger, oversprungne trin, forkert brug af værktøjer, timeouts. En agent, der fejler ved at bede om hjælp, er langt lettere at sætte i drift end en, der fejler i stilhed med et troværdigt svar.
Beslut dig så. Skalér, hvis kriterierne er opfyldt på evalueringssættet, og de resterende fejl er nogle, din proces kan håndtere. Indskrænk omfanget, hvis agenten kun klarer sig godt på en del af opgaven. Stop, hvis den ikke slår udgangspunktet, og gem evalueringssættet til næste forsøg. Vores AI-agentprojekter følger samme rækkefølge: én opgave, rigtige eksempler, gennemgang ved dit team og større omfang, først når agenten har gjort sig fortjent til tillid. Har du en PoC, der skal vurderes, kan du beskrive den via vores formular til at starte et projekt.
Det vigtigste
- Skriv succeskriterier og et udgangspunkt ned, før agenten bygges, så resultatet kan vurderes ærligt.
- Test på et fast sæt rigtige sager, også svære og tvetydige, og kør det igen efter hver ændring.
- Mål omkostning pr. opgave og latens ved den forventede volumen, og se på de værste tilfælde såvel som gennemsnittet.
- Design den menneskelige gennemgang bevidst, og mål, hvor lang tid den tager, og hvad den fanger.
- Fastlæg grænser for data, værktøjer og logning, før du skalerer, for prompt injection og »excessive agency« er kendte risici.
FAQ
Hvor mange sager skal et evalueringssæt for en AI-agent have?
Der er ikke et fast tal. Det skal have sager nok til at dække opgavens vigtigste variationer, de svære og tvetydige og dem, agenten bør afvise. Start med det, du kan mærke omhyggeligt op, og tilføj hver rigtig fejl, du finder senere.
Kan en anden model bedømme agentens output?
Ja, for fritekst, der er svær at kontrollere automatisk, men først når du har sammenlignet dens vurderinger med et menneskes på en stikprøve af sager. Tjek den overensstemmelse igen, hver gang du skifter model eller prompt.
Hvornår bør vi stoppe en PoC for en AI-agent?
Når den ikke slår den nuværende måde at løse opgaven på ud fra dine succeskriterier, eller når den gennemgang, den kræver, koster lige så meget tid, som den sparer. Et klart stop er et nyttigt resultat: gem evalueringssættet, for en nyere model eller en snævrere opgave kan bestå det senere.