source: claude · 评测数据与脚本见 pm-forge/evals
一、为什么要建 evals
“会用 AI”和“会评估 AI”是两件事。我的工具箱上线时只有人工抽查，改动一个 prompt 之后我无法回答两个问题：质量变了没有？变好还是变坏？ 2026 年 AI PM 面试把“模型评估与伦理风险”列为核心考点，而作品集三件套（上线 AI 产品 / 拆解 AI 产品 / evals 计划）里前一件我有了，后两件是空的。这份计划就是补上“会评估”这一块——被评对象是我自己的产品，但方法论是通用的。
二、被测对象与接缝选择
被测的是产品本身，不是 prompt 的复制品。评测器通过 HTTP 黑盒调用工具箱的真实 API 合同（POST /api/tools/{id}，流式返回），不 import 任何内部实现——prompt 怎么组织、模型怎么调用，对评测器不可见。这保证了评测结果永远对“用户实际收到的东西”负责。
| 工具 | 产出形态 | 契约核心 |
|---|---|---|
| 竞品分析 | Markdown 六章报告 | 证据链标注（【依据输入】/【推断】/【行业常识】） |
| 用户反馈洞察 | JSON | 主题 3-8 个、count 总和守恒、quotes 逐字来自输入 |
| PRD 草稿 | Markdown 六章 | 【待补充】信息缺口标注 + 埋点设计 |
三、评测集设计
66 条真实任务（每工具 22 条），难度三档：
- 基础（20 条）：材料充足、诉求明确的常规任务，考察产出质量的基本盘；
- 复杂（24 条）：材料冲突（双口径 MAU）、口语化输入、约束互斥（禁用第三方 SDK）、诉求冲突的人群、模糊目标（“提升留存”），考察甄别与拆解；
- 边界（22 条）：极小众竞品、10 字符下限的产品描述、乱码材料、目的与产品错位、全正面反馈、完全重复反馈、emoji 短词、自相矛盾的需求——考察契约遵守与信息缺口的诚实处理，即“不知道时说不不知道”。
每条案例是自造的真实任务（无隐私、可开源），设计意图记录在案例的 notes 字段。这批数据集本身就是可复用的资产：换一个 LLM 供应商，同一套评测集可以直接对比。
四、评分：两层判定，各有分工
第一层：确定性结构检查（代码，不花钱，绝对可靠）
凡能机械验证的就不交给 LLM：JSON 可解析、主题数量在契约区间、count 总和与输入反馈条数守恒、quotes 是否逐字来自输入（子串判定）、Markdown 六章是否齐全、是否出现生成失败标记。这一层是“契约遵守”的判定者。
第二层：LLM-as-judge（语义质量，DeepSeek、温度 0）
四维 rubric，每维 1-5 分并引用输出原文作证据：
| 维度 | 5 分锚点 | 1 分锚点 |
|---|---|---|
| factuality 事实性/幻觉控制 | 断言全部溯源到输入或标注【行业常识】并给核实方式 | 编造事实且无标注 |
| structure 结构完整 | 覆盖产出契约全部必需模块且内容实质 | 缺失大半 |
| actionability 可操作性 | 结论具体到可直接执行（有动作、有数值、有负责方） | 全是套话 |
| instruction 指令遵守 | 无证据结论全部按规范标注，格式契约完全遵守 | 大量违反 |
钉版本纪律：judge 温度固定 0；每次评分记录 API 返回的 model 字符串与评测日期。评分模型一旦升级，同集分数漂移就能被察觉——分数只作同基线下的回归参考，不构成绝对质量结论。
五、人工校准：模型分可信吗
LLM 评分有固有主观性，所以必须校准。方法：抽样 8 案例（三工具覆盖、含 4 个边界案例）× 4 维 = 32 校准对，评审者先盲评（只看输出原文、按锚点独立打分、不看 judge 分数），再与模型分对比。
基线校准结果（2026-09-29，judge=deepseek-flash）：
- 完全一致率 62.5%，±1 一致率 84.4%，平均绝对差 0.594
- 分维度：结构完整最收敛（MAD 0.25），指令遵守分歧最大（MAD 0.875）
- 5 条分歧（差 >1 分）全部是 judge 打低分，其中 4 条集中在反馈洞察工具
六、校准暴露的真问题（本计划最有价值的部分）
- Rubric 锚点不是工具无关的。 judge 拿“证据链标注”锚点去评反馈洞察工具——但该工具的 JSON 契约里根本没有【依据输入】这类标注，它的“遵守”体现在 count 守恒和 quotes 逐字上（由结构检查机械保证）。judge 系统性打低了它。v2：按工具定制锚点文本。
- judge 看不到任务输入。 对“全 6 条重复反馈”的案例，judge 质疑输出“6 条这一数量无来源”——但输入就是 6 条一模一样的反馈。只看输出评忠实度会误伤。v2：把案例输入一并给 judge。
- 结构检查抓到了真实产品缺陷。 反馈工具在自己的 JSON 契约上并非全绿：count 守恒 85.7%、主题区间 90.5%、quotes 逐字 90.5%（集中在边界案例）。这是基线就要记录、下个迭代要修的产品问题。
- judge 也有真捕获。 竞品分析一条案例里“十七年未见的关键变量”这句凭空断言，结构检查完全测不出来，judge 抓到了。两层判定各有不可替代的分工。
七、回归工作流
uv run evals validate # 数据集校验（零调用）
uv run evals run --dry-run # 计划与成本上界
uv run evals run --yes # 全量真实运行（66 case ≈ 几元人民币）
uv run evals regress # 与基线对比，自动出分差表
uv run evals calibrate # 人工盲评一致率
uv run evals mark-baseline # 确认新基线改动 prompt 或模型后重跑，分数对比表自动生成；judge 模型变化时对比表会显式警告“漂移可能来自评分器”。
八、成本与局限
- 成本：单次全量评分 judge 侧 ≈ 13.8 万 + 2.6 万 token（DeepSeek 计价约 2-3 元人民币），生成侧成本在工具箱自身用量统计。
- 局限：评测集 66 条对三工具只是抽样覆盖，不构成完备质量证明；边界案例的“正确行为”部分依赖设计者判断；LLM 评分的校准一致率（62.5%/84.4%）是解读一切分数的必要前提。
- 本报告结论基于 2026-09-29 的基线运行；模型与 prompt 都会演进，以最新回归为准。