OpenAI工程师必备经典《苦涩的教训》,原来20多年前就有了原型

人工智能 新闻
大量数据学习涌现出来的能力,终于超越了人们的想象。

OpenAI 推出视频生成模型 Sora 已经一周的时间了,热度不减,作者团队还在持续放出让人眼前一亮的视频。比如「一群爱冒险的小狗探索天空废墟的电影预告片」,Sora 一次生成并自己完成剪辑。

当然,一个个生动、逼真的 AI 视频让人们好奇为什么是 OpenAI 率先打造出了 Sora 并能够跑通所有 AGI 技术栈呢?这一问题在社交媒体上引发了热烈的讨论。

图片

其中,在一篇知乎文章中,加州大学伯克利分校计算机科学博士、作者 @SIY.Z 分析了 OpenAI 成功的一些方法论,他认为 OpenAI 的方法论就是通往 AGI 的方法论,并且该方法论构建在几个重要的「公理」之上,包括了 The bitter lesson、Scaling Law 和 Emerging properties。

图片

知乎原贴:https://www.zhihu.com/question/644486081/answer/3398751210?utm_psn=1743584603837992961

其中 The bitter lesson 源自机器学习先驱 Rich Sutton 在 2019 年的一篇经典文章《苦涩的教训》, 通过探讨人工智能近几十年所走过的弯路,他抛出的核心观点是:人工智能如果想要长期获得提升,利用强大的算力才是王道。这里的算力隐含了大量的训练数据和大模型。

图片

原文链接:http://www.incompleteideas.net/IncIdeas/BitterLesson.html

因此,作者 @SIY.Z 认为某种意义上,强大算力加持的通用 AI 算法才是 AGI 路径的王道和 AI 技术真正进步的方向。有了大模型、大算力和大数据,The bitter lesson 构成了 AGI 的必要条件。再加上 Scaling Law 这一充分条件,通过算法使大模型、大算力和大数据获得更好的结果。

无独有偶,本周被疯传的 OpenAI 研究人员 Jason Wei 的每日工作时间线中也提到了 Rich Sutton 的 The bitter lesson。由此可见,很多业内人士将 The bitter lesson 视为圭臬。

图片

来源:https://twitter.com/_jasonwei/status/1760032264120041684

与此同时,在另一个关于「大语言模型(LLM)是否可以作为自身结果的验证者」的讨论中,有人认为 LLM 验证自身结果时根本不够准确,并且会导致性能更差(还需要为 API 付出很多代价)。

图片

来源:https://twitter.com/curious_vii/status/1759930194935029767

对于这一观点,又有推特网友在 Rich Sutton 二十多年前的一篇博客中有了重要的发现。

原文链接:http://incompleteideas.net/IncIdeas/KeytoAI.html

博客中是这样说的:

考虑到任何 AI 系统以及它所拥有的知识,它可能是一个专家系统或者像 CYC 这样的大型数据库。或者它可能是一个熟悉建筑物布局的机器人,或者了解在各种处境下如何做出反应。在所有这些情况下,我们可以问 AI 系统是否可以验证自己的知识,或者是否需要人们干预来检测误差和不可预见的交互,并进行纠正。在后者这种情况下,我们永远无法建立真正庞大的知识系统。它们总是脆弱且不可靠的,并且规模仅限于人们可以监控和了解的范畴。

没想到,Rich Sutton 进行了回帖,表示这篇写了一半的博客是 The bitter lesson 的原型。

图片

来源:https://twitter.com/RichardSSutton/status/1760104125625459171

其实,在 OpenAI 刚发布 Sora 不久,就有很多人意识到了 The bitter lesson 发挥了重要作用。

图片

还有人将 The bitter lesson 与 Transformer 论文 Attention is All You Need 并列看待。

图片

来源:https://twitter.com/karanganesan/status/1759782109399662777

文章最后,我们回顾一下 Rich Sutton 的《苦涩的教训》全文。

70 年的人工智能研究史告诉我们,利用计算能力的一般方法最终是最有效的方法。这个归摩尔定律解释,或者它对每单位计算成本持续指数级下降的概括。大部分 AI 研究都是在认为智能体可用的计算为恒定的情况下进行的(在这种情况下,利用人类知识是提高性能的唯一方法),但是,在比典型研究项目稍长的时间尺度内,我们不可避免地会需要大量的计算。

要在短期内有所提升,研究人员要利用专门领域的人类知识。但如果想要长期的获得提升,利用计算能力才是王道。这两者本无需对立,但实际上它们往往如此。花时间研究一个,就会忽略另一个。利用人类知识的方法容易复杂化,导致其不太适合利用计算的方法。很多例子表明 AI 研究人员对这些教训的认识太晚,因此我们有必要回顾一些突出的例子。

在计算机国际象棋中,1997 年击败世界冠军卡斯帕罗夫的方法基于大量深度搜索。当时,大多数 AI 计算机象棋研究人员沮丧地发现了这一点,他们的方法是利用人类对象棋特殊结构的理解。当这个利用硬件和软件的基于搜索的更简单方法被证明更有效时,这些基于人类知识的象棋研究人员却仍不肯认输。他们认为虽然这个「暴力」搜索方法此次赢了,但它并不是一个普遍的策略,无论如何它不是人类下国际象棋的方法。这些研究人员希望基于人类输入的方法获胜,但结果却令他们失望了。

计算机围棋中也有类似的研究进展模式,只是晚了 20 年。最初研究人员努力利用人类知识或游戏的特殊性来避免搜索,但所有的努力都被证明没什么用,因为搜索被大规模地有效应用。同样重要的是利用自我对弈(self play)来学习一种价值函数(就像在很多其他游戏甚至国际象棋中一样,虽然在 1997 年首次击败世界冠军的比赛中没起到什么作用)。通过自我对弈学习和一般学习有点像搜索,因为它能让大量的计算发挥作用。搜索和学习是人工智能研究中利用大量计算的两种最重要技术。在计算机围棋中,就像计算机国际象棋中一样,研究人员最初是想通过人类理解(这样无需太多搜索)来实现目的,只是在后来,通过搜索和学习才取得了巨大成功。

在语音识别领域,早在上世纪 70 年代就有一个由 DARPA 赞助的竞赛。参赛者利用了很多利用人类知识的特殊方法:单词、因素和人类声道等。另一方面,还有人利用了基于隐马尔可夫模型的新方法,这些方法在本质上更具统计性,计算量也更大。同样,统计方法战胜了基于人类知识的方法。这导致了自然语言处理领域的重大改变,过去几十年来,统计和计算在该领域逐渐占据主导地位。深度学习最近在语音识别中的兴起正是朝着这一方向迈出的最新一步。

深度学习方法更少依赖人类知识,使用更多的计算,并且伴有大量训练集的学习,从而生成更好的语音识别系统。就像在游戏中一样,研究人员总是试图令系统按照他们的思维方式进行运作 —— 他们试图将知识放在系统中 —— 但事实证明,最终结果往往事与愿违,并且极大浪费了研究人员的时间。但是通过摩尔定律,研究人员可以进行大量计算,并且找到一种有效利用的方法。

计算机视觉领域存在相似的模式。早期方法认为视觉是为了搜索边缘、广义圆柱体或者取决于 SIFT 特征。但是今天,所有这些方法都被抛弃了。现代深度学习神经网络仅使用卷积和某些不变性的概念即可以取得更好的效果。

这是一个非常大的教训。因为我们还在犯同一类错误,所以依然未能彻底了解人工智能领域。要看到这一点并且有效地避免重蹈覆辙,我们必须理解这些错误为何会让我们误入歧途。我们必须吸取惨痛的教训,即从长远看,固守我们的思维模式是行不通的。痛苦的教训基于以下历史观察结果:

  1. AI 研究人员常常试图在自身智能体中构建知识,
  2. 从短期看,这通常是有帮助的,能够令研究人员满意,
  3. 但从长远看,这会令研究人员停滞不前,甚至抑制进一步发展,
  4. 突破性进展最终可能会通过一种相反的方法 —— 基于以大规模计算为基础的搜索和学习。最后的成功往往带有一丝苦涩,并且无法完全消化,因为这种成功不是通过一种令人喜欢、以人为中心的方法获得的。

我们应该从痛苦的教训中学到的一点:通用方法非常强大,这类方法会随着算力的增加而继续扩展,即使可用计算变得非常大。搜索和学习似乎正是两种以这种方式随意扩展的方法。

图片

强化学习教父 Richard S. Sutton,现任加拿大阿尔伯塔大学教授。

我们从痛苦的教训中学到的第二个普遍观点是,意识的实际内容是极其复杂的;我们不应该试图通过简单方法来思考意识的内容,如思考空间、物体、多智能体或者对称性。所有这些都是任意的、本质上复杂的外部世界的一部分。

它们不应该被固有化,其原因是复杂性是无穷无尽的;相反,我们只应该构建可以找到并捕获这种任意复杂性的元方法。这些方法的关键在于它们能够找到很好的近似值,但对它们的搜索应由我们的方法完成,而不是我们自己。

我们希望 AI 智能体可以像我们一样发现新事物,而不是重新找到我们所发现的。在我们发现的基础上构建只能令人更加难以看清发现过程的完成情况。

责任编辑:张燕妮 来源: 机器之心
相关推荐

2023-07-10 09:12:18

Date存储Unix

2019-09-08 15:20:38

人工智能AI

2019-01-28 06:13:11

数据工程师数据科学家数据分析

2023-10-26 19:05:57

AI模型

2021-03-09 09:57:33

算法开源技术

2020-08-07 08:30:07

操作系统Android macOS

2020-10-30 08:49:06

戴尔

2020-09-29 13:10:28

DevOps自动化技能

2015-01-26 09:53:54

AppleWatch

2019-02-20 09:35:05

爬虫工程师开发工具

2019-09-24 20:26:03

Windows 10Windows微软

2011-11-28 14:01:30

苹果日本iPhone

2018-04-26 05:48:56

2022-08-15 10:28:11

分布式计算

2017-10-23 13:58:46

前端代码工程师

2019-04-17 10:25:00

前端工程师自检清单

2021-05-08 08:55:54

CPUIBMIntel

2021-11-10 08:58:06

Linux服务器软件

2013-12-18 10:56:48

Linux运维运维技能

2018-05-21 11:47:57

数据库MySQL速查手册
点赞
收藏

51CTO技术栈公众号