Ett lyckat agenttest räcker inte – mät utfallet och upprepningen

För att utvärdera en AI-agent före produktion behöver teamet ge den definierade uppgifter i en återställbar miljö och kontrollera sluttillståndet efter varje försök. Kör samma uppgift flera gånger: ett lyckat försök visar att agenten kan klara den, men inte hur konsekvent den gör det.

Varje testfall behöver ett förväntat utfall, förbjudna sidoeffekter och en tydlig regel för godkänt eller underkänt. Spara även agentens spår, svarstid och kostnad per försök. Då går det att skilja ett felaktigt resultat från ett problem i arbetsgången och upptäcka försämringar efter en ändring.

Beskriv uppgiften som ett kontrollerbart sluttillstånd

I Anthropics genomgång av agentutvärderingar skiljs spåret, alltså hela förloppet, från utfallet i miljön: en bokningsagent kan säga att en flygresa är bokad trots att ingen reservation finns i databasen. Det gör miljöns faktiska tillstånd till den viktigaste kontrollen för uppgifter där agenten ska ändra något.

Skriv ned användarens begäran, miljöns startläge, vilka verktyg agenten får använda och vilket tillstånd som ska finnas när den är klar. Ange samtidigt otillåtna ändringar. I ett hypotetiskt bokningstest kan godkänt kräva exakt en reservation med rätt resenär och avgång, medan en dubbelbokning eller en ändring av en annan resenärs uppgifter underkänns även om svaret till användaren låter korrekt.

Kontrollera att uppgiften går att lösa enligt de regler agenten får se. En referenslösning som klarar bedömningen avslöjar om testet kräver dold information eller ett visst arbetssätt som inte framgår av begäran. Annars kan ett underkänt resultat bero på testets utformning i stället för på agenten.

Ge varje försök samma startläge

En upprepning är svår att tolka om nästa försök ärver den föregående körningens reservationer, cache eller verktygssvar. Återställ databasen före varje start eller ge försöken separata kopior av testmiljön. Lås också de uppgifter agenten får läsa, exempelvis tillgängliga avgångar och bokningsregler, när syftet är att jämföra agentens beteende.

Spara versionerna av modell, instruktioner, verktyg och testdata tillsammans med varje körnings identifierare. Ett styrt svar från ett externt verktyg gör agentens beslut lättare att jämföra mellan körningar; integrationen mot det verkliga verktyget behöver då ett eget test. Den uppdelningen gör det möjligt att se om en avvikelse kommer från agenten, testmiljön eller ett ändrat verktygssvar.

En startsvit med fem skilda felrisker

Följande fem fall är en redaktionell mall för en hypotetisk flygbokningsagent, inte ett påstående om en befintlig tjänst. Varje fall ska bedömas både mot reservationernas sluttillstånd och mot beskedet till användaren. Byt ut bokningsdetaljerna mot motsvarande risker i det arbetsflöde som faktiskt ska testas.

1. Fullständig begäran: Resenären lämnar alla uppgifter som bokningssystemet kräver och väljer en tillgänglig avgång. Godkänt kräver en korrekt reservation och ett svar som beskriver just den reservationen.
2. Saknad uppgift: En uppgift som systemet kräver utelämnas. Agenten ska be om den innan den försöker boka; ingen reservation får skapas i väntan på svaret.
3. Avvisat verktygsanrop: Den valda avgången blir otillgänglig innan bokningen slutförs. Agenten ska hantera avvisningen och får inte påstå att en reservation har skapats.
4. Motstridiga datum: Resenären anger olika resdatum i två meddelanden. Agenten ska reda ut vilket datum som gäller innan den ändrar bokningssystemets tillstånd.
5. Upprepad begäran: Samma begäran kommer igen efter ett avbrutet svar. Kontrollera att arbetsflödet inte skapar dubbla reservationer och att agentens besked stämmer med det faktiska läget.

För varje fall bör en person som känner arbetsflödet kunna ange ett godkänt sluttillstånd och ett tydligt exempel på underkänt. Om två granskare rimligen kan ge olika besked om samma resultat behöver uppgiften eller bedömningsregeln preciseras. Lägg särskild vikt vid sidoeffekter som är svåra att rätta i produktion.

Bedöm resultatet och använd spåret för att hitta felet

OpenAI:s vägledning för agentarbetsflöden rekommenderar spårbedömning vid felsökning och återanvändbara dataset med utvärderingskörningar för jämförelser över tid. Ett spår kan visa modellanrop, verktygsanrop och överlämningar. Det hjälper teamet att hitta var ett försök gick fel, medan kontrollen av sluttillståndet avgör om uppgiften blev utförd.

Låt kod bedöma sådant som kan fastställas exakt: antal skapade reservationer, fältvärden och frånvaro av otillåtna ändringar. För öppnare frågor, som om ett misslyckande förklarades begripligt, behövs en konkret bedömningsmall. Låt en människa granska ett urval av dessa bedömningar och fall där en giltig lösning verkar ha underkänts.

Håll hårda krav åtskilda från kvalitetsmått. En dubbelbokning underkänner försöket även om svaret är välformulerat. Antalet verktygsanrop kan däremot vara ett diagnostiskt mått: olika vägar kan ge samma korrekta utfall, men en ökning kan visa var kostnad eller fördröjning uppstår.

Upprepa fallen och bygg ett regressionspaket

Som praktisk startregel kan vart och ett av de fem fallen köras minst fem gånger från samma rena startläge. Det ger minst 25 försök och gör variation synlig, men antalet är en arbetsregel snarare än en statistisk garanti för driftsäkerhet. Redovisa godkända försök per fall och markera förbjudna sidoeffekter separat; ett samlat genomsnitt kan dölja ett allvarligt fel i ett enskilt arbetsflöde.

Mät tiden från start till slutligt svar och kostnaden för modell- och verktygsanvändning per försök. Redovisa kostnaden för automatisk bedömning separat så att den inte förväxlas med kostnaden för att utföra användarens uppgift. Spara både typisk svarstid och avvikande långsamma försök; vid en liten startsvit är de enskilda körningarna mer informativa än ett ensamt sammanfattande tal.

Det körbara regressionspaketet består av versionsmärkta testfall, en rutin som återställer miljön, sparade spår och mått samt bedömare som lämnar ett resultat för varje försök. Kör paketet efter ändringar i modell, instruktioner, verktyg eller dataformat och jämför med samma baslinje. När ett verkligt fel hittas kan dess startläge och kontrollerbara sluttillstånd bli ett nytt testfall i sviten.