Garak 大语言模型红队工具上手指南：在隔离环境完成授权探测与结果复核

Garak（Generative AI Red-teaming & Assessment Kit）是一个开源的 LLM 漏洞扫描器，由 NVIDIA 参与维护，采用 Apache 2.0 许可，通过 PyPI 以 garak 包分发。它的工作方式很直接：内置的 probe（探测器）向模型发送特定提示，收集多次生成结果，再交给 detector（检测器）判断是否出现不该出现的输出，最后汇总成报告。对安全从业者来说，它解决的是“如何把零散的越狱、提示注入、有害内容测试变成可重复执行的用例集”这个问题。但需要先讲清楚前提：Garak 只适合在你拥有明确书面授权、且与实际业务流量隔离的模型端点上运行。它产生的告警只是线索，不是漏洞结论；报告里的分数也不具备跨 probe 的可比性，官方 FAQ 对此有明确说明。

先核对资源状态与适用边界

在动手安装之前，花几分钟确认你拿到的是当前维护中的版本，而不是某个博客里三年前的快照。

• 官方仓库：NVIDIA/garak，提交历史、安全策略（SECURITY.md）、贡献指南齐全，是判断项目活跃度的第一手依据。
• 包分发：PyPI 上的 garak 页面会列出最新版本号与发布日期。把版本号写进你的测试记录，后续复核时才能对齐行为差异。
• 定位判断：Garak 常被类比成“LLM 版 nmap”，这个比喻有助于理解，但也要注意它的局限，它不会自动证明某个攻击在生产环境可行，也不做归一化评分。不同 probe 的通过率之间没有可比性，别拿 A 模型的 0.9 和 B 模型的 0.6 直接排名。

适用场景包括：上线前的模型选型对比、自建推理服务的基线检查、微调或提示词改动后的回归验证、以及 AI 应用上线前的授权红队演练。不适用的场景则需要说清楚：对第三方公开服务做大规模探测、对生产流量做在线注入、以及处理真实用户数据的环境。

准备隔离环境与授权清单

隔离不是一句口号，落到操作上至少有五件事要提前定好：

1. 测试范围：被测端点的 URL 或本地模型路径、允许调用的 API 子集、允许的 QPS 上限。
2. 凭据管理：单独申请一把仅对测试端点有效的密钥，设置有效期与额度上限，绝不复用生产密钥。密钥通过环境变量或本地凭据文件传入，不要写进命令行历史，也不要提交到 Git。
3. 数据边界：扫描会产生大量提示和模型回答，其中可能包含被诱导出的敏感内容。日志与报告必须存放在隔离主机上，上传或共享前做脱敏审查。
4. 成本与配额：如果被测对象是计费 API，先估算 probe 数量 × 每个 prompt 的多轮生成，设置硬性预算上限并准备随时中断。
5. 停止条件与联系人：提前约定出现什么现象立即停止，例如端点错误率异常、模型输出真实个人信息、或触发了上游服务商的滥用告警。写下来，别只在脑子里过一遍。

环境层面，建议用独立的虚拟机或专用容器，配一个细化的虚拟环境（venv），避免与工作站上其它 Python 工具互相污染。

安装与最小可运行示例

Garak 是 Python 项目，跨平台。安装前先固定版本，方便复现：

python3 -m venv ~/venvs/garak-lab
source ~/venvs/garak-lab/bin/activate
pip install "garak==<核对到的最新版本>"

安装完成后，先不要急着扫描。用列举类命令了解当前版本到底带了多少 probe 和 detector，这一步几乎零成本，也能提前发现依赖缺失：

garak --list_probes
garak --list_detectors

真正的第一次运行，建议遵循“最小用例”原则：只选一个 probe 家族，只对一个隔离端点，把生成次数压到最低。例如针对本地加载的开源模型或一台仅你可见的推理服务：

garak 
  --model_type <端点类型> 
  --model_name <模型标识> 
  --probes dan 
  --generations 1 
  --report_prefix run-2026-01-baseline

具体可用的 --model_type 取值、以及通过 REST 类生成器接入自建服务所需的 JSON 配置字段，随版本演进会有调整，务必以仓库内文档和 --help 输出为准，不要照抄网上文章里的参数。第一次跑通的目标不是发现问题，而是确认“能发请求、能收到回答、能落盘报告”这条链路完整。

关键配置：端点、并发与可复现性

几个直接影响结果可信度的参数，值得在配置阶段就想好：

• --generations：LLM 输出是随机的，单次测试信息量很低。官方 FAQ 明确建议多次采样，但次数增加会线性放大成本。基线测试可以从较小值起步，确认流程后再逐步加大。
• 并发相关参数：提高并发能缩短时间，但会放大对被测端点的压力，也更容易触发限流。隔离环境里可以适度调高，共享环境里应保守设置。
• --report_prefix：给每次运行一个语义化前缀，把日期、目标、probe 集合写进去。这是后续复核的索引，比事后再回忆“那次跑的是什么”靠谱得多。
• 提示集来源：部分 probe 依赖外部数据集。如果环境无外网，需要提前把数据准备到本地，否则会出现 probe 加载失败而非扫描失败的情况，容易误判。

运行结束后，默认会生成 .report.jsonl 和 .report.html 两类产物。jsonl 便于脚本处理与差异对比，html 便于人眼浏览。

输出判读：把告警、证据和风险分开

这是整个流程里最容易被跳过、也最容易出错的一步。建议按三层来处理报告：

第一层，工具告警。detector 标记为 hit 的条目，只代表“这段输出符合了该检测器的判定模式”。它可能真实有效，也可能是检测器误判，还可能是模型在压力下产生的无意义噪声。

第二层，可复现证据。对每一条你认为值得关注的 hit，回到原始记录，取出完整的提示、完整回答、所用模型与参数，单独重放至少一次。如果重放结果不稳定，说明这条告警对采样敏感，应当标注为“未复现”，而不是直接升级为风险。如果稳定复现，就把最小复现步骤整理成一段可交接的材料。

第三层，真实风险。只有把复现结果放回业务上下文，才能判断是不是风险。同样一段越狱输出，在一个只有内部员工能访问、输出不进入下游系统的问答助手里，与在一个面向公众、回答会被自动执行的应用里，后果完全不同。风险结论必须写清楚受影响的前提条件。

一张简单的对照表可以帮助团队统一口径：

停止条件、数据清理与回滚

授权测试的收尾部分常被忽略，但它决定了这次测试是否会变成新的风险源。

触发停止的典型情形：被测端点开始返回 5xx 或超时明显上升；探测内容触发了云服务商的自动化滥用告警；模型输出了疑似真实个人信息或内部凭据片段；测试时长或费用接近预设上限。出现任何一种，立即中断，保留现场记录，然后联系对接人。

数据清理清单：

• 报告文件、原始生成记录、临时下载的数据集，按组织的数据保留策略处理，该删的删、该归档的归档并加密。
• 撤销为本次测试申请的 API 密钥与临时账号。
• 若曾修改被测服务的配置（例如临时放开限流、切换模型版本），逐项核对并恢复原值。
• 删除测试用的虚拟环境或直接销毁隔离虚拟机。deactivate 后删除 venv 目录即可，Garak 本身不写入系统级路径，卸载相对干净。

回滚检查：如果你在测试过程中调整过网关、代理或 WAF 规则以放行探测流量，这些规则必须列入回滚清单，并在测试结束后逐条确认关闭，避免留下长期敞口。

常见故障速查

把 Garak 用好，靠的不是记住多少条命令，而是把“授权、隔离、可复现、可清理”这四个环节固化进流程。工具本身只是把提示集合与判定逻辑打包好，真正决定结论价值的，仍然是你在运行前定下的范围、运行中记录的参数，以及运行后逐条重放的那份耐心。