设计Agent+RAG系统需考虑哪些核心因素
P2 · rag
🏷 标签：agent, rag, system-design, retrieval, generation
1️⃣ 考察意图
面试官想看你能否跳出“搭积木”的思维，从系统设计层面权衡Agent+RAG的耦合关系。这不是考你RAG流程（检索-生成）的背诵，而是考察你对检索时机、Agent决策逻辑、上下文窗口瓶颈三者之间动态博弈的理解。刁钻点在于：很多人只讲“怎么检索”，却忽略了Agent的规划能力会如何影响检索策略（比如多步推理中检索结果如何缓存和复用）。答好了能展示你从单轮QA到多轮复杂任务系统的架构能力，以及处理延迟-成本-准确性三角冲突的实战经验。
2️⃣ 标准答
核心因素分四个维度：检索策略、Agent决策、上下文管理、系统鲁棒性。每个维度都有工程取舍。
1. 检索策略：不是越准越好，要匹配Agent的“思考节奏”
- 索引构建：分块策略是基础。固定大小分块（256 tokens）简单但丢失语义边界；语义分块（用embedding相似度切割段落）能提升召回，但计算成本高。取舍：对知识密集型任务（如法律文档），用语义分块+重叠窗口（overlap 10-20 tokens）避免信息断裂；对实时问答（如客服），用固定分块+BM25粗筛（k1=1.5, b=0.75）降低延迟。
- 检索方式：稀疏检索（BM25）适合精确匹配（如产品ID），稠密检索（DPR/ColBERT）适合语义匹配。实际落地的坑：只用稠密检索时，遇到罕见实体（如“2023年Q3财报中的非GAAP指标”）召回率暴跌。解法：混合检索（Hybrid Search）——BM25+稠密向量加权融合（权重可动态调整，比如实体词多时加大BM25权重）。
- Top-K选择：K值不是越大越好。K=3时生成质量高但可能遗漏关键信息；K=10时噪声增多，LLM容易“迷失在中间”（Lost in the Middle）。经验值：对128K上下文窗口的LLM（如GPT-4-128K），K=5-7是甜点区；对8K窗口的模型，K=3-4。
2. Agent决策：何时检索、如何复用
- 触发时机：Agent不是每步都检索。策略：① 固定触发（每轮对话都检索）——简单但浪费成本；② 按需触发（Agent判断当前问题是否需要外部知识）——用LLM自身做“是否需要检索”的二分类（prompt加一句“If the question requires up-to-date or domain-specific knowledge, call the retrieval tool”），但会引入额外延迟。取舍：对高实时性场景（如股票问答），用固定触发+缓存；对复杂推理（如医疗诊断），用按需触发+多步检索。
- 结果融合：Agent拿到检索结果后，是直接拼接还是让LLM自己筛选？坑：直接拼接会导致LLM被无关信息误导（比如检索到“苹果”的食谱，但用户问的是“苹果公司财报”）。解法：用Reranker（如Cohere Rerank 3）对检索结果重排序，只保留Top-2给Agent；或者让Agent在prompt中显式标注“只使用与问题直接相关的段落”。
- 缓存与复用：多步推理中，Agent可能重复检索相同问题。解法：用LRU缓存（容量1000条，TTL=30分钟）存储检索结果，Agent调用检索前先查缓存。代价：缓存命中率低时（<20%），维护成本反而高。
3. 上下文管理：窗口是硬约束
- 窗口压缩：Agent的推理链+检索结果可能撑爆上下文。策略：① 滑动窗口（只保留最近3轮对话+当前检索结果）；② 摘要压缩（用LLM对历史对话做摘要，每轮压缩到200 tokens）。取舍：滑动窗口丢失长程依赖（比如用户第1轮说“我喜欢科幻”，第5轮问“推荐电影”时模型忘了偏好）；摘要压缩有信息损失（摘要可能遗漏关键实体）。
- 位置编码：RoPE（旋转位置编码）对长上下文友好，但Agent+RAG中检索结果通常放在prompt末尾，导致LLM“注意力衰减”。解法：将检索结果放在prompt中部（紧接用户问题后），历史对话放末尾，利用LLM的“首尾注意力偏好”。
4. 系统鲁棒性：失败处理与评估
- 失败模式：① 检索为空（索引未覆盖）→ Agent应返回“我无法回答，请提供更多信息”而非瞎编；② LLM幻觉（检索结果正确但生成错误）→ 用忠实度检测（如SelfCheckGPT）做后处理。
- 评估指标：端到端用准确率+延迟（P95延迟<2秒）；组件级用检索召回率@K（K=5时>85%）和生成忠实度（用NLI模型打分，>0.9）。坑：只看准确率忽略延迟，系统可能不可用（比如医疗问答中检索耗时3秒，用户等不及）。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从检索策略、Agent决策、上下文管理、系统鲁棒性四个层面回答。检索层面，混合检索（BM25+稠密向量）比单一方式更鲁棒，Top-K控制在5-7；Agent层面，按需触发检索比固定触发更高效，但需用Reranker过滤噪声；上下文管理上，滑动窗口+摘要压缩平衡长程依赖和窗口限制；系统鲁棒性要处理检索为空和幻觉，并用P95延迟+忠实度做评估。总结一句：Agent+RAG的核心不是堆组件，而是让Agent的规划能力与检索的时效性、上下文的容量做动态适配。”
4️⃣ 高频追问 & 应对
追问 1：你提到混合检索，具体怎么实现权重融合？如果BM25和稠密向量打分尺度不同怎么办？
用归一化+加权求和。BM25分数先做Min-Max归一化（映射到[0,1]），稠密向量相似度（余弦相似度）本身在[-1,1]但通常为正，也归一化到[0,1]。权重α=0.3（BM25）和β=0.7（稠密向量）是常见起点，但需要根据数据分布调参。坑：如果数据中实体词多（如产品名），BM25权重应上调到0.5；如果语义相似更重要（如论文检索），稠密向量权重上调到0.8。可以用网格搜索（α从0.1到0.9，步长0.1）在验证集上找最优。
追问 2：Agent按需触发检索时，怎么避免LLM误判（比如该检索时没检索）？
用两阶段策略：第一阶段用轻量级分类器（比如一个小的BERT模型，参数量110M）做“是否需要检索”的二分类，准确率可达92%【通用知识】；第二阶段LLM只在分类器输出“需要”时才调用检索。代价：增加一次模型调用（延迟约50ms），但避免了LLM误判。如果预算有限，可以在prompt中加few-shot示例（比如“如果用户问‘今天天气’，需要检索；如果问‘1+1=？’，不需要”），但准确率会降到85%左右。
追问 3：上下文窗口有限，Agent多步推理时历史信息丢失怎么办？
用记忆模块（Memory Module）做外部存储。具体：Agent每步推理后，将关键信息（实体、关系、决策）写入向量数据库（如Chroma），后续步骤通过检索历史记忆来补全上下文。取舍：增加了系统复杂度（需要维护记忆的时效性和一致性），但能支持超过上下文窗口的长期推理。实际落地中，对10步以内的推理，用滑动窗口+摘要压缩就够了；超过10步，必须引入记忆模块。
5️⃣ 避坑 · 常见错误答法
- ❌ 只讲RAG流程（检索-生成-融合），不提Agent的规划能力 → ✅ 必须强调Agent如何决定“何时检索、检索几次、结果怎么用”，这是系统设计的核心。
- ❌ 说“Top-K越大越好，因为信息越多” → ✅ 要指出“Lost in the Middle”现象，K值需根据上下文窗口和任务复杂度调优，通常5-7是甜点区。
- ❌ 忽略失败处理，只谈理想情况 → ✅ 必须覆盖检索为空、LLM幻觉、延迟超标等异常场景，并给出具体解法（如缓存、忠实度检测）。
6️⃣ 简历呼应
- 如果你有RAG项目：从“混合检索权重调优”切入，展示你在实际数据上如何用网格搜索找到α=0.4的最优值，以及如何用Reranker解决噪声问题。
- 如果你只做过传统NLP：用“信息检索+文本生成”的类比迁移，比如把BM25比作TF-IDF的升级版，把Agent比作多轮对话中的状态追踪，强调系统设计中的trade-off思维。
- 如果你是校招无项目：聚焦论文复现（如“Lost in the Middle”实验），用公开数据集（如Natural Questions）对比不同Top-K下的准确率，展示你对系统瓶颈的理解。
7️⃣ 延伸阅读
- “Lost in the Middle: How Language Models Use Long Contexts” (Liu et al., 2023)
- “REALM: Retrieval-Augmented Language Model Pre-Training” (Guu et al., 2020)
- “ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction” (Khattab & Zaharia, 2020)
- “SelfCheckGPT: Zero-Resource Black-Box Hallucination Detection” (Manakul et al., 2023)
- 博客：LangChain Agent + RAG 官方文档（含缓存和记忆模块实现）