🔍 RAG 与 Agent 结合
检索增强生成(Retrieval-Augmented Generation, RAG)是连接 Agent 与外部知识的关键桥梁。当 Agent 需要超出模型训练数据范围的知识时,RAG 提供了按需检索、动态注入的能力。
📖 RAG 基础回顾
标准 RAG 流程遵循"检索 → 增强 → 生成"三步范式:
📥 用户查询
→
🔍 向量检索
→
📊 相关性排序
→
📝 上下文注入
→
🤖 LLM 生成
→
📤 增强回答
RAG 核心组件
| 组件 | 功能 | 典型技术选型 |
|---|---|---|
| 文档解析器 | 将原始文档拆分为可索引的文本块(Chunk) | Unstructured, LlamaParse, LangChain Document Loaders |
| 嵌入模型 | 将文本块编码为向量表示 | text-embedding-3, BGE, Jina Embeddings, Cohere Embed |
| 向量数据库 | 存储嵌入向量并支持高效 ANN 检索 | Pinecone, Weaviate, Milvus, Qdrant, Chroma |
| 检索器 | 根据查询向量搜索最相关的文档块 | 相似度搜索、混合搜索(向量+关键词) |
| 重排序器 | 对检索结果进行精排,提升相关性 | Cohere Rerank, BGE Reranker, Cross-Encoder |
| 生成器 | 基于检索到的上下文生成最终答案 | GPT-4o, Claude, Gemini, 开源模型 |
🤖 Agentic RAG:动态检索策略
传统 RAG 是一次性检索:查询 → 检索 → 生成。而 Agentic RAG 将 RAG 嵌入 Agent 的推理循环中,使检索变成 动态、多轮、自适应 的过程。
🧠 动态查询重写
Agent 根据检索反馈自动改写查询,进行多轮迭代检索。例如:初始查询结果不足 → 分析原因 → 生成更好的查询 → 再次检索。
🔀 自适应路由
根据查询类型自动选择合适的检索策略:事实查询走向量检索,关系查询走图数据库,结构化查询走 SQL。
📊 检索结果评估
Agent 对检索结果进行质量评估:是否相关?是否充分?是否矛盾?评估结果反馈到检索决策中。
🔄 多源融合
同时从向量库、知识图谱、API、数据库等多个来源检索,由 Agent 自行融合和去重。
🔗 多跳检索(Multi-Hop Retrieval)
复杂问题往往需要多步推理 + 多次检索才能获得完整答案。多跳检索将复杂问题分解为子问题链,逐步检索和推理。
示例:多跳检索过程
问题:"2024年获得图灵奖的科学家所在大学的人工智能实验室负责人是谁?"
Hop 1 检索:2024年图灵奖得主 → 某科学家
Hop 2 检索:该科学家所在大学 → 某大学
Hop 3 检索:某大学 AI 实验室负责人 → 目标答案
Hop 2 检索:该科学家所在大学 → 某大学
Hop 3 检索:某大学 AI 实验室负责人 → 目标答案
多跳检索实现方案
- IRCoT(Interleaving Retrieval with CoT):将检索步骤交错插入思维链中
- Self-Ask:Agent 自行生成后续子问题并逐一检索
- ReAct + RAG:在 ReAct 循环中,将"检索"作为一种 Action,根据 Observation 决定是否需要进一步检索
- Graph RAG:基于知识图谱的实体关系遍历实现多跳推理
📋 结构化数据检索
Agent 经常需要从结构化数据源(数据库、API、表格)中检索信息,这要求 RAG 系统支持 Text-to-SQL 或 API 调用能力。
| 数据源类型 | 检索方式 | Agent 能力要求 | 典型场景 |
|---|---|---|---|
| 关系型数据库 | Text-to-SQL | Schema 理解、SQL 生成、结果解读 | 业务报表查询、订单查询 |
| REST API | Function Calling | API 参数推断、响应解析 | 天气/股票实时数据 |
| 表格/CSV | Pandas/DataFrame 操作 | 代码生成、数据分析 | 数据统计、趋势分析 |
| 知识图谱 | Cypher/SPARQL 查询 | 图查询生成、关系推理 | 实体关系查询、知识推理 |
📊 RAG 在 Agent 中的应用模式
| 应用模式 | 描述 | 检索时机 | 复杂度 |
|---|---|---|---|
| 前置检索 | 在推理开始前一次性检索所有相关文档,作为静态上下文 | 推理前 1次 | 低 |
| 按需检索 | Agent 在推理过程中遇到信息缺口时触发检索 | 推理中 N次 | 中 |
| 迭代检索 | 根据前次检索结果的质量反馈,自动优化查询并重新检索 | 多轮迭代 | 高 |
| 并行多源检索 | 同时检索向量库、数据库、API 等多个来源,融合结果 | 并行 1次 | 高 |
| 混合检索 | 结合上述多种模式,根据任务特征动态选择策略 | 动态 | 极高 |
📌 RAG vs 微调 vs 上下文
| 维度 | RAG | 微调(Fine-tuning) | 长上下文 |
|---|---|---|---|
| 知识更新 | ✅ 实时(更新文档即可) | ❌ 需重新训练 | ⚠️ 需重新预置 |
| 知识容量 | ✅ 近乎无限 | ⚠️ 受参数容量限制 | ⚠️ 受窗口大小限制 |
| 推理开销 | ⚠️ 检索增加延迟 | ✅ 无额外推理开销 | ⚠️ 长上下文推理成本高 |
| 准确率 | ⚠️ 受检索质量影响 | ⚠️ 可能过拟合或遗忘 | ✅ 无损上下文 |
| 适用场景 | 知识密集型、频繁更新 | 风格/格式定制、领域适配 | 长文档分析、代码库理解 |
三者并非互斥。最佳实践是组合使用:微调提升基础能力,RAG 注入实时知识,长上下文承载当前任务的全量信息。