Chunking 文档分块你的 RAG 知识库上线了用户问一个具体问题系统返回了一段莫名其妙的内容。一查发现检索到的文档片段被切在了一个句子中间上半句话在一个块里下半句在另一个块里。模型看到半句话当然答不到点上。文档分块看着简单按字数切就行了。恰恰就是这个按字数切害了很多 RAG 项目。分块的核心矛盾块太大语义太杂检索时相似度分数被不相关内容拉低。块太小语义不完整模型拿到残缺信息无法正确回答。最优块大小取决于你的文档结构和业务场景没有万能参数。三种主流分块策略。Step 一固定大小切分每 500 字切一块加 50 字重叠。简单暴力但容易切断语义。Step 二按结构切分按文档的标题、段落、章节等结构切分。保留了文档逻辑但对文档格式有要求。Step 三语义分块用 Embedding 计算相邻句子的语义相似度相似度骤降的地方就是语义边界在边界处切分。效果最好但计算成本最高。实操建议先按文档结构切找不到结构的部分用固定大小重叠来兜底。块大小从 300-500 字开始测在你的评测集上跑一遍看检索命中率。切分后必须人工抽查 50-100 个块看有没有语义被切断的。32PART 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超了体验会受影响。33PART Hybrid Search 混合搜索用户搜 QWL-2024-0358 号订单的退款进度你的向量检索返回了一堆关于退款流程的通用文档就是找不到那个具体订单。因为向量搜索擅长语义匹配不擅长精确匹配特定编号和关键词。纯向量搜索做语义理解强但关键词匹配弱。纯关键词搜索反过来。Hybrid Search 就是两个都用然后合并结果。做法同一个查询同时跑两条路。第一条向量检索走 Embedding 相似度搜索。第二条关键词检索走 BM25 或传统倒排索引。两条路各返回一批结果通过 RRF 或加权融合合并成一份排序列表。混合搜索对 RAG 效果的提升立竿见影。包含具体实体的查询准确率通常能提升 20%-40%。原因很简单订单号、产品型号、人名这些精确匹配场景关键词搜索天然擅长向量搜索在这类场景下经常失灵。PM 在做需求时要问你的用户会搜什么搜自然语言描述的问题向量检索就够。搜具体编号或精确条件的必须混合搜索。绝大部分生产环境建议默认上混合搜索。34PART Knowledge Graph 知识图谱你的 RAG 只靠向量检索用户问这个产品的竞品是什么能答。但用户问这个竞品的优势是什么在我们的客户群里会产生什么影响单纯检索很难把这几层关系串起来。因为向量数据库里存的是孤立的文档段不理解实体之间的关系。知识图谱的核心不是存信息是存关系。它用实体-关系-实体的三元组结构来组织知识。比如产品 A-竞品-产品 B 产品 B-优势-价格低客户群 X-偏好-低价。这种结构化的关系存储让系统能做多跳推理从 A 找到 B从 B 找到特点从特点匹配到客户群影响。知识图谱RAG 的组合叫 GraphRAG它把向量检索和图谱推理结合起来。简单事实查询走向量检索涉及多跳关系的复杂查询走知识图谱路径。但知识图谱有个 PM 必须面对的问题构建和维护成本高。从非结构化文档里提取实体和关系需要 NER 和关系抽取模型准确率不完美需要人工校准。图谱更新时新实体和关系的标注也需要持续投入。我一般建议业务领域实体关系固定且明确的场景再上知识图谱比如医疗、法律、金融。领域知识变化快或关系不清晰的先把向量 RAG 做好别急着上图谱。35PART 知识库建设你们团队花两周整理了 500 份文档丢进 RAG 知识库上线后效果稀烂。不是 RAG 技术有问题是你们的文档本身就不适合做 RAG 的素材。格式混乱、内容重复、过期信息一堆。很多 PM 以为知识库建设就是把文档导进去。这是最常见的误解。RAG 的天花板不是模型能力是知识库质量。你的文档质量有多高RAG 效果的上限就有多高。知识库建设三个核心环节。Step 一数据治理文档去重、去噪、更新过期内容、统一格式。这步最花时间也最没技术含量但跳过了后面全白做。Step 二结构化处理给文档加标签、加元数据、按主题分类让检索时能精准定位。Step 三质量评估建一套评测集定期测试知识库的覆盖率和准确率发现盲区及时补充。还有个很多团队忽略的事文档的写作方式也要为 RAG 优化。传统文档写给人看上下文在读者脑子里。RAG 文档需要每个段落尽量自包含不依赖上下文就能看懂。因为 RAG 检索出来的是单独段落上下文已经丢了。我有个经验公式知识库建设占整个 RAG 项目投入的 40%以上。如果你在这块只花了 10%的时间效果大概率很差。36PART 文档解析你们公司有上千份 PDF 合同文档要导入知识库直接用解析工具一转换发现表格全乱了、页眉页脚混进正文里、扫描件根本没识别到文字。RAG 效果稀烂问题不在检索也不在模型在于第一步的文档解析就出了问题。文档解析是 RAG 流水线的起点也是最容易被轻视的环节。解析质量差后面所有步骤都是在垃圾数据上做无用功。不同格式的文档解析难度完全不同。纯文本的 Markdown 和 TXT 最简单直接读。结构化的 Word 和 HTML 难度中等主要处理好标题层级和格式信息。PDF 是最头疼的因为 PDF 本质上是一种排版格式而不是文本格式同一段文字可能被拆在不同的文本块里。扫描件更是文字图像混排需要先 OCR 再解析。三个核心挑战。Step 一表格识别表格在 PDF 里可能是由大量独立文本框拼成的普通解析工具会把表格内容乱序输出。Step 二多栏排版两栏三栏的文档解析时容易把左右栏的内容混在一起。Step 三图文混排带图片的技术文档图片里的关键信息需要 OCR 提取。我的选型建议文本类文档用开源的 Unstructured 或 LlamaIndex 的解析器就够。复杂 PDF 和扫描件用专门的文档智能模型。无论用什么工具解析完必须抽样人工检查错误率超过 5%就换方案。37PART Grounding 接地用户问 2025 年 iPhone 16S 的发售日期是什么时候你的 AI 信誓旦旦回答了一个日期。但这个日期是错的而且 AI 没有标注任何来源。用户信了在朋友圈传播了被打脸后来投诉你的产品不靠谱。Grounding 就是让 AI 回答有据可查。核心要求两点Step 一AI 的回答必须基于可验证的数据源而不是凭模型记忆编。Step 二回答中要标注来源信息用户能追溯验证。为什么需要 Grounding因为大模型的知识有截止日期对训练数据之后的事实一无所知但还会自信地编答案。Grounding 的做法是让模型在回答前先检索最新的数据源基于检索到的真实信息来生成回答并在回答中引用来源。RAG 本质上就是一种 Grounding 手段。但 Grounding 不止 RAG还包括实时搜索引擎接入、数据库查询、API 调用获取实时数据。Google 的搜索增强生成就是一个 Grounding 的典型应用先搜索再回答再标注来源。PM 需要在产品里做好信任度设计。有 Grounding 支撑的回答标注来源、展示引用链接。没有 Grounding 的回答要明确提示以下内容由 AI 生成未经验证。这不是可有可无的功能是产品信任的基础设施。38PART 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 了解这些工具能大幅提升方案设计效率。39PART 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 各管一个业务场景底层共享工具池。简单清晰好维护。40PART Planning 规划能力你让 Agent 做一个复杂任务结果它上来就直接开干没有先想好步骤和顺序。做到一半发现缺少前置条件需要的信息只能返回来重新开始。整个过程低效混乱用户等了两分钟得到一个残缺的结果。Agent 的规划能力是它和简单工具最大的区别也是当前技术最薄弱的环节。规划能力包含三个层次。第一层任务分解把一个复杂目标拆成多个可执行的子任务。第二层依赖排序确定子任务的先后顺序和依赖关系哪些可以并行哪些必须串行。第三层动态调整执行过程中某一步失败了重新规划后续步骤而不是直接崩溃。当前大模型的规划能力依然不够可靠。研究表明在复杂多步任务上纯靠模型自主规划的成功率只有 30%-50%。提升方法有两个方向Step 一预定义骨架给出任务类型对应的执行计划模板让模型在模板基础上微调而不是从零开始规划。Step 二思维链强化要求模型先输出完整的执行计划再开始执行计划不合理就重新生成。PM 做 Agent 产品我建议先把用户最常见的 10 种任务类型对应的执行计划模板整理出来。让模型 90%的场景走模板只有 10%的场景需要自由规划。这样可靠性会高很多。41PART Memory 记忆机制用户上周告诉你的 AI 助手我对坚果过敏这周用户问推荐几个零食AI 推荐了一堆坚果类零食。用户火了我都说了过敏你还推荐用户觉得你的 AI 是白痴。上下文管理只管当前对话Memory 管的是跨会话的长期记忆。用户关了页面再打开上一次对话的信息全丢了。如果你不主动设计记忆机制AI 每次都像失忆一样从头开始。Memory 的三层架构。第一层工作记忆当前对话的上下文通过消息列表管理关闭会话就清空。第二层短期记忆近期几次会话的关键信息摘要存在数据库里保留最近 7 到 30 天。第三层长期记忆用户的固定属性和偏好比如过敏信息、角色设定、使用习惯永久存储。PM 的核心设计决策什么信息值得记住、存多久、冲突了怎么办。用户上个月说不喜欢蓝色这个月说喜欢蓝色记哪个必须有更新规则。用户说了隐私信息要不要记必须给用户查看和删除记忆的能力。记忆的隐私合规问题不能忽视。欧盟 GDPR 和国内个保法都要求用户有权查看和删除平台存储的个人数据。AI 记忆功能等于存储个人信息必须有完善的隐私管理机制。42PART ReAct 推理与行动你让 Agent 规划一次出差行程Agent 没做任何调查就直接生成了一份行程单。机票价格是编的酒店是查不到的餐厅已经关门了。Agent 在没有任何真实信息的情况下强行输出了一份看起来完整的答案。ReAct 是解决这个问题的框架全称 Reasoning and Acting。核心思路让 Agent 在思考和行动之间交替进行先想再做再看再想。传统做法是一步到位用户输入 → 模型直接输出结果。ReAct 的做法是多步循环。第一步Thought 推理用户要订北京到上海的行程我需要先查航班信息。第二步Action 行动调用航班查询 API。第三步Observation 观察拿到查询结果看到几个航班选项。第四步再 Thought有直飞和中转两个选择直飞价格偏高但节省时间。循环往复直到任务完成。这个框架的好处每个行动都基于真实的外部信息而不是模型凭空编造。每一步的推理链路清晰可追溯出错了能定位是哪一步想歪了或者工具调错了。但 ReAct 的延迟是个问题。每次循环包含一次模型推理加一次工具调用复杂任务可能循环 5-10 次总延迟可能到 30 秒以上。PM 需要在体验上设计好进度反馈和分步展示。43PART Tool Use 工具使用你的 AI 助手口才很好但毫无实际能力。用户说帮我查一下今天的天气AI 回答我无法获取实时天气数据。用户说帮我算一下这个表格的总和AI 对着表格数字算了半天给了个错误答案因为大模型天生不擅长精确计算。Tool Use 就是给模型配上趁手的工具。模型不擅长计算给它计算器。不擅长实时数据给它搜索引擎。不擅长精确数据操作给它代码执行器。设计工具系统 PM 要考虑四个维度。Step 一工具粒度一个工具做一件事不要做瑞士军刀式的万能工具粒度越细模型选择越准确。Step 二错误处理工具超时了怎么办、返回空结果怎么办、返回格式不对怎么办。Step 三权限控制哪些用户能用哪些工具、工具能访问哪些数据。Step 四成本控制搜索引擎 API 每次调用都要钱要限制单次对话的工具调用次数。我总结的工具设计黄金法则模型擅长的让模型做模型不擅长的让工具做。文本理解和生成是模型的强项精确计算、数据查询、外部操作是工具的强项。别指望模型做它不擅长的事。44PART 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。45PART TTS 文本转语音你做了一个 AI 客服对话系统文字回复效果很好老板说加个语音功能。你找了个 TTS 服务接上生成的语音像读课文一样毫无感情用户说感觉在跟机器对话体验反而变差了。TTS 不只是把文字读出来这么简单。现代 TTS 需要处理语气、停顿、重音、情感、语速变化。同样一句好的没问题客服场景应该热情积极严肃场景应该沉稳可靠。当前 TTS 技术分两代。旧 T 代基于拼接和参数合成声音机械感重情感表现差。新一代基于神经网络的端到端合成可以做到非常自然的语调变化和情感表达部分场景已经接近真人。PM 关注三个指标。Step 一自然度 MOS 评分5 分制4 分以上才像真人。Step 二首包延迟用户等多久才听到第一个字超过 300ms 会有明显停顿感。Step 三音色定制是否支持用少量录音克隆特定音色这对品牌形象建设很重要。一个容易忽略的问题TTS 的文本预处理。数字、英文缩写、标点符号都会影响发音。100 应该读一百还是一零零PM 读 PM 还是产品经理这些边界 Case 需要定义预处理规则。46PART ASR 语音识别用户对着麦克风说了一段话你的 ASR 把帮我订一张去三亚的机票识别成了帮我订一张去三丫的机票。订票 Agent 查不到三丫这个地方整个流程直接挂了。ASR 好坏直接决定了语音交互链路的天花板。后面的 NLU、意图识别、Agent 执行全都依赖 ASR 的准确输出。现代 ASR 基于端到端的深度学习模型能实时把语音流转成文字。但准确率和场景强相关。安静办公室里的普通话识别率可以到 98%以上但加上方言、噪音、语速快、专业术语准确率可能降到 80%甚至更低。PM 做语音产品必须关注三个场景化指标。Step 一字错率 WER核心准确率指标。Step 二实时率 RTF处理 1 秒语音需要多少秒计算超过 0.5 就会有延迟感。Step 三领域适配你的业务有大量专有名词和行话时通用 ASR 的识别率会大打折扣需要热词表或领域微调。有个设计建议ASR 输出一定要加后处理。加标点、数字归一化、敏感词过滤、同音词纠错。这步不做即使 ASR 识别率很高给到 NLU 的文本格式也是乱的。47PART OCR 光学字符识别用户拍了一张发票照片上传你的系统需要自动提取金额、日期、发票号。传统 OCR 只能识别打印体的清晰文字拍照时角度稍微歪一点、光线暗一些识别率就崩了。OCR 不只是把图片里的字提取出来。现代 OCR 需要做四件事。Step 一文字检测在图片里找到文字区域的位置。Step 二文字识别把检测到的区域里的文字识别出来。Step 三结构理解理解文字的位置关系和逻辑结构比如表格里哪个数字对应哪个字段。Step 四后处理纠错和格式化。现在的 OCR 演进方向是从看文字到理解版面。新一代的文档智能模型能同时理解文字内容和版面布局自动识别标题、正文、表格、公式的结构关系。这对复杂文档的自动化处理非常关键。PM 做 OCR 相关产品要先确认场景难度。文本清晰打印体的标准文档用通用 OCR 就够。手写体、弯曲变形、低光照这些难场景需要专门的 OCR 模型。票据证照类需要专门训练的版面理解模型。难度搞错了选型就会错。48PART Text-to-Image 文生图设计师工期排不上来你想用 AI 生成产品配图。输入了一句描述生成的图片里人物多了一根手指、文字变成了乱码、品牌 Logo 完全变形。老板说这图不能用。所有人都被文生图 Demo 里那些华丽的图片震撼过但真正用到产品里才发现大部分生成结果不能直接商用。文生图的底层是扩散模型从完全的随机噪声开始根据文字描述一步步去噪最终生成图片。当前主流模型在以下场景效果很好风景、插画、艺术创作、概念图。在以下场景依然不稳定人手细节、精确文字渲染、品牌 Logo、多物体精确空间关系。PM 做 AI 配图功能要提前定义验收标准。哪些程度的瑕疵可以接受、哪些必须人工修正。比如社交媒体配图对精度要求不高AI 直出可以接受。但产品宣传图对品牌一致性要求很高AI 只能出初稿还是得设计师精修。选型关注三点生成质量、可控性和版权。可控性是关键差异ControlNet 这类技术让你能通过线稿、姿势、深度图来控制生成结果大幅提升实用性。版权问题也不能忽视部分模型的训练数据存在版权争议商用需确认许可条款。49PART NER 命名实体识别用户说帮我订明天从北京到上海的高铁你的系统需要从这句话里提取出三个信息时间是明天出发地是北京目的地是上海。这个提取过程就是 NER。NER 全称 Named Entity Recognition从自然语言文本中识别并分类出预定义的实体类型。常见实体类型人名、地名、时间、金额、组织名、产品名。在 AI 产品里NER 是连接用户自然语言和结构化操作的桥梁。为什么不直接让大模型做 NER可以但有坑。大模型做 NER 的优势是泛化能力强、不需要标注数据、能理解复杂上下文。劣势是推理成本高、速度慢、在精确格式要求下不够稳定。高频场景用专门的 NER 小模型成本低速度快低频场景或复杂场景用大模型做。PM 设计涉及 NER 的功能时要先列出业务需要的全部实体类型和标准格式。明天要转成具体日期、北京要转成标准城市编码。这些转换规则不是模型自动知道的需要你定义好告诉开发。漏定义了一个实体类型对应的业务功能就无法触发。50PART Intent Recognition 意图识别用户说太贵了是想砍价还是要取消订单还是只是吐槽你的 AI 客服把每一个说太贵了的用户都转到退款流程投诉反而多了。因为大部分用户只是在表达情绪根本不想退款。意图识别是 NLU 的核心任务。用户每一句话的背后都有一个真实意图AI 要做的是准确判断出这个意图然后触发对应的处理流程。设计意图识别系统 PM 要做三件事。Step 一定义意图列表。穷举用户可能的意图并分类咨询、投诉、下单、退款、闲聊、超出范围。每个意图对应一个处理流程。Step 二处理模糊意图。用户的话经常是模糊的太贵了可能映射到多个意图。需要定义置信度阈值高于 0.8 直接触发流程0.5-0.8 追问确认低于 0.5 兜底到通用回复。Step 三处理多意图。用户一句话可能包含两个意图我要退掉 A 商品然后换成 B 商品退货和购买两个意图并存。我的经验是意图识别的准确率比模型回答的质量更重要。如果意图就分错了后面再怎么优化回答都是答非所问。在需求阶段就把意图列表和优先级排好比上线后反复调模型有效得多。51PART Precision 精确率你的 AI 风控系统把 1000 个用户标记为疑似欺诈风控团队逐个核查后发现只有 200 个真的有问题800 个是正常用户被误判。那 800 个用户的账户被冻结投诉电话打爆了客服中心。精确率衡量的是别乱报。计算方式模型预测为正的结果里有多少真正是对的。上面的例子精确率只有 20%意味着每标记 5 个欺诈就有 4 个是冤枉的。风控场景最在意精确率。你把一个正常用户标为欺诈这个误报的代价比漏掉一个真欺诈可能还大用户投诉、法律风险、品牌伤害全来了。所以风控宁可漏几个也不能乱报。PM 要做的核心决策你的场景更怕误报还是更怕漏报怕误报就优先精确率提高判定阈值让模型只在高确信时才标记。但代价是会漏掉更多真实案例召回率下降。两个不可兼得必须取舍不存在两全其美的方案。52PART Recall 召回率你的 AI 内容审核系统审核了 1 万条用户评论标记删除了 500 条违规内容。但人工抽检发现另外还有 300 条违规内容漏掉了。那 300 条里有涉及人身攻击和违法信息的被用户截图举报平台被监管部门约谈。召回率衡量的是别漏掉。计算方式实际为正的结果里有多少被模型找到了。800 条实际违规内容只找到 500 条召回率 62.5%漏了近四成。客服场景重召回用户投诉你没发现问题恶化后损失更大。医疗场景更重召回漏诊比误诊后果严重得多。内容安全场景也重召回漏一条违规内容被监管发现就是事故。F1 Score 是精确率和召回率的调和平均当你两个都想兼顾时作为综合指标。但实际产品设计中很少有场景真的两个一样重要。PM 要根据业务风险做明确取舍风控重精确、客服重召回、内容安全重召回、搜索推荐看场景。先确定主要指标次要指标设一个底线就够了。53PART Bad Case 分析团队每周例会上讨论模型效果怎么优化大家凭感觉提了一堆方向Prompt 改了十几版效果忽好忽差。折腾一个月发现根本没改到点上因为从头到尾没人去看线上到底错在哪里。Bad Case 分析是 AI 产品优化的核心方法论。不是拍脑袋改 Prompt而是用数据说话。标准流程五步。第一步收集从线上日志按时间周期采样加上用户点踩或负反馈标记的样本每周至少拉 200-500 条。第二步分类幻觉、拒答、格式错误、逻辑错误、检索失败按大类分统计每类占比。第三步归因每类 Bad Case 的根因是什么是 Prompt 没约束住、知识库没覆盖、检索没命中、还是模型能力不够。第四步修复针对性优化Prompt 问题改 Prompt知识库问题补文档检索问题调策略。第五步验证修复后在相同样本集上验证是否解决防止改了 A 又坏了 B。PM 每周花 2 小时看 Bad Case 比花 10 小时凭感觉调 Prompt 有效得多。因为 Bad Case 告诉你真正的问题在哪里不用猜。54PART 数据标注算法同事说微调需要 5000 条高质量标注数据你以为找几个实习生标一周就行了。结果标出来的数据一致性只有 50%同样一条数据两个人标出相反的结果。模型训练完效果比没微调还差。数据标注看似简单实则坑极多。标注质量等于模型质量上限这个环节省不得。三个关键环节必须卡死。Step 一标注指南必须详细到每种边界 Case 都有明确判断标准不能靠标注员自行理解。正面情感和中性情感的边界在哪不写清楚每个人理解都不一样。Step 二试标校准先让 3-5 个人标 100 条计算一致性用 Kappa 系数衡量一致性低于 80%就得修改标注指南再重新试标。Step 三质检机制正式标注期间持续抽检准确率低于阈值的标注员要重新培训。成本参考简单分类标注每条 0.5-2 元复杂对话标注每条 5-20 元专业领域标注更贵。数量上微调通常需要 1000-10000 条评测集需要 500-2000 条。标注周期和成本是 AI 项目排期里最容易被低估的部分。55PART Human Evaluation 人工评测你用了 BLEU 和 ROUGE 两个自动评测指标分数都很高。上线后用户反馈回答正确但像机器人说话语气很奇怪不像人会说的话。自动指标完全没发现这些问题。BLEU、ROUGE 这些自动评测指标只能衡量文本相似度判断不了回答好不好用、安不安全、语气合不合适。这些只有人能评。做人工评测的标准流程。第一步定义评测维度准确性、相关性、流畅度、安全性、有用性每个维度 1-5 分。第二步准备评测集500-2000 条有代表性的 Case覆盖主要业务场景和边缘 Case。第三步双盲评测同一条样本两个人独立打分计算一致性。一致性低于 0.7 说明评测标准不清晰需要重新校准。第四步汇总报告按维度统计分数找出短板。建议每次模型更新或 Prompt 大改之后都做一轮人工评测。样本量不用太大300 条覆盖主要场景就够发现 80%的问题。人工评测是自动指标的护城河补充不是替代关系。56PART API产品经理不需要会写代码。但你调大模型不是直接操作模型而是通过 API 发 HTTP 请求。如果你连 API 文档都读不懂和开发讨论技术方案时就只能旁听做不了决策。API 就是两个系统之间的通信接口。你的产品后端给大模型服务发一个请求里面包含模型名、消息内容、参数。大模型服务处理后返回结果里面包含生成的文本和 Token 消耗量。PM 需要关注的 API 知识不多但很关键。Step 一入参出参输入什么格式、输出什么格式直接影响你的产品功能设计。比如模型是否支持图片输入直接决定了你能不能做多模态功能。Step 二计费方式按 Token 还是按次输入输出是否分开计价能不能用批量接口降成本。Step 三限制每分钟最多调多少次、单次最大 Token 数、并发数限制。Step 四错误码超限返回 429、超时返回 504、服务不可用返回 503产品层怎么处理每种错误要事先定义好。你不需要会写代码但需要能看懂 API 文档并和开发讨论参数选择。这是 AI PM 和传统 PM 的关键区别之一。57PART 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 动画、分步展示、先显示摘要再展开详情。让等待变得可以接受。58PART Rate Limiting 限流你的 AI 产品上线后突然被某个科技媒体报道了流量一小时内从日常的 1000 飙到 10 万。大模型 API 的并发限制被打满所有用户都看到报错页面。公关的正面效果被产品故障抵消了。限流不是限制用户是保护系统。不做限流一次流量高峰就能让全系统瘫痪。三层限流必须规划。第一层供应商限流大模型 API 提供商对你的 API Key 有 RPM每分钟请求数和 TPM每分钟 Token 数上限超了直接返回 429 错误。第二层系统限流你自己的后端对用户请求做限流防止击穿供应商限制。第三层用户限流每个用户每天能用多少次VIP 和免费用户的配额不同。PM 必须在 PRD 里定义五件事正常负载和峰值负载各是多少、限流时用户看到什么提示不能是空白报错页面、是否支持排队机制、降级策略是什么比如临时切到更便宜更快的模型、流量突增时的自动扩容规则。这些不提前设计上线后第一次流量高峰就是事故。59PART 灰度发布你改了一个 Prompt 觉得效果更好直接全量发布。上线后发现主流场景确实变好了但有个长尾场景客诉量飙升 300%。因为新 Prompt 在那个场景里完全崩了你回滚的时候已经积累了几百条投诉。传统产品更新是确定性的新按钮在不在、新功能好不好用上线前 QA 能测清楚。AI 产品更新是概率性的模型换了一版或 Prompt 改了一段效果好不好只能在真实流量上验证。标准灰度流程5%流量放新版本 → 跑 3-7 天 → 对比核心指标准确率、满意度、延迟、成本→ 指标显著优于旧版才放量 → 10% → 30% → 50% → 100%。任何一步指标不达标就回滚到旧版本。PM 常犯的错误改了一个 Prompt 觉得效果更好就直接全量发布。任何模型层面的变更都要灰度没有例外。因为模型是概率系统你测试的 20 条 Case 效果变好了不代表线上 20 万条 Case 都变好了。灰度是唯一能兜住这个风险的手段。60PART 数据飞轮你的竞品和你用一样的模型一样的技术栈但半年后它的效果明显比你好。不是它的 PM 比你厉害是它的产品设计里从第一天就埋了数据飞轮的机制你没有。数据飞轮是 AI 产品的终极壁垒。不是你的模型比别人好是你比别人有更多更好的业务数据来持续优化模型。飞轮的四个阶段形成闭环产品上线 → 收集用户数据 → 优化模型 → 体验提升 → 吸引更多用户 → 更多数据。循环越转越快先跑起来的产品优势会越来越大。飞轮转起来的关键是 PM 要设计好数据收集机制。Step 一隐式反馈用户点了重新生成说明对上一次输出不满意。Step 二显式反馈点赞、点踩、评分。Step 三行为数据用户有没有复制使用 AI 的结果、有没有手动修改。Step 四转化数据AI 推荐的内容用户有没有点击购买。没有人主动设计这个闭环飞轮就转不起来。数据飞轮不是自然形成的是被设计出来的。PM 的工作是定义哪些数据要收集、怎么存、多久清洗一轮、怎么喂给模型优化。这件事越早做越好因为数据积累是有时间价值的。2026年AI行业最大的机会毫无疑问就在应用层字节跳动已有7个团队全速布局Agent大模型岗位暴增69%年薪破百万腾讯、京东、百度开放招聘技术岗80%与AI相关……如今超过60%的企业都在推进AI产品落地而真正能交付项目的大模型应用开发工程师****却极度稀缺落地AI应用绝对不是写几个prompt调几个API就能搞定的企业真正需要的是能搞定这三项核心能力的人✅RAG融入外部信息修正模型输出给模型装靠谱大脑✅Agent智能体让AI自主干活通过工具调用Tools环境交互多步推理完成复杂任务。比如做智能客服等等……✅微调针对特定任务优化让模型适配业务目前脉脉上有超过1000家企业发布大模型相关岗位人工智能岗平均月薪7.8w实习生日薪高达4000远超其他行业收入水平技术的稀缺性才是你「值钱」的关键具备AI能力的程序员比传统开发高出不止一截有的人早就转行AI方向拿到百万年薪AI浪潮正在重构程序员的核心竞争力现在入场仍是最佳时机我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】⭐️从大模型微调到AI Agent智能体搭建剖析AI技术的应用场景用实战经验落地AI技术。从GPT到最火的开源模型让你从容面对AI技术革新大模型微调掌握主流大模型如DeepSeek、Qwen等的微调技术针对特定场景优化模型性能。学习如何利用领域数据如制造、医药、金融等进行模型定制提升任务准确性和效率。RAG应用开发深入理解检索增强生成Retrieval-Augmented Generation, RAG技术构建高效的知识检索与生成系统。应用于垂类场景如法律文档分析、医疗诊断辅助、金融报告生成等实现精准信息提取与内容生成。AI Agent智能体搭建学习如何设计和开发AI Agent实现多任务协同、自主决策和复杂问题解决。构建垂类场景下的智能助手如制造业中的设备故障诊断Agent、金融领域的投资分析Agent等。如果你也有以下诉求快速链接产品/业务团队参与前沿项目构建技术壁垒从竞争者中脱颖而出避开35岁裁员危险期顺利拿下高薪岗迭代技术水平延长未来20年的新职业发展……那这节课你一定要来听因为留给普通程序员的时间真的不多了立即扫码即可免费预约「AI技术原理 实战应用 职业发展」「大模型应用开发实战公开课」还有靠谱的内推机会直聘权益完课后赠送大模型应用案例集、AI商业落地白皮书