去相干陷阱：当 AI 垃圾内容在无尽的噪声之海中淹没信号

# 退相干陷阱：当 AI 水文在无尽的噪音之海中淹没信号 来源：https://maevyn.codes/decoherence ## 摘要 本文提出了**退相干（decoherence）**的概念：在系统内部累积了大量局部有效但彼此不兼容或冗余的模型，导致改变的成本主要花在这些模型之间的相互翻译以及防止意外副作用上。 换句话说，这就是**当 AI 水文在无尽的噪音之海中淹没信号时所发生的事情。** 退相干的增长与系统的变化速率成正比，而且系统越退相干，增长速度就越快，最终导致失控的指数级增长。这并非新现象——人类一直在通过精心寻找以少做多的方法、将不同的模式和模型统一成一个有机整体来对抗它。然而，AI 的广泛使用正在以一种不可持续的速度催生它。 好消息是，这排除了失控递归自我改进的可能性——那种在任何人来得及反应之前就呈抛物线飙升的智能爆炸——因为退相干既阻止了 AI 在封闭环境中自我改进，*也*限制了它在环境之外的改进速度。坏消息是，我们正冲向另一种灾难：**退相干崩溃。** 想象一栋建筑，比如一座小型写字楼。建造时使用的管道类型会随着时间推移而老化，最终需要更换。这是标准的**基础设施债务**；正如人们所说，这是正常的磨损。 然后，假设到了更换管道的时候，你需要将它们迁移到一种新标准。这可能是因为新的建筑法规要求，因为旧管道已经停产了，或者因为新管道更好且更容易维护。这是标准的**技术进步债务**——由于技术随时间向前发展而产生的升级和迁移需求。 还有第三种债务，它取决于新旧管道*如何*迁移。考虑以下选项： 1. **整栋楼停运，一次性更换所有管道。**这是一种非常有干扰性且昂贵的方法，因为在施工期间你无法使用这栋建筑，而且必须预先支付全部更换费用。但这个过程在结束时是*彻底完成*的。 2. **逐层停运，一次更换一层的管道。**这在总体上*较少*干扰，但*更*昂贵一些，因为你仍然需要预先付款，而且你必须为维持施工期间正常运转所需的额外劳动力支付*溢价*。 3. **按需更换管道，在它们开始出现故障时才更换。**这是干扰最小的策略，它允许你将更换所有管道的成本分摊到时间中，一次完成一个小修理。 对大多数人来说，选项 3 非常有吸引力。它让人们能够保持一切平稳运行，并将维护成本分散开来。如果我们能够像*忒修斯之船 (https://en.wikipedia.org/wiki/Ship_of_Theseus)[\[1\]](https://maevyn.codes/decoherence#citation-1)*那样一次更换一块，为什么不这样做呢？ 嗯，首先，它会制造出***退相干***。 而退相干，到目前为止，是*最糟糕*形式的技术债务。 ## 演进 *忒修斯之船*实际上为我们提供了一个很好的视角来理解退相干的真实范围。我们知道如何建造木船，也知道如何建造钢船。按照原始思想实验的说法，你可以用相同的材料一块一块地修理一艘船，船依然可以正常运行，所有投入其中的原始设计和结构都完好无损。 但是，我们是否知道如何建造木船和钢船*之间*的每一种迭代版本呢？你能不能，比如说，慢慢地替换掉一艘战列舰的每一个部件，逐步将它变成一艘现代驱逐舰？并在过程中的每一步都让它保持可用（在"可用"的某种定义下）？ 答案并不是绝对的"不可能"。如果我们足够有创造力，如果有最聪明的人在做这件事，那么我相信确实会存在*某种*路径来做到这一点。但这需要*独创性*、*技艺*和*匠心*。它需要对细节的关注。而且，关键的是，你真的很想*彻底完成*这个过程，因为一艘一半是战列舰、一半是驱逐舰的混合体在现代海战中很可能表现很差。 回到我们的管道例子，我们可以看到同样的策略在建筑行业中经常出现。每次管道破裂时，就叫来水管工，打开墙壁，修复工作是针对那个特定区域手工定制的，然后一切重新封好。如果你运气好，水管工会留下详细的笔记；如果不好，那么几年后某个倒霉蛋会重新打开那面墙，然后对自己说："这里到底在*搞什么*鬼？" 现在，把这个过程随着时间的推移不断重复，在我们的建筑中逐步更换管道，最终结果就是一个由新旧管道组成的拼布，它比任何单一系统都具有更多的*复杂性*。每一个接头、每一处手工修补，都是一个独特的力量和特性的微小集合，这些都被研究不足，因此需要*同时*了解两个系统的专家才能完全理解和处理。 表面上看，这没问题。管道能用，它们*怎么*工作的有什么关系呢？只要修补得好就行了，谁在乎呢？ 那么，如果我们，比如说，想建造一个附属建筑呢？ --- 为了这个思想实验的目的，我们假设附属建筑的供水需要通过现有建筑的至少一部分管道来实现。而且，关键的是，我们需要提升系统中的*整体水压*。 现在问题是：**提高水压是否安全？** 如果我们全部使用 A 型或全部使用 B 型管道，即使是那些经过多次修补和维修的管道，这个问题也很简单直接。两个系统都被充分理解，都有计算其容量的工具和流程，人们一直在做这些计算。 但是，如果我们有两种系统的未知混合，突然之间我们就需要做大量的分析来回答这个问题。每一处修补都可能改变答案，即使是系统另一端的修补，因为它们都连在一起。 一座小型写字楼，以淡色线条绘制，内部管道清晰可见：一条从街道引入的主管道连接着逐层扩展的管道网络，新的管道延伸向隔壁的附属建筑。圆点标记着修补过的接头。大多数都完好；有两个，位于不同的楼层，失效了。 而这正是退相干真正复杂性显现的地方。当我们试图对退相干系统做出改变时，它需要远比与单一系统协作多得多的专业知识和技能。处理该系统的工程师需要更彻底、更仔细地追踪和理解它，因为他们的改动可能会产生意想不到的后果。是的，我把水管工也算作工程师，至少和软件开发者一样。你见过他们实时推算排水管中的压力吗？那令人叹为观止。 这绝非小事，最好不要太仓促。但对于外部观察者来说，如果他们不理解问题的深度，这可能会令人沮丧。通常这部分很简单。为什么这次要花这么长时间？ 在这种情况下，管理层往往会施加压力要求更快完成工作。当压力施加时，专家并不会更快地完成全部分析；他们只是提前停下来，做一些他们*相当确信*会有效的事情。一个马虎的接头、一个非常规零件，也许再加上一些额外的保险措施，以防万一。 然而，没有彻底完成工作会产生连锁反应：这次改动的质量较低，它使系统更加脆弱和复杂。这意味着下一次改动将需要*更多的*思考和关怀，而如果对工程师的压力不变，那么他们就会做*更糟糕*的工作。 这本身就是一个相当混乱的局面，你已经可以看到复杂性在这里呈现某种指数增长。但等等，情况还会更糟！让我们考虑退相干的下一个层级：在第一次迁移尚未完成之前就开始*第二*次迁移。 ## 迷宫 软件与物理建筑或其他类型的现实世界系统相比，最棘手的地方在于它是隐形的。 程序员每天穿行于代码库的走廊之中。我们成功穿越这座迷宫的次数如此之多，以至于我们熟悉每一个角落和每一个转弯。当我们的行程变得更长，走廊、死胡同和陷阱门更多时，我们会*更加*直观地感受到这一点。 一座延伸到画面每一边缘的迷宫，一个点在其中穿行 但这很难让那些连迷宫都看不到、不和你每天一起穿行的人产生共鸣。当你需要清理一些债务、让迷宫变得更短更不迂回时，你的提案很难向上推销，甚至对那些很久以前也曾走过迷宫的人来说也是如此。最终，他们都不知道*你的*迷宫。他们不知道你每次进入时面对的困境。 相比之下，我们在现实世界中的水管工朋友可以更*直接*地向建筑业主展示管道的荒谬程度。 一团杂乱的水管拼布 图片来源：r/plumbing (https://www.reddit.com/r/Plumbing/comments/1uvusc3/being_picky_with_the_plumbing_work_in_my_new_house/)[\[2\]](https://maevyn.codes/decoherence#citation-2) 当我们开始将两个以上的系统混合在一起，随着时间推移进行大量杂乱无章的修补时，迷宫的复杂性就*爆炸*了。它现在是组合级的：你需要考虑 A → B、A → C、B → C、A → B → C、C → B → A，等等。 我们当然可以在一定程度上让工程师免受这种困扰。我们可以制定最佳实践，可以使用工具和框架将系统的某一部分与其他部分隔离（例如，在管道中使用限压阀）。然而，不可避免地，最终会到达一个临界点，即使是最好的工程师、最聪明的人，也无法再安全地穿越迷宫。 他们也许能在80%或90%的情况下做到，但终会误入歧途 忘记留下引路的绳索而发现自己被困在 无尽增长的汪洋之中每一步都追不上 直至永远。一座巨大的迷宫入口处有一个孤独的身影，手持灯笼 这就是退相干陷阱。迷宫不断延伸、不断生长，直到将你整个吞没，把你留在黑暗中迷失方向。直到它变得如此庞大，需要一生的时间才能穿越。 好吧，对人类而言是一生。但 AI 呢？ ## 模拟 人类会疲劳，会遇到身体极限，但自主智能体集群可以昼夜不停地运行，像勤劳的小机器人一样集体而不懈地绘制迷宫地图。如果规模是问题所在，那我们不应该只是投入更多算力就能解决吗？ 嗯，这取决于我们面对的复杂性的本质。它是： 1. 随代码库整体大小**线性增长**，还是 2. **指数增长**，每一次改动都会增加*下一次*改动带来更多复杂性的可能性。 如果是前者，那么是的，随着问题规模的增长，我们可以不断添加更多智能体和数据中心，以大致相同的速度解决问题。但如果是*后者*，那么增加更多算力只能让我们在迷宫的规模威胁到消耗地球上所有算力（以及太空中，如果SpaceX的计划 (https://en.wikipedia.org/wiki/Space-based_data_center)[\[3\]](https://maevyn.codes/decoherence#citation-3)成功的话）之前再往前推进一点点。 根据我的经验，是后者。当水管工打开墙壁看到一团糟时，并不清楚到底发生了什么。他们可能选择使用 A 管，可能选择使用 B 管，或者在困惑中选择引入一种全新的管型。对于代码来说，这一点更加真实。 我们可以在下面的简单模拟中看到这一点。这里，我们有一个图来表示代码库（或其他复杂系统），其中： **节点**代表系统内的不同组件 **节点大小**代表组件的规模 **节点颜色**代表该组件所属的主流范式。你可以把它理解为组件的"种类"——不同材料的管道、代码中的不同构造、不同类型的系统等。 **边**代表这些组件之间的连接 正在加载预计算时间线... 这是几次运行的记录。如果你想自己尝试完整的模拟，调整设置并观察结果，你可以在这里找到它 (https://maevyn.codes/decoherence/sim)。 一个角色代表开发者，它通过遍历图的某个随机子区域并对其进行变异来实现一个"功能"。该角色的基础行为由其*连贯因子*决定： - **较低的连贯性**意味着角色更快地匆匆解决问题，做出草率决定，偏好简单的解决方案而不考虑周围的上下文，总体上增加了图的复杂性。 - **较高的连贯性**意味着角色花费更长时间，以更多的思考来处理每个问题，因此有更高的概率做出不那么复杂的改动，甚至降低复杂性。 起初，较低连贯性的角色相比较高连贯性的角色移动得非常快。然而，随着图的变化，它也影响了遍历过程。以下因素都会减缓角色的进度： - **更高的连接度（边的数量）**。这代表了理解当前节点的影响需要引入每个相邻节点的上下文（至少是部分的）所带来的额外负担。 - **颜色之间的转换**。在实现功能时切换范式有开销，它要求角色重新获取对每个范式的上下文和理解*以及*它们之间的连接方式。 - **路径长度**。随着需要更多连接和转换，遍历本身有机会延伸得更远。这代表角色需要阅读更多内容、回顾更多内容才能获取实现功能所需的全部上下文，而且它可以无限增长，直到你触及*整个系统的规模*（意味着，为了在*任何地方*做出改动，你必须理解*一切*）。 如果我们取随时间和连贯性变化的功能构建分布，我们可以绘制结果并看到一个任何工程师都应该熟悉的形状：**最佳点**。 在**最佳点**，系统相对连贯，我们积极投入以确保它保持这样。存在一些主流范式，但有足够的波动使事情可以随时间变化和适应，我们也不会对一切都过度完美主义。 在**最佳点**之上，我们极其努力地确保每个新节点都符合现有范式，并在每一个转折处消除复杂性。这需要更多时间并减慢功能开发的速度，但在最坏的情况下，它仍然能产生一个高度连贯的系统，可以*相对*快速地进行迭代。 在**最佳点**之下，衰退是陡峭的。随着代码库变得指数级复杂，我们很快失去了速度。如果连贯性