Auf dem Berkeley Function Calling Leaderboard v4, präsentiert auf der ICML 2025, führt GLM-4.5 mit 70,85 Prozent. Claude Sonnet 4 folgt mit 70,29 Prozent. GPT-5 liegt bei 59,22 Prozent. Alle Top-Modelle bewegen sich in einem Korridor von rund zwölf Prozentpunkten, und niemand bricht nach oben aus. Gleichzeitig dokumentiert OpenAI für seine Structured Outputs eine andere Metrik: ohne den Modus liegt die Schema-Compliance bei rund 93 Prozent, mit dem Modus konstant bei 100 Prozent. Dieselben Modellgewichte. Sieben Prozentpunkte Unterschied, ohne dass am Modell ein einziges Bit verändert wurde.
Wer beide Zahlen ernst nimmt, hat den Trick im Function Calling verstanden.
Zwei Metriken, die nichts miteinander zu tun haben
BFCL misst, ob ein Modell aus einem User-Prompt den richtigen Tool-Call ableitet, mit der korrekten Funktion, den richtigen Parametern und in der passenden Reihenfolge. Verschachtelte Calls. Fehlende Pflichtfelder. Widersprüchliche Inputs. Kurz: alles, was in echtem Code passiert. Dieser Score sagt etwas über die Sprachfähigkeit des Modells aus, nicht über die Stabilität deiner Pipeline.
Schema-Compliance misst etwas anderes: gegeben, das Modell hat sich für einen Tool-Call entschieden, ist die Ausgabe ein gültiges JSON nach deinem Schema? Mit den richtigen Feldnamen, den richtigen Typen, ohne halluzinierte Zusatzfelder?
Das eine ist eine semantische Frage. Das andere ist eine syntaktische. Du kannst die zweite zu 100 Prozent lösen, ohne die erste auch nur einen Punkt zu verbessern. Genau das tun Structured Outputs, und genau deshalb sind sie so wichtig.
Wo der 70-Prozent-Score in Produktion landet
Klarna hat im Laufe von 2025 öffentlich zurückgerudert. CEO Sebastian Siemiatkowski erklärte gegenüber Bloomberg, die KI-Agenten hätten “schlechtere Qualität als erwartet” geliefert. Teile der Kundendienst-Automatisierung wurden zurückgenommen, menschliche Agenten wieder eingestellt. Die Agenten haben nicht versagt, weil das Modell zu dumm war. Sie haben versagt, weil zwischen “richtige Antwort im Test” und “robustes Verhalten in der Edge Case” eine Lücke klafft, die der BFCL-Score nicht schließt.
Air Canada hat das in juristisch eindeutiger Form gezeigt. Im Fall Moffatt vs. Air Canada, entschieden vom Civil Resolution Tribunal in British Columbia am 14. Februar 2024, gab der Chatbot der Fluggesellschaft eine falsche Auskunft über einen Bereavement-Rabatt. Das Tribunal sprach dem Kläger 812 kanadische Dollar Schadensersatz zu mit der Begründung, der Bot sei keine eigenständige juristische Entität und Air Canada hafte für seine Aussagen wie für die jedes anderen Vertreters.
Beides sind keine Modellprobleme. Beides sind Produktionssystemprobleme. Niemand fragt vor Gericht, ob das Modell auf BFCL gut abgeschnitten hat.
Die Adoption überholt die Reife
Der Datadog State of AI Report 2026 zeigt, dass sich der Anteil von Unternehmen mit produktiv eingesetzten Agenten von 9 Prozent (2024) auf 18 Prozent (2025) verdoppelt hat. In zwölf Monaten. Das ist die Geschwindigkeit, mit der Tool-Use in die Produktion wandert, und sie überholt die Geschwindigkeit, mit der die Deployment-Patterns reifen. Wer 2025 noch experimentiert hat, baut 2026 produktiv. Aber die Architekturmuster, die einen Agenten von einer Demo zu einem zuverlässigen System machen, sind in den meisten Teams nicht angekommen.
Genau hier wird das BFCL-Score-Argument trügerisch. “Wir nehmen das Modell mit dem höchsten Score” klingt vernünftig. Der Score sagt aber nichts darüber aus, ob deine Tool-Calls in der zehntausendsten Anfrage immer noch valides JSON sind.
Das Gegenargument: Bessere Modelle lösen das Problem
Die naheliegende Antwort lautet: Wartet einfach auf das nächste Modell. GPT-6, Claude 5, Gemini 3 Pro werden den BFCL-Score auf 80 Prozent drücken, dann auf 90, und dann ist das Thema gelaufen.
Die Daten widersprechen. BFCL v4 zeigt seit zwei Generationen denselben Korridor. GPT-5 ist nicht besser als Claude Sonnet 4, das nicht besser ist als GLM-4.5. Die Plateauisierung hat einen Grund: BFCL misst genau das, was Sprachmodelle strukturell schlecht können — saubere Entscheidungen unter mehrdeutigem Input, ohne Tendenz zur Halluzination eines passenden Parameters.
OpenAI hat das Problem nicht durch ein besseres Modell gelöst. Im Gegenteil: Structured Outputs nutzen dieselben Gewichte wie der Standardmodus, dieselbe Architektur, dieselbe Inferenz-Pipeline. Der Unterschied liegt eine Schicht tiefer, im Decoding. Das ist die eigentliche Aussage. Nicht das Modell ist das Bottleneck. Sondern die Garantien, die du ihm zur Laufzeit aufzwingst.
Was im Decoder passiert
Constrained Decoding mit einer Finite State Machine funktioniert so: Dein JSON-Schema wird zu einem Automaten kompiliert. Während das Modell Token für Token generiert, prüft die FSM bei jedem Schritt, welche der nächsten möglichen Tokens überhaupt kompatibel mit einem gültigen Schema-Pfad sind. Alle anderen werden in der Token-Wahrscheinlichkeitsverteilung auf null gesetzt. Das Modell kann gar kein ungültiges JSON mehr produzieren, weil die Tokens, die es ungültig machen würden, im Sampling nicht mehr existieren.
Das Open-Source-Projekt XGrammar hat diesen Ansatz so weit optimiert, dass er seit März 2026 als Standard-Backend in vLLM und SGLang eingesetzt wird, mit minimalem Latenz-Overhead gegenüber unconstrained Decoding. Was OpenAI hinter dem Strict Mode versteckt, ist als offene Implementierung verfügbar und produktionsreif.
Kein Fine-Tuning. Kein RLHF. Keine Modell-Verbesserung. Ein Output-Constraint auf Inferenz-Ebene löst das Schema-Compliance-Problem deterministisch — während das Modell selbst weiterhin halluzinieren, danebenliegen oder den falschen Tool-Call wählen kann. Das löst die syntaktische Frage. Die semantische bleibt offen.
Was du jetzt anders bauen solltest
Wenn dein Tool-Use-Agent in Demos überzeugt und in Produktion in unerwarteten Punkten bricht, liegt das fast nie am Modell. Es liegt an drei Schichten, die in den meisten Implementierungen fehlen oder zu dünn sind.
Trenne Schema-Validierung von Modellauswahl. Ziehe Constrained Decoding über jeden Tool-Call, der eine strukturierte Antwort braucht. Nutze die OpenAI Structured Outputs, wenn du auf OpenAI bist. Nutze XGrammar via vLLM oder SGLang, wenn du selbst hostest. Anthropic bietet mit Tool-Use-Schemas einen vergleichbaren Mechanismus. Erst wenn das JSON garantiert valide ist, ist es überhaupt sinnvoll, Modelle nach BFCL-Score zu vergleichen.
Baue Validierung als zweite Schicht ein. Ein gültiges Schema heißt nicht, dass die Werte sinnvoll sind. Ein Tool-Call mit quantity: -3 ist syntaktisch korrekt und semantisch Müll. Validierungsregeln, Sanity Checks und Plausibilitätsgrenzen gehören zwischen Modell und Tool-Call-Execution, nicht in das Modell hinein.
Logge auf Tool-Call-Ebene, nicht auf Session-Ebene. Wenn dein Agent in der zehntausendsten Anfrage bricht, willst du wissen, welcher Tool-Call mit welchen Parametern. Strukturierte Logs mit User-ID, Tool-Name, Eingabe-Hash, Ausgabe-Hash und Zeitstempel sind die Forensik, die du brauchst, um zwischen “das Modell hat halluziniert” und “die Eingabe war wirklich kaputt” unterscheiden zu können.
Die nüchterne Lesart
BFCL ist nicht falsch. Der Score sagt etwas Wahres über Modelle aus. Aber er sagt es über Modelle, nicht über Systeme. Wer einen Agenten produktiv schaltet, betreibt kein Modell. Er betreibt ein System aus Prompt, Modell, Decoder, Validator, Tool-Adapter und Logging-Schicht. Genau eine dieser Schichten lässt sich durch ein neues Modell verbessern. Die anderen fünf entscheiden, ob das System die zehntausendste Anfrage übersteht.
Klarna hat gemerkt, dass das Modell nicht das Problem war. Air Canada hat es vor Gericht gelernt. Die 18 Prozent Unternehmen mit Agenten in Produktion lernen es gerade. Wer den Unterschied zwischen Benchmark und Produktion früh sieht, baut die fehlenden Schichten ein, bevor der eigene Vorfall kommt.
Wer wissen will, welche Architekturmuster sich gerade durchsetzen, welche Decoder-Bibliothek als nächstes Standard wird und wo die Lücke zwischen Demo und Produktion in den nächsten Monaten am teuersten wird: Der KI-Syndikat Newsletter ordnet diese Verschiebungen einmal pro Woche ein, mit Quellen und ohne Schaumschlägerei.