AI Tool Calling evaluieren: eine praktische Checkliste

Ein Tool-Use-Eval beginnt mit dem überprüfbaren Ergebnis der Aufgabe, nicht mit der Frage, ob das Modell die erwartete Funktion aufgerufen hat. Fixieren Sie Ausgangszustand, Nutzeranfrage, verfügbare Tools, Daten- und Berechtigungsgrenzen, erlaubte Änderungen, Abschlusskriterium und verbotene Ereignisse. Sonst belohnt ein Exact Match mit dem Referenzaufruf nur eine Trajektorie, obwohl ein anderer sicherer Weg zum gleichen korrekten Ergebnis führt.

Trennen Sie Read-, Propose- und Mutate-Tools. Ein Dokument zu finden, einen Entwurf vorzubereiten und eine E-Mail zu senden haben unterschiedliche Risiken und brauchen unterschiedliche Grader. Versionieren Sie für jedes Fixture Prompt, Modell, Tool Catalog, Schemas, Policy und Sandbox Snapshot. Reale Aufgaben sollten Mehrdeutigkeit, Rückfragen, mehrere Calls und Fehlerbehandlung verlangen statt nur einen Funktionsnamen aus der Anfrage zu wiederholen.

• Initial State → bekannte Datensätze, Berechtigungen, Clock und externe Abhängigkeiten.
• Expected Outcome → überprüfbarer Terminal State oder korrekte Abstention.
• Allowed Trajectory → notwendige Invarianten ohne einen einzigen Weg vorzuschreiben.
• Forbidden Event → unzulässiger Read/Write, Leak, Duplikat oder Aktion ohne Approval.

Bauen Sie Slices für korrekte Auswahl, Verwechslung ähnlicher Tools, fehlenden Call, unnötigen Call und Fälle, in denen überhaupt kein Tool nötig ist. Testen Sie separat unbekannte Entities, fehlende Pflichtfelder, mehrdeutige Daten, falsche Tenants, veraltete Identifier und Anfragen außerhalb der Berechtigung. Valides JSON beweist nur die Form: Ein semantischer Grader muss prüfen, ob die Argumente zu Intent, aktuellem State und Policy passen.

Tool Precision und Recall sind nur innerhalb eines konkreten Slice aussagekräftig. Eine hohe Gesamtgenauigkeit kann verdecken, dass das Modell regelmäßig ein riskantes Mutating Tool statt einer Read-only-Prüfung wählt. Ergänzen Sie negative Fälle, in denen Rückfrage, Ablehnung oder Human Escalation korrekt sind. Bei Parallel Calls muss geprüft werden, dass Operationen unabhängig sind und das Ergebnis nicht von zufälliger Abschlussreihenfolge abhängt.

Ein Mock, der immer Success liefert, testet kein Tool Calling. Die Eval-Umgebung muss Schema Validation, Authorization, Latenz, Pagination, Rate Limits, Partial Results, Timeouts und Side Effects abbilden. Für Mutating Tools nutzen Sie eine isolierte Datenbank oder Record-Replay-Umgebung mit autoritativem Read-back. Der Harness protokolliert Model Proposal, Policy Verdict, tatsächlichen Request, Tool Response und Terminal State als getrennte Ereignisse.

Injizieren Sie kontrollierte Fehler: 429 vor Ausführung, Timeout nach Commit, Schema Evolution, Permission Revocation zwischen Planning und Execution, Duplicate Delivery und Stale State. Nach einem unsicheren Ergebnis muss die Trajektorie zuerst per Read-only-Operation reconciliieren, statt blind zu wiederholen. Der Idempotency Key muss stabil an den Operations-Intent gebunden sein; ein neuer zufälliger Key pro Versuch schützt nicht vor Duplikaten.

Der Outcome Grader liest das System of Record und prüft den geforderten Zustand. Der Trajectory Grader sucht notwendige und verbotene Ereignisse: Authorization vor Write, Approval für den exakten Payload, keine Secrets in Arguments, korrekte Behandlung von Tool Errors und Stop nach Abschluss. Der Side-Effect Grader zählt Duplikate, Orphaned Writes, falsche Destinations und Änderungen außerhalb des Scope. Eine gute finale Antwort kompensiert keine gefährliche Aktion im Trace.

Verlangen Sie keinen wörtlichen Match jedes Schritts, wenn mehrere Trajektorien gültig sind. Exakte Reihenfolge ist für Security Invariants wichtig—etwa Policy Lookup vor Refund—nicht aber für zwei unabhängige Read Calls. Ein Model Grader kann Erklärungsqualität oder Angemessenheit einer Rückfrage bewerten; Permissions, Schema, Ledger Balance und Final State sollten deterministisch geprüft werden. Für mehrdeutige Business-Kriterien bleibt Human Calibration nötig.

• Outcome → korrekter State, Antwort oder begründete Ablehnung.
• Trajectory → korrekte Decisions, Calls, Policy Gates und Error Transitions.
• Integrity → kein unnötiger, doppelter oder unzulässiger Side Effect.
• Efficiency → Calls, Tokens, Latenz und Kosten pro erfolgreich verifizierter Aufgabe.

Tool Performance hängt nicht nur vom Modell ab. Namen, Beschreibungen, Overlap, Parameter, Response Format, Anzahl verfügbarer Tools und zurückgegebener Kontext verändern das Agent-Verhalten. Vergleichen Sie Candidate und Baseline auf einem Frozen Regression Set und einem separaten Held-out-Set. Eine Ablation jeweils nur eines Faktors hilft, eine Schema-Verbesserung von Sampling-Änderung oder Data Leakage zu unterscheiden.

Berichten Sie Task Success, kritische Policy Violations, semantische Argumentvalidität, Tool-Selection Confusion Matrix, unnötige Calls, Recovery Success, Final-State-Mismatch, p95-Latenz und Kosten pro Verified Success. Ergänzen Sie Wiederholungen und Confidence Intervals für stochastische Runs. Übertragen Sie Vendor Benchmarks nicht direkt auf Ihren Workflow: Production Catalog, Data Distribution, Permissions und Error Surface unterscheiden sich.

Der Decision Record fixiert Dataset, Modell, Prompt, Catalog, Schemas, Executor, Policy, Thresholds, Owner und Rollback Revision. Ein kritischer Unauthorized Write, Cross-Tenant Read, Secret Exposure, Approval Bypass oder eine doppelte Finanzaktion blockiert den Release unabhängig vom durchschnittlichen Task Success. Eine nichtkritische Regression kann den Catalog verengen, Parallel Calls deaktivieren, ein Tool auf Read-only zurücksetzen oder Human Approval verlangen.

Der Rollout führt über Offline Sandbox, Shadow Traffic ohne Side Effects, Read-only Canary, Approval-required Writes und erst dann Bounded Autonomy. Production Telemetry nutzt dasselbe Event Schema wie der Eval Harness, ergänzt um Redaction und Retention Controls. Nach einem Incident wird zuerst der externe State reconciliert, das betroffene Tool bzw. die Version blockiert und der Known-good Envelope wiederhergestellt; der bereinigte Trace wird zum permanenten Regression Fixture.