Spark Notes

Appearance

Agentic RAG ​

Agentic RAG 将 Agent 的自主决策能力嵌入到 RAG 流程中，让检索不再是预设好的固定步骤，而是由 Agent 根据信息需求动态发起、评估和迭代。传统的 RAG 是静态的"检索一次、生成一次"，Agentic RAG 是动态的"边检索边判断，不够再查、不对重查"。

从静态 RAG 到 Agentic RAG ​

传统 RAG 的流程是固定的：用户提问 → Embedding 检索 → 拼接上下文 → LLM 生成回答。这个流程在简单的事实查询上表现良好，但面对复杂问题时暴露出明显的局限。如果第一次检索的结果不够充分（遗漏了关键信息），系统没有机制去判断"检索够不够"并追加检索。如果检索到的内容包含矛盾信息，系统也没有机制去交叉验证。

Agentic RAG 将 LLM 从"被动接收检索结果然后生成"的角色升级为"主动决定何时检索、检索什么、如何评估检索结果、是否需要重试"的决策者。Agent 拥有一个检索工具（通常是向量数据库查询接口），在推理过程中可以多次调用：收到问题后先分析需要哪些信息，执行初次检索，评估检索质量，决定是否需要改写查询（Rewrite）或子问题拆分（Decompose），然后执行补充检索，最终在信息充分后生成回答。

主要模式 ​

Self-RAG ​

Self-RAG 在生成的每个段落之后插入自我反思（Self-Reflection）步骤模型判断刚才的陈述是否有检索到的事实支撑。如果判断为"有事实支撑"，继续生成下一段；如果判断为"缺乏支撑"，触发一次补充检索，用新的检索结果修正或补充后续内容。这种模式的核心在于训练或提示模型输出特殊的反思 token（如 <Retrieve>、<Relevant>、<Irrelevant>、<Supported>、<NotSupported>），让模型学会自主控制检索时机。

Self-RAG 的优势是不需要外部编排逻辑——模型自身通过反思 token 驱动检索循环。但这也要求底层模型经过专门的训练（在包含反思 token 的数据集上微调），或者具备较强的指令遵循能力来模仿反思行为。

Corrective RAG ​

Corrective RAG（CRAG）在检索之后、生成之前插入一个"检索质量评估"步骤。评估器（可以是一个轻量级模型或基于规则的评分器）判断当前检索结果与问题的相关性和信息充分性。如果评分低于阈值，CRAG 自动触发查询改写（Query Rewriting）：可能是扩大搜索范围（放宽语义相似度阈值）、尝试不同的表述方式（用同义词替换原查询中的关键词）、或者执行 Web 搜索作为向量检索的补充。

CRAG 的关键工程决策是评估器的设计。基于 Cross-encoder 的 Reranker 天然适合这个角色——它不仅能排序，它的匹配分数也可以作为检索质量的代理指标。如果 Reranker 给出的最高分低于 0.3（在归一化后），说明即使排名最靠前的片段与问题的相关性也很弱，这次检索需要被纠正。

Adaptive RAG ​

Adaptive RAG 根据问题的复杂度自动选择检索策略。简单的事实查询（"某公司的 CEO 是谁"）单次检索即可，不需要走完整的 Agentic 流程。复杂的多跳推理问题（"对比 A 产品和 B 产品在过去三年中的市场策略变化及效果"）则需要问题拆分、多次检索、交叉验证。

Adaptive RAG 的实现通常依赖于一个复杂度分类器：在收到用户问题后，分类器判断问题的复杂等级（Level 1: 简单事实 → 无检索或单次检索，Level 2: 单一主题的多方面 → 多次检索但不需要拆分，Level 3: 多主题对比或推理 → 问题拆分 + 多轮检索 + 综合）。分类器可以是一个 prompt-based 判断（"这个问题的复杂度是 1/2/3 级？"），也可以是一个微调的小型分类模型。分级策略的目标是避免"杀鸡用牛刀"——简单问题不需要复杂的 Agentic 流程，从而节省延迟和成本。

工程落地 ​

Agentic RAG 生产化面临的最大挑战是延迟和可控性。传统 RAG 的延迟是可预测的（一次检索 + 一次生成），Agentic RAG 的检索次数是动态的，最坏情况下可能需要 5 次以上的往返。每个迭代又需要一次 LLM 调用来决策"是否继续检索"或"如何改写查询"，进一步增加了延迟。

工程上的应对策略包括：限制最大检索迭代次数（如 3 轮，超过后使用当前收集的信息直接生成，行业术语称为"硬截止"，Hard Stop）；对决策 LLM 使用更小、更快的模型（如用 7B 模型做检索决策，用 70B 模型做最终生成）；对确定性较高的问题跳过反思步骤直接生成（"快速路径"优化）；以及将多次检索并行化（当 Agent 决定需要查询多个子问题时同时发出检索请求，而非串行）。

另一个工程考量是引用追溯。Agentic RAG 的多次检索意味着最终回答可能融合了来自多个不同查询、不同时间点的检索结果。系统需要记录每条信息来自哪次检索、哪个 chunk，并在最终输出中精确标注引用来源，以便用户可以追溯和验证每一条事实陈述的出处。这要求检索系统在返回结果时携带足够的元信息（文档 ID、chunk ID、版本号），并在 Agent 的各次检索中保持完整的追溯链。