LLM 评测实战：如何在用户之前测试 AI 功能
AI 功能第一次让团队尴尬时，通常不像一次 benchmark 失败。它更像是客服机器人自信地套错退款政策，代码助手修改了明明不该碰的文件，或者销售 copilot 因为 CRM 字段为空就编造了客户细节。演示没问题，提示词评审没问题，模型介绍也很亮眼，但真实用户找到了你从未测试过的输入。
这正是 LLM 评测存在的意义。它不是刷榜，也不是把每个新模型填进绿色表格的表演。实用的 LLM 评测是产品团队的早期预警系统：把混乱的用户期望转化为可重复测试、回归门禁和复审闭环。
为什么 LLM 评测不同于普通 QA
传统 QA 通常检查已知输入是否返回预期输出。LLM 产品更难，因为正确答案可能是一组可接受行为。客服助手可以用十种好方式回答同一问题，代码审查助手可能抓住严重 bug 却忽略风格问题，研究 Agent 在缺少上下文时主动停止并追问反而是好行为。
这不意味着评测可以含糊。相反，评分标准必须匹配产品风险。摘要工具可以评事实一致性、完整性、语气和拒答行为；能调用工具的 Agent 还要评任务成功率、工具选择、权限安全、恢复行为，以及该停下时是否停下。我们在 AI Agent 更需要可靠性 中也强调过：产品不只是模型输出，还包括围绕输出的控制系统。
先构建黄金数据集，再调提示词
黄金数据集是一组经过筛选的真实或高度仿真的输入，包含期望行为、评分说明和元数据。一开始不必很大，50 到 200 条就足以覆盖常见用户任务、高成本失败模式和一些刻意设计的边界情况。
客服 copilot 应包含普通请求、愤怒消息、多语言工单、信息不完整、政策冲突，以及正确答案是升级人工的案例。开发者工具应包含小 bug 修复、模糊重构、失败测试、权限边界，以及助手应该先询问再编辑的场景。每一行不只写输入和理想答案，还要记录用户类型、任务类型、风险等级、所需来源、允许动作和通过理由。
Hamel Husain 关于 LLM evals 的实践文章 的价值就在于，它提醒团队围绕产品真实案例和人类判断构建评测，而不是崇拜抽象 benchmark。收集真正影响产品的案例，然后让它们可重复运行。
像产品实验一样比较提示词和模型
提示词和模型比较不应是主观品鉴，而应像受控实验。尽量一次只改一个变量，用同一黄金数据集跑生产提示词、候选提示词和候选模型。不要只看总分，还要按任务类型、语言、风险等级和用户群体切片。
ChainForge 适合在大量输入上比较 prompt 和模型输出；Vellum 提供 prompt 管理、评测和部署相关工作流；Confident AI 的 DeepEval 则提供面向 LLM 应用的开源测试框架。工具选择重要，但更重要的是纪律：每次评测都记录提示词版本、模型名、检索设置、工具 schema 版本、温度和系统指令。
这对多模型工作流尤其重要。我们在 用 LLM 写软件的实践流程 中讨论过，不同模型适合不同角色；但如果没有稳定评测，团队很难知道一次改动到底提升了哪里、损害了哪里。
把回归门禁接入 CI/CD
有了黄金数据集后，把一个较小的 smoke 集合接入 CI/CD。不要一开始就跑完整评测。先覆盖绝不能回归的失败：危险政策建议、破坏 JSON、禁止工具调用、严重幻觉，以及必须升级人工的案例。
任何修改提示词、模型配置、检索管线、工具 schema 或 Agent 路由逻辑的 PR，都应该运行这些 smoke evals。高风险用例失败时应阻止合并；低风险分数波动可以先作为警告。
自动化不必一次到位。先做确定性检查：schema 是否有效、是否给出必要引用、是否触发禁止动作、是否在不允许请求上拒答、简单任务是否选择正确工具。再加入 LLM-as-judge 或 rubric 评分，处理有主观性的有用性、语气和完整性。自动评审应被视为有噪声的 reviewer，而不是绝对真理。
对 Agent 系统，可以借鉴 MCP 生产集成模式 和 Operator 风格网页自动化架构：记录工具调用、分类错误、版本化 schema，并测试失败路径。
人工复审把失败变成更好的测试
评测集不会自动保持优秀。用户行为会变，政策会变，模型会变，产品界面也会变。有效的机制是定期复审抽样输出、用户差评、升级工单和险些出事的案例，并把最有代表性的失败提升为新的黄金数据。
复审标签不要只有“好”和“坏”。记录失败类型：上下文缺失、工具错误、无依据声明、语气不当、不安全动作、来源过期、过度拒答、拒答不足或 UX 误导。PM、客服、销售、法务或领域专家都应参与高风险场景，因为他们往往比工程师更清楚用户是否真的会满意。
如果团队已经有 Agent 运营看板，可以把评测失败接进去。我们的 Agent 运营漏斗设计 提供了类似思路：衡量任务在哪里进入、在哪里卡住、哪里需要人工介入，以及哪里损害用户信任。
何时需要游戏世界和开放式评测
多数产品团队应从黄金数据集和回归门禁开始。开放式环境更重，只有当 AI 功能需要长程规划、从意外状态恢复，或在模拟世界中交互时才更有价值。Factorio Learning Environment 是一个代表性方向：它用 Factorio 游戏环境衡量 Agent 的规划、资源获取、建造和适应能力。
这类评测不适合 FAQ 机器人，却可能适合浏览器 Agent、编码 Agent、运维 copilot 或需要连续调用多种工具的系统。代价是成本更高、调试更难，也更容易对玩具世界过拟合。只有当生产风险本身就是长程行为时，才值得投入。
一套实用 LLM 评测流程
从风险承诺开始：功能绝不能做什么？必须做什么？哪里必须升级人工？然后构建 50 到 200 条黄金数据，跑当前基线，比较候选提示词和模型，把最关键用例放入 CI/CD，定期复审生产输出，并在确有长程规划风险时加入开放式仿真。
这不会让 AI 功能完美，但会让取舍在用户发现前先暴露出来。最好的 eval 系统不是学术奖杯，而是面向不确定性的产品仪表盘。真正能把 LLM 用好的团队，不是测试最多样例的团队，而是知道哪些失败最重要、能尽早抓住回归、并在需要判断和责任时让人类留在闭环中的团队。