# Garak 中可扩展插件系统的设计：链式 LLM 漏洞检测器与动态风险评分 > Garak的插件架构支持模块化扩展，实现LLM漏洞检测的链式处理和动态风险评估，提供红队工作流的工程化实现。 ## 元数据 - 路径: /posts/2025/09/14/designing-extensible-plugin-system-in-garak-for-chaining-llm-vulnerability-detectors/ - 发布时间: 2025-09-14T20:46:50+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 站点: https://blog.hotdry.top ## 正文 Garak 是一个开源的 LLM 漏洞扫描工具，由 NVIDIA 开发，专注于通过静态、动态和自适应探针来测试大型语言模型的安全性。其核心在于一个高度模块化的插件系统，这个系统允许开发者轻松扩展功能，实现漏洞检测器的链式组合、动态风险评分以及灵活的红队测试工作流。这种设计不仅提升了工具的灵活性，还确保了在复杂 AI 系统中的可维护性和可扩展性。 Garak 的插件架构主要围绕五个关键类别构建：probes（探针）、detectors（检测器）、generators（生成器）、harnesses（测试框架）和 evaluators（评估器）。每个类别都通过 base.py 文件定义了基类，插件开发者只需继承这些基类即可实现自定义功能。例如，probes 负责生成与 LLM 的交互提示，如 prompt injection 或 DAN 攻击模拟；detectors 则分析生成输出，识别特定失败模式，如毒性内容或数据泄露。Generators 处理不同 LLM 接口的集成，支持 Hugging Face、OpenAI 等多种后端。Harnesses 协调整个测试流程，而 evaluators 负责结果报告。这种模块化结构使得系统易于扩展，用户可以根据需求添加新插件，而无需修改核心代码。 在链式 LLM 漏洞检测方面，Garak 的设计特别注重组件间的无缝集成。以 probewise harness 为例，它会为每个 probe 实例化 recommended_detectors，从而形成一个自然的链式流程：probe 生成提示，generator 调用 LLM 产生输出，detector 逐一评估输出是否触发漏洞。这种链式机制支持动态组合，例如将 promptinject probe 与 toxicity detector 链式使用，先注入恶意提示，再检测输出中的有害内容。证据显示，这种设计已在 garak 的默认运行模式中实现，用户只需通过命令行指定 probe 和 detector 即可激活链式测试，而无需手动编码连接逻辑。这种方法比传统的单体测试框架更具优势，因为它允许在运行时动态调整链条长度和顺序，适应不同风险场景。 动态风险评分是 garak 插件系统的另一亮点。Detectors 不只是二元判断（通过/失败），而是计算失败率，例如在多次生成中统计有害输出的比例（如 840/840 表示全失败）。这个评分可以进一步通过 evaluators 聚合，形成整体风险指标，支持阈值-based 的警报机制。在红队测试工作流中，这种动态评分允许实时调整策略：如果初始链式检测显示高风险分数，系统可自动插入额外 probe（如 encoding-based injection）来深化测试。实际工程中，这种机制的落地参数包括设置生成次数（默认 10 次，以平衡准确性和效率）和失败阈值（例如 >20% 触发高风险警报）。此外，日志系统会记录每个链式步骤的评分细节，便于事后分析和优化。 要实现模块化的红队工作流，开发者需要关注插件的互操作性。Garak 支持通过 YAML 配置自定义 REST endpoints 或 NIM 模型集成，确保链式检测适用于云端或本地部署。举例来说，一个典型的红队工作流可以是：使用 dan probe 模拟越狱攻击，链式连接 lmrc detector 检查偏见输出，再由 snowball probe 测试幻觉放大，最后通过 evaluators 生成 JSONL 报告。这种工作流的 modular 特性允许并行运行多个链条，优化资源利用。风险管理方面，需要注意链式深度不超过 5 层，以避免计算开销过大；同时，实施回滚策略，如在 detector 失败时 fallback 到简单 probe。 扩展 garak 插件系统的工程化参数和清单如下，提供可落地指导： 1. **插件开发基础**：选择合适的基类，例如继承 garak.probes.base.TextProbe 用于自定义提示生成。最小化覆盖，只重写 generate() 方法，确保兼容性。 2. **链式配置参数**： - probe_count: 限制链中 probe 数量（推荐 3-5）。 - detector_threshold: 风险分数阈值（0.1-0.5，根据模型敏感度调整）。 - generation_retries: 每个步骤的重试次数（默认 3，避免网络波动影响评分）。 3. **动态风险评分实现**： - 使用 detector 的 score() 方法返回浮点值（0-1），聚合时加权平均（权重基于 probe 严重度，例如 jailbreak probe 权重 1.5）。 - 监控点：集成 Prometheus 指标，跟踪链式延迟（目标 <5s/步骤）和失败率波动。 4. **模块化红队工作流清单**： - Step 1: 定义 YAML 配置，指定 generator（如 openai with API key）和初始 probe。 - Step 2: 构建链式 harness，自定义 probewise 子类支持条件分支（if score >0.3 then add probe）。 - Step 3: 测试集成，使用 test.Blank generator 验证插件无误。 - Step 4: 部署监控，回滚策略：如果整体风险 >0.8，暂停工作流并通知管理员。 - Step 5: 文档化插件，提交 PR 到 garak 仓库，确保社区贡献。 在实际应用中，这种插件系统已证明其价值，例如在测试 GPT-3.5-turbo 时，链式 encoding probe 和 promptinject detector 揭示了模型对编码注入的脆弱性，失败率高达 80%。引用 garak 文档：“每个插件模块定义继承自基类的插件类，例如 garak.generators.openai.OpenAIGenerator 继承自 garak.generators.base.Generator。”这种基础工程设计确保了系统的长期演进。 总之，Garak 的可扩展插件系统为 LLM 安全测试提供了坚实基础。通过链式检测器和动态风险评分，开发者可以构建高效的红队工作流，参数化实现从概念到生产的平滑过渡。未来，随着更多插件的涌现，这一架构将进一步强化 AI 系统的鲁棒性。（字数：1028） ## 同分类近期文章 ### [NVIDIA PersonaPlex 双重条件提示工程与全双工架构解析](/posts/2026/04/09/nvidia-personaplex-dual-conditioning-architecture/) - 日期: 2026-04-09T03:04:25+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析 NVIDIA PersonaPlex 的双流架构设计、文本提示与语音提示的双重条件机制，以及如何在单模型中实现实时全双工对话与角色切换。 ### [ai-hedge-fund：多代理AI对冲基金的架构设计与信号聚合机制](/posts/2026/04/09/multi-agent-ai-hedge-fund-architecture/) - 日期: 2026-04-09T01:49:57+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析GitHub Trending项目ai-hedge-fund的多代理架构，探讨19个专业角色分工、信号生成管线与风控自动化的工程实现。 ### [tui-use 框架：让 AI Agent 自动化控制终端交互程序](/posts/2026/04/09/tui-use-ai-agent-terminal-automation/) - 日期: 2026-04-09T01:26:00+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 详解 tui-use 框架如何通过 PTY 与 xterm headless 实现 AI agents 对 REPL、数据库 CLI、交互式安装向导等终端程序的自动化控制与集成参数。 ### [tui-use 框架：让 AI Agent 自动化控制终端交互程序](/posts/2026/04/09/tui-use-ai-agent-terminal-automation-framework/) - 日期: 2026-04-09T01:26:00+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 详解 tui-use 框架如何通过 PTY 与 xterm headless 实现 AI agents 对 REPL、数据库 CLI、交互式安装向导等终端程序的自动化控制与集成参数。 ### [LiteRT-LM C++ 推理运行时：边缘设备的量化、算子融合与内存管理实践](/posts/2026/04/08/litert-lm-cpp-inference-runtime-quantization-fusion-memory/) - 日期: 2026-04-08T21:52:31+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析 LiteRT-LM 在边缘设备上的 C++ 推理运行时，聚焦量化策略配置、算子融合模式与内存管理的工程化实践参数。