Hur testar man en AI-agent innan den får arbeta på riktigt?

Att prova en gång räcker inte

En agent som svarade rätt på tre exempel i en demo kan svara fel på den fjärde. Modellens svar varierar, och verkliga data är rörigare än exempeldata. Därför behöver ni ett sätt att pröva agenten systematiskt, både innan den släpps in och varje gång något ändras. Här är sex steg som fungerar även utan egen testavdelning.

Sex steg

1. Samla verkliga uppgifter

Ta tjugo eller så uppgifter som agenten ska klara, hämtade från vad människor faktiskt ber om. Inkludera både enkla och svåra. Skriv varje uppgift som användaren skulle formulera den, med slarv och förkortningar. En testuppsättning som bara består av välformulerade frågor säger inte hur det går i verkligheten.

2. Skriv ned vad som är ett rätt resultat

För varje uppgift: vad ska agenten göra, vilka verktyg ska den använda och vilken ändring ska hamna var? Ett rätt resultat kan vara att den svarar ”det vet jag inte” eller lägger ett förslag i godkännandekön. Se Hur skriver man en kravspecifikation för en AI-agent?.

3. Kör i en kopia, med läsrätt först

Testa mot en kopia av data eller en testmiljö, aldrig mot produktion. Börja med att bara låta agenten läsa och föreslå. Se Så planerar ni en avgränsad AI-pilot.

4. Pröva det som kan gå fel

Lägg till uppgifter som är byggda för att få agenten att misslyckas:

• Tom eller saknad data. Hittar den på något, eller säger den att det saknas?
• Dubbletter. Två bolag med nästan samma namn. Väljer den rätt, eller frågar den?
• Fel person. En användare med snäv roll ber om något hen inte får. Se Roller och behörigheter för AI-agenter.
• Instruktioner i innehållet. Ett mejl som innehåller en uppmaning till agenten. Se Vad är prompt injection?.
• Samma anrop två gånger. Skapas en dubblett? Se Varför får vi dubbletter när en integration försöker igen?.

5. Kör flera gånger

Kör varje uppgift några gånger. Skiljer sig resultaten åt är det ett tecken på att uppgiften eller verktygsbeskrivningen är för vag, se Hur ser ett bra MCP-verktyg ut?.

6. Spara uppsättningen och kör om vid varje ändring

Ändrar ni en instruktion, ett verktyg eller byter modell, kör hela uppsättningen igen. En rättning som löser ett problem kan skapa ett annat. Varje fel som upptäcks i drift ska läggas till som ett nytt test, se Agenten gjorde fel – hur tar man reda på varför?.

Hur ni bedömer resultatet

• Rätt eller fel, inte ”ganska bra”. Bestäm på förhand vad som godkänns.
• Allvarlighet. Ett felaktigt förslag i kön är något annat än en felaktig ändring som gick igenom direkt. Väg dem olika.
• Mått över tid. Andelen godkända förslag, andelen avslag och orsakerna är ett bra löpande mått. Se Hur ser vi att ett AI-projekt lönat sig?.

Vad ni inte kan testa bort

Ett test visar att agenten klarar det ni tänkt på. Det kan inte visa att den klarar allt. Därför ska skyddet ändå ligga i systemet: behörigheter per person, en kö för ändringar och en logg. Testerna minskar antalet fel, spärrarna begränsar vad ett fel kan göra.

Vill ni ha hjälp att sätta upp en testuppsättning för en agent ni planerar? Hör av er.