我讨厌未来：莫名失败的常态化

在最近一集《President Curtis》里，总统两次被一扇门难住。

门打不开，是因为有东西挡着：先是个人，后来是价值大约十亿美元的黄金。

两次他都憋不住骂了一句“stupid thing sucks”。这根本不是对门的合理预期！门不该莫名其妙地“sucks”！这两段我笑得不行¹，也可能只是我这脑子太烂。

Jev：造出更多烂门

最近网上都在聊 Jev，TypeSafe AI 开发的一个 AI 模型，返回带概率估计的类型化数值。就我所知，Jev 的关键点在于：

快，便宜，
能很快在它上面搭东西，
快，
便宜。

我对哪种技术会被采用一向没什么判断力。

到现在我也没搞懂² Slack。

但这个产品让我更困惑。它不是什么“搞个 FTP 账号，用 curlftpfs 挂到本地，然后在挂载的文件系统上跑 SVN 或 CVS”——难的那部分你还是得自己做。想知道 Jev 有没有在正常工作，你得搭 eval 和一套 ground-truth 流程。而如果你已经有 eval 和 ground-truth 流程，那你离自己微调一套方案也就差最后几步了。

等等。

难的那部分真的还得自己做吗？

也许我的问题在于，我总指望产品能正常工作。

买这东西的人没一个会去跑 eval。他们只是把说不清的问题丢给 Jev，再拿回说不清的答案。往好里说，这能让他们勾上“AI 驱动”那一栏，赶在周五之前上线；等下游逻辑崩了，他们大可以一摊手：“AI 嘛，总会出错。”

错误预算？失效模式？测试集？这些以后再说。失败率让用户自己去发现就行了！反正你已经上线了！

虚假的信心

“哦，”那个在我帖子下回复的稻草人说，“你没考虑到 Jev 会给你置信度分数！”

你打算拿它们怎么办？

要用置信度分数做出合理的决策，你既需要理解这些分数的校准情况，也需要一个针对不确定性成本的模型。

校准这边：Jev 的首页广告文案主要讲的是他们在各种基准测试上得分多高，而不是他们的置信度分数校准得有多好。有一篇 cookbook 讲如何用置信度分数沿分类树向上爬，但那本质上跟置信度分数准不准没关系。

建模这边：没人愿意想这件事。最后总是变成“呃，超过阈值就接受吧。0.9 听起来差不多？中午吃什么？”他们的文档自己就编了一个 0.5 的阈值代表“什么都不做”、0.9 的阈值代表“执行高风险操作” [存档]，旁边还附了个信息框说“正确的阈值取决于你的领域以及模型在你这个用例上的表现”。

往好了说，人们是在以 cargo cult 的方式使用置信度分数。往坏了说，人们拿它当 API 调用失败的借口。模型只有 73% 的置信度！那我的错误预算就是 27%！

问责

当网站上一个按钮坏了，我脑子里有一套关于本该发生什么的模型。某个地方的契约被违反了。我的 DNS 坏了。有人发布了一坨垃圾代码，里面有条特定路径上才有 JavaScript 语法错误。一个本不该抛异常的 handler 抛了异常。面对一个 HTTP 500，我可能没有权限去调试，但我预期存在某个人，他的工作就是搞清楚这个端点为什么 500。责任归属是明确的，尽管是不透明的³。

然而对很多用户来说，实际体验大致就是“这破玩意儿真烂”。软件本来就让人觉得反复无常；更多的失败只是改变了沮丧的频率。把“从一次失败追溯到具体原因”的可能性去掉，似乎也损失不了什么。有时候事情就是很烂。

这导致“无法解释”被正常化。

我担心的不是 LLM 驱动的开发加速一切之后会有更多东西坏掉。它们会坏。它们已经坏了。这本来就是用新方式造东西要付的代价之一。

我担心的是，“有时候它就是很烂”会越来越成为调查的公认终点。这很可悲，因为 LLM 加速的开发确实能 帮我们 解决其中一些问题。有大量自动化 QA 流程没被写出来，只是因为工程时间不够。那个能让你基本走到替换 Jev（甚至只是为使用 Jev 提供正当理由）的 eval，可能只差几个 prompt。

当今软件工程的悲剧在于，我们正在主动构建这样的系统：无论用户还是构建者，似乎都无意去确认门后到底有没有尸体。

我们只是耸耸肩，得出结论：蠢东西就是烂。

¹这让我想起一句我觉得同样好笑的说法：“有时候你坐上电梯，有时候你被电梯坑。”这也不是一个合理的电梯模型！！

²锁定网络效应我能理解，但我仍然不明白人们怎么会标准化到一个连消息都不能可靠送达的产品上。我在免费、付费和企业实例上都见过消息被丢弃，几周后才出现。

³好吧，也许“定义明确”是乐观了。在 Bill Gates 著名地没能下载 Movie Maker 之后，大家都同意这大概是 某个人 的问题，只是不一定是自己的问题。理想情况下，我们甚至能在客户不是 Bill Gates 的情况下也达到这种问责水平。

Posted by

patrickxia