60 个核心概念第二部分，不讲数学，不背定义，全部落到工作场景。

31 PART 💡 Chunking 文档分块

你的 RAG 知识库上线了，用户问一个具体问题，系统返回了一段莫名其妙的内容。一查发现，检索到的文档片段被切在了一个句子中间，上半句话在一个块里，下半句在另一个块里。模型看到半句话当然答不到点上。

文档分块看着简单，按字数切就行了。恰恰就是这个按字数切害了很多 RAG 项目。

分块的核心矛盾，块太大，语义太杂，检索时相似度分数被不相关内容拉低。块太小，语义不完整，模型拿到残缺信息无法正确回答。最优块大小取决于你的文档结构和业务场景，没有万能参数。

三种主流分块策略。 Step 一 固定大小切分 ，每 500 字切一块加 50 字重叠。简单暴力但容易切断语义。 Step 二 按结构切分 ，按文档的标题、段落、章节等结构切分。保留了文档逻辑但对文档格式有要求。 Step 三 语义分块 ，用 Embedding 计算相邻句子的语义相似度，相似度骤降的地方就是语义边界，在边界处切分。效果最好但计算成本最高。

实操建议，先按文档结构切，找不到结构的部分用固定大小+重叠来兜底。块大小从 300-500 字开始测，在你的评测集上跑一遍看检索命中率。切分后必须人工抽查 50-100 个块，看有没有语义被切断的。

32 PART 💡 Reranking 重排序

你的 RAG 从向量数据库里召回了 10 条文档，排在第一的和用户问题最相关。但有时候排在第六七位的才是真正该用的文档，排第一的只是表面相似。用户体验时好时坏。

向量检索是粗排，速度快但精度有限。Reranking 是精排，速度慢但精度高。先用向量检索快速拉出 Top-20 或 Top-50 候选，再用 Reranking 模型对候选做精细排序，最终只保留 Top-3 到 Top-5 给模型生成答案。

为什么向量检索不够精确？因为 Embedding 是把整段文本压缩成一个向量，压缩过程必然丢失细节。Reranking 模型不同，它同时看用户问题和候选文档的每一个词，逐词比对理解两者关系。信息量大得多，判断自然更准。

Reranking 的加入对 RAG 效果提升非常显著。我经手的项目里，加 Reranking 后准确率平均提升 15%-30%。但代价是增加了一步计算延迟，大约 50-200ms。这个延迟用户基本感知不到，值得投入。

PM 参与选型时关注两个指标，排序质量用 NDCG 衡量，越高越好；推理延迟不能超过 200ms，超了体验会受影响。

33 PART 💡 Hybrid Search 混合搜索

用户搜 QWL-2024-0358 号订单的退款进度，你的向量检索返回了一堆关于退款流程的通用文档，就是找不到那个具体订单。因为向量搜索擅长语义匹配，不擅长精确匹配特定编号和关键词。

纯向量搜索做语义理解强但关键词匹配弱。纯关键词搜索反过来。Hybrid Search 就是两个都用然后合并结果。

做法，同一个查询同时跑两条路。第一条，向量检索走 Embedding 相似度搜索。第二条，关键词检索走 BM25 或传统倒排索引。两条路各返回一批结果，通过 RRF 或加权融合合并成一份排序列表。

混合搜索对 RAG 效果的提升立竿见影。包含具体实体的查询准确率通常能提升 20%-40%。原因很简单，订单号、产品型号、人名这些精确匹配场景，关键词搜索天然擅长，向量搜索在这类场景下经常失灵。

PM 在做需求时要问，你的用户会搜什么？搜自然语言描述的问题，向量检索就够。搜具体编号或精确条件的，必须混合搜索。绝大部分生产环境建议默认上混合搜索。

34 PART 💡 Knowledge Graph 知识图谱

你的 RAG 只靠向量检索，用户问这个产品的竞品是什么能答。但用户问这个竞品的优势是什么在我们的客户群里会产生什么影响，单纯检索很难把这几层关系串起来。因为向量数据库里存的是孤立的文档段，不理解实体之间的关系。

知识图谱 的核心不是存信息 ，是存关系。它用实体-关系-实体的三元组结构来组织知识。比如产品 A-竞品-产品 B 产品 B-优势-价格低客户群 X-偏好-低价。这种结构化的关系存储让系统能做多跳推理，从 A 找到 B，从 B 找到特点，从特点匹配到客户群影响。

知识图谱 +RAG 的组合叫 GraphRAG，它把向量检索和图谱推理结合起来。简单事实查询走向量检索，涉及多跳关系的复杂查询走 知识图谱 路径。

但 知识图谱 有个 PM 必须面对的问题，构建和维护成本高。从非结构化文档里提取实体和关系需要 NER 和关系抽取模型，准确率不完美需要人工校准。图谱更新时新实体和关系的标注也需要持续投入。

我一般建议，业务领域实体关系固定且明确的场景再上 知识图谱 ，比如医疗、法律、金融。领域知识变化快或关系不清晰的，先把向量 RAG 做好别急着上图谱。

35 PART 💡 知识库建设

你们团队花两周整理了 500 份文档丢进 RAG 知识库，上线后效果稀烂。不是 RAG 技术有问题，是你们的文档本身就不适合做 RAG 的素材。格式混乱、内容重复、过期信息一堆。

很多 PM 以为知识库建设就是把文档导进去。这是最常见的误解。RAG 的天花板不是模型能力，是知识库质量。你的文档质量有多高，RAG 效果的上限就有多高。

知识库建设三个核心环节。 Step 一 数据治理 ，文档去重、去噪、更新过期内容、统一格式。这步最花时间也最没技术含量，但跳过了后面全白做。 Step 二 结构化处理 ，给文档加标签、加元数据、按主题分类，让检索时能精准定位。 Step 三 质量评估 ，建一套评测集定期测试知识库的覆盖率和准确率，发现盲区及时补充。

还有个很多团队忽略的事，文档的写作方式也要为 RAG 优化。传统文档写给人看，上下文在读者脑子里。RAG 文档需要每个段落尽量自包含，不依赖上下文就能看懂。因为 RAG 检索出来的是单独段落，上下文已经丢了。

我有个经验公式，知识库建设占整个 RAG 项目投入的 40%以上。如果你在这块只花了 10%的时间，效果大概率很差。

36 PART 💡 文档解析

你们公司有上千份 PDF 合同文档要导入知识库，直接用解析工具一转换，发现表格全乱了、页眉页脚混进正文里、扫描件根本没识别到文字。RAG 效果稀烂，问题不在检索也不在模型，在于第一步的 文档解析 就出了问题。

文档解析 是 RAG 流水线的起点，也是最容易被轻视的环节。解析质量差，后面所有步骤都是在垃圾数据上做无用功。

不同格式的 文档解析 难度完全不同。纯文本的 Markdown 和 TXT 最简单直接读。结构化的 Word 和 HTML 难度中等，主要处理好标题层级和格式信息。PDF 是最头疼的， 因为 PDF 本质上是一种排版格式而不是文本格式 ，同一段文字可能被拆在不同的文本块里。扫描件更是文字图像混排，需要先 OCR 再解析。

三个核心挑战。 Step 一 表格识别 ，表格在 PDF 里可能是由大量独立文本框拼成的，普通解析工具会把表格内容乱序输出。 Step 二 多栏排版 ，两栏三栏的文档，解析时容易把左右栏的内容混在一起。 Step 三 图文混排 ，带图片的技术文档，图片里的关键信息需要 OCR 提取。

我的选型建议，文本类文档用开源的 Unstructured 或 LlamaIndex 的解析器就够。复杂 PDF 和扫描件用专门的文档智能模型。无论用什么工具，解析完必须抽样人工检查，错误率超过 5%就换方案。

37 PART 💡 Grounding 接地

用户问 2025 年 iPhone 16S 的发售日期是什么时候，你的 AI 信誓旦旦回答了一个日期。但这个日期是错的，而且 AI 没有标注任何来源。用户信了，在朋友圈传播了，被打脸后来投诉你的产品不靠谱。

Grounding 就是让 AI 回答有据可查。核心要求两点， Step 一 AI 的回答必须基于可验证的数据源 ，而不是凭模型记忆编。 Step 二 回答中要标注来源信息 ，用户能追溯验证。

为什么需要 Grounding？因为大模型的知识有截止日期，对训练数据之后的事实一无所知但还会自信地编答案。Grounding 的做法是让模型在回答前先检索最新的数据源，基于检索到的真实信息来生成回答，并在回答中引用来源。

RAG 本质上就是一种 Grounding 手段 。但 Grounding 不止 RAG，还包括，实时搜索引擎接入、数据库查询、API 调用获取实时数据。Google 的搜索增强生成就是一个 Grounding 的典型应用，先搜索再回答再标注来源。

PM 需要在产品里做好信任度设计。有 Grounding 支撑的回答标注来源、展示引用链接。没有 Grounding 的回答要明确提示以下内容由 AI 生成，未经验证。这不是可有可无的功能，是产品信任的基础设施。

38 PART💡 Workflow 工作流

你的 Agent 太自由了，用户说帮我写一份竞品分析报告，Agent 想到哪做到哪，先搜了竞品 A 再搜了竞品 C，漏了竞品 B，格式也不统一。输出不稳定，有时候很好有时候很差。

很多 PM 以为 Agent 越自主越好。不是的。在需要稳定输出的业务场景里，用预定义的 Workflow 比让 Agent 自由规划效果好得多。

Workflow 的做法是把复杂任务拆成固定的步骤序列，每一步的输入输出和逻辑都是预先定义好的。比如竞品分析，第一步搜索竞品列表 → 第二步逐个提取产品信息 → 第三步做对比表格 → 第四步写分析结论。每一步用什么工具、用什么 Prompt、输出什么格式，全部事先定义好。

Workflow vs Agent 的选择标准很简单。如果任务步骤固定、业务规则明确、错一步代价很大，用 Workflow。如果任务步骤不可预测、需要动态决策、探索性强，用 Agent。绝大部分企业落地场景适合 Workflow，因为稳定可控比灵活重要。

成熟的 AI 产品通常是混合架构，主流程用 Workflow 保证可控，个别需要灵活判断的节点嵌入 Agent 能力。Dify、LangFlow、Coze 这类平台都在做可视化的 Workflow 编排，PM 了解这些工具能大幅提升方案设计效率。

39 PART 💡 Multi-Agent 多智能体

你让一个 Agent 同时负责客服、数据分析、内容生成三个任务，结果三个都做得半吊子。Prompt 巨长，工具选择频繁出错，效果远不如三个独立的专人各管各的。

一个 Agent 干所有事这条路已经被证明走不通。 Multi-Agent 的核心思路是分工 ，每个 Agent 只负责一个垂直领域，做深做精，然后通过协调机制协同工作。

主流架构两种。第一种，Orchestrator 模式，有一个协调者 Agent 负责理解用户需求、拆分任务、分发给对应的专家 Agent，收集各 Agent 结果后汇总输出。适合任务分界明确的场景。第二种，讨论模式，多个 Agent 围绕同一个问题各抒己见互相评审，最后综合出最佳方案。适合需要多角度分析的场景。

PM 设计 Multi-Agent 系统要定义四件事。 Step 一 每个 Agent 的职责边界 ，。 Step 二 Agent 之间的通信协议 ，。 Step 三 任务路由规则 ，。 Step 四 冲突解决机制 ，。如果两个 Agent 给出矛盾的结果怎么处理，这必须事先定义好。

我做过的项目里最有效的 Multi-Agent 结构是三层，顶层一个 Router Agent 做 意图识别 和任务分发，中间层 N 个垂直 Agent 各管一个业务场景，底层共享工具池。简单清晰，好维护。

40 PART 💡 Planning 规划能力

你让 Agent 做一个复杂任务，结果它上来就直接开干，没有先想好步骤和顺序。做到一半发现缺少前置条件需要的信息，只能返回来重新开始。整个过程低效混乱，用户等了两分钟得到一个残缺的结果。

Agent 的规划能力是它和简单工具最大的区别，也是当前技术最薄弱的环节。

规划能力包含三个层次。第一层，任务分解，把一个复杂目标拆成多个可执行的子任务。第二层，依赖排序，确定子任务的先后顺序和依赖关系，哪些可以并行哪些必须串行。第三层，动态调整，执行过程中某一步失败了，重新规划后续步骤而不是直接崩溃。

当前大模型的规划能力依然不够可靠。研究表明在复杂多步任务上，纯靠模型自主规划的成功率只有 30%-50%。提升方法有两个方向， Step 一 预定义骨架 ，给出任务类型对应的执行计划模板，让模型在模板基础上微调，而不是从零开始规划。 Step 二 思维链强化 ，要求模型先输出完整的执行计划再开始执行，计划不合理就重新生成。

PM 做 Agent 产品，我建议先把用户最常见的 10 种任务类型对应的执行计划模板整理出来。让模型 90%的场景走模板，只有 10%的场景需要自由规划。这样可靠性会高很多。

41 PART 💡 Memory 记忆机制

用户上周告诉你的 AI 助手我对坚果过敏，这周用户问推荐几个零食，AI 推荐了一堆坚果类零食。用户火了，我都说了过敏你还推荐？用户觉得你的 AI 是白痴。

上下文管理只管当前对话，Memory 管的是跨会话的长期记忆。用户关了页面再打开，上一次对话的信息全丢了。如果你不主动设计记忆机制，AI 每次都像失忆一样从头开始。

Memory 的三层架构。第一层，工作记忆，当前对话的上下文，通过消息列表管理，关闭会话就清空。第二层，短期记忆，近期几次会话的关键信息摘要，存在数据库里，保留最近 7 到 30 天。第三层，长期记忆，用户的固定属性和偏好，比如过敏信息、角色设定、使用习惯，永久存储。

PM 的核心设计决策，什么信息值得记住、存多久、冲突了怎么办。用户上个月说不喜欢蓝色，这个月说喜欢蓝色，记哪个？必须有更新规则。用户说了隐私信息，要不要记？必须给用户查看和删除记忆的能力。

记忆的隐私合规问题不能忽视。欧盟 GDPR 和国内个保法都要求用户有权查看和删除平台存储的个人数据。AI 记忆功能等于存储个人信息，必须有完善的隐私管理机制。

42 PART 💡 ReAct 推理与行动

你让 Agent 规划一次出差行程，Agent 没做任何调查就直接生成了一份行程单。机票价格是编的，酒店是查不到的，餐厅已经关门了。Agent 在没有任何真实信息的情况下强行输出了一份看起来完整的答案。

ReAct 是解决这个问题的框架，全称 Reasoning and Acting。核心思路，让 Agent 在思考和行动之间交替进行，先想再做再看再想。

传统做法是一步到位，用户输入 → 模型直接输出结果。ReAct 的做法是多步循环。第一步，Thought 推理，用户要订北京到上海的行程，我需要先查航班信息。第二步，Action 行动，调用航班查询 API。第三步，Observation 观察，拿到查询结果看到几个航班选项。第四步，再 Thought，有直飞和中转两个选择，直飞价格偏高但节省时间。循环往复直到任务完成。

这个框架的好处，每个行动都基于真实的外部信息而不是模型凭空编造。每一步的推理链路清晰可追溯，出错了能定位是哪一步想歪了或者工具调错了。

但 ReAct 的延迟是个问题。每次循环包含一次模型推理加一次工具调用，复杂任务可能循环 5-10 次，总延迟可能到 30 秒以上。PM 需要在体验上设计好进度反馈和分步展示。

43 PART 💡 Tool Use 工具使用

你的 AI 助手口才很好但毫无实际能力。用户说帮我查一下今天的天气，AI 回答我无法获取实时天气数据。用户说帮我算一下这个表格的总和，AI 对着表格数字算了半天给了个错误答案，因为大模型天生不擅长精确计算。

Tool Use 就是给模型配上趁手的工具。模型不擅长计算？给它计算器。不擅长实时数据？给它搜索引擎。不擅长精确数据操作？给它代码执行器。

设计工具系统 PM 要考虑四个维度。 Step 一 工具粒度 ，一个工具做一件事，不要做瑞士军刀式的万能工具，粒度越细模型选择越准确。 Step 二 错误处理 ，工具超时了怎么办、返回空结果怎么办、返回格式不对怎么办。 Step 三 权限控制 ，哪些用户能用哪些工具、工具能访问哪些数据。 Step 四 成本控制 ，搜索引擎 API 每次调用都要钱，要限制单次对话的工具调用次数。

我总结的工具设计黄金法则，模型擅长的让模型做，模型不擅长的让工具做。文本理解和生成是模型的强项，精确计算、数据查询、外部操作是工具的强项。别指望模型做它不擅长的事。

44 PART 💡 Orchestrator 编排器

你的 AI 系统有五个 Agent、十几个工具、三套知识库，但没有一个统一的调度中心。用户发一条消息，系统不知道该交给谁处理，一会让客服 Agent 回答，一会让搜索 Agent 回答，结果互相矛盾用户一头雾水。

Orchestrator 就是整个 AI 系统的总调度。用户请求进来，Orchestrator 负责理解意图、选择合适的 Agent 或 Workflow 执行、协调多个组件的调用顺序、最终汇总结果返回用户。

设计 Orchestrator PM 需要定义三层逻辑。第一层，意图路由，用户这句话属于哪个业务场景，该交给哪个 Agent 处理。第二层，执行编排，复杂请求可能需要多个 Agent 协作，先后顺序和数据传递怎么走。第三层，结果融合，多个 Agent 都有输出时，怎么合并成一个给用户。

我带过的项目里，Orchestrator 的设计花了整个项目 30%的时间。很多 PM 把精力全花在单个 Agent 的 Prompt 优化上，忽略了 Orchestrator 的重要性。一个优秀的 Orchestrator 能让中等水平的 Agent 系统发挥出优秀的效果。

实操中 Orchestrator 自身也是一个 LLM 驱动的模块，它的 Prompt 定义了所有 Agent 的能力描述和路由规则。所以 Orchestrator 的 Prompt 是整个系统里最关键的 Prompt。

45 PART 💡 TTS 文本转语音

你做了一个 AI 客服对话系统，文字回复效果很好，老板说加个语音功能。你找了个 TTS 服务接上，生成的语音像读课文一样毫无感情，用户说感觉在跟机器对话，体验反而变差了。

TTS 不只是把文字读出来这么简单。现代 TTS 需要处理语气、停顿、重音、情感、语速变化。同样一句好的没问题，客服场景应该热情积极，严肃场景应该沉稳可靠。

当前 TTS 技术分两代。旧 T 代基于拼接和参数合成，声音机械感重，情感表现差。新一代基于神经网络的端到端合成，可以做到非常自然的语调变化和情感表达，部分场景已经接近真人。

PM 关注三个指标。 Step 一 自然度 MOS 评分 ，5 分制，4 分以上才像真人。 Step 二 首包延迟 ，用户等多久才听到第一个字，超过 300ms 会有明显停顿感。 Step 三 音色定制 ，是否支持用少量录音克隆特定音色，这对品牌形象建设很重要。

一个容易忽略的问题，TTS 的文本预处理。数字、英文缩写、标点符号都会影响发音。100 应该读一百还是一零零？PM 读 PM 还是产品经理？这些边界 Case 需要定义预处理规则。

46 PART 💡 ASR 语音识别

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

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

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

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

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

47 PART 💡 OCR 光学字符识别

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

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

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

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

48 PART 💡 Text-to-Image 文生图

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

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

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

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

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

49 PART 💡 NER 命名实体识别

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

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

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

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

50 PART 💡 Intent Recognition 意图识别

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

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

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

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

51 PART 💡 Precision 精确率

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

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

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

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

52 PART 💡 Recall 召回率

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

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

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

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

53 PART 💡 Bad Case 分析

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

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

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

PM 每周花 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 消耗量。

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

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

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。其中排队等待在高峰期可能成为瓶颈，模型推理时间和输出长度正相关。

PM 能做的优化。 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 和免费用户的配额不同。

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

59 PART 💡 灰度发布

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

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

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

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

60 PART 💡 数据飞轮

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

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

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

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

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