09-高级 RAG 原型：在稳定证据链上尝试 CRAG、Self-RAG、GraphRAG 和 Agentic RAG

到上一篇为止，NexaRAG 的普通 RAG 证据链已经有了一个比较完整的闭环：

trace
  -> 入库和 metadata
  -> 结构化 chunking
  -> 混合检索
  -> rerank
  -> 上下文工程
  -> 引用和拒答
  -> verifier
  -> Golden Set
  -> 动态知识库更新

这时再讨论高级 RAG，才比较踏实。

普通链路具备可观察性、metadata 稳定、final context 带着 evidence id、评测有 Golden Set 以后，再上 GraphRAG、Self-RAG 或 Agentic RAG，工程收益会更容易判断。高级 RAG 应该继承普通证据链：继续使用 trace、evidence、citation、verification 和 evaluation。

这篇的核心判断是：

高级 RAG 应该建立在稳定普通 RAG 链路之上，并且默认可关闭、可调试、可评测。

高级 RAG 放到最后的原因

CRAG、Self-RAG、GraphRAG、Agentic RAG 听起来都很吸引人，但它们解决的是更复杂的问题。

CRAG 关心检索质量偏弱时怎么自我修正。
Self-RAG 关心什么时候需要检索、证据是否足够、答案是否需要修正。
GraphRAG 关心多跳关系和实体路径。
Agentic RAG 关心复杂问题拆解和多次检索。

这些能力都依赖前面的基础。

retrieval trace 让 CRAG 能解释判定检索质量差的原因。
evidence list 让 Self-RAG 能稳定判断证据是否足够。
完整 metadata 和 title_path 让 Mini GraphRAG 更容易构建节点和边。
评测体系让 Agentic RAG 多检索几次以后，可以判断到底是变好还是变复杂。

所以 NexaRAG 阶段 9 的定位，是在普通链路稳定之后，做可运行、可关闭、可比较的高级 RAG 原型。

feature flag 是第一道边界

阶段 9 spec 里最重要的设计之一是 feature flag：

ADVANCED_RAG_ENABLED=false
CRAG_ENABLED=false
SELF_RAG_ENABLED=false
MINI_GRAPHRAG_ENABLED=false
AGENTIC_RAG_ENABLED=false
ADVANCED_RAG_DEBUG_ONLY=true

默认关闭，是一个很稳的工程判断。

高级原型刚开始时，更适合先提供 debug API，单独观察中间步骤。只有当某个原型稳定，并且评测结果说明它真的有收益，才考虑按配置接入主链路。

这和前面所有文章的思路一致：先可观察，再增强能力。

统一结果结构

高级 RAG 统一返回格式以后，后面调试和评测会更轻。阶段 9 设计了统一请求和结果：

AdvancedRagRequest
  query
  mode
  top_k
  filters
  chat_history

AdvancedRagResult
  answer
  evidences
  trace
  fallback_used

trace 至少要包含：

mode
steps
base_retrieval
final_context
errors

这说明高级 RAG 原型也要遵守证据链规则。无论是 CRAG 还是 Agentic RAG，最后都应该产出 evidences 和 trace，同时产出答案。

CRAG：检索质量差时先修正

CRAG 的目标是对检索质量做判断，然后根据质量采取动作。

第一版可以设计成：

query
  -> base retrieval
  -> retrieval quality evaluator
  -> good: 正常进入 context + answer
  -> ambiguous: 改写 query 或放宽 filter 后再检索
  -> bad: 拒答或提示无足够证据

质量判断不一定一开始就用复杂模型。可以先用规则：

• top1 分数高，并且 evidence 和 query 有关键词重叠，判定 good。
• topK 都很弱，判定 bad。
• 命中多个产品或多个版本，判定 ambiguous。

trace 里应该记录：

quality.label
quality.reason
quality.action
retry_query
retry_retrieval

CRAG 的价值在于让系统显式承认：当前检索结果可能质量偏弱，需要补救或拒答。

Self-RAG：显式判断是否需要检索

Self-RAG 的目标是让系统在回答过程中做自我判断：

query
  -> should_retrieve
  -> retrieve if needed
  -> is_evidence_sufficient
  -> answer
  -> critique_answer
  -> revise or refuse

NexaRAG 已经有不少可复用基础：

• 意图识别可以判断闲聊是否需要检索。
• agent/evidence/selection_policy.py 可以判断证据是否足够。
• agent/verification/service.py 可以检查答案是否 supported。
• trace 可以记录每一步判断。

所以第一版 Self-RAG 可以先规则 + verifier：

• 闲聊类问题：should_retrieve=false。
• 产品参数、售后、故障类问题：should_retrieve=true。
• evidence 为空：拒答。
• verifier 有 unsupported claims：尝试修正一次或拒答。

关键是把判断写进 trace：

self_rag.should_retrieve
self_rag.sufficient
self_rag.critique.needs_revision
self_rag.critique.reason

这样 Self-RAG 才能保持可解释。

Mini GraphRAG：先做轻量图

GraphRAG 的目标是让系统能处理关系和多跳问题。NexaRAG 第一版适合先从轻量图开始。

阶段 9 spec 里建议从已有 metadata 构建轻量图：

节点：

Document
Version
Section
Chunk
Product
Entity

边：

HAS_VERSION
HAS_SECTION
HAS_CHUNK
MENTIONS
SAME_PRODUCT
NEXT_CHUNK

这些信息其实已经在前面阶段准备好了：

• doc_id 可以生成 Document 节点。
• document_version_id 可以生成 Version 节点。
• title_path 可以生成 Section 节点。
• chunk_id 可以生成 Chunk 节点。
• product 可以生成 Product 节点。
• 型号、容量、功率、故障词可以做简单 Entity。

第一版 Mini GraphRAG 的目标是辅助扩展候选：

query
  -> hybrid retrieval
  -> graph expansion by product / section / entity
  -> merge graph candidates
  -> ContextBuilder

trace 里应该能看到 matched nodes、expanded nodes 和 graph candidates。这样图召回到底做了什么，后面才方便评估。

Agentic RAG：复杂问题拆成子检索任务

Agentic RAG 适合处理复杂问题，比如：

对比小米 15 Pro 和 iPhone 16 Pro Max 的电池和充电能力

这个问题里至少有两个产品、两个维度。单次检索时，候选池可能混在一起。Agentic RAG 可以先拆成子问题：

{
  "sub_queries": [
    {"id": "q1", "query": "小米15 Pro 电池容量", "purpose": "battery"},
    {"id": "q2", "query": "小米15 Pro 充电功率", "purpose": "charging"},
    {"id": "q3", "query": "iPhone 16 Pro Max 电池容量", "purpose": "battery"},
    {"id": "q4", "query": "iPhone 16 Pro Max 充电功率", "purpose": "charging"}
  ]
}

第一版 planner 可以先用规则：

• 包含“对比”、“分别”、“区别”时，按产品或维度拆。
• 包含“电池和充电”时，拆成电池、充电。
• 包含“故障原因和解决办法”时，拆成原因、步骤。

然后每个 sub_query 独立检索，最后合并 evidences，再交给答案生成。重点仍然是：每个子查询、每次检索、每组 evidence 都要进入 trace。

debug API 比直接接入主链路更稳

阶段 9 建议先新增：

POST /advanced-rag/debug

请求里指定：

query
mode
top_k
filters

feature flag 关闭时，就返回清晰错误：

{"error": "advanced_rag_disabled"}

这样普通用户链路保持稳定，开发者可以通过 debug API 看高级原型的 steps、base retrieval、final context 和 errors。

等某个模式真的在评测里稳定提升，再考虑让 /chat 按配置启用。

高级 RAG 也必须接受评测

高级 RAG 很容易把复杂度当成收益，所以更需要评测。

阶段 9 spec 里建议扩展阶段 7 评测，新增：

--advanced-mode none|crag|self_rag|mini_graphrag|agentic_rag

然后对比：

普通 RAG 基线
CRAG 原型
Self-RAG 原型
Mini GraphRAG 原型
Agentic RAG 原型

重点样本应该包括：

• multi_fact
• ambiguous
• conflict
• no_evidence
• multi_turn

高级模式指标下降时，需要通过 trace 解释原因。比如 Agentic RAG 可能提升多事实问题，但增加延迟；CRAG 可能提升无证据拒答，但也可能过度保守。这些都要用报告说清楚。

这一步解决的内容和下一步

高级 RAG 原型解决的是普通 RAG 在复杂场景下的短板探索。

CRAG 处理检索质量偏弱。
Self-RAG 处理是否检索和是否修正。
Mini GraphRAG 处理轻量关系扩展。
Agentic RAG 处理复杂问题拆解。

它们第一版的合理目标是：可运行、可关闭、可调试、可评测。先用原型证明价值，再决定哪个方向值得深化。

小结

NexaRAG 把高级 RAG 放在最后，是因为前面的普通证据链已经提供了必要地基：trace、metadata、chunk、hybrid retrieval、rerank、evidence、citation、verification、evaluation。

高级 RAG 应该复用这些地基。无论 CRAG、Self-RAG、Mini GraphRAG 还是 Agentic RAG，最终都要回到同一个问题：证据从哪里来，可信依据是什么，答案是否引用，评测是否变好。

到这里，这组 NexaRAG 施工记录就从请求入口一路走到了高级 RAG 原型。它把每个 RAG 能力放回项目中的位置。

参考材料：

• NexaRAG RAG项目开发与解决思路/阶段9-高级RAG原型/spec.md
• NexaRAG agent/nodes/tool_reasoning_node.py
• NexaRAG agent/groups/customer_service_group.py
• NexaRAG rag/_trace/records.py
• NexaRAG agent/evidence/selection_policy.py
• NexaRAG agent/verification/service.py
• NexaRAG rag/evaluation/chain.py
• 原 RAG 系列 11-GraphRAG-SelfRAG-CRAG和AgenticRAG-普通RAG的下一步.md