不要上线后才补 LLM 评测：用 promptfoo 先定义失败边界

很多团队把 LLM eval 当成“上线以后再慢慢补”的事情。这个顺序通常会带来一个问题：等系统已经接入真实用户、真实工具和真实预算以后，再去讨论“什么算失败”，成本会高很多。

promptfoo 适合放在更早的位置：在 prompt、RAG、agent 或多模型方案进入生产之前，先把可重复的测试集、断言、模型对比和红队检查放到一个可执行的配置里。

Doramagic 对 promptfoo 的项目说明书把它概括为一个 LLM eval 和 testing toolkit。它不是简单跑几个 prompt 看输出，而是围绕配置、provider 调用、assertion grading、结果聚合和 CI 集成形成一个评测闭环。

项目说明书：

https://doramagic.ai/en/projects/promptfoo/manual/

项目页：

https://doramagic.ai/en/projects/promptfoo/

promptfoo 真正解决的不是“打分”，而是“发布边界”

很多 AI 应用的风险不是模型完全不会答，而是它在一些边界场景里表现不稳定：

• 同一个问题换个措辞后，答案格式漂移；
• RAG 检索到了内容，但回答没有引用关键事实；
• agent 调用了工具，却调用了不该用的工具；
• 多模型切换后，成本下降了，但错误类型发生变化；
• 红队提示能绕过原本以为有效的 guardrail。

如果这些问题只靠人工体验，很容易被“这次看起来还行”掩盖。promptfoo 的价值在于把这些体验变成可重复执行的测试。

在 Doramagic 的 manual 中，promptfoo 的核心评测引擎被拆成三个子系统：

1. 配置和 provider resolution：用 YAML/JSON 声明测试目标、模型和 provider。
2. 测试执行和并发：对 prompt、测试用例、provider 组合进行 fan-out 执行，并处理重试、缓存和超时。
3. 断言评分和结果报告：支持字符串匹配、schema 检查、LLM-as-judge、多模态评分等不同层级的判断。

这意味着它更像一个 AI 发布前的测试闸门，而不是一个临时 benchmark 脚本。

对 agent 项目尤其重要：工具调用必须可验收

agent 系统里最危险的失败，往往不是“没完成任务”，而是“完成任务的路径不可接受”。例如：

• 工具调用顺序不符合预期；
• 使用了越权工具；
• 关键步骤没有 trace；
• handoff 没有发生；
• 出错后没有 recovery path；
• 模型直接回答，绕过了必须查询的工具或知识源。

promptfoo 的 manual 提到，它有 MCP tool surface，可以让 agent 通过 MCP 工具触发评测，例如 list_evaluations、get_evaluation_details、run_evaluation、share_evaluation。更重要的是，工具元数据里包含 readOnlyHint、idempotentHint、longRunningHint 这类提示，能帮助 AI 宿主理解工具的行为边界。

这对于“让 AI 自己测试 AI”很关键。因为 eval 工具本身也需要边界：哪些工具只读，哪些会产生副作用，哪些可能长时间运行，都应该在调用前暴露出来。

红队不是最后一步，而是测试集的一部分

promptfoo 还有 red teaming 能力。Doramagic manual 中提到，redteam 层复用核心评测引擎，但增加了迭代攻击 provider：包括 on-topic checking、target invocation、vision-based judging、score comparison，以及在目标模型追问时自动生成回应的 unblocking 机制。

这说明 promptfoo 的红队不是单次“攻击演示”，而可以变成测试集的一部分。

一个实用做法是：

1. 先收集真实失败案例；
2. 把失败案例归类，比如 prompt injection、PII、越权工具调用、幻觉引用；
3. 把每类失败写成固定 test case；
4. 每次改 prompt、换模型、改检索策略、改工具权限时都跑一遍；
5. 如果通过率下降，就先停发布，而不是上线后观察用户反馈。

这就是“发布边界”的意义。

建议的第一次落地方式

不要一开始就试图覆盖所有风险。第一次引入 promptfoo，可以只做一个很小的闭环：

• 选择一个高频任务；
• 写 10 到 20 个真实输入；
• 为每个输入定义一个最小可验收标准；
• 同时跑当前模型和候选模型；
• 记录准确率、格式稳定性、延迟、成本和失败类型；
• 把最严重的失败转成回归测试。

如果是 RAG 项目，优先看 factual grounding 和 citation 是否稳定。

如果是 agent 项目，优先看工具调用、权限边界、trace 和 handoff。

如果是客服或内容生成项目，优先看格式一致性、禁答边界和敏感内容处理。

一个判断标准

当你准备上线一个 LLM 功能时，不要只问：模型这次答得好不好。

更应该问：

• 哪些输入必须失败？
• 哪些工具绝对不能调用？
• 哪些回答必须引用来源？
• 哪些指标下降就必须回滚？
• 这次改动和上一次相比，失败类型有没有变化？

promptfoo 的价值就在这里：它把这些问题变成配置、测试、报告和 CI 信号。

这类工具不会替你证明 AI 系统一定可靠，但它能让“不可靠”变得更早暴露、更容易复现，也更容易被团队讨论。对于真正要把 AI 功能带进生产环境的团队，这比单次 demo 更重要。