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在推理过程中动态决定检索深度和范围，而不是每次都全量检索？这可能是平衡延迟和准确率的一个方向。