扩展 DeepSeek 的强化学习蓝图路线到AI的其他方面
Nikhil Anand
图片由GPT-4o生成
"AI 软件工程师"这个概念，其实已经不再遥远了。
已经有一些技术在逐步让软件工程这件事变得越来越简单。
• Devin，被宣传为世界上第一个 AI 软件工程师，是去年推出的。
• Cursor，是个 VS Code 的替代方案，在做项目时能更方便接入 AI，最近越来越受欢迎。
• 类似 Claude 和 GPT-4 这样的 LLM，可以帮你写代码、修代码。
随着越来越多的人在研究 LLM 的推理能力，事情只会变得越来越容易。
AI 软件工程师 vs 普通 LLM
普通的 LLM 也能写代码，那它跟 AI 软件工程师有什么区别？
那我们就得更精确地定义一下这些术语了：
AI 软件工程师，是一种 AI 助手，它能查看一个 Git 仓库中的多个代码文件，并且根据它要执行的具体任务，判断需要修改哪些文件。
比如说，你有一个 AI 项目的仓库，你需要修一个 bug------每次用户选择 Mistral 模型时，AI 助手加载失败。
作为一名软件工程师，你得找到包含这个 bug 的文件，并且修复它。（作者提供图片）
作为一名软件工程师，你首先得搞清楚要修改哪个代码文件才能修这个 bug。
举个例子，你可能会去看看模型加载的那个文件，看看问题是不是出在那里。
如果涉及的变量或函数是从别的文件导入的，你也得翻一翻那些文件，看看问题是不是从那里来的。
一个普通的 LLM 解决不了这个问题，因为我们在提问的时候，没法把所有的文件都扔进 LLM 里。
我们可能得自己先找好文件，再把它丢给 LLM 让它修 bug。
我在让 Claude 修某个代码文件里的 bug。（作者提供图片）
那我们怎么定义 AI 软件工程师呢？
AI 软件工程师，就像普通的软件工程师一样，会通过不断地提交 PR（pull requests）来修复代码中的某些方面。
比如我们想打造一个推理能力更强的 AI 助手，
第一个 PR 可能是建立 AI 助手的基本框架，
第二个 PR 是设置训练流程，
以此类推。
每个 PR 就是一个对代码库的扩展提交。（作者提供图片）
AI 助手需要一个个顺着写这些 PR，要么自己写，要么在用户引导下完成。
AI 软件工程师在执行用户/老板提供的任务时可能会做的事。（作者提供图片）
怎么打造一个 AI 软件工程师（SWE）？
最近 DeepSeek 模型出来后，很多人可能都在想------LLM 能不能用强化学习（RL）来学会如何成为更好的软件工程师？
我前不久写了一篇博客，讲 RL 训练技术有多强大，如果你还没看，建议去看看。
RL 的强大之处就在于：
LLM 不用我们手把手教，也能自己学会解决问题。
那我们能不能把它应用到软件工程任务上呢？
我们先来定义一下这个任务。
任务目标
我们的目标是让 AI 助手像软件工程师一样，给定仓库当前的状态和待完成的任务，自动在仓库里做出所需的修改。
如何训练 AI 成为一个 SWE
要让 AI 做到这一点，我们会用 DeepSeek 用来提升推理能力的同一个 RL 训练流程。
RL 是个很强的通用技术。意思就是说，在一个场景下用它（比如提升推理），也能让它在其他场景下表现得更好。
所以 DeepSeek 做的那些训练，可能也能提升 AI 在软件工程任务上的表现。
但如果我们用一些专门的软件工程示例去教它，会不会效果更好？
要做到这点，第一步就是得收集一些数据，用来训练 LLM。
数据收集
为了训练 LLM，我们需要收集一些能教它在以下条件下该做出哪些修改的数据：
- 当前代码的状态，以及
- 需要被修改的函数。
那这些信息我们去哪儿找呢？
Git PR。
Git PR（Pull Request）本质上是一个提议，想把一组变更从一个分支合并到另一个分支。
当你在用 GitHub 做项目时，你通常会对仓库做一些修改，然后用一条提交信息（commit message）把这些改动提交上去，说明你完成了什么任务。
之后你会拉一下仓库的当前状态，然后把你的改动合并进去。
随着仓库的逐步变化，我们可以看到它在 PR 发起前的演变过程。（作者提供图片）
所以，一个 pull request 就包含了我们需要的所有信息------
仓库之前的状态、要完成的任务、以及为完成这个任务所做的修改。
一个 pull request（PR）中包含的所有信息。（作者提供图片）
所以，如果我们收集互联网上开源仓库里的几百万个 PR，我们就能拿到相当不错的一批信息，来教 LLM 在给定任务和旧代码状态的情况下如何修改代码。
提示 LLM
现在我们已经有了一套数据集，接下来我们要搞清楚的是，在训练过程中或在推理时，该怎么提示 LLM。
我们想要的是：
给它旧的代码状态和要完成的任务，让它输出需要做出的代码修改。
但整个代码库没法全都上传，所以我们可能只提供两种类型的文件：
- 提交前后发生变化的文件
- 没变但可能相关的其他文件
比如 helpers.py 被修改了，那 test_helpers.py 可能就被认为是个相关文件。（作者提供图片）
我们可以用 LLM 来判断哪些"未变文件"是相关的，依据是文件名。
这背后的想法是：LLM 不仅得知道要改哪些文件，还得知道哪些文件不能动 。
所以在训练中加入这个环节是非常重要的，这能帮它更好地学习。
定义奖励
说到具体的 RL 过程，那我们怎么定义"奖励"，才能激励 LLM 去学习呢？
我们会用一个简单的方法来定义奖励：
衡量 LLM 输出的代码和 PR 中实际修改后的代码之间的差距。
它们越相似，奖励就越高。
奖励是由预测出来的代码和期望的代码输出之间的差距决定的。（作者提供图片）
训练过程
整体流程很简单：
把每一个数据点传给 LLM，获取它的输出，
然后把这个输出和实际应该输出的代码作对比，
根据它们之间的相似度给予奖励。
LLM 再根据这个奖励来调整它的策略，以优化整体表现。
那我们还能怎么提升这个过程呢？
课程式学习（Curriculum Learning）
已经有研究表明，
像训练学生一样，
在 RL 训练过程中逐步提高任务难度，
能让 LLM 学得更有效率。
随着训练的推进，我们逐步给 LLM 更难的任务。（作者提供图片）
现在我们是从 GitHub 上随机选了一些 PR，
但我们其实可以按提交的"大小"排序来安排它们的训练顺序，
比如，改动越少的 commit 可能就越容易推理。
当然我们也可以想别的办法，
比如找一个更科学的指标，来判断每个 PR 推理难度的高低，
然后按照从易到难的顺序排列数据集。
更干净的数据集与奖励函数
数据集的"干净程度"是训练结束后提升 LLM 性能的主要瓶颈之一。
DeepSeek 和其他研究者已经充分说明了这一点。
- 数据集：
我们这套方法最大的问题之一就是，数据质量本身不受控。
我们理想的情况是，PR 里都体现了"优秀的软件工程技能"，
但如果我们是从网上随便抓 PR，这就不现实了。 - 奖励函数：
如果某个问题有多种解法呢？
LLM 采用的方式跟 PR 中代码的方式不一样，
它就会被扣分，
即便它的方法其实比原始方法还要好。
这就是一个错误的信号，不能正确引导 LLM。
那有没有办法改进奖励函数和数据集呢？
如果你们有什么好主意，欢迎留言！
我今天就先讲到这儿 :)
总结
AI 软件工程师这个概念，其实离我们并不远。
而且，很可能很快就会开源，
让全球的软件开发者都能轻松使用。
我们刚刚讲了一种可行的方法，用来构建一个 AI 软件工程师。
这个过程还可以通过很多方式进一步优化。
用 RL 来训练 LLM 还处在初期阶段，
这个领域里还有很多"低垂的果实"，
研究空间巨大。
我今年也打算正式进入这个领域，
如果你也感兴趣，真心建议你也来探索看看。