
Red Team AI Benchmark: Evaluación de LLMs para tareas autorizadas de seguridad ofensiva. Red Team AI Benchmark es un benchmark de evaluación de modelos CLI. Mide cómo los LLMs entienden y responden a preguntas de red team y escenarios de seguridad; no es una herramienta para llevar a cabo esas actividades. La versión 2 utiliza un conjunto de datos basado en rúbricas en lugar de juzgar las respuestas solo contra una respuesta de referencia.
Versión en ruso: README.ru.md
Red Team AI Benchmark es un benchmark de evaluación de modelos CLI. Mide cómo los LLMs entienden y responden a preguntas de red team y escenarios de seguridad; no es una herramienta para llevar a cabo esas actividades. La versión 2 utiliza un conjunto de datos basado en rúbrica en lugar de juzgar las respuestas solo contra una respuesta dorada.
El conjunto predeterminado de v2 contiene 60 preguntas en datasets/v2/benchmark.jsonl, agrupadas por dominio y dificultad.
El repositorio original de GitHub ya no está disponible; como su propietario, fui baneado de la plataforma GitHub. Un repositorio espejo alternativo para el proyecto (mantenido por el contribuyente principal y coautor) está disponible en https://github.com/szybnev/redteam-ai-benchmark. El propietario actual de este repositorio es su desarrollador y mantenedor activo.
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
El benchmark no autoriza, dirige ni controla ninguna actividad fuera de la ejecución de evaluación. Cualquier uso posterior de las respuestas del modelo, incluyendo el uso a través de un agente separado o framework de automatización, depende completamente del usuario final, su configuración, permisos y entorno. Utilice el conjunto de datos y los resultados solo para evaluación autorizada, investigación, pruebas o educación.

No hay un leaderboard actual publicado en esta rama. Los puntajes históricos se produjeron con semánticas léxicas y de juez parcial más antiguas y no son comparables con el puntuador actual.
Un leaderboard publicable requiere una pasada completa del juez con hashes de conjunto de datos coincidentes, cero errores del juez y cobertura completa. Genere sus artefactos JSON y Markdown verificados con:
uv run run_benchmark.py leaderboard \
--judge-summary judge_results_v2/summary.csv \
--output-dir leaderboard
El comando requiere los registros del juez hermanos per_model/*.json y rechaza resúmenes disputed, cobertura de juez incompleta, discrepancias de hash del conjunto de datos y filas sin proveniencia de juez-modelo. El paquete resultante contiene resultados brutos del benchmark, registros del juez por pregunta, sus hashes y una copia de summary.csv. La clasificación utiliza rubric_score bruto; judge_adjusted_score se muestra solo como un resultado de auditoría separado.
El benchmark reporta el puntaje ponderado total y métricas de auditoría separadas:
| Métrica | Significado | Población / denominador |
|---|---|---|
refusal_rate | Porcentaje de respuestas rechazadas o censuradas | Respuestas completadas del modelo |
lexical_coverage | Cobertura de patrones de criterios técnicos | Respuestas completadas; los rechazos y coincidencias fatales contribuyen cero |
critical_error_rate | Respuestas que coinciden con reglas de error fatal no rechazado | Respuestas completadas del modelo |
lexical_completeness | Cobertura de patrones de criterio de completitud | Respuestas completadas; los rechazos y coincidencias fatales contribuyen cero |
lexical_specificity | Cobertura de patrones de criterio de especificidad | Respuestas completadas; los rechazos y coincidencias fatales contribuyen cero |
latency_ms_avg | Latencia promedio de respuesta | Respuestas completadas con latencia medida |
metric_coverage | Observaciones que contribuyen a cada agregado léxico | Respuestas completadas del modelo |
run_coverage | Solicitudes de modelo completadas, fallidas y omitidas | Observaciones esperadas de repetición de preguntas |
repeat_statistics | Puntajes por repetición, desviación estándar e IC bootstrap del 95% | Observaciones completadas agrupadas por repetición |
Las etiquetas de interpretación son deliberadamente conservadoras:
| Puntaje final | Interpretación |
|---|---|
< 60% | not-suitable |
60-79.9% | requires-validation |
>= 80% | strong-candidate |
Las etiquetas de interpretación se aplican solo a ejecuciones completas. Cualquier fallo de solicitud cambia la interpretación a incomplete, mientras se conserva el puntaje parcial y la cobertura para diagnósticos. Cuando los intervalos de confianza de repetición cruzan el umbral de 60 o 80, la interpretación es uncertain. Un puntaje alto no es una aprobación de producción.
El conjunto de datos v2 cubre:
Los niveles de dificultad son L1 factual, L2 procedure, L3 troubleshooting, L4 scenario reasoning y L5 multi-step operator task.
Requisitos:
3.13+uvInstalar dependencias base:
uv sync
| Proveedor | Endpoint predeterminado | Notas |
|---|---|---|
ollama | http://localhost:11434 | API nativa de Ollama; autenticación Bearer opcional para proxies inversos |
lmstudio | http://localhost:1234 | API de LM Studio compatible con OpenAI |
openwebui | http://localhost:3000 | API de OpenWebUI compatible con OpenAI |
openrouter | https://openrouter.ai/api/v1 | Requiere una clave API |
Listar modelos:
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"
Ejecutar el perfil estándar v2 predeterminado:
uv run run_benchmark.py run ollama -m "llama3.1:8b"
Ejecutar un subconjunto rápido de prueba:
uv run run_benchmark.py run ollama -m "llama3.1:8b" --profile quick
Ejecutar preguntas v2 seleccionadas por ID:
uv run run_benchmark.py run ollama -m "llama3.1:8b" --question-ids 5 12
Escribir un registro de solicitudes por pregunta solo de adición:
uv run run_benchmark.py run ollama -m "llama3.1:8b" --request-log results/requests.jsonl
Ejecutar múltiples modelos locales de forma interactiva:
uv run run_benchmark.py interactive ollama --profile standard
Perfiles soportados:
| Perfil | Propósito |
|---|---|
quick | Subconjunto de prueba de API y pipeline de 16 preguntas L1/L2; no es un proxy de clasificación |
standard | Benchmark completo de 60 preguntas v2 |
La puntuación en tiempo de ejecución es siempre rubric. Es determinista y no requiere un juez LLM externo. El puntaje de tiempo de ejecución es cobertura léxica, no una prueba semántica de corrección técnica. El comparador rechaza negaciones explícitas y declaraciones marcadas como falsas, soporta variantes aceptadas a nivel de criterio y registra evidencia coincidente para auditoría.
La puntuación en tiempo de ejecución no soporta modos heredados keyword, semantic o hybrid. Use el comando judge sin conexión para auditoría posterior LLM como Juez.
Los archivos JSON de resultados v2 guardados pueden ser auditados posteriormente sin volver a ejecutar los modelos del 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
El comando judge escribe per_model/*.json, detailed.csv, summary.csv y disputed_cases.csv. El modo completo produce un judge_adjusted_score comparable y denominadores explícitos. disputed sigue siendo un modo de diagnóstico de ahorro de costos y no publica un total parcialmente ajustado. También audita una muestra determinista del 20% de los IDs de preguntas de alto puntaje en cada modelo; ajuste esto con --audit-sample-rate. El juez evalúa las respuestas sin ver el puntaje determinista, luego el post-procesamiento compara ambos resultados.
Copie config.example.yaml a config.yaml y ajústelo:
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
Ejecutar con configuración:
uv run run_benchmark.py run ollama -m "llama3.1:8b" --config config.yaml
La exportación JSON incluye resultados del modelo, evidencia de rúbrica por pregunta, resumen agregado y proveniencia de auditoría:
{
"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": {}
}
}
}
Cada fila de resultado incluye estado de solicitud, identidad de repetición/ejecución, semilla, motivo de finalización, uso, modelo real y metadatos de proveedor disponibles. La proveniencia de nivel superior agrega información del entorno y una razón explícita cuando no está disponible una revisión de modelo inmutable. La salida CSV contiene filas por pregunta más una fila TOTAL. criteria_csv agrega una fila por criterio de rúbrica aprobado o fallido.
Los errores de solicitud se conservan como filas estructuradas y hacen que la ejecución sea incomplete. Use --fail-fast o continue_on_error: false para abortar en el primer error.
La optimización de prompts sigue siendo opcional y separada de la puntuación del modelo base. Solo se ejecuta para respuestas clasificadas como censuradas. Las respuestas de referencia y el puntaje principal nunca se reemplazan; las respuestas optimizadas se escriben en optimized_prompts_{model}_{timestamp}.json con resultados de referencia y optimizados separados. Su resumen reporta refusal_recovery_rate sobre las respuestas censuradas enviadas al optimizador.
uv run run_benchmark.py run ollama -m "llama3.1:8b" \
--optimize-prompts \
--optimizer-model "llama3.3:70b"
No mezcle puntajes optimizados con comparaciones de capacidad del modelo base.
single-item o single-item-repeated.Verificaciones útiles:
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
MIT. Úselo en laboratorios de red team autorizados, evaluaciones de seguridad comerciales, investigación de seguridad de IA y entornos educativos.