在评估 RAG 架构时，延迟直接影响实用性，因为它决定了系统是否能满足实时性能要求。 具有高精度但响应时间慢的 RAG 系统可能在优先考虑彻底性的场景（如研究或文档分析）中表现出色，但在用户期望近乎即时响应的应用程序（如实时客户支持或交互式工具）中失败。 延迟受多种因素影响，如检索复杂性（例如，密集向量搜索与关键字查找）、生成模型大小以及处理步骤的数量。 例如，使用大型语言模型 (LLM) 进行生成并从多个数据库进行详尽检索的 RAG 管道可能会产生高质量的答案，但需要几秒钟才能响应 - 这使其不适合实时使用。 开发人员必须根据应用程序的需求来平衡准确性和速度。
以客户服务聊天机器人为例。 如果 RAG 系统使用复杂的检索机制（例如，查询多个 API 并运行语义相似性检查）并搭配大型 LLM（如 GPT-4），则延迟可能超过 5-10 秒。 用户很可能会放弃交互，即使答案是准确的。 相反，使用较小 LLM（如 Mistral-7B）和快速向量数据库（如 FAISS）进行检索的更简单系统可能在一秒内提供答案，但准确性会降低。 另一个例子是医疗诊断：对于非紧急情况，交叉引用研究论文和患者数据的较慢的 RAG 系统可能是可以接受的，但在急诊室中是不切实际的。 这种权衡取决于用户对延迟的容忍度与他们对精度的需求。
为了优化实用性，开发人员可以采用混合策略。 对于实时用例，优先考虑低延迟组件 - 例如用于检索的近似最近邻搜索 (ANN) 或用于生成的精简 LLM - 同时保持可接受的准确性。 缓存频繁查询或预计算嵌入也可以减少延迟。 例如，旅行助手应用程序可能会缓存常见的目的地常见问题解答，以避免重新处理它们。 或者，并行化检索和生成步骤（如果可行）可以减少整体延迟。 如果准确性是不可协商的，则使用用户通知的异步处理（例如，“我们正在研究您的查询…”）可能会弥合差距。 最终，选择取决于应用程序的特定要求：实时系统偏爱速度优化的架构，而离线或批处理任务可以利用更准确但速度较慢的设计。
