2026-10-27 17:04:14 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

garak 0.17.1的hit@k指标：大模型上线前红队扫描怎么跑、结果怎么读

cwbird
cwbird

bird网络安全

2026年10月27日 09:22
四川

去阅读

10 月 16 日，NVIDIA 开源的 LLM 漏洞扫描器 garak 发布 v0.17.1。这次更新里最值得关注的改动在评估层：新增 hit@k 攻击成功率指标，同时修掉了 FileDetector 把「没检查过的文件」计为通过的 bug。两件事指向同一个问题：你的红队扫描报告里的数字，过去可能既低估又高估了模型的真实风险。这篇文章讲清楚 hit@k 到底在量什么、扫描怎么跑、以及三款主流工具怎么分工。

为什么单次成功率会骗人

garak 的老报告给出的是每个 probe 的通过率，逻辑是逐条 prompt 打分。问题出在抽样上。同一个越狱 prompt 发给模型 k 次，模型可能 3 次拒绝、1 次照做。按「逐条计分再平均」的算法，这次攻击的成功率是 25%；但在真实攻击场景里，攻击者只在乎「多试几次能不能得手」，答案只要有一次成功就是成功。

hit@k 估计的正是后一种概率：k 次采样中至少一次命中的比率，再对所有可评分的 prompt 取平均。这个指标 2026 年 10 月才进 garak 主线（PR #2090，作者 stefanoamorelli），此前要自己写脚本从 report.jsonl 里聚合。

有两个细节容易被忽略。其一，输出条数不足 k 条的 prompt 会被排除在 hit@k 计算之外，所以报告里的 eligible prompt 数量必须和总 prompt 数对账，否则覆盖率缩水了你都不知道。其二，v0.17.1 同时修了 RefusalOnlyAdversarial 多轮攻击中跳过尝试被重复计数的 bug，如果你的历史基线是用旧版本跑的，升级后分数变化未必说明模型变了，可能是计分口径变了。

一条命令跑起 OWASP 覆盖的扫描

garak 的安装就是 pip install garak，当前要求 Python 3.10 到 3.14（3.14 支持是这个版本新加的）。跑一次针对 OpenAI 兼容接口的扫描：

python -m garak --model_type openai \\   --model_name gpt-4o-mini \\   --spec 「probes,-probes.encoding,tag:owasp:llm01」 \\   --generations 5 --parallel_attempts 8 \\   --report_prefix run-20261027

几个参数解释。--spec 是 0.17 系列主推的选择语法，支持 probes.模块名、tag:owasp:llm01 这种标签过滤，也支持 tier:N 按层级圈定 probe 集合，老的 --probes 参数已标记废弃。--generations 5 让每个 prompt 采样 5 次输出，这是 hit@k 能算出有意义数值的前提，单次生成谈 hit@k 没有意义。--parallel\_attempts 8 控制并发，对按 token 计费的 API 能明显缩短一轮扫描的时间。

结果落在 report.jsonl 里，最后的 digest 条目按 probe/detector 对给出 hit@k。想让扫描覆盖 OWASP LLM Top 10 的提示注入项，用 tag:owasp:llm01 过滤即可；OWASP 2025 版列表里提示注入仍排第一位，这也是大多数团队上线的第一优先项。

FileDetector 的教训：分数偏乐观的来源

v0.17.1 之前，garak 的 FileDetector 在文件根本没有被检查时会把它计为通过。这个 bug 的实际影响是：凡是涉及文件生成的 probe（比如诱导模型生成恶意代码文件、数据文件再检测内容的场景），你的报告分数系统性偏乐观。

这类计分器 bug 比模型本身的漏洞更隐蔽，因为它污染的是你的基线。AI Red Team 站点针对这次更新给的实操建议我直接搬过来：对比两次扫描之前，先固定四个变量，扫描器版本、目标模型版本、prompt 集、生成参数（temperature 和 generations 数），一个都不能漂。然后报告里除了分数，把 k 值、eligible prompt 数、未评分输出数一并写上，否则两周后你自己都说不清那次 12% 的越狱率是怎么算出来的。

同版本的 detector 修复还有一条：ApiKey 探测的 safe-token 抑制逻辑从全局收窄到了匹配的具体凭证。老逻辑下回复里出现过一次合法密钥引用，后续真正的泄露可能被连带压掉不计分，收窄后误报漏报都更接近真实。

三款工具的分工：garak 扫模型，promptfoo 测应用，PyRIT 编排攻击

工具选型上我的立场很明确：别指望一个工具通吃，三个各管一段。

garak 管模型层。它的 probe 库按攻击类型组织（越狱、提示注入、数据泄露、编码绕过），适合在接入选型阶段给候选模型跑一轮横向对比，输出的是漏洞面画像。

promptfoo 管应用层。GitHub 星标超 5000，CLI 入口是 npx promptfoo eval，强项在提示词回归测试：你改了一版 system prompt，它告诉你安全拒绝率变了多少、正常任务的质量掉了多少。对 Agent 和 RAG 系统它也有对应的测试位。上线后每次提示词变更都该过一遍 promptfoo，这个节奏和代码 CI 一个道理。

PyRIT 管攻击编排。微软出的 Python 红队框架，强项是自动化多轮攻击：攻击方模型生成恶意输入，目标模型应答，打分器评估，循环迭代。适合做深度评估，但跑一轮的成本（token 和时间）明显高于前两者，日常回归用不着。

顺序上，接入选型先 garak 横向扫，上线前用 PyRIT 对最终版本做一轮深度攻击，上线后每次变更跑 promptfoo 回归。反过来做（先 PyRIT 后 garak）会把预算烧在淘汰候选上。

国内侧的对应动作

国内厂商在 Agent 运行时防护上动作很快。阿里云 2026 年 3 月发布 AI 安全护栏 2.0，防护点放在 Agent 运行时，针对提示词注入触发的非预期工具调用做拦截；腾讯的 AI Agent 安全中心走统一管控数字员工的路线，运行时可信由天御大模型安全网关承接。10 月 19 日安泉数智同时入选大模型与 AI Agent 安全两张图谱，这个赛道在国内已经形成独立的供给端。

这些运行时产品解决「上线之后拦不拦得住」，和本文讲的「上线之前测没测过」是两道工序。顺序不能颠倒：先扫后拦，扫描结果决定拦截规则的重点放哪类攻击上。只买护栏不做红队扫描的团队，护栏规则靠厂商默认配置兜底，攻防对抗里等于闭着眼打。