RAG 没有唯一架构。 SCOUT-RAG、A-RAG 和 SCMRAG 2.0 等论文分别探索自适应检索、分布式 Graph-RAG、分层检索接口与多模态自修正。它们的结果是研究观察，不等于 Agentic 方案普遍优于简单管线。本文将论文主张与生产所需的证据、授权、评测、成本和回滚契约分开讨论。

核心要点

  • RAG 进化路径：Naive RAG → Advanced RAG → Modular RAG → Agentic RAG
  • Agent 自主决定"是否检索/检索什么/从哪检索/是否足够"
  • SCOUT-RAG 在研究环境中探索渐进式跨域遍历和自适应图检索。
  • 多模态与图检索是架构选项，不是企业知识库的标准答案。
  • 分布式检索可以隔离数据所有权并扩展域，但也会增加尾延迟、策略复杂度和故障面。

研究模式，而非唯一演进时间线

阶段 特征 代表技术 时间
模式 典型控制面 主要权衡
--- --- ---
单轮 RAG 固定检索与生成 简单便宜，但适应性有限
工作流/迭代 RAG 预定义查询、检索和校验步骤 可控性更强，但按查询灵活性较低
Agentic RAG 模型从允许的检索动作中选择 自适应，但更难约束和评测
分布式 Graph-RAG 跨所有者进行域路由和图遍历 保留数据局部性，但增加扇出和鉴权工作
多模态 RAG 各模态独立或共享证据路径 保留更多输入信息，但索引和校验成本更高

核心架构

SCOUT-RAG：分布式 Agentic Graph-RAG

SCOUT-RAG 是 Li 等人提出的 “Scalable and Cost-Efficient Unifying Traversal” 的名称。其 2026 年 2 月的 arXiv 预印本描述了域相关性评估、域内种子检索和跨域迭代修正三个阶段，并由多个协作 Agent 完成。它仍是研究框架；在引用成本或质量结论前，应复现其基线和数据条件。

code 
用户查询
    │
    ▼
┌─────────────────────┐
│ Domain Relevance     │ ← 估计哪些独立数据域相关
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ Domain-Scoped Seeding│ ← 在选定域内检索
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ Cross-Domain Refinement│ ← 只有证据需要时才扩展
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ Answer Quality Check │ ← 检查证据缺口和来源
└──────────┬──────────┘
       ┌───┴───┐
       │ 不足？ │→ 回到 Source Selection 重新检索
       └───┬───┘
           │ 足够
           ▼
┌─────────────────────┐
│  Answer Generation   │ ← 基于充分证据生成答案
└─────────────────────┘

A-RAG：分层检索接口

A-RAG（Du 等人，2026）向模型暴露不同粒度的关键词搜索、语义搜索和 Chunk 读取接口，使模型能够选择并交错使用检索动作。由同一模型生成的置信度数字不能作为充分的鉴权或停止信号；生产系统仍需显式预算、证据校验和服务端停止规则。

python 
# 示意伪代码；真实 Tool、鉴权和模型 API 省略。
def adaptive_retrieval(query, policy):
    evidence = []
    for _ in range(policy.max_rounds):
        action = policy.choose_allowlisted_action(query, evidence)
        result = policy.execute(action)
        evidence = policy.validate_and_merge(evidence, result)
        if policy.has_sufficient_cited_evidence(query, evidence):
            break
    return policy.generate_with_citations(query, evidence)

Tool Allowlist、Tenant Filter、字节/Token 预算、Timeout 和 Cancellation 必须由 Policy 层而非模型拥有。

分布式 Agentic RAG（SCMRAG 2.0）

面向跨域知识库的概念性分布式拓扑：

code 
                    ┌─────────────────┐
                    │  Orchestrator   │
                    │    Agent        │
                    └────────┬────────┘
                             │
         ┌───────────────────┼───────────────────┐
         │                   │                   │
         ▼                   ▼                   ▼
┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│ Domain Agent │    │ Domain Agent │    │ Domain Agent │
│   (产品文档)  │    │  (代码仓库)  │    │  (客户数据)  │
└──────┬───────┘    └──────┬───────┘    └──────┬───────┘
       │                   │                   │
       ▼                   ▼                   ▼
┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│  Vector DB   │    │  Code Index  │    │   Graph DB   │
│  (Milvus)    │    │ (Tree-sitter)│    │   (Neo4j)    │
└──────────────┘    └──────────────┘    └──────────────┘

下面是概念拓扑，不是对图中产品的固定推荐：

  • 每个域有独立的检索 Agent，了解本域数据特征
  • Orchestrator 负责分发查询、汇总结果、解决冲突
  • 支持异构数据源（向量库、图数据库、代码索引、API）
  • 域 Agent 可以并行检索，但必须测量尾延迟、部分失败和扇出成本

多模态 RAG

架构方案对比

方案 原理 优势 劣势
统一嵌入 CLIP 系列，图文同空间 检索简单统一 精度受限于嵌入模型
模态转换 VLM 描述 → 文本 RAG 复用成熟的文本管线 信息损失大
分模态融合 各模态独立索引+融合生成 保留模态特有信号 架构复杂且可能出现融合错误

版本化的多模态检索模式

python 
# 示意伪代码。生产环境应固定模型 revision，并校验每个 evidence object。
def multimodal_query(question, retrievers, generator, policy):
    candidates = []
    for retriever in policy.allowed_retrievers:
        candidates.extend(retriever.search(question, limit=policy.limit_for(retriever)))
    evidence = policy.deduplicate_check_permissions_and_provenance(candidates)
    return generator.generate(question, evidence, citations=True)

知识图谱 + RAG 融合

Graph RAG 工作流

code 
文档语料
    │
    ▼
[实体抽取] → [关系抽取] → [知识图谱构建]
                                │
                                ▼
                    ┌───────────────────────┐
                    │   Knowledge Graph     │
                    │  (实体+关系+属性)      │
                    └───────────┬───────────┘
                                │
用户查询 → [意图识别] → [图查询生成] → [子图检索]
                                          │
                                          ▼
                              [上下文增强] → [LLM 生成]

适用场景

问题类型 先测什么 需要验证的图优势
单跳事实 词法/稠密基线 实体消歧或来源追踪
多跳关系 分解检索基线 路径完整性和矛盾处理
全局摘要 层级或 Map-Reduce 基线 覆盖度、来源权重和引用完整性
长尾问题 混合检索与拒答 图召回相对构建成本

用受控评测替代排行榜

维度 必须固定或报告的协议
检索 固定语料、查询切片、证据标注、Recall@k/Recall@Budget、nDCG 或 MRR
回答 引用精确率/召回率、忠实性、完整性、拒答和矛盾处理
效率 p50/p95 延迟、模型/Tool 调用数、检索 Token、存储和每个正确答案成本
分布式行为 域扇出、部分失败、拒绝访问率、跨域泄漏测试和尾延迟
可复现性 模型/Checkpoint、Prompt、索引/解析器版本、随机种子、日期和完整基线配置

工程化建议

选型决策树

code 
你的 RAG 场景是什么？
├── 简单 Q&A（单跳事实）→ 先建立单轮基线
├── 多跳推理/关系问题 → Graph RAG
├── 多数据源/跨域 → Distributed Agentic RAG
├── 图文混合知识库 → Multi-Modal RAG
└── 高准确率要求 → 在有标注切片上比较候选工作流

按契约选择组件

组件 选择问题
向量索引 过滤、更新语义、召回、隔离、导出和删除能力
图索引 所有权、遍历限制、一致性、来源和查询授权
Embedding/Reranker 语言/模态覆盖、版本固定、校准和数据政策
Agent Runtime Schema 校验、Cancellation、幂等、重试、预算和审计事件
可观测性 脱敏、租户隔离、Trace 保留、成本归属和 Replay

生产安全边界

  • 在检索前、父节点/图扩展后分别执行 Tenant、Object 和 Purpose 授权。
  • 将文档、图节点、检索片段、图片和 Tool 结果视为不可信内容，防御 Prompt Injection 与投毒证据。
  • Allowlist 外部 Web/API 目的地，校验 Redirect，并限制响应大小，控制 SSRF 与数据外泄。
  • 保留来源 ID、版本、时间戳、许可证和删除血缘；生成摘要不是权威来源。
  • 对无证据断言要求引用或拒答，高影响写操作保留人工审批。
  • 让域扇出、重试和外部副作用具备幂等性并可观测。

总结

2026 年 RAG 架构的核心演进方向：

  • 从管线到 Agent：检索策略由 Agent 动态决策，而非固定流程
  • 从单一到分布式：跨域知识源通过多 Agent 协作实现统一访问
  • 从文本到多模态：图片、表格、代码等非文本内容纳入检索范围
  • 从平面到图谱：知识图谱为多跳推理提供结构化支撑

对于新启动的 RAG 项目，先建立透明的单轮基线并标注证据；只有切片评测证明收益足以覆盖运营和治理成本时，再加入 Agentic、Graph、多模态或分布式组件。

一手来源