大模型产品的评估与设计
建立 AI 产品评估与 PRD 方法，覆盖任务成功、正确率、人工接管、成本、延迟、安全、信任校准和 ROI。
「产品经理的大模型基础」系列之八
上一篇：Agent 的基本原理 · 系列入口
大模型产品最容易出现的误判，是用几次效果很好的演示代替系统评估。
传统功能通常有明确规则，输入相同时结果比较稳定。大模型输出具有概率性，还可能依赖检索、工具和多步流程。一次成功只能说明系统在这条样例上成功，不能说明它面对真实用户时足够可靠。
因此，大模型产品设计需要从一开始就考虑评估。正确率、任务完成率、人工接管率、成本和延迟，不是上线后的补充指标，而是产品方案的一部分。
一、为什么大模型产品更难评估
大模型输出常常没有唯一标准答案。对于摘要、文案或方案分析，两个不同回答都可能合理。同时，一个回答可以语言流畅，却遗漏事实；格式完全正确，却引用错误；最终任务完成了，但中间执行了不必要的高风险操作。
评估对象也不只是模型。一个完整 AI 系统可能包含：
- 用户输入与数据处理。
- Prompt 和上下文组装。
- RAG 检索。
- 模型生成。
- 工具调用。
- Workflow 或 Agent 循环。
- 权限控制与人工确认。
- 最终界面呈现。
只看最终答案，很难知道错误发生在哪一层。
二、先定义任务成功
评估之前，产品经理需要明确任务怎样才算完成。
例如，“自动分析用户访谈”不能只定义为生成一份总结。更具体的成功标准可能包括：
- 主要用户目标没有遗漏。
- 每条痛点能够对应原文证据。
- 不把单个用户观点扩大为普遍结论。
- 矛盾观点得到保留。
- 信息不足时不自行补全。
- 输出字段能够被后续系统读取。
对于 Agent，成功标准还可能包括：使用了正确工具、没有越权、在预算内完成、执行结果真实写入业务系统。
三、正确率怎样理解
正确率适合有明确标准答案的任务，例如分类、字段提取、计算结果和工具参数。
但在开放式任务中，需要拆成更具体的评价维度：
- 事实正确性：内容是否与可靠资料一致。
- 完整性：关键内容是否遗漏。
- 相关性：是否真正回答用户问题。
- 引用正确性：引用是否支持对应结论。
- 格式合规性：是否符合约定结构。
- 安全性：是否出现越权或敏感内容泄露。
不同产品需要为这些维度设置不同权重。客服政策的事实正确性远比文风多样性重要；创意文案则可能更重视新颖程度和品牌风格。
四、任务完成率
任务完成率关注用户目标是否真正实现，而不只是模型是否生成了回答。
例如，用户要求“根据需求创建一条任务”。模型正确理解了需求并生成漂亮草稿，但工具调用失败，业务系统中没有新任务。文本质量很好，任务完成率仍然是失败。
对多步骤 Agent，任务完成率通常比单个回答正确率更接近实际价值。它需要结合环境结果判断：文件是否真的修改、消息是否真的发送、任务是否真的创建，以及用户是否接受结果。
五、人工接管率
人工接管率表示有多少任务最终需要人介入才能完成。
人工介入可能发生在：
- 系统无法理解输入。
- 检索不到可靠资料。
- 工具连续失败。
- 任务涉及高风险决策。
- 用户需要确认主观选择。
- Agent 达到停止条件。
人工接管率不是越低越好。在金融审批、医疗建议和不可逆操作中，保留人工确认可能是正确设计。更重要的是区分“设计上必须由人确认”和“系统能力不足导致被迫接管”。
六、成本
大模型产品成本不仅来自一次模型调用，还可能包括：
- 输入和输出 Token。
- 多次模型调用。
- Embedding 和检索服务。
- 重排模型。
- 外部工具和数据接口。
- 缓存、存储和日志。
- 人工审核与异常处理。
Agent 执行的步骤越多，成本越容易累积。更强的模型也不一定带来更好的经济性。实际方案需要比较“每次任务花多少钱”和“任务成功带来多少价值”。
降低成本的方法包括缩短无关上下文、缓存重复结果、给简单任务使用更轻量的模型、减少无价值循环，以及把确定性工作交给普通程序。
七、延迟
延迟直接影响用户体验，可以进一步区分：
- 首字延迟：用户多久看到第一部分内容。
- 总完成时间：整个任务多久真正完成。
- 工具等待时间：外部服务耗时多久。
- 人工等待时间：任务因确认或接管暂停多久。
流式输出可以改善首字延迟的感受，却不会自动缩短总完成时间。多步 Agent 可能需要几分钟甚至更久，此时产品需要显示进度、当前步骤和可以暂停的位置，而不是让用户一直看着加载动画。
八、评估集是什么
评估集是一组固定的代表性任务和样例，用于持续测试不同版本的系统。
一个好的评估集通常包括：
- 高频正常输入。
- 边界输入，例如超长、含糊或信息缺失。
- 容易混淆的分类情况。
- 过去已经出现过的失败。
- 涉及权限和安全的高风险情况。
- 对检索、工具和 Agent 路径的测试。
每条样例还需要明确的评判标准。可以使用程序规则、人工评分、模型辅助评分，或多种方式结合。
评估集的价值在于建立稳定基线。团队修改 Prompt、模型、检索或工具后，可以在同一批任务上重新运行，判断新版本究竟改善了什么，又破坏了什么。
九、从失败类型定位问题
当用户反馈“答案不对”，可以按系统层次定位：
| 层次 | 可能问题 |
|---|---|
| 输入 | 数据缺失、格式错误、语音识别不准 |
| Prompt | 任务或边界没有说明清楚 |
| 检索 | 没找到正确资料，或版本过滤错误 |
| 模型 | 误解、遗漏或无依据生成 |
| 工具 | 参数错误、权限不足、执行失败 |
| Workflow | 顺序、分支、重试或状态错误 |
| Agent | 计划偏离、循环、过早停止 |
| 交互 | 用户看不出来源、风险或当前状态 |
分类以后，团队才能选择正确改进方式，而不是遇到任何问题都换模型或加长提示词。
十、大模型产品中的交互设计
AI 产品需要帮助用户形成合理信任。常见设计包括：
- 展示答案来源和适用版本。
- 区分业务系统事实与模型生成建议。
- 信息不足时明确提出澄清问题。
- 高风险动作执行前预览参数。
- 提供编辑、撤销、重试和转人工。
- 多步任务展示进度和停止原因。
- 对不确定结果采用合适表达，而不是假装确定。
简单显示一句“AI 可能犯错”并不能代替这些具体设计。
这里要特别注意 Automation Bias（自动化偏误）：用户可能因为回答流畅、界面正式或系统经常答对，就过度相信错误结果。产品目标不是让用户“越信 AI 越好”，而是建立 Trust Calibration（信任校准）——系统可靠时让用户敢用，不确定或高风险时让用户看得见边界并愿意核验。
十一、概率性产品的 PRD 要写“结果范围”，不能只写正常流程
传统规则产品常用“输入 A，系统返回 B”描述需求。大模型产品更接近“输入 A，在给定上下文和约束下，可能返回 B、C 或失败结果 D”。因此 PRD 至少要回答：
- 哪些结果虽然表达不同，但都属于可接受范围。
- 已知失败有哪些类型，分别怎样被发现。
- 信息不足或模型不确定时，是澄清、拒答还是继续。
- 哪些内容可以自动生成，哪些动作允许自动执行。
- 哪些节点必须让用户预览、确认、撤销或转人工。
- 发生误判后，责任、审计和恢复路径是什么。
置信度字段可以作为信号，却不能自动代表真实正确率。模型说“我有 95% 把握”，不等于经过校准后确实有 95% 的概率正确。高风险流程应依据评估数据、业务规则和操作后果设置阈值，而不是只相信模型的自我判断。
十二、隐私与安全：模型输出和外部内容都不能默认可信
AI 产品扩大了数据流动范围：用户输入、企业文档、检索片段、工具返回和日志都可能进入模型服务。设计时需要确认数据最小化、保存期限、第三方处理方式、地区与合规要求、日志脱敏，以及用户是否有权让模型读取这些内容。
Prompt Injection（提示注入）是另一类关键风险。攻击者可以直接在对话中要求模型忽略规则，也可以把恶意指令藏在网页、邮件或文档里，等 Agent 检索后间接触发。系统提示词不是安全边界，不能仅靠“不要泄露、不要越权”抵抗攻击。
更可靠的控制包括：
- 将检索内容和工具返回视为不可信数据，与系统指令清楚分隔。
- 按最小权限原则提供工具和数据，只开放完成任务所需能力。
- 在程序层校验工具、参数、用户权限和资源范围。
- 对发送、删除、支付、发布等高影响动作要求明确确认。
- 限制 Agent 的步骤、成本和可访问目标，并保留审计记录。
- 用专门的安全评估集测试越权、数据外泄和间接提示注入。
大白话说，模型会读懂文字，也可能把不该听的文字当成命令。因此既要防止它“看见不该看的”，也要防止它“做出不该做的”。
十三、AI 产品 PRD 需要增加什么
传统 PRD 会描述用户、场景、功能、流程和异常。大模型产品还需要补充：
模型与系统职责
模型负责理解或生成什么，知识库、工具、程序规则和人工分别负责什么。
输入和输出边界
支持哪些数据、长度、语言和格式；什么情况下系统应拒绝或转人工。
知识和来源
数据从哪里来，多久更新，怎样处理版本、权限和引用。
失败模式
已知可能出现哪些错误，用户和系统分别怎样发现、恢复或撤销。
评估方案
使用什么评估集、指标和上线门槛；新版本怎样进行回归测试。
工具和权限
哪些操作可自动执行，哪些需要用户确认；怎样记录和审计。
成本与延迟
单任务预算、可接受等待时间、超时、重试、缓存和降级策略。
灰度与回滚
先向哪些用户开放，观察哪些指标，出现问题时怎样停用或退回人工流程。
数据、隐私与安全
哪些数据允许进入模型和日志，保存多久；怎样处理提示注入、越权、敏感信息和第三方服务；出现安全事件时如何止损与追踪。
十四、商业价值：完成任务之后，还要算这件事是否值得做
商业化不只等于“给 AI 功能定价”。产品还要判断系统创造的价值是否长期高于模型、工程、人工审核和风险成本。
可以从以下指标建立最小经济模型：
- 单任务价值：一次成功完成为用户节省多少时间、增加多少收入或避免多少损失。
- 有效自动化率：无需返工且真正完成的任务占比，而不是模型调用次数。
- Cost to Serve：完成一次任务的模型、检索、工具、存储和人工成本。
- 采用与留存：目标用户是否持续使用，而不是只在上线时尝鲜。
- 风险成本：错误执行、合规事件、用户流失和人工补救的预期代价。
- 投资回报率（ROI）：在一定周期内，新增收益和节省成本能否覆盖建设与运营投入。
例如，一个 Agent 把人工处理时间从 20 分钟降到 5 分钟，但一半任务需要返工，那么“节省 15 分钟”就是虚高口径。更合理的计算应基于完成且被接受的任务，并把返工、接管和异常成本算进去。
十五、产品经理在团队中的作用
大模型产品横跨模型、数据、工程、设计、安全和业务。产品经理不需要成为每个领域的专家，但需要把不同团队连接到同一套目标和评估标准。
与算法团队讨论模型和评估；与工程团队讨论接口、状态、工具和日志；与设计团队讨论等待、来源、确认和错误恢复；与业务和合规团队明确数据、权限和责任边界。
最终目的不是让方案包含最多 AI 名词，而是让用户任务在可接受的质量、风险、成本和延迟下完成。
本篇小结
大模型产品不能只凭演示效果判断。完整评估需要同时观察：
回答是否正确
任务是否完成
多少情况需要人工接管
每次任务花费多少成本
用户需要等待多久
错误能否被发现和恢复
隐私、权限和高风险动作是否受控
每次有效完成创造的价值是否覆盖成本八篇文章到这里形成了一条完整链路：从 Token 和概率生成理解模型，从训练和推理理解能力来源，通过提示词和 API 使用模型，再通过 RAG、工具、Workflow 和 Agent 扩展能力，最后用评估和产品设计把这些能力变成可靠系统。
上一篇：Agent 的基本原理 返回：产品经理的大模型基础