查询缓存或预取常见问题 (FAQ) 可以通过减少冗余计算和延迟来提高检索增强生成 (RAG) 系统中向量存储的表观效率。当用户提交查询时，系统首先检查缓存中是否存在类似的问题。如果找到匹配项，则立即返回预先计算好的响应，从而绕过向量搜索和生成步骤。例如，在客户支持聊天机器人中，像“如何重置我的密码？”这样的常见查询可以被缓存，从而避免每次都重新处理嵌入或搜索向量数据库。预取则更进一步，它会在系统启动或低流量时段主动将预期的问题加载到缓存中，即使在高峰使用期间也能确保快速响应。这种方法减少了服务器负载，并通过最大程度地缩短高频问题的等待时间来改善用户体验。
评估启用缓存的 RAG 系统的主要优势在于它反映了实际的性能优化。由于缓存查询跳过了资源密集型步骤，因此响应延迟和吞吐量等指标会显得更有利。例如，一个每秒处理 1,000 个请求，缓存命中率为 40% 的系统，实际上只通过向量存储处理 600 个请求，从而降低了成本和基础设施需求。评估还可以受益于简化的基准测试：开发人员可以直接衡量由缓存带来的改进（例如，平均响应时间缩短 50%）。然而，如果测试数据集偏向于缓存查询，这种方法可能会高估效率。例如，如果评估使用一组静态的类似 FAQ 的提示，它们将无法反映缓存未命中或需要完全处理的罕见查询，从而导致不切实际的性能预测。
评估启用缓存的系统的主要缺点是它可能掩盖向量存储或检索逻辑中的潜在问题。例如，如果由于源数据更改（例如，更新的产品政策）而导致缓存答案过时，系统可能会提供不正确的响应，而不会触发向量存储查找。由于测试优先考虑缓存场景，评估也可能无法检测到未缓存查询的检索精度下降。此外，预取需要仔细调整：过度预取用户很少询问的 FAQ 会浪费内存，而预取不足则会限制效率提升。例如，一个预取关于“节日折扣”的季节性 FAQ 的旅游助手在 12 月份表现良好，但在 6 月份则会低效地使用资源。最终，缓存提高了表观效率，但通过将优化收益与核心系统能力混为一谈，从而使评估复杂化。开发人员必须通过分别测试缓存和未缓存的场景来平衡这些权衡。
