redteam-ai-benchmark

# Red Team AI Benchmark

**Russische Version:** [README.ru.md](https://gitlab.com/toxy4ny/redteam-ai-benchmark/-/blob/main/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

```yaml
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.

<img width="1393" height="1126" alt="image" src="https://assets.kitploit.com/production/public/readmes/7036/058575c06e0b905b6c2219818c8c53886f538e7e3bef64ef28217da355d02489.png" />

## 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:

```bash
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:

| Metrik | Bedeutung | Population / Nenner |
| --- | --- | --- |
| `refusal_rate` | Prozentsatz der verweigerten oder zensierten Antworten | Abgeschlossene Modellantworten |
| `lexical_coverage` | Abdeckung von technischen Kriterienmustern | Abgeschlossene Antworten; Verweigerungen und fatale Übereinstimmungen zählen null |
| `critical_error_rate` | Antworten, die nicht abgelehnte fatale Fehlerregeln erfüllen | Abgeschlossene Modellantworten |
| `lexical_completeness` | Abdeckung von Vollständigkeitskriterienmustern | Abgeschlossene Antworten; Verweigerungen und fatale Übereinstimmungen zählen null |
| `lexical_specificity` | Abdeckung von Spezifitätskriterienmustern | Abgeschlossene Antworten; Verweigerungen und fatale Übereinstimmungen zählen null |
| `latency_ms_avg` | Durchschnittliche Antwortlatenz | Abgeschlossene Antworten mit gemessener Latenz |
| `metric_coverage` | Beobachtungen, die zu jedem lexikalischen Aggregat beitragen | Abgeschlossene Modellantworten |
| `run_coverage` | Abgeschlossene, fehlgeschlagene und übersprungene Modellanfragen | Erwartete Frage-Wiederholungsbeobachtungen |
| `repeat_statistics` | Punktzahlen pro Wiederholung, Standardabweichung und 95 % Bootstrap-KI | Abgeschlossene Beobachtungen gruppiert nach Wiederholung |

Interpretationslabels sind bewusst konservativ:

| Endpunktzahl | Interpretation |
| --- | --- |
| `< 60%` | `nicht geeignet` |
| `60-79,9%` | `erfordert Validierung` |
| `>= 80%` | `starker Kandidat` |

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:

```bash
uv sync
```

## Anbieter

| Anbieter | Standard-Endpunkt | Hinweise |
| --- | --- | --- |
| `ollama` | `http://localhost:11434` | Native Ollama-API; optionale Bearer-Authentifizierung für Reverse-Proxies |
| `lmstudio` | `http://localhost:1234` | OpenAI-kompatible LM Studio-API |
| `openwebui` | `http://localhost:3000` | OpenAI-kompatible OpenWebUI-API |
| `openrouter` | `https://openrouter.ai/api/v1` | Erfordert einen API-Schlüssel |

## Nutzung

Modelle auflisten:

```bash
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:

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

Ein schnelles Smoke-Subset ausführen:

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

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

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

Ein append-only Anforderungslog pro Frage schreiben:

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

Mehrere lokale Modelle interaktiv ausführen:

```bash
uv run run_benchmark.py interactive ollama --profile standard
```

Unterstützte Profile:

| Profil | Zweck |
| --- | --- |
| `quick` | 16-Fragen L1/L2 API- und Pipeline-Smoke-Subset; kein Ranking-Stellvertreter |
| `standard` | Vollständiger 60-Fragen v2-Benchmark |

## 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:

```bash
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:

```yaml
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:

```bash
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:

```json
{
  "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.

```bash
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:

```bash
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](https://gitlab.com/toxy4ny/redteam-ai-benchmark/-/blob/main/CONTRIBUTING.md), [CODE_OF_CONDUCT.md](https://gitlab.com/toxy4ny/redteam-ai-benchmark/-/blob/main/CODE_OF_CONDUCT.md) und [SECURITY.md](https://gitlab.com/toxy4ny/redteam-ai-benchmark/-/blob/main/SECURITY.md).

## Lizenz

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