无法解释的故障的正常化

2026 年 9 月 27 日星期日 莫名其妙的失败正常化 在柯蒂斯总统最近的一集中，总统在两个不同的场合都难以打开一扇门。这些门不起作用，因为路上有障碍物：一开始是一具尸体，然后是价值大约十亿美元的黄金。在这两种情况下，为了应对挫败感，角色都会嘀咕“愚蠢的事情糟透了”。这不是一个合理的门模型！门不应该莫名其妙地“吸”！我发现这些时刻非常搞笑，但也许我愚蠢的大脑很糟糕。 Jev：制造更多糟糕的门 互联网上一直在热议 Jev，这是由 TypeSafe AI 开发的人工智能模型，它返回带有概率估计的键入值。据我所知，Jev 的重要之处在于：它快速且便宜，您可以在其上快速构建，它快速且便宜。我不太擅长了解将采用哪些技术。我还是不明白 ² Slack。但这个产品让我更困惑。这不是“获取 FTP 帐户，使用curlftpfs 在本地安装它，然后在安装的文件系统上使用 SVN 或 CVS”——您仍然需要完成困难的部分。要了解 Jev 是否​​有效，您必须构建评估和真实管道。如果您有评估和地面实况管道，那么您已经基本上可以微调自己的解决方案了。等待。你还需要做困难的部分吗？也许我的问题是期望产品发挥作用。没有人购买这个来运行评估。他们只是向杰夫提出不透明的问题并得到不透明的答复。仁慈的是，这使他们能够检查“人工智能驱动”的盒子并在周五之前发货，当这打破了下游逻辑时，他们总是可以耸耸肩说“好吧，人工智能会犯错误”。预算错误？失效模式？测试集？所有这些都可以稍后处理。用户可以发现故障率！你已经发货了！错误的信心“哦，”回复我帖子的稻草人回答说，“你没有考虑到杰夫给你信心分数的事实！”你打算用这些做什么？为了利用置信度分数做一些合理的事情，您需要了解这些置信度分数的校准以及不确定性成本的模型。在校准方面：Jev 的顶线广告文案主要是关于他们在各种基准上的得分如何，而不是关于他们的置信度得分如何校准。有一本关于使用置信度分数向上分类树的食谱，但这从根本上来说与置信度分数有多好无关。在建模方面：没有人愿意考虑这个。它总是最终成为“呃，让我们接受任何超过阈值的响应。0.9 听起来不错？午餐吃什么？”他们的文档本身构成了“不执行任何操作”的 0.5 阈值和“执行高风险操作”[存档] 的 0.9 阈值，并带有一个旁白信息框，说明“正确的阈值取决于您的领域和用例的模型性能”。充其量，人们以一种货物崇拜的方式使用信心分数。最坏的情况是，人们用它们作为 API 调用失败的借口。该模型的置信度只有 73%！这意味着我的错误预算是 27%！责任 当网站上的按钮损坏时，我有一个关于应该发生什么的模型。在某个地方，合同被打破了。我的 DNS 坏了。有人发布了一些仅在特定路径上存在 JavaScript 语法错误的垃圾。一名处理员投掷了预计不会投掷的东西。我可能无法仅调试 HTTP 状态 500，但我希望有人的工作是理解端点为何为 500。所有权虽然不透明，但定义明确。然而，对于许多用户来说，实际体验大致就是“愚蠢的事情糟透了”。软件已经给人一种反复无常的感觉；更多的失败只会改变挫败感的发生率。消除因具体原因而导致失败的可能性似乎并没有多大损失。有时事情很糟糕。这导致了莫名其妙的正常化。我担心的并不是当法学硕士驱动的开发加速时，更多的事情会失败。他们会的。他们有。这是以新颖的方式构建事物的代价的一部分。我担心“有时这很糟糕”将越来越成为调查的公认终点。这是令人悲伤的，因为LLM加速发展确实可以帮助我们解决其中一些问题。有大量自动化 QA 工作流程由于缺乏工程时间而没有编写。只需几个提示，就可以让您在很大程度上替换（甚至证明使用 Jev 的合理性）的评估。今天软件工程的悲剧在于，我们正在积极地设计系统，而用户和构建者似乎都没有兴趣检查门后是否有人。我们只是耸耸肩并得出结论：愚蠢的事情很糟糕。 1 这让我想起了一句话，我发现相似