AI工程师 vs. 普通大语言模型：谁才是真正的代码大师？
你是否好奇过AI如何成为一位真正的软件工程师？在GitHub和各类技术社区，关于AI工程师的讨论正酣。最近大火的DeekSeek这个话题再次登上热搜。
让我们先看看这些"AI工程师"到底长什么样子：
- Devin------号称全球首位AI软件工程师，去年一经发布就引发轰动
- Cursor------这款 VS Code 的强大替代品，正在成为每个开发者离不开的AI助手
- Claude 和 GPT-4------代码修复界的顶流，谁还没在写代码时用过它们帮忙找bug呢？
但你是否想过：真正的AI软件工程师和普通的大语言模型（LLM）到底有什么本质区别？如何训练一个AI软件工程师（SWE）？
最近DeepSeek模型的发布，你是否好奇过LLM能不能通过强化学习（Reinforcement Learning, RL）来变得更优秀的软件工程师？
在DeepSeek-R1之后，研究领域正等待着我们去挖掘。
DeepSeek的强化学习理念比你想象的更具颠覆性。
强化学习之所以这么强大，是因为LLM能够通过自己的能力解决问题，而不需要明确地进行教学。
那软件工程任务能不能做到同样的事情呢？
让我们先定义一下目标。
我们的目标是让AI助手根据当前代码库的状态和需要完成的任务，自动做出所需的更改，就像一个真正的软件工程师一样。
如何训练一个AI成为SWE
要让AI完成同样的工作，我们将使用DeepSeek用来提升推理能力的相同强化学习训练流程。
强化学习是一个非常通用的技术。这意味着在一种情境下（比如提高推理能力）应用它，可以在其他情境下也能发挥作用更好。也就是说，DeepSeek用来提升推理能力的方法，很可能也会让我们的任务表现得更出色。
但如果我们有意识地使用软件工程实例来教导它，会不会让它变得更好呢？
要实现这一点，首先我们需要收集一些数据来训练LLM。
数据收集
为了训练LLM，我们需要收集能够教会它在以下情况下做出哪些代码变更的数据：
- 当前代码库的状态
- 需要完成的任务
接下来，我将详细讲解如何通过强化学习训练AI完成这些任务。让我们一起探索这个激动人心的领域吧！
利用GitHub PR训练LLM：从代码变更中学到的魔法
在现代软件开发中，Pull Request（PR）不仅仅是代码合并的工具，更是一个强大的学习素材。想象一下，每个PR都记录了一段完整的对话：从问题描述、解决方案到最终验证，每一步都在这里留下痕迹。
PR中的宝藏
当我们观察一个项目的仓库时，会发现代码状态随着时间逐步演进。在AI助手生成PR之前，我们已经积累了大量的变更历史：
每个PR都包含着丰富的信息：
- 问题背景：任务需要完成什么
- 旧代码状态：变更前的代码是什么样的
- 具体修改：如何实现这个任务
这些信息构成了训练LLM的基础数据。通过分析数百万个公开仓库的PR，我们可以提取出宝贵的代码变更模式。
如何提示LLM
在实际应用中，我们需要设计有效的提示方式来引导LLM工作：
- 关键文件优先 ：只提供发生变化的文件和相关背景文件
- 示例：如果helpers.py发生了变化，test_helpers.py可能就是相关联的文件
- 上下文关联 ：通过文件间的依赖关系构建完整的代码视图
- 这样可以让模型更好地理解变更的背景和影响
为什么PR是最佳选择？
- 天然结构化：每个PR都包含清晰的任务描述和对应的代码变化
- 真实场景覆盖：来自实际项目的真实需求和实现方式
- 可扩展性：GitHub上有数百万个公开仓库，提供了海量的训练数据
通过这种方式，我们可以让LLM在真实的开发场景中学习，而不是仅仅依赖人工编写的示例。这种基于实际项目经验的学习方式，将使模型更贴近开发者的真实需求。
接下来，让我们看看如何具体实现这个思路，并利用这些PR数据来训练出一个真正能理解上下文、生成高质量代码变更的AI助手。
我们可以利用大语言模型（LLM）根据文件名来判断哪些文件没有被修改。这个思路的核心在于：LLM不仅要了解需要更改的文件，还要知道哪些文件不需要改动。因此，在训练过程中将这一点融入进去非常重要。
定义奖励机制
在强化学习的过程中，如何定义奖励来激励LLM进行有效学习呢？
我们采用了一种简单直接的方法：量化LLM输出代码 与PR中实际文件的新状态之间的差异。两者越相似，奖励值就越高。
奖励是根据预测代码与预期输出代码的差异来确定的。（图片来源：作者）
训练流程
整个过程非常简单：将每个数据点输入LLM，提取其输出，然后将其与期望的输出代码进行比较，并基于序列相似性提供奖励。LLM会调整自己的策略以优化整体奖励。
如何进一步优化？
课程学习
研究表明，随着训练轮次的推进逐步增加问题难度，能够帮助LLM更有效地学习，这就好比学生的学习过程一样。
随着训练的进行，我们让LLM接触越来越难的问题。（图片来源：作者）
目前，我们从GitHub上的公开仓库随机获取PR。未来可以考虑根据提交大小（即一个提交中所做的更改数量）来排序，假设改动较少的提交更容易推理。
另一种思路是寻找衡量每个PR中推理难度的其他指标，并按难度递增的顺序排列数据点。
数据集与奖励函数的清洁之道：如何提升LLM训练效果？
最近在研究LLM（Large Language Model）的RL（强化学习）训练过程中，发现了一个非常关键的问题------数据质量和奖励函数的设计对模型性能的影响巨大。今天就来和大家聊聊这个技术难点。
数据集的"洁癖"
首先来说说数据集的问题。我们理想中的PR（Pull Request）应该代表优秀的软件工程实践，但现实是我们在互联网上公开仓库中获取的所有PR并不一定都符合这一标准。这就像是在大海里捞针------虽然有很多资源，但真正优质的却凤毛麟角。
这就好比我们在学习编程时，如果参考的教程和代码质量参差不齐，不仅会影响我们的学习效果，还可能养成一些不良的编程习惯。同样的道理，如果我们给LLM提供的训练数据不够纯净，最终得到的模型也会"良莠不齐"。
奖励函数的"选择困难"
接下来说说奖励函数的问题。在实际应用中，我们常常会遇到同一个问题有多种解决方案的情况。如果LLM提出的方法与现有代码库中的方法不同，即使它的方案更优，也可能因为"路子野"而被判定为错误，从而得到负向反馈。
这就好比我们在做选择题时，标准答案不一定是唯一正确的。如果评分系统只认可一种固定答案，可能会让我们失去很多创新的机会。同样的道理，过于僵化的奖励函数会限制LLM的创造力和灵活性。
破局之道
那么问题来了，我们该如何解决这些问题呢？这里有几个思路：
- 数据清洗：建立更严格的筛选机制，确保训练数据的质量。
- 奖励机制优化：设计更灵活的评分标准，避免"一刀切"的情况。
- 多样性评估：引入多种评价维度，全面衡量模型表现。
如果你有其他想法，欢迎在评论区留言讨论哦！