主题
2.8 RAG 知识库与向量存储：给 AI 备一本随时可查的“开卷参考书”
回答公司的报销规则时，与其凭印象回忆，不如先查现行制度，再结合具体情况解释。RAG（检索增强生成）把这个过程放进应用：先取回相关资料，再让模型依据资料组织答案。它提供事实依据，但不能保证检索与回答永远正确。
为什么需要在生成前检索资料
大模型之所以会“一本正经胡说八道”，是因为它的训练数据有截止日期，且它完全不知道你公司的内部私有制度。
- 如果你去问一个刚毕业的大学生：“我们公司今年出差住酒店每晚报销上限是多少？”
- 学生就算再聪明也答不上来，只能瞎猜。
- 但如果你把**《2026年公司最新差旅报销制度.pdf》**递到他手里说：“翻开第 5 页，念给我听”，他就有了核对数字的依据，同时仍需确认适用条件与版本。这就是 RAG（检索增强生成） 的本质。
什么是 Embedding（向量化）？—— 相亲角红娘打分大比喻
计算机根本不认识汉字，它如何知道“西红柿”和“番茄”是同一个东西？
- 相亲角打分雷达图比喻：
- 红娘把每个人的条件量化成一串多维数字坐标：
[年龄, 身高, 年收入, 兴趣爱好倾向, ...]； - 当两个人的多维坐标在几何空间里的**夹角极小（余弦相似度 Cosine Similarity 极高）**时，红娘就会把他们精准匹配在一起。
- 红娘把每个人的条件量化成一串多维数字坐标：
"西红柿炒蛋" ➔ [ 0.92, -0.31, 0.88, ... ]
"番茄炒鸡蛋" ➔ [ 0.91, -0.30, 0.87, ... ] (空间距离贴近。数值仅作示意，不代表实测相似度)
"挖掘机修理" ➔ [-0.45, 0.82, -0.61, ... ] (空间距离遥远。数值仅作示意)文档切块（Chunking）与重叠（Overlap）千层饼心法
把一本 500 页的《产品手册》存入向量数据库前，通常按章节、段落或长度整理成适合检索的片段（Chunks），并保留来源；500 字只是可试验的起点：
- 什么时候需要片段重叠（Overlap）？：
- 如果刚好一句话在正中间被切断（“前一半在第 1 块，后一半在第 2 块”），语义就支离破碎了。保留 50 字的重叠就像“做千层饼”，可以减轻切断上下文的问题，但不能保证信息不遗漏。
混合检索（Hybrid Search）与重排（Rerank）—— 选秀大赛大比喻
工业级 RAG 之所以准，是因为它采用了**“海选 + 决赛精评”**的两阶段打法：
主流向量数据库工具与资源与官网
| 向量数据库 | 官网链接 | 核心定位与特色 |
|---|---|---|
| Qdrant | https://qdrant.tech | 用 Rust 语言编写的高性能开源向量数据库，响应极快、内存占用极低 |
| Pinecone | https://www.pinecone.io | 云原生托管向量库，减少自行维护检索基础设施的工作 |
| Milvus | https://milvus.io | 专为百亿级超大规模数据检索打造的开源工业级分布式向量数据库 |
| Chroma | https://www.trychroma.com | 最适合本地实验和小项目的轻量级开源嵌入式向量库，Python 几行代码跑通 |
| pgvector | https://github.com/pgvector/pgvector | PostgreSQL 的开源向量扩展，无需额外买新数据库，在已有 SQL 库里直接存向量 |
RAG 的进化：从标准 RAG 到 LLM Wiki
前面讲的“检索 → 增强 → 生成”是最基础的标准 RAG（Naive RAG）。随着应用越来越复杂，业界又进化出了更聪明的形态：
| 形态 | 核心思路 | 生活比喻 | 适合场景 |
|---|---|---|---|
| 标准 RAG | 一次检索、一次生成，直接给答案 | 翻一次书、照着念 | 简单问答、FAQ、私有制度查询 |
| Agentic RAG | 用 Agent 自主决定“查不查、查几次、怎么查”，可多轮迭代 | 有脑子的图书管理员，自己判断要不要再查 | 复杂多步问题、需要推理判断的场景 |
| 图 RAG | 把实体与关系建成知识图谱，支持全局 / 多跳推理 | 查“人物关系族谱图”，不只看单页 | 全局总结、实体关系、多跳问答 |
1. 标准 RAG（Naive RAG）：一把梭的“翻书—照念”
- 流程：用户提问 → 向量检索最相关的 chunks → 拼进提示词 → 生成回答；
- 优点：实现简单、速度快、成本低，覆盖大多数常见场景；
- 缺点：只做一次检索，问题绕一点就答不准；对“全局性”问题（如“这整个项目到底讲了什么”）几乎无能为力。
2. Agentic RAG：有脑子的“图书管理员”
- 本质：在 RAG 外面套一层 Agent，让模型自己决定要不要查、用什么工具查、查完是否还要再查；
- 不再是机械地翻一次书，而是会追问的管理员——“您要 2026 年版本还是 2025 年版本？我再翻两本交叉验证一下再回答您。”
- 优点：能处理多步、复杂的检索任务，有机会提高复杂问题的完整性，需通过评估确认；
- 缺点：引入循环，更慢、更烧 Token（呼应 2.4 章的 Agent 机制）。
3. 图 RAG（GraphRAG）：能查“关系网”的知识图谱
- 本质：先把文档抽成**“实体 + 关系”的知识图谱**（如“小明 —任职于→ 科技公司 —研发→ AI 系统”），再在图上做全局检索与多跳推理；
- 标准 RAG 是“翻到某一页”，图 RAG 是“查一张人物关系族谱图”，能顺着关系一路推演；
- 典型能力：
- 全局总结：“这份 500 页报告的核心主题是什么？”（标准 RAG 很难答好）；
- 多跳推理：“哪些员工同时参与过 A 和 B 两个项目？”
- 代表实现：微软开源的 GraphRAG。
4. 进阶 RAG（Advanced RAG）与模块化 RAG（Modular RAG）
- 进阶 RAG：在标准 RAG 的“检索前 + 检索后”两个环节做精细化优化：
- 检索前（Pre-retrieval）：查询改写 / 查询路由 / 切块优化，让问题问得更准；
- 检索后（Post-retrieval）：重排（Rerank）/ 上下文压缩，只把最精华的部分提供给模型（呼应前面“海选 + 决赛精评”）；
- 模块化 RAG：一种组织方式——把整个流程拆成检索、记忆、融合、路由、预测等独立模块，像搭积木一样自由组合，甚至可以"先调用工具再检索""生成后自我反思"。
5. 自我纠错类 RAG（Self-RAG / CRAG / Adaptive RAG）
- Self-RAG：模型生成答案时给自己打分反思，不满意就重写；
- CRAG（Corrective RAG）：先检索，若结果质量差就自动修正、换路（改走网络搜索或数据库查询）；
- Adaptive RAG：用一个“路由器”判断“这个问题要不要查库”——简单问题直接答，复杂问题才检索。
💡 这些都属“进阶 / 模块化”的衍生流派，理解思路即可；落地时大多由成熟的 Agentic RAG 框架替你封装好。
6. 将资料整理成可维护的知识页面
还有一种做法是在查询之前，把原始资料整理为主题页面、术语说明和交叉链接。这更像先编一本内部手册，再供人和模型阅读。它可以与检索结合，不必被理解为 RAG 的替代品。
原始材料、整理结果和维护规则应分开保存。更新原始文档后，要知道哪些页面受影响；生成摘要时，要保留出处，避免把模型推测混入事实层。人工整理或模型整理都可能遗漏信息，因此需要更新和复核流程。
| 方式 | 优先解决的问题 | 仍要维护的部分 |
|---|---|---|
| 查询时检索原文 | 为当前问题寻找证据 | 索引、版本和权限 |
| 提前整理主题页 | 减少重复阅读、沉淀背景 | 引用、冲突和增量更新 |
| 两者结合 | 先查摘要，再追溯原文 | 摘要与来源的一致性 |
主流 RAG 开发框架推荐
不用从零手搓 RAG，成熟框架已经把“切块、索引、检索、重排”全部封装好：
| 框架 | 官网 | 核心定位 |
|---|---|---|
| LlamaIndex | https://www.llamaindex.ai | 数据框架界的“瑞士军刀”，灵活组装任意数据源与检索策略 |
| RAGFlow | https://github.com/infiniflow/ragflow | 中文友好、深度文档理解（PDF / 表格），开箱即用的 RAG 引擎 |
| LangChain | https://www.langchain.com | 最流行的大模型应用框架，内置 RAG 全套组件（详见 2.12 章） |
| Haystack | https://haystack.deepset.ai | 工业级 RAG 流水线，检索—重排—生成全流程编排 |
| Dify | https://dify.ai | 可视化低代码搭建 RAG 应用，初学者友好（后续章节实战） |
重点推荐 1：LlamaIndex（数据框架“瑞士军刀”）
- 是什么：专注“数据连接 + 索引 + 检索”的框架，特别适合手搓定制化 RAG；
- 核心概念：
Document（原始文档）→Node（切块）→Index（索引）→Retriever（检索器）→QueryEngine（问答引擎）； - 最小代码示例：
python
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader
# 1. 读取本地文档（PDF / Word / Markdown 等）
documents = SimpleDirectoryReader("./docs").load_data()
# 2. 切块、向量化并建立索引；需先配置相应模型与凭据
index = VectorStoreIndex.from_documents(documents)
# 3. 查询得到回答；展示来源需要进一步读取并渲染来源信息
query_engine = index.as_query_engine()
response = query_engine.query("我们公司年假怎么算？")
print(response)重点推荐 2：RAGFlow（中文友好、深度文档理解）
- 是什么：开源 RAG 引擎，最擅长读懂复杂 PDF / Word / 表格（版面分析、OCR、表格抽取），需要用实际中文文档验证解析质量；
- 核心优势：内置“深度文档理解”、引用溯源、可视化知识库管理界面，部署后点点鼠标就能建知识库；
- 适合谁：不想写太多代码，或文档以中文 PDF / 表格为主、需要精确引用的团队。
🎯 一句话选型：想高度定制 → LlamaIndex；要开箱即用 + 中文文档理解 → RAGFlow；要可视化低代码 → Dify。
一条回答应该怎样追溯到原文
以“出差住宿能报多少”为例，完整链路应能回答：查到了哪份制度、发布日期是什么、原文位于哪一节、适用哪类人员，以及回答有没有漏掉城市或职级条件。
只附一个文档名称还不够。如果返回的是“住宿标准说明”，却没有取回限额所在段落，模型仍可能自行补出数字。可以在片段中保存文档标识、页码或章节、版本、有效日期等信息，生成时再把出处与结论对应起来。
查不准时，先看哪个环节
| 问题表现 | 可能原因 | 先检查什么 |
|---|---|---|
| 原文有答案，检索结果没有 | 切块、检索词或索引问题 | 实际返回的片段 |
| 返回了相似但不同的产品 | 专有名词被语义相近内容覆盖 | 关键词与元数据过滤 |
| 查到正确段落，答案却漏条件 | 生成时概括过度 | 提供给模型的上下文与答案 |
| 新旧制度混用 | 版本信息没有参与筛选 | 生效日期和废止标记 |
| 用户看到不属于自己的资料 | 权限过滤缺失 | 检索前后的访问控制 |
先分清是“没查到”还是“查到了但答错”，再决定调检索策略还是生成规则。仅更换一个更大的模型，未必能补上索引中根本不存在的内容。
向量检索为什么常与关键词检索一起用
语义相近不等于事实相同。“可以退款”和“不可以退款”谈的是同一主题，向量可能很接近，却表达相反规则。型号、订单号、日期等精确字段也不宜只靠语义匹配。
关键词检索适合保留这些字面线索，向量检索适合发现近义表达。混合后再重排，可以从候选片段中挑选与问题更相关的内容。重排仍是相关性判断，不是对来源真实性的认证。
向量本身也不是按“年龄、身高、收入”逐项人工指定的评分表。模型学习的维度通常没有这样直观的含义，不同向量模型产生的表示也不能随意混用。更换向量模型后，往往需要重新建立文档向量并验证检索效果。
建一个小规模评估集
先选十来个来自实际资料的问题，记录参考答案与来源。其中包括查得到、查不到、有多个条件和存在旧版本的问题。每次改切块长度、检索数量或模型后，用同一批问题比较结果。
回答“资料中没有找到明确规定”应当是允许的结果。对缺少证据的问题强行生成确定答案，会抵消引入 RAG 的价值。可阅读 RAG 原始论文，了解检索与生成组合的研究出发点。