面试题 · 检索
在Agent系统落地实践中，检索增强生成（RAG）技术通常会面临哪些延迟和准确率方面的挑战？产生这些问题的根本原因是什么？
表现
根本原因
按学习路线查看教程、项目和面试题。
表现
根本原因
| 维度 | 传统RAG | Agent+RAG |
|---|---|---|
| 检索触发 | 单轮明确 | 多轮隐式（由LLM决策何时检索） |
| 上下文 | 当前Query | 历史对话+工具结果+检索结果累积 |
| 失败成本 | 单次回答差 | 可能引发错误工具调用链 |
核心矛盾：Agent的自主性要求检索模块既快又准，但两者往往此消彼长。实践中需在延迟约束下做精度妥协，或通过检索-生成流水线并行、缓存热点Query结果、自适应检索深度等工程手段平衡。
场景切入
我看你做过电商客服Agent。用户问‘我的订单到哪里了’,Agent先去查物流接口,再找知识库里的退货政策,最后生成回答。这种场景下,你有没有碰到过检索太慢或者答非所问的情况？具体是哪些延迟和准确率的问题？
层层追问
RAG在Agent落地时,你觉得主要有哪些性能瓶颈？……延迟方面,比如首Token出来慢、流式输出卡顿……准确率方面,召回不够或者噪声干扰……这些问题的根本原因你觉得是什么？
直球架构
请直接分析Agent+RAG系统在延迟和准确率上分别面临哪些核心挑战,并说明每个挑战产生的根本原因。不用展开具体方案,重点讲问题和根因。
这道题其实问的是[[RAG]]落地时最核心的工程博弈：延迟和准确率怎么平衡。咱们先看延迟。首Token延迟高，用户问一句，得等检索完才开始生成，体验很糟糕。根本原因是链路串行，向量检索、[[重排序]]、上下文组装、生成，各环节挨个跑，尤其是Rerank，[[Cross-Encoder]]精度高但慢，百毫秒级，成了瓶颈。还有上下文膨胀，检索Top-K文档后，长上下文导致Prefill阶段计算量激增。举个真实场景：客服系统里，用户问“我退款为什么还没到”，系统得先检索退款政策、订单状态、支付记录，再生成答复，如果每步都串行，用户等个两三秒，体验就很差。准确率方面，常见问题是召回不足和噪声干扰。比如用户说“满减政策”，但文档里写的是“促销活动”，语义不匹配，关键信息漏了。或者检索到相关但没答案的片段，导致[[Hallucination]]。根源是[[Embedding]]空间的语义鸿沟，用户口语化和文档正式化不对齐；还有[[Chunk]]切分粗糙，固定长度切分破坏语义完整性，比如把“满200减50”拆成两段，上下文丢了。[[Agent]]场景更复杂，多轮交互累积历史，工具调用结果和检索结果混在一起，失败成本高，一次检索不准可能引发整条工具链错误。所以落地时我不会追求极致精度，而是做工程取舍。我会用[[Hybrid Search]]，把关键词和向量检索结合，保证召回率；再根据置信度自适应检索深度，低分query少检索几轮；检索和生成流水线并行，首Token延迟能降30%。前提是得做好缓存，热点Query结果直接复用。常见失败场景是知识库更新滞后，如果政策变了，旧文档还在，检索出来就是错的。所以我会特别关注文档版本管理和动态更新。上线后我会监控Recall@K和延迟P99，如果召回率低于85%，就调大Top-K或加Rerank。我更倾向把RAG看成检索和生成的协作，而不是单独优化一个环节。延迟和准确率永远是跷跷板，关键是找到业务能接受的平衡点。说到这，我其实更关注一个延伸点：当Agent需要多跳推理时，单轮检索往往不够，这时候怎么设计检索策略？比如用户问“满200减50的券能和折扣叠加吗”，需要跨文档推理，先查券规则，再查折扣规则，最后判断是否冲突。单轮检索很难覆盖，我会考虑用[[Self-RAG]]让模型自己决定何时检索，或者用[[GraphRAG]]构建[[知识图谱]]，但延迟会更高。这就引出一个问题：能否让Agent在推理过程中动态决定检索深度和范围，而不是每次都全量检索？这可能是平衡延迟和准确率的一个方向。