AI产品经理必懂的60个核心概念（46-60）

46​

PART​

ASR 语音识别​

用户对着麦克风说了一段话，你的 ASR 把帮我订一张去三亚的机票识别成了帮我订一张去三丫的机票。订票 Agent 查不到三丫这个地方，整个流程直接挂了。​

ASR 好坏直接决定了语音交互链路的天花板。后面的 NLU、意图识别、Agent 执行全都依赖 ASR 的准确输出。​

现代 ASR 基于端到端的深度学习模型，能实时把语音流转成文字。但准确率和场景强相关。安静办公室里的普通话识别率可以到 98%以上，但加上方言、噪音、语速快、专业术语，准确率可能降到 80%甚至更低。​

产品经理 做语音产品必须关注三个场景化指标。Step 一字错率 WER，核心准确率指标。Step 二实时率 RTF，处理 1 秒语音需要多少秒计算，超过 0.5 就会有延迟感。Step 三领域适配，你的业务有大量专有名词和行话时，通用 ASR 的识别率会大打折扣，需要热词表或领域微调。​

有个设计建议，ASR 输出一定要加后处理。加标点、数字归一化、敏感词过滤、同音词纠错。这步不做，即使 ASR 识别率很高，给到 NLU 的文本格式也是乱的。​

​

​

47​

PART​

OCR 光学字符识别​

用户拍了一张发票照片上传，你的系统需要自动提取金额、日期、发票号。传统 OCR 只能识别打印体的清晰文字，拍照时角度稍微歪一点、光线暗一些，识别率就崩了。​

OCR 不只是把图片里的字提取出来。现代 OCR 需要做四件事。Step 一文字检测，在图片里找到文字区域的位置。Step 二文字识别，把检测到的区域里的文字识别出来。Step 三结构理解，理解文字的位置关系和逻辑结构，比如表格里哪个数字对应哪个字段。Step 四后处理，纠错和格式化。​

现在的 OCR 演进方向是从看文字到理解版面。新一代的文档智能模型能同时理解文字内容和版面布局，自动识别标题、正文、表格、公式的结构关系。这对复杂文档的自动化处理非常关键。​

产品经理 做 OCR 相关产品要先确认场景难度。文本清晰打印体的标准文档用通用 OCR 就够。手写体、弯曲变形、低光照这些难场景需要专门的 OCR 模型。票据证照类需要专门训练的版面理解模型。难度搞错了选型就会错。​

​

​

48​

PART​

Text-to-Image 文生图​

设计师工期排不上来，你想用 AI 生成产品配图。输入了一句描述，生成的图片里人物多了一根手指、文字变成了乱码、品牌 Logo 完全变形。老板说这图不能用。​

所有人都被文生图 Demo 里那些华丽的图片震撼过，但真正用到产品里才发现，大部分生成结果不能直接商用。​

文生图的底层是扩散模型，从完全的随机噪声开始，根据文字描述一步步去噪，最终生成图片。当前主流模型在以下场景效果很好，风景、插画、艺术创作、概念图。在以下场景依然不稳定，人手细节、精确文字渲染、品牌 Logo、多物体精确空间关系。​

产品经理 做 AI 配图功能要提前定义验收标准。哪些程度的瑕疵可以接受、哪些必须人工修正。比如社交媒体配图对精度要求不高，AI 直出可以接受。但产品宣传图对品牌一致性要求很高，AI 只能出初稿还是得设计师精修。​

选型关注三点，生成质量、可控性和版权。可控性是关键差异，ControlNet 这类技术让你能通过线稿、姿势、深度图来控制生成结果，大幅提升实用性。版权问题也不能忽视，部分模型的训练数据存在版权争议，商用需确认许可条款。​

49​

PART​

NER 命名实体识别​

用户说帮我订明天从北京到上海的高铁，你的系统需要从这句话里提取出三个信息，时间是明天，出发地是北京，目的地是上海。这个提取过程就是 NER。​

NER 全称 Named Entity Recognition，从自然语言文本中识别并分类出预定义的实体类型。常见实体类型，人名、地名、时间、金额、组织名、产品名。在 AI 产品里，NER 是连接用户自然语言和结构化操作的桥梁。​

为什么不直接让大模型做 NER？可以，但有坑。大模型做 NER 的优势是泛化能力强、不需要标注数据、能理解复杂上下文。劣势是推理成本高、速度慢、在精确格式要求下不够稳定。高频场景用专门的 NER 小模型成本低速度快，低频场景或复杂场景用大模型做。​

产品经理 设计涉及 NER 的功能时，要先列出业务需要的全部实体类型和标准格式。明天要转成具体日期、北京要转成标准城市编码。这些转换规则不是模型自动知道的，需要你定义好告诉开发。漏定义了一个实体类型，对应的业务功能就无法触发。​

​

​

50​

PART​

Intent Recognition 意图识别​

用户说太贵了，是想砍价还是要取消订单还是只是吐槽？你的 AI 客服把每一个说太贵了的用户都转到退款流程，投诉反而多了。因为大部分用户只是在表达情绪，根本不想退款。​

意图识别是 NLU 的核心任务。用户每一句话的背后都有一个真实意图，AI 要做的是准确判断出这个意图，然后触发对应的处理流程。​

设计意图识别系统 产品经理 要做三件事。Step 一定义意图列表，。穷举用户可能的意图并分类，咨询、投诉、下单、退款、闲聊、超出范围。每个意图对应一个处理流程。Step 二处理模糊意图，。用户的话经常是模糊的，太贵了可能映射到多个意图。需要定义置信度阈值，高于 0.8 直接触发流程，0.5-0.8 追问确认，低于 0.5 兜底到通用回复。Step 三处理多意图，。用户一句话可能包含两个意图，我要退掉 A 商品然后换成 B 商品，退货和购买两个意图并存。​

我的经验是意图识别的准确率比模型回答的质量更重要。如果意图就分错了，后面再怎么优化回答都是答非所问。在需求阶段就把意图列表和优先级排好，比上线后反复调模型有效得多。​

51​

PART​

Precision 精确率​

你的 AI 风控系统把 1000 个用户标记为疑似欺诈，风控团队逐个核查后发现只有 200 个真的有问题，800 个是正常用户被误判。那 800 个用户的账户被冻结，投诉电话打爆了客服中心。​

精确率衡量的是别乱报。计算方式，模型预测为正的结果里有多少真正是对的。上面的例子精确率只有 20%，意味着每标记 5 个欺诈就有 4 个是冤枉的。​

风控场景最在意精确率。你把一个正常用户标为欺诈，这个误报的代价比漏掉一个真欺诈可能还大，用户投诉、法律风险、品牌伤害全来了。所以风控宁可漏几个也不能乱报。​

产品经理 要做的核心决策，你的场景更怕误报还是更怕漏报？怕误报就优先精确率，提高判定阈值让模型只在高确信时才标记。但代价是会漏掉更多真实案例，召回率下降。两个不可兼得，必须取舍，不存在两全其美的方案。​

52​

PART​

Recall 召回率​

你的 AI 内容审核系统审核了 1 万条用户评论，标记删除了 500 条违规内容。但人工抽检发现另外还有 300 条违规内容漏掉了。那 300 条里有涉及人身攻击和违法信息的，被用户截图举报，平台被监管部门约谈。​

召回率衡量的是别漏掉。计算方式，实际为正的结果里有多少被模型找到了。800 条实际违规内容只找到 500 条，召回率 62.5%，漏了近四成。​

客服场景重召回，用户投诉你没发现，问题恶化后损失更大。医疗场景更重召回，漏诊比误诊后果严重得多。内容安全场景也重召回，漏一条违规内容被监管发现就是事故。​

F1 Score 是精确率和召回率的调和平均，当你两个都想兼顾时作为综合指标。但实际产品设计中，很少有场景真的两个一样重要。产品经理 要根据业务风险做明确取舍，风控重精确、客服重召回、内容安全重召回、搜索推荐看场景。先确定主要指标，次要指标设一个底线就够了。​

53​

PART​

​

​

Bad Case 分析​

团队每周例会上讨论模型效果怎么优化，大家凭感觉提了一堆方向，Prompt 改了十几版，效果忽好忽差。折腾一个月发现根本没改到点上，因为从头到尾没人去看线上到底错在哪里。​

Bad Case 分析是 AI 产品优化的核心方法论。不是拍脑袋改 Prompt，而是用数据说话。​

标准流程五步。第一步，收集，从线上日志按时间周期采样，加上用户点踩或负反馈标记的样本，每周至少拉 200-500 条。第二步，分类，幻觉、拒答、格式错误、逻辑错误、检索失败，按大类分，统计每类占比。第三步，归因，每类 Bad Case 的根因是什么，是 Prompt 没约束住、知识库没覆盖、检索没命中、还是模型能力不够。第四步，修复，针对性优化，Prompt 问题改 Prompt，知识库问题补文档，检索问题调策略。第五步，验证，修复后在相同样本集上验证是否解决，防止改了 A 又坏了 B。​

产品经理 每周花 2 小时看 Bad Case 比花 10 小时凭感觉调 Prompt 有效得多。因为 Bad Case 告诉你真正的问题在哪里，不用猜。​

54​

PART​

数据标注​

算法同事说微调需要 5000 条高质量标注数据，你以为找几个实习生标一周就行了。结果标出来的数据一致性只有 50%，同样一条数据两个人标出相反的结果。模型训练完效果比没微调还差。​

数据标注看似简单实则坑极多。标注质量等于模型质量上限，这个环节省不得。​

三个关键环节必须卡死。Step 一标注指南，必须详细到每种边界 Case 都有明确判断标准，不能靠标注员自行理解。正面情感和中性情感的边界在哪？不写清楚每个人理解都不一样。Step 二试标校准，先让 3-5 个人标 100 条，计算一致性，用 Kappa 系数衡量，一致性低于 80%就得修改标注指南再重新试标。Step 三质检机制，正式标注期间持续抽检，准确率低于阈值的标注员要重新培训。​

成本参考，简单分类标注每条 0.5-2 元，复杂对话标注每条 5-20 元，专业领域标注更贵。数量上，微调通常需要 1000-10000 条，评测集需要 500-2000 条。标注周期和成本是 AI 项目排期里最容易被低估的部分。​

55​

PART​

Human Evaluation 人工评测​

你用了 BLEU 和 ROUGE 两个自动评测指标，分数都很高。上线后用户反馈回答正确但像机器人说话语气很奇怪不像人会说的话。自动指标完全没发现这些问题。​

BLEU、ROUGE 这些自动评测指标只能衡量文本相似度，判断不了回答好不好用、安不安全、语气合不合适。这些只有人能评。​

做人工评测的标准流程。第一步，定义评测维度，准确性、相关性、流畅度、安全性、有用性，每个维度 1-5 分。第二步，准备评测集，500-2000 条有代表性的 Case，覆盖主要业务场景和边缘 Case。第三步，双盲评测，同一条样本两个人独立打分，计算一致性。一致性低于 0.7 说明评测标准不清晰需要重新校准。第四步，汇总报告，按维度统计分数，找出短板。​

建议每次模型更新或 Prompt 大改之后都做一轮人工评测。样本量不用太大，300 条覆盖主要场景就够发现 80%的问题。人工评测是自动指标的护城河补充，不是替代关系。​

56​

PART​

API​

产品经理不需要会写代码。但你调大模型不是直接操作模型，而是通过 API 发 HTTP 请求。如果你连 API 文档都读不懂，和开发讨论技术方案时就只能旁听，做不了决策。​

API 就是两个系统之间的通信接口。你的产品后端给大模型服务发一个请求，里面包含模型名、消息内容、参数。大模型服务处理后返回结果，里面包含生成的文本和 Token 消耗量。​

产品经理 需要关注的 API 知识不多但很关键。Step 一入参出参，输入什么格式、输出什么格式，直接影响你的产品功能设计。比如模型是否支持图片输入直接决定了你能不能做多模态功能。Step 二计费方式，按 Token 还是按次，输入输出是否分开计价，能不能用批量接口降成本。Step 三限制，每分钟最多调多少次、单次最大 Token 数、并发数限制。Step 四错误码，超限返回 429、超时返回 504、服务不可用返回 503，产品层怎么处理每种错误要事先定义好。​

你不需要会写代码，但需要能看懂 API 文档并和开发讨论参数选择。这是 AI 产品经理 和传统 产品经理 的关键区别之一。​

57​

PART​

Latency 延迟​

你的 AI 产品用户满意度评分从 4.2 降到了 3.5，分析原因不是回答质量变差了，而是服务器负载上来之后延迟从 3 秒变成了 8 秒。用户的耐心比你想象的少得多。​

传统 App 的 API 响应通常在 100-300ms，用户感知不到等待。AI 产品的端到端延迟可能在 3-15 秒，用户明显感觉到在等。这是 AI 产品和传统产品在体验上最大的区别之一。​

延迟的构成，网络传输约 50ms + 排队等待 0 到数秒 + 首 Token 生成约 500ms + 逐 Token 输出 3-15 秒 + 网络返回约 50ms。其中排队等待在高峰期可能成为瓶颈，模型推理时间和输出长度正相关。​

产品经理 能做的优化。Step 一流式输出，不等全部生成完就开始返回，用户感知延迟大幅降低。Step 二Prompt 精简，减少无效 Token，每少 1000 Token 快 0.5-1 秒。Step 三模型选择，同等能力选更快的模型，小模型比大模型快很多。Step 四预加载，预判用户意图提前发请求。Step 五体验设计，加 loading 动画、分步展示、先显示摘要再展开详情。让等待变得可以接受。​

58​

PART​

Rate Limiting 限流​

你的 AI 产品上线后突然被某个科技媒体报道了，流量一小时内从日常的 1000 飙到 10 万。大模型 API 的并发限制被打满，所有用户都看到报错页面。公关的正面效果被产品故障抵消了。​

限流不是限制用户，是保护系统。不做限流，一次流量高峰就能让全系统瘫痪。​

三层限流必须规划。第一层，供应商限流，大模型 API 提供商对你的 API Key 有 RPM，每分钟请求数，和 TPM，每分钟 Token 数，上限，超了直接返回 429 错误。第二层，系统限流，你自己的后端对用户请求做限流，防止击穿供应商限制。第三层，用户限流，每个用户每天能用多少次，VIP 和免费用户的配额不同。​

产品经理 必须在 PRD 里定义五件事，正常负载和峰值负载各是多少、限流时用户看到什么提示，不能是空白报错页面，、是否支持排队机制、降级策略是什么，比如临时切到更便宜更快的模型，、流量突增时的自动扩容规则。这些不提前设计，上线后第一次流量高峰就是事故。​

59​

PART​

灰度发布​

你改了一个 Prompt 觉得效果更好，直接全量发布。上线后发现主流场景确实变好了，但有个长尾场景客诉量飙升 300%。因为新 Prompt 在那个场景里完全崩了，你回滚的时候已经积累了几百条投诉。​

传统产品更新是确定性的，新按钮在不在、新功能好不好用，上线前 QA 能测清楚。AI 产品更新是概率性的，模型换了一版或 Prompt 改了一段，效果好不好只能在真实流量上验证。​

标准灰度流程，5%流量放新版本 → 跑 3-7 天 → 对比核心指标，准确率、满意度、延迟、成本，→ 指标显著优于旧版才放量 → 10% → 30% → 50% → 100%。任何一步指标不达标就回滚到旧版本。​

产品经理 常犯的错误，改了一个 Prompt 觉得效果更好就直接全量发布。任何模型层面的变更都要灰度，没有例外。因为模型是概率系统，你测试的 20 条 Case 效果变好了不代表线上 20 万条 Case 都变好了。灰度是唯一能兜住这个风险的手段。​

60​

PART​

数据飞轮​

你的竞品和你用一样的模型一样的技术栈，但半年后它的效果明显比你好。不是它的 产品经理 比你厉害，是它的产品设计里从第一天就埋了数据飞轮的机制，你没有。​

数据飞轮是 AI 产品的终极壁垒。不是你的模型比别人好，是你比别人有更多更好的业务数据来持续优化模型。​

飞轮的四个阶段形成闭环，产品上线 → 收集用户数据 → 优化模型 → 体验提升 → 吸引更多用户 → 更多数据。循环越转越快，先跑起来的产品优势会越来越大。​

飞轮转起来的关键是 产品经理 要设计好数据收集机制。Step 一隐式反馈，用户点了重新生成说明对上一次输出不满意。Step 二显式反馈，点赞、点踩、评分。Step 三行为数据，用户有没有复制使用 AI 的结果、有没有手动修改。Step 四转化数据，AI 推荐的内容用户有没有点击购买。​

没有人主动设计这个闭环，飞轮就转不起来。数据飞轮不是自然形成的，是被设计出来的。产品经理 的工作是定义哪些数据要收集、怎么存、多久清洗一轮、怎么喂给模型优化。这件事越早做越好，因为数据积累是有时间价值的。​

​