LLM的真正危险
这次,人工智能可能会让我们*真正地*变傻。
最近,我与我的联合创始人分享了这条推文:
它相当美妙地说明了最普遍的人类本能之一 —— 我们避免花费努力的倾向。
这并不是新鲜事,也不是由人工智能引起的。这是一个普遍的特征,过去推动了人类很多进步——我们在狩猎、剥皮和烹饪上花费的精力越少,我们剩下的能量就更多地用来发明愤怒的小鸟或者其他东西。
在软件开发中,Stack Overflow及其类似网站多年来一直是避免自主思考的绝佳方式。复制粘贴错误信息和堆栈跟踪,然后搜索,再复制粘贴解决方法。无需思考,无需理解。
大型语言模型(LLM)及其构建在其上的工具(例如Copilot)存在的问题是它们一直存在,很容易使用,对自己的正确性非常自信,这可能会放大这个问题。
在 Copilot 诞生之前,软件工程师不得不分析他们遇到的问题——挖掘文档、调试运行程序并理解执行流程。即使他们并不试图深入理解代码,他们也会阅读论坛中的答案和辩论,通过将所读的与手头问题的细节联系起来确定最有可能生效的解决方案。
在使用Copilot之后,很容易就会使用建议的代码。如果它起作用,那很好(可能吧 - 但如果你不真正理解它,你怎么确定代码的可靠性和副作用呢?)。如果不起作用,就返回LLM寻找另一个解决方案。关键是,理解和分析不再是解决方案路径的一部分。
我预测这一变化(从在Google上搜索自己的问题到由Co-pilot提供答案)将会产生一个意外的影响:软件工程师的学习速度将会减缓。锻炼你的大脑会使它更强壮,就像锻炼肌肉一样,过度依赖LLMs会使它虚弱。
如果你停止练习解决问题,你的批判性思维不只会停滞不前,而会萎缩。
过去,有很多夸张的文章问是否谷歌搜索会让我们变傻。为什么这次不同?因为这是知识和技能、数据和能力之间的区别。谷歌搜索大大降低了获取世界知识的门槛。你的记忆现在只是互联网的L3缓存。但是我们仍然需要思考和技巧,来使用这些信息。
副驾驶风险会改变这一点。做的关键步骤被移除了——副驾驶旨在为您采取知识并应用它。有时它会是正确的!但是,如果我们停止练习我们的技能,我们将开始忘记如何使用它们,他们会更难重新获得。
它让我想起以前我有过的一件印有这个字样的 T 恤。
前提是,如果你回到过去,你可以带去现代科学的思想理解,并加速它们的发现和接受。当然,你可以获得荣誉!但是所有这件 T 恤能给你的只是知识——如果你生活在 18 世纪,知道你可以“通过钨将电导到灯泡中”在有限的可用之余,除非你还知道如何识别出钨矿,可以前往钨矿,可以从它的矿石中提取钨,可以创建一个电源,并可以生产相对来说是可以导电的导线来完成电路。没有这些技能,知识几乎无用。
这件T恤当然只是一个玩笑。但是软件工程职位数量多达约2700万个的未来却不是玩笑。
坏代码的危险
对于企业和科技行业来说,存在着编写不良、不自然甚至错误的代码的即时风险。这已经有很多例子被分享,其中有些甚至很滑稽。以下是我找到的一个例子:
我非常喜欢发现这个问题。一个好的工程师可能会认为,“嗯,只有一个整数的每个位都等于0。那就是0本身。因此,这个函数应该返回0。”。
并不是所有的工程师都知道整数在内存中是如何表示的,因此另一个工程师可能会想:“好吧,我必须遍历这个范围,并测试每个整数。” 然后他们将不得不想出一种聪明的方式来进行比较。这慢得多,但它会得出正确的答案。
ChatGPT采用了一种不同的方法 - 一种古怪而神秘的方法,最重要的是不正确的。它保留了不必要的缓慢循环,但它还包含了这个条件,只过滤符合“num & (num-1) == 0”的数字。乍一看,我以为这个条件只对零成立,我还以为这可能是一段非常聪明的代码。我错了。它不仅对零成立,对每个2的幂也成立。
诡异的事情继续:ChatGPT还引入了“num!= 0”的条件。因此,它除了非常缓慢且找到20个错误答案外,它还排除了它本可以找到的唯一正确答案!
好的。但那是一个艰难的问题,对吧?一个好的解决方案需要一些侧面思考和一些位操作。当然,LLMs至少可以帮助简化语法,这样我就不必打那么多分号和括号,或者调整缩进……
不行!这是另一个人发现的副驾驶建议:
这让我感到惊讶的糟糕。我以为对LLM来说,语法会很容易。
法律和伦理的危险
但是,代码库存在比糟糕的代码更微妙的风险。除了引入漏洞和技术债务到您的代码库中,LLM还可以引入新的道德、法律和安全风险。您是否因为通过LLM无意中合并了其他人的代码而面临道德或法律问题?LLM是否有能力了解您正在处理的功能中的安全风险,并知道如何减轻它们?如果产生不安全或不道德的代码,组织中谁应该负责?LLM的分销商?为您生成代码之前学习了代码库的作者?提交代码的作者?审核者?决定使用LLMs的领导者?!
糟糕的工程师是个危险。
长期来看,我之前提到的萎缩代表着一种存在风险。由于批判性思维和解决问题能力的降低,你可以预计你的开发者学习速度会变慢。我认为,在未来几年中,我们很可能会看到新兴中级和高级工程师质量的下降。
另一条路径
以下是我如何看待我们如何拥抱AI在编写代码中的力量,这对工程部门未来结构意味着什么以及如何在避免上述多方风险的情况下获得这些好处。
对于软件工程师来说,快速提升那些还没有被人工智能挑战的领域技能是保持相关性的必要条件。这意味着学习必须加速,而不是减速。
在短期内,与 AI 助手一起工作的工程师需要深入了解他们所使用的工具。重要的是要知道 LLMs 如何工作(即使只是在高层次上),以帮助开发人员了解 LLMs 擅长处理哪些任务,哪些任务处理不佳或不可靠,以及什么时候它们会欺骗您(“幻觉”是一个委婉的说法)。
在这条替代路线中,技术领导者们应当小心将人工智能视为一种良好的开发工具(就像一个不错的IDE或者Resharper),而非开发替代品。这些技术领导者们还应当理解语言模型的能力和局限性,并且重视确保他们的团队能够优秀地工程化在LLM中输入的提示,以保证他们生成正确的代码以正确的方式。
为了降低风险并拥抱团队带来的人类技能,走另一条道路的技术领导者需要更加注重强大的代码审查技能。如果更多的样板代码由人工智能生成,那么我们工程师的时间应该集中在确保其质量和相关性上。
最后的想法
如果在这个全新的世界中快速获得新领域的技能是必须的,那么ChatGPT-4可以在多大程度上支持学习呢?我的联合创始人戴夫问了它的想法,(也许令人惊讶的是?)我认为它非常准确: