AI 产品经理必学的20个RAG概念

写在最前​

RAG上线效果差，产品经理第一反应永远是换大模型，从 GPT 换到 Claude，再换到通义千问，数据没变好，反而越换越乱。​

90% 上线后效果差的 RAG，问题压根不在大模型，在建库那一刀 Chunking切歪了，后面所有检索、所有 Prompt 优化都是在给前面的坑擦屁股。 ​

​

​

我带过的学员的 RAG 项目，真正决定生死的是建库那 4 步加检索那 4 步，大模型只负责最后两步收尾。​

把这 8 步搞清楚比换十次模型管用，这篇就把产品经理必须吃透的 20 个核心概念一次说清楚，不讲数学，直接说每个概念在产品里干什么、怎么用、怎么踩坑。​

01​

PART​

RAG 到底是什么​

你问一个只读过通识课本的学生一道专业题，他大概率瞎编一通，因为他脑子里压根没这块内容。但如果你把相关资料先递给他看一眼，再让他回答，他至少能照着资料说，不会瞎编。​

RAG 就是让 AI 回答时，先去翻相关资料再说话，英文叫 Retrieval-Augmented Generation，中文叫检索增强生成。​

为什么需要这玩意？大模型自带的知识有两个硬伤，一是训练数据有截止日期，你公司上周新出的产品政策它不知道，二是它不知道的事会瞎编，业内管这叫幻觉。​

把企业内部资料、最新文档、专业知识塞进一个能被搜索的库，每次回答前先去库里捞相关片段，再把片段和问题一起喂给大模型，大模型就有据可查，不靠瞎编。​

老王见过很多产品经理把 RAG 当成黑科技，其实它的本质就一句话，先查再说，不让大模型凭空回答。​

​

​

02​

PART​

离线索引 vs 在线检索​

外卖平台你下单的时候，商家不可能临时去市场买菜再做饭，他必须提前把菜买好、洗好、切好、备齐，你下单他才能 15 分钟出餐。​

RAG 也一样。把所有资料处理成可被秒级搜索的向量、存到向量库，这件事必须提前做完，叫 离线索引，英文 Offline Indexing。用户提问的那一刻，系统只能临场做三件事，把问题转成向量、去库里查、把结果排好，这叫 在线检索，英文 Online Retrieval。​

为什么要分这两段？因为速度。建库可能要跑几小时甚至几天，用户提问不能等，必须毫秒级响应。所有 RAG 工程化的设计逻辑都从这一刀分割开始，建库慢一点没关系，检索必须快。​

老王看产品经理设计 RAG 产品最常见的错，是把所有事情都想成“用户提问的时候才做”，结果一上线就发现根本撑不住并发。这一刀切清楚，后面的资源规划、成本核算、性能优化才有依据。​

​

​

03​

PART​

Chunking，把资料切成块​

你拿一本 300 页的产品手册扔给大模型，它装不下也读不完。必须先把这本手册切成一段一段的小块，每块几百字，这个动作叫 Chunking，中文叫分块或者切片。​

为什么必须切？两个原因，一是大模型上下文窗口有限，塞不下整本书，二是检索的时候要找的是“跟用户问题最相关的那一段”，不是整本书，切成块才能精准定位。​

切的好不好，直接决定后面所有事情的上限。切得太大，一块里塞了 5 个不相关的话题，检索回来一大坨噪音。切得太小，一句话切成两块，语义被切断，大模型读到一半看不懂。​

老王见过最离谱的翻车，一个团队把 Word 文档按段落切，结果一个表格被切成 10 块，每块只有一行，检索回来的全是孤立的表格行，大模型完全拼不出原表格的意思。Chunking 不是技术活，是产品决策，你得知道你的资料长什么样、用户会问什么样的问题、按什么粒度切才能精准命中。​

​

​

04​

PART​

Chunk Size 和 Overlap​

切块有两个参数永远绕不开，一个是 Chunk Size 块大小，一个是 Overlap 块重叠。​

Chunk Size 就是每块多长。主流默认 300 到 600 字，但这只是默认，不是标准答案。你切的是法律条款，每条本身就两百字，那 200 字一块刚好。你切的是技术白皮书，一段论述要 800 字才能讲清一个观点，那 200 字一块就是灾难。​

Overlap 是相邻两块之间故意重叠的部分。比如 500 字一块，前一块的最后 50 字也出现在下一块开头，这 50 字就是 Overlap。为什么要重叠？因为切块的位置永远是机械的，可能正好切在一个关键论述的中间，Overlap 让被切断的语义在两块里都能被找到，避免漏召回。​

主流配置是 Overlap 占 Chunk Size 的 10% 到 20%，500 字的块配 50 到 100 字的 Overlap。重叠太多浪费存储和检索成本，重叠太少又起不到弥补作用。​

老王的经验是，这两个参数没有标准答案，只有适合你数据的答案。第一版上线后，看用户问的问题召回率怎么样，如果发现一类问题总是漏召，大概率是切块在那个语义上断了，加大 Overlap 或者换切法。​

​

​

05​

PART​

Embedding，把文本变成数学坐标​

切好的每一块文本，计算机本身不认识中文，它要做相似度判断，得先把文字变成数字，变成的这个数字叫向量，这个过程叫 Embedding，中文叫嵌入或者向量编码。​

打个比方，地图上每个地点都有经纬度坐标，北京是一个坐标，上海是一个坐标，两个城市离得近不近，看坐标差多少就能算。Embedding 干的就是这事，把每段文字变成几百维的坐标，语义相近的文字坐标距离近，语义远的距离远。​

具体怎么变？用一个叫 Embedding Model 的专门模型，常见的有 OpenAI 的 text-embedding-3、智源的 bge、Cohere 的 embed，模型读进一段文字，吐出一个 768 维或者 1536 维的数字数组。这个数组就是这段文字在语义空间里的坐标。​

老王想强调一件事，Embedding 模型选什么，直接决定你的 RAG 上限。中文场景用纯英文训练的 Embedding，效果会差一截。垂直领域比如医疗、法律，通用 Embedding 也可能打不过专门微调过的小模型。​

选型阶段必须实测，不能看排行榜，排行榜上的中英文混合榜对你的中文垂直场景未必有参考价值。​

​

​

06​

PART​

向量数据库​

每段文本被 Embedding 成几百维的向量后，要存到一个能按相似度极速搜索的地方，这个地方叫 向量数据库，英文 Vector Database。​

普通的 MySQL、MongoDB 不行，它们设计的查询逻辑是“id 等于 123”“标题包含某关键词”，做不了“找语义最接近的 10 条”。向量数据库底层用专门的算法和索引结构，能在千万级甚至上亿条向量里毫秒级找出最相近的几条。​

主流的向量数据库有 Milvus、Pinecone、Qdrant、Weaviate、Chroma。Milvus 国产开源，Pinecone 是云服务，Qdrant 性能口碑好，Chroma 适合小规模本地起步。选型要看几件事，数据量多大、是云上还是本地、要不要支持元数据过滤、有没有运维团队。​

老王见过一个常见误区，产品经理觉得向量数据库就是装向量的桶，选哪个都一样。错。不同向量库在召回准确率、查询延迟、过滤能力上差距很大，百万级以下随便选，千万级以上必须严格压测，否则上线被并发打爆是分分钟的事。​

​

​

07​

PART​

Query Embedding 的一致性​

用户输入“如何申请退款”，这句话也必须先变成向量，才能跟库里的向量做比较，这个动作叫 Query Embedding 问题向量化。​

这里有一个产品经理最容易踩的坑，问题向量化用的 Embedding 模型，必须跟建库时用的模型完全一致。不一样不行，差一个版本号都不行。​

为什么？Embedding 模型本质上是把文本投影到一个特定的语义空间，不同模型投出来的坐标系完全不同。你在 A 模型的坐标系里建库，用 B 模型的坐标系去查，等于拿北京地铁图找上海某个站，坐标对不上，结果全错。​

老王见过一个真实案例，团队建库用了 bge-large，后来觉得查询慢想省钱，查询时改用 bge-small，结果召回率从 80% 暴跌到 20%，排查了三天才发现是模型不一致。建库和查询的 Embedding 必须锁定同一个版本，这是工程纪律，不是优化点。​

​

​

08​

PART​

余弦相似度​

两段文本变成向量后，怎么判断它们像不像？用一种叫 余弦相似度 的算法，英文 Cosine Similarity。​

想象向量是空间里从原点出发的箭头，两个箭头方向越接近，夹角越小，这两个文本就越相似。余弦相似度算的就是这个夹角的余弦值，值域 -1 到 1，越接近 1 越相似，接近 0 表示不相关，负值表示相反。​

为什么用余弦而不用别的？因为它只看方向不看长度。两段文本一段长一段短，但讲的是同一个事，向量长度不一样但方向一致，余弦相似度能识别出来。换成欧氏距离就会被长度干扰，长文本和短文本即使语义相近，距离也会很大。​

主流向量库默认就是余弦相似度，99% 场景不用动。老王见过一些产品经理在选型时纠结要不要换成欧氏距离或者内积，实测下来对最终效果影响极小，不如把精力放在 Chunking 和 Embedding 模型选型上。​

​

​

09​

PART​

ANN 近似最近邻搜索​

向量库里可能存着几千万甚至上亿条向量，用户问一个问题，系统要在毫秒内找出最相似的 10 条，怎么做到的？​

如果用最暴力的方法，跟每条向量都算一遍余弦相似度再排序，叫精确最近邻搜索，千万级数据要算几秒钟，完全不能用。实际生产用的是 ANN 近似最近邻搜索，英文 Approximate Nearest Neighbor。​

ANN 的思路是，牺牲一点点准确率，换巨大的速度提升。它提前把所有向量按某种结构组织好，比如分簇、建图、构建多层索引，查询时只在一小部分候选里搜，不全量比对。主流算法有 HNSW、IVF、PQ。​

ANN 的“近似”两个字意味着，它找回来的 Top 10 跟真正的 Top 10 可能差 1 到 2 条，但 95% 以上场景这点偏差对最终效果毫无影响，换来的是速度从秒级到毫秒级。​

老王想说的是，产品经理不用懂 HNSW 的数学原理，但要知道一件事，当你的向量库越来越大，召回速度变慢，通常不是机器不够，是 ANN 索引参数没调好。这是技术问题，但产品经理要能识别出来，不要一上来就要求扩容。​

​

​

10​

PART​

Top K 检索​

查询的结果不会只返回一条，会按相似度排序返回前 K 条最相关的，这个 K 就是 Top K。​

K 取多少有讲究。K 太小比如只取 3 条，万一最相关的那条没在前 3，后面 LLM 就拿不到正确信息，直接答错。K 太大比如取 50 条，大模型上下文窗口塞不下，塞下了也大部分是噪音，反而干扰回答。​

主流默认 K 取 5 到 10，这是经验值。但具体多少合适，要看你的资料密度和问题类型，密集型资料（每块信息量大）K 可以小一点，稀疏型资料 K 要大一点。​

老王见过一个常见错误，产品经理觉得 K 越大越保险，直接设成 30，结果大模型读到一堆不相关片段，被噪音带偏，反而比 K=5 时还差。Top K 不是越大越好，是要刚好够，够回答的同时不带噪音。​

跟 Top K 配套的还有一个 相似度阈值，低于某个分数的就不要，哪怕排在前 K 里。比如 K=10 但只有前 3 条余弦相似度超过 0.7，后面 7 条全在 0.3 以下，那就只取前 3 条。这能有效过滤掉强行凑数的低质量召回。​

​

​

11​

PART​

召回率​

检索阶段最关键的一个指标，叫 召回率，英文 Recall，衡量的是该被找到的资料，有多少被真的找回来了。​

公式很简单，召回率 = 检索到的相关片段数量 ÷ 全部应该被找到的相关片段数量。比如你的库里关于退款政策一共有 8 个相关片段，这次检索返回了 6 个，召回率就是 75%。​

为什么召回率这么重要？因为大模型的回答上限，被召回率死死锁住。如果该找到的资料压根没被找回来，大模型再聪明也答不对，巧妇难为无米之炊。一切检索优化的核心目标，就是把召回率往上推。​

召回率低的常见原因有三个：​

•

Chunking 切坏了把关键内容割断。​

•

Embedding 模型对你的领域不敏感。​

•

Top K 设得太小漏了相关片段。​

这三个是排查召回问题的固定动作。​

老王见过的最离谱的产品事故，RAG 上线测下来效果烂，团队第一反应是换大模型，换了三个月没改善，最后发现是建库时一个表格被切碎了，关键数据根本没进库，召回率天生只有 30%。先看召回，再看生成，不要本末倒置。​

​

​

12​

PART​

Rerank 重排序​

向量检索召回的 Top K 是按相似度排好序的，但这个序未必是“最适合大模型用”的序，会有第二轮筛选，叫 Rerank 重排序。​

为什么需要重排？向量检索本质是粗筛，看的是整体语义相似度，不擅长理解细节。比如用户问“退款最长多少天”，向量检索可能召回 10 条都跟退款相关，但只有 1 条直接讲了“15 天”这个数字。Rerank 模型会逐条精细判断，把直接命中答案的那条排第一。​

Rerank 用的模型叫 Reranker 或 Cross-Encoder，跟 Embedding 模型完全不是一类东西。Embedding 是把问题和片段分别变成向量再比，叫双塔模型，速度快但精度低。Reranker 是把问题和片段拼在一起一起处理，精度高但慢，所以只能在 Top K 内做精排，不能在全库做。​

工业级 RAG 几乎都是 双段架构，Embedding 粗筛 + Reranker 精排，先用快的拉出几十条候选，再用慢的精排前 5 条。​

老王想说，Rerank 是 RAG 效果优化里性价比最高的一步，加上 Reranker 模型，召回质量通常能再提 10% 到 20%，远比换大模型来得划算。​

​

​

13​

PART​

Prompt 组装​

检索到的片段不能直接扔给大模型，得跟用户问题、回答指令、输出格式一起组装成一段完整的输入，这个动作叫 Prompt 组装，也叫 Context Assembly。​

一个典型的 RAG Prompt 结构长这样：​

•

先一段系统指令告诉大模型你是谁、应该怎么答。​

•

再贴上检索到的资料片段。​

•

再贴用户原问题。​

•

最后约束输出格式比如必须附引用、必须用 JSON。​

这几个部分的顺序、措辞、有没有引用标记，都会显著影响大模型的回答质量。同一份资料，Prompt 写得好可能答对，写得乱可能答错或者答得啰嗦没用。​

老王想提醒产品经理一个特别容易被忽视的细节，Prompt 里给资料片段加序号和来源标签，比如“片段 1 来源：产品手册第 3 章”，大模型在回答时就能照着标签生成引用。如果片段一锅烩塞进去，大模型根本无法标引用。​

Prompt 组装是产品经理能直接参与的 RAG 优化点，不需要懂代码，只要会写清楚的指令、对输出格式有要求，就能把 Prompt 调到 70 分以上。​

​

​

14​

PART​

上下文窗口和 Token 预算​

大模型不是想塞多少东西就塞多少，有一个硬上限，叫 上下文窗口，英文 Context Window，衡量单位是 Token。​

Token 是大模型处理文本的最小单位，一个中文字大概是 1 到 2 个 Token，一个英文单词大概是 1 个 Token。GPT-4o 上下文窗口 128k Token，Claude 200k Token，通义千问 long 也有 32k 到 1M 不等。​

为什么产品经理必须懂这个？因为 Token 是有预算的。每次调用大模型，从系统指令 + 检索资料 + 用户问题 + 输出回答全部算 Token，API 按 Token 计费。Token 用得越多，响应越慢、钱花得越多。​

实际工程里，Token 预算决定了 Top K 能取多大、每个 chunk 能多长。一个 128k 窗口的模型，你不能把所有 Token 都用来塞 chunk，得留出来给输出。如果一次调用预算上限定 8k Token，系统指令 + 输出预留 2k，留给检索资料的就剩 6k，按一块 500 字 750 Token 算，最多塞 8 块，Top K 就锁死在 8。​

做 RAG 产品前必须先算 Token 预算，这是产品成本的核心变量。不算就上，上线一周账单到了才发现一个月烧几十万，这种事老王见过不止一次。​

​

​

15​

PART​

引用与可溯源​

RAG 跟纯大模型问答最大的交付物差别，在于回答必须附 引用与可溯源，英文叫 Citation 或 Attribution。​

为什么这事必须做？因为 RAG 的核心价值就是“不让大模型瞎编”，那用户怎么知道大模型这次没编？只有把回答里每句话对应的资料片段标出来，用户能点进去看原文，才证明这是查出来的不是编出来的。​

实现上分两层：​

•

第一层是 Prompt 里给每个片段编号，大模型回答时引用编号。​

•

第二层是产品 UI 上把编号渲染成可点击的来源链接或者悬浮卡片，用户能直接跳转到原文位置。​

没有引用的 RAG 不能叫严肃 RAG，只能叫“用了一下检索的聊天机器人”。对企业级应用尤其是金融、法律、医疗，引用是合规底线。​

老王见过很多产品经理设计 RAG 产品时，把引用当成锦上添花的功能放在 P2 优先级。错。引用是 P0，是 RAG 区别于普通 ChatGPT 的核心定位，产品上线第一版就必须有。​

​

​

16​

PART​

幻觉​

大模型胡说八道、把不知道的事情编得头头是道，这种现象叫 幻觉，英文 Hallucination。RAG 存在的根本意义，就是把幻觉降下去。​

幻觉分两种：​

•

事实型幻觉，大模型把张三的事编到李四头上、把 2023 年的事说成 2024 年。​

•

逻辑型幻觉，大模型在推理过程中编造一个看起来合理但其实不存在的中间步骤。​

RAG 能解决第一种，通过把真实资料喂给大模型，让它有据可查。第二种解决不了，需要靠 Prompt 工程和模型本身能力。​

但 RAG 并不能 100% 消除幻觉，有三种情况它会失效：​

•

检索没召回到相关资料，大模型在没资料的情况下还是会编。​

•

召回的资料本身错了，大模型会照着错的资料编。​

•

大模型不老实，即使资料给了它也偷懒回答自己脑子里的版本。​

衡量幻觉的指标叫 幻觉率，工业上常用的做法是让另一个大模型做 Judge，逐句判断回答里每个事实是否能在召回资料里找到依据，找不到就算幻觉。降低幻觉率的核心三招是提召回率、加引用约束、用更强的指令遵循模型。​

幻觉率不是 0 就是 100，而是一个连续指标。100 个回答里有 5 个有幻觉，幻觉率就是 5%。要把这个指标接进监控，而不是抽几条人工看看就完事。​

​

​

17​

PART​

Recall vs MRR／NDCG​

检索阶段评估指标不止召回率一个。召回率回答“该找的有没有找回来”，但找回来排在第几位它不管。第 1 位是它，第 30 位也是它，召回率都算 100%。​

但对大模型来说，排第 1 和排第 30 完全是两件事。Top K 截断后排第 30 的片段根本进不了 Prompt，等于没召回。所以还需要看 排序质量，常用两个指标。​

MRR 平均倒数排名，衡量的是“正确答案平均排在第几位”。如果正确答案 50% 时间排第 1、50% 时间排第 2，MRR 大约是 0.75。越接近 1 越好。​

NDCG 归一化折损累积增益，比 MRR 更细，它不只看排第几，还看每条召回的相关性强弱。最相关的排第 1、次相关的排第 2，NDCG 才高；如果次相关的排到了最相关前面，NDCG 就会降低。​

产品经理不用记公式，但要知道这两个指标的存在，只看召回率不够，排序质量是隐藏在召回率背后的杀手。如果你的产品 Reranker 没接，光看召回率 80% 觉得不错，实际上正确答案可能都排在第 8 第 9 位，根本进不了大模型，等于白召回。​

​

​

18​

PART​

RAGAS 评测框架​

光评估检索阶段不够，要看 RAG 整体好不好，得做端到端评估，这事现在的事实标准工具叫 RAGAS。​

RAGAS 把 RAG 拆成 4 个维度自动打分。​

•

答案正确性，Answer Correctness，衡量大模型给出的回答是否事实正确。​

•

完整性，Answer Completeness，衡量是否覆盖了问题所有方面。​

•

自然度，Answer Fluency，衡量语言是否通顺。​

•

无幻觉，Faithfulness，衡量回答里的每句话是否都能在检索资料里找到依据。​

这 4 个维度比单独看一个指标全面得多。它特别擅长发现一类隐蔽问题：回答看起来通顺、看起来覆盖了问题，但其实是大模型编的、跟资料对不上。这种问题人工抽检不出来，RAGAS 能。​

RAGAS 是工业级 RAG 的必需品，不是可选项。产品上线后，每次更新模型、改 Chunking、调 Top K，都要跑一遍 RAGAS 看 4 个维度有没有退化。用感觉判断 RAG 好不好，迟早翻车，用 RAGAS 跑出数字才有迭代依据。​

​

​

19​

PART​

LLM-as-Judge​

RAGAS 里那些“答案正不正确”“完不完整”是怎么自动判断的？用一个能力更强的大模型当评委，这个做法叫 LLM-as-Judge，大模型当评分员。​

为什么用大模型评？因为这些维度没有标准答案，人工评太慢太贵。比如“这个回答完整不完整”，规则写不死，只有人能判断，但找人评 1000 个回答要花一周。换 GPT-4 当评委，1000 个回答几小时就跑完，质量跟人工评的吻合度能到 80% 以上。​

具体做法是给评委模型一个详细的评分 Prompt：这是用户问题、这是检索资料、这是回答，请你按照以下标准从 0 到 1 打分。不同维度有不同的评分 Prompt。​

LLM-as-Judge 不完美，它会有自己的偏见，比如倾向给长回答打高分、对自己同门模型的回答打高分。工业上的做法是用一个跟生成模型不同家族的评委，比如生成用 Claude 评委用 GPT-4，避免同门偏袒。​

老王说个常见误区，产品经理觉得用大模型评不靠谱、坚持人工评，结果迭代速度被人工评卡死，一个月只能跑两轮实验。LLM-as-Judge 不是完美但够用，它换来的是迭代速度，这才是 RAG 优化的真正瓶颈。​

​

​

20​

PART​

Hybrid Search 混合检索​

纯向量检索不是万能的，在三类问题上它会输，专有名词、短查询、代码片段。这时候要混合用关键词检索 BM25，叫 Hybrid Search 混合检索。​

为什么纯向量打不过？向量擅长理解语义但对精确字符不敏感。用户搜“iPhone 16 Pro Max”，向量检索会找到所有 iPhone 相关的文档，但 16 Pro Max 这几个精确字符可能被弱化。BM25 是基于关键词匹配的传统算法，它就盯着字符出现频率和稀有度，精确命中专有名词非常稳。​

Hybrid Search 的做法是两条路并行，向量检索返回一份 Top K，BM25 返回另一份 Top K，然后做结果融合，常用算法叫 RRF 倒数排名融合，把两份排序合并成一份总排序。​

工业级 RAG 几乎都在用混合检索。纯向量适合做原型，上线版本 99% 都得加 BM25。老王想说，这是产品经理在 RAG 进阶阶段必须知道的最后一块拼图，单一检索打不过混合检索，这一仗已经打完了，别再纠结只用向量。​

中文场景下还有一个细节，BM25 需要先分词，分词器选择对效果影响很大，jieba、IK、HanLP 各有适用场景，垂直领域可能还要自己加词典。这个细节产品经理不用动手做，但要知道存在，否则上线后中文召回拉胯都不知道找谁问。​

​

​

21​

PART​

写在最后​

老王这几年看过的 RAG 项目，真正做得好的团队有一个共同特征，他们在 Chunking 和 Embedding 选型上花的时间，远多于纠结用 GPT 还是 Claude。前者决定召回率天花板，后者只决定最后一公里。​