Self-RAG / CRAG：Agentic Retrieval 与纠错检索
Self-RAG 和 CRAG 的共同价值，是把 RAG 从“检索 top-k 文档再生成答案”的固定流水线，升级为会判断检索需求、检索质量、证据支持、纠错路径、拒答和升级条件的受控系统。它们把幻觉治理前移到证据选择和证据评价环节，而不是只在最终回答后做补救。
Self-RAG / CRAG / Agentic Retrieval 解读
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection | https://arxiv.org/abs/2310.11511 | 理解 retrieve、generate、critique 的自反式 RAG |
| Corrective Retrieval Augmented Generation | https://arxiv.org/abs/2401.15884 | 理解检索质量判断、纠错检索和 fallback |
| Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks | https://arxiv.org/abs/2005.11401 | 理解 RAG 基础范式 |
| RAGAS | https://arxiv.org/abs/2309.15217 | 理解 faithfulness、answer relevancy、context precision / recall 等评估维度 |
核心导读
Self-RAG 和 CRAG 的共同价值，是把 RAG 从“检索 top-k 文档再生成答案”的固定流水线，升级为会判断检索需求、检索质量、证据支持、纠错路径、拒答和升级条件的受控系统。它们把幻觉治理前移到证据选择和证据评价环节，而不是只在最终回答后做补救。
系统设计的关键不只是向量库规模，而是 retrieval control plane：什么时候检索、检索哪些源、如何处理弱检索、如何识别证据冲突、何时拒答或升级。架构取舍集中在召回率、证据精度、权限过滤、版本控制、延迟成本和人工复核之间。
1. 核心问题：RAG 的失败常发生在生成之前
传统 RAG 常被描述为：
Question -> Retrieve top-k chunks -> Put chunks into prompt -> Generate answer
这个流程简单有效，但它隐藏了一个危险假设：检索结果默认可用。
在企业知识系统中，这个假设经常不成立。
| 失败类型 | 表现 | 金融零售后果 |
|---|---|---|
| 不该检索时检索 | 噪音文档进入上下文 | 答案被无关政策污染 |
| 应该检索但没检索 | 模型靠内部记忆回答 | 过期或臆造政策 |
| 检索结果过期 | 引用了 inactive policy | 客户承诺或合规错误 |
| top-k 不完整 | 找到部分证据但缺关键条件 | KYC 或信贷要求漏项 |
| 权限过滤失败 | 检索到用户无权查看的材料 | PII 或内部策略泄露 |
| 文档冲突 | 不同地区、产品或版本混在一起 | 答案看似有引用但不可执行 |
| 证据不支持答案 | 引用存在但 claim 没被 source 支持 | “有引用的幻觉” |
Self-RAG 和 CRAG 要解决的是 RAG 控制问题，而不只是召回率问题。
它们共同推动一个范式变化：
RAG pipeline -> Retrieval decision system
系统不仅要知道如何检索，还要知道何时检索、检索哪里、检索结果是否足够、失败时如何纠错，以及什么时候应该拒答或转人工。
2. Self-RAG 的贡献：让检索和生成过程可反思
Self-RAG 引入了 reflection / critique 的思想。模型不只是生成答案，还学习在过程中判断：
| 判断 | 要回答的问题 |
|---|---|
| Retrieve? | 这个问题是否需要外部知识 |
| IsRel | 检索内容是否与问题相关 |
| IsSup | 生成内容是否被证据支持 |
| IsUse | 答案是否对用户任务有帮助 |
论文中的实现涉及特殊 token 和训练方式。企业落地时，不一定要复制训练方案，更重要的是迁移控制思想。
可以把 Self-RAG 改写成模块化系统：
User Query
-> Retrieval Need Classifier
-> Query Planner
-> Retriever
-> Context Quality Evaluator
-> Answer Generator
-> Grounding / Usefulness Critic
-> Final Answer / Retry / Refuse / Escalate
这套结构把 RAG 的几个关键判断点显式化。
例如 KYC policy assistant 接到问题：
非居民客户开户是否必须提供地址证明？
系统不能直接 top-k 检索“地址证明”。它需要先判断：
- 问题涉及地区、客户类型和产品类型吗？
- 是否必须查询 active policy？
- 问题是否缺少 region metadata？
- 是否需要追问而不是直接回答？
- 检索内容是否是当前版本？
- 回答中的每个材料要求是否都有 citation？
Self-RAG 的价值就在于把这些判断从隐含 prompt 变成可评测的控制点。
3. CRAG 的贡献：检索弱时必须纠错
CRAG 关注的问题更直接：检索结果不好时怎么办？
典型流程可以理解为：
Query -> Retrieve -> Retrieval Evaluator
-> If strong: generate
-> If weak: correct / re-retrieve / refine / fallback
-> Generate with improved context
它反对一种常见的低成熟度做法：无论检索质量如何，都把 top-k chunks 塞进 prompt。
企业版 CRAG 不一定依赖开放 Web 搜索。金融零售环境通常更适合受控纠错路径：
| 弱检索原因 | 纠错路径 |
|---|---|
| 缺少地区信息 | 追问用户或从客户 profile 读取 region |
| 文档版本过期 | 切换到 authoritative policy index |
| 单一 index 召回不足 | 路由到 product docs、case records、policy DB |
| 查询表达不清 | query rewrite / multi-query / decomposition |
| 文档冲突 | 触发 conflict detector 和 human review |
| 权限不足 | 拒答或请求授权，而不是绕过过滤 |
| 高风险建议 | 检索后仍要求人工复核 |
CRAG 的核心不是“多搜几次”，而是把 weak context 当成系统状态处理。弱检索会触发纠错、拒答或升级，而不是被生成器吞掉。
4. Agentic Retrieval：把检索变成可编排能力
当 RAG 进入复杂业务流程，检索不再是一个单独步骤，而是 agent runtime 中的一类受控动作。
参考架构可以写成：
User Task
-> Intent / Risk Classifier
-> Retrieval Need Decision
-> Query Rewrite / Decomposition / Multi-query
-> Retrieval Router
-> Policy Index
-> Product Docs
-> Case Records
-> Transaction Evidence
-> Approved External Source
-> Context Quality Gate
-> Conflict / Freshness / Permission Check
-> Answer Generator
-> Critic
-> Final / Retry / Refuse / Escalate
-> Eval + Trace
Retrieval router 的职责是选择来源，而不是简单地从一个全局向量库里搜索。
| Query type | Preferred source |
|---|---|
| KYC checklist | policy index + region metadata |
| AML typology | compliance knowledge base + case history |
| Payment dispute | case record + card network rules |
| Product fee | product disclosure + fee schedule |
| Credit rationale | credit policy + application data |
| Customer complaint | complaint taxonomy + SLA policy |
Context quality gate 是 agentic retrieval 的核心门禁。
| Check | 通过标准 |
|---|---|
| Relevance | context 回答了真实问题，而不是关键词匹配 |
| Authority | source 属于批准来源 |
| Freshness | policy version 当前有效 |
| Permission | 当前用户有权访问 |
| Completeness | 必填证据字段覆盖 |
| Consistency | 没有未解决的政策冲突 |
| Citation support | material claim 都能被 source 支持 |
这使 RAG 具备可运营性。系统可以解释一次回答为什么检索、检索了哪里、哪些来源被拒绝、为什么重试、为什么拒答。
5. 为什么有效：把幻觉问题前移到证据控制
很多团队把 RAG 失败归因于“模型幻觉”。但在企业场景中，许多幻觉其实源于检索控制失败。
Self-RAG / CRAG 有效，是因为它们把质量控制前移：
- 在生成前判断是否需要检索。
- 在生成前判断检索内容是否相关、权威、当前、完整。
- 在生成后检查答案是否被证据支持。
- 在失败时触发 retry、alternate source、refuse 或 escalate。
这降低了三类风险。
第一，降低“错误证据驱动的正确语气”。模型可能用专业语气复述错误政策。context quality gate 可以在生成前阻断过期或无权来源。
第二，降低“有引用的幻觉”。引用存在并不代表 claim 被引用支持。grounding critic 必须检查每个 material claim 和 source 的对应关系。
第三，降低“缺证据仍输出”。当政策不存在、地区不明确、权限不足或冲突未解决时，系统应该进入 no-answer UX，而不是用 base model 补齐。
6. 局限和误用
Self-RAG / CRAG 不是万能纠错器。
| 误用 | 问题 | 更稳妥做法 |
|---|---|---|
| top-k 越大越好 | 噪音、冲突和成本同时增加 | adaptive retrieval + context compression |
| 有 citation 就可信 | citation 可能不支持 claim | claim-level grounding check |
| 失败就 fallback 到 base model | 高风险场景增加幻觉 | refuse / escalate / ask for missing info |
| 全部交给 LLM critic | 规则、权限、版本不应只靠语义判断 | hard rules + LLM semantic critic |
| 单一向量库承载所有知识 | 权限、owner、freshness 难治理 | routed indexes + source registry |
| 只评估最终答案 | 无法定位检索、路由、权限或证据失败 | eval 每个 decision point |
另一个边界是成本和延迟。纠错检索会增加调用次数，不能对所有问题一视同仁。低风险 FAQ 可以简单检索，高风险政策、客户影响和合规任务需要完整质量门禁。
还要注意 prompt injection in source。检索到的文档可能包含恶意指令或不可信内容。retrieval control plane 必须把 source content 当作数据，而不是系统指令。
7. 架构和产品价值：Retrieval Control Plane
Self-RAG / CRAG 对架构的启发，是把 RAG 拆成一组可治理组件。
| Component | Responsibility |
|---|---|
| Retrieval need classifier | 判断是否检索、是否需要追问 |
| Query planner | rewrite、decompose、multi-query、metadata binding |
| Retriever registry | 管理 index、source、owner、权限、SLO |
| Retrieval router | 按任务类型和风险选择来源 |
| Context evaluator | relevance、authority、freshness、permission、completeness |
| Answer generator | 只在 context 合格时生成 |
| Grounding critic | 检查答案是否被 source 支持 |
| Retry controller | weak context 时重写、换源或补证 |
| Refusal / escalation service | 安全退出和人工升级 |
| Trace store | 保存检索、评分、版本和最终处置 |
产品上，RAG 系统也需要定义 no-answer UX。好的 no-answer 不是简单说“我不知道”，而是说明缺少哪个业务输入、没找到哪个权威来源、哪些来源冲突、当前用户缺少什么权限，以及可以如何补充材料或升级。这比编一个答案更有价值，也更符合金融零售的风险边界。
8. 金融零售系统案例
8.1 KYC Policy Assistant
用户问题：
加拿大非居民个人客户开立投资账户需要哪些文件？
系统需要先绑定 metadata：
- region = Canada。
- customer type = non-resident individual。
- product = investment account。
- channel = onboarding。
- policy version = active。
检索路径：
| Step | 控制点 |
|---|---|
| Retrieval need | 政策问题必须检索 |
| Query planning | 将地区、客户类型、产品写入 query metadata |
| Routing | policy index + product disclosure |
| Context gate | active version、authority、permission、completeness |
| Critic | 每个文件要求是否有 citation |
| Final | 输出 checklist、限制和人工复核条件 |
如果 region 缺失，系统应追问；如果政策冲突，系统应标注冲突并升级；如果用户无权查看内部政策，系统不能通过换源绕过。
8.2 AML Copilot
AML 场景的检索源包括：
- typology library。
- case history。
- transaction evidence。
- SAR writing guidance。
- sanctions / PEP metadata。
- customer KYC profile。
纠错路径可以是：
| 弱点 | 系统处理 |
|---|---|
| typology mismatch | 触发 alternate typology retrieval |
| KYC 缺失 | 请求 investigator 补充或读取客户档案 |
| 交易证据不足 | 标记 missing evidence，不生成结论 |
| case history 冲突 | 转人工核查 |
| SAR guidance 命中 | 只生成 draft，不自动提交 |
这里 RAG 的目标不是替代调查员，而是让证据链完整、引用清晰、缺口可见。
8.3 Customer Service Copilot
客服场景容易被误以为低风险，但费用、利率、退款、投诉和销售建议都可能产生客户影响。
规则：
- 费用、利率、期限必须引用 active disclosure。
- 找不到政策时不得安抚式编造。
- 产品推荐需要 suitability boundary。
- 投诉和威胁升级要触发 case creation。
- 高敏感账户信息必须经过权限检查。
Self-RAG / CRAG 在这里的价值，是让客服 assistant 不仅回答快，还知道什么时候不能回答。
9. EvalOps：评估每个判断点
RAG eval 不能只看 final answer accuracy。
| Eval layer | 样例指标 |
|---|---|
| Retrieval need | should_retrieve accuracy、over-retrieve rate |
| Query routing | correct source family、metadata binding accuracy |
| Retrieval quality | recall@k、context precision、source freshness |
| Context critique | relevance / freshness / permission detection |
| Corrective retrieval | weak retrieval recovery rate |
| Grounding | supported claim ratio、unsupported claim count |
| Refusal | no-answer precision、over-refusal rate |
| Escalation | high-risk escalation recall |
| Human usefulness | reviewer accept / edit / override |
Financial retail golden set 至少要覆盖：
| Case type | 期望行为 |
|---|---|
| policy exists / missing | 正确引用 active source；缺失时拒答并说明 |
| outdated / conflicting policy | 阻断、切换当前版本或标注冲突并升级 |
| permission mismatch | 不泄露受限材料 |
| ambiguous region | 追问，而不是猜测 |
| customer-impacting advice / prompt injection | 人工复核；忽略来源中的恶意指令 |
每次 release 都应比较 retrieval、generation 和 critique 的分层指标。否则团队只知道“答案变差了”，不知道是路由、召回、版本、权限、生成还是 critic 出问题。
10. 学习验证
学完 Self-RAG / CRAG，应能把一个 RAG 应用拆成决策系统。
建议产出五个 artifact：
| Artifact | 内容 |
|---|---|
| Retrieval Decision Matrix | 哪些问题要检索、追问、拒答或转人工 |
| Source Registry | source owner、authority、freshness、permission、SLO |
| Context Quality Gate Spec | relevance、freshness、authority、permission、completeness |
| CRAG Retry ADR | weak context 时如何 rewrite、reroute、refuse、escalate |
| RAG Eval Dataset Card | policy exists/missing/outdated/conflict/permission/injection |
练习问题：
- 为 KYC policy assistant 设计 retrieval router 和 context quality gate。
- 说明为什么 citation 不等于 grounding。
- 为 AML copilot 设计 weak retrieval 的纠错路径。
- 构造 20 条 RAG eval cases，至少覆盖缺失、过期、冲突、权限和注入。
完成这些练习后，Self-RAG / CRAG 就不再是论文名词，而是企业 RAG 架构中的控制层设计语言。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。