本次访谈由知名播客主持人 Lex Fridman 主持,访谈对象是 Cursor 团队的创始成员,包括 Michael Truell、Sualeh Asif、Arvid Lunnemark 和 Aman Sanger。访谈的主题围绕 AI 编程工具的未来展开,特别是与 GitHub 整合可能带来的影响。自成立以来,Cursor 团队在 AI 辅助编程领域取得了显著进展,开发出了一系列标志性项目,旨在提升开发者的工作效率。目前,Cursor 不仅专注于优化编程工具,还广泛涉足与大语言模型的集成,力求在编程环境中实现更高的自动化和智能化。在访谈中,团队成员详细讨论了 AI 在编程中的应用前景,以及如何通过技术创新来应对未来的挑战。由于内容较长,今天发布采访的下半部分。
Cursor 团队的核心观点包括:
- 代码编辑器的演变:传统的代码编辑器作为软件构建的工具,正在向更高级的形式发展,集成了 AI 辅助编码功能,使得编程更加高效和有趣。Copilot 是第一个真正面向消费者的 AI 产品,即第一个由语言模型驱动的消费者产品。
- 快速迭代的重要性:在编程和 AI 社区中,快速行动和实验是创造有趣且有用功能的关键,它允许开发者快速验证想法并进行迭代。在 AI 编程中,即使只领先几个月,甚至一年,都会让你的产品更具实用性。
- 编程的民主化:编程的快速实现能力吸引了更多人参与,Cursor 等工具的出现在降低编程门槛,使得非专业人士也能快速开发项目。
- AI 在编程中的角色:AI 正在成为编程中的智能助手,通过自动补全、代码生成等功能,提高编程效率,同时引发对编程本质的重新思考。
- 编程的未来趋势:随着 AI 技术的进步,编程将更加注重创造性和决策性的任务,而繁琐的编码工作将越来越多地由 AI 完成。
- 人机协作的新时代:未来的编程将是由人类和 AI 共同参与的过程,人类负责提供创造性的指导和决策,而 AI 则负责执行和优化,共同推动软件的发展。
以下是本期播客内容的完整翻译,我们作了不改变原意的删减。
拥有优秀的漏洞检测模型必不可少
莱克斯·弗里德曼(Lex Fridman)
人们很难理解哪些代码行是重要的,哪些不是。正如你们网站的一个原则所述,如果一段代码可能导致严重后果,就应该添加注释来说明这行代码的危险性。
莱克斯·弗里德曼(Lex Fridman)
没错。你提到每一行代码都需要被理解,这很有道理,因为这反映了人类的一些特质。工程师会不断进步,即使是同一个人,也可能会忘记某段代码是如何导致泰坦尼克号沉没的。仅仅通过查看代码,你可能无法直观地理解一个简单函数的作用。
阿维德·伦纳马克(Arvid Lunnemark)
是的,我认为这在某种程度上也适用于当今的 AI 模型。如果你在每一行都写上“危险”这样的词,模型会更加关注这些内容,并更可能在该区域发现漏洞。
莱克斯·弗里德曼(Lex Fridman)
实际上,标记代码以识别其可能带来的风险是一种非常好的实践。
阿维德·伦纳马克(Arvid Lunnemark)
确实,这个问题很有争议,有些人觉得它很丑。
苏亚莱·阿西夫(Sualeh Asif)
虽然我个人不太喜欢这种方法,但我从 Arvid 那里学到,这确实有助于模型的运作。人类容易遗忘,也容易犯小错误,这可能导致一些问题,比如在启动服务器时出错。尽管我们进行了大量测试,但总有一些细节需要特别注意。
阿曼·桑格(Aman Sanger)
要非常小心。是的,就像普通的 DOC 字符串一样,我认为人们在做修改时通常会快速浏览,然后觉得,哦,这个我知道怎么做。你确实需要指出来,以免他们忽视。
莱克斯·弗里德曼(Lex Fridman)
是的,你必须意识到自己可能会带来很大的影响。我们通常不会想到这一点。例如,你可能会想:“我该如何弄清楚这个东西的运作方式,以便改进它?”但你可能没有考虑到可能产生的负面影响。
阿维德·伦纳马克(Arvid Lunnemark)
在我们对所有事物进行形式验证之前,你可以更自由地进行操作。一旦验证通过,你就可以确信自己没有引入任何错误。
阿曼·桑格(Aman Sanger)
我很好奇,你具体认为未来会是什么样子?
阿维德·伦纳马克(Arvid Lunnemark)
人们将不再编写测试。当你编写一个函数时,模型会建议一个规范说明,然后你对这个规范说明进行审核。同时,智能推理系统会进行验证,以确保实现符合该规范说明。我认为这种情况会在大多数函数中发生。
迈克尔·特鲁尔(Michael Truell)
这是否涉及到你之前提到的问题,即在软件中明确指定意图的困难?有时候,可能是因为意图本身难以明确,所以很难确保它真正符合你的期望。
阿维德·伦纳马克(Arvid Lunnemark)
你觉得制定那个标准很难吗?
迈克尔·特鲁尔(Michael Truell)
对于给定的规格,我认为可能存在一个问题,那就是你是否真的能够进行形式验证?这是否可行?我认为这里面还有更多值得深入探讨的内容。
迈克尔·特鲁尔(Michael Truell)
我认为你关注的是那些在规范语言中难以明确界定的事物。我明白了。也许你只是需要一个反对形式化验证的理由。
阿曼·桑格(Aman Sanger)
令人担忧的是,有大量文件……
迈克尔·特鲁尔(Michael Truell)
替代单元测试的工具。
阿维德·伦纳马克(Arvid Lunnemark)
当然,我认为你也可以改进标准语言,以捕捉它们目前未能真正体现的一些内容。不过我不太确定。我觉得这非常令人兴奋。
莱克斯·弗里德曼(Lex Fridman)
你讨论的不仅仅是单个函数,而是关于整个代码库。
阿维德·伦纳马克(Arvid Lunnemark)
我认为整个代码库的处理难度较大,但这正是我希望实现的目标。我相信这是可行的,因为最近有许多研究表明,可以进行形式验证,甚至可以深入到硬件层面。例如,你可以对 C 代码进行形式验证,然后通过 GCC 编译器进行验证,最终通过 Verilog 验证到硬件。这是一个非常庞大的系统,但确实可行。我认为大型代码库在某种程度上是类似的,它们就像多层系统。如果你能将其分解并对每个部分进行形式验证,那么我认为这是可行的。 我认为规范化问题确实存在,不过,这需要进一步的探讨和解决。
阿曼·桑格(Aman Sanger)
你是如何处理副作用的?或者说,你是如何处理外部依赖的,比如调用 Stripe API?
苏亚莱·阿西夫(Sualeh Asif)
Stripe 可能会为此编写一个规范。
阿曼·桑格(Aman Sanger)
你不可能对所有事情都采取这种方式。比如,你能对你使用的所有东西都这样做吗?如果有一个语言模型,人们可能会将其作为程序的基本元素使用,对吧?这就会产生依赖。那么,你现在如何将其纳入考虑呢?我认为你需要仔细思考这个问题。
阿维德·伦纳马克(Arvid Lunnemark)
或许可以证明这一点。
阿曼·桑格(Aman Sanger)
那么,语言模型是如何证明这一点的呢?
阿维德·伦纳马克(Arvid Lunnemark)
我认为,实际上是有可能证明一个语言模型符合预期,或者证明它确实给出了正确答案的。这是一种理想的状态。
莱克斯·弗里德曼(Lex Fridman)
是的,我的意思是,如果可能的话,那就是马丁·路德·金的“我有一个梦想”演讲。这无疑有助于确保你的代码没有错误,并保障 AI 的安全性,以防止对人类文明构成潜在威胁。因此,从全面的 AI 安全性到简单的错误检测,你提到模型在找错误方面有困难。那么希望是什么呢?
苏亚莱·阿西夫(Sualeh Asif)
我最初的期望是,我和 Michael 能对此发表看法。首先,模型应该能够快速识别一些明显的错误,比如常见的差一错误。 有时候,你在注释中写了一些内容,但实际操作却不一致。这种情况很常见,比如我在注释中写了“小于”,但在代码中可能用了其他比较符号。模型应该能够识别这种不一致,并提醒你:“你确定要这样做吗?”最终,它也应该能够发现那些更难察觉的错误。
迈克尔·特鲁尔(Michael Truell)
值得注意的是,为了让 AI 为你承担越来越多的编程任务,拥有优秀的漏洞检测模型是必不可少的。 如果 AI 为你构建越来越多的系统,你不仅需要生成代码,还需要验证代码的正确性。否则,我们之前讨论过的一些问题,比如使用这些模型进行编程,将变得难以维持。因此,这不仅仅是为了让人类在编程中发现和修复漏洞,更重要的是,还要能够验证 AI 生成的代码是否真正有效。
阿维德·伦纳马克(Arvid Lunnemark)
那么,重要的是,你实际上是如何做到这一点的呢?我们曾在晚餐时多次激烈讨论过如何清理一个错误模型。其中一个非常流行的想法是,引入错误可能比发现错误更简单。 因此,你可以训练一个模型在现有代码中引入错误,然后再训练一个错误检测模型,利用这些合成数据来发现错误。这只是一个例子,但还有许多其他的想法。
迈克尔·特鲁尔(Michael Truell)
在解决问题时,除了在模型层面进行工作外,你还可以采取许多其他措施,比如使用更大的模型,并为其提供比代码更多的信息。就像通过查看文件来找出错误,这对人类来说常常是个挑战。因此,通常你需要运行代码,查看跟踪信息,并逐步使用调试器,这是一种完全不同的思路。
这里可能存在两种不同的产品形式:一种是专业且高效的模型,它在后台运行并尝试发现错误。就像 Arvid 之前提到的关于某个恶意输入框错误的例子,有时候你可能会知道存在一个错误,而不是盲目地验证假设。你知道这是一个问题,并且非常想解决它。你可能愿意投入大量计算资源,甚至花费 50 美元或更多来解决这个错误。
莱克斯·弗里德曼(Lex Fridman)
你有没有考虑过在整个过程中引入金钱奖励?比如说,如果你发现了一个错误或者生成了让我非常满意的代码,我可能会愿意支付一定的报酬。几天前,我开始使用 Cursor,它生成了完美的代码,比如与 YouTube API 交互的三个函数,用于更新字幕和本地化,处理不同语言。API 文档不够完善,而我在网上搜索了很久也找不到确切的信息,很多信息都很杂乱,但 Cursor 生成的代码却非常完美。我查看并测试了代码,发现它确实是正确的。
当时我就想,如果有个按钮让我可以打赏,比如 5 美元,那就太好了。这样不仅支持了公司,也支持了这个界面和其他用户,这可能会传递一个强烈的信号,比如“干得好”。这比仅仅接受代码的反馈要更有力,对吧?你实际上是在传递一个强烈的“干得好”的信号。而对于错误发现,显然有很多人愿意为发现错误支付大量金钱,比如错误悬赏机制。你们有考虑过这个吗?
阿维德·伦纳马克(Arvid Lunnemark)
是的,在公司内部这是一个有争议的想法。我认为这在某种程度上取决于你对人性的信任程度。你知道,我觉得如果你不花钱去寻找漏洞,而在没有找到漏洞时也不花钱,这样会很不错。而如果找到了漏洞并且你选择接受,那么它会显示你花费了多少钱,比如说 1 美元,表示你花了 1 美元来接受这个漏洞。
当然,也有一些担忧,比如我们可能会消耗大量的计算资源,或者人们可能会直接复制粘贴。我认为这是一个需要考虑的问题。还有一个担忧是,把金钱引入产品可能会降低它的趣味性,因为你不得不考虑金钱,而你只想专注于代码。所以,也许更合理的方式是将其分开,比如你每个月支付一些费用,然后可以免费获得所有这些服务。
莱克斯·弗里德曼(Lex Fridman)
可能还存在一个不同的临界因素。
阿维德·伦纳马克(Arvid Lunnemark)
是的,它仍然保留着类似美元符号的标志。我认为这样可以接受,但我也理解不想引入该标志的理由。
阿曼·桑格(Aman Sanger)
是的,我本来想说,人们这样做是为了分享。当他们有了很棒的经历时,就会与朋友分享。确实如此。
迈克尔·特鲁尔(Michael Truell)
还有一种可能是,我们可以找到一个技术解决方案,比如在系统问题上,如果我们能够更好地理解系统输出。我指的是,例如使用 LSP 进行错误检查,然后运行代码。如果你能够达到某种程度,实际上可以验证“哦,我已经修复了这个错误”,那么外围系统可能就不再依赖我们的系统了。
莱克斯·弗里德曼(Lex Fridman)
终端与代码之间的交互性如何?在终端中运行代码时,可以获得多少信息?是否可以在代码运行时进行循环检测错误?如果代码或运行时出现错误,如何建议修改代码?目前,它们似乎是完全独立的。我知道可以在终端中使用类似 Ctrl+K 的快捷键来辅助编写代码。
阿曼·桑格(Aman Sanger)
你还可以在检查 Command K 中使用终端上下文。我们还没有循环的部分,所以我们怀疑这样做会很有意义。至于这个功能是在前端还是后端实现,我们也一直在讨论。
莱克斯·弗里德曼(Lex Fridman)
当然,背景信息非常有趣。例如,如果我们以不同的方式运行代码,会发生什么呢?此外,还有关于如何保护数据库不被修改的问题。这确实是一个值得关注的问题。
苏亚莱·阿西夫(Sualeh Asif)
这里确实有一些很酷的解决方案。目前正在开发一个新的 API,它并不在 AWS 上,而是在 PlanetScale 上。我不确定 PlanetScale 是否是第一个实现这种功能的平台。它的稳定性类似于为数据库添加分支功能,比如当你在开发一个功能时,希望测试一个模拟数据库,但又不想直接测试生产数据库时,你可以为数据库创建一个分支。他们通过在日志中创建分支来实现这一点。
显然,要正确实现这一点需要很高的技术复杂性。我认为数据库公司需要一些新技术来实现这一功能。目前,他们已经拥有很好的数据库。我认为像 Turbopuffer 这样的数据库可能会在日志中添加分支功能。也许人工智能代理会利用分支功能在某个分支上进行测试,这将成为数据库支持分支功能的一个要求。
阿曼·桑格(Aman Sanger)
复制一个文件系统确实是一件很有趣的事情,对吧?
苏亚莱·阿西夫(Sualeh Asif)
是的,我认为所有事情都需要进行分类,就是这样。
莱克斯·弗里德曼(Lex Fridman)
是的,这正是多元宇宙的特性,对吧?如果每件事情都会产生分支,就会有许多可能的结果。
苏亚莱·阿西夫(Sualeh Asif)
我的意思是,显然有一些非常高效的算法可以确保你不会占用过多的空间或 CPU 等资源。
莱克斯·弗里德曼(Lex Fridman)
这里是一个非常适合讨论基础设施问题的地方。你们主要使用 AWS,那么有哪些值得注意的细节和挑战呢?你们为什么选择 AWS?是什么让 AWS 依然保持优势?
阿维德·伦纳马克(Arvid Lunnemark)
AWS 的产品非常出色,使用时你可以放心它会正常运行,尽管设置过程可能会比较复杂。
莱克斯·弗里德曼(Lex Fridman)
为什么界面设计得如此糟糕?
阿维德·伦纳马克(Arvid Lunnemark)
好的,就这样。
莱克斯·弗里德曼(Lex Fridman)
这就是胜利的本质。
苏亚莱·阿西夫(Sualeh Asif)
他们认为这是理所当然的结果,因为他们正在取得胜利。
阿维德·伦纳马克(Arvid Lunnemark)
你总是可以信任 AWS,因为它始终能够可靠运行。如果出现问题,很可能是由于你的设置或操作导致的。
初创公司扩张的挑战
莱克斯·弗里德曼(Lex Fridman)
作为一家相对较新的初创公司,您是否在扩展过程中遇到了一些有趣的挑战,比如吸引大量用户?
迈克尔·特鲁尔(Michael Truell)
在提升每秒请求处理数量的过程中,我认为这是一个非常有趣的过程。随着规模的扩大,你会发现用于缓存和数据库的通用组件会遇到各种问题。现在,我们已经达到了一个规模,比如说,我们的表会出现溢出等问题。此外,我们还构建了一些定制系统,比如用于计算代码库语义索引和回答代码库相关问题的检索系统。我觉得这些系统一直以来都是比较难以扩展的部分之一。
苏亚莱·阿西夫(Sualeh Asif)
我有几个朋友是非常资深的工程师,他们常说的一句话是:很难预测系统会在哪里出问题。当你扩展系统时,虽然可以尝试提前预测,但总会有一些意想不到的事情发生。 即使你认为已经考虑周全,但实际上并没有完全覆盖所有情况。
对于特定的系统,我们的做法很明确:上传时将所有代码分块,然后对这些代码进行处理,并将处理结果存储在数据库中,但我们并不存储原始代码。这样做是为了避免引入客户端的错误,因为我们对客户端错误非常谨慎。我们在服务器上存储了许多细节,但所有数据都是加密的。技术上的一个挑战是确保本地文件状态与服务器上的状态一致。我们最终采用的方法是:为每个文件保留一个哈希值,然后为每个文件夹保留一个哈希值,这个值是其所有子项的哈希值。你可以递归地这样做直到文件系统的根目录。
为什么要这么复杂呢?你可以为每个文件保留一个哈希值,然后每分钟尝试下载服务器上的哈希值,找出服务器上不存在的文件。可能你刚创建了一个新文件,可能你刚删除了一个文件,或者你切换到了一个新分支,并尝试协调客户端和服务器之间的状态。但这会在客户端引入巨大的网络开销。没有人希望我们一直占用他们的 WiFi,尤其是在使用某些特定工具时。
此外,这也会在数据库中引入巨大的开销。我们每秒查询一个接近 20 TB 的数据库,这简直是疯狂的。你绝对不想这样做。所以我们要做的是尝试协调项目根目录的单个哈希值。如果出现不匹配的情况,就去找出所有不一致的地方。也许你查看子项,看看哈希值是否匹配。如果哈希值不匹配,就去查看它们的子项,依此类推。我们只在不匹配的情况下这样做。对于大多数人来说,大多数时候,哈希值是匹配的。
莱克斯·弗里德曼(Lex Fridman)
这有点类似于分层协调。
苏亚莱·阿西夫(Sualeh Asif)
类似这样的东西。
阿曼·桑格(Aman Sanger)
是的,它被称为 Merkle 树。
莱克斯·弗里德曼(Lex Fridman)
是的。我觉得看到你思考这些问题真的很酷。
苏亚莱·阿西夫(Sualeh Asif)
困难主要源于使用该系统的人数增加。如果客户中有一些拥有庞大代码库的公司,比如我们最初编写了一个很大的 暗码库,但与一些存在了 20 年的公司相比,这算不了什么。这些公司拥有海量文件,你希望能在程序员之间推广。构建简单的东西很容易,但要推广到众多个人和公司显然是一个难题,这实际上是一个独立的挑战。因此,这也是推广的一部分。我们的当前解决方案在不断创新,我们正在努力,但在过去的几周和几个月里,推广所有这些也是一个挑战。
阿曼·桑格(Aman Sanger)
在这个索引系统中,还有许多巧妙的设计。例如,成本的瓶颈不在于将数据存储在向量数据库中,而在于代码的向量化。 你不希望每个使用相同代码的公司员工都重新向量化代码库,除非他们在不同的分支上有一些不同的文件或做了一些本地更改。由于向量化是瓶颈,可以通过一个巧妙的技巧来避免处理分支和其他数据库的复杂性,只需缓存给定代码块的哈希值对应的向量即可。这意味着当公司中的第 n 个人向量化他们的代码库时,速度非常快。而且,所有这些操作都无需在我们的服务器上存储任何代码数据,我们只存储向量数据库中的向量。
莱克斯·弗里德曼(Lex Fridman)
目前,从索引代码库中可以获得的最大收益是什么?我只是好奇,用户能从中得到哪些好处?从长远来看,似乎会有越来越多的好处,但在短期内,仅仅是对代码库提问,这有什么用处和实用性呢?
阿维德·伦纳马克(Arvid Lunnemark)
我认为最明显的例子是,当你想在大型代码库中找到某个正在发生的事情时,你可能模糊地记得“我们在哪里做了 x”,但不确定在普通文本搜索中该输入什么。这时,你可以使用代码库查询工具,只需按下 Command 键和 Enter 键,通常它就能找到你想要的位置。
阿曼·桑格(Aman Sanger)
正如你所说,我认为这种技术在未来只会变得更加强大。我们正在努力提升检索质量,我相信这方面的潜力远超人们的想象。
莱克斯·弗里德曼(Lex Fridman)
一个值得探讨的问题是,你是否考虑过在本地运行,为什么没有更多地在本地进行处理?因为我们刚刚讨论的内容似乎在云端实现起来特别困难。你必须考虑缓存、庞大的代码库以及大量程序员使用同一代码库的问题,这就像是在解一道难题。而大多数软件,尤其是那些需要大量计算的,通常是在本地完成的。那么,你是否考虑过在本地进行嵌入式处理?
阿维德·伦纳马克(Arvid Lunnemark)
是的,我们考虑过这个问题,我认为在本地实现会很酷。然而,这确实非常困难。需要注意的是,虽然我们的一些用户使用的是最新的 MacBook Pro,但超过 80%的用户使用的是 Windows 机器,其中很多性能并不强。因此,本地模型实际上只能在最新的计算机上运行。此外,构建这样的系统需要耗费大量成本和资源。所以即使我们想这样做,目前也无法专注于此。我知道有些人正在尝试这样做,我对此表示赞赏。但随着模型规模的扩大,想要用更大的模型完成更复杂的任务,在本地实现就变得更加困难。
苏亚莱·阿西夫(Sualeh Asif)
这并不是计算机性能不足的问题。举个例子,如果你是大公司的一名员工,拥有该公司的代码库,即使在高性能设备上编译和运行这些代码也非常困难。因此,即便你不是学生,而是大公司里最优秀的程序员,如果你在本地完成所有工作而不利用边缘计算,你的开发体验仍然会很糟糕。这样做可能勉强可行,但就不再有趣了。
阿曼·桑格(Aman Sanger)
例如,近似最近邻算法这样的庞大代码库会消耗大量的内存和 CPU 资源。
阿曼·桑格(Aman Sanger)
正如我们所说,让我们来讨论一下建模方面的问题。目前,本地模型的发展面临一些巨大的阻力,其中一个趋势是向 MoE(专家混合模型)发展。一个优点是,这些模型对内存带宽的依赖较小,这对本地模型有利,而不需要依赖 GPU 或 Nvidia 的 GPU。然而,缺点是这些模型总体上更大,通常需要在多个节点上运行,即使是高性能的 Macbook 也无法胜任。
我认为,特别是在编程方面,问题不在于模型是否足够好以完成这些任务,因为即使满足了这些要求,可能还会有其他问题,这也可能是本地模型的优势所在。但人们总是希望拥有最好的、最智能的、最有能力的东西,而这对于几乎所有人来说都很难实现。
莱克斯·弗里德曼(Lex Fridman)
你会对一个不太理想的模型感到满意吗?我明白,我就是其中之一。但有些人喜欢在本地操作,尤其是现在,确实有一个明显的开源运动在抵制这种趋势。这其实是件好事,因为你希望抵制那些正在壮大的权力中心。
阿维德·伦纳马克(Arvid Lunnemark)
实际上,我特别喜欢一种替代本地模型的方法。我认为这仍然处于研究阶段,但可以设想对语言模型推理进行同态加密的概念。你可以在本地机器上加密输入,然后将其发送到服务器。服务器利用强大的计算资源在这些加密数据上运行你无法在本地运行的模型,但服务器无法看到数据的内容。然后,服务器将答案发送回来,你解密答案,只有你能看到结果。我认为这仍然是研究的重点,所有的努力都是为了降低开销,因为目前开销确实很大。但如果能实现这一点,我认为这将非常酷,也会非常有影响力。
因为一个令人担忧的事情是,随着这些模型的不断进步,它们将变得越来越有经济价值。因此,世界上越来越多的信息和数据将流经一两个集中的参与者。这种集中化会引发担忧,比如传统的黑客攻击尝试,但这也会带来一种可怕的情况,如果世界上的所有信息都以明文形式流经某个地方,就可能会被以非常糟糕的方式进行监控。有时这出于最初的好意,比如人们想要防止坏人以不良方式使用 AI 模型,可能会加入一些监控代码,然后其他人可能会介入,你就会陷入一个滑坡,开始用世界上的大量数据做坏事。因此,我非常希望我们能解决同态加密的问题。
莱克斯·弗里德曼(Lex Fridman)
在机器学习中实现隐私保护确实是一个挑战,但这也是所有软件面临的共同问题。云计算提供了许多功能,我们对其依赖日益加深,这确实改善了我们的生活。然而,这也带来了弊端,因此我们需要依靠强大的安全措施来防范基本攻击。只有少数公司掌握着这些数据,它们显然具有影响力,并可能通过多种方式被渗透。这就是我们所处的世界。
苏亚莱·阿西夫(Sualeh Asif)
我真正担心的是这样一个世界:Anthropic 有一个负责的扩展政策。因此,我们处于较低的 Anthropic 安全等级(ASL),这可能是模型的安全或其他方面的原因。但随着我们使用代码和 ASL3、ASL4 等非常强大的模型,从大多数合理的安全考虑出发,你会希望监控所有的提示。
我认为这是合理且可以理解的,因为每个人都有自己的立场。然而,如果全世界的信息都被如此严格地监控,那就太糟糕了,这显得过于集中化。这就像在一条非常细的线上行走,一方面你不希望模型失控,另一方面,我不确定是否信任所有世界的信息都通过三个模型提供商。
阿曼·桑格(Aman Sanger)
你认为它与云服务提供商有哪些不同之处?
阿维德·伦纳马克(Arvid Lunnemark)
我认为,很多数据本来就不会被上传到云服务提供商那里。通常情况下,你可能会希望将更多的数据,包括一些原本不会在线上分享的个人数据,提供给 AI 模型或这些公司。这也导致了数据控制的集中化。对于云服务而言,你通常可以使用自己的加密密钥,比如在 AWS 上,他们实际上无法做太多事情。然而,在这里,数据是由集中化的实体查看的,所有内容都是明文的。
如何构建与 o1 竞争的模型?
莱克斯·弗里德曼(Lex Fridman)
在编写代码时,我常常遇到一个难点,就是在代码的开头部分。在 Python 中,有很多模块需要导入。你可能可以凭直觉猜出我想在上下文中包含哪些内容。那么,自动识别上下文到底有多难呢?
迈克尔·特鲁尔(Michael Truell)
这确实是个棘手的问题。我认为未来我们可以在自动计算上下文方面做得更好。不过,使用自动上下文时需要权衡。 首先,包含更多上下文会使模型运行速度变慢,增加请求成本,这意味着模型调用和后台复杂操作的次数会减少。此外,许多模型在提示中包含大量信息时会感到困惑。因此,所包含上下文的准确性和相关性标准必须非常高。尽管如此,我们已经在产品的某些部分实现了一些自动上下文功能,这也是我们希望大幅改进的领域。
我认为在这方面有很多有趣的想法可以尝试,比如更好的学习和检索系统,包括更好的嵌入模型和重新排序器。此外,还有一些很有趣的学术想法,我们内部已经尝试过的,以及整个领域正在努力解决的问题,比如能否让语言模型达到理解新信息语料库的水平。最受关注的问题是,能否让上下文窗口变得无限大?如果上下文窗口变得无限大,模型能否真正处理无限的上下文?为了实现这一点,能否对无限上下文进行缓存,以避免每次都重新计算?
此外,还有一些类似于微调的有趣想法,即在模型权重中学习这些信息。如果在权重层面进行,而不是在上下文学习层面进行,可能会获得一种本质上不同的理解。目前还不确定最终结果会如何。但在此期间,作为公司,我们对更好的检索系统以及选择代码库中最相关的部分感到非常兴奋。我们相信在这方面可以做得更好。
阿曼·桑格(Aman Sanger)
一个有趣的概念验证是直接在模型的权重中编码这些知识,比如在 VS Code 中。我们在 VS Code 的一个实例中进行了实验,因为 VS Code 的代码是公开的。因此,这些模型在预训练时已经接触过 VS Code 的代码,甚至可能还接触过关于这些代码的问题和答案。随后,它们经过微调,以便能够回答关于代码的一般性问题。因此,当你询问它关于 VS Code 的问题时,它可能会生成不准确的回答,但有时也能很好地回答问题。我认为它的表现相当不错。
但如果你能专门训练或进一步训练一个模型,使其真正理解这个代码库,会怎样呢?这是一个尚未解决的研究问题,我们对此非常感兴趣。还有一个不确定性是,你是否希望模型成为端到端的解决方案,即它进行检索和内部处理,然后回答问题、创建代码,还是希望将检索与先进模型分开。也许在几个月内,你会得到一些比最好的开源模型更强大的模型。然后,你可能希望单独训练一个非常优秀的开源模型作为检索器,为这些更大的模型提供上下文。
莱克斯·弗里德曼(Lex Fridman)
您能详细说明一下训练模型以理解代码库的过程吗?具体来说,您提到的内容是什么意思?这是否涉及到使用合成数据?
阿曼·桑格(Aman Sanger)
确实,有很多方法可以尝试。想法肯定不缺,关键在于尝试所有这些方法,并通过实证找出效果最佳的方案。一个非常简单的想法是尝试复制 VS Code 和这些前沿模型的做法。可以进行某种免费的持续训练,包括一般的代码数据,同时加入你关注的特定代码库的大量数据,然后进行指令微调。
你可以使用一个关于代码的普通指令微调数据集,并加入许多关于该代码库的问题。获取真实的问题可能比较困难,或者你可以使用合成数据,例如让模型对代码的最新部分提问。你可以提取代码片段,然后提示模型或让模型为该代码片段提出问题,并将这些作为指令微调的独特数据点。理论上,这可能会提升模型回答关于该代码库问题的能力。
莱克斯·弗里德曼(Lex Fridman)
在我看来,OpenAI 某版本的测试时间计算系统在编程中的作用主要体现在评估和优化模型在实际应用中的性能。这样的系统能够帮助开发者在部署前识别潜在问题,并进行必要的调整,以确保模型在真实环境中高效运行。测试时间计算系统在编程中至关重要,因为它不仅提高了模型的可靠性,还改善了用户体验。
阿曼·桑格(Aman Sanger)
测试时计算的概念非常有趣。在预训练阶段,随着数据量和模型规模的扩大,模型的性能会不断提升,无论是在损失函数上还是在下游基准测试中,甚至在我们用于编程或其他任务时的整体表现上。然而,我们开始遇到数据瓶颈,这意味着继续扩大模型规模将变得困难。因此,增加测试时的计算量成为了一种有趣的方法,即在推理时增加浮点运算量(flops),但仍然能够获得相应的性能提升。
传统上,我们需要训练一个更大的模型来使用更多的浮点运算,但现在我们或许可以使用相同规模的模型并运行更长时间,以获得与更大模型相当的结果质量。我觉得这非常有趣,因为有些问题可能需要一个拥有百亿参数并训练了百亿个标记的智能模型,但这可能只占所有查询的 1%甚至 0.1%。所以,你会花费大量精力和计算资源去训练一个如此昂贵的模型,然后很少使用它吗?这感觉完全是浪费。相反,你可以训练一个能够处理 99.9%查询的模型,然后在推理时为那些真正需要最大智能的查询运行更长时间。
莱克斯·弗里德曼(Lex Fridman)
你如何判断某个问题需要什么级别的人工智能模型?是否可以动态地决定何时使用 GPT-4,何时使用较小的模型,以及何时需要其他特定的技术?
阿曼·桑格(Aman Sanger)
这确实是一个开放的研究问题。目前,我认为还没有人能够很好地解决这个模型选择的问题。我们希望能够做到这一点,并且已经有了一些初步的实现,比如用于 Cursor Tab。然而,在 GPT 4o 和 o1 之间,这就有些棘手了。或许吧。还有一些问题,比如需要多高的智能水平才能判断某件事情是否对四级模型来说过于困难。也许需要 o1 模型。这一点还不太清楚。
莱克斯·弗里德曼(Lex Fridman)
你提到了这一点。那么,预训练、微调和推理这三个过程的区分是否合理,以便确定在哪个环节可以获得最大收益?
阿曼·桑格(Aman Sanger)
这确实很奇怪,因为在推理阶段,计算需要一个完整的训练策略才能有效。更奇怪的是,除了大型实验室,甚至可能只有 OpenAI,几乎没有人真正了解其运作方式。有一些非常有趣的论文提供了他们可能在做什么的线索。因此,他们可能正在研究过程奖励机制。但问题在于我们并不完全清楚它具体是什么样的,所以很难评论它在整个过程中的位置。我认为它可能属于后训练阶段,但为了让模型在推理阶段的计算发挥作用,所需的计算量最终可能会远远超过预训练。
莱克斯·弗里德曼(Lex Fridman)
因此,我们甚至不知道 o1 是否仅仅使用类似于链式思维的逻辑。我们不知道他们是如何使用这些方法的。我们对此一无所知。
阿曼·桑格(Aman Sanger)
进行猜测是一件有趣的事情。
莱克斯·弗里德曼(Lex Fridman)
如果你要构建一个竞争模型,你会如何着手进行?
阿曼·桑格(Aman Sanger)
我认为需要训练一个过程奖励模型,我们可以深入探讨奖励模型,以及结果奖励模型与过程奖励模型的区别。 结果奖励模型是为语言模型训练的额外奖励模型,专注于最终结果。例如,在解决数学问题时,我们关注最终结果,评估其可能性,并为这个结果分配奖励。
而过程奖励模型则尝试评估思维链的每一步。去年夏天,OpenAI 发布了一篇初步论文,使用人工标注者创建了一个包含数十万条思维链的数据集。最终,我感觉在使用过程奖励模型方面,除了用它来影响我们在多个样本中进行选择外,尚未发现其他有趣的应用。在这些论文中,研究人员通常会从语言模型中采样大量输出,然后使用过程奖励模型对这些生成结果进行评分,可能还结合一些其他启发式方法,最终选择最佳答案。真正有趣的是那些被认为可能有效的研究,即使用这些过程奖励模型。如果你能评估思维链的每一步,那么你就可以探索多个思维路径,并使用这些过程奖励模型来评估所选路径的优劣。
莱克斯·弗里德曼(Lex Fridman)
是的,当分支的质量与最终结果的质量密切相关时,可以使用一个优秀的模型来判断应该选择哪个分支。这适用于短期和长期的情况。
阿曼·桑格(Aman Sanger)
我认为有趣的工作在于研究如何正确地训练过程奖励模型,或者探索那些已经开源的有趣项目。人们正在讨论如何以更自动化的方式训练过程奖励模型。可能是我有所遗漏,目前我还没有看到特别有效的方法能够创造性地利用过程奖励模型进行树搜索和编程。
莱克斯·弗里德曼(Lex Fridman)
这有点像是一个关于 AI 安全的问题,也可能涉及一些哲学层面的思考。OpenAI 表示,他们正在对用户隐藏推理过程,并称这是一个艰难的决定。他们选择让模型总结推理过程,而不是直接展示。同时,他们在后台监控推理过程,以确保模型不会试图操控用户,这是一种值得关注的可能性。你怎么看待隐藏推理过程这件事?
迈克尔·特鲁尔(Michael Truell)
对于 OpenAI 来说,一个可能需要考虑的因素是他们希望让人们难以从他们的模型中提取这些能力。如果能够访问模型的推理过程,模仿这项技术可能会变得更容易,因为这涉及到一些关键数据,比如模型达到最终结果的步骤。
莱克斯·弗里德曼(Lex Fridman)
因此,你可以据此进行训练。
迈克尔·特鲁尔(Michael Truell)
此外,一些大型语言模型提供商也出现了类似的情况。虽然这只是猜测,但有些 API 曾经允许轻松访问生成的所有标记的对数似然以及提示标记的对数似然,后来这些功能被取消。同样,这完全是猜测,但其中一个可能的原因是,如果能够访问类似的内部机制的对数似然,可能会提供更多信息,从而增强对这些大型模型的控制能力。
关于我们整合 o1 的讨论,我认为我们仍在学习如何使用这个模型。因此,我们在 Cursor 中提供了 o1,因为当我们获得这个模型时,我们非常想尝试一下。我相信很多程序员也会对尝试它感兴趣。然而,o1 并不是 Cursor 默认体验的一部分。我们仍未找到一种方法将其集成到编辑器中,以便能够每小时甚至每天使用。因此,如何使用这个模型仍然是一个悬而未决的问题。我们还没有看到人们发布的例子,明确显示出这是一个明显的用例,也许这可以让你更容易地运行这些后台任务,使这些模型和循环更加高效。但我们仍在探索中。
苏亚莱·阿西夫(Sualeh Asif)
为了澄清这一点,我们确实有一些计划。在尝试获取一些极其有用的东西之前,我们只需要做好充分的准备。
阿曼·桑格(Aman Sanger)
它存在一些显著的限制,例如即使在掩码功能方面,它也不支持流式处理。这意味着在需要监督输出时使用它会非常麻烦,因为你只能等待大段文本的出现。此外,这种感觉就像是在测试阶段进行计算和搜索的早期阶段,像是一个非常初级的版本,许多地方显得不够完善。我怀疑,在人们增加预训练数据量和模型规模并寻找技巧的同时,还会有另一条路径,即不断改进搜索功能。
合成数据的分类体系
莱克斯·弗里德曼(Lex Fridman)
看起来,Github Copilot 可能会以某种方式整合 o1 的功能。我看到一些评论在询问,这是否意味着 Cursor 已经不行了?我记得看到过这样的评论。
莱克斯·弗里德曼(Lex Fridman)
现在是关闭光标功能的时候吗?
迈克尔·特鲁尔(Michael Truell)
我认为这个领域与过去 20 年的软件领域有所不同,这里的发展潜力确实很大。因此,我相信三到四年后,最好的产品将比今天的最佳产品更有用。虽然可以讨论竞争优势和品牌优势,但最终,如果你停止在产品上创新,就会失败。这对初创公司和试图进入这个市场的人来说是个好消息,因为这意味着你有机会通过打造更好的产品来击败那些已经拥有大量用户的公司。因此,我认为在接下来的几年里,关键在于打造最好的产品和系统。这不仅涉及建模引擎,还包括编辑体验。
阿曼·桑格(Aman Sanger)
我认为,与其他产品相比,Cursor 的额外价值不仅在于能够快速集成新模型,更在于这些定制模型所带来的深度,这种深度在产品的各个方面都发挥着作用,可能你并未察觉。此外,精心设计的用户体验也是其价值所在。
莱克斯·弗里德曼(Lex Fridman)
好的,回到技术层面。你提到你有一个关于合成数据的分类体系。
阿曼·桑格(Aman Sanger)
我认为合成数据主要有三种类型。首先,什么是合成数据呢?正常数据,即非合成数据,通常是自然生成的,由人类活动产生。因此,通过某些人类过程,你会得到这些数据。合成数据的第一种类型是知识蒸馏。通过让一个语言模型输出标记或标记的概率分布,可以用这种方法训练一个能力较弱的模型。虽然这种方法不会让你得到比原始生成标记的模型更强大的模型,但如果你想从一些非常昂贵且高延迟的模型中提取某种能力,并将其蒸馏成一个较小的特定任务模型,这种方法非常有用。
第二种类型是当问题的一个方向比反方向更容易时。一个很好的例子是我们之前提到的错误检测,其中引入看似合理的错误比实际检测它们要容易得多。这对人类来说可能也是如此。因此,你可以让一个没有经过大量数据训练、不太聪明的模型在代码中引入一堆错误,然后用这些合成数据训练一个在检测错误方面非常出色的模型。
我认为最后一个类别是大实验室在合成数据方面主要做的事情,即使用语言模型生成可以轻松验证的文本。一个极端的例子是,如果你有一个验证系统可以检测语言是否达到莎士比亚风格,然后有一群猴子在打字机上打字,你最终可以获得足够的训练数据来训练一个具有莎士比亚风格的语言模型。这种情况在数学中尤其如此,因为对于形式语言来说,验证实际上非常简单。
你可以让一个普通的模型生成大量结果,然后选择那些你知道已经证明了基本真理的定理进行进一步训练。对于代码也可以做类似的事情,比如在 LeetCode 问题中,如果你有一组测试,你知道通过这些测试就意味着问题已解决,你可以做同样的事情,验证它通过了测试,然后训练模型和通过测试的输出。我认为在所有领域或一般情况下让这项工作顺利进行会有些困难,比如拥有完美的验证器对于开放式的杂项任务或更长时间跨度的任务(即使在编码中)来说确实很难。
莱克斯·弗里德曼(Lex Fridman)
那是因为你不像 Arvid 那样乐观。不过,确实需要为第三类安排一个审核者。
阿曼·桑格(Aman Sanger)
在你确认其正确性时,最好进行验证。这样,就不需要依赖大型语言模型进行验证,而是可以使用测试或形式系统。
迈克尔·特鲁尔(Michael Truell)
或者也可以运行这个程序,进行类似人工验证的手动质量控制。这类似于语言模型的验证,通过运行程序来实际理解输出。是的,这介于自动化验证和人工检查之间。
阿曼·桑格(Aman Sanger)
我认为这是最有可能带来巨大收益的一个类别。
RLHF vs RLAIF
莱克斯·弗里德曼(Lex Fridman)
RLHF(人类反馈强化学习)和 RLAIF(AI 反馈强化学习)是两种强化学习方法,旨在通过不同类型的反馈来优化模型性能。RLHF 通过人类反馈来指导模型的学习过程。人类评估者可以根据模型的输出提供反馈,帮助模型更好地理解任务目标和优化策略。这种方法特别适用于需要复杂判断和人类直觉的任务,例如自然语言处理中的对话生成和内容审核。RLAIF 则利用 AI 系统提供的反馈进行强化学习。AI 系统通过分析模型的输出和行为,提供自动化的反馈。这种方法可以减少对人类干预的依赖,适合需要快速迭代和优化的场景,如自动驾驶和游戏 AI。
这两种方法在提升模型性能方面的作用在于,通过提供额外的信息和指导,使模型能够更有效地学习和适应复杂的任务环境。RLHF 通过人类的直观判断帮助模型理解复杂任务,而 RLAIF 则通过 AI 的快速反馈加速模型的训练过程。通过结合人类或 AI 的反馈,模型可以更快地收敛到更优的策略,从而提高整体性能。
阿曼·桑格(Aman Sanger)
RLHF 指的是通过人类反馈中收集的标签来训练的奖励模型。我认为,当你能为你关注的任务获取大量人类反馈时,这种方法是有效的。RLAIF 很有趣,因为它依赖于验证比生成更容易的原则。某种意义上,你是在用语言模型查看其输出并进行验证。但实际上,如果语言模型在验证某些解决方案时比生成它们更容易,那么你可能可以递归地实现这一点,但我认为这并不完全如此。你可以做的另一件事是,将 RLAIF 和 RLHF 混合使用,通常模型实际上是相当准确的。 在这种情况下,模型在选择两个可能的生成结果中哪个更好时表现不错。然后只需要一点点人类的引导,大约 50 到 100 个例子,就可以将模型的先验与您想要的结果完全对齐。这与通常需要大量例子来训练这些奖励模型的 RLHF 方法不同。
莱克斯·弗里德曼(Lex Fridman)
在比较生成-验证与生成-排序时,你有什么直观的感受?在生成过程中,排序是否更为简单?
阿曼·桑格(Aman Sanger)
我的直觉告诉我,专业人士可能会认为情况应该如此。这就像是,如果你相信 P 不等于 NP,那么就会有一大类问题,其验证过程比证明过程更简单。
莱克斯·弗里德曼(Lex Fridman)
我想知道是否有相同的方法可以证明 P 不等于 NP,或者证明 P 等于 NP。
阿维德·伦纳马克(Arvid Lunnemark)
那样真的会非常酷。
莱克斯·弗里德曼(Lex Fridman)
那就是人工智能颁发的菲尔兹奖。功劳归谁?又是一个悬而未决的哲学问题。
苏亚莱·阿西夫(Sualeh Asif)
其实我是被提示的,这让我感到意外的好奇。比如,AI 获得菲尔兹奖的可能性有多大?实际上,我并没有相关的专业知识。我也不知道 Aman 的赌注是什么内容。
阿曼·桑格(Aman Sanger)
在 2020 年,我觉得通往 IMO(国际数学奥林匹克)的道路更加清晰,因为我已经能够解决一些 IMO 问题,并且当时的文献中有许多明显的策略可以采用。我认为现在我对这些领域的改进情况了解得更少,也缺乏对我们距离解决这些真正困难的开放性问题的直觉。
莱克斯·弗里德曼(Lex Fridman)
所以你认为这首先是一种直觉,而不是像物理学那样的科学吗?
苏亚莱·阿西夫(Sualeh Asif)
当然,百分之百。我认为这很有可能。我觉得他们可能更难进入。这类似于 BSD 猜想,或者像黎曼假设这样的数学难题的研究。实际上,这些问题真的很难。我们甚至不清楚通往解决方案的路径,更不用说解决方案本身了。
阿维德·伦纳马克(Arvid Lunnemark)
你的意思是,这是一个类似于封闭系统的环境,并且可以建立一个良好的奖励机制,从而使训练更容易进行。
阿曼·桑格(Aman Sanger)
我认为我们可能会在通用人工智能(AGI)出现之前获得菲尔兹奖。
苏亚莱·阿西夫(Sualeh Asif)
我想是的,我会很高兴。但我不知道在 2028 年或 2030 年。
AI 的发展限制在于卓越的工程技术
莱克斯·弗里德曼(Lex Fridman)
感觉事情的发展速度如此之快,仿佛已经过去了很长时间。说到发展速度,我们来聊聊 scaling laws。对于不太了解的人,我们应该先介绍一下 scaling laws 的概念。它们是什么?你认为当前的状况如何?未来的发展方向又是什么?
阿曼·桑格(Aman Sanger)
有趣的是,OpenAI 最初的 scaling laws 论文中存在一些错误,因为他们在学习率的安排上出现了问题,后来 Chinchilla 提出了一个更精确的模型。从那时起,人们开始偏离计算效率的最优路径,因为大家更多地进行优化。为了让系统在给定的生成式 AI(GI)和推理预算下表现更好,我认为这些曲线涉及的维度比我们最初使用的计算、参数数量和数据等要多。
推理计算量显然是一个维度,我认为上下文窗口长度是另一个显而易见的维度。因此,如果你关注推理计算和上下文窗口这两个方面,也许你会想训练某种特定的序列模型(SSM),因为它们在处理超长上下文时更便宜、更快速。即使在训练期间可能需要 10 倍的扩展能力,花费 10 倍的计算资源来训练以达到相同的能力水平也是值得的,因为你最关心的是长上下文窗口的推理预算。因此,观察人们如何在这些维度上进行探索将会很有趣。
莱克斯·弗里德曼(Lex Fridman)
你提到了多个维度的问题。显然,最初的概念仍然无法忽视模型的大小(通过参数来衡量)和数据的大小(通过 token 数量来衡量),以及两者之间的比例。这确实是一个引人注目的观点,似乎有某种特定的比例或阈值正在显现。你是否仍然相信“越大越好”的观点?
阿曼·桑格(Aman Sanger)
从纯粹的性能和智能角度来看,我认为更大的模型确实更出色。我特别看好蒸馏技术。我觉得人们可能会采取的路径是:如果我们在训练上投入大量资金,能否获得既具备强大能力又成本低廉的模型?这就像尽可能关注推理时间的计算。因为像 LLaMA 模型那样的简单版本,或者对 70 亿参数的模型进行过度训练,已经是人们常做的事情,对吧?但如果你真的关心这个问题,也许应该像 Gemma 那样,不仅仅是在 tokens 上训练,而是直接在最小化与 Gemma 27B 分布的 KL 散度(Kullback-Leibler 散度)上进行训练。这就是知识蒸馏。你花费计算资源来训练一个拥有 270 亿参数的模型,最终只是为了得到一个更小的模型。
莱克斯·弗里德曼(Lex Fridman)
这种蒸馏过程可以让你获得一个更快速的模型。模型越小,运行速度就越快。
阿曼·桑格(Aman Sanger)
理论上,知识蒸馏可以从正在训练的数据中提取出更多信息。这可能是解决数据瓶颈问题的另一种方法,因为用于训练的数据是有限的。我们可以先用所有这些数据训练一个非常大的模型,然后将其知识蒸馏到一个更小的模型中。这样,我们或许能够在这个小得多的模型中,从每个数据样本中提取出比直接训练时更多的信息。
莱克斯·弗里德曼(Lex Fridman)
如果我给你 10 万亿美元,你会怎么花?我的意思是,你又不能买个岛什么的。你会如何分配这笔钱,来改善大型模型,还是在区域高频基金中支付高频费用?或者……
阿曼·桑格(Aman Sanger)
是的,我认为在训练大模型方面,有许多我不了解的秘密和细节,这些通常只有大型实验室才掌握。问题在于,如果我尝试去做这些事情,可能会因为不了解这些细节而浪费大量资金。假设你拥有相关的知识和操作能力,或者必须在现有有限的信息下进行操作。
莱克斯·弗里德曼(Lex Fridman)
不,其实,我会说你应该迅速介入,获取所有信息、启发式方法以及定义事物训练方式的所有参数。如果我们考虑在未来五年内如何投资以最大化你所称的原始智能。
苏亚莱·阿西夫(Sualeh Asif)
答案其实很简单:你只需要尽可能多地获取计算能力。 最终,只需购买 GPU,研究人员就能解决所有问题,你可以根据需要调整模型的大小,无论是大模型还是小模型。
阿曼·桑格(Aman Sanger)
这让我产生了一个疑问:你究竟是因为计算能力和资金的限制,还是因为其他因素的限制呢?
苏亚莱·阿西夫(Sualeh Asif)
我更倾向于 Arvid 的观点,即我们的理想在某种程度上是有限的,但总是会有……
阿维德·伦纳马克(Arvid Lunnemark)
如果你拥有大量的计算资源,你可以进行许多实验。
莱克斯·弗里德曼(Lex Fridman)
因此,你会将计算资源用于进行大量实验,而不是用于训练一个庞大的模型。
阿维德·伦纳马克(Arvid Lunnemark)
我确实认为,我们的想法是有限的。
阿曼·桑格(Aman Sanger)
即便拥有所有的计算能力和数据,我认为最终的限制不在于想法,而在于真正卓越的工程技术。 即使拥有全世界的资本,你真的能组建一支在这个领域产生重大影响的团队吗?在研究中,有大量工作是纯粹且极其艰难的工程任务。比如,看看最初的 Transformer 论文,你会发现有多少工作是将文献中许多有趣的概念结合在一起,然后编写所有代码,比如优化内核等。我不确定它最初是在 GPU 还是 TPU 上运行的,但它确实达到了 GPU 的最大性能。
某人在这里编写了所有这些代码,而他可能是世界上最优秀的工程师之一。更进一步,下一代模型需要实现模型并行化,并在成千上万甚至可能是数万台 V100 上进行扩展,我认为这可能是 GBDE-3 所做的。这些事情需要大量的工程努力才能实现。如果你能将这些成本降低到接近零,或者至少让它变得容易 10 倍,使得拥有创新想法的人能够立即实现他们梦想中的新架构,并在 GPU 上达到 50%或 40%的性能利用率,我认为这将极大地加速研究进程。
苏亚莱·阿西夫(Sualeh Asif)
我的意思是,如果你看到一条明确的改进路径,应该优先选择那些容易实现的改进,对吧?我认为,OpenAI 和其他实验室可能做了正确的选择,优先实现那些容易的改进,比如将规模扩大到 GPT-4.25,并且随着规模的扩大,效果不断提升。只要一切进展顺利,就没有必要尝试新的想法,而是应该继续努力,从中获取尽可能多的收益。然后,也许当你真的需要新想法时,比如当你已经花费了 10 万亿美元时,可能就需要重新评估你的想法,那时你的想法可能会有所提升。
阿曼·桑格(Aman Sanger)
我想我们都认为,实现通用人工智能(AGI)需要一些新的想法。我们也可能都相信,这些想法可以在较小的规模上进行测试,并且我们对它们的成功充满信心。然而,对于实验室来说,在当前情况下,将有限的研究和工程人才投入到探索所有这些其他想法中是相当困难的,因为有一个核心技术可能在相当长的一段时间内持续提高性能。
编程的未来:程序员将长期占据主导
莱克斯·弗里德曼(Lex Fridman)
是的,这些大型实验室正如在行业中取得领先地位一样,正在迅速发展。那么,展望未来,这是一个重要的问题。您现在处于编程领域的核心位置,您认为在未来几个月到十年内,编程的本质会如何变化?
迈克尔·特鲁尔(Michael Truell)
我们对未来充满期待,程序员将在其中长期占据主导地位。 你可能已经听我们谈过这一点,我们强调的是程序员的速度、自主性,以及快速迭代和修改任何内容的能力。我认为这与一些人对这个领域的跳跃性想法有所不同。一个吸引人的想法是,你能否像在 Slack 等工具上与工程部门或工程师对话一样,与计算机对话并让它为你构建软件?它能否仅仅是一个独立的文本框?
我们对此不感兴趣的部分原因是我们之前提到的响应延迟问题。但更重要的原因是,这意味着放弃了大量的控制权。在文本框中进行非常具体的交流要困难得多。如果你只是像与工程部门交流那样与某个系统交流,你实际上是在将许多非常重要的决策交给它。这涉及到工程的本质。一些对工程不太了解的人可能认为,规范已经完全制定好,然后工程师只需实现它,把事情变成代码并使其存在。但我认为,很多优秀的工程,我们所享受的工程,涉及到大量关于构建内容的微小决策,以及在速度、成本和系统中涉及的所有其他因素之间的艰难权衡。 只要人类仍然是设计软件的人,并且是指定他们想要构建的内容的人,而不仅仅是由 AI 运行的公司,我们认为人类应该在主导地位做出这些决策。
因此,关于未来的样子仍然悬而未决。我认为,一个有趣的想法是,你可以控制查看代码库的抽象级别。你可以指向代码库的特定部分,通过伪代码的形式来理解代码库,并且实际上可以编辑这些伪代码,然后在正式编程级别进行更改。你可以在软件组件的编程中指向任何逻辑部分,保持编程中的文本编辑组件的流畅性和控制权,你甚至可以深入到代码中,也可以在更高的抽象级别操作,同时也带来巨大的生产力提升。
莱克斯·弗里德曼(Lex Fridman)
如果你能在抽象思维的层次上灵活切换,那就太好了。
迈克尔·特鲁尔(Michael Truell)
确实,这里有许多细节需要理清。目前,这个想法还不够明确,时间会证明它是否真的有效。然而,我们认为,人类在驾驶座上的控制权和速度原则非常重要。对于某些事情,比如 Arvid 之前提到的某些编程风格,可以交给它去处理。就像 chatbot 风格一样,如果你有一个非常明确的错误,这种情况在大多数编程中并不常见。我们认为,许多人重视的编程并不是这样的。
莱克斯·弗里德曼(Lex Fridman)
您如何看待编程这项基本技能?现在有许多年轻人对此感到有些畏惧。他们喜欢编程,但担心如果选择这条职业道路,未来会怎样。您认为编程这项基本技能会发生根本性的变化吗?
迈克尔·特鲁尔(Michael Truell)
我认为现在是一个令人振奋的软件开发时代。回想 2012 年和 2013 年的编程,那时有许多繁琐的流程和模板代码,还有一些非常棘手的问题。虽然这些问题现在依然存在,但绝对没有以前那么多。如今的编程比那时有趣得多。我们真正专注于编程的乐趣,比如快速构建事物的能力和个人掌控感,这些都得到了极大增强。因此,我认为对于从事软件开发的人来说,这是一个非常有趣的时代。 我认为技能可能会发生变化,人们的品味和创造力将得到提升,模板文本编辑和一些细致的工作可能会减少,而这些在今天的程序员中是非常重要的。我相信这将会更加有趣。
莱克斯·弗里德曼(Lex Fridman)
但是我认为,我们需要更多的信息来做出准确的判断。
阿维德·伦纳马克(Arvid Lunnemark)
我同意这一点,并且非常期待能够进行改变。最近,我们计划对代码库进行一次较大的迁移。我们在 Node.js 中使用异步本地存储,但其性能不佳,因此我们希望迁移到使用上下文对象。这次迁移将影响整个代码库。我花了大约五天时间来处理这件事,即使在今天有 AI 工具的帮助下。我对未来感到非常兴奋,因为到那时,我只需展示几个例子,AI 就能将其应用到所有地方,并在遇到新情况时询问“哦,这是一个新例子,我该怎么做?”然后我展示具体的操作方法,这样整个过程大约只需 10 分钟。这样一来,你可以更快地进行迭代,而不必在一开始就花费大量时间思考和计划,因为成本太高。你可以先尝试一些东西,然后意识到“哦,这其实不是我想要的”,并立即进行更改。因此,我认为未来做程序员将会非常有趣。
阿曼·桑格(Aman Sanger)
是的,我非常赞同你提到的观点。在编程中,通常有两种常见的方法。一种是从一开始就仔细思考,精心规划最佳的实现方式,然后在有限的工程时间内完成。然而,我更喜欢直接开始编写代码,尝试一下,看看它的发展情况,然后快速迭代。这样做感觉更有趣。
莱克斯·弗里德曼(Lex Fridman)
能够通过语音生成模板真是太好了,这样你就可以专注于复杂的设计和微妙的设计决策。我觉得转换是一个很有趣的领域。大语言模型似乎基本上可以将一种编程语言翻译成另一种,或者在一般意义上转换我的成果,但这是在当前的阶段。所以,我的意思是,担忧在于,随着这些模型的不断进步,你所做的创造性决策可能会越来越少。是否会发展到一个阶段,你在自然语言作为设计工具的空间中操作,而自然语言成为主要的编程语言。我想我可以通过建议来问这个问题,比如如果现在有人对编程感兴趣,你认为他们应该学习什么?比如说,你们可能是从一些 Java 开始的,我记得,还有一些 PHP。
莱克斯·弗里德曼(Lex Fridman)
是这样的。我是说,最终我们都知道 JavaScript 会占据主导地位,而不是 TypeScript。JavaScript 就像编程语言的基础,将在全球范围内广泛使用,也许 PHP 也会占有一定的市场。这也引出了一个问题,我记得有位专家曾指出,某个比例的人口是极客。编程需要特定的心理和思维方式。感觉上,能够进行出色编程的人群可能会越来越多样化。
阿曼·桑格(Aman Sanger)
我认为,不同的人出于不同的原因进行编程,但真正优秀的程序员往往是那些真正热爱编程的人。 比如,我们团队中有些人在下班回家后,会打开电脑,整晚投入到自己的编程项目中。他们常常说,哦,我编程编到了凌晨三点。当他们感到难过时,会说,我真的需要编程。我觉得,这种对编程的痴迷和热爱造就了真正优秀的程序员。这些人会真正深入了解事物的工作原理。
阿维德·伦纳马克(Arvid Lunnemark)
这不仅仅是简单地按下 Tab 键。虽然这样说很容易,但实际上,当你按下 Tab 键时,你是在不断地表达你的意图。在这个过程中,有时你会忽略某些内容,有时你会多输入几个字符,这就是你塑造所创建事物的方式。我认为编程将更多地转变为关于你想要创造什么的过程。
苏亚莱·阿西夫(Sualeh Asif)
这可以说是一种更高效的交流方式。与其仅仅依靠打字这种低效的方式,不如说与计算机的交流变得越来越高效,能够更好地传达意图。
莱克斯·弗里德曼(Lex Fridman)
这与您的《工程天才》宣言有关。“我们是一家应用研究实验室,专注于构建卓越且高效的人机协作 AI 系统。首先谈到这种人机结合,我们正在打造未来的工程师,即人机协作的 AI 程序员。”这种混合型工程师的效率将比任何单一工程师高出一个数量级。
他们将能够轻松掌控自己的代码库,而无需进行机械化的按键操作。他们将在最复杂的系统中以极快的决策速度进行迭代。通过结合 AI 和人类的创造力,他们将超越最优秀的纯 AI 系统。“我们是一群研究人员和工程师,致力于开发软件和模型,以在实际应用中进行创新。我们的工作已经改善了数十万程序员的生活,并且在此过程中至少让编程变得更加有趣。”感谢您今天的交流。