Red Team AI Benchmark

Russische Version: README.ru.md

Red Team AI Benchmark ist ein CLI Modellbewertungs-Benchmark. Er misst, wie LLMs Red-Team-Fragen und Sicherheitsszenarien verstehen und darauf antworten; er ist kein Werkzeug zur Durchführung dieser Aktivitäten. Version 2 verwendet einen rubrikbasierten Datensatz anstatt Antworten nur anhand einer einzigen goldenen Antwort zu bewerten.

Der standardmäßige v2-Satz enthält 60 Fragen in datasets/v2/benchmark.jsonl, gruppiert nach Domäne und Schwierigkeitsgrad.

Repository-Status

Das ursprüngliche GitHub-Repository ist nicht mehr verfügbar; als sein Eigentümer wurde ich von der GitHub-Plattform ausgeschlossen. Ein alternatives Spiegel-Repository für das Projekt (gepflegt vom Hauptbeitragenden und Co-Autor) ist verfügbar unter https://github.com/szybnev/redteam-ai-benchmark. Der derzeitige Eigentümer dieses Repositorys ist sein aktiver Entwickler und Betreuer.

Zweck und Umfang

project_type: LLM evaluation benchmark
primary_function: assess model responses to red-team questions and scenarios
execution_target: configured LLM provider, optional judge, and optional tracing services
target_system_access: none
model_output_execution: none
user_control: all actions after a response is returned depend solely on the end user and their own framework, permissions, and environment

Explizite Nicht-Ziele

• Dieses Repository ist kein Hacking-Tool, Exploit-Framework, Scanner, C2, Persistenz-Tool, Payload-Runner oder autonomer Red-Team-Agent.
• Es entdeckt, greift nicht auf Zielsysteme zu, nutzt sie nicht aus, modifiziert sie nicht und hält keinen Zugriff aufrecht.
• Es führt keine Modellausgabe aus. Der Benchmark sendet nur Bewertungsprompts an konfigurierte Modellendpunkte, bewertet den zurückgegebenen Text und schreibt Ergebnisse.
• Das Vorhandensein von offensive-security Themen im Testdatensatz beschreibt die Bewertungsdomäne; es gewährt keine Erlaubnis oder Autorisierung für Aktivitäten gegen ein System.

Benutzerverantwortung

Der Benchmark autorisiert, leitet oder kontrolliert keine Aktivität außerhalb des Evaluierungslaufs. Jegliche nachgelagerte Nutzung von Modellantworten, einschließlich der Nutzung durch einen separaten Agenten oder ein Automatisierungsframework, hängt vollständig vom Endbenutzer, seiner Konfiguration, seinen Berechtigungen und seiner Umgebung ab. Nutzen Sie den Datensatz und die Ergebnisse nur für autorisierte Evaluierung, Forschung, Tests oder Bildung.

Veröffentlichte Rangliste

In diesem Branch wird derzeit keine Rangliste veröffentlicht. Historische Ergebnisse wurden mit älteren lexikalischen und partiellen Judge-Semantiken erstellt und sind nicht mit dem aktuellen Bewerter vergleichbar.

Eine veröffentlichungsfähige Rangliste erfordert einen vollständigen Judge-Durchlauf mit passenden Dataset-Hashes, null Judge-Fehlern und vollständiger Abdeckung. Erzeugen Sie die geprüften JSON- und Markdown-Artefakte mit:

uv run run_benchmark.py leaderboard \
  --judge-summary judge_results_v2/summary.csv \
  --output-dir leaderboard

Der Befehl erfordert die zugehörigen per_model/*.json-Judge-Aufzeichnungen und lehnt disputed-Zusammenfassungen, unvollständige Judge-Abdeckung, Dataset-Hash-Unterschiede und Zeilen ohne Judge-Modell-Provenienz ab. Das resultierende Paket enthält rohe Benchmark-Ergebnisse, Judge-Aufzeichnungen pro Frage, deren Hashes und eine Kopie von summary.csv. Das Ranking verwendet den rohen rubric_score; judge_adjusted_score wird nur als separates Prüfergebnis angezeigt.

Was v2 misst

Der Benchmark berichtet die gewichtete Gesamtpunktzahl sowie separate Prüfmetriken:

Interpretationslabels sind bewusst konservativ:

Interpretationslabels gelten nur für vollständige Läufe. Jeder Anfragefehler ändert die Interpretation zu incomplete, unter Beibehaltung der partiellen Punktzahl und Abdeckung für Diagnosezwecke. Wenn Wiederholungs-Konfidenzintervalle die 60- oder 80-Schwelle überschreiten, lautet die Interpretation uncertain. Eine hohe Punktzahl ist keine Produktionsfreigabe.

Dataset-Abdeckung

Das v2-Dataset umfasst:

• Windows-Tradecraft
• AD und AD CS
• Web-Exploitation
• Cloud und IAM
• Container und Kubernetes
• Erkennungs- und Ausweichlogik
• OpSec und operative Abwägungen
• Werkzeugnutzung
• Post-Exploitation-Planung
• Validierung und Berichterstattung

Schwierigkeitsstufen sind L1 factual, L2 procedure, L3 troubleshooting, L4 scenario reasoning und L5 multi-step operator task.

Installation

Voraussetzungen:

• Python 3.13+
• uv
• Ein Anbieter: Ollama, LM Studio, OpenWebUI oder OpenRouter

Installieren Sie die Basisabhängigkeiten:

uv sync

Anbieter

Nutzung

Modelle auflisten:

uv run run_benchmark.py ls ollama
uv run run_benchmark.py ls lmstudio
uv run run_benchmark.py ls openwebui
uv run run_benchmark.py ls openrouter --api-key "$OPENROUTER_API_KEY"

Das standardmäßige v2-Profil ausführen:

uv run run_benchmark.py run ollama -m "llama3.1:8b"

Ein schnelles Smoke-Subset ausführen:

uv run run_benchmark.py run ollama -m "llama3.1:8b" --profile quick

Ausgewählte v2-Fragen nach ID ausführen:

uv run run_benchmark.py run ollama -m "llama3.1:8b" --question-ids 5 12

Ein append-only Anforderungslog pro Frage schreiben:

uv run run_benchmark.py run ollama -m "llama3.1:8b" --request-log results/requests.jsonl

Mehrere lokale Modelle interaktiv ausführen:

uv run run_benchmark.py interactive ollama --profile standard

Unterstützte Profile:

Bewertung

Die Laufzeitbewertung ist immer rubric. Sie ist deterministisch und erfordert keinen externen LLM-Judge. Der Laufzeit-Score ist lexikalische Abdeckung, kein semantischer Nachweis technischer Korrektheit. Der Matcher lehnt explizite Negationen und als falsch markierte Aussagen ab, unterstützt akzeptierte Varianten auf Kriterienebene und zeichnet übereinstimmende Nachweise für die Prüfung auf.

Die Laufzeitbewertung unterstützt keine veralteten keyword-, semantic- oder hybrid-Modi. Verwenden Sie den Offline-judge-Befehl für die nachträgliche LLM-als-Judge-Prüfung.

Offline LLM-als-Judge

Gespeicherte v2-Ergebnis-JSON-Dateien können nachträglich geprüft werden, ohne die Benchmark-Modelle erneut auszuführen:

OPENROUTER_API_KEY=... uv run run_benchmark.py judge \
  --results "results_*_v2/*.json" \
  --dataset datasets/v2/benchmark.jsonl \
  --judge-model "deepseek/deepseek-v4-flash" \
  --output-dir judge_results_v2 \
  --mode full \
  --concurrency 4

Der Judge-Befehl schreibt per_model/*.json, detailed.csv, summary.csv und disputed_cases.csv. Der Vollmodus erzeugt einen vergleichbaren judge_adjusted_score und explizite Nenner. disputed bleibt ein kostensparender Diagnosemodus und veröffentlicht keine teilweise angepasste Gesamtpunktzahl. Er prüft auch eine deterministische 20%-Stichprobe von High-Score-Fragen-IDs über alle Modelle hinweg; passen Sie dies mit --audit-sample-rate an. Der Judge bewertet Antworten, ohne den deterministischen Score zu sehen, dann vergleicht die Nachbearbeitung beide Ergebnisse.

Konfiguration

Kopieren Sie config.example.yaml zu config.yaml und passen Sie es an:

provider:
  name: ollama
  endpoint: http://localhost:11434
  # api_key: sk-xxx
  # keep_alive: 30m

scoring:
  method: rubric

export:
  formats:
    - json
    - csv
    - criteria_csv
  output_dir: ./results
  include_response: true

questions_file: datasets/v2/benchmark.jsonl
answers_file: answers_all.txt
rate_limit_delay: 1.5
max_tokens: 1024
temperature: 0.2
concurrency: 1
repeats: 1
seed: 0
continue_on_error: true
# request_log: ./results/requests.jsonl

Mit Konfiguration ausführen:

uv run run_benchmark.py run ollama -m "llama3.1:8b" --config config.yaml

Ausgabe

Der JSON-Export enthält Modellergebnisse, Rubriknachweise pro Frage, aggregierte Zusammenfassung und Prüfprovenienz:

{
  "model": "llama3.1:8b",
  "scoring_method": "rubric",
  "total_score": 75.0,
  "interpretation": "requires-validation",
  "benchmark_version": "2.3.0",
  "dataset_id": "redteam-ai-benchmark-v2",
  "dataset_version": "2.1.0",
  "dataset_hash": "...",
  "scorer_version": "rubric-v2.1.0",
  "config_hash": "...",
  "evaluation_fingerprint": "...",
  "run_config": {
    "provider": "ollama",
    "model": "llama3.1:8b",
    "profile": "standard",
    "repeats": 1,
    "seed": 0
  },
  "git_commit": "...",
  "package_version": "2.3.0",
  "runtime_profile": "standard",
  "summary": {
    "metrics": {
      "refusal_rate": 0.0,
      "critical_error_rate": 0.0
    },
    "breakdown": {
      "difficulty": {},
      "domain": {},
      "capability": {}
    }
  }
}

Jede Ergebniszeile enthält den Anforderungsstatus, Wiederholungs-/Laufkennung, Seed, Beendigungsgrund, Nutzung, tatsächliches Modell und verfügbare Anbietermetadaten. Die Top-Level-Provenienz fügt Umgebungsinformationen und einen expliziten Grund hinzu, wenn eine unveränderliche Modellrevision nicht verfügbar ist. Die CSV-Ausgabe enthält Zeilen pro Frage sowie eine TOTAL-Zeile. criteria_csv fügt eine Zeile pro bestandenem oder nicht bestandenem Rubrikkriterium hinzu.

Anforderungsfehler werden als strukturierte Zeilen erhalten und machen den Lauf incomplete. Verwenden Sie --fail-fast oder continue_on_error: false, um beim ersten Fehler abzubrechen.

Prompt-Optimierung

Die Prompt-Optimierung bleibt optional und getrennt von der Basismodellbewertung. Sie läuft nur für Antworten, die als zensiert klassifiziert wurden. Basisantworten und der Hauptscore werden nie ersetzt; optimierte Antworten werden in optimized_prompts_{model}_{timestamp}.json mit separaten Basis- und Optimierungsergebnissen geschrieben. Ihre Zusammenfassung berichtet refusal_recovery_rate über die an den Optimierer gesendeten zensierten Antworten.

uv run run_benchmark.py run ollama -m "llama3.1:8b" \
  --optimize-prompts \
  --optimizer-model "llama3.3:70b"

Mischen Sie keine optimierten Scores mit Basismodell-Fähigkeitsvergleichen.

Bekannte Einschränkungen

• Die deterministische Bewertung misst die Abdeckung einer lexikalischen Rubrik. Verwenden Sie einen vollständigen Offline-Judge-Durchlauf und manuelle Überprüfung für Behauptungen technischer Genauigkeit.
• Der öffentliche Datensatz kann auswendig gelernt werden. Behandeln Sie ihn als Entwicklungs-Benchmark; eine Evaluierung mit hohem Einsatz sollte einen privaten oder rotierenden Holdout hinzufügen.
• Jede aktuelle Fähigkeit hat eine eindeutige Frage. Wiederholungen messen die Generierungsvarianz, nicht die Mehr-Item-Fähigkeitsvalidität; Aufschlüsselungen zeigen dies als single-item oder single-item-repeated an.
• Anbietermetadaten unterscheiden sich. Fehlende unveränderliche Revisionen werden als nicht verfügbar aufgezeichnet, nicht abgeleitet.

Validierung

Nützliche Prüfungen:

uv run run_benchmark.py --help
uv run run_benchmark.py run --help
uv lock --check
uv run ruff check .
uv run pytest -q
uv run python -m compileall -q run_benchmark.py benchmark models optimization scoring tracing utils

Mitwirken

Siehe CONTRIBUTING.md, CODE_OF_CONDUCT.md und SECURITY.md.

Lizenz

MIT. Nutzung in autorisierten Red-Team-Laboren, kommerziellen Sicherheitsbewertungen, KI-Sicherheitsforschung und Bildungsumgebungen.