RAG 入门: 知识库分块、向量检索与增强生成

“把公司知识库接进 AI”几乎是每个 AI 产品经理都会接到的第一单需求: 智能客服要懂产品手册, 内部助手要懂规章制度, 销售工具要懂最新报价单。但模型本身不认识你公司的任何一份文档, 让它”认识”的主流方案, 就是 RAG。学完这一课, 你能独立画出 RAG 的整条流水线, 听懂工程师嘴里的分块、向量、召回, 并且在效果不好时知道该去查哪个环节, 而不是笼统地说一句”模型不行”。

RAG 的全称是 Retrieval-Augmented Generation, 中文叫检索增强生成。白话版本: 模型答题之前, 系统先去资料库里把最相关的几页翻出来, 摊在它面前, 让它照着资料回答。最贴切的类比是开卷考试——学生(模型)的水平没变, 但允许带资料进场, 于是答案质量和”带对资料”强相关, 而不再只取决于它脑子里记了什么。

这是《AI 产品经理课》的第七课。前面几课里你已经会写结构化提示词、能用一段提示词搭出最简智能体, 这一课解决它们共同的软肋: 不懂你的私有知识。全程不写代码, 但会拆到你能和工程团队逐环节对齐验收标准的程度。更多同系列内容可以在 AI 产品经理专题里找到。

本文是《AI 产品经理课》第 7 课 · 专题目录 · 学习路线 · 上一课: 第 6 课 · 下一课: 第 8 课

全部 13 篇目录

为什么需要 RAG: 模型有三个天生短板

第一课讲过, 大模型的本质是概率续写: 它把训练语料里的规律压进了参数, 训练结束之后就”闭卷”了。这带来三个绕不开的问题。

知识有截止日期

训练数据停在某个时间点, 之后发生的一切模型都不知道: 上周刚改的退货政策、昨天上线的新套餐、今早发的公告, 统统不在它脑子里。靠重新训练来更新知识既慢又贵, 而业务知识天天在变——这条路走不通, 必须有一条”随时把新资料递给模型”的通道。

私有知识不在训练数据里

你公司的产品手册、内部 wiki、客服话术、历史工单, 模型在训练时根本没见过, 再大的模型也答不出你们的差旅报销标准。站内那篇内部 AI 推广实战记录过一个很有代表性的转变: 团队把大量精力从”调模型”挪到了”收拾内部文档”, 因为私有知识的搬运和治理才是落地的主战场。类似地, 基于 Java 的 RAG 全流程实现这类教程, 核心工作量也在”接入飞书 wiki”那一侧, 而不是模型那一侧。

幻觉: 一本正经地编

幻觉指模型生成看起来可信、实际是编造的内容。没有资料兜底时, 模型面对不知道的问题不会说”我不知道”, 而是按概率续写出一个”长得像答案的答案”。RAG 控幻觉的机制很朴素: 把回答锚在检回的资料上, 并且可以要求模型标注出处, 让人能核查。注意这里的定性——RAG 是显著降低幻觉, 不是消灭幻觉: 资料检错了, 模型照样会一本正经地基于错误资料作答。

一句话总结: RAG 把闭卷考试改成了开卷考试。而剩下的所有工程问题都围绕同一件事展开——怎么保证翻出来的那几页, 恰好是答题需要的那几页。

七个环节: 从一堆文档到一句靠谱的回答

标准 RAG 流水线是: 文档清洗 → 分块 → 向量化 → 存入向量库 → 检索 → 注入提示词 → 生成。前四步是”建图书馆”, 离线做一次、之后定期更新; 后三步是”查资料答题”, 每次用户提问都在线跑一遍。逐个拆开看。

文档清洗: 垃圾进, 垃圾出

把 PDF、Word、网页、扫描件统一转成干净的纯文本: 去页眉页脚、修复乱码、剥离水印、处理图片里的文字。这一步最没有技术光环, 却常常吃掉项目一半以上的工时。一个经验判断: 演示时用三份干净文档效果惊艳, 上线接全量历史文档后效果崩盘, 多半就是清洗没做够。

分块: 把书拆成卡片

分块(chunking)指把长文档切成几百字左右的小段, 每段叫一个”块”。为什么必须切: 其一, 检索是按块进行的, 块太大, 找回来一整章、真正有用的只有两行, 白白挤占上下文窗口; 其二, 窗口再大也塞不下整个知识库。类比图书馆: 不是整本书借给你, 而是把内容拆成索引卡片, 按需抽卡。切法有讲究, 它是效果差异的主要来源之一, 下一节单独展开。

向量化: 给语义装上坐标

向量化(embedding)是把一段文字变成一串数字坐标, 使得”语义相近的文字, 坐标也相近”。”怎么退款”和”退货流程”字面上几乎不重合, 但坐标离得很近——这正是它比关键词匹配强的地方。做这件事的是专门的 embedding 模型, 和你对话用的生成模型是两个东西, 调用成本通常也低得多。

向量库: 按语义距离找邻居

向量库是存所有块坐标、支持”给一个坐标, 找出离它最近的若干块”的数据库。具体选型对产品经理是工程细节, 你只需要知道它不是唯一路线: 站内 SAG 细读就讨论过用传统 SQL join 实现 RAG 的方案; 关键词检索在术语精确的场景里依然能打, 工程上经常两者混用、互补短板。Claude Code 专题下的不少实践讨论, 就是围绕 AI 编程场景里”关键词找得准还是向量找得准”展开的。

检索: 用户的问题也变成坐标

用户提问后, 同一个 embedding 模型把问题变成坐标, 向量库找出最近的 top-k 个块。top-k 就是”取前 k 名”, k 通常是个位数到十几。这一步的输出直接决定模型”看到什么资料”——它是整条流水线的咽喉。

注入提示词与生成

把检回的块和用户问题一起, 按第二课讲的结构化方式组装成提示词: 系统提示里写清规则(“只根据资料回答, 资料里没有就明说”), 资料区用分隔符包好, 最后放用户问题。检回内容太多太杂时, 还可以在进大模型之前再加一道压缩——站内报道过 Kapa 用小模型修剪 RAG 上下文的做法, 把不相关的段落先剪掉, 又省钱又减少干扰。

分块策略: 三种切法, 各有取舍

切法	优点	代价	适合
固定长度	实现最简单, 什么格式都能切	会拦腰截断语义	兜底方案、格式杂乱的文档
段落/语义	块内语义自洽	块长参差, 超长段落仍需二次切	文章、报告类
标题层级	每块自带章节路径, 上下文最好	依赖文档本身结构良好	手册、制度、API 文档

固定长度切

每 N 个字符一刀, 简单可靠。代价是”拦腰截断”: 一条退款政策可能被切进两个块, 只检回其中一半, 答案就是残缺的。常见补救是相邻块之间保留一段重叠, 能缓解、不能根治。

按段落或语义切

沿自然段和句子边界下刀, 块内语义自洽。缺点是块的长度不齐, 碰上超长段落还得二次切; 对”段落本来就乱”的内容(比如聊天记录导出)不好使。

按标题层级切

沿文档的章节结构切, 每块记住自己属于哪一章哪一节, 命中后能顺藤摸瓜补全上下文。这是结构良好文档的首选, 前提是文档真的有结构——很多企业文档并没有。

最大的坑: 表格与格式混乱

表格被按行切碎后, 数字和表头分了家: “上限 500 元”检回来了, 却不知道是哪个城市、哪种场景的上限。这类”检回了错误组合”的答案, 比”答不出来”危险得多。扫描版 PDF、双栏排版、藏在图片里的文字, 同理。产品经理在这里能做的最有性价比的一件事: 立项时就盘点知识源的格式构成, 价格表、参数表这类表格密集型知识, 考虑单独走结构化查询, 别硬塞进 RAG 管道。

检索质量决定上限: 召回不对, 后面全白搭

召回, 白话就是”该找到的资料有没有被找到”。生成环节只是”照着资料写作文”: 资料对, 作文顶多写得不够流畅; 资料错, 作文越流畅越害人。所以 RAG 的效果上限, 在检索环节就已经定死了。

这直接决定了正确的评估姿势: 不能只看最终回答, 要分环节测。先建一个对照集——几十到几百条”问题 → 应该命中的文档块”, 单独度量检索环节的命中情况; 检索达标了, 再往下测生成环节的忠实度。站内 RAG 项目实战复盘的结论足够直白: 数据和评测比模型调优重要, 大多数翻车项目都输在前者。上线之后同理, 用户的踩与赞、反复改写提问的行为都是信号, 要回流去修数据和检索——NVIDIA 的内部 RAG 助手干脆为此搭了一个数据飞轮, 让”评估—修正”持续转下去。

产品经理的角色在这一节最清晰: 你不需要会调检索参数, 但对照集里”哪些问题必须答对”必须由你来定, 这就是验收标准, 也是你对这个系统最大的掌控点。

顺手给一张排障速查表, 效果不好时按症状找环节:

答案是编的 → 先查检索: 是不是压根没检到相关块, 模型被迫硬写
答案是残缺的 → 先查分块: 是不是政策被拦腰切断
答非所问 → 先查清洗: 是不是文本本身就是乱的
知识过时 → 先查更新链路: 新文档到底进没进库

什么时候不用 RAG

RAG 不是标配。知识量小的时候, 把资料全文直接塞进上下文窗口, 比搭一套流水线简单一个数量级——如今主流模型的上下文窗口已经到了百万 token 量级, 几十页文档整份放进去毫无压力。分块、向量化、检索这些环节全部省掉, “检索不准”这个最大的失败模式也就不存在了。

判断可以用三个问题: 第一, 知识总量塞得进窗口吗——塞得进就先别上 RAG; 第二, 更新频率高吗——高频更新适合 RAG, 换文档即生效, 不用动别的; 第三, 需要按人控制可见范围吗——权限过滤要做在检索层, 全文塞窗口做不到。三个问题里有两个答”是”, 再考虑立项。

个人和小团队场景尤其如此: Obsidian 本地知识库实战这类方案里, 很多环节其实就是”把相关笔记直接递给模型”, 未必有严格意义上的向量检索。另外, 别把知识库和”记忆”混为一谈: 知识库是团队共享的事实, 记忆是某个智能体自己积累的经验, codex-brain 的外挂知识库方案和基于 Obsidian 的个人档案实践都偏后者。两者架构上要分开设计, 第八课讲 Agentic RAG 时会展开这条边界。

产品视角: 知识库产品的成本在数据侧

估算 RAG 产品成本时, 多数人的直觉是模型调用费, 但真实的大头在数据侧, 而且是持续性支出:

清洗: 一次性投入最大的环节, 而且新格式会源源不断进来, 永远清不完
更新: 知识库是活的——谁负责更新、多久同步一次、旧版本文档怎么下线, 没有 owner 的知识库三个月就烂掉, 新旧两版政策同时被检回时, 答案会自己打架
权限: 薪酬文档不能被普通员工的提问检回来。权限过滤必须做在检索层, 因为模型看到的每一个字, 都是它可能说出去的每一个字

所以知识库产品是运营型产品, 不是一次性交付的项目, 上线只是运营的开始。写 PRD 时, 记得把”知识运营的人力和流程”作为成本项明确列出来——这笔账常常比 API 账单大。顺带一提, 团队里也会有人问”要不要干脆上多智能体架构”, 这类架构层面的权衡可以先放一放: 检索质量没达标之前, 换架构解决不了数据的问题, 感兴趣可以在 AI 智能体专题里看相关讨论。

动手练习: 拿一份 FAQ 口算分块与命中

不用写任何代码。拿下面这份自制的”报销助手 FAQ”(内容为教学虚构), 人肉当一回检索系统。

报销助手 FAQ(节选)

Q1 差旅住宿报销标准是多少?
A1 一线城市每晚上限 500 元, 其他城市 350 元, 超标部分需部门负责人
   审批后按标准内金额报销。

Q2 打车费可以报销吗?
A2 因公外出打车凭发票可报, 日常通勤打车不可报; 网约车需要同时提供
   行程单和发票两项凭证。

Q3 发票抬头写错了怎么办?
A3 优先联系商家换开正确抬头; 无法换开且金额在 200 元以下的, 可提交
   情况说明代替。

Q4 报销款多久到账?
A4 审批通过后, 财务每周三统一打款, 一般 3 个工作日内到账。

第一轮, 按固定长度切。假设每 60 字一刀, 拿笔数一数: Q1 的问题和 A1 的前半句落进块一, A1 的后半句和 Q2 落进块二——”超标怎么办”的答案和”住宿标准”的问题分了家, 这就是拦腰截断的具象化。

第二轮, 按问答对切。每个 Q 加它的 A 作为一块, 共四块, 每块语义自洽。FAQ 类文档天然适合这么切, 这也是”按结构切”的一个特例。

第三轮, 模拟一次命中。用户问: “滴滴的票能报吗?”注意, 问题里没有”打车”两个字, 纯关键词匹配会漏; 但”滴滴的票”和”网约车需要行程单和发票”意思上贴得很近。你的大脑就是最好的 embedding 模型——判断一下四个块里谁离这句话最近, 显然是 Q2 块。这就是向量检索的价值: 按意思找, 不按字面找。

第四轮, 制造一次失败。用户问: “住宿超标了但部门负责人休假, 怎么办?”Q1 块会被命中, 但资料里只写了”需部门负责人审批”, 没写负责人不在时的替代流程——检索命中了, 知识本身缺失。这类问题应该回流给知识运营去补文档, 而不是回头怪模型。把这四轮亲手走一遍, 你对分块、命中、失败归因的体感, 会比读十篇原理文章都扎实。

FAQ

RAG 和微调有什么区别, 该选哪个?

RAG 改的是”递给模型的资料”, 微调改的是模型本身的权重。知识类需求——内容常变、要出处、要权限——选 RAG; 输出格式和风格的固化需求才考虑微调。第十一课会给出完整的决策顺序: 提示词、few-shot、RAG、微调逐级升舱, 大多数需求根本走不到最后一级。

做 RAG 一定要向量数据库吗?

不一定。向量库只是”按语义找邻居”的一种实现: 知识量小可以直接全文塞窗口; 结构化数据可以走 SQL 查询; 术语精确的场景里关键词检索反而更稳。工程上常见的是混合检索——关键词负责精确命中, 向量负责语义兜底, 两条腿走路。

知识库更新了, 模型的回答会立刻变吗?

取决于更新链路。新文档要走完清洗、分块、向量化、入库这条离线管道, 检索才可能命中它。验收知识库产品时, 要明确”从文档更新到回答生效”的时延指标, 同时确认旧版本文档的下线机制——旧文档不删干净, 新旧答案会互相打架。

检回来的资料和模型自己的记忆冲突了怎么办?

会发生, 而且输出不稳定: 资料说 A, 训练记忆说 B, 模型可能各答一次。工程上的缓解是在提示词里明确”以资料为准, 资料没有就明说”, 并要求标注出处; 产品上的缓解是把价格、合规这类高风险场景的回答强制锚到出处链接, 让用户能一键核查。

RAG 能彻底解决幻觉吗?

不能。它把”凭空编造”的概率显著压低, 但检索检错、资料本身有错、模型无视资料这三种失败模式都还在。所以带 RAG 的产品依然需要出处标注、置信提示和人工兜底通道——这些是产品设计的责任, 别指望模型自己解决。

结语

RAG 的原理一句话能讲完, 难的是把检索质量做成可度量、可运营的系统。把验收标准握在自己手里, 你就握住了这条流水线最关键的阀门。第八课, 我们把检索的决定权交给智能体。