Lokale LLMs für Tool-Aufrufe bewerten
Ein Modell kann überzeugend schreiben und trotzdem ein schwacher Werkzeugnutzer sein. Für einen Tool-Aufruf muss es erkennen, ob eine Aktion nötig ist, das passende Werkzeug auswählen, gültige Argumente erzeugen und das Ergebnis in den nächsten Schritt einordnen. Das sind mehrere Fähigkeiten, keine einzelne Eigenschaft mit dem Namen „agentisch“.
Wer lokale Modelle auswählt, sollte sie deshalb mit einem klaren Testfallkatalog prüfen statt mit einer allgemeinen Textbewertung.
Was ein Test abdecken sollte
Ein kleiner, aussagekräftiger Katalog enthält verschiedene Klassen:
- kein Aufruf nötig: Die Frage lässt sich mit dem gegebenen Kontext beantworten.
- ein eindeutiger Aufruf: Name und Argumente sind klar vorgegeben.
- mehrere mögliche Werkzeuge: Das Modell muss nach Zweck unterscheiden.
- unvollständige Anfrage: Es muss nachfragen, statt Werte zu erfinden.
- fehlerhaftes Tool-Ergebnis: Es muss den Fehler verständlich behandeln.
- mehrstufige Aufgabe: Ein Ergebnis wird erst nach einem weiteren Aufruf nutzbar.
Die OpenAI-Dokumentation zu Function Calling beschreibt die Trennung zwischen Modellentscheidung, Funktionsschema und Ausführung.[1] Diese Trennung ist auch für lokale Tests wichtig: Das Modell soll Vorschläge als strukturierte Daten erzeugen; die Anwendung kontrolliert, ob und wie etwas ausgeführt wird.
Vier getrennte Bewertungen
Ein Test sollte mindestens diese Ergebnisse erfassen:
- Auswahl: Wurde das richtige Werkzeug gewählt oder keines, wenn keines nötig war?
- Argumente: Entsprechen Typen, Pflichtfelder und Werte dem Schema?
- Format: Lässt sich die Ausgabe zuverlässig maschinell verarbeiten?
- Folgeverhalten: Nutzt das Modell Tool-Ergebnisse korrekt und erkennt es Fehler?
Ein einzelner Prozentwert kann später folgen, darf diese Unterschiede aber nicht verdecken. Ein ungültiges JSON, eine falsche Auswahl und ein halluziniertes Argument verlangen unterschiedliche Verbesserungen.
Prompt-Vorlage und Laufzeit mitprüfen
Das Grundmodell ist nicht die ganze Erklärung. Chat-Vorlagen legen Rollen, Sondertokens und gegebenenfalls die Darstellung von Funktionsdefinitionen fest. In lokalen Umgebungen kann eine fehlende oder unpassende Vorlage ein Ergebnis verschlechtern, das fälschlich dem Modell zugeschrieben wird.
Die Serverdokumentation von llama.cpp zeigt, dass Tool-Aufrufe über ein definiertes API-Format und unterstützte Vorlagen vermittelt werden.[2] Vor einem endgültigen Urteil sollte daher geprüft werden, welche Vorlage, welches Modellformat und welche Laufzeit tatsächlich verwendet wurden.
Sichere und nützliche Tests
Gute Testdaten brauchen keine echten Konten, private Dokumente oder folgenreiche Aktionen. Fiktive Kalendertermine, öffentliche Wissensabfragen und harmlose strukturierte Objekte reichen aus, um Auswahl und Schemaeinhaltung zu prüfen. Die erwartete Aktion muss pro Fall vorab festgelegt sein; sonst wird aus der Bewertung nachträgliche Interpretation.
Wichtig ist auch eine Negativklasse: Das Modell darf nicht aus Gewohnheit ein Werkzeug wählen. Ein System, das bei einer direkten Frage unnötig handelt, ist nicht autonomer. Es ist weniger kontrollierbar.
Fazit
Tool-Nutzung wird glaubwürdig, wenn sie als überprüfbare Schnittstellenkompetenz behandelt wird. Teste konkrete Werkzeuge, dokumentiere Vorlage und Laufzeit, trenne Fehlerarten und wiederhole die Fälle nach Änderungen. Dann ist die Modellwahl keine Wette auf einen Namen, sondern eine nachvollziehbare technische Entscheidung.