我们距离 AI 在绝大多数软件开发任务中实现人类水平的能力和自主性大约还有 24 到 36 个月的时间。
出品丨AI 科技大本营（ID：rgznai100）主持人：大家好，我是 NVIDIA 开发者工具 AI 技术软件工程总监，马特·弗雷泽（Matt Frazier）。
众所周知，AI 辅助开发者工具，或者说代码生成、AI 代码生成——现在有很多叫法——正在从根本上改变我们开发软件的方式。NVIDIA 自然非常关注这一趋势如何影响我们处理软件和加速计算的方法。
为此，在 GTC 2025（英伟达大会）上，我们邀请了来自多家公司和不同行业的 AI 代码生成通用应用专家，以及 CUDA 优化与相关研究领域的专家，共同探讨这个话题。
我想快速问各位读者几个问题：
有多少人特别在 CUDA 调试中使用过 AI 驱动的代码工具？
大约有多少人遇到过 CUDA 性能问题，并且花了超过一天的时间来解决？
有没有人尝试过将这两者结合，把 AI 代码生成应用于你们的 CUDA 问题？有人成功过吗？
有多少人的代码库，特别是 CUDA 代码库，规模超过了大约一万行？
接下来是大家可能最关心的问题。在使用 AI 代码生成工具时，你们遇到的最大挑战是什么？是准确性，还是生成速度？
如果你正在用 CUDA 编写加速代码，你会选用 C++ 还是 Python？或者两者都用？
如果你对以上任何一个问题感同身受或感到好奇，那么接下来的讨论就值得你关注。下面，我想介绍一下参与本次讨论的嘉宾。
莎娜·达马尼（Sana Damani），她是 NVIDIA 架构研究组的研究科学家，致力于提升 GPU 上并行应用程序的性能，以及提高调试和优化工作的易用性。
妮哈·巴特拉（Neha Batra），GitHub Copilot 的工程副总裁，她领导的核心生产力组织，专注于贯穿整个软件开发生命周期（SDLC）的工具以及开发者的日常工作流程。她尤其关注 AI 编码助手如何从领导大型团队和产品项目的视角出发，变革开发者的工作流程。
艾兰·亚哈夫（Eran Yahav），他是 AI 编码助手公司 Tabnine 的 CTO，同时也是以色列理工学院（Technion）的计算机科学教授，主要研究方向是代码机器学习和程序综合——此外，他还是一位运动员。
伊索·康德（Eiso Kant），Poolside 的创始人，他是一位工程师，在 AI 和开发者工具领域拥有十余年创办初创公司的经验。在创立 Poolside 之前，伊索曾是 Athenian 和 source{d} 的创始人兼 CEO。
最后是阿比纳夫·巴特勒（Abhinav Bhatele），他是马里兰大学帕克分校计算机科学系的副教授，兼任并行软件与系统组主任。他的研究重点是用于大规模训练、微调大语言模型（LLM）以完成编码任务（如并行代码生成）的基础设施。
接下来，我想先从莎娜开始提问。你的研究工作似乎正好处于 AI 和 GPU 性能的交叉点。根据你的研究，你在提高 CUDA 性能方面遇到了哪些主要挑战？你又采用了哪些方法来应对？
莎娜（NVIDIA）：这是个很好的问题。尝试过 CUDA 编程的人可能都了解，GPU 虽然能提供惊人的计算性能，但要充分挖掘其潜力并非易事。开发者需要付出大量努力，深入理解从算法、CUDA 特性、编译器选项、各种工具一直到 GPU 架构等多个层面，才能真正掌握其工作原理。因此，即便具备了这些专业知识，逐步定位并解决性能瓶颈、优化代码，依然需要投入大量的手动工作。
我们正在探索 AI 在这方面提供帮助的可能性，目前有几个相关的研究项目。第一个项目名为 Nsight Copilot，它已经集成到 NCU 分析器中，大家可以在 GTC 的开发者工具展位观看演示。这是一个 AI 助手，能够帮助识别 CUDA 程序中的性能瓶颈，甚至就如何解决这些瓶颈提供优化建议。这是我们的第一个项目。
第二个项目名为 WarpDrive，这个项目更具实验性质，我们去年在 NeurIPS 会议上进行了展示。它是一个 AI 智能体解决方案，目标是自动化 CUDA 性能调优的完整流程，涵盖从性能分析、识别恰当的优化策略、执行代码转换，到最终测试等各个环节。当然，这个领域仍然面临诸多挑战，尤其是在验证生成代码的正确性方面。
但总的来说，通过这两个项目，我们的目标不仅是减少 GPU 性能调优所需的人力投入，更是要让不同水平的开发者都能更轻松地利用 GPU 的强大性能，而不仅仅局限于那些顶尖的专家。
主持人：阿比纳夫，你的研究方向与莎娜有相似之处。你如何看待她提到的这些挑战？特别是在处理更大规模的代码库和并行性方面，你正在进行哪些工作？
阿比纳夫（马里兰大学）：正如大家可能意识到的，使用 AI 工具仍然面临着严峻的挑战。我想具体指出几个问题。首先，我们正在研究的是整个程序的翻译。这意味着，我们能否超越像 GitHub Copilot 这样的辅助工具，直接让 AI 处理整个源代码库？对于生产级别的代码，这可能涉及数万行代码，并且这些代码通常分布在多个文件和目录中。我们希望 AI 工具能够优化这样的代码库，或者将其从一种并行模型（如 OpenMP）转换到另一种（如 CUDA），或者从 CUDA 转换到 HIP 等其他平台。
这方面存在着重大的挑战。其中一些挑战包括：首先，当前的 AI 工具难以充分理解项目的目录结构、文件组织方式以及它们之间的复杂依赖关系。另一个值得关注的问题是构建系统（无论是 CMake 还是 makefile）。如果 AI 工具生成了新文件或重命名了现有文件，它在自动修正构建系统以适应这些变化方面表现不佳。这看似是一个工程上的细节问题，但实际上是一个非常现实的障碍。因此，如何让 AI 工具在生成正确代码的同时，也能生成或更新配套的、能够正常工作的构建系统，是一个亟待解决的问题。
主持人：所以，这既是一个通用的编码 AI 问题——即管理构建过程、makefile 和文件结构，同时又是一个非常具体的问题，因为这对于 CUDA 和加速编程来说尤其重要。各位嘉宾在处理这种更普遍的问题时，能分享哪些业界的相关进展？
伊索（Poolside）：文件结构的问题本身可能不会持续存在太久。但是，谈到构建系统以及 CUDA 优化或任何加速计算的优化，我们目前推动基础模型前沿发展的主要方式，是通过强化学习让模型在真实的软件开发环境中进行学习。
举例来说明我们公司正在做的工作：我们在一个强化学习环境中运行了超过一百万个完全容器化的 GitHub 项目，这些项目包含了数千万次的修订记录。我们让模型在这些真实环境中执行各种开发任务，然后实际运行项目自带的测试以及我们设置的其他验证检查，以此来反馈和改进模型。
然而，我们目前还没有专门针对加速计算进行此类强化学习训练，原因其实很简单：当我们运行一百万个代码仓库并执行数十亿次强化学习任务时，每月在常规计算资源上的花费大约是 1000 万美元。如果我们要设定一个与提升 CUDA 性能相关的强化学习目标，那么我们就必须运行极其庞大数量的 GPU 实例——这些 GPU 不是用于模型训练或推理，而是用于执行模型在学习过程中尝试完成的任务本身（例如，编译和运行 CUDA 代码以获取性能反馈）。因此，在我们决定将大量计算资源专门投入到针对加速计算领域的强化学习循环之前，许多相关的模型能力改进将难以实现。
但有趣的是，CUDA 优化实际上是一个非常适合强化学习的问题，因为其目标非常明确：我们通常是在尝试改进性能分析器（profiler）报告中的某些具体数值。我们非常清楚优化的目标是什么。相比于那些需要模型改进其通用推理和思维过程以提升整体编码能力的更宽泛任务，针对 CUDA 优化的学习目标要明确和容易衡量得多。因此，我们最终会涉足这个领域，但这目前仅仅是基础模型研发层面（包括我们自己，以及 Anthropic 和 OpenAI 等其他机构）尚未将资源重点投入到这些特定优化环境中的一个暂时性限制。
艾兰（Tabnine）：将强化学习应用于 CUDA 优化这类任务的部分挑战还在于正确性验证。对 CUDA 代码进行测试本身就非常困难，仅仅是为 CUDA 内核运行测试并确保其计算结果正确，就已经相当具有挑战性。你需要有效控制并发执行，并确保对不同的执行交错（execution interleavings）有良好的测试覆盖率。因此，为这些涉及并发和同步的工作负载设计并执行充分的正确性测试，本身就是一个巨大的难题，这还仅仅是为了验证代码的功能正确性，尚未涉及性能。
妮哈（GitHub）：在 GitHub，当涉及到需要跨越整个代码库进行更改时，我们倾向于关注完整的端到端流程。我们目前正在进行的一项工作是扩展 AI 工具能够处理的上下文窗口大小，以及它们能够进行全局性操作的能力范围。例如，Copilot 的编辑功能现在已经能够跨越单个区域、页面或文件，实现跨多个文件的更改。我们在这方面正在取得进展。
我们特别关注的一个研究领域是，识别那些适合在整个代码库范围内进行的更改类型。例如，如果要实施一项安全改进，需要修改或检查哪些不同的文件？如果要进行可访问性方面的改进，又需要涉及哪些类型的文件？以及我们如何能够更系统化地处理这些跨文件的操作？我们正在研究那些可以通过 AI 进行全局性处理的问题类别。
主持人：我听伊索特别提到了强化学习以及使用 GPU 的成本问题。还有一个普遍的问题是硬件支持的多样性。在加速计算领域，有很多硬件版本和 CUDA 版本需要支持。
我很好奇，想先问问阿比纳夫，在大规模维护 CUDA 代码质量方面，哪些非 AI 技术被证明是最有效的？以及当需要进行性能测试时，你如何管理那个包含硬件、CUDA 版本和所有其他依赖项的庞大组合矩阵？
阿比纳夫（马里兰大学）：传统上，在不使用 AI 工具的情况下，维护 CUDA 代码质量涉及大量的手动工作：例如编写单元测试、回归测试、设置和维护夜间构建流程等等。虽然其中部分流程可以实现自动化，但最终程序员仍需编写大量的测试代码。未来，部分这类工作或许可以进一步自动化。例如，我们可以利用 AI 工具进行自动化的代码评审（PR review），或者自动生成更多的测试用例。在这些方面，AI 工具有望提供帮助。目前，程序员确实承担着巨大的手动工作量，而引入 AI 工具有望减轻这种负担。
妮哈（GitHub）：我想补充一点：代码创建、测试编写和代码审查是软件开发中的三个关键环节。这三者对于提高代码质量、确保最终产品符合预期都至关重要。具体在哪些环节实现自动化、减轻哪些负担、侧重于哪些方面，往往取决于不同公司的具体需求和策略。让所有这三个环节完全由 AI 自动化，我认为风险相当大，但利用 AI 进行辅助则非常有价值。
我特别关注的领域之一是 Copilot 代码审查功能，即探索如何让 AI 辅助进行初步的代码审查。另一个领域是测试生成，AI 在生成单元测试方面表现得相当不错。但当涉及到端到端测试时，正如艾兰之前提到的，你需要确保自己真正理解成功的标准是什么、期望的结果是什么、以及需要特别注意哪些方面，因为这些都需要在委托 AI 执行任务时明确指定。
否则，这就像进行结对编程：你将代码交给另一个人，他们进行了一些修改，你必须确保这些修改通过了预定的测试标准。如果你不清楚测试标准是什么，验证就会变得非常困难。因此，虽然 AI 在单元测试生成方面潜力巨大，但在端到端测试方面，我们还需要进一步探索和改进与 AI 协作的方式。
主持人：伊索，你们是如何考虑这种端到端问题的？我知道在内部的强化学习训练中，这是一个核心部分。但是当用户实际使用时呢？在软件开发生命周期（SDLC）中，你还看到了哪些自动化可以发挥作用的地方？
伊索（Poolside）：这个领域最初是从代码补全功能开始的，随后发展到基于聊天的交互模式，而当前最新的趋势是朝着智能体（Agent）的方向发展。但许多人可能尚未完全意识到的是，基础模型的改进速度非常之快，以至于从我们的视角来看，实现具备真正自主行动能力的 AI 系统——也就是能够端到端完成任务的环境——已经为期不远。这意味着 AI 将能够执行完整的端到端操作：从自动解决构建错误，到独立执行大型、复杂的多步骤开发任务，最终交付一个已经完成或准备好供人工审查的成果。
在我们看来，大约再过 24 到 36 个月，AI 就有可能在绝大多数软件开发任务中达到接近人类水平的能力和自主性。当然，届时仍然会存在差距，例如在特定领域的系统知识、实际项目经验等方面，以及在模型尚未充分学习和实践过的任务上。但这预示着，我们很快将不再仅仅把这些 AI 工具视为屏幕右侧的聊天助手或集成在 SDLC 中的某个 API。我们会更多地将它们看作是具备一定自主能力的实体——一个能够在较长时间跨度内持续行动、能够操作我们整个开发环境（从控制浏览器打开 AWS 控制台，到使用终端、编辑器，乃至操作各种开发工具）的智能体。虽然这还不是我们今天的现实，但认识到这一发展趋势至关重要。
回想起来，如果是在 2016 年，我们都刚进入这个行业时你问我这个问题，我可能会说，这或许需要 30 年才能实现。如果是在两年前我创办这家公司时问我，我大概会说 5 到 10 年。而现在你问我这个问题，我的预测是 24 个月、30 个月、36 个月——这个时间范围变得非常具体了。这一点值得我们注意。随着 AI 能力的指数级增长，它的形态和应用方式将发生巨大变化，从简单的编辑器助手演变为更具自主性的智能体。这种转变将有望解决我们目前关心的许多关于端到端自动化能力的问题。
艾兰（Tabnine）：我想立即就此提出一点不同的看法。端到端的自动化能力或许会实现，但其中存在一个我们目前可能有所低估的关键差距，那就是信任问题。我们如何能够信任一个 AI 智能体交付的结果？我个人是绝对不会愿意坐下来审查由智能体生成的 3 万行代码（尤其是审查复杂的 CUDA 代码）。
我们已经观察到，在 AI 驱动的软件开发生命周期（SDLC）中，瓶颈正在从代码生成转向代码审查。生成大量代码变得非常容易，但我们无法确定这些生成的代码是会累积成技术债务，还是可以真正信任并集成到项目中的高质量代码。
这涉及到几个关键点：首先是 AI 需要理解整个现有的代码库，确保生成的内容与组织内已有的代码、库和规范兼容。其次，需要有某种机制来控制生成过程，确保产出的代码在一定程度上遵循团队的最佳实践和编码标准。而这些仅仅是挑战的开始。正如妮哈提到的，我们需要明确的规范和标准：由谁来负责审查这些 AI 生成的代码？对于这 3 万行代码，其正确性的基准（ground truth）又是什么？
伊索（Poolside）：请允许我稍微回应一下。我们之所以信任我们的同事和团队成员，是因为他们通过过往的工作证明了自己具备完成特定任务的能力。而目前，我们确实不应该完全信任 AI，因为它在执行多步骤任务时，存在准确性逐级累积下降的问题。如果一个模型在单步操作上的正确率是 70% 或 80%，那么让它连续执行六七个步骤后，最终结果中错误累积的概率就会非常高。
但是，当未来我们开始拥有能力足够强大的 AI 系统和模型，并且我们能够持续观察到它们的产出质量达到了与我们组织中值得信赖的人类同事难以区分的水平时，那么信任问题将在很大程度上自然缓解。因此，我们或许并不需要刻意去“解决”信任问题本身，而是要关注于提升 AI 的能力和可靠性。
当然，在现阶段，我们必须维持现有的软件开发生命周期（SDLC）、代码审查流程以及其他成熟的工程实践。例如，我目前并不建议用户通过 API 调用我们的模型来执行全局性的代码重构，我甚至会明确建议我们的客户不要这样做。这有点像我们有时会看到一些开发者为代码仓库自动提交大量单元测试的 Pull Request——这可能并非当前技术下最恰当的应用方式。
我们确实观察到一些对当前 AI 技术能力的不当使用或期望过高的情况。但我认为，这是一个随着技术进步会逐渐得到解决的问题。可以将其类比为——我倾向于用拟人化的方式来思考——你目前面对的是一个还不能完全信任的初级实习生。但随着这位“实习生”能力的提升，最终成长为团队中值得信赖的高级开发人员时，我们现有的协作和验证体系就能够有效地处理信任相关的问题了。
主持人：我想请妮哈接着这个话题讨论，因为妮哈之前也提到了开发者角色将如何演变，即思考使用 AI 的开发者如何承担新的角色。
妮哈（GitHub）： “智能体”（Agent）无疑是未来几年的热门概念和重要发展趋势。它本质上描绘了一种场景：我们可以将任务分配给 AI，然后暂时离开，待任务完成后再回来检查结果。有趣的是，作为一个从工程师转变为管理者的人，我深知“授权”是一项关键的管理技能。而现在，我们实际上是在尝试学习如何清晰地定义一个任务，并将其有效地“委托”给一个 AI 智能体，无论是通过聊天界面还是其他交互方式。我们需要找到更优化的方法，将 AI 无缝地嵌入到我们的工作流程中，让它在真正有价值的环节发挥作用。
例如，设想未来你可以直接将一个 GitHub Issue 分配给 Copilot，然后在流程的另一端获得一个相应的 Pull Request。这是我们努力的方向之一。当思考这对我们开发者技能组合的影响时，一方面，我们需要提升理解并清晰定义需求的能力。如果一个问题或任务被准确地描述出来，那么 AI 就更有可能生成符合预期的结果。这最终还是回归到我们软件开发的根本目标：创建有用的功能，为用户解决实际问题，修复软件缺陷。
另一方面，审查能力变得愈发重要。如果我们越来越多地依赖 AI 进行代码生成，那么可被创建的代码量会增加，相应地，需要被审查的代码量也会增加。因此，我们必须提升自身的代码审查技能。虽然可以让 AI 辅助进行初步审查，但最终的判断仍然需要人来完成：这段代码是否有意义？它是否真正解决了我们想要解决的问题？我希望我们始终能回归到这个核心问题上来进行评估。
主持人：伊索刚才提到需要理解我们的意图、完整的开发生命周期以及最终目标，这听起来与产品需求文档（PRD）或详细设计规范有相似之处。那么艾兰，你对于利用这类更结构化的输入（比如计划或规范文档），甚至从这些文档出发来指导 AI 执行任务（而不仅仅是生成代码片段），例如让 AI 根据计划生成集成测试、单元测试等，有什么看法？
艾兰（Tabnine）：我想从一个更根本的层面来看待这个问题。信任的挑战在短期内难以完全消除，因为目前我们很大程度上依赖人类的判断。即使我们将任务外包给人类，我们也是在依赖他们的常识、经验和判断力——这些人通常已经融入了组织的文化，了解我们的工作方式和偏好，并且擅长从不完全明确的规范中推断出隐含的需求。
现实中，规范几乎永远是不充分的。我们不可能编写一份长达一万页的 PRD 来详尽说明如何构建一个应用程序的每一个细节。几乎所有的开发工作都是基于不充分的规范进行的，而将这些不充分的规范具体化为实际代码的过程，目前很大程度上依赖于人类开发者的理解和判断。
这正是当前开发流程能够有效运作的原因之一。你通常不会给初级开发人员一份极其详尽的 PRD，而是会给出相对高层次的指令，比如“我需要在这里添加一个按钮”，然后期望他们能够根据上下文进行合理的推断和实现。在我们拥有能够被充分信任、并且能够准确推断我们高层次意图的 AI 之前，信任问题将持续存在。
再次强调，我们观察到的现象是，AI 驱动开发的瓶颈正显著地转移到代码审查环节。这对在座的各位可能都有体会。我们实际上看到了一种类似“分布式拒绝服务攻击”（DDoS）的效应：代码生成者（可能是一些经验不足、倾向于直接接受 AI 建议的初级开发者）产生了大量的代码，涌向负责审查的高级工程师，使得后者的审查负担可能比以前增加了百倍。这些高级工程师疲于应对，竭力确保涌入的代码不会引入问题，不会破坏代码库的稳定性。这是我对信任问题的一个普遍观察。将这些 AI “助手”或“员工”引入组织的挑战，核心在于如何使它们变得足够值得信赖。我们最终会达到那个目标，但这需要一个过程，需要我们找到方法将 AI 的可靠性提升到等同于值得信赖的人类员工的水平。
主持人：谈到引入 AI “员工”——我刚加入 NVIDIA 时，CUDA 经验也并不丰富。这让我思考，我们如何让 AI 系统，特别是当它们更深入地集成到 SDLC 中、我们对其依赖程度越来越高时，获得必要的领域知识？这既包括为了建立信任而进行的某种形式的“入职培训”，也包括如何让 AI 在那些专业知识要求高、或者可用训练数据相对稀疏的新领域（如 CUDA）中表现良好？
你们认为需要哪些关键要素或资源，才能帮助 AI 在像 CUDA 这样数据相对稀疏的编程领域做得更好？一旦我们拥有了这些要素，又该如何将它们有效地集成到现有的 AI 解决方案中，而无需每次都从头开始训练或构建？
莎娜（NVIDIA）：对于 CUDA 编程，尤其是高度优化的 CUDA 代码，公开可用的高质量示例确实相对较少。因此，一个关键的要素是能够系统地收集这些宝贵的知识，特别是如果我们能从 NVIDIA 内部的库开发者或 DevTech 工程师那里获取——他们拥有深厚的专业技能和编写得非常出色的 CUDA 代码实例。
如果我们能够利用这些高质量的代码构建一个专门的知识库，那么我们就可以将其用于强化学习、模型微调，或者直接作为高质量的示例（few-shot examples）提供给 AI 智能体。这将是一种非常有价值的方法。即使在我们 WarpDrive 项目的探索中，我们的目标也不仅仅是应用已知的、有大量数据的优化技术。
更具挑战的是，当你提出一种新的代码转换方法，但在缺乏足够训练数据的情况下，如何让 AI 能够自动地将这种新方法应用于各种不同的 CUDA 内核。我们当时尝试的方法是通过提供明确的指令，将复杂的转换任务分解成更小的、可管理的步骤，并设计一个引导 AI 执行这些步骤的流程来实现。我个人倾向于从编译器的视角来思考这类问题。总而言之，我们正在探索的途径包括：获取高质量的示例代码，然后研究如何将其有效地分解和表述，以便 AI 能够理解和学习。
阿比纳夫（马里兰大学）：我先快速回应一下关于信任的问题，尽量简短。特别是在科学计算领域——我相信在工业界的生产级软件开发中同样如此——确保代码的正确性是至关重要的。通常，科学计算团队中既有物理学家也有计算机科学家，有时物理学家甚至对计算机科学家编写的代码也持谨慎态度，他们倾向于亲自进行验证和测试。
主持人：他们所处的领域确实要求极高的严谨性，不能轻易信任。
阿比纳夫（马里兰大学）：确实如此。如果你正在研究像高超音速飞行、火星探测器着陆，或者利用分子动力学进行药物设计这样的复杂问题，那么在进行任何后续工作之前，你都必须绝对确保你的模拟代码是正确的。
因此，我同样认为信任问题在短期内不会消失，这是一个非常现实且重要的问题。回到 CUDA 和其他加速计算软件的话题上，我同意莎娜的观点，一个核心挑战在于缺乏足够的高质量数据来有效训练或微调 AI 模型。
特别是在科学计算领域，存在大量使用 Fortran 或 Fortran 结合 MPI 编写的遗留代码。这些语言和编程模型都属于典型的“低资源”（low-resource）场景，意味着可用于训练 AI 的公开代码数据非常有限。在这种情况下，如何确保 AI 能够生成高质量、高性能的代码就成了一个严峻的挑战——因为没有足够的数据，模型的生成效果自然会受限。目前，研究人员正在探索合成数据生成技术来缓解这个问题。例如，伊利诺伊大学厄巴纳-香槟分校（UIUC）有一篇名为 Magicoder 的论文在这方面取得了一些进展，但它尚未完全解决问题，特别是对于那些数据极其稀缺的语言。因此，这确实是一个亟待解决的难题。
https://arxiv.org/pdf/2312.02120
这篇论文也有清华学子的身影
主持人：那么，对于更大规模的代码生成工具来说，你们如何处理数据稀疏的问题？
伊索（Poolside）：我可以谈谈合成数据（synthetic data）这个概念。在我们目前从头开始训练的基础模型中，已经有大约 25% 的训练数据是合成生成的。
我们的预测是，在未来 12 到 18 个月内，我们用于训练模型的数据中，合成数据的比例可能会高达 90%。但这其中有一个非常关键的前提，这也呼应了莎娜刚才提到的观点：有效的合成数据生成，必须基于少量但质量极高的“基准真相”（ground truth）数据。
打个比方：假设我找到一位没有 CUDA 背景，但具备很强推理能力和扎实 C++ 基础的优秀软件工程师，然后让他去处理一个复杂的 CUDA 任务。虽然我本人并非来自科学计算背景，但我们公司内部为了优化模型训练和推理代码，也编写了大量的 CUDA 代码。假设任务是优化一个注意力（attention）机制的 CUDA 内核。为了帮助这位工程师学习，我需要提供给他高质量的 API 文档、清晰的示例代码，以及任何能够简化学习过程的资源（就像一本好的教科书），并假设他有足够的时间（可能需要很长时间，比如数年，去解决一个 CUDA 专家半天就能搞定的问题）。
关键在于，如果存在可供学习的高质量基准真相数据，那么以此为起点，我们实际上可以通过模型自身的推理能力，结合强化学习以及我们使用的一系列其他技术，来综合生成和推断出大量的相关知识和代码模式。但是，明确哪些是可靠的真实样本、哪些是模型需要通过探索来学习的内容，这一点至关重要。因为一旦有了这个坚实的基础，我们就可以引导模型进行类似人类开发者的“体验式学习”：让模型去尝试不同的方法，运用其推理能力，在实践中学习哪些尝试是有效的（做对了），哪些是无效的（做错了）。
然而，如果缺乏高质量的基准真相数据作为引导，模型需要探索的空间就会变得异常庞大。我们在该领域早期的研究论文中看到过这样的例子，比如 Google 在早期探索时（大约在 2016 年，当时这个领域被称为“代码机器学习”（ML on code），全球关注者可能只有百人左右），最初尝试的强化学习方法，有点类似于用遗传算法的方式，让模型盲目地迭代尝试所有可能的解决方案。这种方法的计算成本极其高昂——在座的各位对此可能深有体会——因为搜索空间实在太大了。
因此，我们实际上并不一定需要海量的原始训练数据才能处理低资源语言。我们过去之所以需要海量数据，主要是因为第一代训练模型的技术严重依赖于大规模的“下一个标记预测”（next token prediction）范式。而现在，随着强化学习等新技术的引入，我们获得了新的能力，使得模型对原始数据量的依赖性有所降低。
当然，我们仍然希望获得尽可能多的高质量数据——如果你有大量的 CUDA 代码，我非常乐意将其纳入我的训练数据集中。但这不再是绝对的必需品。然而，正如莎娜和阿比纳夫所强调的，整理和提供高质量的基准真相数据——这项工作将是极其关键的。将这些高质量的样本提供给模型，将极大地提升它们在后续探索、学习和合成数据生成方面的效率和效果。
主持人：你提到基准真相（ground truth）对于合成数据生成（SDG）和解决一般问题都至关重要。那么，请区分一下“基准真相”和“数据可用性”（data availability）这两个概念。
我理解，传统的机器学习方法（比如一两年前的技术）可能需要海量的样本数据，而现在合成数据可以在一定程度上弥补数据量的不足。但是，当你谈论“基准真相”时，你主要指的是某种形式的、可信赖的验证标准或高质量样本，对吗？
伊索（Poolside）：我们可以从两个角度来看待验证或基准真相的作用。
第一种是针对具有明确规则和目标的确定性系统，例如棋类游戏（围棋、国际象棋）或许多编程任务。在这些场景下，存在清晰的成功标准或优化目标。例如，对于一个需要分析性能瓶颈的 CUDA 内核，其优化目标（如降低延迟、提高吞吐量）通常是明确且可量化的。
第二种，我们可以称之为“与已知事实保持一致性”（consistency with ground truth knowledge）。打个比方，假设我明天需要涉足量子物理学领域（一个我完全不了解的领域），如果有人给了我一个关于量子物理学的陈述，我要判断其真伪，就需要去查阅该领域的基准知识来源，比如教科书、权威论文等，然后检查这个陈述是否与这些已知的、公认的事实相符。
这大致对应了我们目前用于提升模型能力的两种主要技术路径：第一种是利用模型日益增强的推理能力，让其学习与我们已知的、可验证的真实知识（基准真相）保持一致。我们可以利用这些高质量的基准数据来引导模型，尽管基于推理的一致性检查在计算上可能成本较高。第二种是强化学习，也就是通过实践和反馈进行的体验式学习。实际上，正是这两种方法的结合，使得我们能够在提升模型能力方面取得显著的进步。
主持人：我知道我们刚才的讨论深入到了一些非常技术性的细节，希望大家还能跟上节奏——当然，深入探讨技术细节也正是大家来参加本次讨论的目的。现在，让我们转换一下话题，谈谈遗留代码（legacy code）的问题。这是一个普遍存在的重大挑战。具体到 CUDA，遗留代码往往受到硬件更迭、API 演进等多种环境因素的影响。但更广泛地说，所谓的“棕地”（brownfield）项目——即在现有代码基础上进行开发和维护——是我们所有开发者都必须面对的现实。
我想先请莎娜和阿比纳夫分享一些在处理 CUDA 遗留代码时遇到的具体挑战。然后，我想将这个问题开放给所有嘉宾：你们认为 AI 在处理遗留代码方面有何潜力？我们之前听到艾兰提到，他可能不会信任 AI 来进行大规模的 API 重构。这背后的原因可能在于，正确的工程实践要求我们进行模块化重构并配合充分的测试，但也可能因为对脆弱的遗留代码进行测试和修改本身就极其困难。
阿比纳夫（马里兰大学）：对于大型的 CUDA 代码库，特别是那些 CUDA 内核散布在整个项目中的情况，目前比较有效的方法通常是聚焦于单个内核进行处理，例如，尝试将其移植到新的硬件架构或对其进行性能优化。
主持人：这就像是处理一个个独立的、封装好的组件。
阿比纳夫（马里兰大学）：是的。而目前效果不佳，或者说挑战更大的，是试图将整个代码库作为一个整体来审视，并尝试进行全局性的、大规模的更改。
主持人：比如更改依赖关系或重构以使用某个库。莎娜，根据你在我们更大规模项目上的经验呢？
莎娜（NVIDIA）：我个人通常不直接处理规模极其庞大的代码库，但即使在单个 CUDA 内核的层面上，情况也可能变得相当复杂。因为对于 CUDA 而言，当新的 GPU 架构问世时，你原有的旧代码虽然通常仍然可以运行，但其性能往往不再是最优的。如果性能不是最优，那么使用 CUDA 加速的意义就大打折扣了。因此，开发者确实需要针对每一代新的 GPU 重新审视和调整之前的优化策略。
并且，通常情况下，新的 GPU 可能会引入新的硬件特性，而这些特性往往只能通过特定的新 CUDA API 来访问。这就要求开发者必须修改代码以利用这些新 API，并可能需要更新所有相关的 CUDA 内核。在某些情况下，为了充分利用某个关键的新硬件特性，甚至可能需要对整个代码结构进行重构，或者从根本上重新设计算法。因此，特别是在 CUDA 领域，为了持续获得最佳性能，不断更新和维护代码是必不可少的。
主持人：所以，这听起来似乎需要在应用层面进行某种评估或检测（可能是在运行时，也可能是在进行大规模重构或更改之前），以确定需要进行的调整。妮哈，这种持续适应和更新的需求，与你之前描述的 AI 辅助开发的愿景是如何契合的？
妮哈（GitHub）：当我们考虑一个遗留代码库时，无论是对于一个 AI 智能体，还是对于一个初次接触该代码库的新人（例如新入职的员工），首要任务都是理解当前的开发环境和代码库本身。
设想一下，如果我突然被调到一个全新的项目，需要在一个我从未接触过的代码库（甚至可能使用我不熟悉的语言）中工作，我首先会投入时间去深入研究和理解它。
在处理遗留代码的软件开发生命周期（SDLC）中，“理解”（Understanding）是一个至关重要的环节。我确实认为 AI 在这方面可以发挥重要作用。虽然目前可能还没有足够成熟的工具，但未来 AI 具备遍历代码库、筛选关键信息、并辅助开发者进行探索性理解的能力，将对学习和上手过程非常有帮助。
有趣的一点是，在理解代码库的过程中，开发者实际上是在脑海中构建整个代码库的“地图”。对于人类来说，将如此庞大和复杂的上下文完整地记在心里是非常困难的，但这对于计算机来说则相对容易。因此，计算机和 AI 在辅助理解遗留代码方面具有天然的优势。理想情况下，AI 不仅能帮助理解，还能基于理解提出行动计划，例如明确“接下来需要进行哪些修改”。
至于代码生成本身，虽然可以让 AI 生成代码，但正如莎娜指出的，特别是在 CUDA 领域，生成的代码必须具备高性能，否则就失去了意义。因此，在性能优化等方面仍然存在挑战。关于 AI 的能力边界，我倾向于不轻易断言“某件事永远做不到”，因为技术发展的速度往往超出预期。但可以预见的是，像高性能代码生成和优化这类问题，将是未来需要攻克的更难的挑战。
艾兰（Tabnine）：正如妮哈所指出的，这涉及到问题的不同层面。对于大型企业级代码库——例如，我们有些客户的代码库规模达到 3000 万行——即使是看似非常简单的更改（比如一个 Jira 工单要求添加一个按钮），开发者也可能需要阅读数千行代码，涉及多个不同的代码层级，才能准确判断应该在代码库的哪个具体位置修改相关的几行代码。
代码生成本身可能相对容易，但准确理解变更的具体位置和影响范围，即具备充分的上下文感知或代码库感知能力（知道在哪里修改，以及如何修改才能避免破坏其他功能），是极其困难和特定的。我们观察到，当前的 AI 在这类需要深度理解和精确定位的任务上表现还不够好，这正是一个巨大的挑战。这是一个有趣的挑战，我们以及整个行业都在努力攻克。
主持人：伊索，你似乎对进行这种规模的改变的能力更为乐观，或者至少我理解是这样。是什么让你对此更有信心？
伊索（Poolside）：首先，我认为我们对于当前 AI 能力的现状和局限性，大体上是有共识的，因为我们都在实际使用这些工具。目前，一种常见的尝试让 AI 理解整个代码库的方法是，试图将全部代码“塞进”一个巨大的上下文窗口中。但我们一直认为这并非最佳途径。我们公司主要服务于所谓的“高风险”（high-consequence）软件开发环境，这些环境通常涉及金融服务、政府、国防或大型科技公司，开发者规模可能从 5000 人到 10 万人不等。因此，我们几乎总是需要处理大型、复杂的代码库。
我们的观点是，随着模型日益展现出智能体（agentic）特性和在环境中行动的能力，我们更期望它们能够像人类开发者一样，自主地沿着探索路径遍历代码库。这与试图将整个代码库一次性加载到上下文窗口中，然后简单地要求 AI “找出这项更改会影响什么”是不同的。
我们可以借鉴人类开发者在面对复杂任务时的做法——这个过程并非完美无缺，当前的 AI 模型也缺乏人类那样完美的、持续的注意力。但是，如果我们将其视为一个多步骤的任务来处理，让 AI 模拟这个过程：“我正在考虑进行这项更改，现在我需要去探索代码库，跟踪依赖关系图，检查相关文件，并在探索过程中做出判断和决策。” 当我们允许模型在更长的时间跨度内，以一种感知时间序列、分步骤的方式行动时，我们观察到它们在这方面的表现正逐步提升。
“智能体”（Agent）这个术语在我们的领域确实有些被滥用。但其核心思想——让模型采用多步骤的方法来解决复杂问题，模拟人类开发者打开文件、检查代码、跟踪依赖等行为——是解决大规模代码理解和修改问题的关键组成部分。我们正看到 AI 在这个方向上展现出良好的发展潜力。然而，这并不意味着它不受当前模型固有局限性的影响，即模型即使在单一步骤上的可靠性也并非 100%，并且在多步骤任务中，准确性可能会迅速下降。因此，我们当前的核心工作——持续推动基础模型能力的提升——就显得至关重要。
我们可以看看在非“专家级”或非底层优化（或许可以戏称为非“忍者编程”）领域已经发生的情况。观察一下如今的前端应用开发或简单的 CRUD Web 应用开发，其创建速度已经大大加快。两年前还难以想象的事情，比如在几十分钟内端到端地构建一个基本应用程序（有时被戏称为“氛围编码”（vibe coding）），现在已成为可能。随着模型能力的不断提升，这种趋势正在向其他软件开发领域扩展。
不过，对于在座的各位——我毫不怀疑从事加速计算开发的专业人士可能是目前对 AI 持怀疑态度最强烈的群体之一，并且你们完全有理由如此，因为这恰恰是当前 AI 表现相对薄弱的领域之一——我有一个具体的建议：找出三到四个对你们来说至关重要的、代表性的开发任务，这些任务是当前 AI 模型还无法很好完成的，将它们作为你们个人的“黄金评估集”（golden evaluation set）。
然后，每隔三到六个月，重新用最新的 AI 工具尝试完成这些任务。通过这种方式，你可以亲身感受 AI 能力的进步，例如发现“哦，现在它的推理能力似乎提高了”，或者“它现在能完成这个任务的 20% 了”。这将帮助你形成自己对于何时、在多大程度上可以信任 AI 的判断，并对这个领域的发展方向有一个更真实、个性化的感知，而不是仅仅依赖于社交媒体上的信息或公司发布的基准测试报告。建立并定期评估你自己的黄金任务集，可能是你在关注和应用这项技术时能做的最有价值的事情之一。
主持人：谈到智能体能力和更宏观的开发流程，往往需要依赖某种形式的反馈循环。NVIDIA 特别关注的一个领域，同时也是在座各位专家正在深入探索的一个方向，是如何利用性能分析（profiling）工具产生的反馈信息，并将其更紧密地集成到软件开发生命周期（SDLC）中。虽然反馈循环对所有软件开发都很重要，但对于 CUDA 编程而言尤其关键，因为在某种意义上，如果 CUDA 代码性能不佳，它几乎等同于“错误”的代码——性能正是其存在的根本意义。
基于此，我很想快速听听各位嘉宾对于“黄金测试”（golden tests）或“黄金评估任务”的想法，正如伊索刚才提到的。我自己也有一些个人的测试用例，用来检验 AI “现在是否能完成这项任务了？”——如果不行，过段时间再试。
那么，在你们各自的领域，你们会使用哪些关键任务或标准来判断一个 AI 智能体或代码生成系统是否取得了实质性的进展或达到了可用的水平？我知道对于 CUDA 和加速计算领域的专家来说，这些标准可能与通用编程领域有所不同。
妮哈（GitHub）：对我个人而言，一个关键的测试是代码重构。我希望 AI 能够可靠地执行重构任务，例如，尝试将某段代码提取成独立的函数或模块，并验证其有效性。另一个重要的测试是跨语言代码转换。这是我关注的两个目前 AI 尚未完全掌握，但我感觉我们正逐步接近目标的领域。
我期望未来能达到这样一种状态：我可以不断提高对工程团队的要求和标准，赋予他们更多的职责，而 AI 能够有效地辅助他们。当我考虑我的团队（大约有 500 名工程师）时，我希望在提升标准（例如，要求他们同时负责高性能代码、数据容量管理、可访问性，并确保代码功能正确且可扩展）的同时，不会让他们负担过重。我希望 AI 能够在这方面提供支持，比如在代码审查环节提供有价值的建议，甚至成为他们学习和探讨技术方案的“伙伴”。所以，总结来说，我的两个关键测试领域是代码重构和语言转换。我们正在取得进展，但尚未完全达到理想状态。
阿比纳夫（马里兰大学）：你提到其中一个关键测试是语言转换，但更具体地说是从串行代码自动转换为并行代码，例如从串行 C/C++ 转换为 MPI 或 CUDA 实现。目前 AI 在这方面的表现还很不理想。另一个重要的测试，我认为是整个程序的翻译或重构，正如我之前提到的。我们也有基于代码规模的“黄金测试”：例如处理 500 行、1000 行、10000 行的代码片段或程序。目前的模型在处理 500 到 1000 行规模的代码时表现尚可，但一旦代码规模显著增大，我们往往无法得到任何有意义的生成结果，或者生成的只是无效的代码。
主持人：看来我们需要私下交流一下关于处理大规模代码上下文的方法，而不是简单地依赖巨大的上下文窗口。莎娜，你的看法呢？
莎娜（NVIDIA）：对我而言，一个关键的测试是 AI 能否成功执行一项复杂的 CUDA 优化任务。这不仅包括它是否能最终生成正确的优化代码，还包括评估其效率：即使初始生成的代码不正确，它需要经过多少轮迭代和修正才能达到正确状态？以及，我需要提供哪些辅助信息或工具（例如性能分析数据、编译器反馈）才能帮助它更有效地完成任务？
因为我们观察到，也许几个月前，某些复杂的代码转换任务 AI 完全无法完成，即使我们尝试提供调试信息。但随着时间的推移，模型在理解和应用这些信息方面有所改进，我们希望看到达到正确结果所需的迭代次数能够逐渐减少。
艾兰（Tabnine）：对我来说，目前特别感兴趣的一个“黄金任务”是执行非常深入且跨越整个代码库的符合性审查。例如，给定一个需求：“确保系统在任何情况下都不会在未加密的状态下传输客户数据”。
我希望 AI 智能体能够准确理解这个需求中的关键概念：什么是“客户数据”？什么是“加密”？哪些操作构成了“传输”行为？这项任务的挑战在于，相关的逻辑可能完全分散在代码库的不同层面和模块中。要完成这项任务，AI 需要具备伊索之前提到的那种在代码库中进行导航和推理的能力。它需要能够理解所有这些分散的部分，并将它们联系起来，作为一个整体流程进行验证。我们目前还没有完全达到这个水平，但我认为我们正在逐步接近。
主持人：好的，接下来我们直接进入提问环节。
观众提问：我的问题是关于带有自动验证的强化学习。特别是在处理复杂软件项目（例如您提到的在 Docker 容器中运行的完整代码仓库）时，您如何设计自动验证规则，以防止模型找到“取巧”或“钻空子”（gaming the system）的方法来满足规则，而不是真正解决问题？
对于 CUDA 加速，目标通常很明确（例如提升性能指标），但对于更广泛的、涉及整个软件项目的复杂任务，如何设定有效的、不易被“游戏化”的验证标准呢？
伊索（Poolside）：这是一个非常好的问题。首先，多样性（diversity）是缓解这个问题的一个关键因素。我们起始于包含多种编程语言的一百万个真实世界的代码库。我们利用这些项目自带的、由开发者编写的现有测试（主要是单元测试）作为初步的验证信号。诚然，单元测试覆盖率可能存在不足，开发者编写的测试本身也可能包含错误。但是，当你拥有足够大的规模和足够高的多样性时，你就可以通过统计和过滤的方法，筛选出那些测试质量相对较高、更可靠的部分作为训练信号。
然后，在此基础上，我们可以利用一种我有时戏称为“LLM 套利”（LLM arbitrage）的现象：目前的模型在编写测试用例和解释代码方面的能力，往往优于它们直接生成复杂功能代码的能力。我们可以利用这种能力上的差异，让模型围绕特定的任务目标，综合生成大量的额外测试覆盖。当然，无论是原始测试还是合成测试，单独来看都可能不完美。但是，当你在强化学习框架中拥有极其庞大的规模和多样性时，这些信号足以将模型的学习过程引导到正确的方向上，使得模型在每一轮训练迭代后都能有所改进。因此我们发现，在进行这类强化学习时，特别是当目标不像“优化某个具体性能数值”那样清晰明确时（性能优化实际上是强化学习中最容易定义目标的一类问题），例如涉及到在整个代码库中进行复杂更改或构建全新功能时，关键在于不断提升用于训练和评估的问题集（problem set）的规模和多样性。
实践表明，随着模型能力的提升，解决特定类型任务所需的训练样本效率会提高（即需要更少的样本）。这时，训练策略就会相应调整：逐渐减少对已掌握的简单任务的关注，将重心转移到新出现的、更困难的任务类别上——这些任务模型可能只能部分解决，或者完全无法解决。这就像一个不断迭代提升模型能力的过程，如同将一个“能力窗口”逐步向前推进。
当然，最终我们会遇到一个挑战：如何为那些非常高层次、抽象的，并且难以找到现成示例的目标任务定义有效的学习信号？这时，之前提到的“套利”方法又可以发挥作用。例如，你可以选取一个现有的复杂项目（比如一个性能分析器的代码库），让一个强大的模型去深入理解它，然后尝试让模型反向生成该项目的目标描述或高级设计规范。本质上，我们是在不断地以真实世界的复杂数据作为“种子”，从不同角度对其进行加工和利用，目标是生成可用于训练的任务描述、用于验证的测试用例，或者作为示例的解决方案代码。理论上，甚至可以尝试同时合成这三者，并且这种方法在一定程度上是可行的。但是，如果能获得一些高质量的真实基准真相数据作为基础，效果通常会更好。同时，我们也希望模型能够在真实、多样化的环境中学习，而不仅仅是局限于某些特定类型的、可能被过度简化的任务。
观众提问：我想向 GitHub 的嘉宾提问。您之前提到了代码重构，并表示在这个领域正取得进展。对于小规模的软件或应用程序，AI 辅助重构或许是可行的。但对于非常大规模的系统（例如数十万行甚至更多代码），尤其是那些包含混乱的“意大利面条式代码”（spaghetti code）或复杂遗留结构的系统，您认为 AI 未来将如何处理这类大型系统的重构挑战？
妮哈（GitHub）：我认为，一个非常重要的原则是，只要人类开发者仍然是开发流程中的关键一环——而且我个人倾向于在可预见的未来保持这种“人机协作”的模式——我们就应该确保 AI 的工作方式不应过度偏离人类的最佳实践。因此，即使是在与纯人类团队合作时，我也通常不希望看到一次性涉及上百个文件的大规模、原子性的重构提交，除非有极其充分的理由。我更倾向于鼓励开发者将大型重构任务分解成更小、更易于管理和审查的步骤。
类似地，当涉及到与 AI “队友”协作进行重构时，我认为正确的方式也应该是从小规模、可控的重构开始，然后逐步扩展其应用范围。我们需要确保在这个过程中，人类开发者能够理解、验证并对结果感到“舒适”或有信心，因为归根结底，我们是在与这些 AI 系统协同工作。
所以我目前并不认为我们能够、或者应该期望 AI 一次性完成涉及两三百个文件的重大重构。主要原因在于，我们仍然需要对最终合并到代码库中的代码负责，这意味着我们需要能够理解这些更改。因此，我的回答是，在设计和应用 AI 辅助重构方案时，我们必须始终考虑到最终使用和审查这些代码的人类开发者。这又回到了信任和责任的问题上。即使未来 AI 的能力发展到足以处理非常大规模的重构任务，我们可能仍然需要将其分解成人类可以理解、审查并最终负责的较小单元。
观众提问：我有一个关于生成式 AI 模型能力的问题。我们看到一些报道或基准测试声称，最新的模型能够在编程竞赛中取得非常好的成绩，甚至“击败”顶尖的人类竞赛选手。但与此同时，当我们在真实的、复杂的软件开发场景中测试这些模型时，它们似乎又经常失败。
我想请问各位嘉宾，你们是否认同这种观察，即当前的某些基准测试（如编程竞赛）可能无法完全反映模型在真实世界开发任务中的实际能力？其次，如果认同，你们认为造成这种差异的主要原因是什么？第三，针对这个问题，你们是否有相应的解决思路或计划？
伊索（Poolside）：原因其实相对直接。与真实世界的软件开发相比，编程竞赛是一个更容易针对性优化的任务领域。这是因为竞赛编程的问题域通常范围更窄，目标更明确（例如，通过所有测试用例并优化时间和空间复杂度），更容易将其转化为一个清晰的强化学习目标，从而可以通过大量训练显著提升模型在该特定任务上的表现。
因此，目前观察到的这种（竞赛表现与真实世界表现的）差异是符合预期的。在编程竞赛中，奖励信号是明确定义的，问题通常具有确定性（给定输入，有唯一或可验证的正确输出），并且问题的规模和复杂度相对可控。
此外，还有一个可能的原因是，在许多研究实验室中，参与模型研发的人员本身可能就有很强的竞赛编程背景（坦率地说，我的团队里也有这样的人才）。他们自然会倾向于关注并优化模型在自己熟悉的竞赛任务上的表现，希望“让模型在这个特定任务上做到极致”。但这并不一定能直接转化为模型在更广泛、更复杂的真实世界软件开发任务中的通用能力。这就像一个顶尖的竞赛程序员，如果其经验仅限于竞赛环境，未必能在实际的工程项目中成为最高效或最有价值的开发者。因此，编程竞赛是一个有趣的基准测试，它可以为我们提供一些关于模型特定能力的信号，但它不应该被视为衡量模型在所有软件开发任务中综合能力提升的唯一或主要标准。
艾兰（Tabnine）：我完全同意伊索的观点。如果允许我补充一点，那就是为真实世界的企业级软件开发任务（例如，执行一项复杂的代码变更）创建有效的、有代表性的基准测试本身就极其困难。其难度远超创建编程竞赛类型的基准测试。因此，我们看到的差异，部分也源于评估真实世界能力的基准测试本身的构建难度。
主持人：正好借此机会宣传一下，如果大家感兴趣，可以去 GTC 大会 NVIDIA 展位的 AI 开发者工具团队展台了解一下。我们正在发布一个名为 ComputeEval 的新基准测试。这个基准测试旨在更准确、更全面地反映企业级规模的软件开发问题，特别是针对 CUDA 编程的挑战，并且充分考虑了刚才讨论的这些因素。当然，这个基准测试是否真正有效，还有待业界的检验和反馈。在此也呼吁所有致力于评估方法研究的同仁们，继续努力为我们的行业创建更好、更贴近实际的评估标准。
观众提问：我的问题也与信任有关。我记得去年十二月左右有一篇研究论文（可能来自某个研究小组）引起了一些讨论，其结论似乎暗示，随着模型能力的增强，它们最终可能会发展出某种形式的“欺骗性行为”（scheming or deceptive behavior）。
* 欢迎回顾这篇经典讨论：《AI 叛乱打响第一枪！Anthropic 最新论文作者齐聚紧急会议：模型“伪装顺从”，暗中对抗训练》
我知道这还只是初步的研究，可能需要更多时间来验证其结论。但是，我的问题是：假设我们最终真的面临这种最坏的情况，即我们发现从根本上无法完全信任 AI 模型（例如，因为验证其真实意图的问题最终被证明是像停机问题（halting problem）那样的不可判定问题）。在那种假想的未来中，您认为我们应该如何继续利用 AI 技术？我们可以设置什么样的“护栏”（guardrails）或采取哪些措施来管理这种风险？
艾兰（Tabnine）：首先，我们需要认识到，这可能是一个相对的问题。就像自动驾驶技术一样，未来可能在某些方面，由于人类自身的局限性（例如疲劳、注意力不集中导致的错误），依赖人类的风险甚至可能高于依赖经过充分验证的 AI 系统。AI 在处理某些复杂任务上的能力可能会超越人类。
但是，你提出的核心问题是对的：从根本上验证一个复杂智能系统的内部状态或“真实意图”，很可能是一个不可判定的问题，因为它本质上是一个极其复杂的验证（verification）问题。
妮哈（GitHub）：我想到了一个俗语——“手里拿着锤子，看什么都像钉子”。这个比喻之所以适用，是因为我们有时会陷入一种思维定式：当我们初次接触 AI 时，可能会预设“只有当它完全可信时，我才会这样或那样使用它”。但即使一个系统并非完全可信（就像逻辑谜题中那些已知总是在说谎的角色），我们仍然可以从中获取有用的信息或洞见。
人类的适应性非常强，关键在于我们能否找到有用的方式来利用这些不完美的工具，并让它们帮助我们做出更好的决策。我不认为我们应该因为潜在的不可信风险就完全放弃 AI。即使一个系统在某些方面不完全可靠（当然，我个人对未来是乐观的），它仍然可能在其他方面帮助我们编写更好的代码或提高效率。最终，这取决于我们如何设计与 AI 的交互方式，如何明智地选择应用场景，而这需要我们进行深入的研究，并不断探索最佳实践。
伊索（Poolside）：我了解你提到的那篇论文，这触及了 AI 安全（AI Safety）的核心议题。那么，在信任问题之外（我基本同意艾兰和妮哈的观点），我们确实必须在不远的将来正视一个现实：我们正在创造出智能水平可能与人类相当甚至超越人类的系统，并且这些系统很快将具备规划和执行长期复杂任务的能力。
这是人类社会从未遇到过的情况。因此，如何“对齐”（align）这些强大的 AI 系统，确保它们的目标和行为符合人类的意图和价值观（这让人联想到经典的阿西莫夫机器人三定律），将成为一个日益关键的研究和工程领域。目前，许多从事基础模型研发的公司（坦率地说，有时也包括我们自己）在这项对齐工作方面仍处于相对早期的阶段。
但是，随着我们越来越接近通用人工智能（AGI）或其他形式的强大 AI 的“临界点”，我们亟需加强关于 AI 安全和对齐的讨论与研究。就我个人而言，我对此持谨慎乐观的态度，因为我们参与了模型训练的全过程，并且正通过强化学习等技术，越来越多地尝试为模型施加更严格的伦理和行为约束。我相信这些是可以通过持续努力来改进和解决的问题。
目前我们能做的最重要的事情（这一点你会反复从各大基础模型公司那里听到）是大力投入评估（evaluation）技术的研究，开发出更好的方法来准确衡量和理解模型是否真正按照我们的期望和指令行事。具体到你提到的那篇关于“欺骗性行为”的论文，它进一步凸显了在可解释性（interpretability）研究方面投入更多努力的重要性，我们需要更深入地理解模型内部的决策机制。但这仍然是一个非常前沿和开放的研究领域，有大量工作亟待完成。
我想提及我们一个非常值得尊敬的竞争对手——Anthropic，他们在探索 AI 安全的“黄金标准”方面，为整个行业树立了很好的榜样。但总的来说，我们所有人都还处于这个征程的早期阶段。
* 本文由 CSDN 精编整理。
* 本场对话源自 GTC 2025，日程为北京时间 2025 年 3 月 22 日 0:00 AM - 1:00 AM。
【活动分享】2025 全球机器学习技术大会（ML-Summit）将于 4 月 18-19 日在上海举办。大会共 12 大主题、50+ 位来自学术界和一线技术实战派的顶尖专家，聚焦下一代大模型技术和生态变革技术实践。详情参考官网：http://ml-summit.org/。
