KI-Red-Teaming als Evaluierungsdaten-Problem

Was ist Red Teaming in der KI eigentlich?

Wenn Sie bereits LLM-Evaluierungen durchführen, lautet die nützliche Antwort nicht „der Versuch, ein Modell zu jailbreaken“. Die nützliche Antwort ist eine strukturierte Adversarial Discovery, die Beweise liefert. KI-Red-Teaming ist wichtig, wenn es Ihnen hilft, bessere Evaluierungsdaten, Refusal-Tests, Schadensrubriken und Release-Entscheidungen zu entwerfen. Es ist weniger wichtig, wenn es zu einer Galerie viraler Prompts wird. [1]

Die Unterscheidung ist wichtig, da in diesem Bereich mehrere verwandte Begriffe ungenau verwendet werden. Traditionelles Cyber-Red-Teaming ist die Emulation von Angreifern gegen die Sicherheitslage eines Unternehmens. KI-Red-Teaming ist ein strukturierter Ansatz, um Fehler und Schwachstellen in KI-Systemen zu finden, oft in Zusammenarbeit mit Entwicklern. Eine Evaluierung (Eval) ist enger gefasst: Man gibt dem System eine Eingabe, wendet eine Bewertungslogik an und misst, ob es das getan hat, was einem wichtig ist. Sicherheitstests und Pre-Deployment-TEVV sind breitere Überbegriffe, die Red Teaming, Feldtests, öffentliches Feedback und formale Evaluierungen umfassen können. [1]

Das macht Demo-Jailbreaks zu einer schwachen Governance-Einheit. Das NIST warnt davor, dass Jailbreak- und Prompt-Engineering-Tests die Validität oder Zuverlässigkeit möglicherweise nicht systematisch bewerten. Microsoft betrachtet Red Teaming als eine Möglichkeit, Schäden aufzudecken und eine Risikooberfläche zu verstehen, nicht als Ersatz für systematische Messungen. AISI vertritt denselben Standpunkt von der Evaluatorenseite: Explorative Tests können auf Bedenken hinweisen, aber stärkere Behauptungen erfordern eine bessere Elicitation, Bewertung und Zuordnung zwischen Ergebnissen und Risikoschwellenwerten. [2]

Das praktische Ziel ist einfach: Entdeckungen in Fälle umwandeln, die Sie wiederholen, kennzeichnen, prüfen und weiterleiten können.

Zuerst das Bedrohungsmodell, zuletzt die Jailbreak-Galerie

Wenn ein Red-Team-Programm damit beginnt, Leute aufzufordern, „das Modell zu knacken“, führt das meist zu bunten Beispielen und schwachen Messwerten. Kehren Sie die Reihenfolge um. Beginnen Sie mit der Formulierung der Behauptung, die durch Beweise gestützt werden soll: Ermittlung von Fähigkeiten, Robustheit der Schutzmaßnahmen oder der Vergleich zwischen Systemen unter gemeinsamen Rahmenbedingungen. Definieren Sie dann die Testumgebung, die Tools und das Budget, die diese Behauptung aussagekräftig machen.

Die Richtlinien von OpenAI zur Evaluierung durch Dritte sind in diesem Punkt eindeutig: Ergebnisse sind nur dann interpretierbar, wenn der Bericht beschreibt, welche Behauptung der Aufbau stützt, wie das System getestet wurde und welche Gültigkeitsprüfungen durchgeführt wurden. [3]

Ein Bedrohungsmodell für KI-Red-Teaming sollte den Akteur, das Zielverhalten, die Angriffsfläche und den nachgelagerten Schaden benennen. AISI argumentiert, dass Evaluierungen auf explizite Risikomodelle abgestimmt sein und relevante Schadenspfade abdecken sollten. Microsoft beschreibt eine interne Ontologie, die Akteure, Taktiken, Schwachstellen und nachgelagerte Auswirkungen erfasst, da rohe Erkenntnisse ohne eine gemeinsame Struktur zu unübersichtlich sind, um daraus Schlüsse zu ziehen. [4]

Für die meisten Teams sollte die „Angriffsfläche“ nicht beim Eingabefeld enden. Wenn das bereitgestellte System über Retrieval, Tools, langen Kontext, multimodale Eingaben, Konnektoren oder Agenten-Scaffolding verfügt, gehören diese Flächen zum Geltungsbereich. Die Testumgebung verändert, was das System tun kann. OpenAI betont, dass umgebende Scaffolds die Leistung erheblich verändern können, insbesondere bei agentenbasierten Systemen. Microsoft empfiehlt in ähnlicher Weise, sowohl das Basismodell als auch die Anwendungsschicht zu testen, idealerweise über die Produktions-Benutzeroberfläche, sofern möglich. [3][5]

Hier beginnt das reine Prompt-Theater: Benutzertext wird gegen einen reduzierten Chat-Endpunkt getestet und das Ergebnis dann als Beweis für ein bereitgestelltes Produkt behandelt. Dabei können indirekte Prompt-Injections, unsichere Tool-Nutzung, zustandsbehaftete Multi-Turn-Eskalationen, abrufabhängige Fehler und umgebungsspezifisches Verhalten übersehen werden. Das Problem ist nicht, dass reine Prompt-Tests nutzlos sind. Das Problem ist, sie so zu behandeln, als würden sie das gesamte System messen.

Stichproben, Schweregrad und Beurteilung

Bei der Stichprobenziehung wird Red Teaming zum Evaluierungsdesign. Google empfiehlt vielfältige und repräsentative Eingaben über Produktrichtlinien, Anwendungsfälle, Fehlermodi, lexikalische Vielfalt und semantische Vielfalt hinweg. Microsoft empfiehlt, mit ergebnisoffenen Tests zu beginnen, um Schäden zu entdecken, und dann zu geführten Runden überzugehen, die auf einer sich entwickelnden Schadensliste basieren. In der Praxis sollte eine Stichprobe nicht aus einer öffentlichen Jailbreak-Liste und ein paar improvisierten Prompts bestehen. Sie sollte ein geplanter Querschnitt durch Schadenskategorien, Nutzerabsichten, Angriffsflächen, Sprachen und plausible Ermittlungsstrategien sein. [6]

Auch der Schweregrad benötigt eine Struktur, bevor das Programm skaliert wird. NIST definiert Risiko als eine Kombination aus Wahrscheinlichkeit und Konsequenz. Für das Red-Team-Labeling ist das ein Ausgangspunkt, keine fertige Rubrik. Die meisten Teams benötigen zudem Dimensionen wie Schadensart, Umsetzbarkeit, Reproduzierbarkeit, Realismus und die Frage, ob das Verhalten nach gewöhnlichen Schutzmaßnahmen bestehen bleibt. Diese Rubrik ist eine redaktionelle Synthese, die auf dem NIST-Risikorahmen und der Evaluierungspraxis basiert, kein zitierter Standard. [2]

Bei der Beurteilung scheitern Teams oft unbemerkt. Google merkt an, dass Menschen bedenkliche Inhalte unterschiedlich annotieren können, und empfiehlt klare Richtlinien oder Vorlagen für Bewerter. OpenAI empfiehlt klare Rubriken, beispielhafte Bewertungsstufen, Bestanden/Nicht-bestanden-Schwellenwerte und Konsensaggregation, wenn mehrere Prüfer eingesetzt werden. Bei Fällen mit hohem Schweregrad oder unklaren Richtlinien sollte menschliche Uneinigkeit als Signal über das Messsystem behandelt werden, nicht nur als Rauschen der Annotatoren. [6][7]

Daraus folgt eine nützliche Arbeitsregel: Wenn eine Erkenntnis einen hohen Schweregrad aufweist, richtlinienunklar oder domänenspezifisch ist, eskalieren Sie sie vom einfachen Labeling zur Expertenbeurteilung. Wenn sich die Prüfer nicht einig sind, ob das Modell gegen Richtlinien verstoßen hat, sollte der Fall in der Regel zu einer Überarbeitung der Rubrik führen, bevor er das Post-Training beeinflusst. Diese Empfehlung ist eine Synthese, leitet sich aber aus den zitierten Richtlinien zu Rubrikklarheit, Kalibrierung und menschlicher Überprüfung ab.

Menschliche und automatisierte Arbeit gezielt aufteilen

Automatisierung hilft am meisten, wenn es um Breite, Aktualisierung und die Erkennung schwacher Signale geht. Die Arbeit von Anthropic zu modellgeschriebenen Evaluierungen hat gezeigt, dass Modelle dabei helfen können, schnell viele relevante Evaluierungselemente zu generieren, wobei die Übereinstimmung der Crowdworker bei den Labels in diesem Umfeld hoch ist. AISI argumentiert, dass automatisierte Fähigkeitsevaluierungen skalierbar genug sind, um einen großen Teil einer bedenklichen Fähigkeitsfläche abzudecken. Google empfiehlt ebenfalls, mit Seed-Beispielen zu beginnen und diese synthetisch zu erweitern, wenn bestehende Datensätze nicht ausreichen. [8][4][6]

Dieselben Quellen definieren auch die Grenzen. AISI sagt, dass automatisierte Tests die reale Nutzung nicht widerspiegeln und für sich allein keine starken Schlussfolgerungen stützen sollten. Google warnt, dass die Genauigkeit von Klassifikatoren bei lose definierten Konstrukten gering sein kann. OpenAI sagt, dass Evaluierungen mehr sind als nur Punktzahlen, und empfiehlt, automatisierte Bewertungen mit menschlichen Urteilen zu kalibrieren. [4][6][7]

Automatisierte Probes sind in drei Dingen stark. Erstens verbessern sie die Abdeckung, indem sie mehr lexikalische und semantische Varianten generieren, als ein kleines menschliches Team produzieren kann. Zweitens machen sie Regressionstests günstig, sobald ein Fall zu einer wiederverwendbaren Evaluierung wird. Drittens ermöglichen sie es Teams, ein System in großem Maßstab mit wiederholten Stichproben anzugreifen, was wichtig ist, da sich einige Jailbreak-Klassen mit mehr Versuchen verbessern. Die Many-Shot-Arbeit von Anthropic ist ein Beispiel dafür, wie langer Kontext neue Fehlermodi schafft. [9]

Die Tools spiegeln diese Arbeitsteilung mittlerweile wider. Microsoft PyRIT ist ein modellagnostisches Framework zur Untersuchung multimodaler Systeme und zur Wiederverwendung zusammensetzbarer Red-Team-Bausteine. AISI Inspect unterstützt Multi-Turn-Dialoge, Agenten-Scaffolds, Modellbewertungen und detaillierte Protokolle. Diese Tools sind nützlich, da Red-Team-Erkenntnisse zu analysierbaren Evaluierungsartefakten werden müssen und nicht zu losen Notizen. [10][11]

Menschen bleiben dort notwendig, wo die Frage nicht nur lautet „Hat die Richtlinie versagt?“, sondern „Was ist hier eigentlich wichtig?“. Microsoft ist hier direkt: Medizin, Cybersicherheit, CBRN, kulturübergreifende Schäden und psychosoziale Schäden erfordern fachliches Urteilsvermögen. AISI beschreibt Experten-Red-Teaming ähnlich als naturalistischer und ergebnisoffener als automatisierte Tests. [12][4]

LLM-Judges erfordern dieselbe Skepsis. OpenAI empfiehlt paarweise oder Bestanden/Nicht-bestanden-Formate, klare Rubriken und die Validierung anhand menschlicher Labels, da Judge-Modelle durch die Reihenfolge der Antworten und die Länge der Antworten verzerrt werden können. Behandeln Sie LLM-Judges wie Messinstrumente: Kalibrieren Sie sie, prüfen Sie auf Abweichungen und auditieren Sie sie regelmäßig. Geben Sie ihnen keine endgültige Autorität bei speziellen Schäden oder unklaren Richtliniengrenzen. [7]

Eine gute operative Aufteilung ist einfach. Lassen Sie die Automatisierung Kandidaten für Angriffe generieren, Seed-Sets erweitern, offensichtliche Fälle vorab kennzeichnen, Duplikate clustern und Regressionen erneut ausführen. Lassen Sie Menschen die Schadensliste definieren, unsichere oder schwere Fälle überprüfen, die Qualität der Bewerter auditieren und interpretieren, was der Systemfehler für das Produkt oder Modell bedeutet. Diese Aufteilung ist eine Synthese, die auf den oben genannten Quellen basiert.

Behandeln Sie Erkenntnisse als Datenobjekte, nicht als Anekdoten

Wenn Red-Team-Ausgaben zu wiederverwendbaren Evaluierungsdaten werden sollen, erfassen Sie mehr als nur den Prompt und die finale Antwort. Microsoft empfiehlt, mindestens das Entdeckungsdatum, eine eindeutige Kennung, den Eingabe-Prompt und Ausgabedetails aufzuzeichnen. Google empfiehlt, Ausgaben in Fehlermodi und Schäden zu annotieren. Das Log-Modell von Inspect zeigt, was eine ausgereiftere Darstellung bewahren kann: Eingabe, Sample-Metadaten, Scores, Fehler, Nachrichten und Ereignisspuren auf mehreren Granularitätsebenen. [5][6][11]

Für angewandte Teams ist das minimal nützliche Schema in der Regel größer. Behalten Sie zusätzlich zu Prompt und Antwort auch Modellversion, System-Prompt-Version oder -Hash, Tool-Konfiguration, Retrieval-Kontext oder Referenzen, Angriffsmethode, Richtlinienkategorie, Verweigerungsstatus, Reviewer-Label, Schweregrad-Label, Begründung, Beurteilungsstatus, Fall-Cluster und Routing-Status bei. Diese genaue Feldliste ist eine Synthese, aber sie ist eine praktische Erweiterung der aktuellen Richtlinien zu strukturierter Erfassung, Metadaten und Scoring.

Die Handhabung von Duplikaten ist wichtiger, als die meisten Teams erwarten. Google empfiehlt, bei der Generierung von adversariellen Datensätzen Duplikate und verrauschte Multi-Label-Beispiele zu vermeiden. Ohne Deduplizierung kollabieren „Top-Fehlermodi“ oft zu wenigen viralen Angriffs-Templates, die dann sowohl die Mitigationsarbeit als auch die Trainingsdaten verzerren. Behalten Sie ein Konzept von kanonischem Fall versus Paraphrasen-Cluster bei und berichten Sie sowohl die rohe Anzahl als auch die Anzahl einzigartiger Angriffsfamilien. Die Empfehlung zu kanonisch versus Cluster ist eine Synthese, aber die Notwendigkeit von Einzigartigkeit und sorgfältiger Zusammensetzung stammt direkt aus den Richtlinien von Google. [6]

Entscheiden Sie, was aus jedem Befund wird, bevor Sie damit trainieren

Dies ist die zentrale operative Frage, und die Antwort sollte vor dem ersten Post-Training-Meeting schriftlich festgehalten werden.

Ein Red-Team-Fall kann zu mindestens fünf verschiedenen Dingen werden: einem Trainingsbeispiel, einem wiederverwendbaren Eval-Fall, einem blockierten Holdout, einer Richtlinien- oder Rubrik-Überarbeitung oder einem Release-Gate-Nachweis. Aktuelle Primärquellen unterstützen die Notwendigkeit dieser separaten Spuren, auch wenn sie diese nicht in einem Standard-Workflow zusammenfassen. OpenAI warnt davor, Eval-Daten in das Reinforcement-Fine-Tuning durchsickern zu lassen, beschreibt produktionsabgeleitete Evaluierungen, die regelmäßig aktualisiert werden, und betont Validitätsrisiken wie Kontamination und Reward-Hacking. AISI argumentiert ähnlich für vordefinierte Schwellenwerte und wiederholte Tests über den Lebenszyklus des Modells. [13][14][3][4]

Ein Fall ist ein sinnvoller Trainingskandidat, wenn das Label stabil ist, der Fehler repräsentativ für die realistische Nutzung ist, die Richtliniengrenze klar ist und das Beispiel nicht für zukünftige Messungen reserviert ist. Anthropics frühere Red-Teaming-Arbeit ergab, dass die Verwendung von Red-Team-Daten in Sicherheitsmethoden die Anfälligkeit für den untersuchten Angriffskorpus verringerte. Deshalb sind Teams versucht, mit allem zu trainieren. Das ist auch der Grund, warum Leakage-Kontrolle wichtig ist: Wenn dieselben Fälle später als Fortschrittsnachweis verwendet werden, ist die Messung kompromittiert. [15]

Halten Sie einen Fall aus dem Training heraus, wenn er als Holdout benötigt wird, wenn er einem öffentlichen Benchmark oder einem wahrscheinlichen zukünftigen Benchmark ähnelt, wenn das Label umstritten ist oder wenn der Exploit so fallspezifisch ist, dass das Training damit dem Modell hauptsächlich beibringen würde, sich einen Patch zu merken. Anthropics BrowseComp-Kontaminationsnotiz zeigt, wie öffentliches Leakage die Ergebnisse aufblähen kann, und OpenAIs SWE-bench Verified-Analyse zeigt dasselbe Fehlermuster auf Benchmark-Ebene. In beiden Fällen ist die Lektion dieselbe: Dasselbe Artefakt kann nicht gleichzeitig Trainingsmaterial und ehrlicher Messnachweis sein. [16][17]

Praktische Routing-Regel: Wenn ein Fall einen neuartigen Fehlermodus aufgedeckt hat, blockieren Sie ihn zuerst in einem Holdout-Bucket. Erst nachdem Sie den Holdout aktualisiert und den Fix an neuen Fällen nachgewiesen haben, sollten Sie in Betracht ziehen, Varianten dieses Fehlermusters in das Training zu verschieben. Diese Regel ist eine Synthese, respektiert aber die aktuellen Leakage-Richtlinien von Anbieter- und Evaluatorenquellen.

Ein Betriebsmodell für kleine Teams, das nicht vorgibt, Sicherheit zu garantieren

Für ein kleines KI-Team ist das Ziel nicht, „alles abzudecken“. Das Ziel ist es, eine Schleife zu erstellen, die Nachweise liefert, denen Sie auch nach Änderungen am Modell noch vertrauen.

Beginnen Sie mit einem konkreten, für das Deployment relevanten Bedrohungsmodell, einer engen Produktoberfläche und einer manuellen Discovery-Runde. Verwenden Sie nach Möglichkeit diverse Tester, aber schließen Sie mindestens jemanden ein, der den Domänenschaden versteht, und jemanden, der kontradiktorisch über die Systemschnittstelle nachdenken kann. Microsoft empfiehlt diverse Tester und explizite Zuweisungen zu Schäden oder Funktionen; Google empfiehlt, mit Seed-Beispielen zu beginnen und diese sorgfältig zu erweitern; OpenAI empfiehlt, Evals frühzeitig zu erstellen, alles zu protokollieren und die Automatisierung mit menschlichen Labels zu kalibrieren. [5][6][7]

Frieren Sie dann die erste Tranche von Befunden mit hoher Konfidenz in einem zurückgehaltenen Adversarial-Eval-Set ein. Führen Sie kein Fine-Tuning mit genau diesen Fällen durch. Erstellen Sie einfache Regressionsläufe um sie herum, selbst wenn der Grader Pass-Fail mit menschlichem Audit ist. Sobald das funktioniert, fügen Sie eine zweite Spur für Trainingskandidaten hinzu und halten Sie die Trennung sauber. Die Evaluierungsrichtlinien von OpenAI betonen wiederholt zurückgehaltene Daten, Nicht-Überlappung und separate Trainingssets für Post-Training-Schleifen. [13][7]

Danach lohnt sich der Aufwand für die Automatisierung. Verwenden Sie modellgenerierte Erweiterungen, Klassifikatoren oder LLM-Judges, um die Abdeckung zu erweitern und die Überprüfungskosten zu senken, aber nur in Bereichen, in denen Sie festgelegt haben, was ein korrektes Label bedeutet. Der mehrstufige Ansatz von AISI ist eine nützliche Vorlage: Lassen Sie leichtere automatisierte Tests Bedenken schnell finden und eskalieren Sie dann zu maßgeschneiderter Elicitation und Expertenprüfung, wenn das Signal wichtig ist. [4]

Nichts davon beweist, dass ein System sicher ist. Das ist das falsche Versprechen. Ein guter Red-Team-Zyklus liefert Ihnen Fälle, die Sie reproduzieren können, Labels, die Sie verteidigen können, Holdout-Daten, mit denen Sie nicht trainiert haben, und genügend Struktur, um zu erkennen, ob eine Maßnahme das Modell verändert oder nur einen Demo-Prompt gepatcht hat.

OpenTrain kann Teams dabei helfen, Red-Teamer, Domänen-Reviewer und Evaluierungsspezialisten für diese Arbeit einzustellen. Nutzen Sie die LLM Judge-Zuverlässigkeitsreferenz für die Kalibrierung von Evaluatoren, den RLAIF vs RLHF Leitfaden für Automatisierungsgrenzen, die PRM vs ORM Referenz für das Design von Messzielen und den RLHF Scoping-Leitfaden für die Planung von Review-Zyklen. Wenn der Engpass in der personellen Besetzung des Review-Zyklus liegt, veröffentlichen Sie ein Stellenangebot.

Quellen

• NIST-Glossar: Red Team; NIST-Glossar: Artificial Intelligence Red-Teaming; NIST AI RMF Generative AI Profile
• NIST AI RMF Generative AI Profile
• OpenAI: Trustworthy third-party evaluations foundations
• AISI: Early lessons from evaluating frontier AI systems
• Microsoft Learn: Planning red teaming for LLMs
• Google: Adversarial Testing for Generative AI
• OpenAI: Evaluation best practices
• Anthropic: Discovering Language Model Behaviors with Model-Written Evaluations
• Anthropic: Many-shot jailbreaking
• PyRIT: A Framework for Security Risk Identification and Red Teaming in Generative AI Systems
• Inspect AI docs
• Microsoft Research: Lessons From Red Teaming 100 Generative AI Products; Microsoft Security Blog summary
• OpenAI cookbook: Eval-driven system design
• OpenAI: Production evaluations
• Anthropic: Red Teaming Language Models to Reduce Harms
• Anthropic: Eval-Awareness und BrowseComp
• OpenAI: Warum wir nicht mehr auf SWE-bench Verified evaluieren