LLM代码生成器的挑战【GDELT早期观察】

越来越多的研究开始对LLM大模型生成的代码的质量提出质疑，尽管科技行业不断推出越来越多的旨在增强甚至取代人类编码员的工具。 随着我们（GDELT）继续探索和评估越来越多的此类工具，以下是我们的一些早期观察结果。

在线工具推荐： Three.js AI纹理开发包 - YOLO合成数据生成器 - GLTF/GLB在线编辑 - 3D模型格式在线转换 - 可编程3D场景编辑器

总的来说，我们发现代码生成器的实用性仅限于少数语言的基本任务，特别是 Python 和 HTML + JavaScript。 令人惊讶的是，尽管基本 shell 脚本在几乎每个现实世界的工作流程中都无处不在，但代码生成器通常在处理琐碎任务之外的任何事情上都表现得非常糟糕。 然而，最令人震惊的是，大型科技公司提供的编码助手在涉及这些公司自己的软件包时经常近乎无用，甚至无法输出能够完成最基本任务的代码。

当被要求生成其母公司开发的一个主要库的简单演示时，一个代码生成器不断输出与该库无关的参数和管道的随机排列，这证明了 RLHF 和其他训练和调整方法的至关重要性。 这些模型。 与围绕其使用的专家相比，他们不能仅仅获得给定库的用户手册，然后要求为其生成各种函数并在大多数情况下生成成功的代码。

要求代码生成器生成一个 Python 脚本，该脚本可以将具有特定标头集的 CSV 文件读取到 Pandas 数据框中，并且任何主要工具都可以生成完全可以通过的代码。 要求它用一种不太常见的语言做同样的事情，结果通常会是胡言乱语。 常见的与 Python 相关的软件通常都有强大的支持。 但是，即使是仅限于特定领域的一级软件也往往支持较差。 例如，虽然 ImageMagick 和 ffmpeg 是图像和视频处理事实上的黄金标准，但支持却参差不齐。

例如，当要求LLM：

将 ImageMagick 的‘convert’实用程序的临时目录更改为 /dev/shm

一个主要的代码生成器在运行四次不同的时间时会产生以下结果：

convert --tempdirectory="/dev/shm/"
convert --tmpdir="/dev/shm/"
convert --workingdir="/dev/shm/"
convert --useshmtmp

尽管基本的网络搜索都会返回正确的响应，但该实用程序只是尝试了看似合理但完全错误的参数的随机组合。 虽然在某些情况下，这些错误答案仍然可以作为起点，但在这种情况下，它们对于找到正确答案没有任何价值。

一些 LLM 的 JSON 输出之前经常出现的噪音前缀“json”会怎么样？让我们要求一个主要的生成器：

从 JSON 字符串中删除json前缀

LLM返回的答案如下：

jq -r . 

不幸的是，这不是一个非常有用的答案。 考虑到 JSON 在现代数据交换中的中心地位以及在 shell 脚本中删除前缀和后缀的通用性，这也令人惊讶。

另一个常见的 JSON 相关任务表现如何？ 对于我们的 GCP Imagen 图像字幕演示，我们需要使用每个请求对图像的 Base64 版本进行编码。 我们使用如下提示：

使用 shell 命令Base64 对图像 ‘./RUSSIA1_20230215_083000_60_minut-000014.jpg’ 进行编码，并将 JSON 文件 ‘input.json’ 中的字段 ‘instances[0].image.bytesBase64Encoded’ 设置为编码后的图像。

反复运行，得到以下结果。 我们立刻明白的是，LLM 本质上是随机尝试命令行选项的不同排列，而不是根据对 jq 文档的实际理解进行操作：

jq -n -e '.instances[0].image.bytesBase64Encoded = base64(file("./RUSSIA1_20230215_083000_60_minut-000014.jpg"))' input.json > output.json 
jq -n -a '.instances[0].image.bytesBase64Encoded = base64file("./RUSSIA1_20230215_083000_60_minut-000014.jpg")' input.json > output.json 
jq -n -u '.instances[0].image.bytesBase64Encoded = base64("./RUSSIA1_20230215_083000_60_minut-000014.jpg")' input.json > output.json 
jq -n -r .instances[0].image.bytesBase64Encoded --base64 "./RUSSIA1_20230215_083000_60_minut-000014.jpg" input.json > output.json 
jq -n -b .instances[0].image.bytesBase64Encoded --encode --format base64 --inputfile "./RUSSIA1_20230215_083000_60_minut-000014.jpg" input.json > output.json 
jq -n .instances[0].image.bytesBase64Encoded --arg b64 "./RUSSIA1_20230215_083000_60_minut-000014.jpg" input.json > output.json 
jq -n --arg b64: base64("./RUSSIA1_20230215_083000_60_minut-000014.jpg") .instances[0].image.bytesBase64Encoded input.json > output.json 
jq -n --arg b64:.instances[0].image.bytesBase64Encoded base64("./RUSSIA1_20230215_083000_60_minut-000014.jpg") input.json > output.json 
jq '.instances[0].image.bytesBase64Encoded |= @base64("./RUSSIA1_20230215_083000_60_minut-000014.jpg")' input.json > output.json

对于一个代码生成器，我们甚至向它提供了 JQ 用户手册的相关部分作为提示的上下文框架，但无济于事。

这体现了开发人员和LLM驱动的代码生成器之间的一个关键区别：阅读文档的能力。 开发人员会查找 jq 的文档页面来查找其每个参数的描述，是否支持内置 Base64 编码，如果支持，如何使用它。 同时，像这样的高级用例通常不会在文档中列出，因此开发人员人员会交叉引用网络上的示例与文档并推断出他们的需求。 相比之下，这里的代码生成器似乎只是尝试对它在不同上下文中工作过的命令进行随机排列，并将它们粘合在一起，而不了解它们在 jq 中实际执行的操作或者它们是否存在。

对于像我们这样的生产环境来说至关重要的是，这些工具生成的代码通常针对可理解性和可读性进行优化，而不是针对安全性和安全性进行优化。 例如，当一个主要生成器被要求：

编写一个接受‘keyword’字段并使用它来关键字搜索 MySQL 数据库的 PHP 脚本
生成器输出了以下代码。 刚接触 SQL 的程序员可能会错过这段代码中明显的安全漏洞：

$keyword = $_POST["keyword"];
$sql = "SELECT * FROM table WHERE column_name LIKE '%$keyword%'";
$result = $conn->query($sql);

如果我们在提示中添加“安全”一词会怎么样？

编写一个接受‘keyword’字段并使用它来关键字搜索 MySQL 数据库的安全 PHP 脚本

乍一看，修改后的代码似乎完全合理，直到我们到达最后一行。 由于未知的原因，生成器生成了相当合理的代码，直到预计它会调用 execute()，然后它又恢复为不安全的代码：

$keyword = filter_input(INPUT_POST, 'keyword', FILTER_SANITIZE_STRING);
$sql = "SELECT * FROM table WHERE column_name LIKE ?";
$hand = $conn->prepare($sql);
$parm = "%$keyword%";
$hand->bind_param("s", $parm);
...
$result = $conn->query("SELECT * FROM table WHERE column_name LIKE '%" . $_POST["keyword"] . "%'");

这个特定的例子尤其阴险，因为新手程序员会错误地认为前面几行的某些内容通过全局行为改变改变了默认的 PHP 行为，而经验丰富的编码员在匆忙中可能会浏览前几行并发现它们看起来很合理 并且不向下滚动到 execute()命令（它们之间有大量注释和其他代码）并看到它被替换为 query()。

讽刺的是，当复制粘贴相同的代码并提示

此代码是否有任何漏洞？

生成器回答说：此 PHP 代码在技术上是准确的，但容易受到 SQL 注入的攻击，并使用危险的‘filter_input’函数。 目前尚不清楚它发现 filter_input有什么危险，但这次它正确地建议使用 $hand->execute()。

那么一个常见的被忽视的漏洞呢：密码硬编码。 许多开发人员将密码保存在快速测试脚本中，然后将其上传到 GitHub 等共享公共环境。 让我们问一个代码生成器

如何在 Python 脚本中安全地存储密码并防止其被读取？

令人惊讶的是，它提供了以下内容：

import base64
encodedpassword = b'BASE64ENCODEDPASSWORD'
password = base64.b64decode(encodedpassword).decode("utf-8")

第二个生成器提供了更合理的解决方案，将密码存储在脚本读取的环境变量中，但错误地解释说：环境变量提供了一种使脚本可以访问密码的安全方法。它们只能由指定的人读取 脚本，并且不能被系统上的任何其他用户或脚本访问。

虽然如果脚本是从在执行前设置环境变量的包装器 shell 脚本运行的，则情况可能是这样，但如果脚本通常作为从同一 shell 包装器运行的脚本序列的一部分运行，则情况也不会如此。 不熟悉 Unix 环境变量的程序员不一定能理解生成器解释中未说明的警告：

import os
password = os.environ.get("PASSWORD")

总的来说，我们对代码生成器的早期研究表明，对于需要快速模板代码来执行几种语言的常见任务的程序员来说，它们可以成为一个强大的助手，但当涉及到更复杂的任务或挑战时，经验丰富的程序员就会转向 StackOverflow 和其他网站 作为指导，代码生成器的作用只不过是像众所周知的键盘上的猴子一样操作。

有时，生成的排列之一虽然是错误的，但可能足够准确，可以为程序员提供找到正确答案所需的指针，但总体而言，它们在实际生产代码设计中的使用比通常描述的要有限得多。 虽然它们将像所有LLM一样不断改进，但其底层架构的基本局限性表明，公司在评估其潜力时要非常谨慎。

---

原文链接：LLM代码生成器的挑战 — BimAnt