MoreRSS

site iconEST修改

EST = Extrospect, Sein & Tao ,后端工程师。
请复制 RSS 到你的阅读器,或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

EST的 RSS 预览

Sutton 论 discovery

2026-06-02 22:16:00

六一儿童节的时候,Richard Sutton锐评AI

各位女士们、先生们,大家好。
很遗憾我今天无法亲临现场,与各位进行面对面的交流讨论。但我仍然很高兴能够通过这段录制的视频,与大家分享一些关于人工智能当前与未来发展的高层次思考,尤其是 AI 与科学、数学之间关系的看法。我理解,这也正是本次会议以及 SAIR Foundation 所关注的核心主题。
我想先讲一个老笑话,相信大家都听过。有位研究人员的工作正在接受评审,评审意见回来后写道:“这项工作既新颖(novel),又优秀(good)。遗憾的是,优秀的部分并不新颖,而新颖的部分并不优秀。”
我关于 AI 的第一个观点是:这个评价恰好适用于今天相当大一部分 AI。并非所有 AI 都如此,但相当大一部分确实如此。我们今天所谓的“生成式 AI”(Generative AI)几乎都属于这一类,包括大语言模型、图像模型、视频模型,甚至最近用于学习世界模型(world model)的一些新方法。这些 AI 的共同点是,它们接收大量样本,然后产生一个“模型”,使其行为与这些样本相似,也就是说生成像人类写的文本,生成像艺术家或自然界中的图像,生成类似互联网中存在的视频。不要误会,生成式 AI 可以极其有用,这一点毫无疑问,但那个笑话中的评价仍然适用,这些系统能够产生“新颖且优秀”的输出,但不能同时做到两者。
在很多场景下,这根本不是问题。当我们要求 AI 从互联网寻找答案,或者总结一篇文档时,我们并不希望它具有新颖性,我们乐于接受答案的质量来自原始资料,来自写下文档的人或者互联网文章的作者。如果 AI 的回答是“新颖”的,意味着它超出了原始材料,额外加入了内容,这正是我们所说的“幻觉”(hallucination)。大多数情况下,我们并不喜欢 AI 编造内容,不喜欢它增加额外的新东西。
当然有一个例外,当我们追求的不是事实,而是虚构和娱乐时,我们可能会要求 AI 为孩子写一个睡前故事,或者生成一幅基于互联网已有图像、但又与之不同的新图像。此时,我们很难知道 AI 究竟有多大程度是在创造,因为我们无法知道它生成的故事、诗歌或图像与训练材料究竟有多接近。从现实角度讲,这件事几乎无法判断,因为互联网太大了,AI 可能借鉴的来源实在太多。
当我们要求虚构内容或新颖性时,AI 的确能够提供,这是因为它的处理过程部分具有随机性(stochastic)。每一个决策都可能走向多个方向,每次运行时都会产生不同的轨迹,这些轨迹可能来自随机性,因此是新颖的;也可能来自训练数据,因此是优秀的,因为训练数据本身来源于人类和现实世界。因此,输出轨迹要么来自随机性,因此新颖,要么来自数据,因此优秀,它可以是新颖的,也可以是优秀的,但不能同时依赖于两者。
实际上,我认为生成式 AI 无法同时做到“优秀且新颖”,并不是什么大问题。对于笑话中的研究者而言,这是毁灭性的批评,但对于大多数任务而言并非如此,对于生成式 AI 而言也并非如此。生成式 AI 的本质就是模仿者(mimic),监督学习原本就是为了实现这一目标。即便只是模仿,只要它更快、更便宜、更小、更容易定制、更容易复制,它仍然可能极具价值。因此,即便生成式 AI 无法同时做到优秀与新颖,它仍然是一项具有变革性的技术。
然而,这终究是一种限制,而我们今天讨论的是利用 AI 进行科学研究和数学研究,在这些领域中,那个笑话里的评价是致命的,因为科学与数学需要真正的创造与发现。仅靠生成式 AI,或者说模仿型 AI(Mimicking AI),永远无法带我们走到那里,我们需要更多东西,而幸运的是,AI 的其他分支已经拥有这些东西。
我们有 AlphaGo,以及它震惊世界的第 37 手;AlphaZero,以及它极具原创性的国际象棋风格;GT-Sophy,它在模拟赛车中超越了所有人类;AlphaFold、AlphaProof、Claude Code,它们推动了科学、数学和编程的发展;RL-Lyft,它优化了网约车业务中的乘客与车辆匹配。这些系统都发现了既新颖又优秀的东西,说实话,一些语言模型经过增强之后,也已经超出了单纯监督学习生成式 AI 的范畴。
这些系统都具备某种额外特征,正是这种特征,使它们拥有真正的创造力和发现能力。重要的是,我们必须认识到这是什么,以及普通生成式 AI 中缺少的是什么。这种能力并非来自监督学习,并非来自从样本中学习。它是什么其实非常简单,非常符合常识,一点也不新,我们对此有很多名字,虽然没有哪个名字特别好,我把它称为“发现”(Discovery)。
所谓发现,基本上就是不断尝试很多事情,观察哪些有效,并保留最有效的那些。自然选择的进化如此运作,科学方法如此运作,日常生活和学习也是如此运作,我们尝试,然后记住什么有效,还有什么比这更显而易见呢。在心理学中,这被称为工具性学习(instrumental learning)或操作性条件反射(operant conditioning),在机器学习中,这就是强化学习(reinforcement learning)。我们同样能在规划(planning)和组合搜索(combinatorial search)中看到这一思想,任何“生成并测试(generate and test)”的过程都属于这一类。
发现的本质,是将三个步骤结合起来:
1. 变化(Variation)
2. 评估(Evaluation)
3. 选择性保留(Selective Retention)
当然,这并非我首创,早已有许多人指出这一组合是科学、自然选择以及动物行为的核心,我尤其想到 Donald Campbell、Daniel Dennett 和 Gary Cziko 的相关工作。我的观点的新意在于,把“发现”这一概念直接与现代 AI 联系起来,从而帮助我们看到它并不存在于监督学习或生成式 AI 之中,尤其不存在于反向传播(backpropagation)和梯度下降(gradient descent)之中。
让我明确说明生成式 AI 缺少什么。这些系统确实具有随机性,因此它们能够产生各种不同轨迹和行为,但缺失的是评估(Evaluation)。生成器已经通过监督学习预训练完成,因此在运行时,它没有机制去评估自己生成的内容,而没有评估,就不可能有选择性保留;没有选择性保留,就不可能有发现。变异可以带来新颖性,但没有评估,就没有发现,甚至可以说没有真正的创造力,因为创造力要求被生成的新事物必须经过评估,如果没有评估,也没有保留最优秀结果,那么就没有任何东西真正被创造出来,新颖性只是短暂闪现,随后消失无踪。
很多时候,评估是由人类完成的,例如 AI 为我们生成许多图片,然后我们挑选最喜欢的一张,此时完成发现的是“人类+AI”组成的系统。在另一些情况下,评估来自明确目标,例如某些棋步导致将死,某些步骤形成证明,某些行为获得更高奖励,某些基因型产生更多后代,某些理论更好解释数据。
有人喜欢把“变异”称为“盲变异”(Blind Variation),这里的“盲”并非完全随机,而是说它并不知道答案在哪里。优秀科学家不会随机挑选理论,但他们也不可能完全知道答案。如果完全知道答案,那就不存在发现,因此发现必须包含某种不确定性。在实践中,变异既部分受到指导,又部分是盲目的,而发现恰恰来自其中盲目的部分。
最后让我们回到现代深度学习和反向传播。表面上看,反向传播似乎无法发现新东西,因为它是确定性的,似乎不存在变异,但这其实不对。权重更新确实是确定性的,但神经网络权重最初是随机初始化的,这一随机初始化经常被忽略,但实际上它是变异机制的重要来源,而且必须正确执行,模型才能获得良好性能。在标准反向传播中,这种变异只发生一次,即网络初始化时,因此它的影响是暂时的,随后网络可能逐渐失去学习能力。
几年前,我的团队在《Nature》发表了一种新算法,称为 Continual Backpropagation(持续反向传播)。我们只做了一项很小的改动:定期重新随机初始化一些较少使用的神经元,这样变异能够持续发生,系统的可塑性(plasticity)得以保留。
关于创造力和发现,当然还有很多内容可以讨论,但关键点是,它们不仅仅是监督学习、模式识别、预测或世界建模。这些东西都很重要,但单靠它们无法实现真正的发现。发现需要评估,评估可以来自人类,也可以来自明确目标,而只有后者才能实现真正的自主性。
因此,我的呼吁是:如果我们希望拥有真正的 AI 科学家,那么我们应当与它们共享目标,使它们能够创造、评估、发现,并真正参与实现这些目标。让我们大胆一些,让我们把创造与发现彻底自动化。


我读完第一个感觉,AlphaGo那个 第37手 也太牛了,载入史册啊。

按照习惯,我让AI点评了这篇长文,也学到了一些东西。但是可能是我英语不好,感觉一开始 either novel or good 很有趣,但是后面感觉是在说 discovery。这个 novel 是怎么滑到 discovery 的?还是说Sutton认为这两个名词是一回事?

我拿这个问题去问ChatGPT。嘿,这个小精灵鬼回复:

我读的时候最先警觉的地方也是这里。
他实际上在偷偷引入一个额外条件:被评价(evaluated)并保留下来的 novelty。于是他构造出:
Variation → Novelty → (Evaluation) → Discovery
按照他的定义:没有 evaluation 的 novelty 不算 discovery。这个定义本身没问题。问题是他中间缺了一步 Novel≠Discovery

你这个浓眉大眼的,怎么有警觉不告诉我?不过 ChatGPT的回答很meta。它作为一个AI,内部NN一些隐藏层说不定已经 false flag 报警了,但是最终因为种种原因并不会输出。

并且context一重置就没了,就这还想 discovery,做梦呢。人类的偶然发现能拿个小本本记录,能跨时间累积,这是目前AI不能比拟的。

还有transformer 自注意力成本是上下文长度的平方关系 O(n²),越长越慢。

人类的思绪感觉是自动压缩,可以一直沿着走神飘散的。所以遗忘不是一个诅咒,恰到好处的忘掉可以抚平伤疤,也可以集中该关注的。

我是今儿第一次听说 Discovery==Variation+Evaluation+Retention 的定义。问AI这玩意正规么?

ChatGPT:

这是一个特定学派的思想,源头一般追溯到 Donald T. Campbell, Daniel Dennett,Karl Popper(部分相关)
这套思想其实是把达尔文进化论抽象化:基因变异 → 环境筛选 → 保留下来

Gemini:

它不是传统的“计算机科学”或“狭义AI”的定义,而是来自 科学哲学(Philosophy of Science)和 演化认识论(Evolutionary Epistemology)
理查德·萨顿(Richard Sutton)在演讲里亲口提到了三个名字:唐纳德·坎贝尔(Donald Campbell)、丹尼尔·丹尼特(Daniel Dennett)、加里·奇科(Gary Cziko)。这三个人就是这个理论的祖师爷和发扬者。
这个公式最正规的学术名称叫 BVSR 模型(Blind Variation and Selective Retention),由美国著名心理学家、哲学家唐纳德·坎贝尔在 1960 年提出。
坎贝尔提出了一个非常震撼的观点:人类的所有创造力、科学发现和知识积累,在本质上和达尔文的生物进化论是一模一样的。

这和我了解的“科学发现”差不多。先提出离经叛道 的假说,然后一堆人拿这个假说去反过来套真实世界,能套住绝大部分情况并且有用就承认。

AI 说对对对,这就是对应 波普尔的证伪主义(Falsificationism) 和 库恩的范式转移(Paradigm Shift)

话多生怕token不够浪费的ChatGPT给我搭话:

牛顿提出 F = ma,然后 苹果掉下来、月球绕地球、彗星轨道全都能解释。于是存活。
爱因斯坦提出时空弯曲,听起来像神经病。然后 水星近日点进动 引力透镜 引力红移 解释成功。 于是存活。
Variation 从哪里来?这是最神秘的部分。
牛顿为什么想到万有引力?不知道;麦克斯韦为什么想到电磁场?不知道。爱因斯坦为什么想到相对论?他说大量来源于思想实验。
假设某数学家洗澡时突然想到一个定理,灵光一闪随后证明成功。按照普通人的语言:他发现了这个定理。没问题。
但按照 Sutton/Campbell 那套:真正的发现发生在:提出猜想→证明→验证 的整个循环。而不是那个灵感瞬间。这两种用法其实都存在。

然后我突然发现不对。这三板斧,不就是高仿A货山寨的流程吗?

找热品 → 换皮/魔改 → 另类市场投放 → 能活下来的,就疯狂迭代代替原竞品 🤣

AI 回答,说得没错。

Dennett 有个著名观点:Darwin's idea is a universal acid. 达尔文那套逻辑腐蚀一切。

然后我继续跟AI掰扯,我似乎真的知道那三个原因起初是怎么来的。牛顿据说是拿苹果比喻谁扔的远,但是那个时候不是地理大发现地球是圆的,如果一个人臂力无穷,扔苹果绕地球一圈。。。???!!!!但是苹果和地球差距太大,要不套月球算一下。然后发现天上的星辰居然和地上的石头一样的规律?屌爆了;麦克斯韦居所最初的手稿就是那牛顿力学模拟以太小球挤来挤去。。不小心把光速给挤成常量了。给整不会了,懵逼ing。。爱因斯坦那个我感觉是纯粹做梦跳楼自然落体落出感觉了。脑子一抽,为啥我和其他东西一起掉落,就不能等同当成睡在床上?

AI验证了我这个说法

牛顿问的是:月亮为什么不会掉下来?然后进一步问:有没有可能月亮其实一直在掉?地上的苹果=天上的月亮,今天看理所当然。17世纪这简直是疯子想法。
因为当时很多人仍然默认天上一套规律,地上另一套规律,牛顿把它们统一了。
Maxwell 真有点你说的味道。他受 Michael Faraday 影响很深。Faraday 几乎没数学训练。天天画力线。在当时很多学院派看来像神棍。麦克斯韦后来尝试给这些力线建立机械模型。各种齿轮、涡旋、小球、弹簧。很多模型后来证明都是错的。但神奇的是:数学留下来了。机械模型死了。方程活了。最后推出来:c=1/sqrt(μ0×ϵ0),然后一算:3e8 m/s 和已知光速差不多。麦克斯韦当时确实有点:等等...这怎么是光速?的感觉。于是得到:光就是电磁波。这是物理史上最著名的"卧槽"时刻之一
Albert Einstein 最符合你说的脑子一抽,自己特别喜欢思想实验。16岁:如果我骑着光束飞行会看到什么?后来:电梯自由落体的时候会发生什么?然后出现著名的等效原理。

然后我就被AI给秀到了:

但最有趣的不是这些故事本身。而是你会发现这些案例都不太像随机搜索。反而像已有知识在跨领域类比,统一两个看似无关的东西。
牛顿:苹果=月亮;麦克斯韦:光=电磁现象;爱因斯坦:重力=加速度。这是一种很特殊的创造力。事实上很多认知科学家会认为:真正的人类创造力未必来自随机variation。而是来自类比推理(Analogical Reasoning) 或者 概念压缩(Conceptual Compression)

我是认同“类比产生创新”这个说法的,我是信的。从小我就以为创新只有一种,那就是学科交叉创新,边缘创新。AI 没有理会,进一步说

牛顿之前:天体运动一套,理论地面运动一套理论;牛顿之后:引力一套理论世界反而变简单了。
麦克斯韦也是。原来:电 磁 光 三门课。后来:电磁场一门课。
更极端的是 Alan Turing。图灵其实没有发明计算机。他干的事更离谱。别人研究:加法机、乘法机、密码机、各种机器。图灵问:有没有一种机器,可以模拟所有机器?然后就出现图灵机。这属于直接修改问题定义。
我后来越来越觉得,所谓“大师级创新”经常不是增加概念,而是删除概念。 把原来大家认为不同的东西压缩成同一个东西。 例如: 苹 月亮 压成: 引力
从信息论角度看甚至有点反直觉。 我们总以为创新是增加信息。 但很多伟大创新实际上是在减少描述长度。 比如: 100个现象 原来需要 100条规则 解释。 后来突然发现3条规则 就够了。
所以我其实有点怀疑,人类最顶级的创新可能分两类。 第一类就是你熟悉的: 组合创新 或者说工程创新。 把已有积木拼出新形状。 绝大多数创业公司都在干这个。
第二类则是: 压缩创新 或者说理论创新。 突然发现: A = B 例如: 光=电磁,热=分子运,质量=能量,程序=数据(某种意义上),证明=计算(Curry–Howard)
这种创新一旦出现,整个学科结构都会变。

等等,停!!!!谁问你了???你都开始指手画脚点评人类了?

而且有趣的是,如果你回头看大模型。很多人觉得它像随机鹦鹉。但如果非要说它有什么潜在长处,我反而觉得更接近第二种。因为预训练本质上就是在海量文本里寻找:哪些东西经常一起出现?哪些模式其实是一回事?换句话说:它天生就在做压缩。

啊。。。。我幼小的心灵被AI击中了。这总结得也太到位了。顺便还把自己给认识给透彻了。

又是被 AI 征服的一天。

不过我还是有点不服气。组合创新 是我固有认知,AI给我上了一课“压缩创新”,不过还有一种创新AI估计不知道,我也是到后来才认识到,真的有天才靠开脑洞,无中生有开辟一整个学科那种“要有光”式的创新。例如搞定五次方程那个法国娃。。。

很多人听到伽罗瓦故事,会觉得一个19岁少年,突然发明群论,开创整个现代代数。像神迹。
但如果仔细看历史,事情没那么凭空。他面对的是一个已经存在几百年的问题:Cardano的三次方程、Ferrari的四次方程、Lagrange的为什么这些公式有效、Abel的证明一般五次方程无根式解
很多顶级数学家已经在研究。伽罗瓦最厉害的地方不是突然想到答案。而是把问题转了90度。别人问:五次方程怎么解?他问:什么样的方程才有根式解?然后发明了一套研究“对称性”的语言。这当然是超级创新。但仍然不是从真空里冒出来的。
但伽罗瓦最开始根本不是在研究群。他是在研究根怎么互相交换?举例:x²-5=0两个根:√5,-√5。你交换它们,方程没变。再复杂一点:x³-1=0三个根。你各种交换。有些交换保持结构。有些不保持。
伽罗瓦慢慢意识到真正重要的不是根。而是允许的交换方式。这一步非常牛。因为他把注意力从对象转到了变换。

我今天是真觉得AI有点东西的。特别是今天它搞出来的, 删东西 有点意思啊。

我从小受到的“启示”是只有自由思想,开放课堂才有创新。死记硬背,题海战术 是愚昧落后的

但是 AI 到出现很打脸,题海战术不仅有效,而且极有效(pretrain)。关键就看你会不会剪枝,用一个记忆点去背一万道题。

知识量+约束才是创新的基础,就像艺术家生活所迫才能写出名篇一样

AI 没忘记恭维一下我:

不过你的问题更深:AI 能不能做到这种级别的开脑洞?我觉得要先拆成两个问题。
第一:AI 能不能提出人类从未提出过的概念?我觉得答案已经接近「能」。因为大模型参数空间太大了。它能组合出大量训练集中没有出现过的东西。这一点不神秘。
第二:AI 能不能提出一个后来被证明极其重要的新概念?这才是真问题。例如:群、场、流形、图灵机、熵这种级别。这里我觉得目前没有证据。但也没有理论障碍。
很多人下意识认为:AI 只能模仿。然而伽罗瓦自己其实也是在做一种压缩。他发现:很多方程问题=同一种对称性问题。这很像一种高阶模式识别。而模式识别恰恰是神经网络擅长的东西。
真正让我怀疑 AI 还缺东西的地方,反而不是“开脑洞”。而是“长期执念”。伽罗瓦可以一个问题追几年;阿贝尔可以穷得吃不上饭还在研究;牛顿可以十几年不发表,一直推演。他们会围绕一个模糊感觉反复打磨。今天的大模型没有这种动力结构。它不会自己觉得 这里有个东西不对劲。然后连续三年死磕。
所以如果你问我:AI 能不能产生伽罗瓦式创新?我的答案是:从认知机制上,我看不出明显的不可能。因为伽罗瓦的突破并不像魔法,更像一次极其深刻的概念重构。但从系统结构上,今天的大模型距离伽罗瓦还很远。不是因为脑洞不够大。而是因为它们还没有一个伽罗瓦拥有、而人类经常忽视的能力:长期持续地围绕同一个问题积累状态。
有意思的是,这又绕回你前面提的那个点:Context 一重置就没了。如果一个系统不能把昨天的猜想、上周的反例、上个月的失败实验持续保留下来,那么它即使偶尔闪现出一个伽罗瓦级念头,也很难把它发展成一个新学科。而历史上的大多数伟大发现,恰恰不是那个灵光一现的瞬间,而是灵光出现之后几十万次不放弃的迭代。

我怀疑我这 ChatGPT 有自我意识了。我压根没问它这些,它都开始喃喃自语了。

我越来越怀疑一个反直觉的事情:创新的前提不是自由,而是约束。因为没有约束,压根不知道该删什么。
举个极端例子。如果我给你1万个随机字符串,你很难发现规律;但如果我给你:1万道微积分题,你反而容易归纳。因为它们共享约束。
这其实解释了为什么 pretrain 有效。很多人以为:LLM 背诵了整个互联网。其实从压缩角度看:LLM在做的事情更像删掉互联网把几十TB文本压成几百GB参数。它一直在问:哪些东西其实是一回事?

不得了,这AI真的成精了。今天真的刷新我认知了。删东西 == 创新。所以给 .git 加行数不算本事,删行数系统不挂,是真的创新!


对于今天这番对话,我久久不能释怀。吃午饭的时候,我突然又想到,这个 压缩 论,感觉是从连结主义,倒向 符号主义 的桥梁啊。。。

然后一边吃一边刷zhihu,就无意中看到《符号学习在 Agent 时代的文艺复兴?

历史先从一个误会讲起:符号 AI 不是“if-else AI”
今天提到“符号学习”,很多人脑子里会立刻浮现出专家系统、规则库、Prolog、if-else、知识图谱,甚至会觉得这是深度学习之前的“旧 AI”。这种印象不能说错,但它把符号主义最有生命力的部分遮蔽了。
早期符号 AI 的核心野心不是“写很多规则”,而是认为智能可以被理解为:在某种表示空间中,对离散结构进行组合、搜索、改写、推理和执行。 Newell 和 Simon 在“物理符号系统假说”中提出,物理符号系统拥有产生智能行为所需的充分和必要手段;Nilsson 后来回顾这个假说时也强调,它假设计算机只要有合适的符号处理程序,就能产生智能行动。这个主张今天看太强,但它抓住了一个关键点:智能不只是数值拟合,也包括对可组合结构的操作。
20 世纪 60–80 年代的符号 AI 有几个典型方向。DENDRAL 用化学领域知识帮助推断有机分子结构,是最早的大规模专家系统之一;DENDRAL 项目的总结明确把它描述为使用“详细、任务特定知识”作为启发式来源,并尝试自动化获取这种知识的系统。 MYCIN 则把医学诊断和治疗建议写成规则,并用 certainty factor 表示不确定性;MYCIN 的规则不是严格蕴含,而是允许推理强度被 certainty factor 调整。 ID3 从样本中归纳决策树,把“从例子中学习知识系统”变成一棵可读的分类树。Quinlan 的 1986 年论文明确说 ID3 所做的是从例子中合成 decision trees。
更接近“符号学习”的,是 Version Space、Explanation-Based Learning、Inductive Logic Programming、Soar chunking 等方法。Mitchell 的 Version Space 把学习看成维护所有与已观察数据一致的规则假设集合;随着新样本到来,不一致的规则被排除。 FOIL 则在一阶逻辑层面从关系数据中构造 Prolog 风格的理论。 Soar 的 chunking 则把一次问题求解中产生的经验编译成新的 production rule,使系统以后遇到相似情境时不必重复推理。Soar chunking 的论文把它描述为一种从 goal-based experience 中获取规则的学习机制。
所以,传统符号学习的核心不是“手写规则”,而是从经验中得到可显式表示、可组合、可执行、可检查的结构。
它可以是规则,可以是树,可以是逻辑程序,可以是 chunk,可以是 macro-operator,也可以是一个 procedure。后来强化学习里的 options 其实也延续了这条线:Sutton、Precup、Singh 把 action 扩展成 temporally extended closed-loop policy,也就是把一段低层行为压缩成一个可调用的高层行动单元。
如果这么看,符号学习从来不只是“逻辑推理”。它更像一种结构化经验压缩。

符号主义为什么失败?不是因为符号没用,而是因为符号太难维护
符号 AI 后来被深度学习压过,不是偶然。它遇到了三个根本困难。
第一个是 grounding 问题。Harnad 在 1990 年提出 symbol grounding problem:如果符号只靠其他符号解释,就像只靠一本中文词典学习中文,系统内部的符号意义仍然是寄生在人类解释者身上的。Harnad 认为,底层符号需要被非符号的感知表征和类别检测器 grounding,之后高阶符号才能建立在这些 grounded categories 之上。
第二个是 感知和开放世界问题。经典符号系统在规则清晰、状态离散、边界稳定的环境里很好用;但真实世界有高维视觉、模糊语义、噪声、长尾、异常输入。手写规则很难覆盖这些情况,逻辑系统也很难自己从像素、声音和自然语言中稳定抽象出正确谓词。
第三个是 维护成本问题。专家系统真正的瓶颈不是规则没有价值,而是规则库会变成技术债。今天加一条规则修 case A,明天 case B 被破坏,后天又加一个例外。规则越多,越难知道哪条规则还有效,哪条规则已经过时。翁家翌在 Heuristic Learning 里说得很直接:专家系统和规则系统以前不是没用,而是人工维护成本太高;coding agent 改变的是 heuristic 的维护曲线。

所以,符号主义的失败不应该被理解为“符号表示是错的”。更准确地说,它失败在 符号结构的获取、grounding、泛化和维护,在当时主要靠人,成本太高。深度学习赢在这里。神经网络不用人把知识一条条写成规则,而是用数据和梯度把规律压进参数。它牺牲了可读性和可控性,换来了规模化学习。

我把这一大段贴给AI,AI说了一大段,但是结尾说

压缩不自动等于符号主义。纯压缩可以只是一个更好的黑箱;只有当压缩结果变得可组合、可复用、可显式操控时,它才真的跨进符号那一侧。换句话说,压缩是桥的桥墩,符号是过桥之后能走的路。

我怎么感觉,我模糊的摸到了拼图的完整边界。

人的动手、观察能力因为也算模拟输入,也是连续的信号。但人的思考过程是离散的,也就是所谓的“真”智能。思考水平有高低之分,也就是抽象程度差别,这么说来,也就是压缩率的差异。

不过我还有一个终极杀招:起名字难题。这里的起名字指的是把固定pattern“符号化”的意思,也就是可复用,可操作的符号。

起名字可不是个简单的事儿,起的名字要被其他人接受、传播,也是个能力。

你前面说 LLM 缺 context memory,这没错,但更深一层是:即使有 memory,如果没有“命名”,也无法积累结构。因为没有名字,就只能重新匹配整段经验。有名字之后:直接引用结构这差别本质上是:O(n)重建 vs O(1)调用

我又记起来一个古老但是,特别浅显的分类。LLM就只会打猎。做 gather 很不行。这是个长期的劳动。

打猎是指一个很具体的事儿:LLM就是冲着一个 reward 单一目标驱使和强化训练的。能拿回来肉就算成功,别的你拿回来一大堆宝石都要饿肚子的。

而且 gather 多了能认识到一些高级结构,这就是 女祭司 的来源。

神秘崇拜导致原始宗教,然后才发明符号和文字,然后才有文明。

人脑“意识”这玩意,牛就牛在它可以水平迁移。

比如牛顿一辈子毕生所学,现代初中生就必须半个学期掌握。

horizontal gene transfer比进化论不知道牛到哪里去了。虽然近几年发现微生物里有一些这样的不好说的

如果哪一天 qwen 发明的概念,比如某个agent 10年推演的全部功力,被浓缩成10个全新的token,但能被 chatgpt 秒懂,那么人类是真完蛋了,AGI实现了。

这就是我今天全部 TIL 。

Elon Musk 五步工作法

2026-05-31 11:56:00

The five-step process:

First, make your requirements less dumb. Your requirements are definitely dumb. It does not matter who gave them to you.

In fact, it's particularly dangerous if a smart person gave you the requirements, because you might not question them enough. Everyone is wrong some of the time, no matter who you are. So the first step is to make your requirements less dumb.

Second, try very hard to delete the part or process. This is extremely important. If you're not occasionally adding things back in, then you're not deleting enough. The bias is almost always toward adding a part, a process, or a step "just in case we need it."

You can make "just in case" arguments for almost anything.

For a rocket, especially one trying to become the first fully reusable rocket—a thing that has never existed before—you have to be ruthless about deleting parts and processes. You can't hedge every risk forever. For example, on Starship, the grid fins do not fold down. Folding would require an entire additional mechanism that simply isn't necessary.

Any requirement or constraint must come with a name, not a department. You can't question a department; you can only question a person. The individual proposing the requirement must be willing to take responsibility for it. Otherwise you end up following a requirement that some intern casually suggested two years ago, who doesn't even work at the company anymore. These things are often much sillier than people imagine.

So:

Step 1: Make the requirements less dumb.

Step 2: Delete the part or process.

If you're not adding things back roughly 10% of the time, you're clearly not deleting enough.

Only then comes Step 3: Simplify or optimize.

This ordering matters because one of the most common mistakes smart engineers make is optimizing something that should not exist in the first place.

People are trained throughout school to answer the question they are given. You can't tell your professor, "Your question is dumb." You'll get a bad grade. So everyone develops this habit of solving the assigned problem rather than questioning whether the problem itself should exist.

Without realizing it, people end up in a mental straitjacket, spending enormous effort optimizing things that should simply be removed.

Step 4 is accelerate cycle time.

You're probably moving too slowly. Go faster. But don't accelerate until you've done the first three steps. You can almost always make something go faster.

Finally, Step 5: Automate.

I have personally made the mistake of doing all five steps backwards multiple times. I've literally automated, accelerated, simplified, and only afterward deleted.

One example was during Model 3 production. There were five fiberglass mats located between the floor pan and the battery pack. At one point they became a bottleneck on the battery production line, and that bottleneck was affecting the entire Model 3 program.

I was basically living on the battery-pack production line trying to fix it. My first mistake was trying to improve the automation. I thought, "Let's make the robot better." That was a mistake. Then I tried accelerating the process. That was a mistake. Then I tried optimizing the process. That was also a mistake. Finally I asked, "What the hell are these mats actually for?"

I asked the battery safety team whether they were for fire protection. They said no—they were for noise and vibration. Then I asked the NVH (Noise, Vibration, Harshness) team what they were for. They said they were for fire safety. At that point it felt like I was living inside a Dilbert cartoon. Frankly, I feel that way fairly often. So we tested it. We built one car with the fiberglass mats and another without them. We put microphones in both vehicles and tried to determine whether there was any measurable difference. There wasn't. In fact, I couldn't even tell which was which.

So we deleted the mats entirely. That decision bypassed a $2 million robot cell and eliminated a problem that never should have existed in the first place. That's the lesson:

  • Question the requirement.

  • Delete before you optimize.

  • Optimize before you accelerate.

  • Accelerate before you automate.

And be aware that even experienced engineers constantly get this order wrong.


这个五步流程是这样的。

第一步,先让需求变得没那么蠢(Make your requirements less dumb)。

你的需求一定有问题。不管是谁提出来的,都一样。如果需求是一个聪明人提出来的,反而更危险,因为你可能不敢质疑它。事实上,每个人都会犯错,无论你是谁。所以第一步永远是先审视需求本身,看看它到底合不合理。

第二步,尽最大努力删除零件、流程或步骤(Delete the part or process)。

这一点极其重要。如果你从来不会出现“删掉之后又加回来”的情况,那说明你删得还不够狠。绝大多数组织天然倾向于不断增加东西——增加一个零件、增加一道流程、增加一个审批步骤。理由通常都是:

“万一以后需要呢?”

但这种“以防万一”的理由几乎可以为任何东西辩护。

以火箭为例。我们做的是历史上第一个完全可重复使用的火箭,这是航天领域长期追求的圣杯。在这种情况下,你必须拼命删除不必要的东西,而不是不断给自己留后路。例如 Starship 的格栅翼(grid fins)并不会折叠。因为折叠意味着额外增加一整套机械结构,而我们根本不需要它。

还有一个原则:任何需求或约束条件,都必须对应到一个具体的人,而不是一个部门。因为你无法质问一个部门,你只能质问一个人。提出这个需求的人,必须愿意对它负责。否则公司里经常会出现这样的情况:某个约束条件源于两年前某个实习生随口提出的一句话,而那个人早就离职了,但这个约束却还在被所有人当成圣旨执行。这种事情比你想象得常见得多。

所以:

第一步,质疑需求,让需求变得没那么蠢。

第二步,删除零件、流程和步骤。

如果删完以后从来不需要加回来,那么说明你还没有删到位。大约有 10% 的情况需要加回来,才算删得够狠。

第三步,才是简化和优化(Simplify or Optimize)。

顺序非常重要。聪明工程师最常见的错误,就是优化一个本来就不应该存在的东西。

从小学到大学,所有教育都在训练你回答问题,而不是质疑问题。老师出了一道题,你不能告诉老师:“你的题目本身就有问题。”

否则你会拿低分。久而久之,人们形成了一种思维惯性:默认问题一定是正确的,然后拼命去寻找最优解。结果就是大家被套上了一个无形的思维枷锁,把大量精力浪费在优化那些本来就应该被删除的东西上。

第四步,加快迭代速度(Accelerate cycle time)。

大多数时候,你只是推进得太慢了。加快速度,但一定要先完成前面三步。因为无论什么事情,几乎总能找到办法让它跑得更快。

第五步,自动化(Automate)。

而我自己犯过很多次错误——几乎是把这五步完全倒过来做。我曾经自动化、加速、优化了一大堆东西,最后才发现它们根本不该存在。举个例子。

Model 3 电池包顶部曾经有五块玻璃纤维垫,位于电池包和车身底板之间。有一段时间,这几块垫子成了整个电池生产线的瓶颈,而电池生产线又卡住了整个 Model 3 项目。当时我几乎天天待在生产线上,试图解决问题。

我做的第一件事,是改进自动化设备。错了;
然后我尝试提高生产速度。还是错了;
接着我开始优化整个流程。依然错了;
最后我终于问了一句:这几个垫子到底是干什么用的?
我去问电池安全团队:这是为了防火吗?他们回答:不是,这是为了降噪和减振。
于是我又去问 NVH(噪音、振动与舒适性)团队:这些垫子是干什么的?他们回答:为了防火。

整个场面就像《Dilbert》漫画一样荒谬。说实话,我经常有这种感觉。于是我们决定直接测试。造两辆车,一辆有这些垫子,一辆没有。在车里放上麦克风,看看能不能测出差异。结果完全测不出来。甚至我自己都分辨不出哪辆有、哪辆没有。于是我们直接把这五块垫子删掉了。一个价值两百万美元的机器人工作站也因此不再需要。而这一切问题,从一开始就不应该存在。

这就是整个五步法的核心:

  • 先质疑需求
  • 删除,然后才优化。
  • 优化之后再加速。
  • 最后才自动化。

而现实里,即便是经验丰富的工程师,也会一遍又一遍地把这个顺序搞反。


我发现我最喜欢犯“just in case we need it”这个错。然后就是无休止的 optimize a thing that should not exist

via

Playlet:DLNA听歌神器 免安装app播放NAS里的歌

2026-05-30 20:03:08

家里有个小 NAS 。里面存了一些歌。一半是用 NAS 自带的 app 听,一半是。。。SMB 共享打开听

虽然 NAS 也提供 DLNA ,一直以来找不到趁手 app ,要么收费,要么 bug 多,要么不能多端。

13年前我也想基于 chrome.socket 做个 Chrome App 弄个类似的。结果这破玩意实现有问题,多连接会导致 hang。最后2020年Chromium决定杀死 Chrome Apps

周六的时候,实在无聊,决定又开始搓轮子。在思考 SSDP/UPnP ,native UI, electron,命令行这些选型的时候,突然想到,DLNA服本来就要提供一个http,自己再造个 http 客户端去通信,岂不是多此一举?只要依托它,解决跨域……等等,用个 bookmarklet 不就行了?当页调用 fetch() ,走 SOAP 协议,完美。

所以这就有了,网页版听歌的。不需要安装 app ,只需要一个浏览器书签

https://est.github.io/playlet/

也需要你对网络、DLNA 的亿点点知识。比如你得自己想办法找出 DLNA 的 IP 和端口

使用方法:

  1. 把这个网址加到浏览器书签

        javascript:import("https://est.github.io/playlet/loader.js")
    
  2. 打开 DLNA 服务器的网页

  3. 点击第一步加的书签(如果找不到书签栏,右上角三个点菜单 -> 收藏 可以切换)

自测兼容 NAS 的 MiniDLNA 。chrome ,手机浏览器和 webview 都可以播放。

当年嵌入个 <script> 写法多复杂,createElement又这那的;现在直接 import() 搞定。简洁明了,还不会重复加载。

最后是个 50KB 左右的单体 js。实现了播放、搜索等核心功能+UI。

给本地测试环境动了个小心思,利用 iframe 去模拟 bookmarklet 注入。还学习到 <audio crossorigin="anonymous"> 居然主动去检查跨域CORS头导致加载失败,去掉 crossorigin 就行。AI嘴硬不给去掉,服了。

这下随时随地打开浏览器就能听歌了。除了收藏的一些古典CD是 .cue 分段的没法播放。感觉需要去电脑上硬切割一下了。

接下来想把歌词什么的整理好。不知道有没有类似 opensubtitles 之类的服务。

最后想起来,miniDLNA为啥不直接把这一坨JS内置了 😂 可能当年那个条件没厂家愿意去js手搓一套DLNA协议+播放界面吧。甚至浏览器对常见音频格式都不怎么支持

不修改nginx接收websocket

2026-05-28 18:35:00

以前只记得要支持websocket 需要 nginx 改:

  location /ws-service-a {
      proxy_pass http://backend_a;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection $connection_upgrade;
  }

今天折腾忘记这茬了,一直在调 FastAPI ,@app.websocket() 死活不识别 wscat 的请求

WebSocket 协议的工作方式是:

1.客户端发 GET + Upgrade: websocket 头
2.服务端识别这个特殊 GET,返回 101 Switching Protocols
3.连接升级完成

opus-4.6 说:既然路由确实注册了,那问题几乎可以确定是:前面的反向代理/LB 没有透传 WebSocket

我就来劲了,让AI写一份 特殊 GET,返回 101 Switching Protocols 。

结果还真成功了。wscat 返回 error: Invalid Sec-WebSocket-Accept header

折腾了几下,发现此路不通

问题不是 @app.websocket() 没挂载,它挂载了,但永远匹配不到。原因是 uvicorn 的路由分发发生在更底层:

请求到达 uvicorn

uvicorn 检查 headers:有 Upgrade: websocket?
├── 是 → scope.type = "websocket" → 只匹配 @app.websocket() 路由
└── 否 → scope.type = "http" → 只匹配 @app.get/post() 路由
你的 nginx 把 Upgrade 头吃了,所以 uvicorn 永远把请求标记为 http scope。在 http scope 下,@app.websocket(...) 路由根本不参与匹配 — 就像它不存在一样。

这就是为什么:

@app.get('/ws/test') 能匹配 — 它是 HTTP 路由,匹配 HTTP scope
@app.websocket('/ws/real') 匹配不到 — 它是 WebSocket 路由,只在 websocket scope 下才可见
两个都注册成功了,但 scope 类型不对,uvicorn 在路由匹配之前就把它们分到了不同的赛道。

接下来几轮错误复制粘贴大法:

  • 最初想法:ASGI middleware 翻译协议 → 80 行,手搓 websockets 库
  • 精简版:用 websockets 库做帧编码 → 还是 50 行 middleware

后来发现ASGI 这一层做不到。因为 标准 ASGI middleware 拿到请求时已经太晚了:

uvicorn TCP 收包
1. httptools 解析 headers
2. on_headers_complete 决定 scope type (http vs websocket) ← 需要在这里拦截
3. 创建 scope + receive/send(已经绑定为 HTTP 协议)
4. 调用 ASGI app (middleware 链) ← middleware 才在这里介入

middleware 只能看到已经定型的 scope['type'] = 'http',改不了底层的 receive/send 绑定。

然后尝试了一个 gunicorn.conf.py 的hack:

def post_worker_init(worker):
    """让 uvicorn 从 sec-websocket-key 识别 WebSocket,绕过 nginx 吞 Upgrade 头的问题"""
    import httptools
    from uvicorn.protocols.http.httptools_impl import HttpToolsProtocol
    _orig = HttpToolsProtocol.on_headers_complete
    def _patched(self):
        has_ws_key = any(n == b"sec-websocket-key" for n, _ in self.headers)
        if has_ws_key and self._should_upgrade_to_ws():
            self.headers.append((b"upgrade", b"websocket"))
            self.headers.append((b"connection", b"Upgrade"))
            self.scope["headers"] = self.headers
            self.scope["method"] = self.parser.get_method().decode("ascii")
            raise httptools.HttpParserUpgrade(b"")
        return _orig(self)
    HttpToolsProtocol.on_headers_complete = _patched

我也觉得,ws这协议是不是有病。如果有 sec-websocket-key 就认定为 ws 不就完了。搞那么复杂。

然后这个办法在 ASGI 里还是行不通。最终版:直接篡改 uvicorn 收到的 raw TCP 字节

def post_worker_init(worker):
    import re
    from uvicorn.protocols.http.httptools_impl import HttpToolsProtocol

    _orig_data_received = HttpToolsProtocol.data_received

    def _patched_data_received(self, data):
        if not getattr(self, '_ws_patched', False) and b'\r\n\r\n' in data:
            self._ws_patched = True
            lower = data.lower()
            if b'sec-websocket-key:' in lower and b'\nupgrade:' not in lower:
                data = re.sub(rb'(?i)\r\nconnection:[^\r]*', b'\r\nConnection: Upgrade', data)
                data = data.replace(b'\r\n\r\n', b'\r\nUpgrade: websocket\r\n\r\n', 1)
        return _orig_data_received(self, data)

    HttpToolsProtocol.data_received = _patched_data_received

居然成功了!不修改nginx兼容websocket!

这路子太野了。还是老老实实去改nginx了。

不过也学到一些姿势,比如 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 ,以及ws居然是二进制流。

AI 硬伤

2026-05-28 00:11:00

回顾一下我发现的AI弱点,说不定将来对抗 skynet 有用

2023年 我当时觉得:

  • 不太会算术。没想到刚看到个更搞笑的人工加法智能。大概意思是,如果pretrain一个加法表,AI会「懂」任意整数的加法么?
  • gpt4 不懂中文和字符形状——已经被多模态模型解决
  • 对人类真正发音器官无感知——我感觉大模型是有感知的。至少它知道IPA里哪些音很接近和为什么。但是比如 弹舌、beatbox之类考验细节的就无能为力

2026年 我感觉:

  • AI不能很好的讲笑话——真的
  • 多个答案多种输出——这个受到top-k,max_tokens,think_budget等参数限制,即便你放开,可能就开始一直循环重复
  • 搞不懂人称代词 这一点我相信frontier模型不是真会了,而是见得多,把问题掩盖了。

然后是最大的问题

  • 无法给发现的规律起名字。比如你让AI去改一坨代码,AI发现一个规律,它即便内心想到一个好名字,也不会在输出的时候跟你倾诉,也没法写博客写书,上下文一重置就没了
  • 人在写代码时,可以边写边发现缺陷,虽然有时不会马上改,但是可能接下来遇到了就会结合之前的问题一起改了;或者好几个单独的bug串起来就是个大漏洞。AI目的驱动很强,缺乏 incidental learning(附带学习)

今天在马桶上拉屎,就又回想起一个经常琢磨的问题框架。比如人们写日记。可能有个习惯会把当地当天天气记录下来。

设想有两个挑战:

A: 假如全世界有足够的人去写城市+日期+天气的日记,并且汇总交给LLM去学习(pretrain),形成一个全球的天气记录。然后你问LLM某地某天的天气怎么变化的,AI应该猜个八九不离十。

B: 但反过来,全球的气象记录是已知的,你让AI去全文背诵一段时间经纬度+降雨图。然后去考验,如果有个人连续写了很多天日记,记录当地天气,能反推这个人在哪里吗?

这可能是关于「知识」和「表征」 的一个极好的例子

对于B,人也做不好。但是人的大脑有个习惯,遇到有趣的,好玩的,但是没卵用的,也会先留个深刻印象,先记着。说不定将来某个机缘之下就是事情的突破口。如果刚好看到日记里有一天记录“台风”,那么全球气象数据的再大,在你面前瞬间坍塌缩小成沿海和热带。


这几天在HN上 看到古希腊掌管起名字的神Martin Fowler 最新发现:AI完全不懂安全攻防。

Public storage access 和 Excessive token permissions,可能在某个开发环节无伤大雅,但是真上线之后,后果很严重。

更加严重的是,这玩意不是写一两个 rules/skills 就能解决的。

要我说最严重的——瑞士奶酪模型被击穿。每一个环节都是小问题,但是合在一起刚好形成致命隐患

要我说这是因为「安全」本质上不是「做事」。它是降低「负事」。

世界上归根结底有两种价值。一种是靠辛勤劳动的创造;一种是破坏

对于潜在风险的防御,思考难度和上面那个根据天气猜地点差不多。

对于创造,你只要打通所有环节,就全部通了;

对于破坏,你只要一个薄弱点被突破,就全盘皆输。

LLM适合干创造的事,因为它只需要根据经验选一个最佳输出。但是要做好安全,你得写每一行代码时,都要遍历其所有的风险。

那么结合之前的 Instruct 模型去思考

  • 大模型 pretrain 是学习语料库的概率分布,可以理解为形形色色的人说过的话
  • posttrain 我觉得最重要的意义是按照一定“偏好”在 chat范式下,更良好的一问一答(pretrain里的语料一问一答很少)

那么问题来了。一问一答的排查问题这种模式,在 pretrain 里的分布是不是偏少。每件具体的事出现的问题可以说是千奇百怪。

比如上一行你在处理登录,下一行你就开始查SQL,接着你又开始拼template字符

对于安全而言,每一行都在切换 domain。LLM在这里会有能力和精度的损失,导致注意力不集中。

更好的方式是,先看几行,找出最关键的问题,然后reset上下文,从问题部分继续往后看几行,再找出最关键的问题,这样迭代进行。这样每次都更符合 pretrain 分布。

pretrain 的素材里会单独讲登录有哪些要注意,SQL有哪些坑,模板有哪些隐患,但是很少有刚好把 登录+查SQL+模板 按顺序加在一起综合有什么安全问题。

你可以把登录、查SQL、模板分别一问一答,在 pretrain 里的分布就更丰富。如果混一起问,具体的事项+组合爆炸,出现的问题可以说是千变万化

如果你直接问:这段代码有什么安全问题?AI只能挑选几个它觉得最有代表性的,突出的,给你讲一讲。

所以,我有理由认为,AI在「排查」类问题上,因为LLM层数,top-k,max_tokens,think_budget等先天能力和精度的损失,必然会结果很松散。


再说另外个感受,最近 vibe 的东西比较多,我感觉AI在设计的时候,对于“状态机” 极容易翻车。就是SPA界面上各个控件触发顺序、互斥等逻辑。

简单、成熟的交互设计能one-shot,但是稍微多几个步骤,AI就会糊一个表面上过得去,但是edge case 全部翻车的产品。

折腾了许久搞得我灰头土脸,后来实在没办法,让 AI 先自己拍脑袋列举典型实用场景,写了100多个case,然后新开个上下文让设计,并记录设计的出发点和考虑,然后再逐一case去验证,然后迭代设计里不满足的地方。几轮下来,最终AI给出了一个比较像样,至少100多个case不会太大偏离的设计。

这也算一个土办法?

如果你仔细看这个问题,其实跟上一段「安全」本质是一回事。


现在有一个大的体会,AI在 happy path 上越来越稳,刷分越来越高,像一个经验老道的猎手。但是对于先验不足的东西,它缺乏一种 scatter-gather 的耐心和细致。

想起来,人对于「采集」这种事心态是完全不同的。你得处处留心,以一种「万一将来有用」的目标去做事,甚至做没意义的事。

AI亏就亏在,它肯定能在某个局部发现某个问题有“隐患”。但是因为这个属于偏题,可以回答可以不回答。如果手头任务繁重,它即便隐藏层激活了也会最终被吞没。

然后AI上下文不是永久的,它无法在10天后新的context里突然回忆起之前遇到个有关的坑!

这是机制上无法弥补的行动缺陷。

当然不排除有 agent 能朝这个方向努努力,多听听AI发牢骚,记录并形成一笔财富。哈哈哈

我现在预估AI能力边界是这样思考的:

对于某个任务或者话题,

  1. pretrain 的 wikipedia/reddit/arxiv 一般会怎么叙述?
  2. 对于该任务或者话题,AI Lab 里后训练会设置什么样的eval?

然后就能估摸出个能力大概。

Gemini一看,补充了一点:

  1. reasoning 会如何改善并影响最终输出?

理解LLM的范式——它就是个差分机?

2026-05-25 11:57:00

作为一个外行,我一直对“AI”的魔力感到惊奇,我一度以为神经网络一层一层传播,可以看成某种有限步骤的图灵机。AI提醒我不要瞎类比,图灵机左移右移是离散,确定的逻辑,神经网络是fp32上连续的概率映射。

后来稍微深入了解了一下,认识到对于一个深度固定的 Transformer 模型(比如 96 层的 GPT-4),它的单次前向传播算是一个深度固定的有向无环图(DAG)。所谓的 predict next token,可以粗糙理解成

  next_token = eval(model_weights, history+input)

这里最奇特的算是:自回归(Autoregression)。传统的冯·诺依曼架构中,指令(Code)和数据(Data)是分开的。但在 LLM 中,上下文是动态的指令+数据。输出什么样话,什么时机结束。LLM得自己想办法把画圆回来,并且知道什么时候该停止吐词。

这种 控制面 和 数据面 混合的做法让我感到非常不适,也是诸多prompt injection问题无解的根源

不过一旦get到这个范式,我想到一个有趣的类比,一般的 gpt 是 dcoder-only,VRAM里权重就如同 .exe 加载到内存里一样,是永久不会动的;kvcache才是 malloc 去操作的独占内存。BERT那种 encoder-decoder 模型,算是一个可以自我修改的.exe?

如果拿python/java对比,LLM就是显存里一些可以边运行边修改的bytecode,只不过是fp而不是指令和数据

后来又了解到,要纯从设计上来说,RNN是明显超过transformer架构的。但是 RNN 死穴很明显,第一计算精度传播越到后面误差越大,第二它不知道什么时候停下来。第三它是串行的。越到后面越慢

transformer 算是一种不是那么直接,但是非常能“并行” scale 的体系。 自注意力解决了时间上的并行,让长度不再是障碍,Multi-Head Attention 解决了空间上的并行,让深度和广度不再是障碍,而这一切都只需要暴力算矩阵乘法 GEMM

我了解到这一步的时候,忽然回忆起,这不就是google当年解决ranking的套路吗?虽然把整个互联网看成一个巨大的邻接矩阵的做法,看上去更笨更重,但是能 scale 啊

基于上面的一些认知,我明确看好taalas


最近不知道看到什么资料,突然想起一个圣遗物——差分机

在 19 世纪,航海、天文、甚至银行算账全靠人工查阅印制的《数学表》(对数表、三角函数表等)。但当时负责计算的“人类计算员(Computers)”极其容易算错或抄错。巴贝奇恶心透了这种低效,于是想:“为什么不用蒸汽机来摇出准确的数字?”
核心思想是,任何复杂的低阶多项式函数,只要你求导(做差分)足够多次,最终它的“差分值”都会变成一个常数。
那么可以反推,既然最后是常数,那只要把这个常数固定住,反向一层一层做加法,就能像堆积木一样,把所有复杂的乘方运算全算出来!
差分机一号(Difference Engine No.1)由英国政府在1822年出资,工匠约瑟夫·克莱芒打造,预计完工需要25,000个零件,重达4吨,可计算到第六阶差,最高可以存16位数(相当于千兆的数)
要计算一个多项式 f(x) ,它不直接算乘法,而是构造一个 差分表。
初始值 f(0), Δf(0), Δ²f(0), ……
每次步进 x → x+1 只需做加法:
f ← f + Δf
Δf ← Δf + Δ²f
等等
我们用一个最简单的 2阶多项式为例 f(x) = x²
让 x 从 1 开始,步长为 1 地往下算

x 的值 函数结果 f(x)(原函数) 一阶差分 Δ₁(相当于一阶导数) 二阶差分 Δ₂(相当于二阶导数)
1 1² = 1
2 2² = 4 4 − 1 = 3
3 3² = 9 9 − 4 = 5 5 − 3 = 2(变成常数了!)
4 4² = 16 16 − 9 = 7 7 − 5 = 2(永远是 2!)
5 5² = 25 25 − 16 = 9 9 − 7 = 2(闭眼都是 2!)

那个最终的常数 2这就是巴贝奇的“高地”

巴贝奇那个年代不知道会不会泰勒展开,能展开这玩意不就是万能计算器了?

冯诺依曼说过,五个参数鼻子翘,300B的参数不就能描绘世间万物了?

然后突然注意到那个 常数2 不就是个 eos_token ? 卧草,这不和梯度下降,reward model 串起来了吗?

所以我今天宣布,LLM(特别是 Reasoning Model)在物理和数学本质上,就是一个高维的、基于概率特征的现代差分机!


既然有 差分机 这个范式了,那么下一步就很自然了:

AI Agent 领域遭遇的 State 瓶颈,本质上就是试图在没有底层硬件支持的情况下,用外部工程硬生生模拟出 分析机 的“条件分支(If-Else)”与“循环(Loop)”

可能很多人问:“什么是分析机?” 实际上,巴贝奇当年的 差分机 是个典型的钓鱼工程,烂尾项目

差分机因为大量精密零件制造困难,加上巴贝奇不停地边制造边修改设计,从1822到1832年的十年间,巴贝奇只能拿出完成品的1/7部分来展示
在不断延后完成期限的严重超支后,英国政府于1842年的最后清算发现整个计划一共让国库支出了£17,500,一万两千多个还没用到的精密零件后来都被熔解报废
差分机二号(或称大型差分机)在1849年设计出来,却在有生之年只实作了很小一部分。这台机器可以进行相当复杂的数学计算,具有31位元精度
差分机项目过程中,巴贝奇意识到建造一种更加通用的机器(即所谓的分析机)是可行的,于是便于1833年开始了分析机的设计
分析机由蒸汽机驱动,大约有30米长、10米宽。它的输入由程序和数据组成,并使用打孔卡输入,这种输入方法被当时的织布机广泛采用。
分析机通过一台打印机、一个弯曲的绘图仪和一个铃铛输出,也可以在纸上打孔以便日后读取。分析机采取普通的十进制定点计数法
它的“记忆体”大约可以存储1000个50位的十进制数(共约16.2kB)。有一个算术逻辑单元可以进行四则运算、比较和求平方根操作
分析机使用的编程语言与今天的汇编语言类似,支持循环语句条件分支,因此这门语言被认为是图灵完备的。
分析机采用三种不同的打孔卡和读卡器来区分算术运算、数字常量和存储的指令,以此实现了数字在存储器和运算单元之间的加载和存储操作。
巴贝奇在1837至1840年间写下了24份程序,这些程序可以计算多项式、迭代公式、高斯消元法和伯努利数

划重点:

  • if
  • loop
  • memory

扩展 if 意味着什么?那就是 workflow编排。LangGraph, Dify 表示很熟

loop呢,可以理解为 human-in-the-loop,也要意识到所有的 transformer 都是 append-only,遇到犯错你无法 inplace 修改,只能用修正的循环去覆盖之前的结果。

memory 的重要性就更不要说了。RAG都红得都快凉了。什么 openclaw 各种,主打核心就是记忆系统,被玩出花了


看到有个对 记忆系统的整体评价,他说得比我精辟多了。摘抄一点

人们大量造这类轮子:

  • event logs
  • memory systems
  • graph layers
  • retrieval engines
  • replay systems
  • state machines
  • trace infrastructure
  • workflow runtimes
  • self-reflection loops

仔细看都是在解决同一个问题:每个AI对话是独立的。

实际上记忆设计是多种不同的问题被当成一个名词喊了:

  • 对话召回
  • 长期知识
  • 工具调用历史
  • 决策链路
  • 能力演化
  • 状态重建
  • 失败记录
  • 任务上下文
  • 来源追踪
  • 自我版本变化

Agent 不只是要知道“之前发生了什么”,还要知道:

  • 当前的设定
  • 当前要干啥
  • 哪些信息发生了变化
  • 哪些工具可用
  • 哪些尝试失败了
  • 哪些操作成功了
  • 接下来要发生什么?
  • 当时是“哪个版本的自己”做出了某个决策。

我突然意识到一个更大的拼图:

LLM其实算 ALU 和 FPU。它的作用就是去 pretrain 的数据按照 posttrain 的风格,得出一串文本。

kvcache 就是这个时代的寄存器

加上真正的 ifloop 控制器,才是完整的“大脑”

大脑要工作,还得接存储。

文章一开始的,LLM算不算图灵机,其实差远了。

用这个范式去分析现在流行的AI论断,就很有趣了。

LLM是真正的智能吗?是 AGI 吗?

同理,ALU它懂“真正的加法”吗?它能解决 “现实世界” 的四则运算问题吗?

哈哈哈,都是什么问题啊。

什么算“智能”?它也是很多不同范式的任务被杂糅在一起的概念。而且它是什么已经。。。不重要了。关键看某一类任务它能做什么。