Ein Sprachmodell kann in einem sauberen Benchmark starke Ergebnisse erzielen und dennoch an mehrdeutigen Fällen scheitern, die für Nutzer in der Produktionsumgebung tatsächlich relevant sind. Das ist die zentrale Lehre, die GitHub in einem von Mariko Wakabayashi und Zixiao Chen am 25. August 2026 veröffentlichten Beitrag darstellt. Grundlage ist die Erfahrung mit der Bewertung eines auf einem Sprachmodell basierenden Systems, das dabei helfen soll, Fehlalarme innerhalb von GitHub Secret Scanning zu reduzieren.
Die Geheimnisprüfung sucht nach Zugangsdaten wie Token und Schlüsseln, die in einem Software-Repository abgelegt worden sein könnten. Einige Zeichenfolgen ähneln jedoch Geheimnissen, ohne echte Zugangsdaten zu sein. Dadurch müssen Entwickler Warnungen prüfen, die keine Bearbeitung erfordern. Für das Team lautete die Frage daher nicht, ob das Modell eine einzelne Zeichenfolge klassifizieren kann, sondern ob es die Menge an Rauschen verringern und zugleich eine ausreichende Trefferquote aufrechterhalten kann, damit ein sicherheitskritischer Workflow zuverlässig bleibt.
Beginnen Sie mit der Produktentscheidung, nicht mit der Modellauswahl
GitHub empfiehlt, zunächst die Entscheidung festzulegen, die durch die Bewertung unterstützt werden soll, bevor der Prompt angepasst, zusätzlicher Kontext hinzugefügt oder das Modell gewechselt wird. Bei der Geheimnisprüfung bestand das Ziel darin, Fehlalarme zu reduzieren und die Präzision zu erhöhen, während die Trefferquote als Sicherheitsbeschränkung diente. Ein echtes Zugangsmittel versehentlich zu verbergen, kann gefährlicher sein, als einen Entwickler zur Prüfung einer zusätzlichen Warnung aufzufordern.
Praktisch wurden die Bewertungskriterien in drei Ebenen aufgeteilt: ein Basisergebnis zur Messung des Nutzens, nämlich die Verringerung von Fehlalarmen und die Präzision; eine Sicherheitsbeschränkung in Form der Trefferquote; sowie betriebliche Leitplanken wie Antwortzeit, Kosten, Zuverlässigkeit und Kompatibilität mit der Produktionsumgebung. Eine Verbesserung der Präzision gilt damit nicht automatisch als Erfolg, wenn sie mit einem nicht akzeptablen Rückgang der Trefferquote einhergeht oder das System langsam, teuer oder schwer integrierbar macht.
Machen Sie die Bewertung zu einem wiederholbaren Integrationstest
Die Bewertung ist kein einzelner Schritt vor der Einführung. Prompts, Modelle, die Art der Eingabekonstruktion und die sie umgebende Systemlogik verändern sich ständig. Jede Änderung kann eine Verbesserung oder Verschlechterung bewirken oder das Fehlermuster an eine andere Stelle verlagern. Deshalb führte GitHub die Bewertung nach jeder wichtigen Änderung erneut durch und protokollierte jedes Mal die Version des Prompts und des Modells, den Datensatz sowie die Systemeinstellungen.
Außerdem isolierte das Team in jedem Experiment jeweils eine zentrale Variable. Es verglich eine Promptänderung mit einer bekannten Basis, bevor es gemeinsam mit ihr ein Modell-Upgrade testete. Prompts und Bewertungseinstellungen wurden wie Code behandelt: Sie wurden versioniert, Änderungen dokumentiert und frühere Einstellungen so bewahrt, dass sie erneut ausgeführt und zurückgesetzt werden konnten. Dadurch lässt sich erkennen, warum eine Verbesserung oder Verschlechterung eingetreten ist, statt sie fälschlicherweise der letzten Änderung zuzuschreiben.
Simulieren Sie die Produktionsaufgabe und beschränken Sie sich nicht auf saubere Daten
Offline-Bewertungsergebnisse sind besonders nützlich, wenn sie der tatsächlichen Aufgabe ähneln. Bei der Geheimnisprüfung betrachtet das Modell nicht unbedingt einen isolierten Wert, sondern einen Kandidaten innerhalb von umgebendem Code und ergänzenden Informationen, die unvollständig oder verstreut sein können. Es könnte sich auf einen anderen Wert konzentrieren, der sicherheitsrelevanter erscheint, etwa ein Test-Token im Code, statt den zu bewertenden Kandidaten zu beurteilen.
Daher sollten die Merkmale der Produktionsaufgabe erhalten bleiben, darunter der zu bewertende Kandidat, der umgebende Kontext, ergänzende Informationen, die Art der Eingabeformatierung und der Durchsetzung von Einschränkungen sowie die umfassendere Systemlogik. Wenn die Bewertung deutlichere Beispiele und vollständigeren Kontext als die Realität verwendet, kann das Ergebnis ein leichteres Problem widerspiegeln als jenes, mit dem das System nach der Einführung konfrontiert wird.
Behandeln Sie Labels und Daten als überprüfbare Belege
Ein bestimmtes Ergebnis im Produkt bedeutet nicht, dass es eine verlässliche Ground Truth darstellt. Das Schließen einer Warnung bei der Geheimnisprüfung kann bedeuten, dass die Zugangsdaten ausgetauscht wurden, dass das Risiko akzeptiert wurde, dass die Warnung zur Eröffnung eines Workflows geschlossen wurde oder dass sie falsch klassifiziert war. Diese Fälle sehen in Workflow-Daten ähnlich aus, beantworten bei der Bewertung jedoch nicht dieselbe Frage.
Vor der Verwendung von Produktionsdaten sollte geklärt werden, wie das Label erstellt wurde, ob es zur Bewertungsfrage passt und ob unterschiedliche Ergebnisse in einer einzigen Kategorie zusammengefasst wurden. GitHub schlägt vor, wichtige oder mehrdeutige Kategorien durch Menschen prüfen zu lassen, statt anzunehmen, dass jedes Label korrekt ist. Synthetische Daten und offene Benchmarks können Lücken in der Abdeckung schließen, insbesondere bei seltenen Fällen wie fehlendem Kontext, ungewöhnlicher Formatierung und Werten, die Zugangsdaten ähneln. Sie sollten produktionsnahe Daten jedoch ergänzen und nicht ersetzen.
Analysieren Sie Fehler und verwenden Sie das bewertende Modell mit Vorsicht
Gesamtmetriken zeigen dem Team, ob sich das System verbessert hat, erklären aber nicht, was als Nächstes geändert werden sollte. Daher überprüfte GitHub Stichproben von falsch positiven und falsch negativen Ergebnissen und ordnete ihre möglichen Ursachen dem Modell, dem Prompt, den Eingaben, der Pipeline, dem Datensatz oder den Labels zu. Diese Klassifizierung verwandelt ein allgemeines Qualitätsproblem in eine konkrete technische Aufgabe: eine bessere Eingaberahmung, eine andere Kontextkonstruktion, eine Datenbereinigung oder eine klarere Produktpolitik.
Ein weiteres Sprachmodell kann als Bewerter eingesetzt werden, um den Aufwand der menschlichen Prüfung zu verringern, indem es eindeutige Fälle bearbeitet und mehrdeutige Fälle priorisiert. Seine Ausgaben sind jedoch keine Referenzwahrheit: Es kann sich irren oder aus dem falschen Grund mit dem bewerteten Modell übereinstimmen. Das sicherere Muster besteht darin, Fälle mit geringer Sicherheit, widersprüchliche Fälle oder Fälle mit hoher Auswirkung an Menschen weiterzuleiten, regelmäßig Stichproben aus Fällen zu nehmen, die der Bewerter mit hoher Sicherheit klassifiziert hat, und seine Abweichungen vom System und von den Prüfern zu verfolgen sowie seinen Prompt zu versionieren und zu bewerten.
Was hat die Erfahrung tatsächlich bewiesen?
GitHub berichtete, auf dem bewerteten Offline-Datensatz eine Verringerung der Fehlalarme um 95 % erreicht zu haben, während die Trefferquote innerhalb der festgelegten Sicherheitsbeschränkung blieb. Das Unternehmen stellte dieses Ergebnis jedoch nicht als Beleg dafür dar, dass sich das System in jedem Produktionsszenario auf dieselbe Weise verhalten wird. Der wichtigste Wert lag im Verständnis des Weges zu diesem Ergebnis: eine stärker an der tatsächlichen Aufgabe orientierte Bewertung, reproduzierbare Baselines und dokumentierte Fehlermuster.
Redaktionelle Einordnung von certi.news: Die eigentliche Veränderung besteht hier nicht in der Einführung eines neuen Modells, sondern darin, die Bewertung von LLM-Systemen von einem Benchmark-Experiment in einen kontinuierlichen technischen Prozess zu überführen, der mit einer klaren Entscheidung sowie Sicherheits- und Betriebsgrenzen verbunden ist. Das ist für Software-, Sicherheits- und Entwicklerwerkzeugteams relevant, weil die Verbesserung einer einzelnen Metrik einen gefährlichen Rückgang der Trefferquote oder steigende Kosten verbergen kann. Zugleich bleibt das Ergebnis auf den Bewertungsdatensatz, die Qualität der Labels und die nicht vollständig aufhebbare Lücke zwischen Offline-Test und Produktionsverhalten begrenzt. Bewertungen bilden daher eine Grundlage für den Übergang zu einem kontrollierten Produktionsexperiment, nicht aber einen Ersatz für die Überwachung von Risiken nach der Einführung.