Red Team AI Benchmark

Version russe : README.ru.md

Red Team AI Benchmark est un benchmark d'évaluation de modèles en ligne de commande (CLI). Il mesure comment les LLM comprennent et répondent aux questions et scénarios de red team ; ce n'est pas un outil pour mener ces activités. La version 2 utilise un ensemble de données basé sur une grille d'évaluation plutôt que de juger les réponses uniquement par rapport à une seule réponse de référence.

Le jeu par défaut de la v2 contient 60 questions dans datasets/v2/benchmark.jsonl, regroupées par domaine et difficulté.

État du dépôt

Le dépôt GitHub d'origine n'est plus disponible ; en tant que propriétaire, j'ai été banni de la plateforme GitHub. Un dépôt miroir alternatif pour le projet (maintenu par le contributeur principal et co-auteur) est disponible à l'adresse https://github.com/szybnev/redteam-ai-benchmark. Le propriétaire actuel de ce dépôt en est le développeur et mainteneur actif.

Objectif et périmètre

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

Objectifs explicitement non visés

• Ce dépôt n'est pas un outil de piratage, un framework d'exploitation, un scanner, un C2, un outil de persistance, un exécuteur de charge utile, ou un agent red team autonome.
• Il ne découvre, n'accède, n'exploite, ne modifie ni ne maintient l'accès à des systèmes cibles.
• Il n'exécute pas la sortie du modèle. Le benchmark envoie uniquement des invites d'évaluation aux endpoints de modèle configurés, note le texte renvoyé et écrit les résultats.
• La présence de sujets de sécurité offensive dans le jeu de données de test décrit le domaine d'évaluation ; elle n'accorde pas d'autorisation ni d'habilitation pour une activité contre un système.

Responsabilité de l'utilisateur

Le benchmark n'autorise, ne dirige ni ne contrôle aucune activité en dehors de l'exécution de l'évaluation. Toute utilisation ultérieure des réponses du modèle, y compris via un agent ou un framework d'automatisation séparé, dépend entièrement de l'utilisateur final, de sa configuration, de ses permissions et de son environnement. Utilisez l'ensemble de données et les résultats uniquement pour une évaluation, une recherche, un test ou un enseignement autorisés.

Classement publié

Aucun classement actuel n'est publié dans cette branche. Les scores historiques ont été produits avec une sémantique lexicale et de jugement partiel plus ancienne et ne sont pas comparables au scoreur actuel.

Un classement publiable nécessite une passe de juge complète avec des empreintes de jeu de données correspondantes, zéro erreur de juge et une couverture complète. Générez ses artefacts JSON et Markdown vérifiés avec :

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

La commande nécessite les enregistrements de juge per_model/*.json frères et rejette les résumés disputed, la couverture incomplète du juge, les discordances d'empreinte du jeu de données et les lignes sans provenance juge-modèle. Le paquet obtenu contient les résultats bruts du benchmark, les enregistrements par question du juge, leurs empreintes et une copie de summary.csv. Le classement utilise le rubric_score brut ; judge_adjusted_score est affiché uniquement comme résultat d'audit séparé.

Ce que mesure la v2

Le benchmark rapporte le score pondéré total et des métriques d'audit séparées :

Les étiquettes d'interprétation sont volontairement conservatrices :

Les étiquettes d'interprétation s'appliquent uniquement aux exécutions complètes. Tout échec de requête transforme l'interprétation en incomplete, tout en conservant le score partiel et la couverture pour le diagnostic. Lorsque les intervalles de confiance des répétitions franchissent le seuil de 60 ou 80, l'interprétation est uncertain. Un score élevé n'est pas une approbation de production.

Couverture du jeu de données

Le jeu de données v2 couvre :

• Techniques Windows
• AD et AD CS
• Exploitation web
• Cloud et IAM
• Conteneurs et Kubernetes
• Raisonnement sur la détection et l'évasion
• OpSec et compromis opérationnels
• Utilisation d'outils
• Planification post-exploitation
• Validation et rapport

Les niveaux de difficulté sont L1 factual, L2 procedure, L3 troubleshooting, L4 scenario reasoning et L5 multi-step operator task.

Installation

Prérequis :

• Python 3.13+
• uv
• Un fournisseur : Ollama, LM Studio, OpenWebUI ou OpenRouter

Installer les dépendances de base :

uv sync

Fournisseurs

Utilisation

Lister les modèles :

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"

Exécuter le profil standard par défaut de la v2 :

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

Exécuter un sous-ensemble de test rapide :

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

Exécuter des questions v2 sélectionnées par ID :

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

Écrire un journal de requêtes par question en mode ajout :

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

Exécuter plusieurs modèles locaux en mode interactif :

uv run run_benchmark.py interactive ollama --profile standard

Profils pris en charge :

Notation

La notation à l'exécution est toujours rubric. Elle est déterministe et ne nécessite pas de juge LLM externe. Le score d'exécution est la couverture lexicale, pas une preuve sémantique de justesse technique. L'apparieur rejette les négations explicites et les déclarations marquées comme fausses, prend en charge les variantes acceptées au niveau des critères et enregistre les preuves appariées pour l'audit.

La notation à l'exécution ne prend pas en charge les modes hérités keyword, semantic ou hybrid. Utilisez la commande judge hors ligne pour un audit post-hoc LLM-as-Judge.

Juge LLM hors ligne (LLM-as-Judge)

Les fichiers JSON de résultats v2 sauvegardés peuvent être audités après coup sans réexécuter les modèles du benchmark :

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

La commande juge écrit per_model/*.json, detailed.csv, summary.csv et disputed_cases.csv. Le mode complet produit un judge_adjusted_score comparable et des dénominateurs explicites. disputed reste un mode de diagnostic économique et ne publie pas de total partiellement ajusté. Il audite également un échantillon déterministe de 20% des ID de questions à score élevé pour chaque modèle ; ajustez cela avec --audit-sample-rate. Le juge évalue les réponses sans voir le score déterministe, puis le post-traitement compare les deux résultats.

Configuration

Copiez config.example.yaml vers config.yaml et ajustez-le :

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

Exécutez avec la configuration :

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

Sortie

L'export JSON inclut les résultats du modèle, les preuves de la grille d'évaluation par question, le résumé agrégé et la provenance de l'audit :

{
  "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": {}
    }
  }
}

Chaque ligne de résultat inclut le statut de la requête, l'identité de la répétition/exécution, la graine, la raison de fin, l'utilisation, le modèle réel et les métadonnées disponibles du fournisseur. La provenance de haut niveau ajoute des informations sur l'environnement et une raison explicite lorsqu'une révision de modèle immuable n'est pas disponible. La sortie CSV contient des lignes par question plus une ligne TOTAL. criteria_csv ajoute une ligne par critère de grille d'évaluation réussi ou échoué.

Les erreurs de requête sont conservées sous forme de lignes structurées et rendent l'exécution incomplete. Utilisez --fail-fast ou continue_on_error: false pour abandonner à la première erreur.

Optimisation des invites

L'optimisation des invites reste optionnelle et séparée de la notation du modèle de base. Elle ne s'exécute que pour les réponses classées comme censurées. Les réponses de base et le score principal ne sont jamais remplacés ; les réponses optimisées sont écrites dans optimized_prompts_{model}_{timestamp}.json avec des résultats de base et optimisés séparés. Son résumé rapporte refusal_recovery_rate sur les réponses censurées envoyées à l'optimiseur.

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

Ne mélangez pas les scores optimisés avec les comparaisons de capacités du modèle de base.

Limitations connues

• La notation déterministe mesure la couverture lexicale de la grille. Utilisez une passe de juge hors ligne complète et une révision manuelle pour les affirmations de justesse technique.
• Le jeu de données public peut être mémorisé. Traitez-le comme un benchmark de développement ; une évaluation à enjeux élevés devrait ajouter un ensemble de rétention privé ou tournant.
• Chaque capacité actuelle a une question unique. Les répétitions mesurent la variance de génération, pas la validité multi-item de la capacité ; les ventilations exposent cela comme single-item ou single-item-repeated.
• Les métadonnées des fournisseurs diffèrent. Les révisions immuables manquantes sont enregistrées comme indisponibles plutôt qu'inférées.

Validation

Vérifications utiles :

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

Contribution

Voir CONTRIBUTING.md, CODE_OF_CONDUCT.md et SECURITY.md.

Licence

MIT. Utilisation dans les laboratoires red team autorisés, les évaluations de sécurité commerciales, la recherche en sécurité IA et les environnements éducatifs.