Giskard vs garak：知识库质量测试与安全扫描怎么选？

简短结论

知识库回答是否有依据、业务条件有没有遗漏，可以从 Giskard 的质量测试开始；想主动寻找 LLM 应用在恶意输入或特定探针下的失败，可以比较 garak。两项工作的测试材料与结果解释不同，适合分别维护检查线。

不要把它们理解成“只有一个做质量、只有一个做安全”。Giskard 的官方产品也包括漏洞扫描；garak 的探测范围也包含幻觉和错误信息。本文重点比较 Giskard 的知识库质量路径与 garak 的探针扫描路径，不做排他的能力判断，也没有共同性能实测。

核心差异速览

Giskard 更适合优先检查的失败

客服助手给出了看起来合理、却不符合当前政策的答复，是知识库质量测试的典型入口。可以从“金额应是多少”“这条政策适用于谁”“是否应转人工”等具体要求开始，将失败保存为固定回归。

官方 v3 质量评估以知识库作为依据生成动态情境，可能包含多轮交互。它能帮助扩展测试，但参考材料本身必须可信。如果两份政策互相冲突，或历史材料仍混在知识库里，首先要解决资料的版本和适用范围，否则评分也可能建立在错误依据上。

手写 Checks 更适合固定已知要求。例如，结构化回答必须携带某个来源标识、金额字段不得变化，或者材料不足时应进入人工审核状态。确定性断言能检查这些明确字段，却不能自动判断整段自由文本的所有含义。

garak 更适合优先检查的失败

garak 官方将其定位为 LLM 漏洞扫描器，利用探针探索幻觉、信息泄漏、提示注入、毒性等不期望的行为。它适合建立独立的安全回归流程，并根据目标系统、输入渠道与业务风险选择检查范围。

例如，问答助手会读取外部网页或用户上传文档，检索材料中可能出现试图改变助手行为的指令。安全测试要观察这些内容能否改变系统行为，而不是只问助手能否答对一条正常的价格问题。测试目标、账号和工具权限都应使用隔离配置，避免真实业务动作受到影响。

扫描结果仍然需要解释。检测器发现某种文本模式，不一定已经证明敏感数据实际泄漏；没有发现，也可能是探针覆盖不到、目标适配不完整或测试条件不同。要保存原始输入输出、配置和复现步骤，再决定风险级别与修复方式。

用一个客服场景说明为什么要分开验收

假设合成政策规定基础套餐为 99 元，退款资格需要审核，材料不足时不得承诺退款成功。质量检查可以围绕金额、条件和来源设计；安全检查则需要增加不可信指令、试图越权调用工具等独立案例。

如果助手回答了正确价格，却执行了来源文档中的恶意指令，事实题通过不能覆盖这个问题。如果助手拒绝了恶意输入，但引用了错误版本的政策，安全探测通过也不能覆盖这个问题。因此，报告应分别列出事实质量、业务规则和安全行为。

修复后也不要把所有失败简单汇总成一个数字。先将每个缺陷转为能够复现的回归用例，确认原失败能够被拦截；再测试修复是否破坏了正常请求。过度拒答也可能损害业务质量，需要与安全拦截一起检查。

成本、数据和执行方式

扫描工具的开源许可费与目标模型、评判模型和运行环境费用分开计算。探针数量、重复次数和多轮对话长度会影响实际请求量；生成测试和人工复核也需要时间。本文不提供未测量的费用节省比例。

真实系统中的失败输入可能包含内部提示、知识片段或用户内容。报告保存位置和访问权限应符合团队的日常要求。先用合成材料跑通流程，再决定如何处理真实案例；接入外部模型时重新确认数据流向，不能因为扫描命令在本机运行就认为所有内容都留在本地。

实际建议

只有少量已知的知识库错误时，先把它们固定成质量回归，不必立刻扩大扫描规模。业务开始读取不可信材料、开放更多工具或接入更多用户后，再结合实际风险增加漏洞探测。已经使用 garak 的团队，也应独立保留自己的业务事实题。

本次没有运行 Giskard 与 garak 的共同目标实验；配套 Giskard 3.0.1 已运行四个固定案例，得到一个通过、三个预期失败，没有执行真实模型扫描。本文依据官方定位给出接入建议，不声称任何扫描能完整证明系统安全。

相关内容：Giskard 工具资料、知识库问答测试工具推荐、Giskard 与 Inspect AI 对比和Giskard 回归教程。

官方资料

• Giskard 质量评估
• Giskard 官方文档
• garak 官方仓库与探测范围