本次访谈由有名播客主持人 Lex Fridman 主持，访谈工具是 Cursor 团队的创始成员，包括 Michael Truell、Sualeh Asif、Arvid Lunnemark 和 Aman Sanger。访谈的主题环绕 AI 编程工具的未来展开，特殊是与 GitHub 整合可能带来的影响。自成立以来，Cursor 团队在 AI 赞助编程领域取得了显著进展，开拓出了一系列标志性项目，旨在提升开拓者的事情效率。目前，Cursor 不仅专注于优化编程工具，还广泛涉足与大措辞模型的集成，力求在编程环境中实现更高的自动化和智能化。在访谈中，团队成员详细谈论了 AI 在编程中的运用前景，以及如何通过技能创新来应对未来的寻衅。由于内容较长，本日发布采访的上半部分。
视频加载中...
Cursor 团队的核心不雅观点包括：
以下是本期播客内容的完全翻译，我们作了不改变原意的删减。
Cursor 像一个快速反应的同事
莱克斯·弗里德曼（Lex Fridman）
以下是与 Cursor 团队创始成员 Michael Truell， Sualeh Asif， Arvid Lunnemark， 和 Aman Sanger 的对话。Cursor 是一个基于 VS Code 的代码编辑器，增加了许多强大的 AI 赞助编码功能，吸引了编程和 AI 社区的广泛关注和激情亲切。因此，我认为这是一个深入磋商 AI 在编程中角色的绝佳机会。这次对话不仅涉及一个代码编辑器，还谈论了编程的未来，以及人类与 AI 在设计和工程繁芜系统中的互助前景。这是 Lex Fridman 播客。首先，一个主要的问题：代码编辑器的意义是什么？
迈克尔·特鲁尔（Michael Truell）
代码编辑器紧张是用于构建软件的工具。长期以来，这意味着在编程措辞环境中进行文本编辑。对付非程序员来说，代码编辑器可以被视为程序员专用的高等笔墨处理器。之以是称为高等，是由于代码具有繁芜的构造。因此，这种“笔墨处理器”——代码编辑器，可以实现许多普通笔墨处理器无法做到的功能。这包括语法高亮以便快速浏览代码、支持在代码库中像利用超链接一样导航、查看代码定义，以及进行基本缺点检讨以捕捉缺点。传统上，这便是代码编辑器的功能。我认为，随着软件构建办法的变革，代码编辑器将在未来十年内发生显著变革。
莱克斯·弗里德曼（Lex Fridman）
我认为代码编辑器也该当充满意见意义。
阿维德·伦纳马克（Arvid Lunnemark）
在我们决定要构建什么时，快速行动是一个常被低估的主要成分。我们常常考试测验和实验，构建许多东西，但终极可能由于不足有趣而放弃。因此，快速行动在创造有趣事物中起着关键浸染。速率每每能带来更好的结果。
莱克斯·弗里德曼（Lex Fridman）
这句话该当印在 T 恤上。
迈克尔·特鲁尔（Michael Truell）
从根本上来说，我认为吸引许多人学习编程的缘故原由之一是其惊人的快速实现能力。在其他领域，你可能会由于资源、能力的限定，乃至须要组织大型团队而受到阻碍。而编程的神奇之处在于，只需你和打算机，就可以快速开拓出有趣的项目。
莱克斯·弗里德曼（Lex Fridman）
对付不太理解的人来说，Cursor 是一个非常出色的新编辑器，它是从 VS Code 分支出来的。 理解一下你们各自的编辑器利用进程会很有趣。我想你们中许多人可能都是 VS Code 和 CoPilot 的虔诚粉丝。你们是如何开始利用 VS Code 的，又是如何转而利用 Cursor 的？
阿曼·桑格（Aman Sanger）
我想我们很多人，实际上是所有人，最初都是从用户的角度出发，纯挚地利用工具。是的，不须要其他工具，只是在终端中作为用户利用。至少对我来说，大约在 2021 年，当 GitHub Copilot 推出时，我真的很想考试测验一下。以是我选择了 VS Code，由于它是唯一可以利用 Copilot 的平台和代码编辑器。只管我非常喜好利用其他工具，但在 VS Code 上利用 Copilot 的体验足够好，让我决定切换。因此，这种情形一贯持续到我们开始开拓 Cursor 之前。
莱克斯·弗里德曼（Lex Fridman）
大概我们该当阐明一下 Copilot 的功能。它就像一个非常出色的自动完成功能。当你开始写作时，它会建议一到三行来补充你的内容。这种体验很有趣，就像和一个亲密的朋友在一起，他能帮你把话说完。当它表现出色时，会让人感到一种亲密感。大概“亲密”这个词不足准确，但会有一种“它懂我”的酷感。当然，当它不理解你时，会带来一些不愉快的觉得，因此会产生冲突。但我认为对很多人来说，那种“它懂我”的觉得会赛过“它不懂我”的觉得。
阿维德·伦纳马克（Arvid Lunnemark）
我认为，实际上利用 Copilot 的一个被低估的优点是，纵然它出错了，也只是有点烦人，并不算太糟糕。由于你只需再输入一个字符，它可能就能理解你的意思。以是纵然出错，也不算严重。
苏亚莱·阿西夫（Sualeh Asif）
对我来说，另一个被低估的方面是，Copilot 是第一个真正面向消费者的 AI 产品，即第一个由措辞模型驱动的消费者产品。
莱克斯·弗里德曼（Lex Fridman）
Copilot 有点像 LLM 的第一个杀手级运用。
迈克尔·特鲁尔（Michael Truell）
测试版本是在 2021 年发布的。
莱克斯·弗里德曼（Lex Fridman）
Cursor 起源的故事是什么？
迈克尔·特鲁尔（Michael Truell）
大约在 2020 年，OpenAI 发布了一篇关于 Scaling Law 的论文。这是一个关键时候，表明该领域的进展是明确且可预测的。纵然没有新的想法，只要有更多的打算能力和数据，彷佛也能显著提升这些模型的性能。
莱克斯·弗里德曼（Lex Fridman）
顺便提一下，我们可能会花三到四个小时谈论 Scaling Law 。大略来说，这是一篇论文及其干系的一组论文和一系列想法，旨在解释在机器学习领域中，随着模型规模和数据规模的增大，模型性能可能会得到提升。
苏亚莱·阿西夫（Sualeh Asif）
学习能力变得更强大、更精良，在预测方面表现更加出色。
莱克斯·弗里德曼（Lex Fridman）
那是另一个话题。好的。
迈克尔·特鲁尔（Michael Truell）
当时，我们中的一些人进行了许多关于未来发展以及不同知识事情领域如何通过技能进步得到改进的观点性谈论。随后，有几个时候让那些预测中的理论收益变得非常详细，仿佛是一种体验：你实际上可以在不攻读博士学位的情形下从事有用的 AI 事情，觉得现在有一整套可以构建的系统非常实用。
我们稍早提到的第一个时候是体验早期的 Copilot 测试版，那真是令人惊叹和神奇。接下来，统统开始领悟的重大时候是得到 GPT-4 的早期访问权限。大约在 2022 年底，我们开始试验这个模型，能力的提升让人感到非常巨大。
在此之前，我们一贯在进行几个不同的项目。由于 Copilot 和我们对技能的兴趣，我们一贯在为程序员开拓非常详细的工具。例如，我们为金融专业人士构建工具，或者考试测验用这些模型进行静态剖析。然后，GPT4 的进步让我们之前预测的理论收益变得详细，觉得在那个韶光点可以立即构建更多东西。
如果我们保持同等，真的觉得这不仅仅是一个点办理方案的问题。这将是所有编程都将通过这些模型进行。觉得这须要一种不同类型的编程环境和编程办法。因此，我们开始构建那种更大的愿景。
苏亚莱·阿西夫（Sualeh Asif）
事情大致是这样的。我清楚地记得一件事：我的室友曾在国际数学奥林匹克竞赛（IMO）中得到金牌。在美国，有一项名为 PUTNAM 的比赛，可以视作 IMO 的大学版，是一项非常精良的数学竞赛。我记得在 2022 年 6 月，Shengtong 和 Aman 打赌，到 2024 年 6 月或 7 月，你是否会通过某个模型在 IMO 中赢得金牌。
迈克尔·特鲁尔（Michael Truell）
Aman 对这些东西非常热衷。在此之前，他有一件印有比例图表和数学公式的 T 恤，常常穿着到处走。
莱克斯·弗里德曼（Lex Fridman）
你是体验到了通用人工智能（AGI）的能力，还是感想熏染到了它的规模？
阿曼·桑格（Aman Sanger）
我清楚地记得有一次与 Michael 的对话，在那之前我从未深入批驳性地思考过扩展的原则。他问了一个问题：为什么扩展不是你所须要的统统？或者为什么扩展不会带来巨大的进步？我想我经历了类似悲哀五阶段的过程：愤怒、否认，末了经由思考，接管。从那往后，我对进步一贯抱有希望和乐不雅观态度。我想补充一点，这也取决于在哪些领域可以看到进步。比如数学便是一个很好的领域，尤其是形式数学，由于你可以通过验证结果的精确性来得到极好的旗子暗记。因此，这意味着像强化学习（RL）这样的东西可以非常有效地运作。我认为你可以拥有在数学上非常超人的系统，但技能上仍旧没有通用人工智能（AGI）。
莱克斯·弗里德曼（Lex Fridman）
我们可以一贯评论辩论 Cursor 吗？Cursor 是什么呢？它是 VS Code 的一个分支。长期以来，VS Code 一贯是最受欢迎的编辑器之一，险些所有人都对它爱不释手。大家纷纭离开了 Vim，我也离开了 DMAX，抱歉。VS Code 在某种程度上统一了开拓者社区。不雅观察这个领域的发展和扩展生态系统，AI 正在变得非常出色。因此，你意识到仅仅为 VS Code 编写一个扩展是不足的，由于扩展有很多限定。如果 AI 要连续进步，我们须要重新思考 AI 如何融入编辑过程。因此，你决定分叉 VS Code，并开始构建许多令人惊叹的功能。我们将能够谈论这些功能。那么，做出这个决定是什么觉得？由于有很多扩展，包括 VS Code 的 Copilot，都在做类似 AI 的事情。是什么匆匆使你决定直接分叉 VS Code 呢？
迈克尔·特鲁尔（Michael Truell）
开拓一个编辑器彷佛是显而易见的任务，至少对付我们想要实现的目标而言是如此。由于在我们开始开拓这个编辑器时，我们认为这些模型的能力会不断提升，从而彻底改变软件构建的办法。这不仅会带来巨大的生产力提升，还会引发根本性的变革。如果只是作为一个插件嵌入到现有的编码环境中，对代码编辑器的掌握将非常有限。我们希望打破这些限定，打造出最有用的工具。
莱克斯·弗里德曼（Lex Fridman）
那么，自然而然的问题是，VS Code 和 Copilot 是竞争对手。你们是如何在竞争中取胜的呢？这是否紧张依赖速率和功能的质量？
阿曼·桑格（Aman Sanger）
我认为这是一个非常有趣，乃至可能是独特的领域。回顾以往的科技浪潮，常日会有一个紧张事宜引发新公司的呈现。然而，在这个领域，每一年、每一个模型能力的提升都会带来新的功能和可能性，尤其是在编程方面。因此，我认为在 AI 编程中，纵然只领先几个月，乃至一年，都会让你的产品更具实用性。我认为一年后的某个产品该当让本日的产品显得过期。在微软公司，我们做了很多出色的事情，但我认为他们并不具备像初创公司那样持续创新和推动发展的有利条件。
莱克斯·弗里德曼（Lex Fridman）
快速实现某项功能。
阿曼·桑格（Aman Sanger）
推动干系事情，例如进行必要的研究实验，以真正提高能力的上限。
苏亚莱·阿西夫（Sualeh Asif）
我不太会从功能的角度去思考这个问题，而是从程序员能力的角度来考虑。正如你所知，新款 O1 模型已经发布，我相信未来还会有更多不同类型的模型涌现，比如更长的高下文，或者速率更快的模型。有很多猖獗的想法可以考试测验，希望个中有 10% 能变成一些很酷且有用的东西。我们希望人们能更早地得到这些创新。
换句话说，一个被低估的事实是，我们是在为自己制作这些东西。当我们开始开拓 Cursor 时，真的感到了一种挫败感。你知道，模型在不断进步，但 Copilot 的体验却没有改变。就像，天哪，这些人，天花板在不断升高，为什么他们不做一些新的东西？他们该当做一些新的东西。他们该当问，所有的 alpha 功能在哪里？根本没有 alpha 功能。我确信它卖得很好，也是一门好买卖，但觉得不对。我是那种真的想考试测验和利用新东西的人，但很长一段韶光内都没有新东西。
莱克斯·弗里德曼（Lex Fridman）
是的，这很有趣。我不清楚你是如何用措辞表达的，但当你将某个工具与协作编译进行比较时，不知为何，很快就会以为它有些过期。
阿维德·伦纳马克（Arvid Lunnemark）
我认为对我们非常有利的一点是，我们在一个统一的框架下进行开拓。我们不仅在开拓用户体验（UX）和模型的交互办法，同时也在提升模型的回答质量。我们在构建提示器、进行高下文检索以及演习模型方面都同步进行。我认为这种办法有助于让同一批人卖力全体体验的开拓过程。
苏亚莱·阿西夫（Sualeh Asif）
就彷佛卖力制作用户界面的人和卖力演习模型的人之间有大约 5.5 米的间隔。
阿曼·桑格（Aman Sanger）
常日是同一个人。
苏亚莱·阿西夫（Sualeh Asif）
纵然是同一个人，也常常会有不同的想法。因此，如果不进行互换和实验，就无法创造出那些看似不可能的事物。
莱克斯·弗里德曼（Lex Fridman）
正如你所说，你正在利用 Cursor 来编写 Cursor。那么，让我们来谈谈个中的一些功能，特殊是这个强大的自动补全功能。Tab 是如何事情的？它到底是什么？
迈克尔·特鲁尔（Michael Truell）
从整体来看，我认为目前 Cursor 在两个方面表现得相称出色。只管它还有其他功能，但紧张在以下两个方面帮助程序员。首先，它就像一个快速反应的同事在你身边，能够提前一步为你输入并预测你接下来的操作。最初的设计是作为一个精良的自动补全工具，预测你将要输入的内容。但这个观点可以更具年夜志，不仅仅是预测光标位置后的字符，而是预测你将要进行的全体修正、下一个差异以及你将要跳转到的地方。其次，它在某些情形下也非常善于帮助你超越 AI，从指令天生代码。在这两个方面，我们都投入了大量事情，以使编辑体验更加符合人体工学，同时让这些功能变得智能和快速。
苏亚莱·阿西夫（Sualeh Asif）
我们非常希望开拓出一个能够为我们编辑代码的模型。在成功拥有一个精良的代码编辑模型之前，我们进行了多次考试测验。拥有这个模型后，我们投入大量精力加快推理速率，以供应良好的用户体验。我们开始引入一种功能，正如 Michael 提到的，可以跳转到不同位置。这种跳转功能的灵感来自一种直觉：一旦你接管了一个编辑，接下来要去哪里该当是显而易见的。就像你做了这个变动，模型该当知道下一个要去的地方是第 18 行之后。
如果你是 vim 用户，你可能会用快捷键来跳转。但为什么要这样做呢？模型该当能够自动完成这个过程。因此，我们的想法是你只需按下 Tab 键，它就会跳到第 18 行之后，然后显示下一个编辑。你只需连续按 Tab 键。我们内部的寻衅是看看我们能让用户按多少次 Tab 键。从更抽象的角度来看，当编辑是零熵的，你已经表达了你的意图，编辑中没有新的信息来完成你的想法，但你仍旧须要输入一些字符让打算机理解你的意图。大概模型该当能够读懂你的意图，所有零熵的部分都该当被轻松处理掉。这有点抽象。
阿曼·桑格（Aman Sanger）
在不同领域不雅观察措辞模型的丢失时，有一个有趣的征象。我认为代码的每字节比特数（即字符归一化丢失）常日比自然措辞要低。这意味着总体而言，代码中的许多标记和字符是高度可预测的。而且，当你不仅仅考试测验自动补全代码，而是预测用户在编辑现有代码时接下来会做什么时，这种征象会更加明显。因此，Cursor Tab 的浸染是：在意图已经基本明确的情形下，肃清编辑器中所有低熵操作。让我们直接跳过这些步骤，连续向前推进。
莱克斯·弗里德曼（Lex Fridman）
关于如何进行 Cursor 下一步的预测，有哪些直不雅观的理解和技能细节？我认为这对人们来说并不随意马虎理解。
阿曼·桑格（Aman Sanger）
我可以谈谈如何让这些技能发挥浸染的一些细节。由于这些技能的延迟非常低，因此须要在这个任务上演习小模型，并且它们对预添补标记的需求非常高。这意味着它们须要很长的提示词，会看到大量代码，但实际天生的标记并不多。因此，利用稀疏模型，即 MOE 模型，是一个完美的选择。这是我们取得的一个打破，显著提高了长高下文的性能。另一个打破是我们开拓的一种变体预测解码技能，称为预测编辑。 我认为这两个方面是确保其高质量和快速性能的主要成分。
莱克斯·弗里德曼（Lex Fridman）
缓存的输入数据量很大，但输出数据量很小。你能谈谈如何让缓存更有效地事情吗？
阿曼·桑格（Aman Sanger）
缓存在处理大量输入标记时起着重要浸染。每当你在某一行中输入一个字符时，模型须要对所有传入的标记重新运行。这不仅会显著增加延迟，还可能因负载问题对 GPU 造成危害。因此，你须要设计模型的提示，以优化缓存的利用。此外，还须要在不同要求间重用键值缓存，以减少事情量和打算量。
莱克斯·弗里德曼（Lex Fridman）
Tab 在不久的将来该当能够实现的功能包括：天生代码、自动补全、多行代码编辑。此外，它还可以在同一文件内跳转到不同位置，并在本地环境中实行这些操作。
苏亚莱·阿西夫（Sualeh Asif）
同样适用于跳转到不同的文件。因此，如果你在一个文件中进行编辑，可能须要切换到另一个文件来完成你的想法。它该当也会跳转到第二个文件。
阿维德·伦纳马克（Arvid Lunnemark）
全面概括就像是预测下一步操作。有时你须要在终端中运行一个命令，它该当能够根据你编写的代码供应建议。或者，当你须要实行某项操作但难以判断其精确性时，实际上可能须要更多的信息来学习。例如，你须要理解类型才能验证其精确性。因此，它或许该当勾引你到某个定义的位置，然后再返回，这样你就能得到进行下一步操作所需的所有知识。
迈克尔·特鲁尔（Michael Truell）
编程有时是一门神奇的学科。在某些情形下，你接下来五分钟要做的事情可以从你最近完成的事情中预测出来。那么，是否可以达到这样一种程度：在接下来的五分钟里，你可以选择不参与，而让系统自动勾引你完成，或者你可以看到下一步要做的事情，并感到满意，就像我们在进行这些重大变革时，只需轻轻按下 Tab 键即可。
Cursor 的代码差异
莱克斯·弗里德曼（Lex Fridman）
说到这一点，我该当提到，Cursor 有一个非常酷且显著的特点，那便是它具备完全的差异显示功能。模型会用赤色和绿色标记代码的修正建议。在谈天窗口中，你可以查看并运用这些建议，系统会显示出差异，你可以选择接管这些修正。那么，或许你可以谈谈这个方向的干系内容？
苏亚莱·阿西夫（Sualeh Asif）
我们可能会有四到五种不同类型的差异。因此，我们已经对自动天生的差异进行了优化，形成了一种不同的差异视图。当你审查较大代码块时，情形又有所不同。我们还在考试测验优化另一种差异处理办法，以便在处理多个不同文件时利用。总体而言，自动天生的差异该当非常易于阅读。实际上，在所有情形下都该当易于阅读。但在自动天生差异时，你的把稳力汇合中在一个区域，人类无法同时关注多个区域。
莱克斯·弗里德曼（Lex Fridman）
以是，你是在评论辩论与界面干系的内容吗？
苏亚莱·阿西夫（Sualeh Asif）
在界面设计中，目前侧边栏中有一个框。如果考试测验在某些地方修正代码，比如删除或添加代码，系统会考试测验在侧边栏显示该框。
阿曼·桑格（Aman Sanger）
如果你访问 cursor.com 网站，可能会看到我们正在谈论的内容。
苏亚莱·阿西夫（Sualeh Asif）
为了让那个框正常事情，我们大概考试测验了三到四次。最初的设计是一个蓝色的交叉标记。在它成为侧边框之前，它曾以类似 Google 文档的风格显示待删除的代码，带有删除线和新代码，这非常让人分心。我们考试测验了多种方法，比如删除和用赤色高亮显示。接下来的迭代比较有趣：在 Mac 上按住 option 键时，会高亮显示一段代码，提示可能有变革。在这个例子中，输入和数值会变成蓝色，提示 AI 有建议。它不会直接显示，而是暗示有建议。如果你想查看，按住 option 键即可看到新的建议；松开 option 键则返回原始代码。
莱克斯·弗里德曼（Lex Fridman）
顺便说一下，这已经相称不错了。不过，你须要按下 option 按键。我虽然不是 Mac 用户，但我明白你的意思。
苏亚莱·阿西夫（Sualeh Asif）
这是一个不太直不雅观的例子，我认为这正是问题的关键。
阿曼·桑格（Aman Sanger）
此外，这也可能不是终极的版本。
阿维德·伦纳马克（Arvid Lunnemark）
我个人对在这个领域进行大量改进感到非常愉快。我们常称之为代码审查问题，这些差异在小规模编辑时非常有用，但在大规模编辑或涉及多个文件时，审查这些差异实际上有些困难。因此，我们有几个不同的想法。例如，我们认为差异的某些部分非常主要，包含大量信息，而其他部分则信息量较低，可能是重复内容。因此，可以考虑突出显示主要部分，并将不太主要的部分灰显。或者，可以利用一个模型来检讨差异，创造可能存在的缺点，并用小红波浪线标记出来，提示用户须要审查这部分差异。我认为这些想法非常令人愉快。
莱克斯·弗里德曼（Lex Fridman）
确实，这是一个非常有趣的用户体验设计领域。基本上，你是在考试测验勾引程序员只阅读他们须要的内容。只管即便做到最好。
阿维德·伦纳马克（Arvid Lunnemark）
你希望有一个智能模型来完成这项任务。目前的算法就像普通的算法，并不具备智能。虽然在设计这些算法时利用了智能思维，但算法本身并不具备智能。无论它处理的是哪种任务，你都希望模型能够完成这个任务。因此，我认为须要进一步完善和优化现有的算法，以便更好地知足智能化的需求。
苏亚莱·阿西夫（Sualeh Asif）
我认为一样平常的问题是，这些模型会变得越来越聪明。随着模型智能的提升，它们能够提出的建媾和变革也会越来越繁芜。因此，人类须要进行更多的验证事情，这变得越来越困难。就像你须要帮助这些模型一样。是的，我不想把所有韶光都花在审核上。很好。
莱克斯·弗里德曼（Lex Fridman）
你能详细解释一下多个文件之间的差异吗？
阿曼·桑格（Aman Sanger）
也便是说，Github 试图通过代码审查来办理这个问题。在进行代码审查时，你须要检讨多个文件中的多项变动。但正如 Arvid 之前所说，我认为你可以做得比代码审查更好。代码审查实在有些不尽如人意。你花费大量韶光试图理解那些对你来说相称陌生的代码，但常日并不能真正创造很多缺点。
我认为你可以通过利用大型措辞模型显著改进这种审查体验。 例如，利用一些技巧来勾引你关注那些真正主要的部分。我还认为，如果代码是由大型措辞模型天生的，而不是由人类开拓者天生的，那么代码审查的体验该当是为审查者和代码天生者设计的。在代码天生者是措辞模型的情形下，你不必过于关注他们的体验。你可以环绕审查者设计全体过程，使审查者的事情尽可能有趣、大略和高效。我认为这便是仅仅试图让这些事情看起来像代码审查的问题所在。我认为你可以更加富有创造性，拓展可能性。
阿维德·伦纳马克（Arvid Lunnemark）
我认为顺序非常主要。常日，在审查一个 PR（Pull Request）时，你会按照文件列表从上到下进行检讨。然而，实际上你可能希望先理解某个逻辑上更早涌现的部分，然后再去理解后续部分，而不必自己去理清这些顺序。你希望有一个模型来帮助你完成这个过程。
莱克斯·弗里德曼（Lex Fridman）
目标是让创作过程越来越靠近自然措辞，而不依赖实际操作。
阿维德·伦纳马克（Arvid Lunnemark）
我认为编程有时并不完备依赖自然措辞。比如，当我和 Sualeh 进行结对编程时，他在操作键盘。当我主导时，我会对 Sualeh 说，帮我实现这个函数，这样是可行的。但有时，向 Sualeh 阐明我要他做什么实在太麻烦了，以是我会接过键盘，给他展示一些示例代码，然后他就明白了。这是最大略的沟通办法。我认为这对 AI 来说也是一样的。
有时，与 AI 沟通的最大略办法是给出一个示例，然后它就能在其他地方实行任务。或者说，如果你在制作一个网站，最大略的办法不是见告 AI 该当做什么，而是通过拖动或绘制来展示。大概终极我们会发展到脑机接口等技能，能够理解你的想法。以是我认为自然措辞会有它的用武之地，但绝对不会是大多数人编程时的紧张办法。
机器学习的细节
莱克斯·弗里德曼（Lex Fridman）
我真的感想熏染到这个编辑器中蕴含的通用人工智能（AGI），觉得到其底层有很多机器学习技能在运作。能见告我一些支持其运作的机器学习技能吗？
阿曼·桑格（Aman Sanger）
在这个自定义模型的凑集中，Cursor 发挥了主要浸染。我们演习这些模型，与那些在繁芜推理任务中表现出色的前沿模型一起利用。例如，Cursor 功能便是一个很好的例子，展示了如何定制化模型，使其表现乃至超过前沿模型。如果你不雅观察这些模型在我们设定的其他领域任务中的表现，会创造自定义模型虽然有些出人意料，但确实是必要的，并且效果显著。
前沿模型在为代码制订操持和天生大致草图方面表现不错，但要创建详细的代码对它们来说相称困难。比如，当你考试测验用 Sonnet 或其他前沿模型来完成这项任务时，它们在处理一些大略问题时会出错，比如在超大文件中计算行号。因此，我们的做法是让模型先勾勒出一个粗略的代码块，指示须要进行的变动，然后演习一个模型来运用这些变动。
莱克斯·弗里德曼（Lex Fridman）
在这个文件中，我们可以说，运用程序就像一个模型，它会查看你的代码，并为你供应下一步的建议。对付人类而言，将两者结合彷佛很大略，但你可能会以为并非如此。
苏亚莱·阿西夫（Sualeh Asif）
与普遍意见相反，它并不是一种确定性的算法。
阿曼·桑格（Aman Sanger）
我认为你可能在其他地方见过浅复制的运用，它大多数情形下会出错，由于你可能试图进行某种精确匹配，但至少有 40%的韶光会失落败。这导致了糟糕的产品体验。我认为总体来说，模型会变得越来越智能。另一个运用的好处是，它许可你在利用最智能的模型时减少 tokens 的利用。这在天生所有这些 tokens 时既昂贵又耗时。
因此，你可以先给出一个非常粗略的草图，然后让大略模型去实现它，由于实现这个粗略的代码任务要随意马虎得多。我认为这种模式会持续下去，你可以利用越来越智能的模型进行方案，然后由不那么智能的模型处理实现细节。 大概你会有更强大的模型来处理更高层次的操持，这种操持可能会递归地运用于特定的运用模型。
苏亚莱·阿西夫（Sualeh Asif）
或许我们该当谈论如何提高它的速率。我认为这是一个永恒有趣的话题。
莱克斯·弗里德曼（Lex Fridman）
你是如何让它运行得更快的？
阿曼·桑格（Aman Sanger）
在提升速率方面，一个主要的组成部分是预测性编辑。预测性编辑是预测性编码的一种变体。为了更好地理解预测性编码，大略先容一下预测性解码：在措辞模型天生中，当受到内存限定时，同时处理多个 token 比逐个天生 token 要快。这就像在比较提示 token 与天生 token 的每秒处理速率时，提示 token 要快得多。因此，我们采取的方法是，不像传统的预测性解码那样利用一个非常小的模型来预测草稿 token，而是由更大的模型进行验证和代码编辑。
我们对现有代码的预期非常强烈，实际上便是完备相同的代码。你可以将原始代码块重新输入到模型中，模型大多数时候会赞许并输出相同的代码。这样，你可以并行处理所有这些行，只需用足够多的代码块进行并行操作。终极，你会达到一个不合点，模型将预测出与原始代码不同的文本。它会天生这些 token，然后在足够多的 token 与原始代码匹配后，我们会决定重新开始对代码块进行预测。实际上，这看起来就像是一个更快版本的正常代码编辑。就像是模型以更快的速率重写所有代码。我们可以利用与差异相同的接口，但它会更快地流式传输。
苏亚莱·阿西夫（Sualeh Asif）
一个上风是，在进行无线流媒体时，你可以在内容加载完成之前就开始不雅观看。因此，不会涌现永劫光的加载画面。
莱克斯·弗里德曼（Lex Fridman）
这样，人类可以在任务完成之前就开始阅读。
苏亚莱·阿西夫（Sualeh Asif）
我认为有趣的是，预测如今已成为一种相称普遍的征象。这不仅表示在措辞模型中，显然在 CPU 和数据库中也存在预测，险些无处不在。
综合表现最好的模型是 Sonnet
莱克斯·弗里德曼（Lex Fridman）
让我来回答这个看似荒谬的问题：在编程领域，哪个措辞模型更精良？是 Claude 还是 GPT？我相信答案要繁芜得多，由于每个方面彷佛都涉及不同的模型。
阿曼·桑格（Aman Sanger）
我认为没有哪个模型能够在我们认为主要的所有种别中全面超越其他模型。这些种别包括速率、编辑代码的能力、处理大量代码的能力、长高下文处理能力等，以及其他一些方面和编码能力。目前，我认为综合表现最好的模型是 Sonnet，这彷佛是一个普遍认可的不雅观点。 Sonnet 在推理方面非常出色，因此如果你给它一些非常难的编程口试题或者前导码问题，它可以表现得很好。然而，它在理解你的大存问图方面彷佛不如 Sona。
很多其他前沿模型给我的觉得是，它们并没有在特界说务上过拟合。我并不是说它们是在基准测试上演习的，但它们在基准测试中的表现相对来说非常好。因此，如果你在这些基准测试和与基准测试分布符合的任务中测试它们，它们会表现得非常好。但当你轻微超出这些范围时，我认为 Sonnet 是在保持相同能力方面表现最好的一个。就像在基准测试中表现出色一样，当你考试测验让它进行任何编码任务时，它也能保持同样的能力。
莱克斯·弗里德曼（Lex Fridman）
在评估这些模型时，正常的编程体验与基准测试所代表的内容之间有什么差异呢？你认为基准测试在哪些方面存在不敷之处？
苏亚莱·阿西夫（Sualeh Asif）
顺便说一下，这就像一个非常棘手的问题，也是一个至关主要的细节，涉及基准测试与我们实际编码之间的差异。我们进行的是实际编码，而不是口试风格的编码。在实际编码中，人们有时会用非正式的英语表达，比如说“按照我之前的做法”，或者“先做这件事，然后帮我做另一件事，末了制作这个 UI 元素”。很多事情都依赖于高下文。你须要真正理解人们的意图，然后去实现他们想要的，而不是像口试问题那样明确。口试问题常日非常明确，依赖于详细的规范，而人们的需求则不那么明确。
迈克尔·特鲁尔（Michael Truell）
存在一个问题，那便是基准测试中可以实际建模的内容与实际编程之间的差异。这有时很难概括，由于实际编程非常混乱，有时并不明确什么是精确的或禁绝确的。此外，由于公共基准测试的寻衅，这变得更加困难。这是由于公共基准测试有时会被过度优化，而且很难从这些模型中获取公共基准测试的数据。例如，一个最受欢迎的代理基准测试，SWE-bench，在这些根本模型的演习数据中被严重污染。因此，如果你让这些根本模型办理一个 SWE-bench 问题，而没有给它们供应代码库的高下文，它们可能会凭空想象出精确的文件路径和函数名称。因此，这些问题的普遍性也很棘手。
阿曼·桑格（Aman Sanger）
在这种情形下，模型可能会直接根据详细的问题或要求进行调度。实验室可能在数据清理方面表现更佳，或者他们已经在这方面做得很好，但他们不会省略仓库本身的实际演习数据。这些仓库包括一些最受欢迎的 Python 仓库，例如 SimPy。我不认为他们会限定模型在 SimPy 和其他这些盛行的 Python 仓库上的表现，以便在基准测试中得到真实的评估分数。
迈克尔·特鲁尔（Michael Truell）
我认为，考虑到稀缺性和基准测试，那些构建这些模型或利用这些模型来开拓系统的地方，实际上利用了一些有趣的指标来判断他们是否走在精确的方向上。在许多地方，人们会让人类与这些模型互动，并供应质量反馈。例如，一些根本模型公司专门有人卖力这方面的事情。此外，我们内部也会对这些模型进行定性评估，并在很大程度上依赖这些评估。
苏亚莱·阿西夫（Sualeh Asif）
这就像一种直觉。
莱克斯·弗里德曼（Lex Fridman）
你让人类进行感情调查。好吧，我的意思是，这便是我所做的事情。比如阅读在线论坛、Reddit 以及其他类似的平台，以是我不太确定如何精确理解人们的见地，由于他们会说一些像“我以为 Claude 或 GPT 变得不如以前聪明了”这样的话。我会说，我也有时有这样的觉得，但我想知道这是模型的问题还是我自己的问题。
阿曼·桑格（Aman Sanger）
是的，关于 Claude，我听说有一个有趣的情形，彷佛 AWS 供应了不同类型的芯片。我疑惑它们的数值打算能力可能与图形处理单元（GPU）略有不同。有人推测，性能低落可能与在 AWS Bedrock 上利用的模型量化版本有关，而不是在 Anthropic 上运行的版本。
莱克斯·弗里德曼（Lex Fridman）
我采访了一些持有阴谋论不雅观点的人，并很高兴能与他们对话。
苏亚莱·阿西夫（Sualeh Asif）
这并不像阴谋论那么繁芜。只是，人类的本性如此，当你进行大量浮点运算时，由于芯片的繁芜性，可能会涌现漏洞。很难强调这些漏洞有多难以避免。
莱克斯·弗里德曼（Lex Fridman）
在这统统中，一个好的提示能起到什么浸染呢？我们提到过，基准测试中的提示常日是非常构造化且精心设计的。那么，人类该当如何做才能最大化成功呢？在你博客中提到的提示设计中，人类的主要性是什么？
阿维德·伦纳马克（Arvid Lunnemark）
是的，我认为这取决于你利用的模型。不同的模型在处理提示时会有些许差异，并且对不同的提示反应也不同。不过，我认为最初的 GPT-4 和去年那些相对出色的模型对提示非常敏感，而且它们的高下文窗口非常小。因此，在我们的代码库中，有许多可能与提示干系的信息，比如文档、你添加的文件、对话历史等。这就带来了一个问题：在有限的空间里，你如何决定实际放入提示中的内容。纵然是本日的模型，纵然有较长的高下文，填满全体高下文窗口也会导致速率变慢，有时模型实际上会感到困惑，而且有些模型比其他模型更随意马虎困惑。
我们内部有一个别系叫做 Preempt，它在这方面对我们有一些帮助。我认为它是为我们拥有 8000 个 token 高下文窗口的时期而构建的。这有点类似于制作网站时，你希望它能在移动设备和桌面屏幕上都能正常事情，并且你有动态信息，而不是像设计印刷杂志那样，确切知道可以放置东西的位置。
但是，当你有一个网站或提示时，你有这些输入，然后你须要格式化它们以确保始终有效。纵然输入非常大，你可能也须要删减一些内容。因此，我们的想法是，好吧，让我们从中汲取一些灵感。设计网站的最佳方法是什么？我们最喜好的是 React 和声明式方法，你在 JavaScript 中利用 JSX，然后声明：“这便是我想要的，我认为这个优先级更高，或者这个比其他东西的 Z 指数更高”。
在网页设计中，有一个渲染引擎，比如 Chrome，而在我们的情形下是 Preempt 渲染器，它将所有内容放到页面上。当你声明一点时，它决定你想要什么，然后它弄清楚你想要什么。我们创造这非常有帮助，我认为它的角色随着韶光的推移有所变革，最初是为了适应这些小的高下文窗口。现在它非常有用，由于它帮助我们分割进入提示的数据和实际的渲染。因此，更随意马虎调试，由于你可以变动提示的渲染，然后在旧提示上进行测试，由于你有进入提示的原始数据。这样，你可以看到，我的变动是否确实改进了全体电子邮件。
莱克斯·弗里德曼（Lex Fridman）
以是，你是直接用 JSX 来提示的吗？
阿维德·伦纳马克（Arvid Lunnemark）
是的，这有点像 React。在这个别系中，有一些组件，比如文件组件，它会吸收光标位置作为输入。常日情形下，光标所在的行是文件中最主要的一行，由于你正在查看这一行。因此，你可以为各行设置优先级，光标所在的行优先级最高，离光标越远的行优先级越低。终极，在渲染时，系统司帐算出可以在光标行周围显示多少行。
莱克斯·弗里德曼（Lex Fridman）
这件事情真是太棒了。
阿曼·桑格（Aman Sanger）
你还可以做一些其他有趣的事情，比如，如果你在全体代码库中有大量的代码块，可以通过检索、嵌入和重新排序评分等方法，为这些代码块设定优先级。
莱克斯·弗里德曼（Lex Fridman）
那么，人类在提问时，是否也该当考试测验利用类似的方法呢？比如说，在问题中利用 JSX 是否有益，还是该当保持全体想法的灵巧和随意。
阿维德·伦纳马克（Arvid Lunnemark）
我认为我们的目标是让你做出最自然的反应。接下来，我们的任务是找出如何检索干系信息，以确保你的反应真正故意义。
莱克斯·弗里德曼（Lex Fridman）
这让我想起我和 Perplexity 的 Arvind 关于模糊性的谈论。他认为该当尽可能简化事情。是的，这确实很美好，但我认为可以对程序员提出更高的哀求。比如，如果你说为所欲为地干事，我的意思是，人类每每方向于选择大略的办理方案。这种方向与付出更多努力之间存在一种紧张关系，险些就像系统在施压或勉励你去深入思考。这里不是指语法构造，而是指你在问题中传达的思维深度。
阿曼·桑格（Aman Sanger）
我认为，纵然一个别系靠近完美，当你向模型提出要求时，常日意图的传达不敷以让模型明确知道该如何操作。为理解决这个问题，有几种方法。一种大略的方法是让模型直接讯问你：根据你的查询，我不愿定如何处理某些部分，你能否澄清一下？另一种方法是，如果查询中存在不愿定性，模型可以天生五到六种可能的结果，直接展示给你选择。
莱克斯·弗里德曼（Lex Fridman）
模型在决定是否进行对话时有多大的难度？与此比较，处理不愿定性又如何？我是否该当选择讯问更多信息以减少不愿定性？
苏亚莱·阿西夫（Sualeh Asif）
我们最近增加了一项功能，可以考试测验建议可能须要添加的文件。在你输入的过程中，我们能够识别不愿定性，并可能建议一些文件。例如，当你编写 API 时，我们可以根据你之前在同一文件中的提交内容，推测出哪些客户端和做事器的内容可能非常有用。技能难点在于如何在所有提交中识别出当条件醒下最主要的文件。
我们已经推出了一个初始版本，我相信我们可以让它更准确。只管这项功能仍处于实验阶段，但我们的想法是向你展示是否须要添加这个文件，以便模型能够帮助你编辑这些文件。由于如果你正在开拓 API，你也该当编辑利用该 API 的客户端和做事器，以及办理该 API 的其他部分。在你编写提示的阶段，乃至在按下回车键之前，我们可能就能帮助办理一些不愿定性。
编程的很多代价在于迭代
莱克斯·弗里德曼（Lex Fridman）
你在多大程度上利用代理方法？代理的浸染有多大？
阿维德·伦纳马克（Arvid Lunnemark）
我们认为智能代理非常酷。智能代理就像是人类的存在，让你在看到演示时感想熏染到它的行为就像人类一样，更靠近 API，这真的很酷。目前智能代理在很多方面还不是特殊有用。不过，我们正在靠近它们真正有用的时候。因此，在某些类型的任务中，拥有一个智能代理会非常好。比如说，如果我们碰着一个 bug，有时候你不能在谈天输入框中利用 Command C 和 Command V，这是一个非常明确的任务。我只想大略地说，这个功能不事情，请修复它。然后我希望有一个智能代理去处理它，一天后我回来查当作果。
莱克斯·弗里德曼（Lex Fridman）
这是否意味着它会找到精确的文件？
阿维德·伦纳马克（Arvid Lunnemark）
是的，它能够找到精确的文件。它会考试测验重现这个缺点，修复它，然后验证修复是否精确。这可能是一个须要很永劫光的过程。因此，我希望能够具备这样的能力。我认为在编程中，很多人相信代理会接管所有编程事情。但我不这么认为，由于编程的很多代价在于迭代。 你不一定想在一开始就明确指定某些东西，由于在看到初始版本之前，你可能并不知道自己真正想要什么。然后，你可以在此根本上进行迭代，供应更多信息。因此，对付很多编程事情，我认为实际上须要一个实时系统，能够立即给出初始版本，然后你可以非常快速地进行迭代。
莱克斯·弗里德曼（Lex Fridman）
Replica Agent 可以设置开拓环境、办理软件包问题、配置所有内容、建立数据库，乃至实际支配运用程序。这也是你一贯梦寐以求的功能吗？
阿维德·伦纳马克（Arvid Lunnemark）
我也是这样认为。我以为这对某些编程类型来说会非常酷。
莱克斯·弗里德曼（Lex Fridman）
Cursor 在选定例模内吗？
阿维德·伦纳马克（Arvid Lunnemark）
我们目前在这方面的事情并不生动，但我们确实希望让程序员的事情变得更加轻松和有趣。有些任务确实繁琐，须要多个步骤，你可能希望将这些任务委托给一个代理程序。而在事情过程中，有些任务实际上可以让代理程序在后台运行。比如说，当你处理一个同时涉及后端和前真个 PR（Pull Request）时，可以在处理前端部分时，让后台代理程序理解你的事情。这样，当你开始处理 PR 的后端部分时，就会有一些初始代码供你进一步开拓。这将会非常酷。
莱克斯·弗里德曼（Lex Fridman）
我们之前已经谈论过速率的问题，但我认为我们可以更深入地磋商技能细节，以使这个程序真正变得非常快速。在程序的各个方面，大多数操作都觉得非常迅速。正如我提到的，运用程序可能是最慢的部分。对我来说，这是一个须要重点关注的领域。
阿维德·伦纳马克（Arvid Lunnemark）
我们正在经历痛楚，并努力办理这个问题。
莱克斯·弗里德曼（Lex Fridman）
这意味着，当你感到某个过程，比如一两秒钟，显得有些慢时，实在是由于其他统统都非常快。那么，有没有一些技能手段可以用来加速这些模型呢？比如如何让谈天更快，或者让差异打算更快。有哪些方法可以立即想到呢？
阿曼·桑格（Aman Sanger）
我们可以谈论许多我们利用的策略，个中一个有趣的策略是缓存预热（Cache Warming）。在用户输入时，你可以提前利用一些高下文信息，由于这些信息在用户完成输入之前就已经可以获取。正如我们之前谈论的，重用 KV 缓存（Key-Value Cache）可以降落延迟和跨要求的本钱。因此，当用户开始输入时，你可以立即利用当前文件内容来预热缓存。这样，当用户按下回车键时，实际上须要预添补和打算的 token 非常少，从而显著降落 TTFT（首次天生韶光）。
阿曼·桑格（Aman Sanger）
KV 缓存是一种用于优化数据存取的技能。它通过在内存中缓存键值对，加速数据的读写操作。KV 缓存的事情事理类似于传统缓存系统：当运用程序要求数据时，首先检讨缓存中是否存在该数据。如果存在，则直接从缓存中返回，避免访问较慢的存储设备；如果不存在，则从存储设备中读取数据，并将其存入缓存，以便下次快速访问。通过这种办法，KV 缓存可以显著提高系统的性能和相应速率。
阿曼·桑格（Aman Sanger）
Transformer 的一个机制使其不仅能够独立处理每个标记，还能同时考虑之前的标记，这便是把稳力机制中键和值的浸染。常日，把稳力机制的事情办法是，在当前标记处天生一个查询，然后利用所有之前标记的键和值，这些是模型内部存储的所有之前标记的某种表示。在默认情形下，当处理序列数据时，模型必须对每个标记进行一次完全的前向通报，这涉及大量的矩阵乘法运算，非常缓慢。
然而，如果你已经完成了这些运算并将键和值存储在 GPU 中，那么当模型已经处理了末了 n 个标记后，如果现在须要预测第 n+1 个标记的输出，就不须要将前 n 个标记再次通过全体模型，由于模型已经拥有了所有这些键和值。因此，你只须要对末了一个标记进行前向通报。在进行把稳力打算时，你会重用那些已经打算出的键和值，这是 Transformer 唯一的顺序依赖部分。
莱克斯·弗里德曼（Lex Fridman）
是否存在更高等别的缓存，例如针对提示词或相似内容的缓存？
阿曼·桑格（Aman Sanger）
有一种有趣的缓存办法可以用于 Cursor Tab，即通过预测用户会接管某个建议来提前准备下一个要求。这种方法结合了预测和缓存，由于你是在预测用户会接管建议，从而缓存了这个建议。当用户按下 Tab 键时，下一个建议就会立即为他们准备好。这是一种奥妙的启示式方法或技巧，利用了更高等别的缓存，让用户感想熏染到速率的提升。
苏亚莱·阿西夫（Sualeh Asif）
如果你能缩小 KV 缓存的大小，个中一个好处是可以进行更多的预测。你可以预测出 10 个可能有用的选项，这样用户点击个中一个的概率会远高于只展示一个选项的概率。用户可能会输入另一个字符，这样我们就能在缓存中找到其他干系内容。因此，这里有很多技巧，这种征象在强化学习（RL）中也非常有用。大概模型的单个样本效果不佳，但如果你预测 10 个不同的选项，个中一个精确的概率就会大大提高。这些是被动触发成分，RL 的一部分事情便是利用这种被动触创造象进行多种预测。
可以这样理解，模型内部对哪个关键点是精确的或哪个选项是人类想要的存在不愿定性。当我们利用 RL 标记模型时，我们所做的事情之一便是在模型天生的 100 个不同建议中预测哪个更适宜人类，哪个是人类更喜好的。大概模型可以预测得很远，大概只能预测一点，或者在中间某个地方。然后你可以对人类更喜好的选项给予褒奖，对不喜好的选项进行惩罚，从而演习模型输出人类更喜好的建议。你可以利用这些非常有用的 RL 循环来优化模型的表现。Aman 可能可以对此进行更详细的阐明。
阿曼·桑格（Aman Sanger）
这与速率有些不同，但从技能上讲，可以将其联系起来。由于如果你对较小的模型进行强化学习（RL），并得到与较大模型相同的性能，就像 Sualeh 提到的关于缩减知识库（KB）缓存大小的一些内容。此外，还有其他技能也能显著提高速率。大约两年前，人们紧张利用多头把稳力机制。我认为现在已经转向更高效的把稳力机制，比如分组查询把稳力或多查询把稳力。这对付在较大批量处理中更快天生标记非常有帮助。
有趣的是，这对首次标记预添补速率没有影响，主要的是天生标记时的速率。为什么呢？由于在天生标记时，速率的限定更多来自于长高下文和大批量处理时读取缓存键和值的速率，而不是高度并行化的矩阵乘法。因此，这涉及到内存带宽的限定。
我们如何加快速率呢？可以考试测验压缩这些键和值的大小。多查询把稳力是个中最为激进的一种，常日在多头把稳力中，你会有多个所谓的把稳力头和查询头，而多查询把稳力只保留查询头，去掉所有的键值头，只剩下一种键值头，别的都是查询头。而在分组查询中，你保留所有的查询头，但键和值的头数较少，不过不会减少到只有一个。总之，重点在于减少 KB 缓存的大小。
阿曼·桑格（Aman Sanger）
是的，这涉及多个潜在变量，情形轻微繁芜一些。其事情办法是将所有把稳力头的键和值整体转换为一个隐向量表示，然后在推理时进行解码。
苏亚莱·阿西夫（Sualeh Asif）
DeepSeek 公司的算法相称有趣。其核心思想可能与 MQA 及其他方法类似，即通过减少键值敌人（KV heads）的数量来实现上风。虽然数量减少了，但理论上你可能仍须要许多不同的键和值，并希望每个键和值都是独特的。减少大小的一种方法是为所有键和值保留一个大的共享向量，同时为每个单独的标记保留较小的向量。
这样在操作时，你只需存储较小的部分，作为某种低秩近似。低秩近似的好处在于，当你须要打算终极结果时，考虑到内存带宽，你仍旧可以利用一些打算能力。因此，如果你能扩展潜在向量，这样做效率更高，由于你减少了，比如说，可能是减少了 30Q 或其他类似的向量大小。
阿曼·桑格（Aman Sanger）
是的，将键和值分开进行成对匹配查询，可能会带来一些灵巧性，而不是将所有内容合并为一个整体，至少在这种交互中是这样的。
莱克斯·弗里德曼（Lex Fridman）
这与内存限定有关。那么，这终极如何影响用户体验呢？
阿曼·桑格（Aman Sanger）
现在，你可以将缓存设置得更大，由于为键值缓存分配的空间减少了，这样可以更积极地缓存更多内容。因此，你会得到更多的缓存命中，从而减少延迟的令牌天生韶光，正如我们之前所述。此外，当你开始处理越来越多的要乞降更大的批处理时，天生令牌的速率不会显著低落。
苏亚莱·阿西夫（Sualeh Asif）
它是否大概可你在某些情形下扩展提示？
阿曼·桑格（Aman Sanger）
基本上，你的 KV 缓存大小是所有提示信息大小与并行处理数量的乘积。因此，你可以增加这两个参数中的任意一个，即批处理大小或提示信息的大小，而不会降落天生令牌过程的延迟。
莱克斯·弗里德曼（Lex Fridman）
Arvid，你写了一篇关于影子事情环境的博客文章。是的，你在后台进行代码迭代。那么，详细发生了什么？
阿维德·伦纳马克（Arvid Lunnemark）
为了更清晰地解释，我们希望在后台进行许多操作，并考试测验多种不同的方法。目前，除了缓存预热或探求得当的高下文来输入命令行提示外，我们并没有进行太多其他操作。我们的想法是，如果能在后台进行打算，就可以帮助用户在更长的韶光范围内做出决策，而不仅仅是预测接下来的几行代码，而是预测接下来 10 分钟内的操作。通过在后台进行这些操作，可以投入更多的打算资源。
因此，我们实现并在内部用于实验的影子事情区的观点是，实际上要利用后台操作，你须要某种反馈旗子暗记返回给模型，否则仅仅让模型思考更永劫光并不能提高性能。例如，0 和 1 便是一个很好的例子。但提高性能的另一种方法是让模型进行迭代并得到反馈。对付程序员来说，一个非常主要的反馈来源是措辞做事器。
措辞做事器存在于大多数编程措辞中，每种措辞都有一个独立的措辞做事器，它可以见告你，比如这里利用了缺点的类型，并给出错误提示。或者它可以让你跳转到定义，理解代码的构造。措辞做事器是由不同措辞的开拓者开拓的，比如 TypeScript 团队开拓的 TypeScript 措辞做事器，Rust 团队开拓的 Rust 措辞做事器，它们都通过措辞做事器协议与 VS Code 进行接口连接。这样，VS Code 不须要内置所有不同的措辞，而是可以利用现有的编译器根本举动步伐。
阿维德·伦纳马克（Arvid Lunnemark）
它用于代码检讨、跳转到定义以及查看代码中利用的类型信息。
莱克斯·弗里德曼（Lex Fridman）
也在做类型检讨。
阿维德·伦纳马克（Arvid Lunnemark）
在处理大型项目时，类型检讨和引用跳转功能是必不可少的。如果短缺这些功能，编写大型项目的代码将变得非常困难。
莱克斯·弗里德曼（Lex Fridman）
你能详细解释一下在 Cursor 中如何利用措辞做事器协议进行通信吗？
阿维德·伦纳马克（Arvid Lunnemark）
这个功能用于在 Cursor 向程序员展示信息，就像在 VS Code 中一样。接下来的想法是，你希望将相同的信息展示给 AI 模型，并且希望以一种不影响用户的办法进行，由于你希望在后台完成这项事情。因此，这个事情空间的想法是，我们可以天生一个隐蔽的窗口。你可以设置一个选项，使窗口隐蔽。虽然窗口存在，但实际上你看不到它。在这个窗口内，AI 代理可以自由地修正代码，只要不保存，由于它仍旧在同一个文件夹中，然后可以从代码审核对象中获取反馈，查看定义，并对代码进行迭代。
莱克斯·弗里德曼（Lex Fridman）
以是，这就像是在后台运行所有程序或任务，乃至可能还会实行代码，对吧？
阿维德·伦纳马克（Arvid Lunnemark）
这便是终极的版本。好的，这便是你想要的结果。许多博客文章实际上在谈论如何实现这一点，由于这确实有些繁芜。你希望它能在用户的机器上运行，以便准确反响用户的环境。在 Linux 系统上，有一个非常有趣的功能，可以实际镜像文件系统，让 AI 对文件进行变动。AI 认为它是在文件层面进行操作，但实际上这些操作是在内存中完成的。你可以通过创建一个内核扩展来实现这一点。然而，在 Mac 和 Windows 系统上，这就比较困难了。不过，这也是一个有趣的技能问题。
阿曼·桑格（Aman Sanger）
一个可能有些奥妙但有趣的想法是对保存操作进行限定。 基本上，你可以让大措辞模型掌握保存到磁盘的操作。这样，你操作的就不是那些已经安全保存到磁盘的文件的真实版本，而是操作之前的临时事情区和仅存在于内存中的未保存内容。这些内容仍旧会触发代码剖析工具（Linter）的缺点，你可以在个中编写代码。当你考试测验运行代码时，会有一个小警告提示存在限定，如果你考试测验并发操作，就须要从措辞做事器或临时事情区中解除锁定。
莱克斯·弗里德曼（Lex Fridman）
这是一个令人愉快的未来。顺便说一下，我喜好模型能够变动文件的功能。虽然这可能让人有些不安，但可以让代理实行一系列任务，然后第二天回来查当作果，就像不雅观察同事一样，真的很酷。
阿曼·桑格（Aman Sanger）
在可实行性方面，可能存在不同的实现办法。对付一些大略的任务，比如用户在编程时可以在几分钟内完成的事情，让程序在用户确当地机器上运行是合理的选择。而对付那些须要更永劫光的大规模任务，你可能希望在一个远程的沙盒环境中进行。这又引出了一个非常棘手的问题，即如何精确或大致地重现用户的环境，以便在远程沙盒中运行代码时达到与本地相同的效果。
苏亚莱·阿西夫（Sualeh Asif）
我很好奇，你希望代理程序在编码中扮演什么角色？是希望它们创造漏洞，还是实现新功能呢？你空想中的代理程序是什么样的？
莱克斯·弗里德曼（Lex Fridman）
顺便说一下，当我想到自动化时，我不仅仅想到编程。我想到的是运用领域，比如这个特定的播客和视频编辑。如果你看看 Adobe 的产品，很多功能都是由代码驱动的。虽然这些代码的文档很差，但你可以通过编程与 Premiere 进行交互。基本上，我在 YouTube 上进行的所有上传事情，包括翻译、配音等任务，都是通过编程实现的。因此，我设想自动化许多与编辑不直接干系的任务。这便是我所考虑的。在编程方面，我紧张关注的是缺点查找，比如多层次的缺点检测和逻辑缺点检测，而不是精神上的缺点，而是像履行方向上的大问题。
苏亚莱·阿西夫（Sualeh Asif）
这使得你能够在探求漏洞方面供应帮助。
阿曼·桑格（Aman Sanger）
是的，我的意思是，当这些模型仅仅通过大略提示来识别缺点时，它们在创造缺点方面的表现非常差，准确性很低。
阿维德·伦纳马克（Arvid Lunnemark）
即便是最聪明的模型，也可能会碰着无法办理的问题。
莱克斯·弗里德曼（Lex Fridman）
你会如何阐明这个问题？有没有更直不雅观的阐明方法？
阿曼·桑格（Aman Sanger）
我认为这些模型确实很好地反响了预演习数据的分布。虽然随着丢失函数值的降落，它们具备一定的泛化能力，但我认为丢失值还没有低到足以让它们完备泛化到我们利用这些模型的所有领域。它们在代码天生和问答系统方面表现得非常出色，比如处理代码、Github 上的内容，以及数万亿的标记和在 Stack Overflow 或 Github 问题上的问答。
因此，当你考试测验进入那些在线上不常见的领域时，比如预测下一个编辑的光标位置（给定到目前为止的编辑），模型的局限性就会显现出来。另一个很好的例子是缺点识别，由于实际上没有那么多关于实际检测真实缺点并提出修复方案的例子，模型在这方面确实面临困难。但我认为这是一个模型迁移能力的问题。 就像你可以从仅在代码上预演习的模型中得到出色的迁移性能一样，你会创造代码到缺点识别的泛化模型中也会有类似的效果，只须要轻微推动一下。
苏亚莱·阿西夫（Sualeh Asif）
首先，我认为他们对代码的理解非常出色。在预演习过程中，模型构建的表示险些可以肯定会在某个环节中意识到可能存在一些可疑的情形。实际上，这部分是由于人类能够很好地判断哪些缺点真正主要。关键不仅在于识别可疑之处，而在于判断其是无关紧要的，还是会导致做事器宕机的严重问题。部分缘故原由可能与文化知识有关，比如资深工程师之以是精良，是由于他们知道三年前有人写过一段非常可疑的代码，导致了做事器宕机。
相反，如果这是一个实验项目，那么涌现一些缺点是可以接管的，由于你只是想进行实验并感想熏染一下。如果模型在实验过程中变得非常滋扰，那就很糟糕。但如果你在为生产环境编写代码，比如在 Postgres 或 Linux 上编写数据库代码，像 Linus Torvalds 这样的有名开拓者，纵然在这种情形下也不能接管。对用户警觉程度的判断是非常主要的。
