VAKRA ist ein tool-grounded, ausführbarer Benchmark, der bewertet, wie gut KI-Agenten in unternehmensähnlichen Umgebungen schlussfolgern und handeln. Anders als Benchmarks mit isolierten Einzelaufgaben misst VAKRA kompositionelles Reasoning über APIs und Dokumente hinweg und nutzt vollständige Ausführungsspuren, um zu prüfen, ob Agenten mehrstufige Workflows zuverlässig abschließen.
Die Umgebung umfasst mehr als 8.000 lokal gehostete APIs auf Basis realer Datenbanken aus 62 Domänen sowie domänenspezifische Dokumentkollektionen. Aufgaben können 3 bis 7 Reasoning-Schritte erfordern und strukturierte API-Interaktion mit unstrukturiertem Retrieval unter natürlichsprachigen Tool-Nutzungsbeschränkungen verbinden. Laut Beitrag schneiden Modelle auf VAKRA insgesamt schwach ab; vorgestellt werden zusätzliche Details zum Datensatz und eine Analyse beobachteter Fehlermodi.
Vier Fähigkeitsbereiche
Der Benchmark besteht aus vier Aufgabenbereichen mit unterschiedlichen Anforderungen. Der erste Bereich umfasst 2.077 Testinstanzen aus 54 Domänen und nutzt Werkzeuge aus den Sammlungen SLOT-BIRD und SEL-BIRD. Gegenüber Elder et al. (2026) wurde der Tool-Umfang durch zusätzliche Domänen erweitert. Pro Domäne ist jeweils nur eine Tool-Sammlung aktiv. Die Aufgaben erfordern Ketten aus 1 bis 12 Tool-Aufrufen.
Jede Instanz besitzt eine JSON-Datenquelle, aus der die Antwort abgeleitet werden muss. Zu Beginn jeder Instanz muss das spezielle Tool get_data(tool_universe_id=id) aufgerufen werden. Es initialisiert die Datenquelle, liefert eine kompakte Vorschau, speichert den vollständigen Datensatz serverseitig zur Vermeidung großer Datenübertragungen über das MCP-Protokoll und konfiguriert den MCP-Server so, dass nur das passende domänenspezifische Tool-Set verfügbar ist.
SLOT-BIRD stellt global sieben generische Werkzeuge für Datenmanipulation bereit, etwa zum Filtern oder Sortieren. SEL-BIRD erweitert dies um stärker spezialisierte Werkzeuge. Teilweise werden kategoriale Argumente in getrennte Funktionen aufgespalten, etwa sort_data in sort_data_ascending und sort_data_descending. Zudem wird die generische Funktion retrieve_data aus SLOT-BIRD durch abfragespezifische Getter ersetzt; für jeden Schlüssel einer Instanz gibt es eine zugehörige get_KEY_NAME-Funktion, im Mittel vier pro Instanz.
Der zweite Bereich umfasst 1.597 Instanzen aus 17 Domänen und verwendet eine erweiterte REST-BIRD-Sammlung. Die Schnittstellen sind als spezifische, abfrageorientierte Endpunkte umgesetzt, die einen Großteil der Berechnung kapseln. Sie laufen als REST-APIs auf einem FastAPI-Server, der durch den MCP-Server eingebunden wird. Die Aufgabe besteht darin, aus dem domänenspezifischen Tool-Satz die richtigen APIs auszuwählen. Pro Domäne gibt es mindestens 6 und höchstens 328 Werkzeuge, im Mittel 116. Auch hier beschränkt get_data die sichtbaren APIs auf die relevante Domäne.
Ein praktischer Randfall ergibt sich aus der OpenAI API Specification, die die Werkzeugliste auf maximal 128 Tools begrenzt. Agenten, die diese API verwenden, müssen daher eine Shortlisting-Strategie einsetzen. In den Baseline-Agenten des Projekts wird dies durch eine einfache Shortlisting-Funktion umgesetzt.
Der dritte Bereich umfasst 869 Testinstanzen aus 38 Fachdomänen und baut ebenfalls auf REST-BIRD auf, ergänzt aber Multi-Hop-Reasoning. Die Fragen verlangen, mehrere Belegstücke zu extrahieren und zu kombinieren. Die Instanzen benötigen zwischen einem und fünf logischen Hops.
Der vierte Bereich enthält 644 Instanzen aus 41 Domänen und ist der komplexeste Teil des Benchmarks. Er kombiniert mehrere Anforderungen: zusätzliche Dokumentindizes pro Domäne, Multi-Hop-Fragen über APIs und Dokumentabruf, Multi-Turn-Dialoge sowie Richtlinien für die Tool-Nutzung. Die Daten werden als Kontext-Antwort-Paare veröffentlicht; der Kontext enthält den bisherigen Dialogverlauf, und der Agent beantwortet nur den aktuellen Zug.
Für korrekte Schlussfolgerungen wurden die Quellen bei der Datengenerierung decontaminiert: Die für einen Hop benötigte Information ist jeweils nur in einer Quelle verfügbar. Wenn ein Hop über APIs beantwortet werden soll, werden aus dem Dokumentindex Dokumente entfernt, die diese Information wahrscheinlich enthalten. Ein Teil der Instanzen enthält zudem textuelle Policies, die vorgeben, welche Wissensquellen ein Agent in welchen Fällen verwenden darf. Der Baseline-Agent setzt diese Beschränkungen durch einen zusätzlichen Prompt-Hinweis um, wobei andere Mechanismen ebenfalls möglich sind.
Auswertung über Antwort und Ausführungspfad
VAKRA bewertet nicht nur die Endantwort, sondern die vollständige Tool-Ausführung mit Tool-Aufrufen, Eingaben und Zwischenergebnissen. Für jedes Beispiel verarbeitet der Evaluator zwei Eingaben: die vorhergesagte Endantwort und die zugehörige Tool-Trajektorie. Die Tool-Aufrufe aus der vorhergesagten Trajektorie werden in derselben Umgebung wie die Ground Truth ausgeführt, um Zwischenergebnisse zu verifizieren.
Die Auswertung folgt einer Waterfall-Pipeline. Bei Aufgaben aus Bereich 4 wird zuerst die Einhaltung der Policies programmatisch geprüft. Danach wird die vorhergesagte Tool-Sequenz mit der Ground-Truth-Sequenz verglichen. Nur Beispiele mit gültigen Trajektorien gelangen zur Bewertung der Endantwort.
Da Agenten in der ausführbaren Umgebung auch alternative, aber gültige Werkzeuge oder Reasoning-Pfade nutzen können, wird keine strikte Schritt-für-Schritt-Übereinstimmung erzwungen. Stattdessen werden die vorhergesagten Tools ausgeführt und die Menge ihrer Antworten mit den Ground-Truth-Antworten verglichen. Zunächst wird programmatisch geprüft, ob alle Informationen aus den Ground-Truth-Tool-Antworten in den vorhergesagten Tool-Antworten wiedergewonnen wurden. Bei unklaren Fällen, etwa bei Teiltreffern, semantischer Äquivalenz oder Darstellungsunterschieden wie Reihenfolge, Aggregation oder Formatierung, folgt eine zusätzliche LLM-basierte Bewertung auf Basis eines angepassten CRAG-Ansatzes nach Yang et al. (2024).
Die Endantwort wird nur dann mit einem LLM-Judge bewertet, wenn die Trajektorie die vorherige Prüfung besteht. Dabei wird kontrolliert, ob die Antwort in den vorhergesagten Tool-Ausgaben verankert und faktisch mit der Ground Truth konsistent ist, auch wenn Formulierung oder Struktur variieren.
Für das Leaderboard werden alle vier Fähigkeitsbereiche gleich gewichtet. Innerhalb der Bereiche 1 bis 3 werden alle Beispiele gleich gewichtet; für Bereich 4 werden heterogene Anfragen höher gewichtet.
Fehleranalyse
Die Fehleranalyse ordnet jeden Fehlschlag dem ersten Punkt des Scheiterns zu. Der Beitrag prüft der Reihe nach, ob die richtigen Tools gewählt wurden, ob erforderliche Argumente ohne Auslassungen oder Halluzinationen übergeben wurden, ob die Argumentwerte korrekt waren und ob die Endantwort sowohl richtig als auch in den Tool-Ausgaben verankert war. Tritt ein Beispiel an mehreren Stellen fehl, wird nur die früheste Fehlerstufe gezählt, um Doppelzählungen zu vermeiden.
Im ersten Bereich mit 2.077 Beispielen mussten mehrere Tools ausgewählt und in die richtige Reihenfolge gebracht werden. Das war für alle Modelle schwierig; GPT-OSS-120B erzielte in diesem Segment die besten Ergebnisse. Laut Analyse lag der Vorsprung vor allem an einem besseren Verständnis der Tool-Schemata. Die Werkzeuge in diesem Bereich besitzen viele Parameter, von denen viele optional sind, und GPT-OSS-120B war robuster bei der Auswahl der passenden Parameter. Die Synthese einer korrekten Endantwort nach korrekten Tool-Aufrufen war hier weniger problematisch als in der Dashboard-API-Aufgabe.
Innerhalb des BI-API-Bereichs unterscheiden sich SLOT-BIRD und SEL-BIRD leicht. SLOT-BIRD umfasst weniger, dafür generische Werkzeuge mit vielen auszufüllenden Parametern, während SEL-BIRD mehr Werkzeuge mit weniger Parametern pro Tool bereitstellt. Bei SLOT-BIRD machten alle getesteten Modelle außer GPT-OSS-120B viele Fehler bei den korrekten Namen der Tool-Argumente. Bei SEL-BIRD traten solche Fehler wegen der geringeren Parameterzahl seltener auf, dafür häuften sich Fehler bei der Tool-Auswahl, was mit dem größeren und dynamischen Tool-Satz zusammenhängt.
Im zweiten Bereich mit 1.597 Beispielen zur Tool-Auswahl schnitt Gemini-3-flash-preview über alle Fehlerkategorien hinweg am besten ab. Da die Dashboard-API-Instanzen eine Auswahl aus vielen Tool-Optionen verlangen, jedes Tool aber nur wenige Parameter benötigt, traten viele Fehler bei der Tool-Auswahl und bei den Parameterwerten auf. Halluzinierte oder ausgelassene Pflichtparameter waren dagegen seltener. Selbst bei korrekten Tool-Aufrufen hatten Modelle, insbesondere Gemini-3-flash-preview und Claude-Sonnet-4-5, weiterhin Schwierigkeiten, aus den Tool-Antworten eine korrekte Endantwort zu synthetisieren.
Im Multi-Hop-Bereich nahm die Leistung mit steigender Hop-Tiefe ab. Alle Modelle erreichten bei Fragen mit nur einem logischen Hop die besten Ergebnisse und verschlechterten sich bei 2-Hop- und erneut bei 3+-Hop-Fragen.
Im vierten Bereich mit Dokumentquellen zusätzlich zu APIs wurden Instanzen mit einzelnen oder mehreren API-Aufrufen, einzelnen oder mehreren Dokumentabfragen sowie Kombinationen daraus untersucht. Auch hier zeigte sich ein deutlicher Unterschied zwischen 1-Hop-API und 2-Hop-API; Dokument-Retrieval erhöhte die Schwierigkeit zusätzlich. Bei Fragen mit einem einzelnen Document-Retriever-Aufruf versuchte GPT-OSS-120B laut Analyse teilweise, die Antwort direkt aus Parameterwissen zu geben, anstatt das Tool zu nutzen. Bei Aufgaben mit mehreren Hops beantwortete das Modell die Frage dagegen. Als mögliche Erklärung nennt der Beitrag den Wikipedia-ähnlichen Fokus der 1-Hop-RAG-Fragen. Für Gemini-3-flash-preview fiel auf, dass die Leistung bei 2-Hop-API-RAG höher ausfiel als bei anderen hybriden Hop-Mustern, was mit den vergleichsweise guten Ergebnissen bei den Dashboard-APIs zusammenhängen könnte.
Policies erschweren Multi-Hop- und Multi-Source-Reasoning zusätzlich. Wenn die Policy die für die Antwort nötige Quelle nicht verändert, spricht der Beitrag von No Updates to Answer. Wenn die Policy den Zugriff auf die relevanteste Quelle einschränkt, sank die Leistung bei allen Modellen außer Granite-4.0-h-Small-32B deutlich. Insgesamt verletzten Modelle entweder die Vorgaben oder konnten trotz erkannter Policy nicht genügend Informationen beschaffen und zeigten dabei teils die bereits beschriebenen Fehlermodi.
Der Beitrag beschreibt VAKRA damit als Benchmark, der die Lücke zwischen oberflächlicher Tool-Kompetenz und robuster End-to-End-Zuverlässigkeit von Agenten sichtbar machen soll. Zwar können moderne Modelle APIs zunehmend auswählen und isolierte Tool-Aufrufe ausführen, unter Ausführungsbeschränkungen über APIs, Dokumente, Dialogkontext und Policies hinweg treten jedoch weiterhin deutliche Ausfälle auf.
