整理丨诺亚
出品 | 51CTO技术栈（微信号：blog51cto）
当下，AI的崛起已成大势。但是，当AI的触角伸向开源操作系统时，一些社区陆续亮起了“红灯”。
先是Linux发行版Gentoo 在四月中旬发布了一项理事会政策，禁止使用AI工具生成的代码；随后，类UNIX操作系统NetBSD也于五月通过更新其提交指南，添加了类似规定。
短短一个月间，Gentoo和NetBSD的明确表态引发了广泛的讨论：在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可能更倾向于采取灵活的管理策略，关注代码的质量控制、版权合规性以及透明度，而不是简单地设立禁令。
当前技术进步带来了前所未有的自动化水平，但同时也不断开辟出需要人类创造性思维的新领域。尽管降本增效是推动技术进步的重要动力，但如何在这一进程中平衡环境影响和社会责任，成为了不可回避的议题。在这个由人工智能日益主导的世界里，如何找到人与技术和谐共生的方式，是我们之后将长久面临的议题。
参考链接： https://www.theregister.com/2024/05/18/distros_ai_code/
想了解更多AIGC的内容，请访问：
51CTO AI.x社区
https://www.51cto.com/aigc/