Evaluatiecriteria voor agenten die over meerdere stacks werken

Definiëren van een reisgereed beoordelingscriteria

Ik begin met het schrijven van de beoordelingscriteria voordat ik naar de modeluitvoer kijk. De beoordelingscriteria moeten drie onafhankelijke assen bevatten: taaksucces, toolcorrectheid en betrouwbaarheid. Elke as krijgt zijn eigen beoordelingsgids die geen melding maakt van de modelnaam, de frameworkversie of de exacte promptwoorden. Ik bewaar de gidsen in een platte-tekstbestand dat naast de testsuite staat, zodat iedereen ze kan controleren.

Kern eigenschappen

- Vooraf geregistreerde criteria – de succesvoorwaarden worden opgeschreven voordat de eerste run.

- As-isolatie – scores voor één as bloeden nooit over in een andere.

- Taal zonder versie – vermijd zinnen als 'vanaf GPT-4' of 'bij het gebruik van LangChain 0.1'.

Wanneer ik deze eigenschappen volg, geeft dezelfde beoordelingscriteria me vergelijkbare cijfers, of ik de agent nu uitvoer met OpenAI's GPT-4o, Anthropic's Claude 3 of een lokale Llama 3-model.

Waarom taakgeslaagd moet worden gebaseerd op resultaat

Taakgeslaagd beantwoordt de eenvoudige vraag: heeft de agent de taak voltooid? Ik beoordeel dit aan de hand van een checklist die kijkt naar de eindstatus van de wereld, niet naar de formulering van het antwoord. Bijvoorbeeld, als de taak is 'update de e-mailadres van de gebruiker naar alice@example.com', controleer ik het database-record na de uitvoering. Het maakt me niet uit of de agent zei 'Ik heb uw e-mailadres bijgewerkt' of 'Uw e-mailadres is nu alice@example.com'.

Concreet checklist

- Preconditie geverifieerd (bijv. gebruiker bestaat). - Postconditie geverifieerd (bijv. e-mailveld is gelijk aan alice@example.com). - Geen extra neveneffecten (bijv. geen andere velden gewijzigd). - Optioneel: latentie onder een drempel (bijv. 2 seconden).

Ik registreer een binaire score voor elk traject. Als de agent de postconditie niet haalt, is de taakgeslaagd-score nul, ongeacht hoe vloeiend de proza eruit ziet.

Toolcorrectheid als een aparte as

Toolcorrectheid kijkt naar de oproepen die de agent maakt naar externe API's, functies of databases. Ik behandel elke oproep als een mini-experiment: heeft de agent het juiste hulpmiddel gekozen, heeft het de juiste argumenten doorgegeven en heeft het het juiste aantal keren opgeroepen? Ik volg de richtlijnen van de OWASP-kaarten voor veilig hulpmiddelgebruik, zoals de -kaart voor het voorkomen van injectie en de SQL-injectiepreventiekaart om per ongeluk injectie te voorkomen.

Beoordelingsrubriek

- Juist hulpmiddel geselecteerd – 1 punt. - Alle argumenten komen overeen met het schema – 1 punt per argument. - Geen extra oproepen – 1 punt als het oproepaantal gelijk is aan het verwachte. - Geen verboden neveneffecten (bijv. schrijven naar een logboek dat alleen-lezen zou moeten blijven) – 1 punt.

De as-score is de som van de punten gedeeld door het maximum aantal mogelijke punten.

Betrouwbaarheid: elke claim traceren

Betrouwbaarheid vraagt of elke statement in de output van de agent kan worden herleid tot de resultaten van het instrument of de context die aan het model is gegeven. Ik behandel de output als een verzameling claims en controleer elke claim tegen de bewijslast. Als een claim niet kan worden ondersteund, markeer ik deze als een hallucinatie. Deze as is het belangrijkst wanneer de agent documenten samenvat, bronnen citeert of vragen beantwoordt die externe gegevens vereisen.

Stap-voor-stap verificatie

- Deel de output op in atomaire zinnen. - Voor elke zin, maak een lijst van de feiten die deze beweert. - Koppel elk feit aan een regel in de tooloutput of aan een snippet uit de verstrekte context. - Als een feit geen overeenkomst heeft, tel het als een fout. - Betrouwbaarheidsscore = (aantal ondersteunde feiten) / (totaal aantal feiten).

Ik registreer de ruwe tellingen zodat ik kan zien of een daling in betrouwbaarheid voortkomt uit een paar grote hallucinaties of veel kleine fouten.

Wat dit niet is

Ik wil duidelijk zijn over de beperkingen van een reisgereed rubric. Het garandeert niet dat de agent veilig, goedkoop of snel is. Het belooft geen 100 % nauwkeurigheid voor elke mogelijke invoer. Het vervangt geen gedetailleerde beveiligingscontrole, een kostenanalyse of een latentiebenchmark. De rubric meet alleen de drie assen die ik hierboven heb gedefinieerd. Als u moet weten of de agent privésleutels lekt, moet u een aparte geheimenbeheercontrole uitvoeren, bijvoorbeeld met de Secrets Management Cheat Sheet. Als u moet weten of de agent binnen een budget blijft, moet u tokengebruik of API-aanroepkosten buiten deze rubric volgen.

Kortom, de rubric is een instrument voor het vergelijken van agentkwaliteit over stacks heen, geen zilveren kogel voor alle productieproblemen.

Vergelijkbare trajecten opbouwen

Een traject is het volledige logbestand van wat er gebeurt tijdens een run: de initiële prompt, elke toolaanroep met zijn argumenten en resultaten, en de finale modeluitvoer. Ik sla elk traject op als een JSON-object met een vast schema, zodat ik runs automatisch kan vergelijken. Hieronder vindt u een voorbeeld van het schema dat ik gebruik.

Veld | Type | Beschrijving prompt | string | De exacte gebruikers- of systeemprompt die naar het model is verzonden. calls | array | Geordende lijst van tooluitvoeringen. calls[].tool | string | Naam van de tool of API. calls[].args | object | Argumenten die aan de tool zijn doorgegeven. calls[].result | any | Ruwe uitvoer van de tool. output | string | Finale tekst die door het model is geretourneerd. metadata | object | Optionele tags zoals modelnaam, frameworkversie, tijdstempel.

Omdat het schema nooit verandert, kan ik de drie assen scores voor elk traject berekenen met behulp van dezelfde scripts. Ik hou een masterverzameling van trajecten bij die de kernfuncties dekt die ik lever en de gebruikelijke foutmodi die ik heb gezien. Wanneer ik het model wijzig, voer ik de trajecten opnieuw uit en vergelijk ik de nieuwe scores met de basislijn. Het gebruik van tools zoals kan ook worden geïntegreerd in dit proces.

Evaluaties uitvoeren bij elke wijziging

Ik integreer de evaluatiefase in mijn continue-integratiepijplijn. De pijplijn voert de volgende stappen uit bij elke commit die het gedrag kan beïnvloeden:

- Haal de laatste code op. - Installeer de agentafhankelijkheden. - Voer de agent uit tegen de vaste trajectverzameling. - Parseer de logbestanden en bereken de taakgeslaagd-, toolcorrectheid- en betrouwbaarheidsscores. - Publiceer de resultaten op een dashboard en markeer elke as die meer dan vijf procent daalt ten opzichte van de vorige groene build.

Deze praktijk vangt regressies vroeg op. Bijvoorbeeld, toen ik de onderliggende opzoekbibliotheek verwisselde, daalde de toolcorrectheidas van 0,96 naar 0,82 omdat de nieuwe bibliotheek resultaten in een andere volgorde teruggeeft, waardoor de agent extra oproepen maakt. De daling werd zichtbaar in het CI-rapport voordat een gebruiker een probleem opmerkte.

Ik hou ook een door een mens beoordeelde set van twintig trajecten aan. Elke maand beoordeel ik die met een persoon en vergelijk ik het gemiddelde met de automatische scores. Als de automatische rechter afwijkt, kalibreer ik de rubriek opnieuw of train ik het rechtermodel opnieuw.

Operator checklist voor Agent eval rubrics die over stacks reizen

Ik hou een geschreven checklist bij elke release die deze onderwerpen behandelt. De lijst is saai om een reden: noem de eigenaar, noem het bewijsartefact en noem de rollback. Als een stap geen bestand, ticket of logregel kan produceren, is het geen stap - het is een wens.

Voordat u productie wijzigt

- Vries de branch of configuratieversie in die u wilt meten. - Registreer de huidige foutmodus met één concreet invoer- en één concreet uitvoerexemplaar. - Bevestig welke identiteit de job uitvoert en of die identiteit toegang heeft tot gegevens die het niet zou moeten hebben. - Open de primaire referenties die u zal citeren: https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html, https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html.

Terwijl u de controle uitvoert

- Geef de voorkeur aan één reproduceerbare pad over tien anekdotische screenshots. - Schrijf het verwachte veilige resultaat voordat u het hulpmiddel of de query activeert. - Vang de exacte opdracht, prompt, schema of regex onder test - niet een parafrase. - Als het systeem kan handelen (verzenden, schrijven, verwijderen, overdragen), vereis een confirmatiegrens in hetzelfde doorvoeren.

Nadat u klaar bent

- Bestand residual risico met een eigenaar en een datum, zelfs als de scan schoon is. - Converteer geen groene check naar verkooptaal die volledigheid claimt. - Voer dezelfde checklist opnieuw uit wanneer het model, het hulpmiddelschema of de validatieregels veranderen.

Signaal | Wat te registreren | Stop-ship? Onverwachte schrijf- of verzendactie | Hulpmiddelnaam, args, identiteit | Ja totdat het is afgeschermd Ontbrekende confirmatie bij destructieve actie | Oproep-pad en omzeiling | Ja Onbetrouwbaar tekst behandeld als instructie | Bronoppervlak en resulterende actie | Ja voor agentbereik Scanner schoon, oordeel open | Uitgestelde items + eigenaar | Alleen als de kernpad veilig is

agenteval helpt met de meetbare eerste doorvoeren. Architectuurkeuzes, juridische goedkeuring en klantgerichte claims hebben nog steeds een menselijke eigenaar nodig. Behandel elke rij in de checklist als beslissingsondersteuning, niet als certificaat.

Hoe ik limieten uitleg aan kopers

Wanneer een prospect vraagt of het product "alles dekt", antwoord ik met de grens: geautomatiseerde controles vangen bekende patronen; nieuwe ketens en beleidsbeoordeling hebben nog steeds een review nodig. Die eerlijkheid houdt de ondersteuningslast laag en houdt de blog in overeenstemming met wat het product daadwerkelijk doet.

Als u een tweede mening nodig heeft, combineer deze tekst met de onderstaande referenties en met uw eigen reproduktie in een testomgeving. Sla de reproduktiestap niet over alleen omdat een model een zelfverzekerde samenvatting heeft geschreven.

Referenties

- https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html - https://docs.agents-squads.com/guides/config-files

Veelgestelde vragen

Hoeveel testgevallen hebben we nodig?

Genoeg om de taken die je daadwerkelijk verzendt en de manieren waarop ze falen te dekken. Een handvol goed gekozen trajecten is beter dan een grote set eenvoudige gevallen.

Kunnen we outputs beoordelen met een andere model?

Dat kan, maar noteer dat de beoordelaar een model is en houd een vaste steekproef gescoord door mensen aan, zodat je kunt zien of de beoordelaar zelf is afgedwaald.

Wat is concreet gezien trouw?

Of elke claim in de output wordt ondersteund door de toolresultaten of context die de agent heeft gekregen, in plaats van gegenereerd uit de eigen a priori van het model.

Moeten we alleen het eindantwoord beoordelen?

Nee. Beoordeel ook het traject - de toolaanroepen zijn waar de meeste agentfalen ontstaan.

Hoe vaak moeten evaluaties worden uitgevoerd?

Bij elke wijziging die het gedrag kan beïnvloeden: prompt, model, toollijst of opvragingsconfiguratie.

Betekent een goede score dat de agent veilig is?

Nee. Het betekent dat het goed presteerde op de taken die je hebt getest. Beveiliging, kosten en foutafhandeling zijn separate evaluaties.

Referenties

- NIST — AI Risk Management Framework - Stanford CRFM — HELM (Holistic Evaluation of Language Models)

Probeer het product: AgentGrade

2026-09-20 · alleen primaire bronnen · geen gefabriceerde verkeersmetrieken · alleen beslissingsondersteuning

Gerelateerde artikelen

- Offline evaluatie versus online monitoring voor AI-agents - Verken de volledige AI micro-SaaS onderwerpmatrix →