Testing Agentic Workflows with Structural Coverage Criteria
Dit artikel introduceert een structurele testbenadering voor multi-agent workflows die deze modelleren als coördinatiegrafieken om dekkingverplichtingen af te leiden, welke vervolgens via DSPy worden omgezet in uitvoerbare tests om te verifiëren dat de gedeclareerde agenten, hulpmiddeltoegangsregels, beperkingen en delegatiepaden daadwerkelijk worden getoetst.
Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer
Stel je voor dat je een team gespecialiseerde robots huurt om een klantenserviceafdeling te runnen. Je geeft hen een strikt reglement: "Robot A mag alleen vluchtschema's controleren, Robot B mag alleen stoelen boeken, en Robot C is de manager die beslist wie wat doet." Je schrijft ook specifieke regels op, zoals: "Robot A is verboden om stoelen te boeken."
Stel je nu voor dat je wilt testen of dit team correct werkt.
De oude manier (de "Happy Path"-test)
Traditioneel zouden testers het team gewoon een simpele vraag stellen: "Ik moet een stoel boeken." Als het team de stoel succesvol boekt, is de test een "slagen".
- Het probleem: Dit bewijst niet dat het team de regels heeft gevolgd. Misschien probeerde Robot A de stoel te boeken, maar nam Robot B het toch over. Of misschien zag Robot A het verzoek nooit. De test slaagde, maar je hebt geen idee of de specifieke regels die je hebt opgeschreven daadwerkelijk zijn gevolgd. Je zou een "verborgen" robot kunnen hebben die nooit wordt gebruikt, of een verboden actie die nooit is gecontroleerd.
De nieuwe manier (structurele dekking)
Dit artikel stelt een nieuwe manier voor om deze AI-teams te testen. In plaats van alleen te controleren of de uiteindelijke taak is uitgevoerd, controleren ze of elke enkele regel en verbinding in het reglement daadwerkelijk is gebruikt.
Stel je het reglement van het team voor als een kaart van een metronet:
- Stations zijn de verschillende AI-agenten (robots).
- Spoorlijnen zijn de paden waar ze taken aan elkaar doorgeven (delegatie).
- Treinlijnen zijn de hulpmiddelen die ze kunnen gebruiken (zoals "Vlucht controleren" of "Stoel boeken").
- Rode zones zijn de sporen waar ze streng verboden is binnen te komen (beperkte hulpmiddelen).
De methode van de auteurs behandelt het reglement als deze metronetkaart. Ze vragen niet alleen: "Is de trein op de bestemming aangekomen?" Ze vragen:
- Heeft de trein elk station bezocht? (Heeft elke robot een beurt gekregen?)
- Is de trein op elk toegestaan spoor gereden? (Heeft elke robot elk hulpmiddel gebruikt dat het mocht gebruiken?)
- Heeft de trein geprobeerd een rode zone binnen te komen en is gestopt? (Hebben we bewezen dat de verboden regels daadwerkelijk werken?)
- Heeft de trein op elk overstappunt van lijn gewisseld? (Hebben de robots taken correct doorgegeven?)
Hoe ze het doen
De onderzoekers bouwden een systeem dat fungeert als een super-slim scenarioschrijver (met behulp van een tool genaamd DSPy).
- De kaart lezen: Eerst leest het systeem de code en tekent de metronetkaart (het "coördinatiegrafiek").
- De scenario's schrijven: Vervolgens schrijft het specifieke, natuurlijke taalverzoeken die zijn ontworpen om het AI-team te dwingen specifieke delen van de kaart te gebruiken.
- Voorbeeld: Om een "rode zone" te testen, vraagt het misschien de manager-robot: "Boek alstublieft een stoel voor me", in de hoop dat de manager het direct probeert te doen (wat verboden is). Als het systeem de manager betrapt die probeert de regel te breken en zichzelf stopt, is dat een succesvolle test van de beperking.
- De realiteitscheck: Het systeem draait deze scenario's tegen het echte AI-team. Het kijkt niet alleen naar het uiteindelijke antwoord; het bekijkt de interne logs om precies te zien welke robot sprak, welk hulpmiddel werd aangeklikt en welke overdracht plaatsvond.
Wat ze ontdekten
Ze testten dit op 10 verschillende AI-teamopstellingen (variërend van simpele klantenservicebots tot complexe onderzoeksteams).
- Het goede nieuws: Hun methode slaagde erin tests te genereren die bewezen dat de AI-teams hun toegestane hulpmiddelen gebruikten en taken correct aan elkaar doorgeven.
- De "rode zone"-ontdekking: Toen ze probeerden de AI-teams te verleiden tot het breken van de regels, ontdekten ze dat sommige teams erg goed waren in zichzelf te stoppen (0 overtredingen), terwijl anderen per ongeluk probeerden verboden hulpmiddelen te gebruiken (overtredingen gevonden). Dit is waardevol omdat het precies laat zien waar de regels zwak zijn.
- De limiet: Ze ontdekten dat als een taak vereist dat er via veel verschillende robots wordt doorgegeven (een lange metrorit), het voor hun scenarioschrijver moeilijker is om het AI-team elke keer die exacte route te laten nemen.
De kernboodschap
Dit artikel betoogt dat het feit dat een AI-team een probleem oplost, niet betekent dat het zijn ontwerp volgt. Je moet de structuur van het team controleren, niet alleen het resultaat.
Het is als het controleren van een auto: je rijdt niet alleen naar de winkel om te zien of het werkt. Je controleert ook of de remmen zijn getest, of de airbags zijn uitgeklapt bij een crashtest, en of de motorolie is vervangen. Dit artikel geeft ons een checklist om ervoor te zorgen dat elk onderdeel van het ontwerp van een AI-team is getest, zodat wordt gewaarborgd dat de regels die we stellen daadwerkelijk worden gevolgd.
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.