个人网站开发用到的技术,成都销售型网站,手机网站建设可行性分析,想做一个静态网页网站不需要有后台数据库越来越多的研究开始对LLM大模型生成的代码的质量提出质疑#xff0c;尽管科技行业不断推出越来越多的旨在增强甚至取代人类编码员的工具。 随着我们#xff08;GDELT#xff09;继续探索和评估越来越多的此类工具#xff0c;以下是我们的一些早期观察结果。 在线工具推荐尽管科技行业不断推出越来越多的旨在增强甚至取代人类编码员的工具。 随着我们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 . string不幸的是这不是一个非常有用的答案。 考虑到 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 bBASE64ENCODEDPASSWORD
password base64.b64decode(encodedpassword).decode(utf-8)第二个生成器提供了更合理的解决方案将密码存储在脚本读取的环境变量中但错误地解释说环境变量提供了一种使脚本可以访问密码的安全方法。它们只能由指定的人读取 脚本并且不能被系统上的任何其他用户或脚本访问。
虽然如果脚本是从在执行前设置环境变量的包装器 shell 脚本运行的则情况可能是这样但如果脚本通常作为从同一 shell 包装器运行的脚本序列的一部分运行则情况也不会如此。 不熟悉 Unix 环境变量的程序员不一定能理解生成器解释中未说明的警告
import os
password os.environ.get(PASSWORD)总的来说我们对代码生成器的早期研究表明对于需要快速模板代码来执行几种语言的常见任务的程序员来说它们可以成为一个强大的助手但当涉及到更复杂的任务或挑战时经验丰富的程序员就会转向 StackOverflow 和其他网站 作为指导代码生成器的作用只不过是像众所周知的键盘上的猴子一样操作。
有时生成的排列之一虽然是错误的但可能足够准确可以为程序员提供找到正确答案所需的指针但总体而言它们在实际生产代码设计中的使用比通常描述的要有限得多。 虽然它们将像所有LLM一样不断改进但其底层架构的基本局限性表明公司在评估其潜力时要非常谨慎。 原文链接LLM代码生成器的挑战 — BimAnt
