Wat is het probleem met duizenden agent-traces?

Een AI-agent die een dag draait, genereert makkelijk duizenden logs. Elk log bevat modelaanroepen, toolaanroepen, foutmeldingen en reactietijden. Je kunt dashboards instellen voor dingen die je al weet te meten, maar het echte probleem is wat je nog niet weet. Welke fout herhaalt zich elke dag, maar is nooit gedefinieerd als metric? Dat is precies het gat dat automatische Insight-analyse probeert te vullen.

Stel je bouwt een AI-agent die klantmails beantwoordt. Je meet al responstijd en foutpercentage. Maar wat als de agent systematisch bij een bepaald type vraag in een loop belandt? Dat zie je niet in je dashboard, want je hebt die loop nooit als fout gedefinieerd.

Observability (zichtbaarheid op wat er gebeurt) en evaluaties (testen op criteria die je al kent) lossen dit niet op. Ze meten wat je al weet. Het ontdekkingsprobleem is anders: je wilt patronen zien die je nog niet zocht.

Dit is het vertrekpunt van Insights in Microsoft Foundry. De tool analyseert je productie-traces en groepeert terugkerend gedrag automatisch in reviewbare bevindingen. Of dat in de praktijk werkt, lees je in de volgende secties.

Voor wie meer wil weten over hoe AI-agents in elkaar zitten: AI agent tools bouwen zonder vijftien versies bij te houden legt de basis goed uit.

Wat bevat een Insight precies?

Een Insight is geen alert en geen foutmelding. Het is een samengestelde bevinding over terugkerend gedrag. Je krijgt een titel en uitleg, gekoppelde traces als bewijs, ernst en categorie voor prioritering, en een voorstel voor vervolgactie. Concreet: niet ‘er is een fout’, maar ‘deze agent herhaalt bij 80 inputs een extractiestap zonder voortgangscheck, hier zijn drie voorbeeldtraces, overweeg een terminatieconditie toe te voegen’.

Het verschil met een gewone foutmelding is het bewijs. Een Insight laat je niet alleen weten dát er iets mis is, maar ook welke traces het laten zien en hoe vaak het voorkomt. Dat maakt het reviewbaar in plaats van vaag.

Let op de beperkingen. Concrete code- of promptwijzigingen als voorstel zijn alleen beschikbaar voor ondersteunde agent-types en configuraties. Voor andere agents krijg je algemene onderzoeksrichtingen, geen kant-en-klaar antwoord. Dat is eerlijk, want een automatisch systeem dat je code herschrijft zonder context is gevaarlijker dan nuttig.

Het systeem scheidt ernst van impact. Een klein probleem kan prima gecalibreerd zijn op ‘laag’ zonder dat het daarmee niet de moeite waard is om te bekijken. Dat zijn twee aparte dimensies, en vermenging ervan leidt tot slechte prioritering.

Hoe goed werkt het? De benchmarkcijfers op een rij

Microsoft heeft de kwaliteit van Insights getest op zes publieke datasets met gelabelde agent-traces. De resultaten lopen sterk uiteen per dataset. Op datasets met alleen mislukte traces haalt het systeem tot 99,7% recall. Op een gemengde dataset met goede en slechte traces zakt die recall naar gemiddeld 57,5%. Dat laatste getal is het meest eerlijke, want echte productieomgevingen zijn altijd gemengd.

De twee meetwaarden zijn trace recall (welk percentage van de bekende fouten pikt het systeem op?) en trace precision (van alles wat als fout wordt aangemerkt, hoeveel is ook echt een fout?). Op de AgentRx Tau-bench dataset, de enige dataset met een echte mix van goede en slechte traces, was de gemiddelde precision 37,8% en de recall 57,5%. Dat betekent: van elke drie traces die een Insight aanwijst als problematisch, is er gemiddeld iets meer dan één ook echt gelabeld als mislukking.

Is dat goed of slecht? Dat hangt af van je alternatief. Heb je nu helemaal geen geautomatiseerde detectie, dan is 57,5% recall een flinke verbetering. Doorzoek je handmatig elke trace, dan kan een precision van 37,8% frustrerend zijn: je kijkt naar veel ruis.

De scores op de LLM-judge evaluatie (hoe goed zijn de bevindingen zelf?) variëren van 2,84 tot 3,88 op een schaal van 1 tot 5. Dat is solide maar niet uitmuntend. Tau2-bench scoort het laagst met 2,84, wat aangeeft dat sommige Insights te generiek zijn voor bepaalde agent-typen.

Meer over hoe je AI-implementaties eerlijk evalueert lees je in AI implementatie kosten: waar het geld écht heen gaat.

Wat betekent dit als je zelf AI-agents bouwt of inkoopt?

Dit type tooling is pas echt waardevol als je agent al in productie draait met enig volume. Voor een agent die tien keer per dag wordt aangeroepen, heb je geen automatische patroondetectie nodig. Ga je richting honderden of duizenden dagelijkse uitvoeringen, dan is handmatig reviewen onmogelijk. Dan wil je weten welke patronen terugkomen, zonder ze allemaal vooraf te definiëren.

Het eerlijke advies: ga er niet van uit dat een Insight een kant-en-klare oplossing geeft. Het is een startpunt voor onderzoek, geen eindoordeel. De tool zegt zelf ook: valideer voorgestelde wijzigingen via je normale evaluatie- en deploymentproces. Dat is precies de juiste insteek.

Koop je AI-agents in via een bureau of platform? Vraag dan naar monitoring en observability. Niet alleen dashboards voor de metrics die je al kent, maar ook mechanismen om onverwacht gedrag te ontdekken. Zegt een leverancier alleen ‘we monitoren op uptime en responstijd’, dan zie je terugkerende fouten in agent-gedrag pas als een klant erover klaagt.

Bouw je agents op Microsoft Azure? Insights in Foundry is nu in public preview, dus gratis te proberen. Koppel je Application Insights-resource aan je Foundry-project en het systeem analyseert bestaande traces. Je hoeft niets opnieuw te bouwen.

Wie bredere keuzes maakt over AI-modellen en migraties: LLM model migratie: zo doe je het zonder gedoe is de moeite waard om naast dit onderwerp te lezen.

Waarom de huidige manier van meten niet klopt?

Stel je voor: je laat een AI een video beschrijven en vergelijkt die tekst met een handmatig geschreven referentie. Als de woorden niet overeenkomen, scoort de AI slecht. Maar wat als de AI-beschrijving gewoon een andere invalshoek kiest, en toch correct is? Dat is precies het probleem met gangbare meetmethoden voor videobeschrijvingen. Ze straffen afwijking af, ook als die afwijking inhoudelijk juist is. Het gevolg: ontwikkelaars optimaliseren modellen voor woordovereenkomst in plaats van voor feitelijke nauwkeurigheid.

Het probleem heet het ‘one-to-many’ probleem. Eén video kan op tien manieren correct beschreven worden. De ene beschrijving focust op de mensen in beeld, de andere op de omgeving, de derde op de actie. Alle drie kunnen kloppen. Maar als je ze vergelijkt met één referentietekst, lijken er maar twee goed te zijn.

Dit klinkt als een academisch probleem, maar het heeft praktische gevolgen. Als jij AI-tools gebruikt om video’s te beschrijven, ondertitels te genereren of metadata aan te maken voor je website, dan trainen en beoordelen ontwikkelaars die tools op dit soort gebrekkige metrics. Ze mikken dus op iets wat niet overeenkomt met wat jij eigenlijk wilt: een beschrijving die klopt met wat er echt te zien is.

Ik gebruik zelf AI-tools voor contentproductie, en dit is een punt waar ik sceptisch over ben. Een hoge score op een benchmark zegt weinig als die benchmark het verkeerde meet. Het is vergelijkbaar met een leerling die goed is in overschrijven maar niet in begrijpen. In het AI-begrippen overzicht leg ik uit hoe dit soort evaluatieproblemen vaker opduiken bij taalmodellen.

Wat doet CapQuiz anders dan bestaande benchmarks?

CapQuiz beoordeelt een videobeschrijving niet door hem te vergelijken met een referentietekst, maar door te kijken of de beschrijving bruikbaar is om vragen over de video te beantwoorden. Die vragen zijn meerkeuze, door mensen geverifieerd, en verdeeld over tien vraagtypen in 24 videocategorieën. Een beschrijving is goed als je er de juiste antwoorden mee kunt vinden. Niet als hij toevallig op dezelfde woorden lijkt als een andere beschrijving.

Het idee is eenvoudig: als een beschrijving goed is, moet je er informatie uit kunnen halen die overeenkomt met wat er echt in de video gebeurt. CapQuiz stelt dus vragen die je alleen kunt beantwoorden als de beschrijving feitelijk klopt én voldoende detail bevat.

Daarvoor introduceert het onderzoek twee nieuwe maatstaven. CapP meet factualiteit: klopt wat er staat? CapR meet dekking: hoe volledig is de beschrijving? Samen geven ze de CapF1-score, een gecombineerde maatstaf die beter correleert met menselijke oordelen dan bestaande methoden.

Wat me aanspreekt: de vragen zijn door mensen geverifieerd. Dat is een stuk geloofwaardiger dan automatisch gegenereerde testsets, waarbij je het risico hebt dat de testset dezelfde fouten maakt als het model. Toch wil ik hier één voorbehoud maken: dit systeem is zelf ook afhankelijk van een AI-model dat de vragen beantwoordt op basis van de beschrijving. Dat model kan fouten maken. De benchmark is beter dan zijn voorgangers, maar niet perfect.

Voor wie meer wil weten over hoe AI-modellen onderling vergeleken worden: dit artikel over LLM model migratie laat zien hoe afhankelijk je van dit soort kwaliteitsverschillen bent als je overstapt van het ene naar het andere model.

Wat betekent dit als je AI inzet voor videocontentproductie?

Als ondernemer gebruik je AI misschien om ondertitels te maken, video’s samen te vatten of metadata te genereren voor je website. De kwaliteit van die output hangt af van hoe goed het onderliggende model video’s begrijpt. Onderzoek als CapQuiz laat zien dat de huidige manier van meten die kwaliteit onderschat of overschat. Dat heeft directe gevolgen voor welke tool je kiest en hoe je de output controleert.

Stel je vertrouwt op een AI-tool om productvideos op je webshop automatisch van beschrijvingen te voorzien. Die tool scoort goed op de benchmarks die het bedrijf op de marketingpagina noemt. Maar als die benchmarks het verkeerde meten, zegt die score weinig over of de beschrijvingen daadwerkelijk kloppen met wat er in de video te zien is.

Mijn advies is simpel: vertrouw niet blind op benchmark-claims van AI-tools. Kijk liever naar concrete voorbeelden. Laat de tool een video beschrijven die jij goed kent en controleer of de beschrijving klopt. Dat duurt vijf minuten en leert je meer dan een whitepaper vol grafieken.

Dit soort onderzoek is nuttig als context, maar het lost jouw probleem niet direct op. Het laat wel zien dat de industrie zelf worstelt met het definiëren van ‘goed’. Dat betekent dat jij als gebruiker kritisch moet blijven, ook als een tool indrukwekkend klinkt. De echte kosten van AI-implementatie zitten vaak in precies dit soort kwaliteitscontrole die je niet had verwacht.

Overigens: als je AI-tools inzet voor webdesign of contentproductie, is het de moeite waard om te kijken hoe Figma Weave herbruikbare AI-workflows opzet. Daarmee leg je tenminste vast wat je verwacht, ook al kun je de output nog niet automatisch meten.