Testing Agentic Workflows with Structural Coverage Criteria
Dieser Beitrag stellt einen strukturellen Testansatz für Multi-Agenten-Workflows vor, der diese als Koordinationsgraphen modelliert, um Abdeckungspflichten abzuleiten, die anschließend mittels DSPy in ausführbare Tests umgesetzt werden, um zu verifizieren, dass deklarierte Agenten, Tool-Zugriffsregeln, Einschränkungen und Delegationspfade tatsächlich ausgeführt werden.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie stellen ein Team spezialisierter Roboter ein, um eine Kundenbetreuungsabteilung zu leiten. Sie geben ihnen ein strenges Regelwerk: „Roboter A darf nur Flugpläne prüfen, Roboter B darf nur Sitzplätze buchen, und Roboter C ist der Manager, der entscheidet, wer was tut." Sie schreiben auch spezifische Regeln auf, wie zum Beispiel: „Roboter A ist verboten, Sitzplätze zu buchen."
Stellen Sie sich nun vor, Sie möchten testen, ob dieses Team korrekt funktioniert.
Der alte Weg (Der „Happy Path"-Test)
Traditionell würden Tester das Team einfach eine einfache Frage stellen: „Ich muss einen Sitzplatz buchen." Wenn das Team erfolgreich einen Sitzplatz bucht, ist der Test ein „Bestanden".
- Das Problem: Dies beweist nicht, dass das Team die Regeln befolgt hat. Vielleicht versuchte Roboter A, den Sitzplatz zu buchen, aber Roboter B übernahm trotzdem. Oder vielleicht sah Roboter A die Anfrage gar nicht. Der Test bestand, aber Sie haben keine Ahnung, ob die spezifischen Regeln, die Sie aufgeschrieben haben, tatsächlich befolgt wurden. Sie könnten einen „versteckten" Roboter haben, der nie eingesetzt wird, oder eine verbotene Aktion, die nie überprüft wurde.
Der neue Weg (Strukturelle Abdeckung)
Dieser Artikel schlägt eine neue Methode vor, um diese KI-Teams zu testen. Anstatt nur zu prüfen, ob die endgültige Aufgabe erledigt wurde, prüfen sie, ob jede einzelne Regel und jede Verbindung im Regelwerk tatsächlich verwendet wurde.
Stellen Sie sich das Regelwerk des Teams als eine Karte eines U-Bahn-Systems vor:
- Stationen sind die verschiedenen KI-Agenten (Roboter).
- Gleise sind die Pfade, auf denen sie Aufgaben aneinander weitergeben (Delegation).
- Zuglinien sind die Werkzeuge, die sie verwenden können (wie „Flug prüfen" oder „Sitzplatz buchen").
- Rote Zonen sind die Gleise, in die sie streng verboten sind (Eingeschränkte Werkzeuge).
Die Methode der Autoren behandelt das Regelwerk wie diese U-Bahn-Karte. Sie fragen nicht nur: „Ist der Zug am Ziel angekommen?" Sie fragen:
- Hat der Zug jede Station besucht? (Hat jeder Roboter einen Turn gehabt?)
- Ist der Zug auf jedem erlaubten Gleis gefahren? (Hat jeder Roboter jedes Werkzeug verwendet, das ihm erlaubt war?)
- Hat der Zug versucht, eine Rote Zone zu betreten und wurde gestoppt? (Haben wir bewiesen, dass die verbotenen Regeln tatsächlich funktionieren?)
- Hat der Zug an jedem Umsteigepunkt die Linie gewechselt? (Haben die Roboter Aufgaben korrekt übergeben?)
Wie sie es tun
Die Forscher entwickelten ein System, das wie ein super-intelligenter Drehbuchautor agiert (unter Verwendung eines Tools namens DSPy).
- Karte lesen: Zuerst liest das System den Code und zeichnet die U-Bahn-Karte (den „Koordinationsgraphen").
- Szenarien schreiben: Anschließend schreibt es spezifische Anfragen in natürlicher Sprache, die das KI-Team dazu zwingen sollen, bestimmte Teile der Karte zu nutzen.
- Beispiel: Um eine „Rote Zone" zu testen, könnte es den Manager-Roboter fragen: „Bitte buchen Sie einen Sitzplatz für mich", in der Hoffnung, dass der Manager versucht, dies direkt zu tun (was verboten ist). Wenn das System den Manager dabei erwischt, dass er versucht, die Regel zu brechen, und sich selbst stoppt, ist dies ein erfolgreicher Test der Einschränkung.
- Realitätscheck: Das System führt diese Szenarien gegen das echte KI-Team aus. Es betrachtet nicht nur die endgültige Antwort, sondern überwacht die internen Protokolle, um genau zu sehen, welcher Roboter sprach, welches Werkzeug angeklickt wurde und welche Übergabe stattfand.
Was sie fanden
Sie testeten dies an 10 verschiedenen KI-Team-Setups (von einfachen Kundenbetreuungs-Bots bis hin zu komplexen Forschungsteams).
- Die gute Nachricht: Ihre Methode generierte erfolgreich Tests, die bewiesen, dass die KI-Teams ihre erlaubten Werkzeuge nutzten und Aufgaben korrekt aneinander weitergaben.
- Die „Rote Zone"-Entdeckung: Als sie versuchten, die KI-Teams dazu zu verleiten, gegen die Regeln zu verstoßen, stellten sie fest, dass einige Teams sehr gut darin waren, sich selbst zu stoppen (0 Verstöße), während andere versehentlich versuchten, verbotene Werkzeuge zu verwenden (Verstöße gefunden). Dies ist wertvoll, weil es genau zeigt, wo die Regeln schwach sind.
- Die Grenze: Sie stellten fest, dass es schwieriger ist, wenn eine Aufgabe den Durchgang durch viele verschiedene Roboter erfordert (eine lange U-Bahn-Fahrt), für ihren Drehbuchautor, das KI-System dazu zu bringen, diesen exakten Pfad jedes Mal zu nehmen.
Das Fazit
Dieser Artikel argumentiert, dass allein die Tatsache, dass ein KI-Team ein Problem löst, nicht bedeutet, dass es sein Design befolgt. Sie müssen die Struktur des Teams überprüfen, nicht nur das Ergebnis.
Es ist wie das Überprüfen eines Autos: Sie fahren es nicht nur zum Laden, um zu sehen, ob es funktioniert. Sie prüfen auch, ob die Bremsen getestet wurden, ob die Airbags bei einem Crashtest ausgelöst wurden und ob das Motoröl gewechselt wurde. Dieser Artikel gibt uns eine Checkliste, um sicherzustellen, dass jeder Teil des Designs eines KI-Teams getestet wurde und dass die von uns festgelegten Regeln tatsächlich befolgt werden.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.