用途：在 AI 产品开发中，输入与输出是模糊的，evals 相当于模型的“单元测试”，帮助团队从“凭感觉”开发转向指标驱动迭代，量化产品能力并判断何处需要人工介入。
主要能力（Eval 工作流）：一，识别“核心用例”：不从 MMLU 等通用基准入手，而是列出用户最常问或最高价值的 10–20 个查询，为每个查询定义“完美/黄金”答案，并包含预期模型会吃力的边界情况（复杂推理、特定格式）。二，设计“测验”：每条测试包含输入（具体提示或指令）、参考（黄金答案或标准，如“必须提到 X”“不得超过 200 字”）、评分机制（用更强的模型如 O1 或 GPT-4o 按标准给生产模型输出打分）。三，应用“爬山”流程：先在基线模型上跑评测；若分数低，提供 1000+ 条“问题→好答案”示例进行微调；再重测；若性能停滞，把问题拆成更小任务（集成）并为每个子任务建立专门评测。四，按准确率阈值决定 UX：60% 准确率做“副驾驶/草稿”体验，用户需大量编辑；95% 做“人在环”体验，模型执行、人工快速审核；99.5% 做“智能体/自动化”体验，模型自主行动。
示例：深度研究工具中，评测提示为“比较 2024 年聚变能源公司的竞争格局”，标准包括是否提到 Helion、是否引用来源、报告是否 15 页以上；若模型历史正确但漏掉近期新闻，则专门增加“时效性”评测并微调浏览工具。客服代理中，用 500 张历史工单及其已验证的正确解决方案做评测，若退款准确率 98%、技术调试仅 70%，则可自动处理退款、把技术问题转人工并提供建议草稿。
常见误区：使用静态评测（模型与用户行为每隔几个月会变，不更新测验则指标失去意义）；为当前模型过度搭脚手架（避免写复杂 if/then 代码修补当前错误，应面向下一代模型能力构建）；忽视“人类类比”（评测失败时问“我会怎么教人做这件事”，若人需要检查清单或同行评审，就把它加入模型的思维链）；靠“感觉”上线（不要因三个提示“感觉更好”就发布模型更新，只有聚合评测分数显示统计显著提升才发布）。
限制：资料未提供具体实现代码、评分模型 API 用法、微调数据格式或成本信息，暂未提供。