„A language model can perform well on a clean benchmark and still struggle with the cases that matter in production.“ Das Zitat beschreibt das Kernproblem der LLM-Evaluierung. Ein Benchmark ist eine kontrollierte Umgebung mit sauberen Daten und klaren Erwartungen. Die Produktion ist das nicht. Dort treffen unvollständige Kontexte, uneindeutige Eingaben und widersprüchliche Labels aufeinander. Wer LLM-Systeme ernsthaft einsetzen will, braucht eine Evaluierungsstrategie, die näher an der Realität liegt als ein kuratiertes Testset.
Der Erfahrungsbericht, der diesem Beitrag zugrunde liegt, beschreibt ein LLM-basiertes System, das False Positives beim GitHub Secret Scanning reduzieren soll. Secret Scanning erkennt Zugangsdaten wie Tokens und Schlüssel, die versehentlich in ein Repository gelangt sind. Ein Teil dieser Funde sieht zwar wie echte Zugangsdaten aus, ist aber harmlos. Entwickler verlieren dann Zeit mit der Prüfung solcher Alerts, obwohl keine Maßnahme nötig ist. Das Team stand vor einer typischen Produktionsfrage: Kann ein LLM die Spreu vom Weizen trennen, ohne relevante Alerts zu übersehen? Eine reine Benchmark-Aufgabe wäre gewesen, Strings korrekt zu klassifizieren. Die eigentliche Herausforderung war eine andere: die Fehlalarmrate senken, ohne die Sicherheit zu gefährden.
Am Anfang steht die Produktentscheidung, nicht das Modell
Für die Entwicklung dieses Systems war die Frage entscheidend: Kann die Lösung Fehlalarme reduzieren, ohne die Erkennungsrate realistischer Bedrohungen zu senken? Das klingt naheliegend, ist es aber nicht. Ohne eine klare Produktentscheidung verliert man sich in Prompt-Optimierung und Modellvergleichen, ohne zu wissen, was erreicht werden soll. Die Autoren raten, zuerst festzulegen, welche Fehler vermeidbar sein müssen und welche Kennzahlen die Entscheidung tragen.
Das Team entschied: Ein übersehener echter Credential ist schwerwiegender als ein zusätzlicher Fehlalarm. Precision und Recall wurden nicht gleich behandelt. Precision war das primäre Ziel, denn sie misst, wie viele der gemeldeten Alarme wirklich relevant sind. Recall diente als Sicherheitskriterium. Ein Experiment durfte nur weiterlaufen, wenn der Rückgang echter Erkennung innerhalb eines vorher festgelegten Rahmens blieb. Dazu kamen operative Rahmenbedingungen wie Latenz, Kosten, Zuverlässigkeit und die Kompatibilität mit der bestehenden Pipeline.
Ein Beispiel verdeutlicht das: Experiment A verbessert Precision stark, fällt aber unter den Recall-Schwellenwert. Experiment B bringt eine moderate Verbesserung, bleibt aber im erlaubten Bereich. Nur Experiment B ist aus Produktsicht ein Fortschritt. Diese Unterscheidung fehlt oft, wenn Teams nur einen Modellwechsel testen. Die Evaluierung von LLM-Systemen im Produktionsumfeld verlangt mehr als einen sauberen Testlauf. Sie verlangt eine klare Vorstellung davon, was das System verbessern soll.
Offline-Evaluation wie einen Integrationstest behandeln
Eine einmalige Evaluierung reicht nicht. Ändern sich Prompt, Modell, Eingabekonstruktion oder die Logik im Umfeld, verschiebt sich das Verhalten. Deshalb haben die Entwickler die Offline-Evaluation wie einen Integrationstest behandelt. Bei jeder relevanten Änderung lief sie erneut. Auch die Reproduzierbarkeit war wichtig. Zu jedem Lauf gehörten Prompt-Version, Modellversion, Datensatzversion und Systemkonfiguration. Nur so lässt sich beantworten, ob eine Änderung wirklich geholfen hat oder ob sich Fehler nur verschoben haben.
Ein Grundsatz war: eine große Variable pro Experiment. Eine Prompt-Änderung wurde getrennt von einem Modell-Upgrade getestet, bevor beide zusammenkamen. Wenn zwei Dinge gleichzeitig wechseln, weiß man am Ende nicht, was die Verbesserung oder Regression verursacht hat. Der Beitrag empfiehlt, Prompts wie Code zu behandeln – versioniert, dokumentiert und jederzeit zurückrollbar. Wer diese Disziplin nicht einhält, vergleicht Äpfel mit Birnen und schreibt einem Prompt eine Verbesserung zu, die eigentlich vom Modell stammt.
Modell-Upgrades sind ein eigenes Thema. Wenn ein System nicht gut funktioniert, neigen viele dazu, den Prompt mit immer mehr Anweisungen zu füllen. Manche Probleme verschwinden, andere entstehen neu. Ein stärkeres Modell arbeitet mit einem einfacheren Prompt oft besser als das alte Modell mit viel Feintuning. Ein simpler Prompt ist leichter zu verstehen, zu testen und zu warten. Aber auch der Wechsel des Modells muss durch die Offline-Evaluation, weil er Qualität, Latenz und Kosten verändern kann.
Die Offline-Evaluation so nah wie möglich an der Produktion halten
Ein Offline-Test ist nur so gut wie seine Ähnlichkeit zum Produktionseinsatz. Das Modell bewertet selten einen einzelnen, sauber isolierten Wert. Es sieht einen Kandidaten, umgebenden Code und weitere Hinweise, die relevant, unvollständig oder irreführend sein können. Bereits kleine Unterschiede verzerren das Ergebnis. Ein bereinigtes Testset, das alle mehrdeutigen Fälle entfernt und immer vollständigen Kontext liefert, misst ein einfacheres Problem als das, was später in Produktion auftritt.
Der Beitrag nennt ein Beispiel: Eine Variable heißt candidate_value und soll bewertet werden. Daneben steht eine Variable example_token, deren Name nach einem Sicherheitswert klingt. Das Modell könnte sich auf example_token stürzen und eine plausible Erklärung für den falschen Wert liefern. In einem sauberen Evaluierungsdatensatz mit nur einem offensichtlichen Kandidaten fällt das nicht auf. In der realen Secret-Scanning-Umgebung passiert genau das. Wer ein LLM für solche Aufgaben baut, sollte die Offline-Pipeline der Produktionspipeline so ähnlich wie möglich gestalten. Sonst zeigt eine gute Offline-Bewertung nur, dass das System ein einfacheres Problem gut löst.
Produktionslabels sind Signale, keine absolute Wahrheit
Produktionsdaten sind wertvoll, aber ihre Labels entstehen oft aus Workflow-Abläufen. Ein als „dismissed“ markierter Secret-Scanning-Alert ist nicht automatisch ein False Positive. Die Entwickler nennen mehrere Gründe: Der Credential wurde rotiert, das Risiko wurde akzeptiert, der Alert musste für einen Workflow verschwinden, oder die Klassifikation war schlicht falsch. Diese Fälle können im selben Datenfeld landen, obwohl sie unterschiedliche Wahrheiten repräsentieren. Wer ein Korpus aus Produktionsdaten baut, sollte sich fragen: Wie wurde das Label erzeugt? Beantwortet es dieselbe Frage, die die Evaluierung stellen soll? Werden verschiedene Workflow-Ausgänge in einer Kategorie zusammengefasst?
Ein manueller Review ist für wichtige oder mehrdeutige Teilmengen notwendig. Ziel ist nicht, jedes unvollständige Label zu eliminieren, sondern die Datengrundlage präzise genug für die Entscheidung zu machen. Wer diese Genauigkeit ignoriert, evaluiert auf einer Statistik, die mit der echten Welt wenig zu tun hat. Bei LLM-Modellen vor dem Produktionseinsatz hängt viel davon ab, ob die Labels die tatsächliche Produktlogik abbilden oder nur eine Annäherung.
Synthetische Daten und offene Datensätze als Ergänzung nutzen
Gute produktionsnahe Daten sind nicht immer verfügbar. Am Anfang fehlen repräsentative Beispiele, oder die Daten sind sensibel. Dann helfen synthetische Daten, akademische Benchmarks und offene Datensätze. Sie füllen Lücken – etwa bei seltenen Eingabeformaten, fehlendem Kontext oder ungewöhnlichen Fehlermustern. Sie sollten die produktionsnahen Daten ergänzen, nicht ersetzen. Eine Liste von Credential-Strings zeigt, ob das Modell Formate erkennt. Sie zeigt nicht, wie es mit einem Kandidaten in echtem Code umgeht.
Die Entwickler haben externe Beispiele an ihre Aufgabe angepasst und geprüft, ob die Labels zur eigenen Produktdefinition passen. Aus real aufgetretenen Fehlermustern haben sie gezielt synthetische Fälle erzeugt. Das sagt mehr aus als ein generischer Corpus. Dass ein Modell Benchmarks kann, ist noch kein Produktionsargument. Erst wenn die Testfälle die typischen Fallstricke des eigenen Einsatzbereichs abdecken, wird daraus ein belastbares Ergebnis.
Was die LLM-Evaluierung vor dem Produktionseinsatz bedeutet
Der Erfahrungsbericht zeigt: Die Evaluierung von Large Language Models vor dem Produktionseinsatz ist kein einmaliger Check, sondern ein Prozess. Sie beginnt mit der Produktentscheidung, läuft durch eine reproduzierbare Offline-Phase und endet idealerweise in einem Online-Experiment. Im beschriebenen Fall diente die Offline-Evaluation als Filter. Erst wenn die Ergebnisse den Produktkriterien standhielten, kam es zu einem kontrollierten Test in der echten Umgebung. So verhindert man, dass ein Modell nur auf Papier gut aussieht und in Produktion unerwartet versagt.
Für dein eigenes Projekt bedeutet das: Definiere zuerst das erwünschte Verhalten, nicht die Modellarchitektur. Entscheide, welche Fehler akzeptabel sind und welche nicht. Baue die Offline-Evaluation so auf, dass sie die Produktionsrealität abbildet – inklusive Unschärfen. Versioniere deine Prompts und Modelle, damit jede Verbesserung zugeordnet werden kann. Hinterfrage Labels, bevor du sie als Ground Truth akzeptierst. Und nutze synthetische Daten, um Lücken zu schließen, ohne dich von ihnen blenden zu lassen. Wer diese Punkte beachtet, hat eine belastbare Grundlage, um LLM-Modelle vor dem Produktionseinsatz zu bewerten – jenseits von Benchmark-Zahlen, mit Blick auf False Positives, Recall und Produktionsrealität.
Quelle: github.blog
