02｜如何设计一个 Agent+RAG 系统？需要考虑哪些因素

P2 · rag

🏷 标签：agent, rag, system-design, retrieval, evaluation

1️⃣ 考察意图

这道题是典型的系统设计 + 工程取舍类问题，面试官真正想看的是：你能否从业务目标出发，把 Agent 的自主决策与 RAG 的检索能力有机融合，而不是简单堆砌组件。刁钻点在于：Agent 何时触发检索、如何管理多轮记忆、检索结果如何影响 Agent 决策——这三者耦合极易失控。答好了能展示：系统架构思维、对检索与推理边界的理解、以及落地时对延迟/成本/准确率的权衡能力。

2️⃣ 标准答

设计一个 Agent+RAG 系统，核心是从业务目标倒推架构，而非先选工具。我分四个层面展开：

1. 明确系统目标与边界

先问：是单轮问答（如客服 FAQ）、多轮任务执行（如数据分析助手），还是决策支持（如投资建议）？
目标决定 Agent 的自主度：问答场景用 ReAct 模式（思考-行动-观察循环），任务执行用 Plan-and-Solve（先规划再执行），决策支持需引入自我反思（Reflexion）。
工程约束：目标延迟（如<2秒）、成本（如每次检索<0.01元）、数据规模（如百万级文档）。

2. Agent 核心能力设计

规划：用 LLM 的 Chain-of-Thought 生成子任务，但需加防循环机制——设定最大步骤数（如5步），超时回退到默认答案。
工具调用：定义函数式 API，如 search_knowledge_base(query, top_k=5)、summarize(text)。工具描述要精确（如“用于检索公司内部政策文档，输入是自然语言问题”），否则 Agent 会误用。
记忆管理：多轮对话中，用滑动窗口（保留最近3轮）加摘要压缩（当窗口超 token 限制时，用 LLM 生成历史摘要）。坑：记忆膨胀导致检索噪声——解法是只将当前轮 query 与摘要拼接后检索，而非全量历史。

3. RAG 组件选型与调优

文档切分：按语义段落切（用 spaCy 或 LangChain 的 RecursiveCharacterTextSplitter），chunk_size=512 token，overlap=128 token。trade-off：小 chunk 提升检索精度但丢失上下文，大 chunk 反之——对问答场景，优先精度，用重排序弥补上下文。
嵌入模型：稠密检索用 bge-large-en-v1.5（768维，MTEB 排名前10），稀疏检索用 BM25（默认 k1=1.5, b=0.75）。混合检索：线性加权（权重 0.3 BM25 + 0.7 稠密），或 RRF（Reciprocal Rank Fusion）合并排名。
重排序：必加！用 Cohere rerank-v3 或 BGE-reranker-v2，取 top-20 检索结果重排后保留 top-5。实测：重排序后答案准确率提升 15-20%，但增加 200ms 延迟——可接受。
向量数据库：Milvus 或 Qdrant，用 HNSW 索引（efConstruction=200, M=16），支持标量过滤（如按文档日期筛选）。

4. Agent 与 RAG 的交互机制

触发时机：两种模式——① 规则触发：Agent 检测到 query 含“政策”“流程”等关键词时调用检索；② 模型决策：Agent 自主判断是否需要外部知识（如“我需要查一下最新规定”）。推荐混合：规则做快速兜底，模型做精细判断。
结果注入：不要直接拼接原始 chunk！用 LLM 生成摘要（如“根据文档 X，结论是 Y”），或结构化输出（如 JSON 格式的“来源+结论”）。坑：Agent 可能过度依赖检索结果而忽略自身推理——解法是加 prompt 约束：“如果检索结果与你的知识冲突，优先相信检索结果，但需标注来源”。
错误处理：检索无结果时，Agent 应主动问用户澄清，而非编造答案。设定 fallback 策略：先重试（换检索参数），再降级（用 LLM 自身知识），最后道歉。

5. 评估与迭代

离线指标：检索召回率（Recall@5）、答案准确率（F1）、Agent 任务完成率（如多跳问答的 EM）。
在线指标：用户满意度（点赞/点踩）、任务完成时间、成本（API 调用次数）。
迭代策略：用 A/B 测试对比不同检索策略（如 BM25 vs 混合检索），或不同 Agent 模式（ReAct vs Plan-and-Solve）。坑：离线指标好不代表在线好——需关注用户真实反馈，如“答案太长”可能需调整摘要长度。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从三个层面回答：第一，明确系统目标，是问答、任务执行还是决策支持，这决定 Agent 的自主度和 RAG 的复杂度；第二，设计 Agent 的规划、工具调用和记忆管理，同时选型 RAG 的切分、嵌入、检索和重排序组件；第三，定义交互机制，包括触发时机、结果注入和错误处理。总结一句：好的 Agent+RAG 系统不是堆组件，而是从业务目标出发，在准确率、延迟和成本之间做工程取舍。”

4️⃣ 高频追问 & 应对

追问 1：多轮对话中，Agent 如何避免重复检索相同信息？

用缓存机制：对每个检索 query 计算 embedding，存入内存字典（key=query embedding，value=结果）。新 query 先计算 embedding，与缓存中的 embedding 做余弦相似度，若>0.95 则直接复用缓存结果。同时，Agent 的 prompt 中加指令：“如果你已经检索过类似问题，直接引用之前的结果，不要重复检索。” 实测：缓存命中率约 30%，减少 20% 的 API 调用成本。

追问 2：如果检索结果与 Agent 的自身知识冲突，怎么处理？

优先相信检索结果，因为 RAG 的知识库通常更权威。但需做冲突检测：让 LLM 比较检索结果和自身输出，若差异大（如答案相反），则触发“冲突解决”流程——① 标注来源（如“根据文档 X，答案是 A；但根据我的知识，答案是 B”）；② 让用户选择；③ 记录冲突案例用于后续知识库更新。坑：不要直接覆盖 Agent 知识，否则可能引入错误。

追问 3：如何评估 Agent 的规划能力是否有效？

用“子任务完成率”指标：将 Agent 的规划拆解为子任务（如“检索-分析-总结”），人工标注每个子任务是否完成。同时，用“规划效率”指标：实际步骤数 vs 最优步骤数（如多跳问答中，最优是 2 步检索，Agent 用了 4 步则效率低）。工具：用 LangSmith 或 Weights & Biases 记录 Agent 的每一步，可视化分析规划路径。

5️⃣ 避坑 · 常见错误答法

❌ 直接说“用 LangChain 的 Agent+RAG 模板就行” → ✅ 应该先分析业务目标，再选组件，因为模板化方案无法处理多轮记忆、检索冲突等工程细节。
❌ 认为 Agent 应该每次都检索，保证准确性 → ✅ 应该设计触发机制，避免过度检索导致延迟和成本飙升，比如对简单问题（如“今天天气”）直接让 LLM 回答。
❌ 只谈 RAG 的检索精度，忽略 Agent 的规划能力 → ✅ 应该平衡两者，因为 Agent 的规划错误（如检索错误 query）比检索精度低更致命。

6️⃣ 简历呼应

如果你有 RAG 项目：从“多轮对话中记忆管理”切入，展示你如何用滑动窗口+摘要压缩解决检索噪声问题，并给出具体数据（如 F1 提升 10%）。
如果你只做过传统 NLP：用“信息检索 vs 对话系统”类比迁移，强调 BM25 和稠密检索的 trade-off，以及如何用重排序提升答案质量。
如果你是校招无项目：聚焦“ReAct 模式”的论文复现，用 LangChain 实现一个简单的 Agent+RAG demo（如基于 Wikipedia 的问答），并分析延迟和准确率的权衡。
《ReAct: Synergizing Reasoning and Acting in Language Models》（Yao et al., 2022）
《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》（Lewis et al., 2020）
《BGE: A Family of Embedding Models for General Retrieval》（BAAI, 2023）
《LangChain: Building Applications with LLMs through Composability》（LangChain 官方文档）
《Milvus: A Purpose-Built Vector Data Management System》（Milvus 技术白皮书）

—— 本场面试完 ——