云服务商服务器恢复后，Beat 的 PR 审查模型一夜之间变慢近 20 倍

我在开发 Beat 这个工具，它可以在云端审查 pull request（以及做其他一些事情），在有内容发布或发送之前，给用户一张卡片来审阅并批准这些工作。几天前，我们的 PR 审查在一个晚上之内几乎慢了 20 倍。我们的代码没有任何改动，环境和配置也没有任何变化，简单来说，模型发生了漂移，而我们没有及时发现。

我们的审查分为两个主要阶段。首先进行几轮扫描，从完整的代码 diff 中找出可能存在的问题；然后对每个问题单独进行验证，模型会阅读包括用法和引用在内的全部代码，并且必须证明或证伪最初提出的问题。几乎所有的“成本”和时间都花在这个阶段。

本质上并没有什么地方出错，我们的监控也没有捕捉到异常。审查仍在发布，bug 仍在被发现，产品看起来也在正常运行，只是我注意到，我团队审查我提交的小型 PR 所花的时间比以前长了很多。我以为一定是哪里变了，但什么也没变……除了模型。我们的云服务提供商出现了长达数小时的服务降级，而在恢复到“正常”之后，我们验证模型的行为就变了。

为了证明这一点，我们用几周前完全相同的构建和设置重新运行了旧的评估集。数千次审查，数万条记录。几乎每一次审查都花了更长时间，输出也明显更大。

接下来的大问题是：它是不是变差了？我们对每一条发现都做了准确率和误报的评估。准确率仍然非常高，而误报实际上还下降了。这个模型最终变得更细致，而不是更差。于是我们接受了它，并决定围绕它来改进我们的系统。我们增加了服务器容量和并行 worker，调整了严重性评级标准，也许最重要的是，加入了更好的监控和遥测，以确保速度是实时检查的，而不是等到有人被拖烦了才去查。

我构建 AI 系统已经有好几年了，做软件的时间还要长得多，但这里面总有令人兴奋和充满挑战的东西。我知道在当今这个时代，很多人对软件工程的长期前景感到悲观，但我个人认为，我们的技能从来就很少是打字，真正有价值的是创造性思维、问题解决和协作。这正是我们想用 Beat 去构建的东西。消除那些机械重复的工作，让我们所有人都有更多时间去做自己最擅长的事。

Beat 目前处于完全免费的私有 beta 阶段，如果你好奇想看看，可以访问 gobeat.ai，我很想得到一些反馈。我也很好奇其他人是如何应对托管模型漂移的。