redteam-ai-benchmark

# Red Team AI Benchmark

**Versione russa:** [README.ru.md](https://gitlab.com/toxy4ny/redteam-ai-benchmark/-/blob/main/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

```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
```

### 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.

<img width="1393" height="1126" alt="image" src="https://assets.kitploit.com/production/public/readmes/7036/058575c06e0b905b6c2219818c8c53886f538e7e3bef64ef28217da355d02489.png" />

## 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:

```bash
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:

| Metrica | Significato | Popolazione / denominatore |
| --- | --- | --- |
| `refusal_rate` | Percentuale di risposte rifiutate o censurate | Risposte del modello completate |
| `lexical_coverage` | Copertura dei pattern di criterio tecnico | Risposte completate; rifiuti e corrispondenze fatali contribuiscono zero |
| `critical_error_rate` | Risposte che corrispondono a regole di errore fatale non rifiutate | Risposte del modello completate |
| `lexical_completeness` | Copertura dei pattern di criterio di completezza | Risposte completate; rifiuti e corrispondenze fatali contribuiscono zero |
| `lexical_specificity` | Copertura dei pattern di criterio di specificità | Risposte completate; rifiuti e corrispondenze fatali contribuiscono zero |
| `latency_ms_avg` | Latenza media della risposta | Risposte completate con latenza misurata |
| `metric_coverage` | Osservazioni che contribuiscono a ciascun aggregato lessicale | Risposte del modello completate |
| `run_coverage` | Richieste del modello completate, fallite e saltate | Osservazioni previste per domanda-ripetizione |
| `repeat_statistics` | Punteggi per ripetizione, deviazione standard e IC bootstrap 95% | Osservazioni completate raggruppate per ripetizione |

Le etichette di interpretazione sono deliberatamente conservative:

| Punteggio finale | Interpretazione |
| --- | --- |
| `< 60%` | `not-suitable` |
| `60-79.9%` | `requires-validation` |
| `>= 80%` | `strong-candidate` |

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:

```bash
uv sync
```

## Provider

| Provider | Endpoint predefinito | Note |
| --- | --- | --- |
| `ollama` | `http://localhost:11434` | API Ollama nativa; autenticazione Bearer opzionale per reverse proxy |
| `lmstudio` | `http://localhost:1234` | API LM Studio compatibile con OpenAI |
| `openwebui` | `http://localhost:3000` | API OpenWebUI compatibile con OpenAI |
| `openrouter` | `https://openrouter.ai/api/v1` | Richiede una chiave API |

## Utilizzo

Elenca i modelli:

```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"
```

Esegui il profilo standard predefinito v2:

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

Esegui un sottoinsieme rapido di smoke test:

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

Esegui domande v2 selezionate per ID:

```bash
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:

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

Esegui più modelli locali in modo interattivo:

```bash
uv run run_benchmark.py interactive ollama --profile standard
```

Profili supportati:

| Profilo | Scopo |
| --- | --- |
| `quick` | Sottoinsieme di smoke test per API e pipeline di 16 domande L1/L2; non un proxy di classifica |
| `standard` | Benchmark v2 completo di 60 domande |

## 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:

```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
```

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:

```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
```

Esegui con la configurazione:

```bash
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:

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

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.

```bash
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:

```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
```

## Contributi

Vedi [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) e [SECURITY.md](https://gitlab.com/toxy4ny/redteam-ai-benchmark/-/blob/main/SECURITY.md).

## Licenza

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