一文讲清 RAG：让 AI 读懂业务知识库的核心方法

大模型本身不认识你公司的最新制度，也不知道产品上周刚改过的价格规则。RAG 要解决的，就是让模型在回答之前先去查资料，再基于资料回答。
简单说：不要让模型闭卷瞎猜，让它开卷作答。

这篇文章想讲清楚一个问题：RAG 到底是什么，为什么它是企业知识问答、AI 客服、内部助手绕不开的一步。

很多人第一次接触 RAG，会把它理解成"向量数据库 + 大模型"。这个说法不能算错，但太粗了。真正落到生产里，RAG 不是一个组件，而是一条链路：文档怎么进来、怎么切、怎么检索、怎么重排、怎么塞进 Prompt、怎么让模型少编、怎么评估、怎么持续运营。

如果只会搭 Demo，RAG 很简单；如果要做得稳定、准确、安全、可维护，RAG 就是一套完整的工程系统。

---

一、RAG 解决的是"模型不知道业务事实"的问题

RAG，全称 Retrieval-Augmented Generation，中文通常叫"检索增强生成"。

拆开看就是两步：

1. Retrieval：先检索

   根据用户问题，从知识库里找到相关资料。

2. Generation：再生成

   把检索到的资料和用户问题一起交给大模型，让模型基于资料组织回答。

所以，RAG 的本质不是让模型"变聪明"，而是给模型接上一套外部知识系统。

没有 RAG 时，用户问：

企业版每月最多能建多少个项目？

模型可能会根据互联网上常见 SaaS 产品的描述，编出一个看似合理的答案：

企业版通常支持 100 到 500 个项目，具体取决于套餐。

听起来像那么回事，但它并不知道你的真实产品规则。

有 RAG 后，系统会先去知识库里检索"企业版""项目数量""价格政策"等内容。如果命中《价格政策 v2.1》里写着"企业版单工作区最多 200 个项目"，模型就可以基于这条资料回答，并给出来源。

这就是 RAG 最核心的价值：

让模型的回答有据可查。

但也要说清楚：RAG 不是"防幻觉开关"。它不能保证模型永远不出错。它只是把问题从"模型凭空编"变成了更可排查的工程问题：

• 是文档没进库？
• 是 chunk 切得不对？
• 是检索没召回？
• 是召回了但排序太靠后？
• 是上下文给对了，但模型没按资料答？
• 是资料本身已经过期？

错误依然可能发生，但它变得可定位、可修复、可持续优化。

---

二、RAG、微调、长上下文到底怎么选

很多人会把 RAG、微调、长上下文混在一起看，觉得它们都能让模型"更懂业务"。但这三件事解决的问题并不一样。

方式	主要解决什么	适合场景	典型问题
RAG	模型不知道哪些业务事实	知识库问答、客服、产品文档、企业内搜	检索质量决定上限
微调	模型应该怎么说话、怎么做事	输出风格、行业表达、固定任务模式	知识更新成本高
长上下文	临时让模型读一份长材料	合同阅读、报告总结、一次性分析	高频场景成本高，信噪比容易失控

一句话区分：

• RAG 管事实
• 微调管风格和行为
• 长上下文管一次性阅读

这三者并不冲突。成熟系统里，常见组合是：

RAG 接知识库，微调对齐风格，长上下文处理临时大材料。

但如果你要做企业知识问答、AI 客服、内部知识助手，通常第一步不是微调，而是 RAG。

原因很简单：业务知识会变化。价格规则会改，合同模板会改，产品说明会改，内部制度也会改。把这些知识写进模型参数里，更新一次就要重新训练，成本和维护压力都很高。

RAG 的思路更工程化：

知识放在外面，按需检索；模型负责阅读、理解和表达。

---

三、一条完整的 RAG 链路长什么样

RAG 不是"搜几段文档丢给模型"这么简单。它一般分成两个阶段：离线索引 和在线检索生成。

1. 离线阶段：把文档变成可检索的索引

离线阶段发生在用户提问之前。目标是把原始资料整理成机器能检索、能定位、能追溯的结构。

典型流程是：

接入知识源
→ 解析成文本
→ 清洗标准化
→ 切分成 chunk
→ 生成 Embedding 向量
→ 写入向量库 / 全文索引
→ 保存来源、权限、版本等元数据

知识源可能是 PDF、Word、Markdown、网页、Notion、API 文档、工单、会议纪要，也可能是数据库或业务系统里的结构化数据。

比如一份《企业版权限说明》进入系统后，通常不会整篇直接塞进向量库，而是被拆成多个片段：

• 企业版支持哪些角色；
• SSO 如何开启；
• 成员数量限制；
• 审计日志保留多久；
• 管理员权限边界。

用户问"企业版最多能加多少成员"时，系统只需要召回"成员数量限制"相关的片段，而不是把整份文档都交给模型。

这里有个很容易被低估的点：文档解析非常关键。

如果解析阶段丢掉了标题层级、表格结构、编号条款、页码、版本号，后面的检索和引用都会受影响。很多 RAG 效果差，并不是模型不行，而是文档从一开始就没处理好。

2. 在线阶段：用户提问时发生什么

在线阶段发生在每次用户提问时。

典型流程是：

接收问题
→ 必要时做 Query 改写
→ 问题转向量
→ 向量检索 + 关键词检索
→ 融合多路结果
→ 权限和元数据过滤
→ 重排候选结果
→ 压缩去重
→ 拼接 Prompt
→ 模型生成回答
→ 返回答案和引用来源
→ 记录日志和反馈

生产级 RAG 很少是"检索 Top-K 后直接塞给模型"。更常见的是漏斗结构：

1. 先多路召回，宁可多捞一点；
2. 再重排，把真正相关的片段排上来；
3. 最后只把少量高价值上下文交给模型。

这一步决定了回答质量。因为模型再强，也不能凭空回答没有召回到的资料。

RAG 的上限，通常先由检索决定，再由生成决定。

---

四、Embedding：让机器理解"语义相近"

RAG 的语义检索能力，主要建立在 Embedding 上。

Embedding 做的事情是把文本转换成向量。向量可以理解成一串数字，但它背后表达的是文本在语义空间里的位置。

比如：

• "猫"和"小猫"语义接近，向量距离也接近；
• "猫"和"路由器"语义无关，向量距离就比较远；
• "企业版项目数量上限"和"企业版最多能创建多少项目"，虽然字面不同，但语义接近，也应该被检索到一起。

检索时，系统会把用户问题也转成向量，然后去向量库里找距离最近的 chunk。

这就是语义检索的基本逻辑。

1. 相似度一般怎么算

文本向量常用 余弦相似度 来衡量相近程度。

它关注的是两个向量方向是否接近，而不是长度。对文本语义来说，"方向"通常比"长度"更重要。

很多 Embedding 模型会对输出做归一化。归一化后，余弦相似度、点积、欧氏距离在排序上可能接近，但工程上还是要以模型文档和向量库推荐配置为准。

2. Embedding 模型怎么选

不要只看榜单。要同时看这些因素：

• 中文 / 英文 / 多语种支持；
• 最大输入长度；
• 输出维度；
• 部署方式：本地还是 API；
• 成本和延迟；
• 数据是否允许出域；
• 向量库兼容性；
• 你自己的业务评测结果。

中文知识库可以优先看 BGE 系列；多语种可以看 BGE-M3、E5 multilingual、Cohere、Voyage；快速接入可以用 OpenAI Embedding；本地教学和小项目可以用 MiniLM。

这里有一个绝对不能踩的坑：

入库用模型 A，查询换成模型 B。

不同 Embedding 模型的向量空间不是一回事。入库和查询如果混用，检索结果基本会变成噪音。换模型就意味着要全量重建向量，没有捷径。

---

五、Chunking：文档切分决定召回质量

文档切分，也就是 Chunking，是 RAG 里最容易被低估的环节。

很多人一开始会把注意力放在向量库、模型、Prompt 上，但实际项目里，chunk 切得好不好，往往直接决定检索效果。

1. 为什么一定要切分

主要有三个原因：

• Embedding 模型有最大输入长度，文档太长会被截断；
• 长文本向量容易被稀释，主题不够聚焦；
• 用户问题通常是局部问题，检索粒度也应该足够细。

用户问"企业版如何开启 SSO"，你希望召回的是"SSO 配置流程"这一段，而不是整本《企业版管理员手册》。

2. 切太小和切太大都会出问题

切太小，容易丢上下文。

比如一个 chunk 只有一句：

最长可设置为 30 天。

这句话单独看没有意义。到底是 Token 过期时间、项目保存周期，还是试用期？模型不知道。

切太大，语义又会不聚焦。

一个 chunk 里同时包含登录、安全、计费、权限四个主题，用户问计费时，向量可能被其他内容稀释，反而召回不出来。

3. 常见切分策略

策略	特点	适合场景
固定长度切分	简单粗暴，按字数或 Token 切	原型验证
递归切分	优先按标题、段落、句子等自然边界切	通用文档，最常用
句子切分	以完整句子为单位	FAQ、客服问答
语义切分	根据话题变化切分	主题跳跃明显的长文档
Parent-Child	小块检索，大块给模型	长报告、合同、复杂说明书

4. 中文切分要额外注意

中文没有天然空格，如果切分器只按英文空格处理，效果会很差。

更稳妥的做法是显式配置中文分隔符，例如：

。 ！ ？ ； ，
换行
段落边界
标题边界

还要注意中英文混排、全角半角、书名号、专有名词、省略号、表格内容等细节。

RAG 里很多"检索不准"，最后排查下来不是模型问题，而是切分阶段把语义结构切坏了。

---

六、向量数据库：在海量向量里快速找相似内容

chunk 切好、向量生成好之后，需要一个地方存储和检索它们。这就是向量数据库要做的事。

常见选择包括：

• pgvector：已有 Postgres 时很方便；
• Pinecone：全托管，省运维；
• Milvus：开源分布式，适合大规模；
• Qdrant：Rust 实现，单机性能强；
• Weaviate / Chroma：适合不同规模和开发场景；
• Faiss：更偏算法库，不是完整数据库；
• Elasticsearch k-NN：适合已有 ES 体系的团队。

1. 为什么不能直接暴力搜索

最朴素的做法是：用户问题转向量后，和库里每一个 chunk 向量都算一遍距离，再排序。

这叫精确最近邻，也就是 KNN。

问题是数据一大就慢。百万级、千万级文档下，逐个计算距离不可接受。

所以生产里通常使用 ANN：Approximate Nearest Neighbor，近似最近邻。

它牺牲一点点召回率，换来大幅速度提升。RAG 不需要数学意义上的绝对最近邻，只需要在可接受延迟内找到足够相关的资料。

2. HNSW、IVF、PQ 怎么理解

HNSW 是最常见的 ANN 算法。可以粗略理解成一张多层导航图：高层节点少，用来快速跳转；底层节点多，用来精细搜索。

特点是查询快、召回高、参数好调，但内存占用大，建索引也比较慢。中小规模 RAG 里，它通常是默认选择。

IVF 是先聚类再检索。把向量分成很多簇，查询时只查最接近的几个簇。它更省内存，适合更大规模，但召回率通常不如 HNSW。

PQ 是向量压缩。把高维 float 向量压成更小的表示，节省存储和内存，但会损失精度。

一个粗略选型可以这样看：

数据规模	优先考虑
100 万以下	HNSW
100 万到 1000 万	HNSW 或 IVF，看内存和延迟要求
1000 万以上	IVF + PQ 或分布式方案

---

七、只靠向量检索不够：还需要混合检索和重排

向量检索擅长语义匹配。

用户问"怎么开通单点登录"，文档写"SSO 配置流程"，向量检索一般能对上。

但它不擅长所有问题。遇到下面这些内容时，关键词检索往往更可靠：

• 错误码：ERR_AUTH_403
• 接口名：createProject
• 合同编号：CN-2026-001
• 政策版本：v2.1
• 专有名词、字段名、配置项

所以生产级 RAG 通常会做 混合检索：

向量检索负责语义召回，BM25 负责关键词匹配。

然后用融合算法把两路结果合并。常见做法是 RRF：Reciprocal Rank Fusion。

RRF 不直接比较分数，因为向量相似度和 BM25 分数不是一个量纲。它看的是排名：一个结果如果在向量检索和关键词检索里都排得靠前，那它就更值得被保留。

重排：把"召回候选"变成"精选上下文"

粗排召回之后，还需要重排。

向量检索通常使用 Bi-Encoder：问题和文档分别编码成向量，再算距离。速度快，但排序精度有限。

重排通常使用 Cross-Encoder：把问题和候选文档拼在一起，让模型直接判断相关性。它更准，但更慢，所以只能用于少量候选。

一个常见漏斗是：

向量检索 + BM25 + RRF
→ 召回 Top-50
→ Cross-Encoder 重排
→ 选 Top-5 给大模型

如果 RAG 效果不好，优先检查这一步。很多时候，加一个可靠的 reranker，比盲目换更大的生成模型更有效。

---

八、生成环节：Prompt 不是越长越好

检索完成后，还要把资料组织好，再交给模型。

一个比较稳的 RAG Prompt 通常包含：

• 角色说明：你是基于知识库回答问题的助手；
• 约束规则：只能基于上下文回答，不要自行推测；
• 回退策略：资料不足时明确说无法确定；
• 引用要求：回答要能对应来源；
• 检索上下文：标题、来源、章节、更新时间、相关片段；
• 用户问题：放在最后，让模型读完资料再回答。

但要注意：上下文不是越多越好。

Top-50 全塞进去，结果通常是：

• 成本上升；
• 噪音变多；
• 模型注意力分散；
• 引用更容易混乱；
• 回答反而不稳定。

更好的做法是：

• 去重；
• 合并相邻 chunk；
• 删除低分结果；
• 保留关键句；
• 保留数字、时间、版本、权限条件；
• 不要删掉否定词和限制条件。

RAG Prompt 的目标不是把所有资料塞给模型，而是把足够支撑回答的最小上下文交给模型。

---

九、RAG 怎么评估：不要靠感觉

RAG 好不好，不能只靠"我问了几个问题感觉还行"。

评估要拆成两层：检索质量 和生成质量。

1. 检索指标

指标	看什么
Recall@K	前 K 个结果里，该找到的内容有没有被找到
MRR	第一个相关结果排在第几位
NDCG@K	相关性和排序位置是否都合理

检索指标回答的是：

资料有没有找对，排得够不够靠前。

2. 生成指标

指标	看什么
Faithfulness	回答是否忠实于检索资料，有没有编造
Answer Relevancy	回答是否真正回应了用户问题
Context Precision	检索结果里有多少是真正有用的
Context Recall	需要的上下文是否都被检索到了

生成指标回答的是：

资料给对之后，模型有没有好好用。

3. 评测集比单次调参更重要

没有评测集，就很难知道一次改动到底是变好了还是变差了。

一个实用评测集至少包含：

• 用户问题；
• 标准答案；
• 相关文档 ID；
• 容易混淆的 hard negative；
• 是否应该拒答；
• 期望引用来源。

评测问题最好来自真实业务：客服高频问题、搜索日志、FAQ、错误案例、用户差评、人工转接记录。

每次改 Embedding 模型、chunk 策略、Top-K、reranker、Prompt，都应该跑回归评测。

没有评测的 RAG，最后很容易越调越玄学。

---

十、召回率怎么提升

RAG 效果不好时，很多人第一反应是换更强的生成模型。但资料没召回来，模型再强也没用。

提升召回率可以从几件事入手：

1. Query 改写

用户问题往往短、口语化、不完整。

比如用户问：

登不上去怎么办？

直接拿这句话检索，效果可能一般。可以先改写成：

用户登录失败的常见原因和解决方法。

但 Query 改写要保留关键约束，尤其是时间、数字、否定、版本号、产品名。改写不能改变用户原意。

2. 多路召回

同一个问题可以生成多个查询表达，分别检索后合并去重。

适合用户表达和文档表达差异很大的场景。

3. 混合检索

向量 + BM25 是生产 RAG 的基本配置。只做向量检索，很容易漏掉错误码、接口名、编号、版本号这类精确关键词。

4. 重排

先粗排召回较多候选，再用 Cross-Encoder 精排。它通常是提升 RAG 质量性价比最高的手段之一。

5. 元数据过滤

按权限、产品线、文档类型、更新时间、语言、版本号过滤，既能减少无关结果，也能提升速度。

比如用户问的是中国区价格，就不要把海外区定价文档召回进来。

---

十一、高级 RAG 模式：先别急着上

基础 RAG 没做好之前，不建议一上来就 Graph-RAG、Self-RAG、Adaptive-RAG 全家桶。

这些模式有价值，但也会增加调试难度。大多数系统，先把文档解析、chunk、混合检索、重排、权限、评测做好，收益会更明显。

常见高级模式可以这样理解：

模式	核心思路	适合场景
HyDE	先让模型生成一个假想答案，再用假想答案检索	短问题、口语化问题
Self-RAG	让模型判断是否需要检索、结果是否可靠	闲聊和知识问答混合系统
CRAG	引入评估器判断检索质量，不好就改写或兜底	知识库覆盖不完整的场景
Adaptive-RAG	按问题复杂度选择是否检索、检索几次	需要控制成本和延迟的系统
Graph-RAG	构建知识图谱，回答跨文档全局问题	战略分析、长期趋势、复杂组织知识

一句话建议：

先把基础 RAG 做稳，再考虑高级模式。

否则很容易变成"链路更复杂了，问题更难排查了，但效果没有明显提升"。

---

十二、生产落地最容易被忽略的三件事

1. 权限：不能等到生成阶段再处理

企业 RAG 最大的区别是权限。

不能先召回全库最相关内容，再指望模型"不要说无权限内容"。内容一旦进入上下文，就已经有泄露风险。

正确做法是在检索阶段就过滤：

• 用户权限；
• 团队权限；
• 文档权限；
• 数据源权限；
• 行级 / 字段级权限；
• 版本和可见范围。

权限不是附加功能，而是企业 RAG 的基础能力。

2. 可观测性：要能解释为什么答错

每次请求最好记录：

• 用户问题；
• 改写后的 Query；
• 命中的文档和 chunk；
• 向量分数、BM25 分数、重排分数；
• 最终进入 Prompt 的上下文；
• 模型回答；
• 引用来源；
• Token 消耗；
• 延迟；
• 用户反馈。

这些日志能回答几个关键问题：

• 是没检索到，还是检索到了但没用好？
• 是文档过期，还是 Prompt 约束不够？
• 哪些文档经常被引用？
• 哪些问题经常没有答案？
• 哪类问题最容易转人工？

没有可观测性，RAG 就很难持续优化。

3. 持续运营：RAG 更像搜索系统，不是一次性脚本

RAG 系统搭起来只是开始，后面还要持续维护：

• 新文档入库；
• 旧文档更新；
• 过期文档下线；
• 权限同步；
• 评测集更新；
• 用户反馈分析；
• 检索参数调优；
• 模型升级评估；
• 索引重建；
• 成本和延迟监控。

业务知识本身在变化，RAG 系统也必须跟着变化。

---

十三、常见问题速查

问题	优先排查
检索不相关	Embedding 模型是否一致、chunk 是否合理、Top-K 是否太小、是否缺 BM25
明明有资料但搜不到	文档是否入库、权限过滤是否过严、关键词是否被切坏、版本是否正确
回答有幻觉	检索上下文是否正确、Prompt 是否要求基于资料回答、是否有拒答机制
中文效果差	Embedding 是否适合中文、中文切分是否正确、BM25 是否有中文分词
换模型后效果崩了	入库和查询是否用了不同 Embedding 模型；如果换了，需要重建向量
延迟高	索引是否正确、ef_search 是否过大、重排候选是否太多、Embedding API 是否太慢
成本高	Top-K 是否过大、上下文是否冗余、是否缺压缩、输出是否过长

---

十四、结论：RAG 的本质是"检索系统 + 阅读模型"

RAG 的核心逻辑其实不复杂：

用户提问
→ 检索相关资料
→ 把资料交给模型
→ 基于资料生成回答

但要把它做好，需要把每个环节都当成工程问题来处理。

可以用一句话概括 RAG 的本质：

把检索系统当成模型的长期记忆，把模型当成会阅读和表达的执行器。

检索系统负责：

• 存储知识；
• 更新知识；
• 按需检索；
• 保留来源；
• 控制权限；
• 支持评估和追踪。

模型负责：

• 理解问题；
• 阅读资料；
• 组织答案；
• 给出自然语言回复。

普通 RAG 能跑通 Demo：切块、向量化、入库、检索、塞给模型。

生产级 RAG 还需要：

• 稳定的文档解析；
• 合理的 chunk 策略；
• Embedding 模型评测和版本管理；
• 混合检索；
• 重排；
• 权限过滤；
• 引用回写；
• 拒答机制；
• 上下文压缩；
• 评测集；
• 监控日志；
• 成本控制；
• 增量更新；
• 用户反馈闭环。

所以，RAG 的难点不在"跑通"，而在：

稳定、准确、安全、可持续。

它让 AI 不再只是一个会聊天的模型，而是一个能读取业务知识、理解上下文、基于事实回答问题的助手。

---

写在最后🧪

这里是言萧凡的 AI 编程实验室 。我会在这里持续记录和分享 AI 工具、编程实践 ，以及那些值得沉淀下来的高效工作方法。不只聊概念，也尽量分享能直接上手、能够复用的经验。希望这间小小的实验室，能陪你一起探索、实践和成长。2026 年，一起进步。
有兴趣的话可以添加我的微信号 Cookieboty 一起交流，不仅是编程也可以是畅谈人生