RAG 架构选型：2-Step、Agentic 与 Hybrid 怎么选

本文基于 LangChain Retrieval 官方文档整理，重点是架构选择，不绑定特定向量数据库或模型。

RAG 用查询时检索来缓解两个问题：模型上下文有限，以及训练知识不会实时更新。一个基本流水线通常包含文档加载、切分、Embedding、向量存储、Retriever 和生成模型。

真正影响系统复杂度的，是“谁决定何时检索”。

2-Step RAG

固定执行“先检索、后生成”。优点是调用次数已知、延迟可预测、容易缓存和评测，适合 FAQ、内部文档机器人和固定领域问答。

它的弱点是无论问题是否需要外部知识都会检索，而且单次检索失败后缺少自我修正能力。

Agentic RAG

模型在推理过程中决定是否检索、调用哪个数据源、是否继续追问。它适合研究助手、多数据源分析和复杂任务，但调用次数与延迟更难预测，也更需要预算、超时和工具权限控制。

Hybrid RAG

混合方案保留固定检索主链路，同时加入重写、验证或回退步骤。它在稳定性与灵活性之间折中，适合对答案质量有明确门槛的垂直领域。

方案	延迟	可控性	灵活性	典型场景
2-Step	低且可预测	高	较低	FAQ、文档问答
Agentic	可变	较低	高	调研、多工具助手
Hybrid	中等	中等	中等	有质量校验的专业问答

落地时先解决这些问题

1. 切分：按语义边界切，不要只按固定字符数；保存标题和来源元数据。
2. 召回：同时观察 recall、噪声和重复片段，top-k 越大不一定越好。
3. 生成约束：要求答案引用检索片段；证据不足时明确拒答。
4. 权限：检索前过滤用户可见范围，不能检索后再靠模型保密。
5. 评测：分别测检索质量、答案正确性、groundedness、延迟和成本。

建议从 2-Step RAG 开始：它最容易建立基线。只有当真实失败案例证明“固定检索不够用”时，再增加 Agent 决策或 Hybrid 验证步骤。

原文：LangChain Docs — Retrieval