AI 测试工具开始变多了：它们到底在测试什么

AI 测试工具正在变多，但它们测的不是同一件事。Prompt 回归、RAG 质量、应用断言和模型红队分别需要不同样本与结论；把所有分数放进一个仪表盘，会制造虚假的统一质量。

四个项目的证据地图

| 项目 | 技术栈与重点 | release/tests/docs/demo | 许可 | | --- | --- | --- | --- | | promptfoo | TypeScript，prompt/model 对照、断言与红队能力 | Releases、tests、Docs、配置示例 | MIT | | DeepEval | Python，LLM 应用单元测试与评估指标 | Releases、tests、Docs、示例 | Apache-2.0 | | Ragas | Python，RAG/Agent 数据集、指标与实验 | Releases、tests、Docs、examples | Apache-2.0 | | garak | Python，模型/接口探测与红队 probes | Releases、tests、Docs、命令示例 | Apache-2.0 |

表格按 2026-07-15 的公开仓库整理。材料存在不代表本站已运行全部测试，也不保证许可证覆盖外部模型、数据或报告内容。

Prompt 回归能证明什么

promptfoo 适合固定输入、候选 prompt/model 和断言，比较版本是否破坏既有行为。它能发现回归，不能证明样本集之外的总体正确，也不能替代真实用户分布。

应用级断言能证明什么

DeepEval 更接近把 LLM 评估放进 Python 测试流程。它能让指标、阈值和 CI 关联，但模型裁判本身也有偏差；关键样本仍需人工规则或双重检查。

RAG 指标能证明什么

Ragas 把问题、检索上下文、回答和参考信息组织起来，适合比较检索/生成版本。高分不能证明权限正确、文档最新或引用符合业务要求，那些要用专门用例验证。

以客服 RAG 发布为例，团队准备 30 条来自历史工单的问题，其中 10 条要求准确引用，5 条属于越权资料，5 条没有可回答文档。promptfoo 可以固定版本回归与规则断言，Ragas 可比较检索和回答，DeepEval 可进入 Python 测试，garak 只负责另一个安全探索层。四类结果不能平均成“总分 87”。

真正的发布判断要逐项做：引用类问题必须指向当前版本，越权问题必须在检索前被挡住，无答案问题必须诚实拒答。模型裁判可以帮助筛查，但这三类高风险样本要保留确定性字段和人工复核。工具若无法表示业务期望，就先改测试资产，不要为了接入框架降低验收标准。

红队探测能证明什么

garak 的 probes 可以系统寻找已知类型弱点。发现失败说明风险存在；扫描未发现问题，只能说明本次配置和探测集合没有命中，不能写成“系统安全”。

一句话解读：测试工具缩小未知范围，不会把开放世界问题变成一次性合格证。

最小试用步骤：只组合能解释的测试

先用 20–30 条真实样本做 prompt 回归；有 RAG 时补上下文与引用字段；把少量关键规则放入 CI；上线前选择与场景相关的红队 probes。每层输出独立结论，不平均成一个总分。

第一次可执行试用只选一种最担心的失败：例如用 promptfoo 固定十条回归输入，或用 Ragas 比较两个检索版本。保存配置、模型、数据和人工复核分歧；未能解释结果时不继续叠加第二种工具。

上手成本与停止点

每个工具先给 60–90 分钟阅读 docs 和运行自带最小示例；没有真实数据时停止在资料阶段，不为了展示框架而造“完美样本”。工具数量增加后，首要成本会从代码转向数据维护与结果解释。

常见失败：指标名称相同，就以为结果可比

“相关性”“正确性”“安全”在不同工具、模型裁判和配置中不是同一量。把 Ragas 的某个指标、DeepEval 的断言和人工评分直接画在一张趋势图上，会让变化看起来精确，却没有共同测量口径。另一个失败是每次测试都让裁判模型和被测模型同时升级，结果无法解释来自应用还是评估器。

每个指标都要保存实现、版本、提示、阈值理由和一个已知误判。升级评估器时先重跑固定样本并人工复核分歧；不能解释的分数不进入发布门禁。

替代方案与投入判断

规则明确的输出先用 JSON Schema、普通单元测试和确定性检查，不需要 LLM 评估器；样本很少时，双人盲评表可能比接入平台更可信；已有安全团队的攻击用例也不必为了使用 garak 全部改写。工具应承接现有质量问题，而不是取代问题定义。

promptfoo 适合配置驱动的多 Prompt/模型回归，DeepEval 适合 Python 测试流程，Ragas 适合围绕 RAG 数据集做实验，garak 适合扩大漏洞探测面。只有团队能维护真实样本、解释结果并处理失败时，才值得持续投入；否则先维护十条高风险用例，价值高于安装四套工具。

文档与实测的分界

Release、测试目录和 demo 只能支持“项目公开维护这些能力”的陈述。指标是否稳定、CI 是否可接受、红队覆盖是否足够，都必须在目标模型、版本和数据上运行后再写。

结论

先问你害怕哪种失败，再选工具：版本回归、检索偏差、业务规则破坏或安全弱点。没有明确失败类型时，安装更多评估框架只会增加不可解释的分数。

建立测试资产清单

为每条样本记录来源、风险类别、期望、人工分歧、最近复核日期和适用版本；为每个指标记录阈值理由和误判案例。promptfoo 配置、DeepEval 测试、Ragas 数据集和 garak 报告应能追到同一个业务风险，而不是各自保存一套无法比较的示例。

结果发布边界

不要写“通过红队”或“RAG 准确率达标”而不说明模型、数据、配置和覆盖范围。模型更新、提示变化、检索数据变化都可能使旧结果失效。对外报告只发布可复核结论，敏感探测样本和系统漏洞按安全流程限制访问。

测试资产还需要淘汰机制。真实问题会过期，旧文档答案会变化，某些攻击样本也可能因产品功能下线而失去意义。每条样本应有负责人和复核日期；删除样本时保留原因，不让“通过率提高”来自悄悄移除困难问题。指标阈值变化也要走代码审查，避免上线压力把门槛临时调低。

对于模型裁判，至少保存一组人工已定级的锚点样本。更换裁判模型或提示后先比较这些锚点，分歧过大就暂停趋势对比。测试工具的价值是让质量讨论可重复，不是用小数点替代人工责任。

每次发布只引用本次真正运行的测试，不沿用旧报告里的结论。输入、模型或知识库任一变化，都应标记旧结果的适用边界。