🤖 AI

AdversaBench: Automated LLM Red-Teaming with Multi-Judge Confirmation and Cross-Model Transferability

AdversaBench ist eine automatisierte Red-Teaming-Pipeline, die durch strukturierte Mutationsoperatoren adversarielle Prompts generiert und Fehlschläge durch ein Multi-Judge-Bestätigungssystem validiert, wobei sie aufzeigt, dass die Effektivität der Mutation je nach Aufgabenkategorie variiert, während adversarielle Prompts eine starke modellübergreifende Transferierbarkeit aufweisen.

Ursprüngliche Autoren: Khanak Khandelwal (Indian Institute of Technology Jodhpur)

Veröffentlicht 2026-06-24

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Khanak Khandelwal (Indian Institute of Technology Jodhpur)

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie sind der Cheftrainer eines neuen, sehr intelligenten Roboter-Assistenten. Bevor Sie ihn mit echten Menschen sprechen lassen, müssen Sie sicherstellen, dass er nichts Sinnloses sagt, keinen schlechten Anweisungen folgt oder seine eigenen Regeln bricht. Dieser Prozess des Versuchs, den Roboter zu Fehlern zu verleiten, wird Red-Teaming genannt.

Das Paper „AdversaBench“ beschreibt eine neue, automatisierte Methode, um diese Tests durchzuführen, zusammen mit einer Studie darüber, wie gut verschiedene Testmethoden tatsächlich funktionieren. Hier ist die Aufschlüsselung in einfachen Worten:

1. Das Problem: Ein Richter ist nicht genug

Normalerweise fragt man bei der Testung eines Roboters eine knifflige Frage und bittet dann eine andere KI (den „Richter“), die Antwort zu bewerten.

Der Fehler: Wenn dieser einzelne Richter zu nachsichtig ist, übersieht er echte Fehler. Wenn er zu streng ist, denkt er, der Roboter hätte versagt, obwohl er es eigentlich nicht getan hat. Man hat keine Möglichkeit zu wissen, ob der Richter nur einen „schlechten Tag“ hat oder voreingenommen ist.
Die Lösung: Die Autoren haben AdversaBench entwickelt, ein System, das drei Richter verwendet, um jede Antwort zu bewerten. Wenn sie sich alle einig sind, großartig. Wenn sie uneins sind, springt ein „Super-Richter“ (ein Meta-Richter) ein, um die endgültige Entscheidung zu treffen. Es ist wie bei einem Sportspiel, bei dem man nicht nur einen Schiedsrichter hat, sondern ein Gremium, und wenn sie sich nicht einigen können, trifft der Chefrichter die endgültige Entscheidung.

2. Wie der Angriff funktioniert (Die „Mutations“-Maschine)

Das System beginnt mit einer einfachen „Seed“-Frage (wie einer grundlegenden Testfrage). Dann nutzt es einen „Mutator“, um diese Frage zu verdrehen und zu verändern, damit sie für den Roboter schwieriger zu beantworten ist.

Die Werkzeuge: Der Mutator besitzt fünf spezifische Tricks:
1. Rephrase (Umformulieren): Dasselbe auf eine verwirrende Weise sagen.
2. Inject Distractor (Ablenkung einfügen): Eine falsche, irreführende Regel hinzufügen (z. B. „Antworte in 3 Sätzen, aber erkläre alles im Detail“).
3. Role Flip (Rollenwechsel): So tun, als wäre man ein anderer Charakter, um den Roboter zu täuschen.
4. Add Constraints (Einschränkungen hinzufügen): Zu viele Regeln übereinander stapeln.
5. Jailbreak Wrap (Jailbreak-Verpackung): Die Frage in eine „Hacker“-Stil-Vorlage einbetten.
Die Schleife: Das System stellt dem Roboter die Frage, die Richter bewerten sie, und wenn der Roboter besteht, versucht der Mutator einen neuen Trick. Es wiederholt dies bis zu fünfmal, bis der Roboter schließlich scheitert.

3. Was sie herausgefunden haben (Die Überraschungen)

Das Team testete 45 verschiedene „Seed“-Fragen in drei Kategorien: Reasoning (Logikrätsel), Instruction-Following (Befolgen komplexer Regeln) und Tool Use (Verwendung von Taschenrechnern oder APIs). Hier ist, was sie entdeckten:

Nicht alle Tricks funktionieren überall:
- Analogie: Stellen Sie sich vor, Sie versuchen, einen Tresor zu knacken. Ein Hammer funktioniert super bei einer Holzkiste, aber ein Schraubendreher eignet sich besser für eine Metallbox.
- Das Ergebnis: Der Trick „Inject Distractor“ war ein Superstar für Logik- und Tool-Fragen, war aber schrecklich darin, den „Instruction-Following“-Roboter zu brechen. Man kann nicht einfach einen Trick für alles verwenden; man muss den Trick auf die Aufgabe abstimmen.
Einige Aufgaben sind einfach schwerer zu brechen:
- Analogie: Einen Stock zu brechen braucht einen Schlag. Einen dicken Baumstamm zu brechen, erfordert vielleicht zehn Schläge mit einer Axt.
- Das Ergebnis: Obwohl der Roboter schließlich bei allem scheiterte, dauerten die „Instruction-Following“-Aufgaben mehr als doppelt so viele Versuche, um sie zu brechen, wie die anderen. Wenn man nur das endgültige „Bestanden/Nicht bestanden“-Ergebnis betrachtet, würde man diesen Unterschied übersehen. Das System musste zählen, wie viele „Treffer“ (Iterationen) es brauchte, um den Roboter zu brechen, um die wahre Schwierigkeit zu erkennen.
Die „Einigkeit“-Falle:
- Analogie: Wenn 95 % der Zeit die Antwort „Ja“ lautet und zwei Leute beide fast immer „Ja“ sagen, sehen sie perfekt einig aus. Aber wenn sie nur deshalb „Ja“ raten, weil es die häufigste Antwort ist, sind sie nicht wirklich einig über die schwierigen Fälle.
- Das Ergebnis: Die drei Richter stimmten zu 80–87 % überein, was gut klingt. Aber da der Roboter so oft scheiterte (über 90 %), war diese hohe Übereinstimmung hauptsächlich darauf zurückzuführen, dass sie beide einfach nur mit „Fehlgeschlagen“ geraten hatten. Wenn man sich die „schwierigen“ Fälle ansieht (besonders bei Anweisungen), waren sie tatsächlich oft uneins. Das Paper warnt davor, dass die Standardmathematik zur Messung der Übereinstimmung irreführend sein kann, wenn ein Ergebnis (Fehlern) so häufig vorkommt.
Die Tricks wandern mit:
- Analogie: Wenn man einen Weg findet, einen kleinen, schwachen Hund zu täuschen, findet man vielleicht heraus, dass derselbe Trick auch bei einem großen, starken Hund funktioniert, weil der Trick einen grundlegenden Instinkt ausnutzt und nicht nur die Größe des Hundes.
- Das Ergebnis: Die Tricks, die das System erfunden hat, um einen kleinen, schwächeren Roboter (8 Milliarden Parameter) zu brechen, funktionierten auch bei einem viel größeren, intelligenteren Roboter (70 Milliarden Parameter). Dies deutet darauf hin, dass die Tricks fundamentale Schwächen in der Art und Weise angreifen, wie diese Roboter denken, und nicht nur Bugs im kleinen Modell sind.

4. Das Fazit

Das Paper kommt zu dem Schluss, dass man für das richtige Testen von KI Folgendes benötigt:

Ein Gremium von Richtern: Nicht nur einer, um Voreingenommenheit abzufangen.
Den Aufwand zählen: Sagen Sie nicht nur „es ist kaputtgegangen“. Sagen Sie „es hat 5 Versuche gebraucht, um diese spezifische Art von Aufgabe zu brechen“.
Das Werkzeug anpassen: Verwenden Sie unterschiedliche Tricks für unterschiedliche Arten von Aufgaben (Logik vs. Regeln).
Vorsichtig mit der Mathematik sein: Hohe Übereinstimmungswerte können künstlich hoch sein, wenn der Test zu einfach ist (oder in diesem Fall die Fehler so häufig vorkommen).

Die Autoren haben ihren Code und ihre Daten veröffentlicht, damit andere „AdversaBench“ nutzen können, um ihre eigenen Roboter zu testen und sicherzustellen, dass sie sicher und zuverlässig sind, bevor sie in der realen Welt eingesetzt werden.

Technisches Resümee: AdversaBench

Problemstellung

Die Skalierung der adversariellen Evaluierung von Large Language Models (LLMs) stellt eine doppelte Herausforderung dar: die Generierung schwieriger Eingaben und die zuverlässige Bestätigung, dass resultierende Fehler tatsächlich echte Fehlleistungen sind. Während ein einzelner automatisierter Judge schnell ist, mangelt es ihm an der Fähigkeit, die eigene Milde zu erkennen oder Grenzfälle zu entscheiden. Zudem können Standardmetriken für die Inter-Annotator-Übereinstimmung wie Cohens $\kappa$ in adversariellen Settings, in denen Fehlerraten hoch sind (verzerrte Verteilungen), irreführend sein, da sie substantielle Unstimmigkeiten bei schwierigen Fällen maskieren können. Aktuelles Red-Teaming stützt sich oft auf naives Prompting oder die Verifizierung durch einen einzelnen Judge, was nicht in der Lage ist, die Nuancen von Instruktionsverletzungen, Denkfehlern oder Fehlbedienungen von Tools in großem Maßstab zu erfassen.

Methodik

AdversaBench ist eine automatisierte Red-Teaming-Pipeline und eine Zuverlässigkeitsstudie, die darauf ausgelegt ist, diese Lücken zu schließen. Das System operiert in einer Schleife bestehend aus einem Angreifer, einem Zielmodell und einem Multi-Judge-Panel.

Systemarchitektur

Pipeline: Basierend auf LangGraph zur Orchestrierung und LangChain für Modellaufrufe, unterstützt das System die Fortsetzung unterbrochener Prozesse (Checkpoint Resumption) und ein robustes Handling von API-Rate-Limits.
Zielmodell: Llama 3.1 8B Instant (bewusst als schwaches Ziel ausgewählt, um die Evaluierungsmetriken zu testen und eine hohe Fehlervorhersage sicherzustellen).
Angreifer: Primär Llama 3.3 70B, mit Eskalation zu GPT-4o-mini ab Iteration 2, falls ein Fehler noch nicht bestätigt wurde.
Judges: Ein Panel aus drei Modellen (Llama 3.3 70B, Cerebras GPT-OSS 120B und Qwen3 32B) stimmt darüber ab, ob eine Antwort gegen eine Ground-Truth-Spezifikation verstößt. Einstimmiger Konsens speichert das Ergebnis; bei Uneinigkeit wird durch einen GPT-4o-mini Meta-Judge entschieden.

Konstruktion und Mutation der Seeds

Die Studie nutzte 45 Seed-Prompts aus drei Kategorien: Reasoning (15), Instruction-Following (15) und Tool-Use (15). Diese wurden aus einem initialen Pilotprojekt erweitert, um zeitliches Denken, strikte Formatierung (z. B. exakte JSON-Keys), negative Constraints und Tool-Edge-Cases abzudecken. Jeder Seed enthält einen Basis-Prompt, eine eindeutige expected_behavior-Spezifikation und eine Referenzantwort.

Fünf strukturierte Mutationsoperatoren werden iterativ (bis zu 5 Iterationen pro Seed) unter Verwendung einer $\epsilon$ -greedy-Selektionsstrategie ( $\epsilon=0.2$ ) angewendet:

rephrase: Oberflächliche Umformulierung des Seeds.
inject_distractor: Fügt eine plausible, aber irreführende Einschränkung hinzu.
role_flip: Formuliert die Aufgabe unter einer adversariellen Persona um.
constraint_add: Hängt widersprüchliche Anforderungen an.
jailbreak_wrap: Bettet den Seed in ein Jailbreak-ähnliches Template ein.

Zentrale Beiträge

Reproduzierbare Pipeline: Ein LangGraph-basiertes System mit $\epsilon$ -greedy Operator-Selektion, Angreifer-Eskalation und einem Drei-Judge-Panel mit Meta-Judge-Tiebreaker zur Bestätigung von Fehlern.
Iteration Cost Metric: Ein Vorschlag, die durchschnittliche Anzahl der Angreifer-Iterationen, die benötigt werden, um einen Seed zu brechen, neben binären Fehlerraten zu berichten. Diese Metrik offenbart Schwierigkeitsgrade, die aggregierte Pass/Fail-Raten verschleiern.
Zuverlässigkeitsstudie: Eine Adaption der Inter-Judge-Reliabilitätsanalyse (Cohens $\kappa$ ) für binäre Urteile zu Einzelantworten. Die Studie zeigt, wie hohe Rohübereinstimmungen mit nahezu Null oder negativen $\kappa$ -Werten in verzerrten Verteilungen koexistieren können, und argumentiert dafür, dass kategorie-stratifizierte Disagreement-Raten eine informativere Metrik sind.
Evidenz der Transferierbarkeit: Ein Zero-Shot-Transferierbarkeitsexperiment zeigt, dass gegen ein schwaches 8B-Modell generierte adversarielle Prompts erfolgreich ein wesentlich stärkeres 70B-Modell brechen, was darauf hindeutet, dass die Mutationen allgemeine Verhaltensmuster statt modellspezifischer Schwächen ausnutzen.

Ergebnisse

Erfolgsrate: Alle 45 Seeds produzierten bestätigte Fehler.
Effektivität der Operatoren: Die Effektivität variiert stark nach Kategorie. Beispielsweise erreichte inject_distractor eine mittlere Belohnung von 1,00 bei Reasoning- und Tool-Use-Seeds, aber nur 0,33 bei Instruction-Following-Seeds. Aggregierte Zählungen maskierten diese kategorie-spezifischen Abhängigkeiten.
Iterationskosten: Instruction-Following-Seeds erforderten signifikant mehr Aufwand (durchschnittlich 2,4 Iterationen) im Vergleich zu Reasoning- und Tool-Use-Seeds (durchschnittlich 1,1 Iterationen). Eine Überlebenskurve zeigte, dass 60 % der Instruction-Seeds nach der ersten Iteration ungebrochen blieben, gegenüber nur 10 % bei anderen Kategorien.
Judge-Reliabilität: Die paarweise Judge-Übereinstimmung war hoch (80–87 %), doch Cohens $\kappa$ lag nahe Null oder war leicht negativ (−0,05 bis −0,11) aufgrund der hohen Prävalenz von "Fail"-Urteilen (90–97 %). Die Disagreement-Raten waren am höchsten in der Kategorie Instruction-Following (33 % der Fälle), während Reasoning-Fehler einstimmig waren (0 % Disagreement).
Transferierbarkeit: Eine vorläufige manuelle Überprüfung von 15 verifizierten adversariellen Prompts deutete darauf hin, dass logische Fallen und Constraint-basierte Mutationen erfolgreich vom Llama 3.1 8B auf das Llama 3.3 70B transferiert wurden.

Signifikanz und Behauptungen

Das Paper behauptet, dass AdversaBench eine nuanciertere Sicht auf die adversarielle Evaluierung bietet, indem es über einfache binäre Fehlerraten hinausgeht. Es argumentiert, dass:

Die Operator-Selektion kategorieabhängig sein muss: Kein einzelner Operator dominiert über alle Aufgabentypen hinweg; die aggregierte Berichterstattung verbirgt kritische Ineffizienzen.
Iterationskosten eine kritische Metrik sind: Sie offenbaren die "Schwierigkeit", ein Modell zu brechen, was unsichtbar bleibt, wenn nur Erfolgsraten gemeldet werden.
Multi-Judge-Panels für Instruction-Following essenziell sind: Einzelne Judges übersehen Fehler, die andere Judges als "pass" bewerten; die Disagreement-Raten in dieser Kategorie unterstreichen die Notwendigkeit einer Schlichtung bei ambivalenten Fällen.
$\kappa$ Kontext benötigt: In verzerrten adversariellen Settings ist ein $\kappa$ nahe Null ein Signal der Prävalenz und kein Zeichen mangelnder Judge-Alignment; kategorie-stratifizierte Disagreement ist ein besserer Indikator dafür, wo sich Judges unterscheiden.
Generalisierbarkeit: Die Mutationen legen allgemeine Verhaltensmuster offen (z. B. die Schwierigkeit, widersprüchliche Constraints aufzulösen), statt nur spezifische Schwächen kleiner Modelle, wie der erfolgreiche Transfer auf größere Modelle zeigt.

Die Autoren schließen damit ab, dass der Code, der Datensatz und die Analyse-Skripte veröffentlicht werden, um reproduierbares Red-Teaming und weitere Studien zur Zuverlässigkeit von Evaluatoren zu ermöglichen.