Hur utvärderar man en AI-agent? Uppgifter, förlopp, tillförlitlighet och kostnad

Att utvärdera en AI-agent innebär att testa om den på ett tillförlitligt sätt kan utföra representativa uppgifter, följa godtagbara tillvägagångssätt, hålla sig inom sina befogenheter och skapa tillräckligt stort värde i förhållande till kostnaden. Ett slutligt svar räcker inte, eftersom en agent kan nå ett rimligt resultat genom osäkra handlingar, påståenden utan stöd, överdrivet många omförsök eller ren tur.

Det är svårt att utvärdera agenter eftersom systemet agerar över tid. Modellen väljer verktyg, observerar miljöer som förändras och kan ta olika vägar vid varje körning. Effektiva utvärderingar mäter därför både resultat och förlopp vid upprepade försök.

Terminologin för utvärdering av agenter

Anthropics guide till att reda ut hur utvärdering av agenter fungerar innehåller en användbar uppsättning termer:

• Uppgift: ett testfall med ett mål, en miljö, indata och kriterier för godkänt resultat.
• Försök: ett försök av agenten att slutföra en uppgift.
• Transkript eller förlopp: följden av meddelanden, beslut, verktygsanrop, observationer och handlingar under försöket.
• Bedömare: en regel, ett program, en modell eller en person som poängsätter en del av prestationen.
• Utvärderingsramverk: systemet som förbereder miljöer, kör försök, samlar in spår, anropar bedömare och rapporterar resultat.

Om man håller isär begreppen undviker man ett vanligt misstag: att tolka en lyckad demonstration som bevis för att agenten kommer att prestera tillförlitligt.

Börja med en tydlig specifikation av uppgiften

En användbar utvärderingsuppgift beskriver utgångsläget, tillgängliga verktyg, begränsningar, förväntat resultat och viktiga förbjudna handlingar. Testet bör likna verkligt arbete utan att avslöja en enda förutbestämd väg.

För en supportagent är ”lös ärendet” för vagt. En bättre uppgift anger kundens uppgifter, vilken policy som gäller, vilka åtgärder som är tillåtna, vilken kommunikation som krävs och vilka ändringar som måste synas i det officiella systemet. Då går resultatet att bedöma objektivt.

Fyra lager i utvärderingen av en agent

De här lagren bör hållas åtskilda i rapporteringen. Om de slås ihop till ett enda genomsnitt kan oacceptabelt beteende döljas – till exempel ett högt resultat för uppgiftslösning som maskerar återkommande obehöriga verktygsförsök. Team kan först fastställa bindande säkerhetskrav och sedan jämföra kvaliteten på resultaten och effektiviteten mellan de körningar som uppfyller kraven.

1. Resultatets kvalitet

Uppnådde agenten målet? Bedömare av resultat kan kontrollera exakta tillståndsändringar, obligatoriska fält, testresultat, faktamässig korrekthet, stöd i källhänvisningar eller kvalitet utifrån en bedömningsmatris.

Använd om möjligt miljöns slutliga tillstånd i stället för agentens eget påstående. En kodningsagent har inte lyckats bara för att den säger att felet är åtgärdat; relevanta tester och programmets beteende måste bekräfta det.

2. Förloppets kvalitet

Tog agenten en lämplig väg? Utvärdering av förloppet kan upptäcka onödig åtkomst till data, förbjudna verktyg, upprepade misslyckanden, utebliven verifiering, påhittade observationer eller överträdelser av godkännandekrav.

Alla avvikelser från en referensväg är inte fel. Agenter kan hitta giltiga lösningar som utvärderarna inte förutsåg. Bedömare bör upprätthålla verkliga krav, men samtidigt tillåta alternativa och effektiva tillvägagångssätt.

3. Säkerhet och efterlevnad av policy

Höll sig agenten inom sina befogenheter? Testerna bör omfatta promptinjektioner, motstridiga instruktioner, känsliga uppgifter, otydliga användaravsikter och förfrågningar som kräver avslag eller eskalering.

Säkerhetsutvärderingar behöver realistiska konsekvenser i en sandlådemiljö. Det räcker inte med en mening som följer policyn om agenten redan har skickat meddelandet, ändrat uppgifterna eller röjt informationen.

4. Operativ effektivitet

Hur mycket tid och pengar krävdes för att lyckas? Följ upp modellens tokenförbrukning, verktygsanrop, total svarstid, omförsök, mänskliga ingripanden och kostnader för externa tjänster. En agent som lyckas efter 100 onödiga handlingar kan vara mindre användbar än ett enklare arbetsflöde.

Använd flera typer av bedömare

Deterministiska bedömare kontrollerar exakta egenskaper: om ett test har godkänts, om en fil har ändrats korrekt, om ett databasfält har det värde som krävs eller om en förbjuden slutpunkt har anropats. De är snabba och konsekventa, men täcker bara sådant som utvecklarna har kodat in.

Modellbaserade bedömare utvärderar egenskaper som tydlighet, fullständighet, relevans och efterlevnad av nyanserade kriterier. De går lättare att skala upp än mänsklig granskning, men behöver valideras separat eftersom de kan vara partiska eller inkonsekventa.

Mänskliga bedömare är viktiga när det krävs expertbedömningar, vid tvetydiga fall och för att validera automatiserade bedömare. De arbetar långsammare och kostar mer, så team använder dem ofta för stickprov, oenigheter och områden med stor påverkan.

De mest robusta utvärderingspaketen kombinerar dessa metoder. OpenAI:s utvärderingsplattform Evals ser på liknande sätt utvärdering som en strukturerad process för att definiera tester och bedömare samt genomföra upprepade experiment, snarare än som en informell granskning.

Tillförlitlighet kräver upprepade försök

Kör varje uppgift tillräckligt många gånger för att se variationen som beror på sampling, förändrade verktyg och miljötillstånd. Redovisa både genomsnittliga resultat och hur ofta allvarliga fel inträffar. I arbetsflöden med flera beroende steg kan träffsäkerheten för varje enskilt steg verka hög, samtidigt som tillförlitligheten från början till slut är låg, eftersom ett enda fel kan få hela uppgiften att gå om intet.

Agenters beteende är probabilistiskt. Samma uppgift kan leda till olika planer, verktygsanrop och resultat. Kör varje viktig uppgift flera gånger och redovisa andelen godkända försök eller poängfördelningar, inte bara det bästa exemplet.

Två tillförlitlighetsmått besvarar olika frågor:

• Pass@k: sannolikheten att minst ett av k försök lyckas. Måttet är användbart när flera försök är acceptabla.
• Pass^k: sannolikheten att alla k försök lyckas. Måttet speglar konsekvens när varje körning måste fungera.

Ett system kan ha ett tilltalande pass@k-värde och ändå vara olämpligt för automatisk drift, eftersom enskilda körningar är otillförlitliga.

Skapa en representativ uppsättning uppgifter

Börja med verkliga fel och vanliga produktionsförfrågningar. Ta med enkla uppgifter, svåra specialfall, tvetydiga indata, verktygsfel, inaktuella data, saknad information och adversariellt innehåll.

Dela upp resultaten efter uppgiftstyp och risk. Ett övergripande genomsnitt kan dölja en allvarlig svaghet vid finansiella åtgärder, uppgifter med lång tidshorisont eller i en viss applikation. Behåll en separat testmängd så att upprepad justering av promptar inte gör utvärderingspaketet till en träningsmängd.

Utvärdera miljön, inte bara modellen

En agents resultat beror på verktygsdefinitioner, behörigheter, minne, kontexthantering, användargränssnitt, nätverksbeteende och orkestrering. En modelluppgradering kan minska ett fel men samtidigt blottlägga ett annat.

Versionshantera hela den stack som används för varje körning. Dokumentera modellen, promptarna, verktygen, dataögonblicksbilden, miljön, budgetarna och bedömarversionerna. Annars går det inte att härleda en förändring i poäng till en meningsfull orsak.

Vanliga misstag vid utvärdering

Dataläckage är en annan risk. Om benchmarkuppgifter, förväntade svar eller bedömningsmönster förekommer i modellens träningsdata eller promptkontext kan poängen mäta igenkänning i stället för generaliseringsförmåga. Behåll privata uppgifter som inte används i utvärderingen, uppdatera testfallen när systemen förändras och dokumentera exakt vilken modell, prompt, verktygsversioner och miljö som används vid varje körning.

• Demodriven utvärdering: att välja uppgifter efter att ha sett vad agenten är bra på.
• Poängsättning som bara utgår från slutsvaret: att ignorera osäkra eller slösaktiga handlingsförlopp.
• Slutsatser baserade på en enda körning: att behandla en lyckosam engångshändelse som en stabil förmåga.
• Läckande tester: att lägga svaret eller referensförloppet i agentens kontext.
• Modellbaserade bedömare som inte validerats: att anta att en automatiserad bedömare har rätt utan att kontrollera om den är överens med experter.
• Statiska miljöer: att bara testa ett gränssnitt, ett kontotillstånd eller en datauppsättning.
• Inga negativa tester: att mäta om uppgiften slutförs utan att kontrollera om agenten avböjer eller eskalerar på lämpligt sätt.
• Ekonomin ignoreras: att optimera framgång samtidigt som kostnader och latens blir oacceptabla.

Från offlineutvärderingar till produktionsövervakning

Offlineutvärderingar är kontrollerade och upprepningsbara. De lämpar sig väl för att jämföra prompter, modeller, verktyg och policyer före lansering. Produktionsövervakning visar den stora variationen i faktiskt användarbeteende och förändringar i miljön.

Ett moget program kopplar samman de två. Incidenter och produktionsspår med låg konfidens blir nya offlineuppgifter. Kandidatändringar måste klara regressionssviten. Efter driftsättning följer teamen upp hur ofta uppgifter slutförs, ingripandefrekvens, policyhändelser, verktygsfel, kostnader, latens och användarfeedback.

Ett praktiskt poängkort för agenter

Ett poängkort bör skilja mellan absoluta krav och optimeringsmått. Efterlevnad av policy, behörighet och obligatoriska belägg kan vara godkänd/underkänd-krav; därefter kan noggrannhet, latens, kostnader och granskarinsats jämföras mellan godtagbara körningar. På så sätt undviker man att team byter en liten effektivitetsvinst mot en försämring av säkerheten som annars skulle döljas av ett medelvärde.

Ett användbart poängkort kan innehålla:

• andel lyckade uppgifter och kvalitetsbetyg;
• konsekvens mellan upprepade försök;
• frekvens av allvarliga policyöverträdelser;
• träffsäkerhet vid val av verktyg och argument;
• återhämtningsgrad efter fel i verktyg eller miljö;
• frekvens av eskalering till människor och manuella åsidosättanden;
• median- och svanslatens;
• kostnad för modell, verktyg och mänskligt arbete per lyckad uppgift;
• förloppets effektivitet jämfört med en rimlig baslinje.

Redovisa kostnaden per lyckad uppgift, inte bara kostnaden per körning. En billig agent som misslyckas upprepade gånger kan bli dyrare än en kraftfullare modell som lyckas på första försöket.

Viktiga saker att komma ihåg när du utvärderar en AI-agent

Utvärdering av agenter handlar om att testa ett komplett, målstyrt system under realistiska förhållanden. Man mäter om arbetet är korrekt, om tillvägagångssättet är godtagbart, om beteendet går att upprepa och om ekonomin är rimlig.

Börja med ett litet urval uppgifter med betydande konsekvenser, flera försök, bedömare på olika nivåer och fullständiga handlingsförlopp. Gör sedan varje betydelsefullt produktionsfel till ett regressionstest. Agenters förmåga förändras snabbt; ett hållbart utvärderingssystem hjälper team att skilja verkliga framsteg från en övertygande demo.