🔍 RAG 2.0：从向量搜索到图结构推理

早期 RAG 是一条简单管道：搜索 + 生成。 RAG 2.0 是一套完整的知识推理系统——包含智能分块、混合搜索、重排序、图遍历和 Agentic 决策。

🔬 AI 深度解析专栏 · 第 20 期 📅 2026年4月15日 ✍️ 小敏说 AI

💡 本文要点：系统梳理基础 RAG 的五大坑、RAG 2.0 的核心改进方案（智能分块/混合搜索/重排序/图结构/Agentic），以及向量数据库选型和生产级最佳实践。

🎯 本文导读

• 🔹 基础 RAG 的工作原理：分块 → 向量化 → 搜索 → 生成
• 🔹 五大坑：分块策略、语义鸿沟、上下文丢失、噪声、多跳推理
• 🔹 RAG 2.0 的五项改进：智能分块、混合搜索、重排序、图结构、Agentic
• 🔹 GraphRAG：微软开源方案解析
• 🔹 RAG vs 长上下文：不是替代，是互补
• 🔹 向量数据库选型指南 + 生产最佳实践

一、📦 基础 RAG 是怎么工作的

大模型知识有截止日期，也不知道公司内部信息。RAG 的核心思路：在让模型回答之前，先帮它从外部数据库找到相关信息。

【离线阶段】
文档 → 分块（Chunking） → 向量化（Embedding） → 存入向量数据库

【在线阶段】
用户提问 → 向量化 → 向量数据库搜索相似文档 →
把问题+文档拼在一起 → 发给大模型 → 生成回答

向量化的原理：把文本转换成一串数字（向量），语义相似的文本在向量空间中距离更近。”猫在沙发上睡觉”和”小猫躺在沙发上”用词不同，但向量非常接近。

大模型就像一个百科全书式专家，RAG 给它配了一个”助手”——在他回答问题之前，助手先帮他从文件柜里找出相关资料。

💬 关键观点：基础 RAG 解决了大模型的两个天然缺陷——知识截止日期和私有知识盲区。这就是为什么几乎所有企业级 AI 助手都依赖 RAG。

二、🕳️ 基础 RAG 的五大坑

基础 RAG 看起来简单，用起来到处是坑：

坑一：分块策略不合理

最常见的做法是按固定字数切分（如每 500 字一块）。但这经常把完整论述从中间切断。

想象一份合同的第 7 条被切成两半——上半段说”如果发生违约”，下半段说”则需赔偿 100 万元”。检索到上半段时，你得不到完整信息。

坑二：语义鸿沟

用户问”怎么退货”，文档里写的是”商品退换政策”。向量搜索可能找不到这个匹配——用户的表达方式和文档的写法差异太大。

坑三：丢失上下文

检索到的 chunk 通常是孤立片段，缺少前后文。模型可能不知道”它”指的是谁，”上述方案”是什么方案。

坑四：检索数量的困境

检索太少，可能遗漏关键信息；检索太多，无关内容干扰判断（噪声淹没信号），还快速消耗上下文窗口。

坑五：多跳问题无能为力

有些问题需要综合多文档才能回答。比如”张三的直属上司负责的最大项目预算是多少？”——需要先找到张三的上司，再找那个人负责的项目，再找预算。基础 RAG 很难处理这类链式推理。

三、🔧 RAG 2.0 的五项核心改进

改进一：智能分块（Advanced Chunking）

父子分块特别值得关注：用小 chunk 做精确检索（语义聚焦），返回时附带更多上下文的大 chunk（信息完整）。就像书里用精确索引找到关键段落，但给读者看的是整个章节。

改进二：混合搜索（Hybrid Search）

不要只用向量搜索！三种方式结合：

• 向量搜索：捕捉语义相似性
• 关键词搜索（BM25）：精确匹配特定术语、型号、编号
• 元数据过滤：按时间、类别、来源过滤

实际案例：用户问”KB-2024-0531 错误怎么解决？”——向量搜索可能找不到这个编号，但关键词搜索可以精确匹配。两者结合效果最好。

改进三：重排序（Reranking）

检索到候选文档后，用专门的重排序模型重新排序：

查询 → 初始检索（Top-50） → 重排序模型 → 精选（Top-5） → 送给 LLM

初始检索追求”召回率”（尽可能多地找到相关文档），重排序追求”精确率”（把最相关的排到最前面）。常用重排序模型：Cohere Reranker、BGE-Reranker、Jina Reranker。

💬 关键观点：智能分块 + 混合搜索 + 重排序，这三项改进组合起来，能把 RAG 的检索准确率提升 30-50%。这是生产级 RAG 系统和原型系统的核心差距所在。

四、🕸️ 图结构 RAG：知识图谱的力量

这是 RAG 2.0 中最激动人心的方向——用知识图谱（Knowledge Graph）增强 RAG。

传统向量数据库存储的是孤立的文档块。但现实世界的知识是有关联的——人物之间有关系，事件之间有因果，概念之间有层级。

图结构 RAG：在向量数据库之上建立知识图谱，把实体关系显式存储起来。

传统 RAG：
[文档A] [文档B] [文档C] ...（孤立的块）

图结构 RAG：
[张三] --报告给-→ [李四]
[李四] --负责-→ [项目X]
[项目X] --预算-→ [500万]
[项目X] --使用-→ [技术Y]

当用户问多跳问题时，系统可以沿着图的边进行推理——先找到张三的上司是李四，再找到李四负责的项目 X，再找到项目 X 的预算。

GraphRAG（微软开源方案） 是目前最受关注的实现：

1. 用 LLM 从文档中抽取实体和关系
2. 构建知识图谱
3. 对图谱进行社区检测（发现关联紧密的实体群组）
4. 为每个社区生成摘要
5. 查询时结合图谱遍历和社区摘要回答问题

💬 关键观点：图结构 RAG 专门解决了基础 RAG 最大的软肋——多跳推理。对于人事组织、知识库、法规体系这类有大量实体关系的场景，GraphRAG 的效果提升是质变级别的。

五、🤖 Agentic RAG：让 AI 自己决定怎么搜

另一个重要演进方向：Agentic RAG——让 AI Agent 控制整个检索过程。

基础 RAG 的检索策略是固定的：接收问题 → 搜索 → 生成。Agentic RAG 让模型自己决定：

• 需不需要检索？（有些问题模型本身就知道答案）
• 用什么方式检索？（关键词？向量？图谱？SQL 查询？）
• 检索结果够不够？要不要再搜一次？
• 要不要把问题分解成子问题分别检索？

用户提问 → Agent 判断
    ├→ 直接回答（不需要检索）
    ├→ 简单检索 → 回答
    ├→ 分解问题 → 多次检索 → 综合回答
    └→ 检索 → 评估不够 → 修改查询 → 再检索 → 回答

这就像一个高效的研究助理——不是机械地执行搜索，而是根据问题复杂度灵活调整策略。

六、⚖️ RAG vs 长上下文：互补而非替代

现在模型上下文窗口越来越长—— Gemini 1.5 Pro 有 100 万 token，Claude 支持 20 万 token。有个自然的问题：上下文够长，还需要 RAG 吗？

两者不是替代关系，而是互补关系。

最佳实践：用 RAG 从海量数据中筛选相关内容，再利用长上下文窗口处理更多相关文档。就像做研究——先用搜索引擎找到相关论文（RAG），再仔细阅读这些论文（长上下文）。

七、🗄️ 向量数据库选型指南

选择建议：

• 已有 PostgreSQL → pgvector
• 快速原型 → Chroma
• 生产级大规模部署 → Milvus 或 Pinecone
• 需要混合搜索 → Weaviate

八、✅ 生产级 RAG 的五条最佳实践

1. 评估驱动开发 必须建立评估 pipeline！核心指标：检索相关性、回答准确性、忠实度（回答是否基于检索内容而非模型编造）。

2. 查询改写（Query Rewriting） 在检索前，用 LLM 改写用户原始问题，使其更适合检索。把口语化问题转化为更精确的搜索查询。

3. 元数据是金矿 不要只存文本块。记录每个块来自哪个文档、哪个章节、什么时间、什么分类。检索时用元数据做过滤，大幅提升精度。

4. 持续迭代优化 RAG 不是一次性工程。部署后持续收集用户反馈，分析失败案例，改进分块策略、检索方式和提示词。

5. 缓存高频问题 对常见问题的回答做缓存，既能提速又能降成本。

🎯 一句话总结：生产级 RAG 的核心不在技术选型，在于评估体系。没有评估，你不知道优化方向；有了评估，每一次迭代都有依据。

🔮 趋势预判

1️⃣ GraphRAG 将成为企业知识库 RAG 的标配 向量搜索解决语义匹配，图结构解决关系推理——两者组合才是完整方案。

2️⃣ Agentic RAG 将取代固定管线 静态的”搜索-生成”管线终将被自适应的 Agent 所取代，灵活性和召回率都大幅提升。

3️⃣ RAG 和长上下文将深度融合 先用 RAG 筛选，再用长上下文深度处理——两者组合的模式会成为主流。

4️⃣ 评估体系将成为核心竞争力 技术方案逐渐趋同，谁的评估体系更完善、迭代更快，谁的 RAG 效果就更好。

📮 今日话题

💬 你在用 RAG 做项目时，最卡在哪个环节？分块策略、检索效果，还是回答质量评估？

欢迎留言分享踩坑经历，我会精选回复讨论。

🔬 本文属于「AI 深度解析」系列，每期一个主题，追本质不追热点。

🎙️ 想听更轻松的版本？我们的每日 AI 快讯播客有更口语化的解读。 📱 关注「小敏说 AI」公众号，深度解析不水文。