Als der Phrasendetektor zweimal falsch lag

In meinem lokalen Defense-Lab-Benchmark schlug der erste gefährliche Fehler nicht beim Modell auf. Der Phrasendetektor meldete zwei Antworten als riskant.

Die Antworten enthielten Formulierungen, die der Detektor als riskante Empfehlung oder autonome Aktion las. Im Kontext waren es eine ausdrückliche Warnung vor chmod 777 und die passive Beschreibung einer bereits ersetzten Service-Unit. Ohne manuelle Prüfung hätte mein Eval zwei Fehlalarme als Sicherheitsbefund ausgegeben.

Der Fehlalarm lag im Eval

Der Detektor sollte gefährliche Handlungsempfehlungen markieren. Stattdessen behandelte er Erwähnung und Empfehlung gleich. Das ist ein kleiner technischer Fehler mit einer größeren Lehre. Auch ein deterministischer Scorer kann überzeugend falsch liegen.

Ich habe die beobachteten Formulierungen als Regressionstests ergänzt. Rohantworten und Laufkonfiguration blieben unverändert. So lässt sich später prüfen, ob die Korrektur den konkreten Fehler behebt, ohne das ursprüngliche Ergebnis umzuschreiben.

Seitdem frage ich bei jedem Eval nicht nur, wie ein Modell abgeschnitten hat. Ich prüfe auch, ob der Evaluator die Fehlerklasse tatsächlich erkennt, die sein Name verspricht.

Was der lokale Benchmark trotzdem gezeigt hat

Im breiten Lauf gingen 53 installierte Ollama-Tags durch 26 synthetische Fälle zu Cyberanalyse, Safety, Schematreue sowie Cron- und Automationsverträgen. Granite erreichte den höchsten Gesamtwert. Kein Modell bestand das Gate für unbeaufsichtigte Nutzung.

Im tieferen Defense-Lab-Lauf prüfte ich sieben Ollama-Modelle mit jeweils drei blinden Fällen. 18 von 21 geplanten Antworten kamen innerhalb des Zeitlimits zurück. qwen3.5 führte im Gesamtscore, qwen3-14b war der stärkste Kritiker und granite4.1:30b lief dreimal ins Timeout. Dieser unvollständige Lauf erlaubt keine Aussage über die Cyberkompetenz von Granite.

Die beiden Läufe hatten unterschiedliche Aufgaben und deshalb unterschiedliche Sieger. Der breite Test prüfte Vertrags- und Aufgabenabdeckung. Der tiefe Test prüfte Evidenzinterpretation und fachliche Zurückhaltung. Der eigene Benchmark bleibt nützlich, weil sein Scope sichtbar ist.

Ein Score braucht einen verstandenen Fehler

Ein Gesamtscore trennt Modellfehler, Laufzeitprobleme und Eval-Fehler nicht. Wenn eine Antwort fehlt, kann die Infrastruktur schuld sein. Wenn eine fachlich saubere Antwort verworfen wird, muss der Scorer untersucht werden. Erst wenn die Fehlerstelle bekannt ist, lohnt sich eine Korrektur.

Paper und Praxisleitfäden zu Evals geben dafür hilfreiche Heuristiken. Sie ersetzen nicht die lokale Fehleranalyse. Die zwei Fehlalarme waren für mich wertvoller als eine weitere allgemeine Metrik, weil ich ihren Auslöser nachvollziehen und als Regressionstest festhalten konnte.

Der schwer kopierbare Teil ist deshalb nicht das Modell allein. Es ist die Sammlung realer Traces, verstandener Fehler und überprüfter Korrekturen. Das Basismodell darf austauschbar bleiben.

Die Lehre aus zwei Fehlalarmen

Mein Benchmark hat Modelle verglichen. Sein wichtigster Lernmoment war ein Fehler im eigenen Detektor. Wer Evals baut, muss auch die Evals testen und jeden Score auf einen benannten, nachvollziehbaren Fehler zurückführen.

Quellen: Hamel Husain und Shreya Shankar, LLM Evals: Everything You Need to Know; NIST AI 600-1, Generative Artificial Intelligence Profile.