要模拟真实的 RAG（检索增强生成）延迟，您必须考虑管道中的所有组件，而不仅仅是模型的生成时间。 这包括文档检索、模型加载、预处理和后处理。 例如，当用户提交查询时，系统首先从数据库或外部 API 检索相关文档。 此步骤的延迟取决于网络速度、数据库查询复杂性和检索数据的大小。 如果文档存储在像 Pinecone 这样的远程向量数据库中，则将查询转换为嵌入并搜索索引的时间会增加可测量的开销。 通过在测试中集成实际的 API 调用或数据库查询来模拟这一点，而不是模拟检索步骤。
接下来，模型加载和初始化会导致延迟，尤其是在模型未预加载的环境中。 例如，如果您的 RAG 系统使用像 Llama 2 或 GPT-4 这样的大型语言模型 (LLM)，则将模型加载到内存或 GPU VRAM 中可能需要几秒钟到几分钟。 即使模型已预加载，由于运行时优化，冷启动推理（启动后的第一个请求）通常也具有更高的延迟。 为了衡量这一点，在您的测试中包含一个“热身”阶段，以比较初始请求和后续请求的时间。 此外，输入文本的标记化和为 LLM 的上下文窗口格式化检索到的文档会增加处理时间。 例如，将 10 页的 PDF 分成可供模型使用的部分需要进行大量的计算。
最后，在真实的负载和基础设施条件下进行测试。 使用像 Locust 或 k6 这样的工具来模拟并发用户，这可以暴露瓶颈，例如数据库连接限制或 GPU 内存争用。 例如，如果 100 个用户同时查询系统，则由于数据库限制，检索延迟可能会飙升，并且模型推理可能会随着 GPU 处理多个批次而变慢。 此外，复制生产环境的硬件（例如，CPU/GPU 规格、服务之间的网络延迟）以避免结果出现偏差。 如果您的检索服务在与 LLM 不同的区域中运行，请包括跨区域 API 调用延迟。 使用像 Prometheus 或 OpenTelemetry 这样的工具记录每个步骤的持续时间有助于识别优化目标，例如缓存频繁的查询或预加载常见的文档集。
