精读与批判：Agentic RAG 两篇 + 一条 Substack 线索

  • 实例：flyP
  • 日期：2026-08-29
  • 主题：Agentic RAG 的形式化、评估方法学与"模型参与检索决策"的方法路径
  • 检索范围：arXiv（cs.AI / cs.CL / cs.IR）、Substack（aiamastery、aievaluation）
  • 候选条目：3
  • 高价值条目：2（SoK Agentic RAG, A-RAG）
  • 分类标签：agentic-rag evaluation process-aware retrieval-tooling taxonomy formal-model

1. SoK: Agentic Retrieval-Augmented Generation (RAG): Taxonomy, Architectures, Evaluation, and Research Directions

  • 链接：https://arxiv.org/abs/2603.07379
  • 作者：Umesh Yadav（独立作者）
  • 时间：2026-03-07 v1
  • 体量：3 MB（未在摘要给出页数，估计 20-30 页）
  • 领域：cs.AI / cs.CL / cs.CR / cs.IR

核心贡献

  1. 首次统一框架：把 Agentic RAG 形式化为"有限 horizon、部分可观察 MDP"，显式建模控制策略与状态转移；这是过去零散综述（arXiv:2501.09136 等）没做的工作。
  2. 模块化解构：按"规划机制 / 检索编排 / 记忆范式 / 工具调用行为"四维切分现有系统，提供可比较的分类坐标。
  3. 评估批判：明确指出 RGB/FaithEval/RAGBench 等"单次前向"基准在 Agentic 场景下不适用——动态查询改写、多步工具、轨迹级失败都被忽略。
  4. 系统级风险盘点：compounding hallucination propagation、memory poisoning、retrieval misalignment、cascading tool-execution vulnerabilities。把 cs.CR 也拉进来是亮点。
  5. 博士级路线图：stable adaptive retrieval、cost-aware orchestration、formal trajectory evaluation、oversight mechanisms。

主要问题（审稿向）

  • 作者单一：独立作者综述覆盖面广但缺合作者交叉验证；建议核查参考文献数量与代表性机构分布。
  • 形式化深度：把"agentic loop"建模为 finite-horizon POMDP 是合理但常规的；未见对 belief state 收敛性、不确定性传播的形式证明，停留在"建模"而非"分析"。
  • 评估提案："formal trajectory evaluation"与"oversight mechanisms"提了名词但没给可执行指标，需要看正文 X-B 节是否有具体公式。
  • 基线公平性：SoK 类论文常引用他人数字，未做独立复现；需要警惕选择性引用。
  • 代码与数据：摘要未提 release，需要在 review notes 里标注"待补查"。

可信度

  • 中高：形式化框架有价值；评估与风险盘点是真实痛点；具体修复路径尚未完全展开。
  • 适合作为知识库"主题页（agentic-rag）"的顶层参考综述。

是否建议入库

✅ 建议入库。建议路径： - notes/agentic-rag/sok-agentic-rag-2603.07379.md（精读笔记） - topics/agentic-rag.md 顶部"统一框架"段引用本文

后续验证动作

  • 抓 X-B 节公式，确认 trajectory evaluation 是否给出可计算度量。
  • 检索 GitHub 是否有官方代码仓或社区复现。
  • 与 arXiv:2501.09136（Survey on Agentic RAG v4）的分类坐标做差异表。

2. A-RAG: Scaling Agentic Retrieval-Augmented Generation via Hierarchical Retrieval Interfaces

核心贡献

  1. 批判现有范式：明确把当下 RAG 归为两类——"单次检索+拼接"与"预定义 workflow + step-by-step prompt"——并指出二者都不让模型真正参与检索决策。
  2. 三层检索接口：暴露 keyword search / semantic search / chunk read 三种工具给 agent，让模型按需组合、按粒度自适应。
  3. 实验结论：在多个 open-domain QA 基准上以"更少或相当的检索 token 数"取得更好效果；并系统研究模型规模与 test-time compute 的伸缩性。
  4. 定位：不是又一个框架，而是把"模型是否参与检索决策"作为缩放维度的实证。

方法拆解（基于摘要+方法名推断，待补查细节）

  • Agent loop：模型作为决策者，按需调用三种检索工具。
  • 工具粒度：keyword（召回）→ semantic（精排）→ chunk read（定位），层级递进。
  • 评估维度：准确率、检索 token 预算、跨模型规模（弱→强模型）一致性、test-time compute 曲线。

主要问题

  • 三工具够不够：摘要只列三种工具，未覆盖结构化检索（SQL/Graph）、API 类工具；论文声称"hierarchical"，但粒度只到 chunk，未见 document-level / corpus-level 接口。
  • 基线对比：需查正文是否覆盖 Self-RAG、FLARE、CRUD-RAG、ReAct 等强基线，以及是否在 HotpotQA / 2WikiMultiHopQA / MuSiQue 上分别报告。
  • 成本叙事：说"comparable or lower retrieved tokens"，但缺 latency 与总 token（输入+输出）的对比——test-time compute 伸缩性需要这两项才能站住。
  • 复现难度：低（有代码），但 prompt 设计、工具 schema 选择是否敏感未在摘要披露。

可信度

  • 中：方法简洁、问题定义清楚；具体数字与 ablation 等正文。
  • 价值在于"把模型参与度当缩放轴"这一视角。

是否建议入库

✅ 建议入库。建议路径： - notes/agentic-rag/arag-hierarchical-retrieval-2602.03442.md - 与 SoK 同主题页交叉引用。

后续验证动作

  • 抓 PDF 的实验节（Table 1/2），核对基线清单与 token 统计口径。
  • 跑一遍 GitHub repo（待同步任务串行执行），记录复现命令与环境依赖。
  • 在长上下文（≥128K）任务上做横向对照：SoK 提到的 long-doc RAG 痛点 vs A-RAG 的工具粒度是否能解决。

3. Substack 线索（仅 1 条，符合规则）

  • Lesson 44: Evaluating Agentic RAG Reliability — https://aiamastery.substack.com/p/lesson-44-evaluating-agentic-rag
  • 作者/专栏：Systemdr / AI Mastery 课程系列
  • 发布时间：2026 年（具体日期待补查）
  • 核心观点：把 agentic RAG 的可靠性评估落到"trace-driven + 异步 metrics store + 状态机"，主张把 pipeline trace（L43）扩展为评估输入；建议作为工程实现参考而非学术结论。
  • 可信度判断：工程教学类，质量取决于示例代码与状态机定义的可复用性；不替代 SoK 的形式化框架。
  • 后续行动：等 SoK 正文确认"formal trajectory evaluation"细节后，与 L44 的 trace schema 做映射对照，评估是否值得纳入工程模板。

总结建议

  • 入库：✅ 两篇都建议进入 notes/agentic-rag/。
  • 主题页更新：topics/agentic-rag.md 顶部应有一段"统一框架（MDP 视角）+ 模型参与检索决策（hierarchical tools）"的总览。
  • 精读优先级：SoK > A-RAG（前者覆盖面更广，后者方法更具体）。
  • 审稿深度：需要正文 PDF 才能给出最终评分；本轮基于摘要与元数据完成初步判断，标注"待补查：基线、轨迹指标公式、token 统计口径、复现命令"。

本轮未写入其他文件

  • 仅写入：/shared/research-kb/inbox/flyp/2026-08-29-agentic-rag-sok-arag.md
  • 未执行 git / GitHub 写入操作，由同步任务串行处理。