AIGC 生成代码正流行,对程序员是好还是坏?( 四 )


多轮对话的有趣之处在于,生成的代码可以通过工具运行,然后将工具的结果反馈给模型,然后模型做进一步优化,这个过程可能比人类做得更好 。
彭靖田:我最后补充一个我个人非常认同的观点,即关于“我们今天应该如何解决 AI 生成代码的安全隐患?”这个问题没有太多可讨论的,因为这与 AIGC 无关,代码就是代码,无论是谁生成的都存在安全隐患,所以我不想讨论这个问题 。
我更关注生成代码的质量高低,也就是 AI 生成代码的问题 。目前,有两种对此完全不同的观点 。有一类观点认为,每个人都应该开发自己的大模型,因此出现了很多专注于大模型的创业公司 。然而训练语料库是有限的,在 OpenAI 和其他国外大厂已经做了很多投入的情况下,是否值得从零开始开发一个大模型还需要探讨 。我们需要知道的是,一些大模型并没有特别针对编写代码这一任务进行增强,特别是当我们要在生产环境中将其作为生产力工具替代选择时 。
我们招聘一个研发工程师时为什么要写招聘要求?为什么要对研发工程师进行分类?因为他们花了很多时间进行自我训练,他们的训练来自各种类型的教程、框架手册、项目实践等 。如果你的公司有自己的代码库,可能没有开源,或者你正在进行一个特定领域的项目,有许多开源框架和基础项目代码,那么是否应该进行 fine-tuning(微调)?是否可以提升模型的权重,使通过 fine-tuning 得到的模型能够更好地解决代码生成问题,而不是从零开始开发一个模型?我认为这可能是一个可以考虑的方向 。
关于 AI 辅助编程工具的使用建议
吴少杰:三位老师平时会 AI 辅助编程工具来做些什么?是否可以提供一些使用建议?
Michael Yuan:我们团队主要使用 Copilot 来生成代码,因为它与 Github 的 IDE 结合非常紧密,我认为这一点非常重要 。如果你要在其他地方使用它,你就需要打开另一个用户界面(UI),这将增加工作量 。然而,刚才提到的多轮对话生成应用并且使用人工工具进行检查,这是一个很好的方向 。比如,我可以将它集成到问题跟踪(Issues)或讨论(Discussion)中 。
关于代码质量本身,有很多工具可供选择 。今天代码中的许多问题都源自所谓的供应链问题,这意味着你依赖于其他人的代码,如果其他人的代码出了问题,你的代码就会受到影响 。另外,复制、粘贴的代码可能会在大型模型中带来更多问题 。这段代码可能不是在 NPM 或 Cargo 的包管理器中引入的,而是来自 Apache 或其他许可证的,如果出了问题或者上游进行了修复,开发者可能并不知道,这种情况下就需要更深层次的代码检查器 。
在 AIGC 中,这种代码检查器也特别有用,其实就是用同一个工具解决可以两个问题:一个是解决代码来源和许可证不兼容的问题;另一个是,如果上游代码出了问题,有工具可以跟踪并通知开发者,然后对下游代码进行相应的更改 。
当然在编写代码后的测试是必不可少的 。我们在用的 Rust 有很多工具选择,如快速测试(fast testing) 。实际上,快速测试也是一种机器学习方法,它不断测试输入和输出边界,然后看代码是否出错 。在这方面,我认为大型开源项目会提供这种专门的服务 。我们的项目为什么加入 CNCF,主要是因为 CNCF 与 google 合作提供了这样的服务 。但这需要大量的机器时间不断地进行编译和测试 。
另外,每个项目的情况可能都不一样 。我们使用的是 Rust,因此我们有一套特定类型的工具 。而对于使用 Python 的项目,可能要用其他不同的工具,因为它没有内存安全的问题,但有其他要解决的问题 。
彭靖田:我觉得目前最好用的工具还是 AI 辅助编程工具本身 。大部分工作仍然是基于大模型进行的,开发框架的迁移还不够成熟 。
我认为从安全的角度考虑是非常重要的 。比如,对于我们要与 Autodesk 工业设计软件(如 AuthCD 和 Rivet)竞争开发的 SaaS 产品,如果接入 AI 生成的代码,需要如何处理呢?实际上,传统的软件工程方法仍然非常有用 。软件工程告诉我们需要进行环境划分、编写良好的测试用例、采用不同的测试方法,并在各个环境中有测试人员关注一些边界情况和使用场景 。
举个例子,我们有个环节是将用户上传的 CAD 图纸通过计算机视觉和深度学习算法转换为三维模型 。但建筑设计师绘制的 CAD 图纸也存在很多问题,他们没有编译器,也没有测试环境,只能依靠施工现场的人逐个解决 。这其中有两类测试问题:一种是代码确实存在问题,这类问题可以通过软件工程的方法解决;还有一类问题更偏向于算法和领域场景,即输入数据本身就不够健壮和稳定,这种设计上的问题需要进行降级处理,捕捉异常 。


推荐阅读