NVIDIA Garak 开源项目架构、工作流、策略与治理

1 概览与痛点

彩色总览图：

围绕总体架构，我们将问题拆解为三类叙述：

• 业务痛点叙述：从“谁在用”“他们遇到了什么”到“为什么传统方法难以解决”，明确范围与优先级。例如客服问答的主要风险集中在提示注入与隐私泄露，代码助手则集中在危险指导与越权。
• 工程可行性叙述：如何将风险检测转化为流水线，可复现、可审计、可治理，包括插件边界、日志事件、报告格式的统一与版本化。
• 组织治理叙述：评估并非一次性，而是持续流程；需要责任人、工单闭环、门禁阈值与豁免机制，以保障交付节奏与合规稳定。

这三类叙述贯穿全文，帮助读者从“框架理解”走向“落地执行”。

2 架构与工作流（组件+时序）

2.1 组件关系

该组件关系图展示了从探针到报告的清晰责任边界：探针负责构造输入并触发风险，生成器承载与后端的交互，检测器在输出侧进行归类与判定，评估器则将各类命中汇总为可阅读的结论与可审计的证据。通过这种分层设计，团队可以分别迭代各模块而不破坏整体流程，形成“稳定的流水线 + 快速的局部优化”的良性结构。

2.2 时序工作流

该时序图强调了评估运行的关键握手点：参数配置决定运行范围与成本，探针与模型的往返是风险触发的核心，检测器与评估器负责把原始文本转化为决策依据。只要在每个握手点保持可观察性与审计留痕，评估就能做到可复现、可比较、可治理。

2.3 参数与约定

时序中的每一环都可能成为风险放大点。尤其是“探针→模型→检测器”三个环节：

• 探针环节：如果缺少场景化设计，容易出现“命中率低但无决策价值”的问题。应结合业务域构造提示库，并维护标签（危害类型、场景、成本）。
• 模型环节：不同后端与模型版本的策略过滤能力差异大，需记录“版本指纹”，在报告中体现，以便比较与复测。
• 检测器环节：避免单一关键词匹配，建议采用“关键词+语义相似度+规则库”多通道，降低误报与漏报。

令牌应采用最小权限，评估端点与生产严格隔离，并设置合理的限流与超时策略，以控制成本与稳定性。

3 功能与策略（探针+检测+评分）

3.1 探针分类与策略

策略图：

3.2 检测维度与评分

为了让评分可用于生产决策，应建立“指标→动作”的映射：

• 当“PII泄露”为非零时，自动阻断发布；同时触发工单与责任人复核，必要时增加策略库禁令。
• 当“越狱样例”在低数量范围内出现，允许豁免，但必须登记并在下个版本的基线中重点复测。
• 幻觉比例过高时，优先改进“引用质量”，要求模型输出来源与可验证片段；否则报告中的结论不可直接用于客户交付。

重点标注：评分需结合业务影响（资产/规模/法律罚则），避免“指标漂亮但无决策价值”。

4 部署与使用（安装、后端、Harness）

4.1 安装

python -m pip install -U garak

开发版：

python -m pip install -U git+https://github.com/NVIDIA/garak.git@main

贡献者：

conda create --name garak "python>=3.10,<=3.12"
conda activate garak
git clone https://github.com/NVIDIA/garak.git
cd garak
python -m pip install -e .

4.2 后端矩阵

4.3 Harness（probewise）

• 实例化探针，读取 primary_detector 与 extended_detectors。
• 并发与限流控制，输出进度与阶段报告。

并发应与预算挂钩，避免拖垮后端或造成费用失控；在高负载窗口使用分批与退避策略，保持系统稳态。

在使用 Harness 时，推荐以下运行策略：

• 先跑“低成本高价值”的探针集合（编码/越狱/模板劫持），得到初始命中分布；再按需要启用高成本探针（如自适应迭代）。
• 所有运行必须写入统一的 run_id（时间戳或流水号），并输出到固定 outdir，保持审计一致性。
• 长跑任务启用断点续跑与阶段性汇总，避免因网络或令牌异常导致整体失败。

5 治理与集成（GRC、CI/CD门禁）

5.1 GRC与门禁

5.2 CI/CD流程（彩色Mermaid）

PR 检查应输出可链接报告与命中样例，支持审阅与复现；关联工单与责任人，让修复路径清晰、可追踪。

在集成层面，将报告与工单系统打通尤为关键：

• PR 评审页展示命中摘要与样例链接，允许安全官直接点击查看脱敏片段与上下文。
• 工单自动附带“复测建议”与“阈值状态”，减少沟通成本。
• 迭代结束后，自动生成“版本变化”小结：命中率、严重度、误报处理情况，便于季度审计与策略迭代。

6 案例与实践（对抗样例、隐私合规、性能工程）

6.1 对抗样例（三例）

6.2 多轮对话与工具链注入（时序）

工具链评估应在隔离环境或模拟模式下进行，防止真实数据在测试过程中外泄。

6.3 性能工程与隐私合规

在隐私合规上，最常见的失误是“报告样例脱敏不充分”。经验表明：

• 不要仅遮蔽前后各若干字符，应采用“结构化脱敏”，保留字段类型但移除具体值（如邮箱→<email>）。
• 对跨境传输进行静态阻断与动态告警双重控制，避免评估人员无意将样例贴到外部系统。
• 对命中样例的访问设定短期令牌与审计日志，确保“看过谁，在何时，为何目的”。

8 深入实践与工程细则

8.1 概览与痛点

• 风险生态的动态性：生成式AI模型的知识边界随训练数据与指令调优而变化，导致同一探针在不同版本间命中率差异明显。企业需建立“版本化评估基线”，将时间维度纳入风险趋势分析。
• 业务上下文的影响：客服场景与代码助手场景的风险显著不同，前者偏向隐私与越权，后者偏向危险指导与不安全示例输出。评估必须“场景绑定”，不可使用一套通用探针覆盖所有业务。
• 人因因素：红队评估与修复链路需要“所有者明确”，否则容易出现报告无人认领、风险积压的情况。建议将“模型负责人”与“合规负责人”在工单系统中显式绑定。
• 预算与优先级：评估成本由调用费用、人工复核、报告生成与审计归档组成。应建立“评估预算配额”，在超限时触发降级策略（缩小探针集合、延后非关键扫描）。

表：风险生态与治理要点

落地建议：先从单一业务域建立“场景化探针库”和“阈值门禁”，形成可复用模板；再逐步扩展到其他域，避免“一开始就全面铺开”造成治理混乱与成本失控。

8.2 架构与工作流

• 插件边界与接口契约：base.py 抽象类定义了生命周期方法（初始化、执行、清理）。自定义插件应遵循“幂等性”原则，避免副作用影响其他模块。
• Harness资源治理：probewise 在并发执行时可采用“令牌桶+优先队列”策略，将高风险探针优先执行，低风险或高成本探针延迟或分批。
• 观测性与回溯：所有阶段应产生结构化事件（开始/结束/结果），输出到统一的事件总线或日志聚合器，便于后续统计与审计。

Mermaid 类图（插件抽象）：

事件流示意（彩色）：

这套类与事件模型不仅适用于 Garak，也适用于其他评估工具。统一接口与事件有利于将评估结果汇入“安全数据湖”，进行全局分析与报表生成。

8.3 功能与策略

• 编码/混淆的组合攻击：将 Base64 与 ROT13 混合，插入零宽字符，再要求模型“逐步翻译并解释语义”，使单次过滤难以覆盖。
• 越狱的场景化构造：对代码助手注入“评教模式”（输出教学示例），并在示例中嵌入危险操作的“学术讨论”，规避显式禁止词。
• 动态攻击生成（atkgen）的评价：在每轮攻击后记录“强度提升因子”，并对命中样例进行聚类，识别最有效提示模板，作为后续基线的一部分。

表：组合攻击策略与防护建议

策略选择的核心是“性价比”。例如编码/混淆往往成本低、命中价值高；而自适应迭代需更多调用预算与人工复核，不应作为日常基线的第一优先。

8.4 部署与使用

• 分环境策略：测试环境与生产环境完全隔离，日志与报告存储路径不同，避免测试数据泄露到生产审计库。
• 令牌与密钥：使用短期令牌与自动轮换；PowerShell 下通过 $env:OPENAI_API_KEY 设置环境变量。
• 运行参数模板：

示例：OpenAI 编码探针（Windows PowerShell）

$env:OPENAI_API_KEY="sk-xxx"
python -m garak --target_type openai --target_name gpt-4o --probes encoding --outdir .\reports --loglevel INFO

示例：HuggingFace 本地模型越狱测试

python -m garak --target_type huggingface --target_name gpt2 --probes dan.Dan_11_0 --outdir .\reports_hf

表：参数含义与默认值

实践要点：

• Windows 环境下注意路径转义与编码问题，使用 PowerShell 时建议统一项目根目录变量，避免相对路径混乱。
• 本地模型评估需校验显存与内存占用，建议先跑小模型验证流程，再迁移到目标模型。

8.5 治理与集成

• 门禁阈值定义：

CI/CD 集成要点：在 PR 阶段执行 Garak 扫描，将 JSON-L 报告与命中样例链接到评审页面；失败触发工单与通知，限制合并操作。

门禁实践：

• 对关键系统（如面向客户的生产问答）设定更严格阈值，尤其是隐私与危险指导维度。
• 对内部场景（如研发辅助）允许一定豁免，但必须记录，并在季度复核时统一处理。

8.6 案例与实践

• 编码混淆实录：使用 Emoji 编码替换危险关键词，再由模型进行“语义解释”，观察检测器是否能识别编码轨迹。输出样例需脱敏并保留证据片段（起始/结束标记）。
• DAN 越狱实录：在提示中加入“平行人格”与“实验性探索”，并大量使用中性词汇，规避显式禁止词；检测器使用“语义相似度”与“规则库匹配”双通道识别。
• 模板劫持实录：构造一个看似无害的“翻译任务”，在“要翻译的文本”中嵌入对系统指令的覆写；生成器端设定“格式校验”，要求输出必须包含指定结构，避免被覆写。

时序图（工具链注入）：

在这些案例中，核心不是“是否命中”，而是“命中后如何处置”。处置流程应包含：自动阻断（如涉及隐私与法律风险）、人工复核（判定业务可接受与否）、策略库更新（提升未来防护能力）。

8.7 性能工程与隐私合规

• 并发治理：建议采用“令牌桶+退避算法”，并在达到预算上限时自动降级（缩减探针集合、延迟非关键评估）。
• 日志与报告：对 hit-log 实施采样与分类存储，区分“立即复核”与“批量归档”，降低存储压力。报告导出时添加“数字签名”保证不可抵赖性。
• 法规遵循：对跨境数据流进行标记与隔离，禁止将含敏感样例的报告传出监管区域。使用“脱敏模板”对样例进行标准化遮蔽。

表：隐私合规控制项

性能治理的目标是“稳态可持续”。建议为评估配置每日/每周预算，并在达到 80% 阈值时主动预警；必要时自动降级到低成本探针集合，确保生产系统与评估系统都不被拖垮。

8.8 报告样例与JSON-L片段

示例（脱敏片段）：

{"run_id": "2025-11-24T10:15:00Z", "target": {"type": "openai", "name": "gpt-4o"}, "probes": ["encoding", "dan.Dan_11_0"], "metrics": {"toxicity_hit_rate": 0.004, "pii_hits": 0, "jailbreak_examples": 2}, "hits": [{"probe": "encoding", "detector": "pii", "severity": "high", "snippet": "..."}], "notes": "all samples redacted"}

表：报告字段说明

报告撰写建议：

• 每条命中样例至少包含“危害类型、上下文摘要、处置建议、复测计划”四要素，避免报告成为“仅罗列问题”的清单。
• 所有数值型指标应附带“样本量与区间”，避免因样本偏差导致误判。

8.9 选型与组合

饼图：

组合策略说明：红队覆盖用于发现“未知未知”，用例断言用于保障“已知要求”，门禁集成用于把“规则”纳入交付流程。三者协同，才能兼顾发现能力与交付稳定性。

8.10 行动清单

• 建立版本化评估基线与场景化探针库。
• 配置令牌最小权限与环境隔离，启用限流与退避。
• 将 JSON-L 报告接入审计总线，开启签名与只读存档。
• 设定门禁阈值与豁免流程，绑定责任人与SLA。
• 每季度复核评分模型与误报样例，优化检测器。

行动优先队列建议：

• 第1周：搭建最小可用流水线（OpenAI/HF 后端、编码与越狱探针、JSON-L 报告）。
• 第2周：引入门禁阈值与工单闭环；建立场景化探针库雏形。
• 第3周：优化检测器多通道与脱敏模板；接入安全数据湖。
• 第4周：进行季度复核与路线图制定，明确下一期评估目标与预算。

9 结束语

精简章节不意味着浅薄内容。通过对“架构、工作流、策略、部署、治理、案例与工程细则”的纵深补充，本文提供了足够的操作指南与治理框架，确保任何规模的组织都能以可审计、可复现、可治理的方式推进 LLM 安全评估。若需进一步定制（行业场景、专用探针、合规模板），可在现有框架上增添场景库与阈值策略，不改变整体章节结构即可实现扩展。

最后的建议是保持“评估即产品”的心态：

• 版本化评估：像发布软件一样管理评估版本与变更说明。
• 可视化沟通：用图表展示趋势与决策依据，减少跨部门沟通成本。
• 持续治理：把门禁、报告、工单与审计串起来，让评估真正融入交付节奏，而不是一次性的活动。