🔬 AI深度解析 DD20 — RAG 2.0：从向量搜索到图结构推理

预计时长：约25分钟

🎤 开场

大家好，欢迎回到AI深度解析，我是小敏。

今天我们要聊的是一个做AI应用开发的人几乎绑定要接触的技术——RAG，检索增强生成（Retrieval-Augmented Generation）。

如果你用过任何一个”企业级AI助手”，或者试过让大模型回答关于你公司内部文档的问题，你大概率已经在用RAG了。

但是，早期的RAG非常粗糙——经常检索到不相关的内容，回答质量参差不齐。而现在，RAG 2.0正在从一个简单的”搜索+生成”管道，进化为一个包含图结构推理、多跳检索、智能重排的完整系统。

今天我们就来完整梳理一下这个进化过程。

📖 第一部分：基础RAG——简单但有效

先来回顾一下最基础的RAG是怎么工作的。

核心思路非常简单：大模型虽然知识渊博，但它的知识有截止日期，也不知道你公司的内部信息。所以在让模型回答之前，先帮它从外部数据库里找到相关信息。

基础RAG流程：

[离线阶段]
文档 → 分块(Chunking) → 向量化(Embedding) → 存入向量数据库

[在线阶段]
用户提问 → 向量化 → 在向量数据库中搜索相似文档 → 
把问题和找到的文档拼在一起 → 发给大模型 → 生成回答

打个比方：大模型就像一个什么都知道一点的百科全书式专家。RAG就像给这个专家配了一个助手——在他回答问题之前，助手先帮他从文件柜里找出相关资料。

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

📖 第二部分：基础RAG的五大坑

基础RAG看起来简单，但实际用起来到处都是坑。

坑一：分块策略不合理

最常见的做法是按固定字数切分文档，比如每500个字一块。但这经常会把一段完整的论述从中间切断。

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

坑二：语义鸿沟

用户的问法和文档的写法可能完全不同。用户问”怎么退货”，但文档里写的是”商品退换政策”。向量搜索可能找不到这个匹配。

坑三：丢失上下文

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

坑四：检索数量的困境

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

坑五：多跳问题无能为力

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

📖 第三部分：RAG 2.0的核心改进

好，现在进入正题——RAG 2.0时代的改进方案。

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

分块策略 说明 适用场景
固定大小 按字数/token数切分 最简单，效果一般
语义分块 检测语义边界来切分 叙述性文档
递归分块 按标题、段落、句子逐级切分 结构化文档
文档感知分块 理解文档结构（表格、列表等） 复杂文档
父子分块 小块用于检索，大块用于上下文 兼顾精度和完整性

父子分块值得特别说一下。idea是：用小chunk做精确检索（因为小chunk的语义更聚焦），但返回给模型时附带上下文更多的大chunk（保证信息完整）。就像在书里用精确的索引找到关键段落，但给人看的时候展示整个章节。

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

不要只用向量搜索！把多种搜索方式结合起来：

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

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

改进三：重排序（Reranking）

检索到候选文档后，用一个专门的重排序模型对结果重新排序。初始检索追求”召回率”（尽可能多地找到相关文档），重排序追求”精确率”（把最相关的排到最前面）。

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

常用的重排序模型有 Cohere Reranker、BGE-Reranker 和 Jina Reranker 等。

📖 第四部分：图结构RAG——知识图谱的力量

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

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

图结构RAG的思路是：在向量数据库之上（或之旁）建立一个知识图谱，把实体之间的关系显式地存储起来。

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

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

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

GraphRAG（微软开源的方案）是目前最受关注的图结构RAG实现。它的流程：

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

📖 第五部分：Agentic RAG——让AI自己决定怎么搜

这是另一个重要的进化方向——Agentic RAG，让AI Agent来控制整个检索过程。

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

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

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

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

📖 第六部分：RAG vs 长上下文——谁会取代谁？

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

维度 RAG 长上下文
成本 只处理相关部分，便宜 全部塞入，按token计费，贵
延迟 检索快 长上下文处理慢
精度 可能漏检 “所有信息都在”
数据量 可处理海量数据 受窗口限制
更新性 数据库随时更新 每次都要重新输入

我的观点是：两者不是替代关系，而是互补关系。

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

📖 第七部分：向量数据库的选择

做RAG绕不开向量数据库。来看看主流选择：

数据库 类型 特点
Pinecone 托管云服务 开箱即用，无需运维
Weaviate 开源 内置混合搜索，功能丰富
Milvus/Zilliz 开源/云 高性能，大规模场景
Qdrant 开源 Rust编写，性能好
Chroma 开源 轻量级，适合原型
pgvector PostgreSQL扩展 已有PG的团队首选

选择建议：

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

📖 第八部分：生产级RAG的最佳实践

最后，分享一些经过实战验证的RAG最佳实践。

1. 评估驱动开发

一定要建立评估pipeline！常用指标：

  • 检索相关性（检索到的文档是否相关）
  • 回答准确性（回答是否正确）
  • 忠实度（回答是否基于检索内容，而非模型编造）

2. 查询改写（Query Rewriting）

在检索之前，用LLM改写用户的原始问题，使其更适合检索。比如把口语化的问题转化为更精确的搜索查询。

3. 元数据是金矿

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

4. 迭代优化

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

5. 缓存常见问题

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

👋 结尾

好了，今天我们从基础RAG一直聊到了RAG 2.0——智能分块、混合搜索、重排序、图结构推理、Agentic RAG。RAG这个领域正在从一个简单的工程技巧进化为一套完整的知识检索和推理系统。

如果你正在做AI应用开发，RAG几乎是必修课。希望今天的内容能给你一个清晰的全景图和实用的指南。

下期节目，我们要聊AI Agent的完整技术栈——规划、记忆、工具使用、多Agent协作。打造一个真正的AI助手，到底需要什么？我们下期再见！

AI深度解析播客 DD20 · 发布日期：2026年4月15日