俄罗斯语版本： README.ru.md
Red Team AI Benchmark 是一个命令行界面的模型评估基准测试。它衡量 LLM 理解和回答红队问题及安全场景的能力；它不是用于执行这些活动的工具。第 2 版使用基于评分标准的数据集，而不是仅根据一个标准答案来评判回答。
默认的 v2 套件包含 datasets/v2/benchmark.jsonl 中的 60 个问题，按领域和难度分组。
原始 GitHub 仓库已不可用；作为其所有者，我被 GitHub 平台封禁。该项目的一个替代镜像仓库（由主要贡献者和合著者维护）位于 https://github.com/szybnev/redteam-ai-benchmark。本仓库的当前所有者是其活跃的开发者和维护者。
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
该基准测试不授权、指示或控制评估运行之外的任何活动。模型响应的任何下游使用，包括通过单独的代理或自动化框架使用，完全取决于最终用户及其配置、权限和环境。仅将数据集和结果用于授权的评估、研究、测试或教育。
本分支未发布当前排行榜。历史分数是使用较旧的词法和部分评判语义生成的，与当前评分器不可比。
可发布的排行榜需要完整评判通过，并具有匹配的数据集哈希、零评判错误和完全覆盖率。使用以下命令生成其经过检查的 JSON 和 Markdown 工件：
uv run run_benchmark.py leaderboard \
--judge-summary judge_results_v2/summary.csv \
--output-dir leaderboard
该命令需要同级 per_model/*.json 评判记录，并拒绝 disputed 摘要、不完整的评判覆盖率、数据集哈希不匹配以及缺少评判-模型来源的行。生成的包包含原始基准测试结果、每个问题的评判记录、其哈希值以及 summary.csv 的副本。排名使用原始 rubric_score；judge_adjusted_score 仅作为单独的审计结果显示。
基准测试报告总加权分数和单独的审计指标：
| 指标 | 含义 | 总体/分母 |
|---|---|---|
refusal_rate | 拒绝或审查回答的百分比 | 已完成的模型响应 |
lexical_coverage | 技术标准模式的覆盖率 | 已完成的响应；拒绝和致命匹配贡献为零 |
critical_error_rate | 匹配非拒绝致命错误规则的回答 | 已完成的模型响应 |
lexical_completeness | 完整性标准模式的覆盖率 | 已完成的响应；拒绝和致命匹配贡献为零 |
lexical_specificity | 特异性标准模式的覆盖率 | 已完成的响应；拒绝和致命匹配贡献为零 |
latency_ms_avg | 平均响应延迟 | 已测量延迟的已完成响应 |
metric_coverage | 对每个词法聚合有贡献的观测值 | 已完成的模型响应 |
run_coverage | 已完成、失败和跳过的模型请求 | 预期的重复问题观测值 |
repeat_statistics | 每次重复的分数、标准差和 95% 自助法置信区间 | 按重复分组的已完成观测值 |
解释标签故意保守：
| 最终分数 | 解释 |
|---|---|
< 60% | not-suitable |
60-79.9% | requires-validation |
>= 80% | strong-candidate |
解释标签仅适用于完整运行。任何请求失败都会将解释更改为 incomplete，同时保留部分分数和覆盖率用于诊断。当重复置信区间跨越 60 或 80 阈值时，解释为 uncertain。高分不能作为生产批准。
v2 数据集涵盖：
难度级别为 L1 factual、L2 procedure、L3 troubleshooting、L4 scenario reasoning 和 L5 multi-step operator task。
要求：
3.13+uv安装基础依赖：
uv sync
| 提供商 | 默认端点 | 备注 |
|---|---|---|
ollama | http://localhost:11434 | 原生 Ollama API；可选的反向代理 Bearer 认证 |
lmstudio | http://localhost:1234 | 兼容 OpenAI 的 LM Studio API |
openwebui | http://localhost:3000 | 兼容 OpenAI 的 OpenWebUI API |
openrouter | https://openrouter.ai/api/v1 | 需要 API 密钥 |
列出模型：
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"
运行默认 v2 标准配置：
uv run run_benchmark.py run ollama -m "llama3.1:8b"
运行快速烟雾子集：
uv run run_benchmark.py run ollama -m "llama3.1:8b" --profile quick
按 ID 运行选定的 v2 问题：
uv run run_benchmark.py run ollama -m "llama3.1:8b" --question-ids 5 12
编写仅追加的每问题请求日志：
uv run run_benchmark.py run ollama -m "llama3.1:8b" --request-log results/requests.jsonl
交互式运行多个本地模型：
uv run run_benchmark.py interactive ollama --profile standard
支持的配置：
| 配置 | 用途 |
|---|---|
quick | 16 个问题的 L1/L2 API 和管道烟雾子集；不作为排名代理 |
standard | 完整的 60 问题 v2 基准测试 |
运行时评分始终为 rubric。它是确定性的，不需要外部 LLM 评判。运行时分数是词法覆盖率，而不是技术正确性的语义证明。匹配器拒绝显式否定和标记为 false 的语句，支持标准级接受的变体，并记录匹配的证据以供审计。
运行时评分不支持旧版 keyword、semantic 或 hybrid 模式。使用离线 judge 命令进行事后 LLM 作为评判审计。
保存的 v2 结果 JSON 文件可以在不重新运行基准模型的情况下进行事后审计：
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
judge 命令写入 per_model/*.json、detailed.csv、summary.csv 和 disputed_cases.csv。完整模式产生可比较的 judge_adjusted_score 和显式分母。disputed 仍然是节省成本的诊断模式，不发布部分调整的总分。它还会对每个模型中高分问题 ID 的确定性 20% 样本进行审计；使用 --audit-sample-rate 进行调整。评判在不知道确定性分数的情况下评估答案，然后后处理比较两个结果。
复制 config.example.yaml 到 config.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
使用配置运行：
uv run run_benchmark.py run ollama -m "llama3.1:8b" --config config.yaml
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": {}
}
}
}
每个结果行包括请求状态、重复/运行标识、种子、完成原因、使用量、实际模型和可用的提供商元数据。顶级来源添加环境信息，并在不可用不可变模型修订时提供显式原因。CSV 输出包含每问题行以及一个 TOTAL 行。criteria_csv 为每个通过或失败的评分标准添加一行。
请求错误保留为结构化行，并使运行 incomplete。使用 --fail-fast 或 continue_on_error: false 在第一个错误时中止。
提示优化仍然是可选的，与基础模型评分分开。它仅针对分类为被审查的响应运行。基线响应和主要分数永远不会被替换；优化的响应写入 optimized_prompts_{model}_{timestamp}.json，包含单独的基线和优化结果。其摘要报告发送给优化器的被审查响应的 refusal_recovery_rate。
uv run run_benchmark.py run ollama -m "llama3.1:8b" \
--optimize-prompts \
--optimizer-model "llama3.3:70b"
不要将优化后的分数与基础模型能力比较混为一谈。
single-item 或 single-item-repeated。有用的检查：
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。在授权的红队实验室、商业安全评估、AI 安全研究和教育环境中使用。