如果你构建过经典RAG系统，就会了解它的优势：检索相关文本块，由LLM生成有依据的答案，性能合理，成本可预测。对于大多数知识库查询，这已经足够。
但有些查询会让经典RAG失效。多跳问题（“哪些客户正在使用功能X，并且在过去6个月内已经流失？”）、关系密集型问题（“我们的定价与竞争对手A、B、C相比如何？”）、综合性问题（“总结我们掌握的这位客户完整历程”）。经典的文本块检索不善于组合文本块；上下文分散在多处时，LLM最终会遗漏信息。
“超越文本块”的方法——图RAG、智能体RAG、长上下文RAG——分别以不同方式解决这些局限。本文介绍它们是什么、各自何时适用、在生产环境中实际如何工作，以及需要关注的权衡。
基于文本块的RAG有哪些局限
要理解我们在修复什么，先看它的局限：
局限1：没有关系结构。 文本块是彼此独立的单元。文本块A讲客户X的账户，文本块B讲客户X提出的投诉，两者之间的联系会丢失——它们只是向量空间中的两个文本块，各自独立地被检索到（或没有被检索到）。
局限2：不支持多跳。 “使用功能X且投诉过Y的客户”需要结合两个不同来源的信息，并进行集合逻辑运算。基于文本块的检索无法做到这一点。
局限3：综合能力有限。 “按时间总结这个账户的关系历程”需要将许多文本块整合为连贯叙述。文本块以片段形式呈现；LLM每次都必须从头完成综合。
局限4：固定流水线过于僵化。 经典RAG始终执行：嵌入查询 → 检索K个结果 → 生成。需要迭代检索或多步推理的复杂查询不适合这条流水线。
局限5：上下文稀释。 排名前5的文本块中，可能有些虽然匹配查询，却偏离主题。LLM被迫从中筛选，质量因此下降。
下面讨论的不同变体分别解决了其中一部分问题。
图RAG
其思路是：将数据表示为知识图谱。实体（人员、产品、文档、事件）是节点，关系是边。查询通过遍历图来完成，而不是只进行向量搜索，也可以将两者结合。
图RAG何时有帮助
关系密集型领域。 客户-账户-交易-互动结构、组织层级、产品分类体系、引用网络，以及任何实体之间的联系与实体本身同样重要的场景。
多跳推理。 “第三季度购买产品X的团队，其经理是谁？”需要依次跳转：产品 → 交易 → 团队 → 经理。图RAG能自然处理。
聚合。 “细分市场Y中有多少客户已与系统Z集成？”需要跨实体执行集合运算。对知识图谱运行SQL胜过文本检索。
引用与解释。 图中的关系明确且可审计。LLM可以引用“John是Team Acme的经理 [边：manages]”，而不是“根据上下文，我认为John管理Team Acme”。
图RAG实际如何工作
典型流水线如下：
1. 提取。 根据数据构建图。常见方式有两种：
- 结构化来源（数据库、结构化API）：直接导入。客户、产品、交易已经存放在表中。
- 非结构化来源（文档、文字记录、电子邮件）：使用LLM提取实体和关系。“从这份文字记录中提取人员、组织及其关系。”
输出包括节点（含类型和属性）与边（含类型和属性）。
2. 存储。 使用图数据库——Neo4j、Memgraph，或采用边表的自定义Postgres。具体选择取决于查询模式和规模。
3. 加入嵌入。 每个节点还会获得文本表示和嵌入，从而实现混合模式：遍历图并进行语义搜索。
4. 在检索时查询。 常见模式有三种：
- 仅图查询。 LLM（或路由逻辑）生成图查询（Cypher、SQL），执行后将结果返回给LLM。
- 先嵌入，再扩展图。 通过嵌入找到相关实体，然后扩展到其邻接节点和相关实体。
- 混合模式。 在同一条流水线中结合向量搜索与图遍历。
5. 为LLM格式化。 将图查询结果格式化为LLM可以使用的结构化文本，列出实体及其属性，并明确展示关系。
一个具体示例
假设一家SaaS公司拥有客户数据。实体包括：客户、合同、产品、支持工单、互动和员工。
经典RAG方法：将客户文档分块、嵌入并检索。这会丢失关系结构。
图RAG方法：
- 节点：客户、合同、产品、工单、互动、员工。
- 边：customer→has→contract、customer→subscribed_to→product、customer→submitted→ticket、ticket→assigned_to→employee、contract→sold_by→employee。
查询：“SaaS套餐中，哪些客户在第一季度提交了超过3张支持工单，并将在第二季度续约？”
这很自然地对应一条图查询：
MATCH (c:Customer)-[:HAS]->(contract:Contract)
WHERE contract.tier = "SaaS"
AND contract.renewal_date BETWEEN "2026-04-01" AND "2026-06-30"
MATCH (c)-[:SUBMITTED]->(t:Ticket)
WHERE t.created BETWEEN "2026-01-01" AND "2026-03-31"
WITH c, count(t) as ticket_count
WHERE ticket_count > 3
RETURN c, ticket_count
LLM生成这条查询（或从模板化查询中选择），然后执行、格式化结果并生成回答。
经典RAG很难回答这个问题，而图RAG可以清晰地完成。
权衡
优点：
- 能自然处理关系型查询。
- 结构明确、可审计。
- 可与嵌入组合。
缺点：
- 构建图需要真正的工程投入。尤其对于非结构化来源，提取并不完美。
- Schema设计很重要；糟糕的Schema会限制你。
- 需要维护：数据演变时，图也会演变。
- 工具链不如向量搜索成熟。
何时选择：
当关系是你所在领域的一等要素时，选择图RAG。不要仅仅因为它听起来先进就采用；对于许多以文档为主的领域，经典RAG更简单，效果也同样好。
Microsoft GraphRAG与相关工作
Microsoft的开源 GraphRAG 项目（2024年）普及了一种特定方法：
- 从文档中提取实体和关系（基于LLM）。
- 将实体聚类为社区。
- 在多个层级上为每个社区生成摘要。
- 查询时检索相关社区摘要，并将其用作上下文。
这种方法很适合跨越整个语料库的“全局”问题（例如，“这位客户的投诉历史主要有哪些主题？”），而不是具体查找。
其他变体包括LightRAG、Graphiti等，每种方案都有特定的架构选择。
智能体RAG
其思路是：不采用固定的“先检索、再生成”流水线，而是让LLM智能体决定检索什么、何时检索以及如何优化。智能体可以发出后续检索查询，查看结果并判断信息不足，然后尝试其他角度。
智能体RAG何时有帮助
需要迭代的复杂查询。 “帮我弄清楚第一季度流失率为何上升”需要从多个角度调查（哪个细分市场、哪个时间段、哪些功能、哪些竞争对手）。智能体可以迭代探索。
一次检索不够的查询。 如果答案需要结合多次不同检索得到的信息，智能体能自然处理。
包含条件逻辑的查询。 “如果根据检索1判断X为真，就查找Y；否则查找Z。”智能体可以处理分支，固定流水线则不能。
含义模糊的查询。 智能体可以向用户（或数据）询问澄清信息。
智能体RAG如何工作
流水线如下：
用户查询
↓
智能体推理自己需要什么
↓
智能体调用检索工具（一个或多个）
↓
智能体读取结果
↓
智能体判断：信息足够了吗？还是需要再次检索？
↓
循环，直至完成
↓
生成最终答案
实现涉及：
将检索封装为工具。 向智能体公开检索函数：search_documents(query)、lookup_by_id(id)、aggregate(field, filter)。智能体按需调用。
记忆。 智能体记住每次调用检索到的内容，避免重复获取相同内容。
决策。 智能体明确推理自己是否掌握了足够信息。“我知道用户问题的答案了吗？如果不知道，还需要检索什么？”
终止。 智能体必须知道何时停止：最大步骤预算、置信度阈值，或“我已经回答完毕”条件。
一个具体示例
查询：“第一季度客户最关心的三个问题是什么？请提供示例。”
经典RAG方法：检索一些客户反馈文本块，希望它们覆盖相关主题。
智能体RAG方法：
智能体：我需要找出第一季度的客户关切。先搜索这一时期的客户投诉。
> 工具：search_documents(query="customer complaints Q1 2026", filter={date_range: "Q1 2026"})
智能体：我得到了25个结果。看看它们涵盖哪些主题。
> [读取结果]
智能体：我看到三个主要主题：定价、支持响应慢和缺少集成。分别查找具体示例。
> 工具：search_documents(query="customer pricing complaints", filter={...})
> 工具：search_documents(query="customer support speed complaints", filter={...})
> 工具：search_documents(query="customer integration missing complaints", filter={...})
智能体：现在每个主题都有3–5个具体示例。接下来汇总答案。
多次检索、迭代优化。智能体根据找到的内容决定答案结构。
权衡
优点：
- 能处理复杂的多步查询。
- 会适应查询复杂度（简单查询不会触发冗长的智能体运行）。
- 可以通过提问澄清歧义。
缺点：
- 延迟更高（需要多次检索）。
- 成本更高（需要多次LLM调用）。
- 智能体可靠性至关重要；糟糕的智能体会循环或放弃。
- 更难评估（执行路径更加多样）。
- 更难控制（智能体可能做出意外操作）。
何时选择：
当查询复杂度差异很大时，选择智能体RAG。简单查询可以走快速路径，复杂查询则交给智能体。若所有查询都很简单，这些额外开销并不值得。
智能体RAG中的模式
常见模式包括：
模式1：ReAct（Reason + Act）。 智能体明确推理，然后采取行动（检索），接着观察，再次推理，循环直至完成。
模式2：规划后执行。 智能体先制定多步计划（按什么顺序检索什么），然后执行，并可能进行调整。
模式3：自我批评。 检索后，智能体评估所获信息是否充分。如不充分，就优化查询并再次检索。
模式4：工具丰富型智能体。 智能体拥有多种检索工具（全文搜索、SQL查询、图查询、API调用），并自行选择。
不同模式适用于不同用例。工具丰富型适合异构数据源；ReAct适合探索式查询；当复杂查询的结构可以提前规划时，规划后执行模式很合适。
长上下文RAG
其思路是：既然Gemini、GPT-5已经拥有100万以上token的上下文窗口，为什么还要检索文本块？直接把整个语料库放入上下文即可。
长上下文RAG何时有帮助
小型语料库。 10万token的语料库很容易装进100万token的窗口，无需检索基础设施。
理解完整文档。 “总结这份500页文档的全部内容。”长上下文模型可以直接处理。
对少量文档进行跨文档查询。 “比较这10份合同。”将它们全部放入上下文，比精心检索更简单。
制作原型。 长上下文是构建可用系统最简单的路径。先用长上下文构建原型；以后如有需要，再通过检索优化。
长上下文RAG如何工作
流水线非常简单：
[语料库，可能包含10万–100万token]
↓
+ [用户查询]
↓
LLM调用
↓
[答案]
没有向量存储，无需分块，也没有重排序。
实际使用中，你可能仍会进行轻量检索，使语料库适合放入上下文（例如，对于500万token的语料库，检索其中50万token的子集）。不过这属于粗粒度检索——由LLM完成细粒度的“寻找相关部分”工作。
“上下文退化”问题
2025–2026年的现实是：长上下文模型其实并不能很好地利用长上下文。
实证结果表明：
- 当上下文大约为5,000–50,000个token时，质量最高（背后的位置信息注意力模式见 Liu等人的“Lost in the Middle”及后续长上下文评估）。
- 超过10万token时，质量明显下降。
- 超过50万token时，重要信息经常被遗漏或误用。
模型在技术上可以处理长上下文，但“大海捞针”基准测试夸大了其表现。现实世界中的长上下文使用会受到影响。
这意味着，长上下文RAG可以可靠处理不超过约5万token的语料库。超过这个范围后，其表现不如良好的检索系统。
权衡
优点：
- 架构最简单。
- 无需维护检索流水线。
- 最适合需要理解完整语料库的任务。
缺点：
- 上下文很大时质量会下降。
- 每次查询成本很高（每次都要为完整上下文付费）。
- 延迟很高（上下文越大，响应越慢）。
- 无法扩展到超出可靠上下文容量的语料库。
何时选择：
小型语料库（低于5万token）、一次性分析和原型。不要将其用于大型知识库的通用检索。
混合模式：检索 + 长上下文
一种常见模式是：检索比经典RAG更多的相关内容（5万–20万token），但少于完整语料库。LLM获得足够上下文来妥善处理查询，同时避免上下文退化。
实现方式：检索排名前50的文本块（而不是前5），全部加入上下文，让LLM从中筛选。
这种方法适用于：
- 查询需要广泛上下文。
- 模型能够妥善处理5万–20万token的中等长度上下文。
- 成本可以接受。
2026年的一个理想平衡点是：积极检索（50–100个文本块），全部加入上下文，让LLM使用相关部分。这是在用成本换取简单性和质量。
选择正确的变体
可以使用以下决策框架：
在以下情况使用经典的基于文本块的RAG：
- 文档是主要数据。
- 查询大多属于检索型。
- 数据量和成本很重要（单次查询最便宜）。
- 需要可预测的延迟。
在以下情况使用图RAG：
- 数据具有丰富的实体-关系结构。
- 查询涉及多跳推理、集合运算和聚合。
- 你可以投入资源构建和维护图。
在以下情况使用智能体RAG：
- 查询复杂度差异很大。
- 某些查询需要迭代探索。
- 你愿意为困难查询承担更高的延迟和成本。
- 你具备用于调试智能体运行的可观测性。
在以下情况使用长上下文RAG：
- 语料库很小（低于5万token）。
- 你想要最简单的架构。
- 用于一次性分析或原型。
在以下情况组合使用：
- 大多数真实系统都会组合。
- 对关系型查询采用经典RAG + 图RAG。
- 对复杂查询采用经典RAG + 智能体RAG。
- 对临界用例采用检索范围更广（中等上下文）的经典RAG。
2026年成熟的答案是“以上全部，根据每次查询分别应用”。路由器根据查询特征决定使用哪种变体。
生产环境的现实
以下是实际部署中的一些观察：
复杂性会叠加。 每种变体都会增加复杂性。同时使用四种方案的系统是一项重大的工程项目。应从经典RAG开始，只有遇到明确局限时才添加变体。
评估更困难。 存在多条检索路径时，评估必须覆盖所有路径。测试集应包含能够分别触发各条路径的查询。
成本差异很大。 图RAG可能很便宜（一次数据库查询），长上下文RAG则很昂贵。智能体RAG的成本不定（简单查询便宜，复杂查询昂贵）。应跟踪每次查询的成本。
延迟差异同样明显。 对有些用例而言，智能体RAG用30秒回答可以接受，另一些则不能。应根据用户体验场景选择变体。
维护负担。 图Schema会漂移，智能体提示词需要调优，嵌入模型会更新。每种变体都有自己的维护成本，要提前规划。
80/20原则。 经典RAG足以妥善处理80%的查询。超越文本块的变体负责经典RAG不擅长的困难20%。不要替换经典RAG，而要增强它。
组合架构
一种使用多种变体的实用架构：
查询
↓
路由器（对查询进行分类）
├→ “查找” → 经典RAG（便宜、快速）
├→ “关系型” → 图RAG
├→ “复杂 / 开放式” → 智能体RAG
└→ “完整语料库 / 小型语料库” → 长上下文
每种变体都会生成答案。
可观测性会跟踪使用了哪条路径。
评估套件覆盖所有路径。
这种架构比任何单一变体都复杂，却能妥善处理完整的查询范围。对于查询类型多样的成熟系统，它是最终的架构形态。
实用的扩展路线
如果你已经拥有可用的经典RAG，并希望扩展：
先添加长上下文。 工程成本最低，适合特定查询类型，通常可以立即取得成效。
为复杂查询添加智能体。 找出经典RAG难以处理的查询，构建专门处理它们的智能体，并按条件路由。
最后添加图RAG。 工程成本最高。只有在你有明确的关系型查询模式时才值得采用。
这个顺序通常符合投资回报率。长上下文：成本低、有实际价值。智能体：成本适中、解决真实缺口。图：成本高、用例具体。
增强，而不是替换
经典的基于文本块的RAG是主力方案，但确实存在局限。“超越文本块”的变体——图RAG、智能体RAG、长上下文RAG——分别解锁不同能力。
前进的方向不是替换经典RAG，而是增强它。成熟系统会使用多种变体并进行适当路由，让每一种变体处理自己擅长的查询。
这需要切实投入——每种变体都是真正的工程工作。但当经典RAG遇到瓶颈时，能力提升也是真实的。一个只能妥善处理“查找”查询的系统，远不如同时能够处理关系型、复杂型和完整语料库查询的系统有用。
梳理你的查询，找出经典RAG处理不佳的那些，选择合适的变体，构建增强方案，然后迭代。
RAG系统正是通过这种方式，从“对某些查询有用”成长为能够真正应对现实世界多样问题的系统。
