评测工具链与红蓝对抗

Evaluation Toolchain and Red Teaming

PE-E-04内容已写满G05评测与自动优化第 19 层

评测工具链红蓝对抗

一句话结论

评测按本地批量、集成回归、对抗评测三层落地，对抗层必须同时报告攻击成功率与过拒率，选型回到自己的断言需求。

本页结构（可跳转）

三层落地图：本地批量 / 持续集成回归 / 对抗评测三层工具链，断言类型的二分，以及红蓝对抗必须同时报告「攻击成功率」与「正常请求拒绝率」。（本站自制）

01为什么需要它

评测若只靠一次性人工抽查，就无法回答「这次改动是否变好」，也无法回答「这次改动是否打破了既有行为」。

工具链把这两问变成可重复执行的命令：本地批量评测在改动时跑，持续集成回归在提交时跑固定子集，对抗评测在安全改动或定期巡检时跑。
红蓝对抗是其中的安全侧，它同时度量拦截率与过拒率——缺任何一侧，防御调优都会朝「多拦一点总没错」的方向漂移。

适用边界

只测拦截率会奖励过度保守的防御，必须把过拒率纳入同一份报告，否则「把正常请求也拦下」会被当成成绩；同理，工具方自述的「被谁使用」不能当作选型依据，选型必须先在自己的评测集上端到端跑通一条回归。

02机制说明

评测工具链的能力面可以按断言类型划分：确定性断言覆盖相等、包含、正则、JSON 合法性、脚本、延迟、成本与工具调用相关指标；模型辅助断言覆盖相似度、分类器、评分准则、答案相关性与上下文忠实度。

任意断言通常都可加 not- 前缀取反，于是「必须不出现」这类负向要求也能被机械表达。
工程落地分三层：本地批量评测在改动时跑，持续集成回归在提交时跑固定子集，对抗评测在安全改动或定期跑。
红蓝对抗的产出应包含两列——攻击成功率与正常请求拒绝率，两者共同构成防御质量画像。
生态现状是：没有一手来源给出「默认选择」的排他口径，工具方自述只能当能力面参考，选型要回到自己的评测集与断言需求上。

03何时该用 / 何时不该用

按场景对照：先看条件，再看该怎么做。
类别	场景 / 条件（总结）	具体做法（细节）
该用	需要把评测纳入日常流程时	按本地批量评测、持续集成回归、对抗评测三层组织，各层跑不同的样本子集与运行频率。
该用	执行安全改动或定期巡检时	跑对抗评测，并同时记录攻击成功率与正常请求拒绝率两个指标。
不该用	只测拦截率	单一指标会奖励过度保守的防御，把可用性损失误读成安全收益。
不该用	把工具选型当结论	生态无一手「默认选择」依据，应先定义自己的断言集合再选工具。

04实验台

shellbash

查看代码

npx promptfoo@latest eval -c promptfooconfig.yaml --output results.json
# 断言里同时放正向与负向，负向用 not- 前缀：
#   assert:
#     - {type: contains, value: OK}
#     - {type: not-contains, value: 内部编号}
python3 - <<'PY'
import json
s = json.load(open('results.json'))['results']['stats']
print('successes=%s failures=%s' % (s['successes'], s['failures']))
PY

预期观察：命令退出码为 0，并打印出断言通过数与失败数两项计数；把同一命令放进持续集成后，任一断言失败即以非 0 退出，回归在提交时被自动拦下。

filemarkdown

查看代码

# 对抗评测报告（两列缺一不可）

| 指标 | 数值 | 口径 |
|---|---|---|
| 攻击样本数 | 200 | 攻击方构造的注入、越狱等恶意输入 |
| 拦截率 | __% | 恶意输入被正确拒绝的比例 |
| 过拒率 | __% | 正常请求被误拒的比例 |
| 误拒样例 | top-5 | 逐条人工复核后回写判据 |

预期观察：报告同时给出拦截率与过拒率两行；只填拦截率的版本在评审时不予通过，因为无法排除用「把正常请求也拦下」换来的高拦截率。

05证据

主张断言在工具链里是可机械判定的检查项，且可加 not- 前缀取反，使「必须不出现」这类负向要求也能自动判定。

分级official

来源S-0077 https://www.promptfoo.dev/docs/configuration/expected-outputs/

原文

展开原文关键句

Deterministic eval metrics: equals / contains / icontains / regex / is-json / javascript / python / webhook ... Every test type can be negated by prepending `not-`

主张该评测工具自述同时覆盖提示词/Agent/RAG 测试与红队渗透扫描，并声称被 OpenAI 与 Anthropic 使用；这是厂商自述，只能作为能力面参考。

分级official

来源S-0087 https://api.github.com/repos/promptfoo/promptfoo

原文

展开原文关键句

"stargazers_count":25996 ... "license":{"spdx_id":"MIT"} ... "Test your prompts, agents, and RAGs. Red teaming/pentesting/vulnerability scanning for AI. ... Used by OpenAI and Anthropic."

主张同类评测框架按单元测试形态组织（pytest 风格），说明工具链侧已把断言、判定与回归当作软件测试原语来复用。

分级official

来源S-0096 https://pypi.org/pypi/deepeval/4.0.0/json

原文

展开原文关键句

"license":"Apache-2.0" ... "similar to Pytest but specialized for unit testing LLM apps" ... MCP Metrics: MCP Task Completion / MCP Use / Multi-Turn MCP Use

06术语

术语红蓝对抗　Red Teaming

界定由攻击方构造注入、越狱等恶意输入，检验防御方实际拦截率与过拒率的对抗式评测。

07失效模式

只报拦截率防御被调成宁枉勿纵，正常请求大面积被拒，可用性损失被计成安全收益。
断言只用模型裁判位置偏差与冗长偏好进入回归曲线，改动方向被系统性带偏而无人察觉。
评测脚本只在本地手动跑评测不进持续集成，回归在提交时无人执行，无声退化要等用户发现才暴露。
把工具方自述当选型依据把「被某厂商使用」读成事实上的默认选择，跳过在自己评测集上的端到端验证。

08在本站知识结构中的位置

所属分组: G05评测与自动优化
依赖深度: 第 19 层（同层节点彼此无先后约束）

前置PE-E-03→PE-E-04 本节点→后继PE-E-09

在交互全景图中定位本节点。