江苏龙网

  1. 主页 > 生活百科 > >

为何大语言模型不会取代码农？

大语言模型

译者 | 布加迪
审校 | 重楼
生成式人工智能（GenAI）会取代人类程序员吗？恐怕不会 。不过 ， 使用GenAI的人类可能会取代程序员 。但是如今有这么多的大语言模型（LLM），实际效果不一而足 。

为何大语言模型不会取代码农？

文章插图
如果您在努力跟上所有LLM，并非只有您一个人 。我们目睹一场激烈的LLM竞赛 。单单谷歌的GenAI产品就已经变得非常丰富——其最新的开放模型Gemma是LLM快速精简的最新例子，甚至可以称之为小语言模型 。
与DevOps社区更密切相关的是我们看到其他用于生成代码的LLM闪电般的开发速度，比如Meta最近更新的Code Llama 70B 。当然，GenAI吓倒了不少开发者 。最近的一项研究发现，近一半的开发者对于自己凭借目前的技术技能在GenAI界取得成功表示了担忧 。
但这种担心真的有道理吗？关于人类程序员已死的说法可能夸大其辞了 。人类甚至可能实际上有更多的时间来准备迎接由GenAI主导的世界 。
事实上，开发者应该询问的更适当的问题不是“GenAI会抢走我的工作吗？”，而是“我该使用哪个LLM？”
太庞大了，编程没法成功【为何大语言模型不会取代码农？】LLM给软件开发界的承诺是有望将码农变成架构师 。然而 ， 并非所有LLM都天生一样；值得探讨的是，为什么一开始就涌现出了较小巧的LLM 。
更强大的主流模型（比如GPT-4和Claude 2）仍然只能勉强解决不到5%的实际Github问题 。ChatGPT仍然存在严重的幻觉问题：假变量，或者甚至十多年前就已经被弃用的概念 。此外 ， 它让没用的内容看起来很有用 。您可以尝试利用“提示工程”来摆脱这些没用的内容，但是有益的上下文数量存在一个最佳平衡点——太多会导致更混乱更随机的结果，白白耗费了更多的处理能力 。
LLM编程方面更大的问题是信任 。在过去，主流LLM不加区别地吸收网上的一切内容，就像一个大型数字吸尘器，至于它们从哪里获取数据缺乏透明度 。哪怕一家公司交付的代码中仅仅1%含有另一家公司的受版权保护的代码 ， 这也是个问题 。您可以想象噩梦般的召回场景：交付的产品没有无线传输功能来挑出可疑代码 。
不过，LLM格局正在迅速改变 。
LLM对于编码够专业吗？当Meta在今年早些时候宣布对其Code Llama 70B进行更新时 ， 感觉这是大受欢迎的尝试，有望解决主流LLM对编码缺乏关注的问题 。它有三种不同大小的版本：70亿个参数、130亿个参数和340亿个参数 。它还使用代码的5000亿个token和与代码相关的数据进行训练，包含10万个token的庞大上下文窗口 。
从理论上讲，其中最令人兴奋的是Code Llama Python/ target=_blank class=infotextkey>Python，这是专门为Python设计的Code Llama版本——主要是由于它代表了LLM未来的发展方向 。与Meta的大型科技同行开发的一些模型不同 ， 这个模型完全致力于为一种特定的语言编程，使用Python代码的大约1000亿个额外的token进行训练 。业界更加需要的正是针对特定用例的这种级别的定制建模 。
之所以需要强调“理论上令人兴奋” ， 是由于像Code Llama这样的LLM对开发者到底有多有用还有待观察 。去Reddit看看，就会发现早期的结论似乎是 ， 该模型因诸多问题而令人沮丧，其中包括复杂的提示格式、过于严格的护栏，最重要的还有幻觉问题 。最后一点是另一个不争的事实，提醒人们：任何模型的好坏完全取决于训练它所使用的数据 。
不管是否存在缺陷 ， Meta的定制LLM方法已经引起了人们的重视，即大语言模型并不是AI辅助代码生成取得成功的唯一途径 。我们看到，业界越来越青睐使用规模较小、更专门化的LLM编写代码，比如BigCode、Codegen和CodeAlpaca 。StarCoder是另一个LLM，尽管只有155亿个参数，但在评估基准测试中的表现却胜过PaLM、LaMDA和LLaMA等超大模型 。
这每一种选择都有优缺点，但最重要的是，小模型用起来比大模型安全得多 。如果您在用C++编程，果真需要您的LLM充斥着一大堆不相关的知识（比如“谁是美国第三任总统？”）吗？数据池越?。?３帜谌莸南喙匦跃驮饺菀祝?模型的训练成本就越低，无意中窃取他人受版权保护数据的可能性也就越小 。
2024年的DevOps团队应该彻底调研市面上所有可用的LLM选项，而不是默认选择最明显的选项 。甚至可能有必要针对不同的用例使用不止一种LLM 。


推荐阅读


上一篇：如何从头开始编写LoRA代码，这有一份教程

下一篇：又出新JS运行时了！JS运行时大盘点