一站式 Web3 探索中心 | 去中心化应用商店 & Web3 线下活动

热门话题

Michael Anti

安替， Globus， Global Research.国际事务资深记者、哈佛尼曼研究员 '08、TEDGlobal 演讲者。

Michael Anti 已转发

转译：为什么大语言模型无法真正构建软件作者：Conrad Irwin 我花了大量时间做的一件事就是面试软件工程师。这显然是项艰巨的任务，我不敢说自己有什么绝招；但这段经历确实让我有时间去反思，一个高效的软件工程师究竟在做什么。软件工程的核心循环当你观察一个真正的行家时，你会发现他们总在循环执行以下几个步骤： * 构建一个关于需求的心理模型。 * 编写（希望如此？！）能够实现需求的代码。 * 构建一个关于代码实际行为的心理模型。 * 找出两者之间的差异，然后更新代码（或需求）。完成这些步骤的方式有很多种，但高效工程师的过人之处，就在于他们能够构建并维持清晰的心理模型。大语言模型表现如何？平心而论，大语言模型在编写代码方面相当出色。当你指出问题所在时，它们在更新代码方面也做得不错。它们还能做所有真人工程师会做的事：阅读代码、编写并运行测试、添加日志，以及（大概）使用调试器。但它们无法做到的是，维持清晰的心理模型。大语言模型会陷入无尽的困惑：它们会假设自己写的代码真的能用；当测试失败时，它们只能猜测是该修复代码还是修复测试；当感到挫败时，它们干脆把所有东西删掉重来。这与我所期望的工程师特质恰恰相反。软件工程师会边工作边测试。当测试失败时，他们可以对照自己的心理模型，来决定是修复代码还是修复测试，或者在做决定前先收集更多信息。当他们感到挫败时，可以通过与人交流来寻求帮助。尽管他们有时也会删掉一切重来，但那是在对问题有了更清晰理解之后才会做出的选择。但很快就行了，对吧？随着模型能力越来越强，这种情况会改变吗？也许吧？？但我认为这需要模型在构建和优化方式上发生根本性的变化。软件工程需要的模型，不仅仅是能生成代码那么简单。当一个人遇到问题时，他们能够暂时搁置全部的上下文，专注于解决眼前的问题，然后再恢复之前的思绪，回到手头的大问题上。他们也能够在宏观大局和微观细节之间自如切换，暂时忽略细节以关注整体，又能在必要时深入研究局部。我们不会仅仅因为往自己的“上下文窗口”里塞进更多词语，就变得更高效，那只会让我们发疯。即便我们能处理海量的上下文，我们也知道当前这些生成式模型存在几个严重的问题，这些问题直接影响了它们维持清晰心理模型的能力： * 上下文遗漏：模型不擅长发现被忽略的上下文信息。 * 新近度偏见：它们在处理上下文窗口时，会受到严重的新近度偏见影响。 * 幻觉：它们常常会“幻想”出一些本不该存在的细节。这些问题或许并非无法克服，研究人员也正在努力为模型增加记忆，让它们能像我们一样施展类似的思维技巧。但不幸的是，就目前而言，它们（在超出一定复杂度后）实际上无法理解到底发生了什么。它们无法构建软件，因为它们无法同时维持两个相似的“心理模型”，找出其中的差异，并决定是该更新代码还是更新需求。那么，现在该怎么办？显然，大语言模型对软件工程师来说很有用。它们能快速生成代码，并且在整合需求和文档方面表现出色。对于某些任务来说，这已经足够了：需求足够清晰，问题足够简单，它们可以一蹴而就。话虽如此，对于任何有点复杂度的任务，它们都无法足够精确地维持足够的上下文，来通过迭代最终产出一个可行的解决方案。你，作为软件工程师，依然需要负责确保需求清晰，并保证代码真正实现了其宣称的功能。在 Zed，我们相信未来人类和 AI 智能体可以协同构建软件。但是，我们坚信（至少在目前）你才是掌控方向盘的驾驶员，而大语言模型只是你触手可及的又一个工具而已。