在问答系统中引入检索步骤通常会增加端到端延迟，相比于独立的LLM答案生成。 这是因为检索增加了顺序处理阶段：系统必须首先查询数据库或文档存储，处理结果，然后将相关上下文传递给LLM进行生成。 例如，一个独立的LLM可能需要2秒才能直接从其内部知识生成响应。 通过检索，同一系统可能花费500毫秒搜索像FAISS这样的向量数据库，200毫秒过滤结果，然后LLM花费1.5秒生成答案——总计2.2秒。 增加的延迟来自检索步骤本身、网络或磁盘I/O，以及检索数据的任何预处理。 但是，影响取决于诸如检索方法效率、数据大小以及系统优化方式等因素。
为了衡量这种影响，开发人员可以对系统进行检测，以跟踪每个组件花费的时间。 例如，使用日志记录或分析工具来记录检索和生成阶段之前和之后的时间戳。 A/B测试可以比较独立LLM和检索增强版本在相同查询下的延迟。 平均延迟、第95百分位延迟和吞吐量（每秒查询数）等指标有助于量化差异。 例如，一项测试可能显示，添加检索会使平均延迟增加30%，但答案准确性提高40%。 诸如Prometheus之类的工具或自定义日志记录脚本可以自动执行这些测量。 此外，开发人员应在实际负载下（大型数据集或高查询量）进行测试，以考虑扩展效应，例如缓存未命中或数据库索引延迟。
可以通过优化来缓解延迟影响。 缓存频繁访问的数据（例如，使用Redis）可以减少常见查询的检索时间。 并行化检索和生成的部分（例如，在LLM初始化时预取上下文）可能会有所帮助，尽管依赖关系通常会限制这一点。 选择有效的检索方法（例如，近似最近邻搜索而不是完全匹配）可以平衡速度和准确性。 例如，从Elasticsearch（基于关键字）切换到FAISS（基于向量）可能会将检索时间缩短一半。 开发人员还应考虑硬件：GPU加速检索或更快的存储（SSD与HDD）可以减少瓶颈。 最终，权衡取决于用例的优先级——如果准确性至关重要，则可以接受增加的延迟，但对于实时应用程序，尽管精度较低，但独立的LLM可能是更优的选择。
