Gorilla: Wie Retrieval-Aware Training LLM-API-Halluzinationen von 78 % auf 11 % reduziert

Ich habe das Gorilla-Paper (Patil et al., 2023, arXiv:2305.15334, NeurIPS 2024) gelesen, da es an der Schnittstelle zweier Probleme liegt, auf die ich immer wieder stoße: Wie bringen wir einen LLM-Agenten dazu, das richtige Tool mit den richtigen Argumenten aufzurufen, und wie halten wir diese Fähigkeit aufrecht, wenn sich APIs ändern? Die Antworten hier sind praxisnah und die Zahlen überraschend stark – aber die in die Evaluierung einfließenden Annahmen verdienen mehr Aufmerksamkeit, als sie üblicherweise erhalten.

Das Paper

Gorilla, entwickelt von Shishir G. Patil, Tianjun Zhang, Xin Wang und Joseph E. Gonzalez an der UC Berkeley, adressiert ein konkretes Fehlerszenario: State-of-the-Art LLMs halluzinieren API-Aufrufe. Wenn sie aufgefordert werden, Code zu schreiben, der eine bestimmte Bibliotheksfunktion aufruft, generiert GPT-4 (Stand Mitte 2023) häufig plausibel aussehende, aber falsche Funktionssignaturen, nicht existierende Modelle oder veraltete Argumentnamen. Gorilla ist ein auf 7 Milliarden Parametern basierendes LLaMA-Modell, das speziell für die Generierung präziser API-Aufrufe feinoptimiert wurde. Es wurde mit einer Technik trainiert, die die Autoren Retriever-Aware Training (RAT) nennen. Die Idee ist simpel: Während des Trainings erhält das Modell neben der Benutzeranfrage auch die abgerufene API-Dokumentation im Format: "Verwenden Sie diese API-Dokumentation als Referenz: <retrieved_API_doc_JSON>". Dies lehrt das Modell einerseits, Dokumentationen zu lesen, und andererseits, dem abgerufenen Kontext mehr zu vertrauen als seinem parametrischen Gedächtnis – eine Eigenschaft, die sich zur Inferenzzeit auszahlt, wenn sich die Dokumentation geändert hat.

Der Evaluierungsdatensatz, APIBench, umfasst 925 HuggingFace Model Hub APIs, 95 TorchHub APIs und 696 TensorFlow Hub APIs, wobei pro API zehn synthetische Instruktionsabfragen mittels Self-Instruct generiert wurden. Als Evaluierungsmetrik dient das AST-Sub-Tree-Matching – der generierte API-Aufruf wird geparst und auf funktionale Korrektheit geprüft –, was in diesem Kontext erstmals eine fundierte Messung der Halluzinationsrate ermöglicht.

Kernaussagen

• RAT macht Dokumentationen zur Inferenzzeit lesbar. Durch das Training mit Prompts, die abgerufene Dokumentationen enthalten, lernt Gorilla, auf den abgerufenen Text zurückzugreifen, anstatt API-Details aus den Gewichten abzurufen. Das bedeutet, dass das Modell aktuell bleibt, wenn APIs weiterentwickelt werden, ohne dass ein erneutes Training erforderlich ist.
• Zero-Shot-Genauigkeit: Gorilla 59–84 %, GPT-4 18–39 %. Auf TorchHub erreicht Gorilla 59,13 % gegenüber 38,70 % bei GPT-4. Auf HuggingFace sind es 71,68 % gegenüber 19,80 %. Auf TensorFlow Hub 83,79 % gegenüber 18,20 %. Der Vorsprung ist dort am größten, wo der API-Raum am vielfältigsten ist.
• Die Reduzierung von Halluzinationen ist das Highlight. Gorillas Halluzinationsrate liegt bei 6,98 % auf TorchHub, 10,95 % auf HuggingFace und 5,40 % auf TensorFlow Hub. GPT-4-Raten liegen bei denselben Datensätzen zwischen 36,55 % und 78,65 %.
• Der Oracle-Retriever bildet die Obergrenze. Wenn das korrekte Dokument abgerufen wird (Oracle-Modus), erreicht die Genauigkeit 67–94 %. Dies ist der theoretische Bestfall für jedes RAG-basierte System, und die Lücke zwischen dem Zero-Shot-Gorilla und dieser Obergrenze zeigt das Potenzial für Verbesserungen beim Retriever auf.
• Reale Retriever schneiden schlechter ab. Der Wechsel vom Oracle zu GPT-Index zum Zeitpunkt der Evaluierung verschlechtert die Genauigkeit um 29,20 %; BM25 verschlechtert sie um 52,27 %. Die Robustheit des Modells gegenüber Retrieval-Rauschen ist real, aber nicht unbegrenzt.
• AST-Evaluierung lässt sich verallgemeinern. Der Sub-Tree-Matching-Ansatz misst, ob der generierte Aufruf funktional korrekt ist, nicht nur syntaktisch ähnlich. Dies ist die richtige Metrik für jede Aufgabe, bei der die Ausgabe Code ist, der tatsächlich ausgeführt werden soll.

Was Bestand hat – und was nicht

Die Kernbehauptung bestätigt sich: Das Fine-Tuning auf dokumentationsgestützten Prompts verbessert die Genauigkeit von API-Aufrufen dramatisch und reduziert Halluzinationen. Die AST-Evaluierungsmethodik ist wirklich neuartig und deutlich besser als String-Matching oder menschliche Evaluierung in großem Maßstab. RAT ist eine saubere, reproduzierbare Idee.

Skeptisch bin ich hinsichtlich der Reichweite des Benchmarks. Alle drei Datensätze – HuggingFace, TorchHub, TensorFlow Hub – sind ML-Modellregister mit einer sehr regelmäßigen API-Struktur: Man lädt ein Modell per Name, eventuell mit ein paar Schlüsselwortargumenten, und ruft eine Predict-ähnliche Methode auf. Die Anweisungen sind synthetisch generiert, was bedeutet, dass die Testverteilung eng mit der Trainingsverteilung verwandt ist. Ein Modell, das auf ML-API-Dokumentationen optimiert wurde, die via Self-Instruct trainiert und an Self-Instruct-Abfragen für ML-APIs evaluiert wurden, wird nicht an der Komplexität getestet, die in der Produktion tatsächlich auftritt: mehrdeutige Anfragen, mehrstufige Workflows, Typkonvertierung von Argumenten, Authentifizierung, Rate-Limits oder Fehlerbehandlung.

Der Performance-Abfall beim Retrieval ist ebenfalls größer, als das Paper suggeriert. Ein Einbruch der Genauigkeit um 52 % bei BM25-Retrieval ist katastrophal. Wenn der in der Produktion eingesetzte Retriever eher BM25 als einem Oracle ähnelt, verpuffen die Gewinne. Die Autoren räumen diese Lücke ein, bieten jedoch keinen Weg, sie zu schließen.

Schließlich ist das Modell selbst ein 7B LLaMA-Fine-Tune. Der Vergleich mit GPT-4 Zero-Shot ist beeindruckend, aber nicht ganz fair: GPT-4 wurde nicht darauf trainiert, abgerufene Dokumentationen zu nutzen. Ein RAG-erweitertes GPT-4 mit einem System-Prompt, das auf das Lesen von API-Docs ausgelegt ist, würde die Lücke mit Sicherheit erheblich schließen.

Warum das für Finance-KI wichtig ist

Das RAT-Muster ist direkt auf Beancount-Write-Back-Agenten übertragbar. Ein Beancount-Agent muss CLI-Befehle (bean-query, bean-report), Python-APIs (beancount.loader, beancount.core) und den beancount-ledger-FastAPI-Service aufrufen – jeder mit spezifischer Argument-Semantik, die zwar dokumentiert, aber nicht unbedingt in den Trainingsdaten des Modells enthalten ist. Der Gorilla-Ansatz besagt: Rufe zur Inferenzzeit den relevanten Dokumentationsschnipsel ab, injiziere ihn in den Kontext und trainiere das Modell darauf, ihn zu lesen und zu befolgen.

Die Halluzinationszahlen sind das wichtigste Signal für den Finanzkontext. Eine Halluzinationsrate von 10 % bei ML-Modellnamen ist ärgerlich. Eine Halluzinationsrate von 10 % bei Ledger-Mutations-Aufrufen – falsche Kontonamen, falsche Währungscodes, invertierte Soll/Haben-Vorzeichen – ist ein Korrektheitsfehler. Daraus folgt, dass selbst ein Gorilla-ähnlich trainierter Agent einen Validierer zur Laufzeit benötigt, bevor eine Buchung festgeschrieben wird, ganz im Sinne dessen, was CRITIC (LOG-012) über Tool-interaktive Kritik gezeigt hat. Die Erkenntnisse zur Retrieval-Verschlechterung unterstreichen dies: Wenn das reale Retrieval die Genauigkeit halbiert, darf das Sicherheitsnetz nicht allein auf der Retrieval-Qualität basieren.

Die AST-Evaluierungsmethodik lässt sich natürlich übertragen. Beancount-Transaktionen haben eine parsbare Struktur, und das Prüfen generierter Direktiven gegen ein Schema mittels AST-Matching ist genau die Art von leichtgewichtigem Validierer, der in einem Pre-Commit-Hook oder einer Agenten-Schleife laufen könnte.

Nächste Lektüre-Empfehlungen

• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789) – erweitert das API-Aufruf-Problem auf 16.000 reale REST-APIs mit mehrstufigen Tool-Nutzungsketten; adressiert direkt Gorillas Einschränkung, nur Einzelaufrufe in ML-Registern zu evaluieren.
• The Berkeley Function Calling Leaderboard (BFCL) (OpenReview:2GmDdhBdDk, NeurIPS 2024 Poster) – die direkte Weiterentwicklung von Gorilla zu einem lebenden Leaderboard, das verfolgt, wie sich Frontier-Modelle beim Function Calling über die Zeit verbessern; V3 fügt Multi-Turn-Interaktionen hinzu, V4 agentenbasierte Websuche.
• API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs – evaluiert LLMs an 73 APIs über ein breiteres Spektrum von Domänen, einschließlich Finanzen und Web-Services, mit Multi-Turn-Tool-Nutzung; eine nützliche Ergänzung zum engeren ML-Fokus von APIBench.