Gorilla: Ein Repository, drei Werkzeuge für Function Calling

Welches Problem Gorilla adressiert

Ein Sprachmodell, das eine Funktion aufrufen soll, muss zwei Dinge gleichzeitig treffen: den semantisch passenden Endpunkt auswählen und die Argumente syntaktisch korrekt bilden. Das README formuliert das Ziel so, dass Gorilla bei einer natürlichsprachlichen Anfrage zu dem semantisch und syntaktisch korrekten API-Aufruf kommt. Der Adressat sind damit nicht Endanwender, sondern Entwickler, die Tool-Aufrufe in eine Anwendung einbauen und dafür entweder ein Modell feinabstimmen oder ein vorhandenes Modell bewerten wollen. Das Repository ist ausdrücklich kein Dienst. Es enthält Inferenzcode unter gorilla/inference, Evaluationscode unter gorilla/eval und mit APIBench unter data eine Sammlung von APIs, die das README als größte kuratierte Sammlung dieser Art bezeichnet. Wer eine Bibliothek sucht, die zur Laufzeit Funktionsaufrufe ausführt, wird hier nicht fündig. Wer wissen will, welches Modell Funktionsaufrufe zuverlässig bildet, schon.

Wie das Repository aufgebaut ist

Die Ordnerstruktur trennt drei Aufgaben. gorilla/inference enthält den Code zum Ausführen der feinabgestimmten Modelle, gorilla/eval den Code zum Nachvollziehen der Ergebnisse aus dem Paper, data beherbergt APIBench. Dazu kommen eigenständige Teilprojekte, die jeweils einen eigenen Ordner mit eigener Dokumentation haben: berkeley-function-call-leaderboard, goex und agent-arena. Diese Aufteilung ist der wichtigste Hinweis darauf, wie das Projekt gelesen werden will. Es ist keine einzelne Anwendung mit einer Einstiegsdatei, sondern eine Sammlung, deren Teile unterschiedlich schnell veralten. Die Release-Historie stützt diesen Eindruck: v1.1, v1.2 und v1.3 sind sämtlich Aktualisierungen der Leaderboard, nicht des Inferenzcodes. Der letzte Push datiert auf April 2026, die jüngste Veröffentlichung auf Juli 2025. Wer den Inferenzpfad nutzt, sollte deshalb prüfen, ob er noch zum aktuellen Stand der Modelle passt, statt von der Aktivität im Repository auf die Pflege aller Ordner zu schließen.

Der Datenfluss bei einem Tool-Aufruf

Aus der Beschreibung lässt sich ein Ablauf ableiten, der in drei Schritten verläuft. Zuerst liegt eine natürlichsprachliche Anfrage vor. Dann wählt das Modell aus einer Menge von API-Beschreibungen eine Funktion aus und erzeugt die zugehörigen Argumente. Schließlich wird der Aufruf gebildet. Genau an dieser Stelle setzen die Benchmarks an. BFCL V3 führte laut README ein zustandsbasiertes Evaluationssystem ein, das mehrstufige Abläufe und Dienstzustände prüft. Das bedeutet: bewertet wird nicht nur, ob ein einzelner Aufruf formal korrekt ist, sondern ob eine Folge von Aufrufen den erwarteten Zustand hinterlässt. BFCL V4 Agentic erweitert das um Websuche mit mehrstufigem Schlussfolgern und Fehlerbehebung, um Speicherverwaltung für Agenten und um eine Auswertung der Formatempfindlichkeit. Der letzte Punkt ist der praktisch relevanteste, weil er die Frage berührt, wie stark die Leistung eines Modells von der Schreibweise des Prompts abhängt. GoEx setzt eine Ebene tiefer an und führt laut README Laufzeitkonzepte wie post-facto validation, undo und damage confinement ein, also die Möglichkeit, eine bereits ausgeführte Aktion nachträglich zu bewerten oder zurückzunehmen.

Inbetriebnahme: was das Material hergibt

Konkrete Befehle nennt das vorliegende Material nicht. Das README verweist für die Kommandozeile auf inference/README.md und für die Nachvollziehbarkeit der Paper-Ergebnisse auf gorilla/eval. Für die Leaderboard-Arbeit ist der relevante Ordner berkeley-function-call-leaderboard mit der Datei CHANGELOG.md, die das README als Ort für Datensatz- und Modellaktualisierungen benennt. Wer das Projekt ausprobieren will, muss sich also durch die README-Dateien der einzelnen Unterordner arbeiten, statt mit einer einzigen Installationsanweisung ans Ziel zu kommen. Das ist eine echte Hürde und kein Detail: die drei Teile haben unterschiedliche Abhängigkeiten und unterschiedliche Zielsetzungen. Ein Modell lokal auszuführen ist etwas anderes, als eine Benchmark gegen einen API-Anbieter laufen zu lassen. Ohne die Unterordner-READMEs lässt sich nicht sagen, welche Python-Version, welche Pakete oder welche Konfigurationsschlüssel erwartet werden. Ich habe das Projekt nicht installiert und kann deshalb keine Befehlsfolge bestätigen.

Wo die Grenzen liegen

Der offensichtlichste Vorbehalt betrifft die Rolle des Repositories. Es ist eine Forschungs- und Evaluationsinfrastruktur, kein Produkt. Für den Betrieb einer Anwendung fehlen Zusagen zu Verfügbarkeit, Latenz und Fehlerbehandlung. Die Leaderboard führt laut README seit April 2024 Kosten- und Latenzmetriken, aber das sind Messwerte über Modelle, keine Garantien für einen Dienst. Ein zweiter Vorbehalt betrifft die Bewertung selbst. BFCL V2 Live setzt auf unternehmensseitig beigesteuerte Daten und reale Szenarien. Solche Daten sind wertvoll, aber sie sind auch an die Mitwirkenden gebunden, die sie eingereicht haben, und dürften sich in Zusammensetzung und Schwierigkeit zwischen den Versionen unterscheiden. Ein dritter Punkt ist die Formatempfindlichkeit, die V4 ausdrücklich als eigenes Bewertungsthema führt. Wenn ein Modell je nach Prompt-Formulierung unterschiedlich gut abschneidet, dann ist eine einzelne Platzierung in einer Rangliste nur dann aussagekräftig, wenn die eigene Prompt-Form der getesteten ähnelt. Wer aus einem Leaderboard-Platz direkt eine Architekturentscheidung ableitet, überspringt diesen Schritt.

Was sich stattdessen anbietet

Die naheliegende Alternative ist, direkt die Function-Calling-Schnittstellen der Modellanbieter zu nutzen, also die nativen Tool-Aufrufe von OpenAI, Anthropic oder Google, und die Auswahl anhand eigener Testfälle zu treffen. Der Unterschied im Ansatz ist grundlegend. Gorilla stellt eine Bewertungsinstanz und einen Trainingsdatensatz bereit, mit dem sich ein Modell auf eine API-Menge abstimmen lässt. Die Anbieter-Schnittstellen liefern dagegen den Aufrufmechanismus selbst, ohne Aussage darüber, welches Modell ihn besser beherrscht. Beide Ansätze schließen sich nicht aus: man kann die BFCL als Auswahlhilfe verwenden und anschließend die native Schnittstelle des gewählten Anbieters einsetzen. Was Gorilla nicht ersetzt, ist eine Bibliothek zur Ausführung und Validierung von Aufrufen im eigenen System. Genau dort setzt GoEx an, allerdings ebenfalls als Forschungsbeitrag mit eigener Dokumentation und ohne Betriebszusagen.

Pflegeaufwand und Lizenz

Der Code steht unter Apache-2.0, das README nennt die Gorilla-Modelle ausdrücklich als kommerziell nutzbar und ebenfalls Apache-2.0-lizenziert. Das ist eine Aussage über den Code und über die zum damaligen Zeitpunkt veröffentlichten Modelle. Für die auf Hugging Face bereitgestellten Gewichte ist damit nichts gesagt, und das ist der Punkt, an dem vor einem kommerziellen Einsatz die eigentliche Prüfung ansetzt: die Lizenzangabe beim jeweiligen Modell, nicht die des Repositorys. Beim Pflegeaufwand zeigt die Release-Historie ein klares Muster. Zwischen v1.1 im August 2024 und v1.3 im Juli 2025 liegen drei Aktualisierungen der Leaderboard, jede mit eigenem CHANGELOG-Eintrag. Wer die Benchmark in eine eigene Auswertung einbaut, muss mit Änderungen an Kategorien und Bewertungslogik rechnen und die CHANGELOG.md im Leaderboard-Ordner mitverfolgen. Wer nur den Inferenzcode nutzt, hat es mit einem ruhigeren Teil des Repositories zu tun, dessen Aktualität dafür weniger offensichtlich ist. Diese beiden Aufwände sind verschieden und sollten nicht in einen Topf geworfen werden.

Redaktionelles Fazit

Wer ein Modell für Tool-Aufrufe auswählen will, findet in der BFCL das konkreteste Hilfsmittel, das dieses Repository bietet, und sollte vor jedem Einsatz die im CHANGELOG unter berkeley-function-call-leaderboard/CHANGELOG.md dokumentierten Versionssprünge prüfen, weil sich zwischen v1.1 und v1.3 sowohl Kategorien als auch Bewertungslogik geändert haben. Wer dagegen eine gehostete API mit Zusagen zu Latenz oder Verfügbarkeit sucht, ist hier falsch: das Repository liefert Code und Daten, keinen Betrieb. Vor dem ersten eigenen Lauf empfiehlt sich ein Blick auf die Lizenzhinweise der Modelle auf Hugging Face, denn Apache-2.0 für den Code sagt nichts über die Gewichte.

Offizielle Quellen

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. ShishirPatil/gorilla on GitHub