通信人家园

 找回密码
 注册

只需一步,快速开始

短信验证,便捷登录

搜索

军衔等级:

  二级军士长

注册:2010-4-284
发表于 2024-11-19 13:01:18 |显示全部楼层

作者:吴炳见

AI Coding是一个我很感兴趣的方向。

还是得说到Cursor,这是一个给我带来惊喜的产品,作为曾经学计算机的二把刀选手,已经很久没碰代码了,用Cursor生成代码,还是能让我构建一个demo,一下就能运行起来,这种简单和顺畅的体感非常真切。我也发现身边的开发者,用Cursor的越来越多。

我和做AI Coding的从业者讨论过,如果用自动化程度来看AI Coding的进展的话,一个美好又科幻的展望是这样的:

L1:给程序员用的工具,Copilot。(当下大家在使用的产品,GitGub Copilot、Cursor)

L2:从idea到demo,通过自然语言,建立产品demo,做到业务能力和代码能力分离。这一阶段只能交付demo,不能交付实用产品。

L3:AI程序员,Auto Pilot,能端到端的完成编程任务,不需要程序员介入。(融了很多钱的Poolside、Magic做这个,产品还是期货状态,效果如何是个开放问题)

L4:从一个idea到一个实用产品,多个AI角色协作完成任务,包括AI产品经理+AI程序员+AI测试员+AI运维等。(这个还比较科幻,当下模型能力相差甚远,听听就好)

L5:AI接管App工厂中的多个职能,除了编程,还包括AI投放、AI收集用户反馈、自动迭代、AI尝试商业化。(更科幻了,先当故事听听)

从L1到L5,能走到哪一步不好说,这取决于模型能力的提升。

一种思考方式:手写代码是螺丝刀,AI coding是电动螺丝刀,AI Coding这个工具有多大的市场规模?这是比较现实的角度。

一种思考方式:随着摄影机的提升和普及,乃至手机拍摄,视频内容出现了什么新形式?出现了什么新平台?同样,随着AI Coding的提升,应用产品会有哪些变化?有什么增量机会?这是叙事的角度。

所以,AI Coding能撑起一个多大的叙事?

美国老牌VCGreylock写过一篇文章<Code Smarter, Not Harder>,系统梳理了三类AI Coding创业公司,现状如何,遇到的难题是什么。可能是目前对AI Coding分析最系统的一篇文章了,我翻译分享给大家。

<Code Smarter, Not Harder>

AI Coding是一个巨大的机遇:解锁高保证、可靠的AI,进行代码生成和重塑工作流程。

编程这项工作非常适合 AI 增强或替代,原因如下:

1/ 编码本质上要求工程师将问题分解成更小、更易管理的任务;

2/ 有大量现有的训练数据;

3/ 任务需要判断力和基于规则的工作相结合;

4/ 解决方案利用可组合的模块(比如开源软件库等);

5/ 在某些情况下,工作成果可以通过经验测试其正确性。这意味着可靠的 AI 编码工具可以提供可量化的价值。

过去一年里,AI Coding工具爆发式增长。最终,是希望这些编码工具做到和人类工程师一样好,甚至超越,但仍有很多悬而未决的问题。

我们看到了做AI Coding的三种方法,这三种方法对应三个挑战:

1/ 如何创造更强的上下文感知能力?

2/ 如何让AI Agent在端到端编码任务中做的更好?

3/ 有人押注于编码模型,这能否带来长期的差异化?

市场现状

在过去的一年里,我们看到初创公司采取了三种方法:

1/AI Copilots和Chat界面,做副驾驶,辅助工程师,提升他的编程能力。

2/AI Agent,做主驾,替代掉工程师,能端到端的完成任务。

3/构建编程模型,用特定的代码数据训练一个专有模型,并与应用垂直整合。

这三条道路上各有一批公司,我们来看看行业地图。



1. 增强现有工作流程

如今,大多数AI Coding创业公司的切入点是Copilot,在IDE中嵌入Chat界面,来增强工作流程。

虽然像Tabnine这样的公司研发代码助手多年,但AI Coding的重要时刻是2021年GitHub Copilot发布:工程师开始使用GitHub Copilot写代码,市场上出现大量AI Coding项目。

这类产品能有很好的验证,是因为:

- 产出代码是工程师的核心工作;

- 这类产品只要相对较少的上下文即可奏效;

- 多数情况下,它们可以在单一平台内捆绑;

- 因为,将输出直接放在用户面前(即在IDE中)允许他们负责所需的任何更正。

显而易见,这类产品最大的挑战是GitHub Copilot,GitHub Copilot已经占据了相当的市场份额(祝贺Devin,他刚刚与微软达成合作关系)。初创公司试图通过差异化来解决这个问题,找到立足点。比如,Codeium优先做企业客户,而Codium从代码测试和审查开始,从这一切入点拓展。

我们也相信,针对代码重构、代码审查和软件架构等任务的工具有很大机会。这些可能更复杂,因为它们不仅需要对代码有更广泛的理解,还需要理解不同文件之间的知识图谱、外部库、业务背景、软件的使用模式、以及复杂工具的选择。

无论切入点如何,这类产品统一的挑战是——如何更好的获取上下文,来完成代码库中更广更深的任务。

这是一个开放性问题,我们放在最后讨论。

2. AI Coding Agent

如果增强工作流程有价值,那么更大的机会是取代某些工作流程。

能端到端执行任务的AI Coding产品——工程师在做事情时,Agent同时在后台工作——将创造全新的生产力和创新模式。AI Copilot是卖生产工具,AI Agent更进一步,在卖AI工程师。在一个AI coding Agent很好用的世界里,一个人类可以同时监督多个“AI工程师”。

AI Agent的基本能力不仅仅是预测代码行中的下一个词。它需要将这种能力与执行复杂任务的能力结合起来,这种任务可能多达数十个步骤,并且像工程师一样从用户的角度考虑产品。

比如修复一个bug,它需要知道bug的位置、问题性质、它对产品的影响、修复bug可能会导致的任何上下游变化,等诸多问题,然后才能采取第一个行动。上下文必须来自像摄取Jira票据、更大块的代码库块、和其他信息源。能够编写详细的代码规范和准确的代码规划将成为AI工程师的核心。

我们在这一领域看到的产品包括:Devin、Factory、CodeGen、SWE-Agent、OpenDevin、AutoCodeRover、Trunk等。

那么,问题来了:为了让Agent能端到端的完成更多任务,我们需要做什么?这个问题我们留在后面回答。

3. 代码模型公司

一些创始人认为,为了在AI Coding应用层建立长期的差异化,需要拥有一个专门的代码模型。

听着似乎有道理,这是一条资本密集的道路,似乎有些问题阻碍创业公司走这条路:专门的代码模型更好?还是基础模型层持续进步,并超越代码模型?这个问题还不清楚。我将在开放问题部分进一步讨论这个话题。

首先,让我们回顾一下,大多数基础LLM并不是专门在代码上训练的,许多用于代码的模型,如CodeLlama和AlphaCode,是基于LLM基础模型做的,给它数百万个公开可用的代码点,然后针对编程需求微调来创建的。



注:时间线仅显示了部分代码模型和用于编码的LLM

如今,像Magic、Poolside和Augment这样的创业公司试图更进一步,正在训练自己的代码模型,通过生成自己的代码数据和人类对编程示例的反馈来训练模型(Poolside称之为“基于代码执行反馈的强化学习”)。他们的观点是,这样能带来更好的输出,减少对GPT-4或其他LLM的依赖,并最终创建最持久的护城河。

核心技术问题是,一个新团队能否超越前沿模型的改进速度。基础模型发展如此之快,如果你试图深入研究代码专用模型,你会面临一个风险——在你的新模型训练完之前,一个更好的基础模型出现,并超越你的模型。模型训训练是个资本密集的活儿,如果你在这个问题上判断失误,将会浪费大量的时间和金钱。

我知道一些团队正在采取(非常吸引人的)方法,即在基础模型上对特定任务进行特定微调,这样既可以受益于基础模型的进步,又能提高编程能力。我将在开放问题部分讨论这个问题。

开放问题

无论采取哪种方法,都需要解决一些技术挑战,来解锁更可靠的AI coding工具,更低延迟,更好的用户体验:

- 如何创造更强大的上下文感知能力?(context awareness)

- 如何让AI Agent在端到端任务中变现的更好?

- 拥有代码模型这一基础设施,是否能带来具有长期差异化的产品?



开放问题1:如何创造更强大的上下文感知能力?

上下文问题的关键在于,某些编码任务需要正在工作的文件之外的信息和上下文,这些信息不能简单通过增加上下文窗口来访问。

从代码库的不同部分(甚至外部)检索这些信息是有挑战的,还可能增加延迟,这在即时完成的世界中是致命的。

这个问题也带来了创业机会,谁能准确和安全的找到所需的上下文?

目前,有两种方法可以做到:

-持续微调:我听到客户说过“我希望一家公司能在我的代码库上安全地微调他们的模型”。虽然理论上对自己的代码库进行模型微调有用,但实际上有一个问题:一旦你调整了模型,它就变得静态的,除非你进行持续的预训练(这很昂贵,并且可能还是有幻觉)。如果做不到持续预训练,它可能在一段时间内变现很好,但没有随着代码库的演变而学习。

确实,微调变得越来越容易,所以定期对你的代码库进行模型微调是可行的。例如,Codeium提供“客户特定的微调”,但他们明确表示谨慎使用,因为最好的方法是上下文感知RAG。

-上下文感知RAG:RAG也许是目前提高上下文的最佳方法,通过检索代码库中的相关片段。这里的挑战是,在很大的代码库中,检索排名问题非常复杂。

像Agentic RAG和RAG微调这样的概念正在普及,这是更好地利用上下文的有效方法。例如,Codeium在博客文章中分享了他们如何使用教科书式的RAG,并辅以更复杂的检索逻辑,爬取导入和目录结构,并把用户意图(比如你过去打开的文件)作为上下文。初创公司如果能把这些细节做好,将成为护城河。

开放问题2:如何让AI Agent在端到端的任务中变现更好?

尽管我们离完美的AI工程师还有一段路要走,但像Cognition、Factory、Codegen、SWE-Agent、OpenDevin和AutoCodeRover这样的公司正在取得进展。

SWEBench评估显示,大多数基础模型只能修复4%的问题,SWE-Agent达到12%,Cognition达到14%,OpenDevin高达21%。

一个有趣的想法(由Andrej Karpathy提出)是 flow-engineering,它超越了single-prompt或Chain-of-Thought Prompt,专注于代码的迭代生成和测试。确实,Prompt Engineering无需训练模型,就可以提高性能,但对一家公司来说,这在长期能有多大的护城河尚不清楚。

注意,这种测量方法有一定的局限性:就上下文而言,SWE-bench由Github的问题和拉取请求配对组成,因此当模型在它上面进行测试时,它只会得到代码库的一小部分(这是一种提示,同时也引入了偏差),而不是给予整个代码库并让它们自行解决。尽管如此,我认为SWE-Bench是一个很好的衡量标准,可以开始理解这些Agent。

代码规划将在AI Agent中扮演核心角色,我很期待看到更多公司专注于生成代码规范,这些规范可以帮助Agent建立目标、规划功能、定义实现方式、和定义架构。多步骤Agent推理仍是一个悬而未决的问题,据传闻这是OpenAI下一个代模型的重点课题。

事实上,一些人(如Jim Fan)会认为,AI Coding Agent的护城河并不来自“套壳”,而是LLM本身及“解决现实世界软件工程问题的能力,具有人类级别的工具访问能力,比如搜索StackOverflow、阅读文档、自我反思、自我纠正,并执行长期一致的计划”。

这就引出了最后一个开放问题,也是最大的问题。

开放问题3:构建代码模型能否带来长期差异化的产品?

这是一个价值十亿美元的问题,初创公司是应该依赖现有LLM模型(无论是直接调用LLM的API,还是微调模型)?还是构建自己的代码模型?——即使用高质量的代码数据,从头做预训练,经历资本密集型的过程。

实际上,我们不知道代码模型是否会比下一代LLM有更好的结果。

这个问题可以归结为以下未知要素:

- 一个较小的代码模型能否胜过一个大的多的基础模型?

- 基于代码预训练模型,需要炼到什么程度才能看到显著改进?

- 是否有足够的高质量代码数据可供训练?

- 基础模型的大规模推理能力是否压倒一切?

Poolside、Magic和Augment的假设是,拥有底层模型,并在代码上训练它,可以显著提升代码生成质量。这种潜在优势在竞争中是有意义的:据我所知,GitHub Copilot并没有从头训练模型,而是运行在一个较小、经过大量代码微调的GPT模型上。

我猜这些公司不会构建一个基础级尺寸的模型,而是构建更小、更专业的模型。根据我与AI Coding领域的人的交流,我的结论是,在结果发布之前,我们仍不知道这种方法能带来多大的改进。(Poolside、Magic等都未发布产品,虽然融了很多钱)

也有人反驳代码模型:现有成功的AI Coding Copilot,如Cursor和Devin,都是建立在GPT模型上,而不是基于代码模型。

据报道,DBRX Instruct的表现优于专门训练的CodeLLaMA-70B。如果用代码数据训练有助于推理,那么前沿模型肯定会在未来的模型中包括代码执行反馈,从而使它们更适合代码生成。与此同时,主要在语言上训练的大型模型可能具有足够的上下文信息,使其推理能力胜过对代码数据的需求——毕竟,这就是人类的工作方式。

关键问题是,是基础模型的改进速度更快?还是代码模型的性能提升更快?我认为,大多数Copilot公司会使用前沿的基础模型,并在自己的数据上微调——例如,使用Llama3-8b,通过代码执行反馈进行强化学习——这允许公司从基础模型的发展中受益,同时使模型偏向于代码性能。

结论

构建用于代码生成和工程工作流的AI工具,是当下最令人兴奋和值得投入的事业之一。持续提升编码能力,甚至最终完全自动化编码,将开启一个巨大的市场,远大于历史上出现过的开发者工具。虽然需要克服众多技术障碍,但这个市场的上升空间是无限的。

PS:这是ChatGPT翻译的,我做了一些更符合中文习惯的修改。

还是建议大家去读原文,这是链接。

https://greylock.com/greymatter/code-smarter-not-harder/


来源:36kr

举报本楼

本帖有 1 个回帖,您需要登录后才能浏览 登录 | 注册
您需要登录后才可以回帖 登录 | 注册 |

手机版|C114 ( 沪ICP备12002291号-1 )|联系我们 |网站地图  

GMT+8, 2024-12-5 07:57 , Processed in 0.251233 second(s), 16 queries , Gzip On.

Copyright © 1999-2023 C114 All Rights Reserved

Discuz Licensed

回顶部