

现在很多团队已经把 AI 能力嵌进测试或业务流程:需求转测试点、缺陷摘要、风险分级、客服回复、SQL 解释、日志归因。问题是,这些功能不是传统接口返回固定 JSON,不能只靠 status=200 判断通过。
Pydantic Evals 适合解决这个问题。官方文档把它定义为一个用于系统化测试和评估 AI 系统的框架,从简单 LLM 调用到复杂多 Agent 应用都可以覆盖。它是 code-first 的:用 Python 定义 case、dataset、evaluator,并可以把结果输出到终端、磁盘或 Logfire。
适合的 QA 工作类型:AI 功能验收、prompt 回归、缺陷摘要质量检查、AI Agent 输出门禁。
AI 直接参与的测试动作:LLM-as-a-Judge 根据 rubric 对另一个 AI 输出打分或给出 pass/fail,同时结合确定性 evaluator 做硬规则校验。

假设系统新增了一个“把失败日志总结成缺陷摘要”的功能。研发说模型已经接好了,页面也能返回摘要。但 QA 真正要看的是:摘要有没有关键错误码、有没有复现步骤、有没有乱编根因、有没有遗漏影响范围。
原始做法通常是:
这套方法最大的问题是没有可复跑标准。Pydantic Evals 更适合把它拆成 case 和 evaluator。

官方 quickstart 里,Pydantic Evals 支持创建 type-safe 的 structured inputs 和 expected outputs,能用 deterministic checks、LLM judges 或 custom evaluators 打分,还能比较不同运行结果。
安装非常直接:
pip install pydantic-evals
先不要接复杂平台。准备 5 条历史失败日志:
每条 case 写清:输入日志、期望包含的信息、禁止出现的臆测结论、可接受的摘要格式。
然后设置两类 evaluator:

第一,少凭感觉验收 AI 输出。
Pydantic Evals 把输入、期望、评估逻辑写进代码。以后 prompt 改了、模型换了、上下文变了,都能跑同一批 case。
第二,少写重复检查逻辑。
有些检查不需要 LLM Judge,例如字段是否存在、输出是否是 JSON、是否包含错误码。这些应该用 deterministic evaluator,便宜且稳定。
第三,少遗漏主观质量问题。
缺陷摘要、风险分级、客服回复这类输出有语义质量。官方文章里解释了 LLM-as-a-Judge 的模式:给 judge 一个 rubric,让它对另一个 LLM 的输出返回 verdict、score 或 label。
第四,少把一次失败忘掉。
每次线上或测试环境发现 AI 输出问题,都应该变成新 case。这样 AI 功能的质量会随历史问题积累,而不是每次靠 QA 记忆。
第一,rubric 是否贴近业务。
“回答清晰”太泛,应该写成“必须指出失败接口、触发条件、实际错误、建议排查方向;不能臆测未在日志中出现的根因”。
第二,judge 是否稳定。
LLM Judge 会有波动。高风险输出要抽样复核,必要时用多个 evaluator 交叉判断。
第三,硬规则和软评分要分开。
JSON 格式、字段存在、敏感词、禁止泄露信息,这些是硬规则。语义质量、可读性、下一步建议,这些再交给 LLM Judge。

适合:缺陷摘要、日志归因、需求转测试点、客服回复、AI 生成测试用例、Agent 工具调用结果总结。
不适合:没有固定业务口径的开放生成;无法定义最低通过标准的创意文本;必须 100% 确定性的传统接口断言。
Pydantic Evals 的价值不是“帮你写一个万能评测平台”,而是让 QA 把 AI 功能验收写成小而可运行的 case 集。
先拿 5 条历史失败日志做最小验证:输入固定、输出可审、规则清楚、失败可复现。做到这一点,AI 功能测试才会从人工感觉变成可维护回归。