做AI产品这行，经常收到同行的提问：我是产品经理，不懂算法，怎么和研发聊？我的答案一直很简单——从RAG入手。RAG（检索增强生成）是当前大模型落地概率最高、见效最快、可控性最强的一条技术路线，做知识库问答、智能客服、文档分析类产品的人，几乎绕不开它。但很多产品经理一听到“向量数据库”“Embedding”“重排序”就头大，觉得这是算法工程师的事。我的看法是：你可以不写代码，但必须能把RAG的数据流转链路画清楚、能把效果指标讲明白、能判断一个问题到底该优化哪一环。这篇文章就把我理解中的RAG压缩成7个核心概念，按一个产品经理真正需要掌握的颗粒度逐个拆开，顺便告诉你每个概念对应产品里的哪个体验问题。
哪怕你是零基础的小白，看完之后至少能做到三件事：第一，听研发聊方案时不再一脸懵；第二，能独立画出一张包含“切分—检索—排序—生成—评估”的完整流程图；第三，产品上线后效果不好，你能判断该找谁、该调什么，而不是只会说“效果差”。
1. 概念还没进脑子，先搞懂RAG要解决什么问题
1.1 三个让大模型产品很难用的“原生毛病”
先抛开所有技术名词，想一个场景：你做了一个智能客服机器人，替换掉原来的关键词匹配引擎。产品刚上线，用户问“我买的东西坏了，能退吗”，大模型回答得有模有样，但仔细一看，它把退换货政策里的“七天无理由”说成了“三十天包退”。为什么会这样？因为大模型本身有三个天生的毛病。
第一是幻觉。模型在训练时见过了海量文本，但它并不真正“知道”你的售后政策是什么，它是根据概率在“猜”下一段最像人话的文字，猜错了就一本正经胡说八道。第二是知识截止。哪怕它训练时看过你公司的数据，那也是几个月甚至几年前的事，而产品文档、价目表是天天变的。第三是拿不到私有数据。你的企业制度、设备操作手册、内部流程，根本不在公开互联网上，大模型没读过就是没读过。这三个毛病合在一起，就是大多数大模型产品从Demo到上线之间最难跨越的一道坎。
1.2 为什么是RAG而不是一直微调
有的团队会说：要不我们微调模型？把公司的知识库灌进去训练。微调确实能解决一部分问题，但它有三个硬伤。
一是贵。现在主流的模型动辄百亿千亿参数，一次完整微调要消耗大量算力，而且每次业务知识更新，都可能要重新训练一轮。二是慢。知识库的更新频率是按天甚至按小时算的，微调的节奏根本跟不上。三是不可解释。模型内部是个黑盒，用户问它“为什么这么回答”，没人能给出一个“你能看得到的答案来源”。而RAG的思路完全不同——它不试图让模型记住知识，而是让模型在回答时去查一份“允许翻阅的资料”，查到什么就答什么。你可以理解为开卷考试和闭卷考试的区别。闭卷考试要求你把整本教材背进脑子里，开卷考试只需要你知道去哪一页找答案。
为了直观一点，我把两种方案放在一起做了个对比，这也是我在项目里给团队汇报时常画的表：
| 对比维度 | RAG方案 | 微调方案 |
|---|---|---|
| 知识更新速度 | 换文档即可，分钟级生效 | 需要重新训练，数天到数周 |
| 实施成本 | 主要靠检索系统，成本可控 | 算力成本高，周期长 |
| 幻觉风险 | 低，答案有出处约束 | 仍有幻觉，且更隐蔽 |
| 可解释性 | 高，能回溯到原文片段 | 低，无法展示依据 |
| 适合场景 | 知识频繁变化、需要可溯源 | 领域表达风格固化、推理能力微调 |
所以我的建议是：如果产品的核心价值是“把已有的知识准确、及时地交付给用户”，那RAG几乎是你第一优先级的方案。
1.3 产品经理视角的RAG理解框架
那RAG到底是怎么工作的？我给你一个三句话版本：先把你的知识文档切成小块，存进一个“能按语义找东西”的仓库；用户提问时，系统去仓库里捞回最相关的几块资料；把资料连同问题一起塞给大模型，让模型只依据资料作答。没了，就是这么个事。
技术圈的描述是“检索增强生成”，就是Retrieval-Augmented Generation，简写RAG。产品经理理解它不需要碰数学公式，只需要掌握两个子任务：检索要多准，生成要多稳。检索多准，决定用户问的问题能不能找到“正确答案所在的那段资料”；生成多稳，决定模型拿到资料后能不能“不添油加醋、老老实实复述”。这篇文章后面的所有概念，拆来拆去都在为这两件事服务。
2. 拉通研发前的共同语言：先把RAG数据流转链路画出来
2.1 一张图看懂RAG整条流水线
产品经理和算法工程师之间最难的事，不是技术，而是鸡同鸭讲。研发说“召回不够”，你说“搜索结果不好”；研发说“chunk切得不合理”，你以为是程序报错。所以我建议，任何一个RAG项目启动的第一周，先让研发给你出一张数据流转图。理解这条链路，你就拿到了和任何人对话的基线。
我把标准流程拆成八个节点：
- 文档接入与解析：把PDF、Word、网页等原始资料解析成纯文本。
- 文档清洗与切分：去掉页眉页脚、乱码，再按一定规则切成小块，也就是chunk。
- 文本向量化：把每个chunk喂给Embedding模型，变成一串数字向量。
- 向量入库存入向量数据库，同时保留原文、标题、页码等元信息。
- 查询改写：有时把用户原话做一点处理，比如补全指代、拆分成多个子问题。
- 检索与召回：把用户问题也变成向量，去库里做相似度搜索，拿回Top-K个候选chunk。
- 重排序：用更精细的模型对候选结果重新打分，把最靠谱的资料排到最前面。
- 组装与生成：把排序后的chunk按格式拼进提示词，交给大模型生成最终答案。
这八个节点，前四个决定“资料好不好找”，中间三个决定“找得准不准、排序对不对”，最后一个决定“答得稳不稳”。你会发现，这正好对应我前面讲的两个子任务：检索多准、生成多稳。
2.2 产品经理要问研发的第一组问题
拿着这张图，你和研发开会时就不只是听PPT了，你可以直接问几个“产品向”的问题。这些问题没有标准答案，但研发的回答能帮你快速判断方案的健康度。
第一个问题：文档解析失败时怎么办？很多项目只处理了“干净的文本”，但真实世界里有扫描件、加密PDF、复杂表格，一旦解析失败，这个文档就等于石沉大海。你要问清楚失败率，以及是否对用户可见。
第二个问题：知识多久更新一次？如果是每天更新的价目表，那你需要的是一个增量更新的管道，而不是每次全量导入。产品经理要能拍板更新频率和延迟容忍度。
第三个问题：用户问题完全没匹配到任何资料时，系统给什么反馈？很多团队只做了“有答案”的路径，没做“无答案”的兜底。这个问题一定得在链路图上画出来，否则用户会被硬生生“编”出一个答案。
第四个问题：整个流程的耗时预算是多少？检索加上重排序再加上大模型生成，每一步都在增加延迟。你需要在产品上评估，用户能接受转圈两三秒，还是必须压到一秒内。
这组问题问完，你对整个项目的掌控力会明显上一个台阶。至少研发不会再觉得你只会在PRD里写按钮。
3. 上游决定下限：切分、Embedding与向量库
3.1 Chunk切分：你以为是技术问题，其实是产品问题
现在进入具体的7个核心概念。第一个概念是文档切分，业界一般叫Chunking。它就是把长文档切成一个个小的文本块。为什么要切？因为用户的问题往往是局部的，比如“这台设备的保修期是多久”，答案可能藏在50页手册的某一页。如果把整本手册一次性塞给大模型，一方面普通模型的上下文窗口装不下，另一方面，无关信息太多，模型容易被带偏。
切分这个环节非常有意思，它看似是纯技术操作，实际上到处是产品决策。比如切多长？切短了，比如100字一块，定位精确，但可能截断语义，把“保修期一年”和“但电池只保半年”这样的完整规则拆到两块里，检索时就可能漏掉条件；切长了，比如1000字一块，语义完整，但噪音也多，“查出来一大片，真正有用的就那一句”。常见做法是512到800个字符左右，并让相邻块之间有一部分重叠，专业叫overlap，比如每块500字，重叠80字，避免关键信息刚好被切在缝里。
更合理的策略是按结构切分。产品资料通常有标题层级：一章、一节、一个小节。你按标题边界切，每一块天然就是一个语义完整的段落。我见过一个做设备维修知识库的项目，研发一开始按固定字数硬切，结果维修步骤的“第1步到第5步”被切散了，查“怎么更换滤芯”时，召回的资料里只有第一步。改成按步骤编号切分后，准确率立刻涨了一截。所以下次当你听到研发说“切分要优化”的时候，你脑子里蹦出来的应该是：我们的文档结构是不是没有利用起来。
3.2 Embedding：把文字变成“坐标”的魔法
第二个概念是Embedding，中文常翻译成向量化。如果说切分是把资料分成块，Embedding就是给每一块资料配一个“语义坐标”。这个坐标不是二维的经纬度，而是高维空间里的一串数字，常见的可能是768维、1024维甚至更高。这串数字的意义在于：语义上越接近的文字，它们的“坐标”距离就越近。“今天天气怎么样”和“明天会不会下雨”这两句话，字面完全不同，但坐标距离很近；而“今天天气怎么样”和“数据库连接失败”，坐标距离就很远。
产品经理不需要会算这个坐标，但必须理解两个由Embedding派生出来的关键决策。一是Embedding模型的选型很重要。中文场景必须用中文效果好的模型，拿一个主要针对英文训练的模型来处理中文文档，召回效果会肉眼可见地差。二是Embedding模型一旦选定，最好不要中途更换。因为所有历史文档都已经用旧模型转成了向量存在库里，你换模型，就等于要把全部文档重新转一遍。有些企业有几百万篇文档，全量重转的成本不低。所以选型要谨慎，尽量选成熟、稳定、有中文优化方案的版本。
这里可以用一个生活化类比帮助你记忆：Embedding模型就是一个“翻译官”，把人类语言翻译成机器能计算的距离关系。翻译官水平差，后面所有环节做得再好都白搭。
3.3 向量数据库选型：别只盯着名字
第三个概念是向量数据库。有了向量，总得有个地方存。向量数据库就是专门用来存向量、按向量相似度做检索的仓库。它的核心操作叫“近似最近邻搜索”，意思就是：给定用户问题的向量，快速找出库里最相近的几十个向量。
市面上的选择五花八门，有开源的，有云服务商托管的，也有直接在传统数据库上装向量插件。我的建议是，产品经理不要在“哪个向量数据库最好”上纠结，而应该关注三个产品导向的指标：一是检索延迟，用户提问后，向量检索本身最好控制在100毫秒级别，否则整体体验会被拖垮。二是是否支持元数据过滤，比如能不能只搜“2024年的合同”而不搜“2023年的合同”，这个能力经常被忽略，却特别影响检索精度。三是混合检索能力，也就是一个库里能不能同时支持向量检索和关键词检索。这一点我下节细说，但它直接在选型阶段就会卡掉不少方案。
需要特别提醒一句：向量数据库只负责“找到相关资料”，它不产生答案。很多老板以为换一个更贵的向量库，客服机器人就能变聪明，这是巨大的误解。它就是仓库管理员，你问它“材料在哪”，它给你指个路而已。
4. 中间检索决定体验：召回、混合检索与重排序
4.1 召回数量和阈值：为什么Top-K不是越大越好
第四个概念是召回。用户提问后，系统不可能把整个知识库都塞给大模型，它只会挑选最相关的若干块资料，这个挑选动作就叫召回。经常听到的“Top-K”，就是“取最相关的K块”。K值的大小，直接决定生成质量。
K太小，比如只召回1块，真实的答案可能压根没被选中，属于漏检。K太大，比如召回20块，模型会被大量弱相关的内容包围，回答时容易被噪音带跑偏。那么K怎么定？这没有标准值，常见的在3到10之间，需要根据你的资料粒度和文档风格去测。另外还要看一个指标叫相似度分数阈值。向量检索会给每个候选打一个相似度分，如果用户的问题和知识库任何一块都不太像，分就会很低。这时候宁可返回“没找到”，也不要硬凑一块低分的资料给大模型。这个“拒绝回答”的阈值，是产品经理需要和研发一起反复调的东西。
这里有个产品层面的坑：有些团队为了表现“产品很智能”，把K设得很大，结果答非所问的比例上升了。记住一句话：召回的质量永远比数量重要。让模型有据可依，且只有最靠谱的一小撮据，才是正确的状态。
4.2 混合检索：当向量检索“看不懂”精确编号时
第五个概念是混合检索。前面说的向量检索优势在于理解语义，但它有一个软肋：对精确匹配不敏感。比如用户问“请查合同编号HT2024-001的付款条款”，向量检索可能觉得“HT2024-001”只是一个贡献度很低的符号，按语义去搜，把编号相关的特征稀释掉了。而传统的关键词检索，反而能精确命中这个编号，做到一个字都不差。
所以成熟的RAG系统通常不走单一通道，而是“关键词检索+向量检索”双通道并行，再把两个通道的结果合并。关键词检索常用的算法叫BM25，它可以理解为一种改进版的“TF-IDF”，谁的关键词出现得多、出现得稀罕，谁的分就高。合并之后，两边都推上来的chunk，可信度自然更高。
在项目实践中，我见过太多只做向量检索的方案，一到“查单号、查编号、查型号”就翻车。产品经理在评审时一定要问一句：我们的检索是单一的还是混合的？如果是混合的，两个结果集怎么融合——简单的分数相加，还是加权，还是用后面要讲的Rerank统一排序，这都影响最终表现。
4.3 Rerank重排序：用第二次打分把最优资料捞到第一位
第六个概念是重排序，业界常叫Rerank。你可以把它理解为两轮筛选：第一轮粗筛，用向量检索快速捞出比如50块候选；第二轮精排，用一个专门的排序模型对这50块重新打分，再取最相关的5块。为什么要多此一举？因为向量检索追求的是“快和广”，它用近似算法计算，效率和召回够好，但精度不够细。Rerank模型则是专门训练来做“精打细算”的，它会真实地把“用户问题”和“每一块资料”做深度语义匹配，打出的分数更可靠。
但Rerank不是免费的。每一次重排序都是一次模型推理，会增加几十到几百毫秒的延迟，而且这部分成本也是按调用次数算的。常见的做法是：粗召回取50块，重排序之后再取前5块或前8块，这样既能保住精度，又把延迟控制住。产品经理要做的权衡是：如果产品对响应速度极其敏感，可能要做成“只对Top-N块重排”，甚至“部分高置信场景跳过重排”。
这里有一个真实项目经验：某客服机器人，查“发票怎么开”这种高频问题，向量检索第一候选经常不准，把正确答案排到第几个位置上。加入Rerank之后，正确答案进入前三的概率明显提高，应答准确率从81%涨到89%。所以当研发给你讲Rerank的价值，你不要觉得那是炫技，它往往是效果提升最大的一环。
5. 生成阶段拼图与约束：上下文窗口、提示词与输出控制
5.1 上下文窗口不等于越大越好
最后一块拼图是把资料交给大模型生成答案，这里第七个核心概念是上下文窗口，也就是模型一次最多能“读”多少内容。目前主流模型动辄几十万token，听起来很大，但你要明白：不是你塞进去多少资料，它就能用好多少资料。经验数据是，塞进去的相关物料越多，模型被无关信息干扰的概率也越大。上下文窗口与其说是储物空间，不如说是一个“注意力预算”。空间越大，你越需要在里面放高质量的内容，而不是把粗召回的全部结果一股脑塞进去。
产品经理在设计阶段就要算一笔账：你的知识库切块多大？平均一块多少token？上下文窗口里要留多少token给答案输出？如果每块200个token，窗口还剩4000个token，那最多只能塞十几块。如果粗召回Top-50全部塞进去，必然超出窗口，那就要重排后截断。这些约束条件直接决定你在产品上能展示“参考资料”的数量上限。很多团队上生产环境才发现，上下文窗口不够用，临时压缩切块大小，又导致检索效果波动，绕了很大一圈。这些坑，最好在评审阶段就暴露出来。
5.2 提示词让模型当好“资料整理员”
生成质量好不好，一半在检索，一半在提示词。所谓提示词工程，放在RAG场景里，核心就是给模型立三条规矩：第一，只基于提供的资料回答，资料里没有的，明确说“不知道”，不要自行补脑。第二，优先从资料中摘取原文表述，必要的信息用自然语言整理成通顺的回答。第三，回答中要标注依据，说明这句话来自哪一块资料，方便产品侧展示引用来源。
一个适合项目的提示词结构可以长这样：
你是某产品的智能客服助手。请根据下面由系统检索到的资料回答用户的问题。 规则： 1. 仅使用资料中的信息作答，不要使用资料之外的先验知识。 2. 如果资料中没有相关答案，请直接回复：抱歉，我没有在相关资料中找到该信息。 3. 回答需简洁、完整，重要结论后标注来源编号，例如（来源3）。 4. 如用户问题与资料无关，可委婉告知无法回答。 资料： [来源1] 配件保修政策：整机保修一年，电池保修半年。 [来源2] 退换货流程：签收后七日内可申请无理由退换。 用户问题： 电池坏了能保修多久？这个示例，你在和研发对齐“生成策略”时可以直接拿来改。它的价值在于把“如何答”从模型藏在肚子里，变成了产品可控的规则。产品经理千万不要觉得提示词是研发的私活，你可以不懂模型细节，但你要能看懂提示词里的规则对不对、覆盖了哪些边界场景。
5.3 引用来源：产品经理最容易加分的设计
讲到生成，就不得不提产品设计里的一个加分项：引用来源展示。RAG天然能告诉你“答案来自哪块资料”，只要在切分时给每个chunk保留原始文档信息和页码，生成后就能把答案与知识库里的特定片段对应起来。产品上做成“回答末尾附引用编号，点击即可展开原文”，用户能自己核对答案对错，这比什么都管用。
别小看这个设计，它至少解决三件事：一是建立信任，用户看到答案有凭有据，不再怀疑是AI瞎编；二是提供纠错路径，一旦引用原文和答案对不上，用户可以点出来投诉，等于免费帮你收集bad case；三是缓解法务和合规压力，很多要求“可追溯”的行业场景，有了引用来源，才敢把AI回答放到公网上。所以在需求阶段，我通常会建议把“引用来源点击率”直接定为产品指标，它不只是技术能力，更是产品策略。
6. 永远别等到上线再测：RAG效果评估体系
6.1 离线评估：搭建一套Golden Set
产品经理管RAG项目，最该抓的是一套评估体系，而不是等上线后靠用户骂。最实用的做法是建一套离线评测集，业内叫Golden Set。简单说，就是先准备50到100条有代表性的“问题—标准答案—期望命中的资料”的三元组。比如问题“密码忘了怎么重置”，标准答案是“可通过手机验证码重置”，期望命中的资料是操作手册里那一段。
评测时，让系统跑一遍这些测试问题，看两个数：一是命中率，期望的资料在不在召回结果里；二是答案正确率，让大模型生成的回答和标准答案比一比，语义是否一致，有无关键信息遗漏。这个评测集的价值在于，每次你改了切分策略、换Embedding模型、调了重排序，都能用同一套题回归测试，用数字说话，而不是凭感觉说“好像变好了”。
搭建的时候有两点容易踩坑：第一，问题要覆盖真实用户的高频提问，你不能自己凭空编一堆理想化的问题；第二，期望资料要标注到具体的chunk，这样才能定位是哪一环出了问题。这个工作很耗时，但它是产品经理在RAG项目里投入产出比最高的一件事。
6.2 在线评估：让用户成为你的测试员
离线评测覆盖的是“已知的问题”，但线上用户的提问永远千奇百怪。所以线上部分需要一个从体验指标到技术埋点的闭环链路。技术上要埋的埋点至少包括：检索无结果率（说明召回失败）、引用点击率（说明用户是否认可来源）、回答点赞点踩率（直接反映用户体验）、兜底对话率（即转到人工客服或触发“不知道”回复的比例）。
产品经理要盯的指标我建议精简为三个：首次应答成功率、无效回答率和引用的准确率。无效回答既包括触发“找不到资料”，也包括被用户点了“踩”。每一条“踩”的bad case都要进入一个定期复盘池，积累到一定数量，就形成一个问题类型清单，比如“问型号参数总答不准”“问流程步骤总是漏步骤”。有了这个清单，你就可以反向推导：是切分把参数表格拆坏了，还是Embedding没识别这种问法，还是提示词没把“不知道”的边界说清楚。
6.3 效果调优判断题：先调哪里
拿到一个bad case，产品经理最容易犯的错是抓瞎式地提需求：“把效果优化一下”。这等于没提。你需要学会做“环节定位”，我把它总结成一个判断题列表，你可以按顺序排查：
- 查召回：期望的资料在不在搜索结果里？如果不在，问题出在上游——切分、Embedding、向量检索。
- 查排序：资料在结果里，但排得靠后，导致没进最终候选。这时优先看Top-K和重排序。
- 查生成：资料明明进了候选，答案还是答偏了。问题出在提示词，或模型本身对这类指令的处理能力。
- 查兜底：没有资料却硬答了。问题出在相似度阈值和拒绝回答策略。
用这个判断顺序，你能把“效果差”这个抽象问题，拆成“切分问题”“检索问题”“生成问题”等可执行的工单，再去找研发同事解决，效率完全不同。这也是我认为产品经理最值得练的一项基本功。
7. 一个从立项到交付的RAG知识库项目复盘
7.1 真实场景：某公司的售后答疑知识库
理论讲了一堆，最后分享一个我做过的项目复盘，你会有更具体的体感。场景是一家做家用电器的公司，要给售后客服做一个内部问答助手，目标是把常用售后政策、常见报修问题的处理办法做成一套知识库辅助系统。资料大概有两千多篇文档，格式非常混乱：有PDF说明书，有Excel价目表，有历史工单摘录，不少还是扫描件。这个“脏乱差”的资料现状，几乎是所有RAG项目的真实起点。
项目刚跑起来，效果感人。测试同事问“洗衣机E1故障代码怎么解决”，系统答非所问。我顺着链路排查，发现原因是：故障代码那段文字在一个表格里，研发用通用解析库抽出来的时候，表格结构丢了一半，内容变成了一堆零散字符串，切分后每块都不完整。后来我们换了带表格结构识别能力的解析方案，并针对故障代码这类内容单独设计了按“故障码—现象—处理方法”三段式切分，效果立刻变了。这个教训是：解析工具选型比调参更影响效果，而切分规则一定要跟着资料的实际结构走。
7.2 我作为产品经理做的四件事
回看项目，我作为产品经理第一件事是画数据流转链路图，拉着研发把每个环节当前的表现数据摊开看：谁耗时最长，谁失败率最高，先解决明显的瓶颈。第二件是主导搭建了那套Golden Set，专门把售后高频问题按场景分好类，规定每一次版本迭代都必须先过这几十条回归。第三件是参与了切分策略的产品化。当时研发做了好几版切分参数，我把文档按类型分成“制度文件”“产品说明书”“故障代码表”三类，和研发约定不同类别用不同规则，并把这个配置暴露在后台，方便运营同学以后自己微调。第四件是坚持做了引用来源展示，所有回答必须带来源编号，用户点开能看到原始段落。
这四件事没有一件需要写算法代码，但它们都直接影响了最终效果。你会发现，产品经理在RAG项目里最大的价值其实是“搭桥”：桥接业务需求和技术约束，桥接用户的问法和资料的文档结构。
7.3 上线后的效果与遗留问题
上线三个月后，这个助手在售后场景里，高频问题的有效解答率稳定在85%左右，无结果回答率降到了8%以下。效果显著，但仍有两个遗留问题值得警惕：一是资料的更新机制，每个季度都有新的型号和保修政策，如果运营没有及时上传最新文档，系统就会用旧资料给出“看起来合理但实际已过期”的答案。二是个别复杂推理类问题，比如“多个故障码同时出现时先处理哪个”，RAG能召回资料但模型不一定能组织出正确的步骤性回答，这类问题需要靠提示词加流程引导来慢慢磨。
这两类问题没有一劳永逸的解法，需要运营、产品、研发常态化地维护。
做完这个项目，我对RAG的体会是：它不是什么高深的魔法，而是一套需要精耕细作的知识交付系统。产品经理懂RAG，并不意味着你要去抢算法工程师的活儿，而是你要能在“用户的一句话”和“系统的一整条链路”之间建立起清晰的因果感。知道哪里可能出错、出错后该盯谁、改了之后怎么验证，这三件事，就是产品经理真正的护城河。下次再有人问你懂不懂RAG，你不用解释什么是向量，你只需要说：我知道RAG的哪一环导致什么体验问题，我可以和团队一起把它修好。
