Agent-Leaderboards täuschen — benchmark gegen deine eigenen Tools

Öffentliche Agent-Leaderboards wirkten autoritativ — bis Teams tatsächlich mit dem erstplatzierten Modell in Produktion gingen. Dann hatte die Tool-Call-Fehlerrate im Betrieb keinerlei Ähnlichkeit mehr mit dem Score auf dem Chart. Der Grund ist strukturell: Jeder veröffentlichte Benchmark testet eine feste, kuratierte Menge generischer Tools — und dein interner Stack ist mit ziemlicher Sicherheit keines davon. Die ehrliche Einschätzung: Die Frage, welches Modell für agentic Workloads geeignet ist, lässt sich nicht beantworten, ohne einen Eval-Harness zu haben, der auf deine eigenen Tool-Oberflächen zeigt.

Was sich daran geändert hat, wie die Community Agent-Fähigkeiten misst

Das Hugging-Face-Team macht die strukturelle Kritik in seinem Post "Is it agentic enough?" explizit. Die dominierenden agentic Benchmarks — darunter vielzitierte Suites rund um Web-Suche, Taschenrechner und File I/O — teilen eine gemeinsame Design-Einschränkung: Tool-Oberflächen sind fest und standardisiert, damit Ergebnisse lab-übergreifend vergleichbar bleiben. Das ist die richtige Eigenschaft für ein vergleichendes Leaderboard. Es ist die falsche Eigenschaft für einen Operator, der ein Modell für einen internen Agenten auswählen will, der ein proprietäres ERP, eine Custom-Dokumentenabruf-API und einen Legacy-SOAP-Service hinter einem dünnen REST-Shim aufruft.

Der Post beleuchtet auch das Problem der Mehrschritt-Kompoundierung. Ein Modell, das 80 % Single-Step-Tool-Call-Accuracy erreicht, liefert keine 80 % Task-Completion in einer 5-stufigen Chain — sondern ungefähr 33 % (0,8⁵). Leaderboards berichten fast immer Single-Step- oder Kurzhorizont-Scores. Die Lücke zwischen diesen Scores und der realen Task-Completion wächst nichtlinear mit der Chain-Länge — und genau dort lebt Enterprise-Agent-Arbeit: Multi-Hop-Lookups, bedingte Verzweigungen, Write-Back-Schritte.

Open-Model-Releases haben dieses Problem 2025 und im ersten Halbjahr 2026 verschärft. Wenn ein neues Modell auf einem öffentlichen Benchmark 3 Punkte besser abschneidet, verbreitet sich die Modell-Card schnell. Das Tool-Call-Schema, auf das es trainiert wurde — ob es striktes JSON-Function-Calling bevorzugt, einen ReAct-Style-Scratchpad oder einen Code-Execution-Loop — bekommt in der Ankündigung weit weniger Aufmerksamkeit. Aber genau das entscheidet darüber, ob das Modell auf deinem Schema graceful degradiert oder katastrophal versagt.

Warum das die Mathematik der Agent-Evaluation verändert

Die meisten Teams in der Größenordnung von 50–500 FTE haben keine Eval-Infrastruktur für Agents. Sie haben eine Staging-Umgebung, ein paar manuelle Tests und jemanden, der das Modell vor einem Deployment gegen einige repräsentative Prompts laufen lässt. Das war ausreichend, als LLMs Text vervollständigten. Es ist nicht ausreichend, wenn das Modell Tools mit Seiteneffekten aufruft — Records schreibt, Workflows triggert, State aktualisiert.

Die strategische Konsequenz: Die Entscheidung „Welches Modell nehmen wir für unseren internen Agenten?" wird bei den meisten Unternehmen derzeit ohne valide Daten getroffen. Teams orientieren sich an Benchmark-Headlines, Vendor-Reputation oder Cost-per-Token. Alle drei sind vernünftige Tie-Breaker, wenn zwei Modelle für eine Aufgabe sonst gleichwertig sind. Keiner davon ersetzt die Messung von Tool-Call-Accuracy, Schema-Adherence und Multi-Step-Completion-Rate auf deinen eigenen Tools.

Es gibt auch ein umgekehrtes Sourcing-Risiko. Wer den Eval-Harness nicht gebaut hat, kann auch keine Regression erkennen, wenn das Modell gewechselt oder ein Tool-Schema geändert wird. Agent-Stacks sind nicht statisch — Tools entwickeln sich weiter, Modelle werden ausgetauscht, Prompt-Templates driften. Ohne kontinuierliches Eval gegen repräsentative Traces fliegst du jedes Mal ohne Instrumente, wenn sich etwas ändert.

Was du am Montag konkret tun kannst

Die erste Frage ist, ob du die Voraussetzungen für ein sinnvolles Eval hast. Geh diese Sequenz durch, bevor du Zeit in Modellvergleiche investierst:

• Hast du Tool-Call-Traces aus Production oder Staging? Falls nicht: Instrumentiere dein Agent-Framework so, dass jeder Tool-Call geloggt wird — das gesendete Input-Schema, den rohen Model-Output und das geparste Ergebnis. 2 bis 3 Tage Traffic bei auch nur moderatem Volumen reichen, um ein Replay-Corpus aufzubauen.
• Hast du Ground-Truth-Labels für einen Teil dieser Traces? Du brauchst mindestens 50 bis 100 gelabelte Beispiele — richtiges Tool gewählt, korrekte Argumente, korrekte finale Antwort — um ein Signal zu bekommen, das kein Rauschen ist. Diese sollten Domain-Experten in deinem Team labeln, keine ML-Engineers.
• Ist deine Tool-Anzahl hoch genug, dass die Modellwahl einen Unterschied macht? Unter etwa 5 Tools werden die meisten fähigen Open-Models ähnlich abschneiden. Ab 10 Tools — besonders bei überlappenden oder mehrdeutigen Schemas — beginnt die Modellwahl, deutlich zu zählen. Ab 20 ist sie wahrscheinlich die dominierende Variable für Agent-Reliability.

Sobald diese Voraussetzungen erfüllt sind, ist das eigentliche Eval nicht teuer durchzuführen. Wähle 2 bis 3 Kandidaten-Modelle — mindestens das aktuell verwendete, einen Challenger aus der aktuellen Open-Weight-Kohorte und ein cost-optimiertes kleineres Modell als Baseline. Lass alle drei gegen dein Replay-Corpus laufen — mit identischen Prompts. Miss Single-Step-Tool-Call-Accuracy, Argument-Schema-Validity und End-to-End-Task-Completion auf Multi-Step-Traces separat. Die Deltas werden dir an einem Nachmittag mehr sagen als ein Jahr Leaderboard-Posts lesen.

Wenn dein Team diese Woche nicht die Kapazität hat, den Harness zu bauen: Die minimal viable Version ist ein strukturiertes Log und ein gelabeltes Sample. Den Replay-Runner kannst du später bauen. Lass dich von perfekter Eval-Infrastruktur nicht davon abhalten, schon jetzt mit der Datensammlung anzufangen.

Was es kostet — und was es einspart

Einen minimalen Agent-Eval-Harness zu bauen dauert ungefähr 2 bis 4 Engineer-Wochen — Instrumentierung, Replay-Runner, Labeling-Workflow und ein Reporting-Layer, der einfach genug ist, dass ein Product Manager ihn lesen kann. Das ist ein echter Kostenposten und wird sich in einem Quartal, in dem die Roadmap ohnehin voll ist, wie Infrastruktur-Tax anfühlen.

Die Alternative ist schwerer zu sehen — aber teurer. Teams, die Eval überspringen, entdecken modellspezifische Failure Modes typischerweise in Production. Im besten Fall bedeutet das eine schlechtere User Experience für einen Sprint-Zyklus, während Prompt-Templates gepatcht werden. Im schlimmsten Fall — wenn Agents Schreibzugriff auf Systems of Record haben — entstehen Datenintegritätsprobleme, die Wochen brauchen, um sie zu entwirren. Das Regressionsrisiko allein rechtfertigt die Infrastrukturinvestition: Jedes Modell-Update ohne Harness ist eine unkontrollierte Änderung an einem System mit Seiteneffekten. Die Unternehmen, die in den nächsten 18 Monaten einen dauerhaften Vorteil in Agent-Reliability haben werden, sind nicht die, die das richtige Modell vom Leaderboard gepickt haben. Sie sind die, die zuerst die Messschicht gebaut haben.