Agentic RAG

传统的 RAG 是一个线性过程，对知识切片向量化，利用向量检索和 BM25 混合检索，然后返回结果。

但 Agentic RAG 是循环迭代（规划 - 检索 - 反思 - 生成）。

生产环境中的架构选择

很多时候在生产环境中，Agentic RAG 我觉得使用最好的还是 CRAG，也就是纠错型的 RAG。

• Plan-and-Execute：适合复杂的研究活动。
• ReAct RAG：会大大增强反应时间。

而在生产活动中 RAG 很多时候只是一部分，引入分类器和评估器后就能很好承担检索的职责，毕竟在生产活动中，知之为知之，不知为不知最好，想 toC 那种还去网上检索反而增加很多不确定性。

CRAG 工作机制

CRAG 检索内容后，Grader 对内容与问题的「相关性」进行打分。

• 如果相关（Relevant）：进入生成节点。
• 如果不相关（Irrelevant）：触发 Query Rewrite（重写查询），或其他操作。

CRAG 的核心思想是将传统的线性流水线解构为一个具备记忆（State）与条件边的有向无环图（DAG）或循环图。

有向无环图 (DAG) 的优势

但我觉得绝大多数时候对于 RAG，有向无环图才是最好的选择。

为什么这么说呢？不出错就是最大的优势，循环图可能有更大概率产生幻觉。 而 CRAG 完全不相关直接出发兜底即可。

微循环与熔断机制

不过为了提高一些问题解决率，我们可以引入微循环和熔断机制：

1. 第一次检索：口语化输入 → 检索失败 → Grader 打分“不相关”。
2. Query Rewrite：LLM 结合历史对话和专有名词表，把“那个 5 门槛的 5g 尊享套餐”重写为标准的业务术语“畅享 5G 尊享版”。
3. 第二次检索（循环）：用标准的术语重新去库里查，精准召回。
4. 最终生成：完美回答用户问题。

所谓熔断就是在全局 State 中维护一个 retry_count。每一次进入重写节点，计数器 +1，到达设定的 count 就出发兜底节点。

但这个做法大大提高了检索时间，其实有点得不偿失，实际许多场景中对于检索时间要求很高，其实实际的工程就是取舍问题，带着镣铐跳舞，没有恒定的标准，业务和用户满意就行。