ContinuityBench: A Benchmark and Systems Study of Stateful Failover in Multi-Provider LLM Routing
本文介绍了 ContinuityBench，这是一个基准测试和有状态代理架构，它利用历史前向传递策略，在多供应商大语言模型（LLM）故障转移事件期间实现近乎完美的对话连续性，解决了无状态系统丢弃对话历史这一关键局限性。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你正在和一个非常聪明、友好的语音助手聊天。你们已经聊了十分钟，分享了你最喜欢的电影、关于会飞的烤面包机的怪梦，还有你秘密树屋的暗号。突然，这个语音助手的“大脑”感到一阵眩晕，需要切换到备用大脑来继续交谈。在计算机科学领域，这被称为“故障转移”（failover）。通常情况下，工程师们会确保新大脑能立即回答问题。但问题在于，这个新大脑根本不知道你是谁，也不知道你刚才说了什么。这就像是你走进一个房间，开始了一段对话，结果和你说话的人突然忘了你的名字，并问道：“你又是谁来着？”你不得不从头开始讲述你的整个故事。由 Metriqual 研究人员撰写的这篇论文，深入探讨了这种被称为“对话连续性”（conversational continuity）的具体问题。它提出了一个简单但至关重要的问题：当计算机系统在发生故障时从一个 AI 提供商切换到另一个提供商时，它是真的记得这段对话，还是只是在假装活着，实则患有失忆症？
研究人员发现，现有的标准做法是破碎的。如今大多数系统都是“无状态的”（stateless），这意味着它们将每一条消息都视为一个全新的、孤立的事件。如果主 AI 提供商崩溃了，系统会立即切换到备份，但它只会把你在对话中输入的最后一句句子发送给备份。它丢弃了你聊天中的整个历史记录。论文指出，这对用户体验来说是一场灾难。即使系统在技术上处于“运行中”状态，对话也已经死亡了，因为语境（context）已经消失了。为了证明这一点，作者构建了一个新的测试工具，名为 ContinuityBench。他们创建了 150 段虚构对话，并在聊天早期植入了“事实锚点”（fact anchors）——比如一个特定的日期、一个虚构的名字或一种喜欢的食物。然后，他们在用户针对该秘密事实提问之前模拟了一次崩溃。他们对比了两种系统：旧的“无状态”方式和他们设计的一种名为 History-Forwarding（历史转发）的新型“有状态”方式。
结果是戏剧性的。旧系统完全失败了。在他们模拟的所有 750 次测试崩溃中，备份 AI 对语境的记忆率为 0%。就好像对话从未发生过一样。用户会问：“我的秘密暗号是什么？”而新的 AI 会诚实地回答：“我不知道，你还没告诉我。”然而，新的 History-Forwarding 系统完全改变了局面。这个系统并没有只发送最后一条消息，而是抓取了整个对话历史，并将它像一本完整的绘本一样递交给备份 AI。这种新方法在保留语境方面的成功率达到了 99.20%。在极少数失败的情况下（750 次中有约 6 次），并不是因为系统忘记发送历史记录，而是因为备份 AI 模型本身在遵循指令方面出了点小错。
论文还解决了在尝试让数百人同时交谈时会遇到的棘手工程难题。他们发现，如果你不够小心，系统可能会意外地混淆两个不同人的对话，把 A 先生的秘密给了 B 女士。他们还发现，如果备份 AI 变得过于繁忙，一个简单的“重试”按钮可能会引发“惊群效应”（thundering herd problem），即成千上上个请求同时冲向备份服务器导致其崩溃。为了解决这个问题，他们使用了“带有抖动的指数退避”（exponential backoff with jitter）技术，这就像是告诉一群人，在尝试挤门之前要随机等待一段时间，而不是在同一秒钟集体推门。
简而言之，这篇论文证明了在计算机崩溃期间保持对话活跃，不仅仅是让灯亮着，更是要让记忆存续。通过将完整的历史记录转发给备份，他们展示了你可以实现高达 99.20% 可靠性的无缝、连续对话，且几乎不会给用户带来额外的延迟。他们甚至向公众发布了他们的测试工具 continuity-bench，以便其他工程师能够构建出不仅能回答问题，而且能记住故事的系统。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。