AI产品PRD：评估集设计三件套——考卷、考纲与分数线

可视化演示

动态演示AI产品PRD的核心机制，通过全局/局部/动态/静态四种模式展示关键概念与交互流程。

评估集基础

每个学期末，老师都会拿出一套精心准备的期末考卷。考卷不是随便出的——它的作用是区分出哪些学生真正掌握了知识，哪些只是混日子。如果全班都考 95 分以上，这张考卷就是失败的，因为它没有“辨识度”。AI 产品里的评估集（Evals），就是这套期末考卷。

在 PRD 撰写阶段，你就要明确：评估集是预先定义好的一批测试用例，每个用例包含用户输入、期望输出和判定规则。模型这位“学生”学得怎么样，不看它自称学会了，而是看它在考卷上能拿多少分。评估集的质量标准由此而来：可执行、可判定、有区分度——就像好考卷不能出有争议的题，每道题必须有唯一标准答案。

进一步看，模型从开发到上线需要三套“卷子”：训练集（平时作业，模型照着学）、开发集（模拟考，调参时用）、评估集（期末考，最终验收）。三者严格分离，各司其职。评估集的通过率，是 PRD 中约定的核心验收指标。

有了这张“期末考卷”，你才能在 PRD 里和技术团队约定：模型达到多少分才允许上线。而没有评估集的 AI 产品，就像不考试就直接发毕业证——风险全留到了线上。

PRD文档规范

考卷出好了，还要配一份“考试说明”：考试范围是什么、每道题多少分、评分标准怎么定。学生只有看清说明，才知道怎么复习。同样，PRD 里的评估集章节，必须有一份规范化的用例表，让开发和测试同学一眼就懂。

规范的评估集用例表通常包含这些字段：用例编号（唯一标识）、场景名称（如“订单查询”）、用户输入（原始问法）、期望输出（模型应给出的回答或动作）、判定方式（精确匹配、关键词匹配或人工判定）、优先级（P0/P1/P2）。这个格式必须固定下来，就像考卷的题号、分值、答题区一样标准。

评审标准也要写清楚：每个用例必须可执行、可判定、无歧义。如果一条用例写成“用户问问题，模型要回答得好”，开发同学根本没法实现——“好”的标准是什么？要写成“用户问‘订单到哪了’，模型必须返回物流查询结果并给出订单状态”这种可验证的描述。

考试说明写得越清楚，学生越知道怎么答题；PRD 里评估集写得越规范，团队越知道怎么实现。规范不是形式主义，而是让“考卷”能被所有人以同一标准批改的前提。

覆盖度设计

出考卷最怕什么？怕只考一个单元。如果老师只出第一章的题，学生把第一章背熟就能拿高分，但后面几章一窍不通——这样的考试毫无意义。评估集的覆盖度设计，就是要确保考卷覆盖所有关键“知识点”，也就是重要业务场景。

场景枚举要分成三类：正常场景（用户最常见的提问方式）、边界场景（订单金额为零、库存只剩一件等极端情况）、异常场景（用户输入乱码、提问超出业务范围等）。覆盖度不是平均用力，而是按优先级取舍——P0 核心场景必须全覆盖，P1 次要场景尽量覆盖，P2 低频场景量力而行。

样本分布同样关键。评估集中的用例比例要尽量贴近线上真实流量分布——如果线上 70% 是订单查询，评估集里订单查询也最好占 70% 左右。否则就可能出现“考卷全是难题，学生被考懵”或“考卷全是送分题，成绩虚高”两种失真。

覆盖率是评估集的“广度”指标，但它只是基础——就像考卷覆盖了所有章节，也不能保证没有“泄题”。接下来要防的，就是最隐蔽的坑：数据泄漏。

数据泄漏防范

如果期末考试前，有同学偷偷拿到了标准答案，考试分数还能反映真实水平吗？当然不能。模型训练中也有这种“泄题”事故，叫数据泄漏——评估集里混入了训练时见过的数据，模型“背答案”就能拿高分，上线后面对新问题立刻原形毕露。

防范泄漏有三道防线。第一道是集间隔离：训练集、开发集、评估集必须从不同的数据源或时间段抽取，且评估集样本绝不能参与训练，就像考卷在考试前绝不能流到学生手里。第二道是时间切分：对于容易过时的数据（如新闻、电商商品、热点话题），按时间先后划分——用 1-8 月的数据训练，用 9-10 月的数据评估，模拟“考未来的题”。第三道是相似去重：把评估用例和训练语料做文本相似度比对，重复度高的用例要剔除或改写，防止“刷题刷到原题”。

即使做了三道防线，仍要监控一个关键信号——泛化差距。模型在训练集上的表现和评估集上的表现差得越多，越要警惕泄漏或过拟合。

泄题的考卷，分数再高也骗不了人；泄漏的评估集，通过率再高也骗不了线上用户。防住泄漏只是让“考试公平”，但公平的考试就一定能预测工作表现吗？答案是未必——这就是下一步要解决的线上指标对齐。

线上对齐策略

小李在公司面试时笔试拿了 95 分，可入职后连最基础的报表都做不好。为什么？因为笔试考的是“背书能力”，而工作要的是“解决问题能力”——两者没有对齐。评估集与线上指标的对齐，就是要回答一个核心问题：评估集的高分，是否能带来线上业务指标的高绩效？

对齐的第一步是指标映射。你需要搞清楚评估集里的“答对”对应线上的什么业务价值。例如智能客服的评估集考核“是否正确识别用户意图”，线上指标则要看“问题解决率”或“用户满意度”。你要把评估集的通过率和线上指标建立对应关系，而不是各看各的。第二步是阈值设定：在 PRD 中明确规定评估集必须达到多少分才能上线（例如通过率 ≥ 90%），以及这个分数对应的线上指标预期值（例如问题解决率 ≥ 80%）。

模型上线不代表万事大吉。业务场景会随时间漂移——双十一的咨询高峰、新产品的上线、用户语言习惯的变化，都会让“考卷”渐渐过时。所以要建立漂移监控：定期把线上真实用户的输入加入评估集回测，比对评估集得分与线上指标是否仍然同步变化。如果评估集得分稳定但线上指标下滑，说明考卷和实际工作已经脱节，该升级考卷了。

对齐的考卷才能选出真正的人才。但对齐不只是一堆数字——当模型考砸了，你作为产品经理，必须能说清楚它为什么没考好，这正是可解释性设计要解决的问题。

可解释性设计

老师批改试卷时，不能只在错题上画个红叉就完事。负责任的老师会写下评语：“这道题你混淆了概念”“这一步计算粗心了”。这样学生才知道怎么改进。AI 模型评估中同样需要这种“评语”——这就是可解释性需求设计。

可解释性至少包含三个层面。第一是失败归因：每个未通过的用例，必须能定性分析失败原因——是“用户输入不在业务范围内”（覆盖问题）、“模型理解错意图”（能力问题）、还是“期望输出标注本身有误”（标注问题）。第二是示例标注：在 PRD 或评估报告中，对高频失败类型附上典型的正例和反例，让技术团队能直观理解——“看，这类问法应该归入退货咨询而不是退款流程”。第三是人工复核：对于模糊或低置信度的判定结果，设计人工抽检机制，确保评估结果的可靠性。

在 PRD 中，你要明确提出可解释性的量化需求，让“说得清”从口号变成可考核的指标：

有了评语，学生才知道下一步怎么复习；有了归因，算法团队才知道下一步怎么优化。可解释性让评估集从“一堆红叉”变成“一本错题集”——而错题集最典型的应用场景，就是对话式 AI 产品的多轮对话评估。

对话流设计

面试时，面试官不仅会问“你会什么”，还会通过追问、情景题来考察你的临场反应。对话式 AI 产品的评估也是这样——它不能只看单轮问答对不对，还要看多轮对话能不能捋顺。这就是 PRD 中对话流设计的核心。

多轮对话的评估要覆盖三类路径。主路径：用户一步步按预期流程走，如“查订单→确认订单号→获取物流信息”，每一步机器人都要接得住。分支路径：用户中途打断、改主意、补充信息，如“算了，先不管物流，我要退货”——模型要能优雅切换话题。失败路径：用户连说三遍都答非所问，或直接表达不满“你什么毛病？换个客服来”——这时必须触发兜底策略：转人工、道歉安抚或提供替代方案。合规审查也在这里登场：对话内容不得涉及隐私套取、敏感话题或诱导性表达，就像面试官不能问求职者婚育情况一样。

对话流评估的结果，同样需要一个可量化的指标来度量：

从出考卷到设考纲，从防泄题到对业绩，从写评语到面试流程——你现在已经掌握了老师出题的全套智慧。这正是 AI 产品经理在 PRD 阶段就为产品质量打下的根基。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""评估集与线上指标对齐度分析演示""" def build_evals():    """构建评估集: (场景, 用户输入, 期望输出, 模型实际输出, 是否通过)"""    return [        ("订单查询", "我的订单到哪了", "查询物流", "查询物流", True),        ("退货咨询", "怎么退货", "退货流程", "退款流程", False),        ("改地址", "帮我改收货地址", "修改地址", "修改地址", True),        ("催发货", "什么时候发货", "催发货", "物流查询", False),        ("投诉", "我要投诉快递", "转人工", "转人工", True),        ("开发票", "能开发票吗", "发票申请", "发票申请", True),        ("查运费", "运费多少", "运费说明", "订单查询", False),        ("取消订单", "我不想要了", "取消订单", "取消订单", True),    ] def calc_pass_rate(evals):    """计算评估集通过率"""    passed = sum(1 for _, _, _, _, ok in evals if ok)    return passed / len(evals) def calc_alignment(eval_rate, online_rate):    """计算对齐偏差: |评估通过率 - 线上指标| / 线上指标"""    return abs(eval_rate - online_rate) / online_rate def main():    evals = build_evals()    eval_rate = calc_pass_rate(evals)    online_rate = 0.80  # 线上问题解决率, 来自业务报表    gap = calc_alignment(eval_rate, online_rate)    level = "对齐" if gap <= 0.15 else "需排查"    print(f"评估集用例数: {len(evals)}")    print(f"评估集通过率: {eval_rate:.1%}")    print(f"线上指标: {online_rate:.1%}")    print(f"对齐偏差: {gap:.1%}")    print(f"结论: {level}") if __name__ == "__main__":    main()

1. def build_evals():定义评估集数据，每行是一条用例，含场景、输入、期望输出、实际输出和通过标记，对应 PRD 中的用例表格式。
2. ("退货咨询", "怎么退货", "退货流程", "退款流程", False)一条典型失败用例：模型把“退货流程”答成了“退款流程”，意图识别偏差，归因是“语义近似混淆”。
3. def calc_pass_rate(evals):计算评估集通过率，对应正文的通过率公式：通过数 ÷ 总用例数。
4. sum(1 for _, _, _, _, ok in evals if ok)Python 生成器表达式，遍历所有用例统计通过数量，是核心计数逻辑。
5. def calc_alignment(eval_rate, online_rate):实现对齐偏差公式，偏差 ≤ 15% 判定“对齐”。
6. if __name__ == "__main__":脚本入口，保证模块被导入时不执行，直接运行时才跑主流程。
7. print(f"对齐偏差: {gap:.1%}")格式化输出偏差百分比，方便直接粘贴进 PRD 评审记录。

常见误区

面试题