U kunt een AI agent niet testen zoals gewone code. Het grootste deel van de workflow wel.

Vraag een ontwikkelaar hoe hij controleert of zijn code werkt, en hij verwijst naar de tests. Dezelfde invoer levert steeds dezelfde uitvoer op. Een test die gisteren slaagde, slaagt vandaag ook. Mislukt de test, dan is er iets veranderd.

Zet nu een taalmodel in het midden van die workflow. Geef het dezelfde invoer en het antwoord verschilt bij elke run een beetje. De formulering verandert, net als de volgorde. Soms is het antwoord beter, soms slechter. Een test die de uitvoer woordelijk vergelijkt, mislukt dan zonder dat er daadwerkelijk iets mis hoeft te zijn. Al snel vertrouwt het team de test niet meer en voert het die uiteindelijk helemaal niet meer uit.

Dat is een reëel probleem, maar het is kleiner dan het lijkt. Het model is niet deterministisch. Het grootste deel van de workflow is dat wel.

Eén team wilde gewone unittests schrijven voor de workflow van zijn agent. Uit de documentatie van hun framework bleek hoe ze de ene manier om een workflow te bouwen konden testen, maar niet de andere. De opslag waarin de bewaarde status van een run stond, werd al vastgelegd toen de code werd geladen. Daardoor konden ze die opslag in hun tests niet vervangen door een testversie. Ze bouwden wrappers en globale schakelaars om dit probleem te omzeilen. Zelf noemden ze die oplossingen hacks. Sommige daarvan zorgden er bovendien voor dat tests mislukten wanneer ze parallel werden uitgevoerd.

Let op wat ze eigenlijk wilden testen. Niet de tekst die het model schreef, maar de onderliggende logica: wordt de status opgeslagen, krijgt een stap de juiste invoer en volgt de run de juiste route? Dat deel zou eenvoudig te testen moeten zijn. Is dat niet zo, dan zit de tool in de weg, niet het model.

Bent u nog niet bekend met agents, lees dan eerst wat een AI agent is. Kort gezegd: een model neemt beslissingen, tools voeren acties uit en een workflow verbindt de verschillende stappen.

Verdeel de onderdelen van één run in twee groepen.

Vaste onderdelen. Deze gedragen zich bij dezelfde invoer elke keer op dezelfde manier.

Tool-aanroepen. Als een stap een tool met bepaalde argumenten aanroept, kunt u het verwachte gedrag van die tool testen. Gebruik daarvoor testgegevens of eerder vastgelegde gegevens. Uitvoerstructuren. Een stap moet bepaalde velden van bepaalde typen teruggeven. Een lijst met resultaten mag bijvoorbeeld niet leeg zijn. Routering. Ligt een waarde boven een bepaalde grens, dan gaat de run naar vertakking A. Zo niet, dan gaat de run naar vertakking B. Dit is gewone logica. Gegevensverwerking. Denk aan gegevens parseren, omzetten, de status opslaan en die later weer inlezen. Modelafhankelijke onderdelen. Deze kunnen per run verschillen.

De tekst die het model genereert. De tool die het model kiest, als het meerdere opties heeft. De manier waarop het model informatie samenvat, rangschikt of indeelt. In veel workflows vormen de vaste onderdelen het grootste deel van de code. Test deze zoals u gewone code test, met exacte controles. Voor de modelafhankelijke onderdelen hebt u een andere aanpak nodig.

Vraag bij uitvoer van het model niet langer: 'Is dit precies dezelfde tekst als de vorige keer?' Vraag in plaats daarvan: 'Voldoet dit aan de criteria?' Leg die criteria vast voordat u de tests uitvoert.

Goede criteria zijn concreet. U moet elk criterium met ja of nee kunnen beantwoorden:

Het antwoord vermeldt het ordernummer van de klant. De samenvatting telt minder dan 120 woorden. Het label komt uit een lijst met vijf toegestane labels. Het antwoord belooft geen terugbetaling. Elke bewering in het antwoord wordt ondersteund door de brondocumenten. Sommige criteria kunt u met een paar regels code controleren. Voor anderen hebt u een mens nodig, of een tweede model dat als beoordelaar optreedt. Zo'n tweede model kan nuttig zijn, maar is zelf ook niet deterministisch. Beschouw het oordeel daarom als een aanwijzing, niet als bewijs. Controleer een steekproef van die oordelen handmatig.

Voer elk testgeval vervolgens meerdere keren uit in plaats van slechts één keer. Eén geslaagde run zegt weinig. Als een testgeval bijna altijd slaagt, levert dat bruikbare informatie op. Slaagt het maar in de helft van de gevallen, dan ontdekt u een zwakke plek voordat uw gebruikers die tegenkomen.

Hier zit de spanning. Voor de modelafhankelijke onderdelen krijgt u nooit dezelfde zekerheid als met een gewone testsuite. Een verzameling van vijftig testgevallen dekt niet alle invoer die echte gebruikers kunnen aanleveren. En dat een test vandaag slaagt, betekent niet dat hij ook slaagt nadat de modelleverancier het model heeft bijgewerkt.

Testen vóór de release is daarom niet voldoende. Ook na de release moet u echte runs bekijken en vergelijken wat er daadwerkelijk gebeurde met wat u verwachtte. Een run die met een groen vinkje eindigt, kan het verkeerde werk hebben uitgevoerd — daarover schreven we in een groen vinkje betekent niet dat de taak is afgerond. Tests vangen de fouten op die u vooraf kunt bedenken. Door echte runs te controleren, ontdekt u ook de fouten waar u niet aan had gedacht.

Dat is geen reden om tests over te slaan. Het is een reden om eerlijk te zijn over wat ze aantonen.

Elke laag vraagt om een eigen soort test en een eigen moment waarop u die uitvoert. Begin bovenaan. De eerste rijen kosten nauwelijks tijd en helpen veel fouten op te sporen die anders onopgemerkt blijven.

Wat u test	Hoe u het test	Wanneer het draait
De uitvoerstructuur van elke stap	Leg de vereiste velden, typen en toegestane waarden vast. Laat de stap mislukken als de uitvoer niet aan deze structuur voldoet.	Bij elke wijziging
Uw tools	Test elke tool afzonderlijk met testgegevens of eerder vastgelegde gegevens. Er is geen model nodig, dus de controles zijn snel en exact.	Bij elke wijziging
De routering	Vervang het model door een stub, een vervanger die altijd hetzelfde antwoord geeft. Gebruik vaste invoer voor elke vertakking en controleer welke route de run volgt.	Bij elke wijziging
De uitvoer van het model	Gebruik een kleine verzameling echte testgevallen met vooraf vastgelegde criteria. Twintig goede testgevallen zijn nuttiger dan tweehonderd vage. Voer elk geval meerdere keren uit en houd bij hoe vaak het slaagt.	Vóór elke release en na elke wijziging van het model
Echte runs	Vergelijk wat er gebeurde met wat u verwachtte. Als een echte run mislukt, voeg die dan toe als nieuw geval.	Doorlopend, na de release

Neem de goedkope tests op in CI, zodat ze automatisch worden uitgevoerd zonder dat iemand ze handmatig hoeft te starten.

In EpicStaff kunt u voor een stap een gestructureerde uitvoer definiëren. U bepaalt de structuur van het resultaat en de stap moet die structuur teruggeven. Lukt dat niet, dan mislukt de stap in plaats van dat deze als geslaagd wordt aangemerkt.

U kunt een volledige flow uitvoeren met uw eigen testinvoer en een Python-stap afzonderlijk testen. Een script of CI-job kan via de API met een API-sleutel een run van een flow starten.

EpicStaff heeft geen ingebouwde test- of evaluatiefunctie. Houd daarom uw eigen verzameling testinvoer en vooraf vastgelegde criteria bij. Laat vóór elke wijziging de volledige flow via de API uitvoeren.