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

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。这个延迟用户基本感知不到，值得投入。​

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

​

​

33​

PART​

Hybrid Search 混合搜索​

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

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

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

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

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

​

​

34​

PART​

Knowledge Graph 知识图谱​

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

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

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

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

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

​

​

35​

PART​

知识库建设​

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

很多 产品经理 以为知识库建设就是把文档导进去。这是最常见的误解。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 的典型应用，先搜索再回答再标注来源。​

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

​

​

38​

PART​

Workflow 工作流​

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

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

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

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

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

​

​

39​

PART​

Multi-Agent 多智能体​

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

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

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

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

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

​

​

40​

PART​

Planning 规划能力​

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

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

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

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

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

​

​

41​

PART​

Memory 记忆机制​

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

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

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

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

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

​

​

42​

PART​

ReAct 推理与行动​

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

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

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

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

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

​

​

43​

PART​

Tool Use 工具使用​

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

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

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

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

​

​

44​

PART​

Orchestrator 编排器​

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

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

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

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

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

​

​

45​

PART​

TTS 文本转语音​

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

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

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

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

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

​

​

​