RAG: 给LLM外挂知识库，文档解析、分块、向量检索与增强生成
接入AI、接入LLM是去年乃至今年年初的热门话题
公司最简单的需求是：AI智能客服要懂产品手册, 企业内部助手要懂公司的规章制度。
直接调个API对话不够垂直、不够准确，因为LLM训练的数据是有时效性、并且只有互联网公开资料。
但模型本身的训练数据集没有公司内部的文档、制度等，直接一股脑塞进上下文里也非常不优雅, 这场景的的主流方案, 就是 RAG。
RAG 的全称是 Retrieval-Augmented Generation, 中文叫检索增强生成。
为什么需要 RAG？
大模型的本质是概率推理续写: 它把训练语料里的规律压进了参数, 训练结束之后就”闭卷”了。这带来三个绕不开的问题。
知识有截止日期
训练数据停在某个时间点, 之后发生的一切模型都不知道: 上周刚改的退货政策、昨天上线的新套餐、今早发的公告, 统统不在它脑子里。
靠重新训练来更新知识既慢又贵, 而业务知识天天在变。
LLM没有私有知识
公司的产品手册、内部 wiki、客服话术、历史工单, 模型在训练时根本没见过, 再大的模型也答不出你们的差旅报销标准。
所以与其费力微调大模型，不如专攻私有知识的外挂。
LLM之幻觉
幻觉指模型生成看起来可信、实际是编造的内容。没有资料兜底时, 模型面对不知道的问题不会说”我不知道”, 而是按概率续写出一个”长得像答案的答案”。
RAG 控幻觉的机制很朴素: 把回答锚在检回的资料上, 并且可以要求模型标注出处, 让人能二次核查。
注意这里的定性——RAG 是显著降低幻觉, 不是消灭幻觉: 资料检错了, 模型照样会一本正经地基于错误资料作答。
一句话总结: RAG 把闭卷考试改成了开卷考试。
而剩下的所有工程问题都围绕同一件事展开——怎么保证翻出来的那几页, 恰好是答题需要的那几页。
七个环节: 从一堆文档到一句靠谱的回答
标准 RAG 流水线是: 文档清洗 → 切分chunk → 向量化 → 存入向量库 → 检索 → 注入提示词 → 生成。
前四步是”建图书馆”, 离线做一次、之后定期更新; 后三步是”查资料答题”, 每次用户提问都在线跑一遍。逐个拆开看。
文档清洗: 垃圾进, 垃圾出
把 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 不是标配。知识量小的时候, 把资料全文直接塞进上下文窗口, 比搭一套流水线简单
如今主流模型的上下文已经到了百万, 几十页文档整份放进去毫无压力。分块、向量化、检索这些环节全部省掉, “检索不准”这个最大的痛点也就不存在了。
判断可以用三个问题:
第一, 知识总量塞得进窗口吗——塞得进就先别上 RAG
第二, 更新频率高吗——高频更新适合 RAG, 换文档即生效, 不用动别的
第三, 需要按人控制可见范围吗——权限过滤要做在检索层, 全文塞窗口做不到。
三个问题里有两个是, 再考虑。
练习: 拿一份 FAQ 口算分块与命中
不用写任何代码。拿下面这份”报销助手 FAQ”, 人肉当一回检索系统。
PLAINTEXT
报销助手 FAQ(节选)
Q1 差旅住宿报销标准是多少?
A1 一线城市每晚上限 500 元, 其他城市 350 元, 超标部分需部门负责人
审批后按标准内金额报销。
Q2 打车费可以报销吗?
A2 因公外出打车凭发票可报, 日常通勤打车不可报; 网约车需要同时提供
行程单和发票两项凭证。
Q3 发票抬头写错了怎么办?
A3 优先联系商家换开正确抬头; 无法换开且金额在 200 元以下的, 可提交
情况说明代替。
Q4 报销款多久到账?
A4 审批通过后, 财务每周三统一打款, 一般 3 个工作日内到账。第一轮, 按固定长度切。假设每 60 字一刀, 拿笔数一数: Q1 的问题和 A1 的前半句落进块一, A1 的后半句和 Q2 落进块二——”超标怎么办”的答案和”住宿标准”的问题分了家, 这就是拦腰截断的具象化。
第二轮, 按问答对切。每个 Q 加它的 A 作为一块, 共四块, 每块语义自洽。FAQ 类文档天然适合这么切, 这也是”按结构切”的一个特例。
第三轮, 模拟一次命中。用户问: “滴滴的票能报吗?”注意, 问题里没有”打车”两个字, 纯关键词匹配会漏; 但”滴滴的票”和”网约车需要行程单和发票”意思上贴得很近。你的大脑就是最好的 embedding 模型——判断一下四个块里谁离这句话最近, 显然是 Q2 块。这就是向量检索的价值: 按意思找, 不按字面找。
第四轮, 制造一次失败。用户问: “住宿超标了但部门负责人休假, 怎么办?”Q1 块会被命中, 但资料里只写了”需部门负责人审批”, 没写负责人不在时的替代流程——检索命中了, 知识本身缺失。这类问题应该回流给知识运营去补文档, 而不是回头怪模型。把这四轮亲手走一遍, 你对分块、命中、失败归因的体感, 会比读十篇原理文章都扎实。
RAG vs 微调，怎么选？
RAG：改递给模型的资料。适合知识常变、要出处、要权限的场景。
微调：改模型权重。适合固化输出格式与风格。
一定要向量数据库吗？
不一定。知识量小塞窗口；结构化数据走SQL；术语精确用关键词。工程上常混合检索（关键词精确命中 + 向量语义兜底）。
知识库更新后回答立刻变吗？
取决于更新链路时延。新文档需走完清洗→分块→向量化→入库全流程。验收时需明确更新生效时延指标，并确认旧版本下线机制，避免新旧答案打架。
检回资料与模型记忆冲突怎么办？
输出会不稳定。工程上在提示词明确“以资料为准+标注出处”；产品上对高风险场景强制锚定出处链接，支持一键核查。
RAG 能彻底解决幻觉吗？
不能。检索错、资料错、模型无视资料三种失败模式仍存在。出处标注、置信提示、人工兜底。
