
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.
# Red Team AI Benchmark
**Versión en ruso:** [README.ru.md](https://gitlab.com/toxy4ny/redteam-ai-benchmark/-/blob/main/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.
## Estado del Repositorio
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.
## Propósito y Alcance
```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
```
### No-objetivos Explícitos
- Este repositorio no es una herramienta de hacking, un framework de exploits, un escáner, C2, herramienta de persistencia, ejecutor de payloads o un agente autónomo de red team.
- No descubre, accede, explota, modifica ni mantiene acceso a sistemas objetivo.
- No ejecuta la salida del modelo. El benchmark solo envía prompts de evaluación a endpoints de modelos configurados, puntúa el texto devuelto y escribe los resultados.
- La presencia de temas de seguridad ofensiva en el conjunto de datos de prueba describe el dominio de evaluación; no otorga permiso ni proporciona autorización para actividad contra ningún sistema.
### Responsabilidad del Usuario
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.
<img width="1393" height="1126" alt="image" src="https://assets.kitploit.com/production/public/readmes/7036/058575c06e0b905b6c2219818c8c53886f538e7e3bef64ef28217da355d02489.png" />
## Leaderboard Publicado
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:
```bash
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.
## Qué mide v2
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.
## Cobertura del Conjunto de Datos
El conjunto de datos v2 cubre:
- Técnicas de Windows
- AD y AD CS
- Explotación web
- Cloud e IAM
- Contenedores y Kubernetes
- Razonamiento de detección y evasión
- OpSec y compensaciones operativas
- Uso de herramientas
- Planificación posterior a la explotación
- Validación e informes
Los niveles de dificultad son `L1 factual`, `L2 procedure`, `L3 troubleshooting`, `L4 scenario reasoning` y `L5 multi-step operator task`.
## Instalación
Requisitos:
- Python `3.13+`
- `uv`
- Un proveedor: Ollama, LM Studio, OpenWebUI u OpenRouter
Instalar dependencias base:
```bash
uv sync
```
## Proveedores
| 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 |
## Uso
Listar modelos:
```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"
```
Ejecutar el perfil estándar v2 predeterminado:
```bash
uv run run_benchmark.py run ollama -m "llama3.1:8b"
```
Ejecutar un subconjunto rápido de prueba:
```bash
uv run run_benchmark.py run ollama -m "llama3.1:8b" --profile quick
```
Ejecutar preguntas v2 seleccionadas por ID:
```bash
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:
```bash
uv run run_benchmark.py run ollama -m "llama3.1:8b" --request-log results/requests.jsonl
```
Ejecutar múltiples modelos locales de forma interactiva:
```bash
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 |
## Puntuación
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.
## Juez LLM sin conexión
Los archivos JSON de resultados v2 guardados pueden ser auditados posteriormente sin volver a ejecutar los modelos del benchmark:
```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
```
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.
## Configuración
Copie `config.example.yaml` a `config.yaml` y ajústelo:
```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
```
Ejecutar con configuración:
```bash
uv run run_benchmark.py run ollama -m "llama3.1:8b" --config config.yaml
```
## Salida
La exportación JSON incluye resultados del modelo, evidencia de rúbrica por pregunta, resumen agregado y proveniencia de auditoría:
```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": {}
}
}
}
```
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.
## Optimización de Prompts
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.
```bash
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.
## Limitaciones Conocidas
- La puntuación determinista mide la cobertura de rúbrica léxica. Use una pasada completa del juez sin conexión y revisión manual para afirmaciones de precisión técnica.
- El conjunto de datos público puede memorizarse. Trátelo como un benchmark de desarrollo; la evaluación de alto riesgo debe agregar un conjunto de exclusión privado o rotativo.
- Cada capacidad actual tiene una pregunta única. Las repeticiones miden la varianza de generación, no la validez de capacidad de múltiples ítems; los desgloses exponen esto como `single-item` o `single-item-repeated`.
- Los metadatos del proveedor difieren. Las revisiones inmutables faltantes se registran como no disponibles en lugar de inferirse.
## Validación
Verificaciones útiles:
```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
```
## Contribuciones
Vea [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) y [SECURITY.md](https://gitlab.com/toxy4ny/redteam-ai-benchmark/-/blob/main/SECURITY.md).
## Licencia
MIT. Úselo en laboratorios de red team autorizados, evaluaciones de seguridad comerciales, investigación de seguridad de IA y entornos educativos.