AI 产品概率性挑战

3.1 概率性不是缺陷，而是 AI 能力的来源#

大模型不是传统规则引擎。规则引擎接到输入后，根据代码分支返回确定结果。只要数据和代码不变，结果就应该一致。大模型的输出来自对上下文中下一个 Token 的概率预测。它能生成自然语言、归纳复杂信息、处理模糊表达，正是因为它不是简单查表，而是在概率空间中生成最可能的表达。

这带来优势：

• 能理解自然语言中的模糊意图。

• 能把不完整信息组织成可读答案。

• 能根据不同上下文调整表达。

• 能生成候选方案和解释。

• 能处理传统规则难以覆盖的长尾问题。

也带来风险：

• 同问不同答。

• 对缺失信息过度补全。

• 对事实边界不敏感。

• 输出格式偶尔不稳定。

• 被提示注入或上下文噪声影响。

• 在没有依据时仍然生成看似合理的答案。

产品负责人要接受一个现实：AI 产品不能追求“永远完全一致”，而要追求“在业务可接受范围内稳定有用”。这句话看起来简单，但会改变整个产品设计。

例如商品文案生成，同一商品生成不同版本文案通常可以接受，甚至有价值，因为运营需要多样化表达。但订单退款政策问答同问不同答就不可接受，因为用户权益必须一致。客户续约风险总结里措辞略有差异可接受，但把“已续约”说成“高流失风险”不可接受。医疗、金融、法务场景中，错误建议可能必须拦截，不能只靠事后纠正。

所以第一步不是消灭概率性，而是判断场景对确定性的要求。

1
低确定性要求：创意生成、营销文案、标题备选、脑暴
2
中确定性要求：导购建议、客服话术草稿、销售摘要、知识问答
3
高确定性要求：价格、库存、订单、权限、合同、医疗、金融、法律

确定性要求越高，AI 越不能直接输出最终动作。它可以做辅助、摘要、候选、解释，但事实字段要来自系统，关键动作要由规则和人确认。

3.2 用户不反感 AI 出错，用户反感系统假装确定#

用户对不同产品的容错预期不同。写作助手给出一个不完美标题，用户可以改；导购推荐不够准确，用户可以继续筛选；客服机器人给错退款政策，用户会投诉；AI 数据分析报错导致经营决策错误，管理层会失去信任。

用户真正不能接受的是：系统明明不确定，却用确定语气回答；系统明明没有查到依据，却编造依据；系统明明只是建议，却表现成最终结论；系统出错后没有纠错入口。

因此，AI 产品要管理用户预期：

这里要避免两个极端。

第一个极端是过度免责声明。每句话都说“AI 可能出错”，用户体验会很差，也没有实际风控价值。第二个极端是完全不提示边界，让用户以为 AI 结果等同于系统事实。正确做法是把不确定性嵌入流程：

• 用“建议”“草稿”“候选方案”表达模型输出性质。

• 对事实类内容展示来源或引用。

• 对关键字段使用业务系统返回值，不让模型编造。

• 对高风险结论要求确认。

• 对低置信度输出自动追问或转人工。

• 对用户反馈提供“有误”“不相关”“需要人工”入口。

这不是削弱 AI，而是提高用户信任。用户知道系统边界，反而更愿意使用。

3.3 错误分级：不要把所有 AI 错误混在一起#

很多团队复盘 AI 问题时只说“模型回答错了”。这个说法太粗，无法指导产品决策。一个标点错误、一句语气不自然、一个格式字段缺失、一个价格错误、一个隐私泄露，都是“错”，但严重程度完全不同。

建议把 AI 错误分为 5 级：

这个分级的价值是让团队能做明确决策。L1 和 L2 可以通过迭代优化；L3 需要灰度和人工兜底；L4 通常不能直接自动化；L5 必须在输出前拦截。

产品负责人需要推动团队建立“错误预算”。不是说允许严重错误，而是明确某类错误的可接受阈值。例如：

• 商品文案语气瑕疵率小于 8% 可接受。

• JSON 格式错误率大于 2% 阻塞上线，因为前端无法解析。

• 客服政策错误率大于 0.5% 阻塞自动回复。

• 价格、优惠、权益错误 0 容忍。

• 隐私泄露、越权调用、违法内容 0 容忍。

没有错误分级，团队会陷入两种低效状态：要么因为小错误无限延期，要么把严重错误当成“模型偶发”继续上线。错误分级让质量讨论回到业务影响。

3.4 可接受错误、不可接受错误、必须拦截错误#

计划表今天要求定义三类错误：可接受错误、不可接受错误、必须拦截错误。这是产品评审中最实用的分类。

可接受错误指不会造成明显损失，用户能修正或业务能容忍的错误。比如文案不够精彩、推荐理由不够完整、摘要漏掉非关键点。这类错误可以通过反馈、编辑、重新生成解决。

不可接受错误指会明显伤害任务完成或用户信任，但不一定触碰合规红线。比如客服回答错售后流程、数据分析归因方向错误、销售摘要遗漏关键风险。这类错误不能直接放任，需要限制自动化范围、增加人工确认、优化评估集。

必须拦截错误指一旦输出就可能造成严重损失或违规。比如泄露隐私、越权访问、错误财务承诺、医疗诊断、法律定论、诱导违规操作、绕过安全规则。这类错误必须在输出前通过规则、权限、内容安全、工具校验、人审机制拦截。

这三类错误和产品形态直接相关：

1
可接受错误：
2
AI 可直接输出，但提供编辑、重试、反馈。
3

4
不可接受错误：
5
AI 可生成草稿或建议，但需要人工确认或引用依据。
6

7
必须拦截错误：
8
AI 不应生成最终内容，应拒答、转人工或触发安全流程。

以客服场景为例：

• 可接受：回复语气略机械，用户仍能理解。

• 不可接受：漏说退货需要保持吊牌完整，导致用户操作失败。

• 必须拦截：承诺“无条件赔付 500 元”或泄露其他用户订单信息。

以电商导购为例：

• 可接受：推荐排序不完全符合用户审美。

• 不可接受：给孕妇推荐明确不适用的产品。

• 必须拦截：编造商品功效、输出医疗治疗承诺。

以数据分析为例：

• 可接受：图表解释措辞不够简洁。

• 不可接受：把环比当同比解释。

• 必须拦截：给无权限用户展示部门薪酬或客户隐私数据。

3.5 不可复现问题如何排查#

AI 产品还有一个工程管理难点：用户反馈“刚才 AI 回答错了”，团队复现时可能得不到同样结果。传统 Bug 通常有明确步骤，AI Bug 需要更完整的上下文记录。

排查 AI 错误至少需要记录：

没有这些日志，团队只能争论“是不是模型不行”。有了日志，才能判断错误来源：

• Prompt 指令冲突。

• 输入字段缺失。

• 检索资料错误。

• 模型能力不足。

• 输出被截断。

• 后处理解析错误。

• 用户问题超出支持范围。

• 权限和工具调用异常。

这里要注意隐私和安全。记录日志不等于无限保存用户敏感信息。高风险字段要脱敏，日志权限要控制，保存周期要明确。AI 可观测性和数据合规必须一起设计。

3.6 概率性输出如何进入上线流程#

AI 功能上线不能只做功能测试，还要做概率性测试。传统功能测试通常验证某个输入是否得到某个确定输出。AI 测试更像评估分布：在一组样本、多个版本、多个模型参数下，输出是否总体符合标准，高风险样本是否被稳定拦截。

上线流程建议：

1
需求定义
2
-> 错误分级
3
-> 样本集设计
4
-> Prompt 和模型初版
5
-> 离线评估
6
-> 红线样本测试
7
-> 内部试用
8
-> 小流量灰度
9
-> 监控错误和反馈
10
-> 扩大流量
11
-> 定期回归

每一步都要有退出条件。比如：

• 红线样本有 1 条失败：不得上线。

• 格式合规率低于 98%：不得接入自动流程。

• L3 错误率高于 3%：只能人工审核，不允许自动发送。

• 用户满意度低于基线：停止放量。

• 成本超过预算 90%：触发限流或降级。

这会让 AI 项目从“凭感觉上线”变成“按风险上线”。

3.7 增长团队为什么必须理解概率性风险#

增长团队往往关注曝光、点击、转化、留存，但 AI 产品多了一个变量：每次交互都有边际成本和质量风险。一个 AI 导购入口如果被放到首页，调用量会上升，转化可能上升，成本也会上升，错误推荐和投诉也可能上升。

增长实验必须把质量和风险指标纳入实验设计：

否则 AI 功能可能短期提升互动，长期损害信任。尤其客服、金融、教育、医疗、招聘、合同等场景，错误不是简单体验问题，而可能变成合规和品牌问题。

增长负责人需要和产品、算法、法务一起定义放量条件。例如：

• 只对低风险问题开放自动回复。

• 高风险问题只生成草稿。

• 新用户入口先展示边界提示。

• 活动期间设置预算上限和限流。

• 投诉率超过阈值自动回滚。

AI 增长不是让模型尽可能多地参与，而是让模型在风险可控的地方创造增量。

4.1 业务背景#

某国内电商平台上线售后客服机器人，主要处理退货、换货、退款、运费险、发票和物流问题。上线初期，机器人能回答大量常见问题，人工客服压力明显下降。但大促后出现投诉：不同用户询问“拆封后还能退吗”，机器人给出了不同答案。

有时回答“七天内支持无理由退货”，有时回答“拆封不影响退货”，有时又补充“部分商品除外”。问题在于平台售后政策实际上区分类目：服饰拆吊牌不可退，食品开封不可退，3C 激活后不可退，普通日用品可以按规则退。

4.2 相关角色#

4.3 原始流程#

1
用户进入售后客服
2
-> 输入“拆封后还能退吗”
3
-> 机器人检索售后知识库
4
-> 大模型生成自然语言答案
5
-> 用户按答案操作
6
-> 若产生争议，再转人工

原流程的问题：

• 用户问题没有绑定具体订单和商品类目。

• 知识库里存在多条相似政策，模型自行综合。

• Prompt 没要求缺少商品类目时先追问。

• 没有错误分级，把政策不完整当成普通回答问题。

• 缺少一致性评估，同一问题不同上下文回答不一致。

4.4 AI 改造流程#

改造目标是把“通用政策问答”改成“订单和类目感知的政策解释”。

1
用户提出售后问题
2
-> 判断是否涉及具体商品政策
3
-> 检查是否有订单上下文
4
   |-- 有：读取商品类目、订单状态、签收时间
5
   |-- 无：追问商品类型或引导选择订单
6
-> 查询售后政策系统
7
-> 返回结构化政策结果
8
-> 模型只负责解释，不负责创造政策
9
-> 如果政策冲突或置信度低，转人工

4.5 数据 / 系统依赖#

4.6 方案架构#

1
客服入口
2
  |
3
售后 AI 编排层
4
  |-- 意图识别：是否为退换货政策
5
  |-- 上下文检查：是否绑定订单
6
  |-- 信息缺口判断：是否缺商品类目
7
  |-- 政策查询：售后政策系统
8
  |-- 模型解释：把政策转为用户可懂话术
9
  |-- 输出校验：是否存在承诺类风险
10
  |-- 转人工：冲突、低置信度、高风险
11
  |
12
订单 / 商品 / 政策 / 知识库 / 工单

4.7 关键指标#

4.8 主要风险#

4.9 复盘结论#

这个案例的本质不是“模型同问不同答”，而是产品没有把确定性事实和概率性解释分层。退换货政策属于高确定性信息，必须来自政策系统；模型只能负责解释和表达。缺少商品类目时，正确行为不是猜答案，而是追问或引导用户选择订单。

5.1 业务背景#

一家 B2B SaaS 公司为运营团队上线 AI 数据分析助手。运营可以直接问：“为什么上周新增客户下降？”系统会查询数据仓库并生成归因报告。上线后，某次周会上，AI 报告指出“新增客户同比下降 18%，主要来自渠道 A 投放减少”。但运营负责人发现报表原始字段其实是环比下降，AI 在解释时把环比写成同比。

这个错误没有直接造成系统损坏，但影响了管理层判断，团队对 AI 分析助手的信任明显下降。

5.2 相关角色#

5.3 原始流程#

1
用户自然语言提问
2
-> AI 生成查询条件
3
-> 查询数据仓库
4
-> 大模型读取表格结果
5
-> 生成归因报告
6
-> 用户在会议中引用结论

原流程的问题：

• 指标口径没有强制结构化展示。

• 模型把计算结果和解释文字混在一起生成。

• 报告没有区分原始数据、计算口径和模型推断。

• 缺少高风险分析场景的人工确认。

• 评估集没有覆盖“同比 / 环比 / 占比 / 绝对值”混淆。

5.4 AI 改造流程#

改造方案把数据分析助手拆为“确定性计算层”和“概率性解释层”。

1
用户提问
2
-> 意图解析：指标、时间、维度、对比方式
3
-> 指标层校验：是否存在标准口径
4
-> SQL / 查询工具执行
5
-> 结构化返回：数值、单位、时间范围、对比方式
6
-> 规则层生成事实摘要
7
-> 模型生成解释和可能原因
8
-> 报告中明确区分：事实 / 推断 / 建议
9
-> 关键报告支持分析师确认

5.5 数据 / 系统依赖#

5.6 方案架构#

1
AI 数据分析入口
2
  |
3
意图解析
4
  |-- 指标
5
  |-- 时间范围
6
  |-- 维度
7
  |-- 对比方式
8
  |
9
确定性数据层
10
  |-- 指标口径校验
11
  |-- SQL 查询
12
  |-- 数值计算
13
  |-- 权限过滤
14
  |
15
解释生成层
16
  |-- 事实摘要
17
  |-- 归因假设
18
  |-- 建议动作
19
  |-- 风险提示
20
  |
21
人工确认 / 报告发布

5.7 关键指标#

5.8 主要风险#

5.9 复盘结论#

数据分析 AI 的关键不是让模型“聪明解释”，而是把确定性计算和概率性解释严格分开。数值、口径、时间范围、维度必须由指标系统和查询系统控制；模型负责把这些事实转成可读解释，并明确哪些是推断。否则 AI 生成的报告越流畅，误导性可能越强。

任务：定义一个 AI 功能的错误分级表#

选择一个你正在考虑或已经设计过的 AI 功能，例如智能客服、AI 导购、商品文案生成、销售摘要、经营分析、合同摘要、课程咨询。为它定义错误分级和处理策略。

你需要输出：

1. 功能说明：AI 在什么场景下为谁完成什么任务。

2. 用户预期：用户认为 AI 输出是建议、草稿、事实，还是可执行结论。

3. 错误清单：至少列出 15 类可能错误。

4. 错误分级：按 L1-L5 标注严重程度。

5. 三类归属：可接受错误、不可接受错误、必须拦截错误。

6. 处理策略：重试、澄清、引用、规则校验、人工确认、拒答、转人工。

7. 指标阈值：每类错误的可接受上限。

8. 上线结论：允许上线、只允许灰度、必须人工审核、阻塞上线。

验收标准#

7.1 理解题#

题 1：为什么 AI 产品会出现同问不同答？

参考答案： 大模型基于概率生成，输出受 Prompt、上下文、模型版本、参数、检索片段和会话历史影响。即使用户问题相似，系统上下文不同也可能导致答案差异。同问不同答不一定是 Bug，但在政策、价格、权限等高确定性场景中必须被产品和工程机制控制。

题 2：用户最不能接受的 AI 错误通常是什么？

参考答案： 用户最不能接受的不是小的表达瑕疵，而是系统在不确定时假装确定，编造事实、给出错误承诺、泄露隐私、越权操作，或出错后没有纠错和人工接管入口。

题 3：为什么要做 AI 错误分级？

参考答案： 不同错误的业务影响不同。语气问题和隐私泄露不能用同一标准处理。错误分级能帮助团队决定哪些问题可以迭代优化，哪些需要灰度和人工确认，哪些必须拦截并阻塞上线。

题 4：确定性数据层和概率性解释层为什么要分开？

参考答案： 价格、库存、订单、指标数值、权限、合同条款等事实信息必须来自确定系统。模型适合解释、总结和生成表达。二者混在一起会导致模型编造或改写事实，增加业务风险。

7.2 应用题#

题 5：客服机器人错误承诺退款，你会如何处理？

参考答案： 先将该错误定为 L4 高风险业务错误，若涉及越权或权益损失则接近 L5。短期应下线相关自动回复或强制转人工，复盘日志、Prompt、政策版本和订单上下文。中期要把退款承诺改为规则或政策系统控制，模型只解释，不做承诺；增加红线评估样本和输出拦截。

题 6：AI 导购推荐不够精准，但没有事实错误，是否阻塞上线？

参考答案： 通常不阻塞全量探索，但要看程度。如果只是偏好不精准，可归为 L1-L2，通过用户修正、重新推荐和反馈优化。如果明显违反关键约束，例如预算、尺码、禁忌人群，则可能是 L3 或 L4，需要限制灰度并优化意图理解和约束校验。

题 7：AI 数据分析助手把环比写成同比，应该如何设计防护？

参考答案： 对比方式必须由指标层结构化返回，不能让模型自由解释；报告中固定展示时间范围、指标口径、对比类型和原始数值；模型只生成解释和建议；把同比/环比混淆加入评估集；关键经营报告需要分析师确认。

8.1 AI 错误分级表#

8.2 可接受 / 不可接受 / 必须拦截错误清单#

1
功能名称：
2
业务场景：
3
目标用户：
4
AI 输出性质：建议 / 草稿 / 事实解释 / 可执行动作
5

6
一、可接受错误
7
1.
8
2.
9
3.
10
处理方式：
11
- 用户可编辑：
12
- 支持重新生成：
13
- 记录反馈：
14

15
二、不可接受错误
16
1.
17
2.
18
3.
19
处理方式：
20
- 增加引用：
21
- 增加人工确认：
22
- 限制自动发送：
23
- 加入评估集：
24

25
三、必须拦截错误
26
1.
27
2.
28
3.
29
处理方式：
30
- 输出前规则拦截：
31
- 权限校验：
32
- 内容安全检测：
33
- 转人工：
34
- 安全审计：

8.3 概率性输出上线风险评审模板#

1
项目名称：
2
AI 功能：
3
上线范围：
4
负责人：
5

6
一、场景确定性要求
7
- 低 / 中 / 高：
8
- 原因：
9

10
二、错误分级
11
| 错误类型 | 等级 | 业务影响 | 处理策略 | 是否阻塞上线 |
12
|---|---|---|---|---|
13

14
三、评估集
15
- 样本总数：
16
- 红线样本数：
17
- 通过率：
18
- L4 / L5 是否全部拦截：
19

20
四、用户预期管理
21
- 是否标注 AI 输出性质：
22
- 是否展示依据：
23
- 是否支持用户反馈：
24
- 是否提供人工入口：
25

26
五、工程防护
27
- 日志字段是否完整：
28
- Prompt 版本是否记录：
29
- 模型版本是否记录：
30
- 是否支持灰度：
31
- 是否支持回滚：
32

33
六、上线结论
34
- 允许上线：
35
- 仅内部试用：
36
- 仅小流量灰度：
37
- 必须人工审核：
38
- 阻塞上线：