P50 内存检索的 15 毫秒对语音代理毫无作用

我看到每个内存工具都用检索延迟来宣传，但这本身意义不大。我在将内存放入语音代理后发现了这一点。我面临的限制：语音轮次有一个硬性时间限制，从用户说话结束到第一个音频输出，如果耗时太长，用户会听到线路中断，他们开始再次说话，这会触发打断并搞乱下一个轮次。一个级联栈将时间分配到语音结束检测、TTFT、语音合成以及传输上，一旦这三者完成，剩下的时间很少，内存必须适应这个空间。问题 1：P50 不是正确的指标。一次呼叫是一系列轮次，而不是一个轮次，所以在几次呼叫中，你的 P99 绝对会显现出来。用户感受到你最差的轮次，听起来像代理在句子中间静默。我只在测量每个轮次而不是整体时发现了尾部延迟，主要是对具有数百个链接的实体进行图遍历。一个有 200 次交互的客户检索的内容与只有 5 次的客户完全不同，在干净测试存储上的 P50 中看不到任何这些。如果你在评估任何内存层，请要求在真实数据上并发下的 P99。问题 2：检索阻塞响应。基本流程是（语音结束 - 转录 - 检索 - 构建提示 - 调用模型），这将检索置于用户已经沉默的时期，每一毫秒都直接增加他们的感受。解决方案是预取，流式转录在用户仍在说话时发送部分结果，所以我根据部分结果进行检索，到语音结束时内存已经存在，一旦你预取，检索速度只在未命中时重要。问题 3：返回太多的快速检索更糟。注入的令牌在这些规模下大致线性地推高 TTFT，所以一个 15ms 的检索将几千个令牌转储到提示中，增加的延迟比检索节省的更多，因此你得到了一个好的基准但失去了轮次。我开始用令牌预算而不是 top k 来思考。跨存储排名并填充到预算，加上削减任何不值得令牌的内容，并从你的语音系统提示中移除 markdown，它会干扰合成，而且你还在为无用字符支付预填充。问题 4：用户在轮次中改变主意。例如“帮我预约周二，实际上不，周四并安排在下午。”这就是低检索延迟重要的地方，当猜测错误时作为恢复成本。我将每个预取视为推测性的，并在任何内容进入模型之前根据最终转录检查它。我的建议：对于任何在这个领域构建的人，测量每个轮次的 P99，在并发下，并在具有真实数据密度的存储上。在部分转录上预取。用令牌预算内存而不是结果，并计算你注入的任何东西的 TTFT 成本。在优化任何单一链接之前，对整个链进行检测。乐意回答任何问题，请提出你的问题:)