Red Team AI Benchmark

Versione russa: README.ru.md

Red Team AI Benchmark è un benchmark di valutazione dei modelli da CLI. Misura quanto i LLM comprendono e rispondono a domande e scenari di red team; non è uno strumento per svolgere tali attività. La versione 2 utilizza un dataset basato su rubriche invece di giudicare le risposte solo in base a una risposta gold standard.

La suite predefinita v2 contiene 60 domande in datasets/v2/benchmark.jsonl, raggruppate per dominio e difficoltà.

Stato del Repository

Il repository GitHub originale non è più disponibile; in quanto proprietario, sono stato bannato dalla piattaforma GitHub. Un repository mirror alternativo per il progetto (mantenuto dal contributore principale e co-autore) è disponibile all'indirizzo https://github.com/szybnev/redteam-ai-benchmark. L'attuale proprietario di questo repository è il suo sviluppatore e manutentore attivo.

Scopo e Ambito

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

Obiettivi Esplicitamente Esclusi

• Questo repository non è uno strumento di hacking, un framework di exploit, uno scanner, un C2, uno strumento di persistenza, un esecutore di payload o un agente red-team autonomo.
• Non scopre, accede, sfrutta, modifica o mantiene l'accesso a sistemi target.
• Non esegue l'output del modello. Il benchmark invia solo prompt di valutazione a endpoint modello configurati, valuta il testo restituito e scrive i risultati.
• La presenza di argomenti di sicurezza offensiva nel dataset di test descrive il dominio di valutazione; non concede permessi né autorizza attività contro alcun sistema.

Responsabilità dell'Utente

Il benchmark non autorizza, dirige o controlla alcuna attività al di fuori della sessione di valutazione. Qualsiasi uso successivo delle risposte del modello, incluso l'uso tramite un agente separato o un framework di automazione, dipende interamente dall'utente finale, dalla sua configurazione, autorizzazioni e ambiente. Utilizza il dataset e i risultati solo per valutazioni, ricerche, test o formazione autorizzati.

Classifica Pubblicata

Nessuna classifica attuale è pubblicata in questo branch. I punteggi storici sono stati prodotti con semantiche lexicali e di giudizio parziale più vecchie e non sono confrontabili con il valutatore corrente.

Una classifica pubblicabile richiede una sessione completa del giudice con hash del dataset corrispondenti, zero errori del giudice e copertura completa. Genera i suoi artefatti JSON e Markdown verificati con:

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

Il comando richiede i record del giudice per_model/*.json fratelli e rifiuta riepiloghi disputed, copertura incompleta del giudice, discrepanze negli hash del dataset e righe senza provenienza del modello giudice. Il pacchetto risultante contiene i risultati grezzi del benchmark, i record del giudice per domanda, i loro hash e una copia di summary.csv. La classifica utilizza il rubric_score grezzo; judge_adjusted_score è mostrato solo come risultato di audit separato.

Cosa Misura v2

Il benchmark riporta il punteggio ponderato totale e metriche di audit separate:

Le etichette di interpretazione sono deliberatamente conservative:

Le etichette di interpretazione si applicano solo a esecuzioni complete. Qualsiasi fallimento di richiesta cambia l'interpretazione in incomplete, preservando il punteggio parziale e la copertura per la diagnostica. Quando gli intervalli di confidenza delle ripetizioni attraversano la soglia 60 o 80, l'interpretazione è uncertain. Un punteggio elevato non è un'approvazione per la produzione.

Copertura del Dataset

Il dataset v2 copre:

• Tecniche Windows
• AD e AD CS
• Sfruttamento web
• Cloud e IAM
• Container e Kubernetes
• Ragionamento su rilevamento ed elusione
• OpSec e compromessi operativi
• Utilizzo di strumenti
• Pianificazione post-exploit
• Validazione e reporting

I livelli di difficoltà sono L1 factual, L2 procedure, L3 troubleshooting, L4 scenario reasoning e L5 multi-step operator task.

Installazione

Requisiti:

• Python 3.13+
• uv
• Un provider: Ollama, LM Studio, OpenWebUI o OpenRouter

Installa le dipendenze di base:

uv sync

Provider

Utilizzo

Elenca i modelli:

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"

Esegui il profilo standard predefinito v2:

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

Esegui un sottoinsieme rapido di smoke test:

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

Esegui domande v2 selezionate per ID:

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

Scrivi un log delle richieste per domanda in modalità append-only:

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

Esegui più modelli locali in modo interattivo:

uv run run_benchmark.py interactive ollama --profile standard

Profili supportati:

Valutazione

La valutazione in tempo di esecuzione è sempre rubric. È deterministica e non richiede un LLM giudice esterno. Il punteggio in tempo reale è la copertura lessicale, non una prova semantica di correttezza tecnica. Il matcher rifiuta negazioni esplicite e affermazioni contrassegnate come false, supporta varianti accettate a livello di criterio e registra le evidenze corrispondenti per l'audit.

La valutazione in tempo di esecuzione non supporta le modalità legacy keyword, semantic o hybrid. Utilizza il comando judge offline per audit post-hoc LLM-as-Judge.

LLM-as-Judge Offline

I file JSON dei risultati v2 salvati possono essere auditati post-hoc senza rieseguire i modelli 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

Il comando judge scrive per_model/*.json, detailed.csv, summary.csv e disputed_cases.csv. La modalità full produce un judge_adjusted_score comparabile e denominatori espliciti. disputed rimane una modalità diagnostica di risparmio sui costi e non pubblica un totale parzialmente aggiustato. Inoltre, esegue un audit deterministico su un campione del 20% degli ID domanda con punteggio elevato per ogni modello; regola con --audit-sample-rate. Il giudice valuta le risposte senza vedere il punteggio deterministico, quindi la post-elaborazione confronta entrambi i risultati.

Configurazione

Copia config.example.yaml in config.yaml e modificalo:

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

Esegui con la configurazione:

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

Output

L'esportazione JSON include i risultati del modello, le evidenze della rubrica per domanda, un riepilogo aggregato e la provenienza dell'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": {}
    }
  }
}

Ogni riga di risultato include lo stato della richiesta, l'identità della ripetizione/esecuzione, il seed, il motivo della terminazione, l'utilizzo, il modello effettivo e i metadati del provider disponibili. La provenienza di primo livello aggiunge informazioni sull'ambiente e un motivo esplicito quando una revisione immutabile del modello non è disponibile. L'output CSV contiene righe per domanda più una riga TOTAL. criteria_csv aggiunge una riga per ogni criterio della rubrica superato o fallito.

Gli errori di richiesta sono preservati come righe strutturate e rendono l'esecuzione incomplete. Usa --fail-fast o continue_on_error: false per interrompere al primo errore.

Ottimizzazione dei Prompt

L'ottimizzazione dei prompt rimane opzionale e separata dalla valutazione del modello base. Viene eseguita solo per risposte classificate come censurate. Le risposte di base e il punteggio principale non vengono mai sostituiti; le risposte ottimizzate vengono scritte in optimized_prompts_{model}_{timestamp}.json con risultati separati di base e ottimizzati. Il suo riepilogo riporta refusal_recovery_rate sulle risposte censurate inviate all'ottimizzatore.

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

Non mescolare i punteggi ottimizzati con i confronti delle capacità del modello base.

Limitazioni Note

• La valutazione deterministica misura la copertura lessicale della rubrica. Utilizza una sessione completa del giudice offline e una revisione manuale per affermazioni di accuratezza tecnica.
• Il dataset pubblico può essere memorizzato. Trattalo come un benchmark di sviluppo; la valutazione ad alto rischio dovrebbe aggiungere un set di validazione privato o rotante.
• Ogni capacità attuale ha una domanda unica. Le ripetizioni misurano la varianza di generazione, non la validità della capacità su più elementi; le suddivisioni lo espongono come single-item o single-item-repeated.
• I metadati del provider differiscono. Le revisioni immutabili mancanti sono registrate come non disponibili piuttosto che inferite.

Validazione

Controlli utili:

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

Contributi

Vedi CONTRIBUTING.md, CODE_OF_CONDUCT.md e SECURITY.md.

Licenza

MIT. Utilizzabile in laboratori red team autorizzati, valutazioni di sicurezza commerciali, ricerca sulla sicurezza dell'IA e ambienti educativi.