Bedöm en proof of concept (PoC) för en AI-agent mot kriterier för framgång som skrevs innan den byggdes, på en fast uppsättning verkliga fall där de svåra ingår. Mät träffsäkerhet, kostnad per uppgift och svarstid, kontrollera vilka data och verktyg den når och hur den fallerar, och skala upp först när resultaten håller även utanför demon.
En övertygande demo är inget bevis
En demo visar en AI-agent från sin bästa sida, eftersom den körs på exempel som utvecklarna har valt och övat på. Frågan inför en uppskalning är en annan: hur ofta gör agenten verkligt arbete rätt, vad kostar varje uppgift och vad händer de dagar den gör fel?
Behandla din proof of concept som ett experiment som slutar i ett beslut: skala upp, ändra eller stoppa. Beslutet kräver kriterier som skrivs innan resultaten kommer in; annars kan nästan vilket resultat som helst tolkas som lovande.
Skriv kriterierna för framgång innan agenten byggs
Definiera vad tillräckligt bra betyder för verksamheten och gör sedan om det till siffror som går att mäta. För en agent som sorterar supportärenden kan det vara andelen ärenden som går till rätt team, andelen som den med rätta avböjer att hantera och den tid en person lägger på att kontrollera varje ärende.
- Andel lyckade uppgifter på realistiska fall, med en skriftlig definition av ett korrekt resultat
- De fel du kan acceptera och de du inte kan acceptera, till exempel ett felaktigt svar som skickas till en kund
- Kostnad per slutförd uppgift, inklusive modellanvändning och tiden för den person som kontrollerar arbetet
- En svarstid som passar arbetsflödet, beroende på om någon väntar på svaret
- Utgångsläget: hur lång tid uppgiften tar för människor i dag, och hur ofta de gör rätt
Testa på en fast uppsättning testfall byggd av verkliga fall
Samla verkliga indata ur din egen historik, anteckna rätt utfall för vart och ett och håll uppsättningen oförändrad. Ta med enkla fall, tvetydiga fall, sällsynta fall och några som agenten borde avböja. En mindre uppsättning väl valda fall säger mer än en stor uppsättning enkla fall.
Kör agenten på hela uppsättningen varje gång prompten, modellen, verktygen eller data ändras, och jämför resultaten med föregående körning. Modellernas svar varierar mellan körningar, så kör varje fall mer än en gång och titta på hur konsekvent resultatet är, inte bara på det bästa svaret. Håll fallen utanför prompten och utanför alla exempel som agenten ser, annars blir resultatet för smickrande.
Kontrollera också hur du poängsätter. Automatiska kontroller fungerar för strukturerade svar. Fritext kräver oftast en människa, eller en andra modell vars bedömningar du har jämfört med en människas på ett urval.
Mät kostnad och svarstid vid den volym du räknar med
En proof of concept som hanterar några dussin förfrågningar om dagen kan dölja kostnader som spelar roll vid flera tusen. Registrera modellanrop, tokens och verktygsanrop per uppgift och den tid varje uppgift tar. Agenter som loopar, gör nya försök eller läser långa dokument kan kosta långt mer än genomsnittet på vissa indata, så studera de långsammaste och dyraste fallen, inte bara medelvärdet.
Räkna sedan fram kostnaden vid den volym du räknar med och jämför med vad arbetet kostar i dag, inklusive den tid människor fortfarande kommer att lägga på granskning. Sätt hårda gränser per uppgift för antal steg, tokens och tid, så att en enda dålig indata inte kan dra på sig en stor faktura. OWASP Top 10 for LLM Applications tar upp den här risken som obegränsad förbrukning (unbounded consumption).
Utforma den mänskliga granskningen medvetet och mät den sedan
Mänsklig granskning är en del av designen, inte ett tillfälligt skyddsnät. Bestäm vilka åtgärder agenten får vidta på egen hand, vilka den bara får föreslå och vilka den aldrig får vidta. Allt som inte går att ångra eller som syns för kunderna, som att skicka ett meddelande, ändra en post eller spendera pengar, bör vänta på en människas godkännande tills agenten har visat vad den klarar under lång tid.
Mät själva granskningen: hur lång tid den tar, hur ofta granskarna ändrar resultatet och hur ofta de godkänner utan att egentligen kontrollera. Om granskningen tar nästan lika lång tid som att göra uppgiften sparar agenten inte tid än. Om ditt användningsfall kan räknas som högrisk enligt EU:s AI-förordning är effektiv mänsklig tillsyn ett lagkrav enligt artikel 14, inte ett designval, så involvera dina juridiska rådgivare tidigt.
Sätt gränser för data och säkerhet innan du skalar upp
Uppskalning innebär mer data, fler användare och fler verktyg, och det är då svaga gränser börjar spela roll. OWASP Top 10 for LLM Applications rankar prompt injection först: text som agenten läser, som ett mejl, ett ärende eller en webbsida, kan innehålla instruktioner som styr om den. Listan tar också upp överdriven handlingsfrihet (excessive agency), det vill säga fler funktioner, behörigheter eller mer självständighet än uppgiften kräver. Reda ut de här punkterna innan piloten växer.
- Vilka data agenten kan läsa, och om personuppgifter eller konfidentiella data skickas till en modellleverantör, under vilka avtals- och lagringsvillkor
- Vilka verktyg den kan anropa, med snävast möjliga behörigheter och egna inloggningsuppgifter för varje agent
- Vad den kan ändra, och om varje ändring går att spåra och ångra
- Vad som loggas: varje verktygsanrop med indata och utdata, utan att personuppgifter läcker
- Hur varje kunds eller teams data hålls åtskilda från de andras
Studera hur den fallerar och fatta sedan beslutet
Läs felen innan du bestämmer dig, inte bara poängen. Sortera dem efter typ: säkra men felaktiga svar, korrekta avböjanden, missade steg, fel verktygsanvändning, timeouter. En agent som fallerar genom att be om hjälp är mycket lättare att ta i drift än en som fallerar tyst med ett rimligt klingande svar.
Fatta sedan beslutet. Skala upp om kriterierna uppfylls på testuppsättningen och de fel som återstår är sådana som din process kan hantera. Smalna av uppdraget om agenten bara klarar en del av uppgiften bra. Stoppa om den inte slår utgångsläget, och spara testuppsättningen till nästa försök. Våra projekt med AI-agenter följer samma ordning: en uppgift, verkliga exempel, granskning av ditt team och större uppdrag först när agenten har förtjänat förtroende. Om du har en proof of concept som ska bedömas kan du beskriva den via vårt formulär ”Starta ett projekt”.
Det viktigaste
- Skriv kriterier för framgång och ett utgångsläge innan agenten byggs, så att resultatet kan bedömas ärligt.
- Testa på en fast uppsättning verkliga fall, även svåra och tvetydiga, och kör den igen efter varje ändring.
- Mät kostnad per uppgift och svarstid vid den volym du räknar med, och titta på de sämsta fallen och inte bara genomsnittet.
- Utforma den mänskliga granskningen medvetet och mät hur lång tid den tar och vad den fångar.
- Sätt gränser för data, verktyg och loggning innan du skalar upp, eftersom prompt injection och överdriven handlingsfrihet är kända risker.
Vanliga frågor
Hur många fall behöver en testuppsättning för en AI-agent?
Det finns inget fast antal. Den behöver tillräckligt många fall för att täcka uppgiftens viktigaste varianter, de svåra och tvetydiga fallen och dem som agenten borde avböja. Börja med det du kan märka upp noggrant och lägg till varje verkligt fel du hittar senare.
Kan en annan modell poängsätta agentens svar?
Ja, för fritextsvar som är svåra att kontrollera automatiskt, men först när du har jämfört dess bedömningar med en människas på ett urval av fall. Kontrollera överensstämmelsen igen varje gång du byter modell eller ändrar prompten.
När ska vi avbryta en proof of concept för en AI-agent?
När den inte slår det nuvarande sättet att utföra uppgiften enligt dina kriterier för framgång, eller när granskningen den kräver tar lika mycket tid som den sparar. Ett tydligt stopp är ett användbart resultat: spara testuppsättningen, eftersom en nyare modell eller en snävare uppgift kan klara den senare.