当前位置:首页 > 最新资讯 > 行业资讯

拒绝AI生成代码!开源操作系统陆续举起禁令

当下,AI的崛起已成大势。但是,当AI的触角伸向开源操作系统时,一些社区陆续亮起了“红灯”。

先是Linux发行版Gentoo 在四月中旬发布了一项理事会政策,禁止使用AI工具生成的代码;随后,类UNIX操作系统NetBSD也于五月通过更新其提交指南,添加了类似规定。

短短一个月间,Gentoo和NetBSD的明确表态引发了广泛的讨论:在AI的辅助下,我们真的能写出更好的代码吗?这些禁令的发布仅仅是出于对代码质量的担忧吗?禁令之下,真的能令行禁止吗?细究起来,似乎并不那么简单。

AI

1.代码质量是最不重要的一个原因

Gentoo 的政策指出了促使该决定的三个要点:代码质量、版权问题和伦理问题。

其中,代码质量是最容易理解的。尽管AI在代码生成方面取得了一定进展,但由于上下文理解受限、依赖训练数据、缺乏创造性、可维护性有待提高等因素,其生成的代码质量在很多情况下并不尽如人意。

首先,没有哪个项目愿意接受糟糕的代码。其次,人们也不希望从那些识别不出烂代码,或者自己写不出好代码,甚至不能改进 AI 生成代码的程序员那里得到帮助。因此可以说,代码质量肯定是禁令发布的考量因素之一,但也是其中最浅显、最不重要的原因。

相较之下,版权问题和伦理问题则更为复杂,它们也是 NetBSD 项目作出决定的基础。要理解这些标准的重要性,就必须了解所谓的“AI助手”到底是如何工作的。

所谓大语言模型(LLM)工具,是基于海量文本数据构建统计模型,以生成文本。它们借助包含万亿字节信息的庞大语料库,运用Transformer算法自动学习词语间的关联、序列及结构。通过这种学习,不仅能预测单个词汇,还能生成完整句子和段落,即“生成式”文本,源于对输入文本模式的学习。

事实上,只要你能负担得起足够算力,并且有足够的存储和带宽来处理数据,就能使模型产出极为逼真的内容。简言之,LLM通过学习海量文本模式,凭借强大的计算能力,实现了从预测单词到生成连贯文本的飞跃。如果在模型训练所依据的语料库中有与输入查询紧密匹配的文本,LLM就能够生成优质、连贯的答案。

2.生成式人工智能,还不那么智能

不过,能做到这一点的前提是,拥有足够丰富的语料。因此,作为输入的“语料库”包含了创建模型的团队能够免费或低成本获取的所有文本。比如社交网络和在线论坛的内容,比如源代码库。

网上有大量的复杂软件教程,这些内容已被纳入到LLM机器人的索引中。这确实是这些工具的一个极佳应用场景:针对Git等复杂程序提供定制化的教程和使用指南。

但这并不意味着机器人本身理解Git。实际上,它并不理解:它只是能生成符合众多Git教程文本模式的内容。LLM机器人能做到的是——当输入的内容中包含与你想要的答案相似的文本,它们可以非常逼真地模仿思考和解决问题的过程。

任何被标榜为“人工智能”的工具实际上并不具备智能——因为真正的智能现在被称为通用人工智能(AGI),而目前尚无人能够实现这一目标。

任何现代通用操作系统的代码库对于单人来说,其体积都太过庞大,无法整体阅读、理解和修改。以Debian项目为例,Debian 12 中有超过 1,341,564,204 行代码。

大语言模型本质上比这大了好几个数量级,并且它们不是人类可读的代码。它们是由大量机器计算出来的,这些模型无法被检查、验证或微调。正是基于这一原理,所以不可能调整它们以避免输出不符合事实的文本。

3.所有权的争议

想象一下,你正在一个基于Electron的在线编辑器里写代码。当你在敲代码时,这个聪明的工具可以把你的码字实时送到一个AI助手那里……这就像是超级加强版的自动完成功能:它能在你打字的瞬间,把你敲的代码和它语料库中数百万个模式进行匹配,然后立即给出一段几乎为你量身定制,能直接用的代码建议。

问题来了,要是你写的代码碰巧和AI学过的某个例子很像,它就可能给你吐出个匹配项。按理说,它给的建议不该和学的样本一模一样,但有时候区别就仅仅是变量名不同而已,其他部分像极了复制粘贴。

对于开源软件项目来说,这意味着如果训练数据中包含了诸如许多操作系统共有的C语言功能代码,那么由LLM驱动的编程助手生成的代码将与它们语料库中的代码极为相似。如果代码相似到足以让一个熟练的程序员识别出来,就存在违反许可的风险。机器人从其他项目中获取的代码可能会被无意中整合到其他项目中,即使没有任何人故意复制任何内容。

这就是Gentoo所指出的版权和伦理担忧的核心所在。如果LLM助手提供的代码可以追溯到其他项目,这将使Linux发行版面临所有权问题。如果意外复制的代码中包含漏洞,谁应该负责?是贡献代码的程序员——即便他们自己并没有编写这段代码?还是原创作者,他们从未贡献过这段代码,甚至不知道有机器人在复述它?

对于NetBSD而言,由于许可问题,所有这些问题都适用,甚至更为严重。虽然在线代码仓库被Linux开发者大量使用,意味着其中充满了GPL代码,但NetBSD并非采用GPL许可,而是采用BSD许可。不小心将GPL代码纳入BSD代码库是个问题:这意味着要么重新许可现有代码,要么完全替换它——这两者他们都缺乏人力去执行。

还有一个值得注意的点在于:GitHub的所有者微软并未将其任何自有操作系统的源代码输入到其LLM训练语料库中。这间接表明了即使是科技巨头也意识到了潜在的风险和挑战。

4.真的能禁止吗

如今我们已经清楚地了解了这些开源社区对AI生成代码说“不”的理由。但问题又出现了:禁令虽然发了,但真的能禁止吗?

在相关话题的讨论中,有开发者一针见血地指出了这一点:“我不清楚Gentoo或NetBSD如何能阻止包含由LLM生成的代码,因为他们依赖上游提供的修复。”

“除非每个主要发行版乃至内核,都预先对超过700家LLM公司发出警告,否则似乎没有方法能阻止这种情况,但没有任何发行版甚至内核有资金去做这件事,而且GPL许可证可能也不兼容这样的威胁(所有LLM公司只需托管用于训练数据的GPL代码副本,让人们可以下载,就可以轻松应对)。”

Debian的政策似乎就意识到了这一点。他们没有选择全面禁止,可能是因为认识到在当前开源生态系统和法律框架下,彻底阻止LLM生成代码的流入几乎是不可能的任务,而且可能还会牵涉到复杂的法律和社区合作问题。因此,Debian可能更倾向于采取灵活的管理策略,关注代码的质量控制、版权合规性以及透明度,而不是简单地设立禁令。

当前技术进步带来了前所未有的自动化水平,但同时也不断开辟出需要人类创造性思维的新领域。尽管降本增效是推动技术进步的重要动力,但如何在这一进程中平衡环境影响和社会责任,成为了不可回避的议题。在这个由人工智能日益主导的世界里,如何找到人与技术和谐共生的方式,是我们之后将长久面临的议题。

猜你喜欢

微信公众号

微信公众号