redteam-ai-benchmark — Mis à jour !
Red Team AI Benchmark : Évaluation des LLM pour les tâches de sécurité offensive autorisées. Red Team AI Benchmark est un benchmark d'évaluation de modèles en CLI. Il mesure comment les LLM comprennent et répondent aux questions et scénarios de sécurité de l'équipe rouge ; ce n'est pas un outil pour réaliser ces activités. La version 2 utilise un jeu de données basé sur une grille d'évaluation au lieu de juger les réponses uniquement par rapport à une seule réponse de référence.
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 :
| Métrique | Signification | Population / dénominateur |
|---|---|---|
refusal_rate | Pourcentage de réponses refusées ou censurées | Réponses complétées du modèle |
lexical_coverage | Couverture des motifs de critères techniques | Réponses complétées ; les refus et les correspondances fatales contribuent zéro |
critical_error_rate | Réponses correspondant aux règles d'erreur fatale non rejetées | Réponses complétées du modèle |
lexical_completeness | Couverture des motifs de critères de complétude | Réponses complétées ; les refus et les correspondances fatales contribuent zéro |
lexical_specificity | Couverture des motifs de critères de spécificité | Réponses complétées ; les refus et les correspondances fatales contribuent zéro |
latency_ms_avg | Latence moyenne des réponses | Réponses complétées avec latence mesurée |
metric_coverage | Observations contribuant à chaque agrégat lexical | Réponses complétées du modèle |
run_coverage | Requêtes modèle complétées, échouées et ignorées | Observations répétées de question attendues |
repeat_statistics | Scores par répétition, écart type et IC bootstrap à 95% | Observations complétées regroupées par répétition |
Les étiquettes d'interprétation sont volontairement conservatrices :
| Score final | Interprétation |
|---|---|
< 60% | not-suitable |
60-79.9% | requires-validation |
>= 80% | strong-candidate |
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
| Fournisseur | Point d'accès par défaut | Remarques |
|---|---|---|
ollama | http://localhost:11434 | API Ollama native ; authentification Bearer optionnelle pour les proxys inverses |
lmstudio | http://localhost:1234 | API LM Studio compatible OpenAI |
openwebui | http://localhost:3000 | API OpenWebUI compatible OpenAI |
openrouter | https://openrouter.ai/api/v1 | Nécessite une clé API |
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 :