We're sunsetting PodQuest on 2025-07-28. Thank you for your support!
Export Podcast Subscriptions
cover of episode Benchmarking AI Agents on Full-Stack Coding

Benchmarking AI Agents on Full-Stack Coding

2025/3/28
logo of podcast AI + a16z

AI + a16z

AI Deep Dive AI Chapters Transcript
People
M
Martin Casado
总合伙人,专注于人工智能投资和推动行业发展。
S
Sujay Jayakar
Topics
Martin Casado: 我认为许多AI代码生成工具的轨迹管理仍有待改进,编写困难的代码就像玩游戏,需要良好的启发式方法来指导过程。当前的AI代理在构建完整的全栈应用方面仍存在挑战,这需要进一步改进轨迹管理和启发式方法。 我最近使用Cloud 3.7时遇到了一些问题,它过于‘聪明’,导致代码修改难以回退。这说明在实际应用中,选择合适的模型版本非常重要,需要权衡模型的‘聪明程度’和代码的可维护性。 基准测试可以帮助理解不同平台的优缺点,但评估对于独立开发者更实用,评估需要开发者掌握一定的技巧。对于构建使用AI模型的应用程序的开发者来说,基准测试和评估都非常重要,评估可以帮助开发者更好地理解和改进其产品。AI应用程序需要进行评估,这往往被低估了,一个好的评估可以帮助开发者构建更好的产品。编写评估可以帮助开发者明确产品目标、解决方案和评估标准,并通过测试验证改进。 在使用AI模型进行代码生成时,模型的更新可能会导致评估需要重新编写,这给软件工程带来了挑战。模型的开发和训练过程缺乏透明度,导致模型更新时评估需要重新编写,这在一定程度上是模型开发方式造成的。大型语言模型的改进方向可能并非总是专注于解决核心问题。随着模型的改进和技术的成熟,模型更新对评估的影响可能会逐渐减小。 我经常使用AI进行代码编写,它能显著提高我的工作效率。 Sujay Jayakar: 构建完整的全栈应用对于目前的自主AI代理来说仍然不是易事,一些因素会影响其性能,例如强有力的防护措施、模型的代码编写能力以及良好的库选择和抽象。强有力的防护措施(例如快速反馈和明确的正确与错误界限)可以显著提高AI自主编码的性能。AI模型擅长编写代码,但不擅长评估RLS规则或解释SQL查询的运行原理。选择合适的库和抽象对于提高AI编码性能至关重要,要明确模型需要做什么,以及不需要做什么。 Full Stack Bench这个基准测试评估AI代理能否完成从前端到后端(包括数据库、API和订阅)的完整全栈应用构建任务。创建Full Stack Bench基准测试是因为现有基准测试无法充分评估AI代理在实际全栈应用开发中的性能。 在处理复杂问题时,AI代理可能由于上下文管理问题而出现不一致性。强有力的防护措施(例如类型安全)可以减少AI代理在代码生成过程中的不一致性。类型安全是减少AI代码生成中不一致性的有效方法。类型安全等防护措施可以帮助AI代理保持一致性,减少在探索解决方案过程中的偏差。运行时防护措施(例如易于测试的语言)也可以帮助管理AI代理的轨迹。 AI模型在调试和推理方面不如代码编写能力强,尤其是在处理React Hook规则或SQL的RLS规则时。大型语言模型的知识截止日期和预训练数据会限制其构建新抽象的能力,但它们可以通过上下文学习来改进其性能,但其知识和上下文学习能力在不同模型之间存在差异。价格较低的模型性能不如价格较高的模型,微调可以提高价格较低模型的性能,但对于业余爱好者来说可能操作复杂。Gemini模型在性价比方面表现出色。 Full Stack Bench基准测试主要关注的是能够集成多个组件(前端、API层、数据库)的大型多组件系统。在使用AI模型进行代码生成时,即使是同一模型,也会存在较大的差异,而类型安全等防护措施可以有效降低这种差异。高质量的评估对于AI应用程序开发至关重要,但目前公开的评估数量有限,许多公司将其视为商业机密。公开共享高质量的评估集可以促进AI应用程序开发领域的合作与进步。 在使用AI工具进行复杂任务时,需要关注模型的轨迹规划、进度管理和避免循环等问题。改进AI代码生成工具的性能,需要关注任务提示、工具选择和框架选择等方面。使用AI进行代码编写类似于与人类工程师合作,需要将任务分解成步骤,并确保在每个步骤都达到可提交的状态,以便在出现错误时能够回退。

Deep Dive

Chapters
The episode starts by discussing the challenges of trajectory management in AI coding, drawing parallels to AlphaGo and heuristic development in game playing. It highlights the difficulty of finding efficient paths to solutions and the need for robust heuristics.
  • Trajectory management in AI coding is underdeveloped.
  • Coding is like playing a game with a starting and ending position, but few clear paths between them.
  • Good heuristics are crucial but hard to develop for AI agents.

Shownotes Transcript

你知道,我甚至从强化学习的角度考虑这个问题,从 AlphaGo 和所有这些开始。在我看来,对于很多这样的事情来说,轨迹管理仍然相当不发达。我觉得编写一个难题实际上就像玩游戏一样,对吧?你有一个起始位置,你有一个结束位置,而且它们之间可能很少有明确的路线。拥有一个好的启发式方法实际上非常困难,对吧?这是我们一直教给人类的东西,对吧?我想,你怎么知道你应该提交

并将此作为指挥位置以取得进一步进展。我认为这两者的结合感觉像是启发式环境,其中存在这些明确的界限,周围有一些回旋余地,但不多。然后一旦你偏离了这条路线,你就完全……感谢收听 A16Z AI 播客。本期节目重点讨论了 A16Z 普通合伙人 Martine Cassato 和 Convex 联合创始人兼首席科学家 Sujay Jayakar 之间的精彩对话,内容正如标题所示。

对全栈编码任务进行 AI 代理基准测试。Sujay 讨论了为什么这很重要,以及他的团队为此开发的基准测试,两人还分享了他们对 AI 生成的代码的整体体验。您将听到所有这些内容,以及 Martine 在这些披露之后对 Sujay 的热情介绍。

提醒一下,请注意,此处的內容仅供参考,不应视为法律、商业、税务或投资建议,也不应用于评估任何投资或证券,并且并非针对 A16Z 基金的任何投资者或潜在投资者。更多详情,请访问 a16z.com/disclosures。CJ,非常感谢您加入我们的播客。

对于那些不认识的人来说,在我和许多其他人看来,Sujay 被认为是世界上顶尖的系统思想家。我这么说有点轻描淡写,但也有点不是。所以让我简单介绍一下他的背景。Sujay 曾是 Dropbox 的 Magic Pocket 团队成员。他们从 S3 一直到硬件都实现了。他是 Convex 的联合创始人,他花了大量时间思考 AI 生成的代码的影响

AI 生成的代码。所以我们将要讨论的是使用 AI 进行编码,以及对系统的影响等等。欢迎来到播客,CJ。

谢谢。感谢您的介绍。当然。只有一点点夸张。顺便说一句,我想非常清楚地说明一点。许多人确实认为你是世界上顶尖的系统思想家之一。因此,并非每个人都熟悉 Convex。它试图做的事情是人们几十年来一直在数据库领域讨论的事情。这几乎是一种海市蜃楼。所以也许可以简单介绍一下你在 Convex 上的工作,然后我们将转向 AI 方面的内容。

是的,当然。Convex 是一个反应式数据库,它是一个从头开始构建的数据库,旨在使应用程序开发尽可能容易。这有很多含义。但我认为起点是我们漫不经心地使用超过 30 年历史的数据库,而没有考虑它。我们对编程语言并没有这样做。我们对我们的库也没有这样做。

Convex 正如你所说,我们正在追逐这个海市蜃楼:如果你从第一性原理重新思考了一些事情,你能否使应用程序开发效率提高一个数量级甚至更高?例如,一切默认都是反应式的。

您根本不需要处理状态管理。一切都是端到端的类型安全的。是的,我的意思是,它拥有使现代应用程序集成和配置完全在代码中所需的所有组件。

那么,对于我们这些外行开发者来说,这意味着什么呢?我在很多项目中都使用 Convex。所以假设我正在用 JavaScript 编写一些 Web 应用程序。实际上,这意味着我只是使用我的 JavaScript,它会在 Convex 中运行。然后我得到了事务性、反应性和查询事物的能力。我不必求助于 SQL 和 SQL 的所有缺点来做到这一点。因此,您实际上最终只编写 JavaScript 就能获得事务性后端。是的。

公平吗?是的,完全正确。我的意思是,JavaScript 是世界上最流行的语言之一,它非常直观。为什么不能所有东西都在其中呢?Sujay 也是 AI Town 的主要开发者之一。实际上,AI Town 是由在我们团队工作的 Yoko 启动的。然后我参与了一点。但是你和 Ian 做了很多这方面的工作。所以对于所有使用 AI Town 的人来说,Sujay 是其后端的无名英雄。是的。

现在,你最近写了一篇关于 AI 生成的代码基准测试的博客文章。顺便说一句,对于收听节目的各位,如果您还没有阅读,我强烈建议您阅读。它实际上给了我自从整个 AI 生成代码讨论开始以来最深刻的直觉。但我认为,如果您愿意,最好在阅读过程中回顾一下您的主要见解。然后我们将尝试深入探讨细节。是的,完全正确。我认为核心见解是

能够完全构建全栈应用程序,对于当今的自主 AI 代理来说仍然不是轻而易举的事。有时在其能力范围内,有时则不在。而真正有趣的是,由于它处于可能的边缘,我们可以做一些事情来使其发挥作用,也可以做一些事情来使其肯定发挥作用。

因此,我们观察到有一些因素确实会影响自主编码性能。其中之一就是拥有非常强大的护栏。我们看到,能够提供非常快速反馈并对正确与不正确有非常严格界限的系统

帮助引导这些模型能够实现更多目标。我们还观察到,模型非常擅长编写代码。你之前提到了 SQL。他们不太擅长做诸如

评估 RLS 规则或推断 SQL 查询是否有效的原因。代码是模型出奇地擅长的事情,对吧?然后我们做的另一件事,我认为我们将深入探讨这一点,选择合适的库和抽象对于在 AI 编码中获得良好的性能来说是一项非常重要的任务。您有一组您希望模型执行的任务,这就是我们描述任务的方式。

但同样重要的是选择您不希望模型执行的任务。因此,如果存在一些非常困难的问题或已经作为良好库存在的东西,请不要让模型从第一性原理重新发明它,因为它很可能会弄糟它。您知道,作为博客文章的一部分,您实际上引入了一个新的基准。因此,很高兴听到您对为什么需要新的基准的也许辛辣的看法,因为现在已经有很多基准正在使用。是的。

所以我们称之为 Full Stack Bench。基准测试是……

如果一个 AI 代理有一个前端应用程序实现了诸如我们从聊天应用程序、待办事项应用程序、文件管理器应用程序开始的内容,这有点像常见的全栈应用程序模式。如果它只从前端开始,然后作为测试的一部分,我们选择它想要使用的后端,模型能否填充其余部分?它能否将前端完成的所有事情映射到它如何设置数据库、如何设置 API、如何设置订阅?并且

创建和运行这些类型的基准测试需要大量工作。因此,正如您所说,为什么要创建一个新的基准?坦率地说,这是因为我们看到了差距,对吧?例如,当我们开始对这方面真正感兴趣时,对于 Convex 来说,我们有很多用户写信给我们说 Convex 是 AI 编码工具的非常好的目标。因此,我们有一些客户本身就是 AI Cogen 初创公司,然后他们为使用 Convex 作为后端的用户的用户创建应用程序。

他们说,有些事情在 Convex 上运行得非常好,有些事情根本运行得不好,有些事情则处于中间状态。因此,为了更严格地了解这一点,这就是我们想要拥有这个实验框架的原因。所以……

我们四处查看,并试图了解人们正在执行的这些任务,是否存在良好的基准。答案是否定的。我认为这是令人惊讶的事情。有一些公开可用的,例如 SweeBench。最近,有来自 OpenAI 的 Sweet Lancer。

这些范围更窄,更易于创建数据集,例如只需获取一个公共 GitHub 存储库,查看所有提交,查看导致它的 GitHub 问题,在没有太多监督的情况下组装它们。然后有

微不足道、非常狭窄的焦点问题,对吧?例如您的代码力量,例如竞赛编码。但是对于人们实际执行的任务,例如如果有人使用光标并在其中使用代理模式来构建某些东西,那么实际上并没有很好的公开可用的基准。这本身就是一个有趣的主题,我认为我们已经看到很多公司认为

高质量的阀门是他们的秘密武器,并没有公开发布它们。但对我们来说,我们看到了这一点,然后决定自己制作。然后我们也将其公开。我很想知道您对这些基准测试对像我这样的普通人的实用性的看法。我将给您一个简短的轶事。所以

Cloud 3.7 发布了,这太棒了。我在家做很多外行开发只是为了好玩,对吧?我的意思是,我是一个超级休闲的开发者。这不是我的日常工作。这是我用来放松的事情。所以我一直在使用 Cursor 和 Cloud 3.5,3.7 发布了。我使用了 3.7,我发现我遇到了很多麻烦,因为它实际上可能……

过于聪明了,就像它只是做所有这些编辑一样。然后,你知道,我最终不得不撤销它们。所以我现在又回到了 3.5。而且,你知道,我相信我会随着时间的推移弄清楚 3.7。但是,当您考虑这些基准测试时,您认为它们的价值是否延伸到独立开发者?它对系统构建者更有用,还是对最终用户更有用?例如,您如何看待实用性?

广泛地?我认为如果您正在构建一个产品,该产品随后使用这些模型,那么也许不像您只是使用 Cursor 或使用 TrashEBT 的开发者那样,您的任务是您直接关心的内容,对吧?所以,你知道,没有必要实验性地运行许多条件。但我认为,现在有很多人正在构建应用程序,他们的应用程序正在调用这些模型,

然后他们想为最终用户提供良好的用户体验,对吧?有一篇关于您的 AI 应用程序需要评估的非常好的博客文章。

我认为这是长期以来被低估的事情之一,我认为人们只是假设您可以将一些随机的东西拼凑在一起,然后它就会变成一个好产品。但作为过去的一个 Web 开发新手,你知道,像学习 CSS 一样,就像你调整一样东西,然后其他东西完全崩溃了。我认为通过编写严格的步骤,例如具体来说,您希望 AI 代理解决什么问题?解决方案是什么样的?

这些解决方案是如何评级的,以及如何编译这些解决方案,这不仅是您在产品中实际尝试执行的操作的非常好的阐述。但是,例如,如果 3.7 发布,您就可以自动查看 3.7 如何在您的产品需要它执行的 100 件不同的事情上执行,查看它在某些方面有所改进,在其他方面有所倒退,

然后,如果您正在调整提示以使其在 3.7 上运行得更好,那么您也可以很容易地验证您没有使 3.5 倒退,对吧?

只是看到我在这里理解。因此,基准测试让您对不同平台做得更好或更差的地方有大致的了解,但它不会帮助您完成独立的工作。为此,评估更好,而且可能被低估了,但您需要对如何在这些事情上进行评估感到相当满意,这绝对是我的经验。对于本播客的听众来说,我认为每个人都在高级别上理解评估是什么,但并不真正了解它们是如何

应用于这些现代 AI 的。所以也许值得快速谈谈您如何看待评估,例如它们是什么,它们如何适应这个过程。是的,完全正确。所以,你知道,我实际上发现它非常有趣。这是我第一次编写大量评估。而且,你知道,在这种情况下,首先要提出我们试图执行的任务是什么,对吧?在这种情况下,例如编写 Convex 代码,可能是给定某种类似测验问题、给定提示,

例如,编写一个全栈应用程序的后端,该应用程序需要能够列出通道中的消息或向通道发布新消息。评估的第一部分是这些任务描述。您将什么提供给模型?

然后,鉴于此,模型将为您提供一些输出。评估设计的一部分是确保您告诉模型以特定方式格式化其输出或其他内容。然后在框架中,我们解析该输出并将其与参考解决方案进行比较,然后对其进行评分。这听起来很难。例如,您如何……

是语法吗?是语义吗?是正确的吗?你甚至如何考虑比较这两件事?是的。而且有时也没有黄金标准解决方案,对吧?对。是的。所以如果你只是得到这个随机的输出,你怎么……是的。你怎么……是的。对。是的。我认为这是实验设计的重要组成部分,对吧?因为可能是这样的,例如,如果我们有一个任务只是像实现聊天应用程序的后端。

那么它的输出可能看起来像任何东西,对吧?它可能合法地看起来像任何东西。我已经看到了任务描述的一般权衡

和伟大的能力。所以,你知道,与其只是说,为我编写聊天应用程序的后端,不如说,编写一个聊天应用程序的后端,其中有一个 get 请求 /list messages,它接收这个 JSON 对象并按此排序顺序返回它,如果只是提示某个随机代理,它可能比你理想的情况更具描述性,但它使它变得伟大。你现在可以对它进行评分了,是的。是的。对我们来说,不同的评估集是,我们有

有参考解决方案,我们有模型生成的解决方案。然后我们实际上为两者都启动了 Convex 后端,推送了代码。哦,有趣。然后我们有一些人工编写的单元测试来比较两者的结果。但我们也有一些后端自省 API 来询问,例如,两者的模式是什么?这些应该 100% 匹配。什么是带有所有类型的 API 描述?这些应该 100% 匹配。

因此,能够更自动地执行此操作并使其更易于评分是我们实验设计的一部分。代理不擅长的事情有哪些,你知道,你有那些具体的测试,还是说大多数易于评分的事情都是一样的?是的,至少根据我们的经验,在不同……之间存在一种非常有趣的关联。

难度和方差,你知道,就像我们看到的那样……方差是指模型之间的方差还是同一模型内的方差?即使在同一模型内。在其产生结果的能力方面的一致性。对不起,我不是故意打断,但给定相同的输入。真的吗?是的,完全正确。因为当我们拥有这些编码代理在一个……中花费一个小时时,是的,这只是很多上下文和状态……

是的。因此,对于我们最困难的任务,我们让它实现这个文件应用程序,其中有不同的项目命名空间。存在这种分层授权模型,其中组可以彼此嵌套,但不能循环嵌套。组可以附加到文件夹。所有这些都是为了设计得相当复杂。

除此之外,还有很多代码,对吧?它从前端的 4000 行代码开始,然后在实现后端时添加几千行代码。我看到很多方差,有时它能够在光标代理导航实现它的过程中保持正确的上下文。我不认为他们的上下文管理是公开的,但我认为他们只会逐出输入中非常重要的一部分。

提示或他们沿途放置的一些文件。然后它可能永远找不到它,直到人类不得不介入说,嘿,你完全卡住了。因此,您会发现对于更复杂的问题,方差会增加。

然后,那么,当涉及到……例如,假设我是一个开发者,并且我实际上关心这些时,您如何考虑控制这种方差?我的意思是,有解决方案吗?是的。我认为这是从全栈基准工作中获得的重要收获之一,那就是拥有非常强大的护栏和可以快速应用的护栏。顺便说一句,您所说的护栏是什么意思?我的意思是,我想我们都直观地理解您所说的护栏是什么意思,但具体来说,是类型安全吗?是好的语义吗?

是的,我认为类型安全只是一个最好的例子,对吧?因为,你知道,特别是对于 TypeScript 来说,有很多不变量。它就像 JavaScript,你根本没有任何不变量。是的。我的意思是,这也很有趣。我记得 TypeScript 首次发布时,所有 PL 极客都讨厌它,对吧?我自己。

对,它不健全,它只是试图将 javascript 生态系统中的每一个模式都嵌入到类型中,然后过了一段时间后,我觉得如果你放弃你的原则,如果你只是放弃可判定性,你就会有一种钦佩感,你会经历悲伤的五个阶段,你最终会接受现实,是的,从这一点中带走任何东西

我认为改变任务和改变代理使用的工具来选择更类型安全的工具,其中类型安全可以是光标代理,一旦模型生成代码,就会使用来自语言服务器的类型信息将其反馈到此上下文中。因此,它会立即修复问题,而无需任何真正的迭代循环。所以我认为这是其中一个重要收获。如果您想减少它在探索过程中的方差,那么

拥有类型安全可以使其保持正轨,你知道吗?运行时护栏怎么样,例如大多数情况下是引用透明的语言,或者超越类型安全的东西?这些重要吗?还是……

是的,这是一个好问题。我的意思是,我认为编写测试的难易程度,我的意思是,这是模型似乎非常擅长做的另一件事。因此,如果语言的语义通常鼓励事物、更易于测试的模式,那么这是管理模型轨迹的另一种方式,对吧?当它解决问题或代理的轨迹时。是的。

我的意思是,但我最初的反应是,我认为这更多地体现在推理上,而不是代码的实际创作上。例如,我认为这是我们在全栈基准实验中观察到的事情之一,那就是很多时候是,你知道,模型会认为它已经完成了,然后我们会开始对其进行评分。然后我们会说,嘿,这不起作用。这是开发者工具中错误的屏幕截图。

然后能够从该错误中进行调试并将其缩小到问题是什么,这依赖于大量的推理,对吧?而且,你知道,我们看到模型非常一致地卡在 React hook 规则上,对吧?是的,当然。是的。

难以推理。诸如 SQL 中的 RLS 规则之类的东西,其中没有非常清晰的过程执行语义。我认为这些是出现在推理中的事情,以及模型很容易偏离快乐路径并完全卡住的地方。所以也许,您是否愿意谈谈您使用不同类型模型的经验?

我们已经看到,因为我们还有一组基准测试来测试模型知识。我认为这对现在的开发工具来说是一个非常有趣的问题。而且,你知道,很多人已经谈论过它,例如知识截止,而且只是像锚定在现有系统上的数据和预训练量一样。很难构建新的抽象,对吧?即使在上下文中?

所以这就是问题所在。我认为这就是最终拯救我们的东西。但没有任何提示工程,对吧?这些模型擅长的默认内容不会随着时间的推移而发展。它会很接近。感觉它有点像一个统一的样本,对吧,互联网上的东西。我们做的第一件事就是试图理解不同模型的这种现象。

然后,就像你说的那样,在上下文中修补它。我认为,拯救我们的方法是这些模型似乎也非常好引导。它们仅从非常少的示例、指南和上下文中学习事物的能力非常酷。你知道,我的意思是,这是我们用 Claude 3.5 与 3.7 看到的事情,我们注意到,至少在知识方面……

Convex,它基本上保持不变。它稍微差一点。这可能是因为我们的提示针对 3.5 进行了调整。但我们没有看到明显的改进。好吧,这包括知识,但也包括任何类型的上下文学习都是一样的。此测试的工件是我们告诉人们将其放入光标规则中的内容。

哦,我明白了。因此,一个新的模型发布了,我们看到了它知道什么和不知道什么。然后我们将这些见解折叠回光标规则中,然后查看它是否有所改进。是的,这非常有趣,例如,使用 Gemini,例如 2.0 Flash 与……

我认为我们在 CI 中使用 O3 Mini 运行它。我们已经使用 O1 完成了它,只是不想为此付费。是的。对。谈到不为此付费,最近尝试使用 GPT 4.5。我想,我只是要运行一次,再也不碰它了。多少钱?使用 4.5 进行操作的成本是多少?好吧,我们,我的意思是,我认为是 600,000 个输入标记。我认为大约……

我必须去复查一下。但我认为,你知道,输出标记的数量大致相同。好吧,这不算多。不,但仍然像,什么,像 50 美元,我认为?是的,好的。是的,是的。好的,没关系。是的,是的。

是的。可以做很多 50 美元的事情,Martin。是的。不,我一直在关注,你知道,这些模型的价格相当惊人,对吧?如果你做任何 GPT-4,哦,是 2.50 美元。如果你做 mini,它是 0.47 美元或类似的东西。所以,你知道,你是否发现更昂贵的模型和更便宜的模型之间存在很大的权衡?对我来说,如果我使用更便宜的模型,它们实际上比更昂贵的模型要差得多。所以我认为……

而且我还没有找到弥合这一差距的方法,不幸的是。作为一个业余爱好者,也许这只是我的问题。我不想在我的愚蠢的小程序上花很多钱。所以我总是想使用较小的模型,但我发现它们并不那么好。所以也许一个具体的问题是,A,你是否发现这种二分法是真实的?第二个问题是,我有什么方法可以使用更便宜的模型,还是我完蛋了?

这是针对 4.0 与 4.0 Mini 的。正是如此。是的,我们使用小型模型的结果非常糟糕。是的。我知道查看 OpenAI 的文档很有趣,我们还没有尝试过,但是 OpenAI 的常规微调 API 的文档……

实际上非常不鼓励使用它来提高模型性能。如果您使用 4.0,而 4.0 不够用,他们喜欢,你知道,稍微阅读一下字里行间的意思,他们不想设定期望,如果您提供大量用于微调的示例,它会变得更好很多。他们所说的内容是,如果您有一个非常具体的任务,而 4.0 足够好,

您可以使用您的标签数据微调 4.0 mini,然后以更低的价格将其性能提升到该水平。所以,但我认为这就像业余爱好者。是的。

这听起来太麻烦了。Gemini 的东西相当不错,对吧?这就是我们在基准测试中看到的,而且它很便宜。就性价比而言,我发现 Gemini 实际上是最好的。但很多都是实际的价格因素,我的意思是,我猜从谷歌的角度来看,这是一个他们可以发挥优势的领域,因为他们可以垂直整合,对吧?我的意思是,一直到硬件。所以他们可能正在做的就是,由于这个原因,他们可以更便宜地提供它。是的。

好的,所以我只想回顾一些高级谈话要点,因为这很棒。第一个是,在基准测试方面存在差距,涉及到这种大型后端。我的意思是,你会如何描述它?后端还是全栈,像全栈类型的负载?有状态的?它是事务中的有状态的吗?或者这是主要的事情?

是的,我认为这是,你知道,整合所有这些不同的系统。我认为已经有大量的关于前端的工作,并且能够跨多个系统工作。所以从前端到 API 层到数据库,能够在所有这些方面做出明智的决策。这些都是构建真实应用程序的必要组成部分。而且它……

看到,我的意思是,即使查看像 SweeBench 这样的东西,对吧?它通常只非常关注某种狭窄的东西。所以大型多组件系统是这个基准测试的优点。它确实处理高度稳定的东西,高度事务性的东西,像真实的东西。是的。其次,你发现即使在同一个模型中也有相当大的差异。然后减少这种差异的方法是护栏。我们特别指出的一个就是类型安全实际上非常有意义。是的。

是的。第三,从独立开发人员的角度来看,基准测试很棒,但你真的必须严重依赖评估。这就是关键所在。这对我来说非常有趣,因为现在公开的评估很少。所以,我的意思是,我认为大多数人不知道如何进行良好的评估。所以,我的意思是,你对评估的现状有什么想法?处于我们试图开始并弄清楚的位置,对吧?我认为这就像,你知道,我认为人们已经,

可能正确地识别出评估非常有价值。而且,你知道,我记得 Vercel 的 CTO 在谈论 V0 时,他们,我认为,一开始是试图非常小心地保护他们的系统提示。然后最终我们想,这实际上并没有那么有价值。我们会让人们获得我们的系统提示。真正让你构建真实应用程序的是评估。

我认为拥有针对其领域的优秀 UL 集的组织与没有优秀 UL 集的组织之间的差距非常大。然后人们已经识别出这一点,但没有分享它们,对吧?我有点希望出现更多开源类型的时刻,对吧?即使应用程序的代码或系统提示是开源的,

在很多方面,这并不是开发的难点。我认为不仅仅是将模型相互比较进行基准测试会非常酷。但是如果有一些针对正在构建的特定应用程序的评估集可以发布并一起处理,那就太好了。是的。所以我必须问这个问题,因为你是一位非常强大的系统思想家,它与评估相关,是否有希望在这个领域逐步发展

在我的经验中,你有一个新模型,一切都变了,对吧?我就像,我的意思是,我发现媒体对这一点并没有什么用。你最终必须重写很多你的评估。即使是评估,很大程度上也是在处理相同的事情。

基于代码的相同模型。即使我增加了模型的次要版本号,一切都会改变。那么你认为我们是否已经控制了这个问题,即如何使用生成代码的模型进行真正的软件工程?如果 Cloud 3.7 是一个完美的例子,它只会改变很多东西。我想问的问题是,你认为这是可控的吗?你有没有发现什么技巧,或者它仍然是狂野西部?这是……

只是我的猜测。未经提示的热门话题。是的,请。是的。我认为其中一些是模型当前开发方式的产物,对吧?它们经过训练,我们有这些大型公司在争夺成为顶级基础模型以及它们预训练的内容。但我认为更重要的是,在后训练期间发生的事情对每个人来说都是一个完全的黑盒,对吧?我明白了。是的。

当然有很多基准测试作弊行为。关于 Cloud 3.7 到目前为止我注意到的一件事是,它非常擅长可爱的螺栓式的东西。所以我想,在 HTML 中制作一个弹出框。它就像魔术一样神奇。所以他们关注的领域显然非常具体。他们只是……

你知道,感觉几乎是虚荣的,而不是解决核心问题。所以如果那是对你的理论的任何轶事证据。完全正确。你特别谈到的问题,对吧,如果你有一些编码工作流程并且你建立在 3.5 上的模式,我认为,你知道,谁知道这五年后或十年后是否会在某个时间点,我可以想象那种技术

会被编纂成某种类型的基准。然后,你知道,很容易让他们在他们的强化学习循环中运行,也很容易让他们针对它进行训练。然后这可能是一件可以做到的事情,因为,你知道,我们已经看到了所有这些模型在所有不同类型的模型中是多么可控的

调整和提示。而且,你知道,我相信如果事情更开放一些,那么这种方式可能会更加一致。这样我们就不会在出现新模型时都争先恐后地将其运行在我们自己的基准测试上,然后说,“哦,这有效,或者这无效,或者这就是我必须在我的提示中更改的内容”。我不知道你是否为模型本身建立了一个排行榜,使用你正在使用的全栈基准,

但我觉得这会很棒,因为在我看来,如果你正在构建一个真实的系统,这是最有用的基准。它不是虚荣的事情。嘿,你做过吗?我应该知道这个。如果没有,你是否计划这样做,以便模型创建者考虑这个基准?

是的,还没有。我们主要关注的是使用 Claude 的游标代理。所以让我们用 Claude 3.5、Claude 3.7 完成吧。我尝试使用游标代理使用 OpenAI 模型,但是,你知道,我有一种感觉,它们并没有真正针对 OpenAI 模型进行优化。

所以我一直在尝试考虑,也许使用 AIDR,然后将其与所有不同的模型一起使用,这是一种更公平的比较。但是,你知道,这是一件花费所有时间设计尽可能公平的东西的事情。但这可能很有趣,只需尝试使用它们进行游标操作,然后将其放在排行榜上。好的。所以,在全栈基准测试方面做得很好。我真的很喜欢这次谈话。对这些东西的走向有什么预测,或者你还有什么想评论的吗?

我认为对于这些工具的用户来说,我认为对我来说,要点是这些工具,如果我们试图解决非常复杂的任务,那么它们,你知道,它仍然处于可能性的边界上,而不是让他们制定这些轨迹,这些计划说明他们如何一步一步地执行复杂的编码任务,以及他们如何知道他们在取得进展,以及他们如何确保他们不会陷入循环。

所以,我认为对我来说,从非常广泛的意义上来说,我们可以做很多工作来编写更好的任务提示。你知道,当我们在游标上打开一个新的聊天视图时,我们可以做得更好,比如我在那里输入什么,以及如何做得更好?但我认为还有另一个选择空间。

例如,我们如何更改我们使用的工具?我们如何更改我们使用的库?我们使用什么框架来具有一些更好的类型安全性和护栏的属性?这,你知道,秘密地是提示的一部分。我认为花一些时间优化它并考虑模型如何规划从起点到解决方案的过程,可以带来大量的改进。太棒了。好的,我必须问。那么你使用……

自己进行编码的 AI 吗?我的意思是,我认为你可能是我认识的最好的开发者。我认识很多开发者。那么你使用 AI 进行编码吗?100%。它能让你更快吗?如果是这样,快多少?

我认为很难量化,对吧?因为我认为它让我,你知道,可能快两倍。这种想法是世界上对编码的需求积压了这么多。而且,你知道,我做了所有我以前永远不会做的事情。当我使用工具时,我会编写一些自定义调试器并可视化数据。老实说,这令人愉快。这真的很有趣。你现在已经花了很多时间来研究这些模型以及它们如何生成代码。

而且,你知道,你会给那些使用这些模型的人什么样的建议或思维模型,关于如何更有效或更安全地提示,或者使用这些模型进行代码时如何思考工作流程?是的。我的意思是,我认为这里有很多与与人类合作的类比,对吧?我的意思是,我认为就像,

在将事情分解成步骤时,你知道,就像与一些初级工程师一起工作一样,对吧?首先要完成所有接口的编写工作,并使其能够进行类型检查,然后进行 git 提交。确保一旦你达到指挥地位,你就永远不会被赶走。对,对,对。先让它工作,让它成为基础,让它提交,所以如果它

搞砸了,你可以回到那个。然后从那里……完全正确。然后,你知道,如果你有一个小的扩展,对吧,你有一个你已经提交的地方,你知道它有效,尝试一些小的东西,设计它以便可以评估。你能知道它是否有效吗?如果它不起作用,对吧?

还原。我认为作为人类,我们必须学习这些作为程序员的东西,但我认为我们对此相当直观地擅长。我认为模型还没有做到这一点,也许将来会做到,但我们还没有看到。太棒了。非常感谢,CJ。谢谢,马丁。

就是这样。书中又一集。我们希望你喜欢它。如果你喜欢,请对播客进行评分和评论,并与你的朋友和同事广泛分享。和往常一样,继续收听更多精彩剧集。