营销型网站需要备案吗,长沙装修公司口碑比较好的,网站管理权限怎么进去,一个空间怎么放两个网站引言
“克隆 dev 环境到 test 环境#xff0c;等所有服务运行正常之后#xff0c;把访问地址告诉我”#xff0c;“检查所有项目#xff0c;告诉我有哪些服务不正常#xff0c;给出异常原因和修复建议”#xff0c;在过去的工程师生涯中#xff0c;也曾幻想过能够通过这…引言
“克隆 dev 环境到 test 环境等所有服务运行正常之后把访问地址告诉我”“检查所有项目告诉我有哪些服务不正常给出异常原因和修复建议”在过去的工程师生涯中也曾幻想过能够通过这样的自然语言指令来完成运维任务如今 AI 助手 Appilot 利用 LLM 蕴藏的神奇力量将这一切变成了现实。
今年9月数澈软件Seal 以下简称“Seal”开源了一款面向 DevOps 场景的 AI 助手 Appilotgithub.com/seal-io/appilot让工程师通过自然语言交互即可实现应用管理、环境管理、故障诊断、混合基础设施编排等应用生命周期管理功能。
目前 Appilot 以 GPT-4 为基准进行开发测试。GPT-4 是当前最强的大模型之一能够将一个复杂任务按照思维链条分解为多个可以单独执行的子任务并根据返回继续执行新的子任务表现出极强的表达和推理能力。在开发过程中GPT-4 也常常给作者带来意想不到的惊喜。但是较慢的推理速度相对昂贵的使用费用还有潜在的数据安全问题都让我们期待是否能通过使用国产在线 LLM 服务或者部署私有开源的 LLM 来完成同样的管理任务。
本文将探讨在 Appilot 的场景下GPT 以外的 LLM 有着怎样的表现。
基本工作原理
在评测之前我们先简单地介绍 Prompt 工程和 Appilot 实现的基本原理。
Walrus
Walrus 是一款开源的基于平台工程理念、以应用为中心、以完整应用系统自动化编排交付为目标进行设计开发的云原生应用平台。在本文中Appilot 将使用 Walrus 作为基座进行应用管理Walrus 并非 Appilot 唯一指定基座您可以接入熟悉的平台例如 Kubernetes。
在 Walrus 中项目作为应用系统的工作空间每个项目可管理多个应用环境例如应用的开发、测试、预发布、生产、双活、灰度等环境在每个环境中可以使用 Walrus 模板部署多种类型的服务包括运行在 K8s 上或弹性容器实例上的容器化应用、传统部署应用、RDS 之类的各种公有云资源以及配置 LB/DNS 等各种私有基础设施资源等。
RAG
RAG 的全称为 Retrieval-Augmented Generation即检索增强生成。目前 LLM 主要用于文本生成生成效果取决于预训练的数据。如果问题涉及到训练数据领域外的知识获取正确答案的概率就会大幅降低。例如 GPT-4 的训练数据截止到 2021 年 9 月如果提问 2022 年新增的名词GPT-4 则无法给出正确答案。
为了解决这一问题可以在 Prompt 时引入外部数据源配合原始任务来生成更好的结果这一方法也被称为检索增强Retrieval-Augmented。
在 Appilot 中部署服务需要对应的模板这个模板的定义由底层的云原生应用平台 Walrus 提供。在每次执行一个部署任务时Appilot 会先从 Walrus 找出相关的模板然后将其和原始任务一起发送给 LLM由 LLM 选择对应的模板生成最终的服务部署配置。
Agent
LLM 在自然语言理解方面的突破使得人机交互的门槛大大降低——我们可以像与人沟通一样与机器进行交流。
但仅靠 LLM只能完成一些文本、图片生成的任务。为了释放 LLM 的全部潜力我们要构建一个系统以获取外部信息和应用外部工具来解决实际问题这就是 Agent 的用武之地。
下图是 Agent 的实现框架LLM 作为 Agent 的大脑负责理解任务、拆分任务、并调用工具执行任务每次生成工具的调用历史记录通过任务结果分析和工具调用不断循环最终得出目标结果。之前爆红的全自动人工智能助手 AutoGPT 也是采用这一思路实现。 在 Appilot 的实现中我们遵循相同的设计把应用管理相关的工具集放到 Prompt 中让 LLM 来决定如何调用工具。
模型选择
我们选择以下5个流行的 LLM 加入本次的评测范围。
GPT-4
GPT-4 是现阶段效果最好的 LLMAppilot 也是基于 GPT-4 进行开发所以本次测试将其作为基准。
Llama2
Llama2 是 Meta 公司发布的开源模型因其不错的性能和可免费商用引起广泛关注。本次测试使用的是 Llama2 的Llama2-70B-Chat 模型部署在 AWS 的 Sagemaker 平台上使用的机器规格是ml.g5.48xlarge。
通义千问
通义千问是阿里云研发的大语言系列模型在 Huggingface 和魔搭社区上有对应的开源版本。本次测试使用的是阿里云灵积平台上在线版本的Qwen-14B-Chat模型。
文心一言
文心一言是百度研发的大语言模型近期发布了 4.0 版本。本次测试使用的是百度智能云上在线版本的ERNIE-Bot-4模型。
ChatGLM
ChatGLM 是由清华大学 KEG 实验室和智谱 AI 基于千亿基座模型 GLM-130B 开发的支持中英双语的对话语言模型具备多领域知识、代码能力、常识推理及运用能力。支持与用户通过自然语言对话进行交互处理多种自然语言任务。本次测试使用的是智谱 AI 在线版本的 ChatGLM-Turbo 模型。
省流版TL;DR
先放评测结论在市面上的所有预训练大语言模型中针对 Appilot 这样的 AI agent 场景GPT-4 依然是“名列前茅”的优等生独一档的存在。 注本评测仅针对 Appilot 所面向的使用 AI agent 来进行应用管理的场景评测结果仅为一家之言不做为对其它 LLM 应用领域大模型效果的排名依据。 除了 GPT-4 以外其余4款大语言模型**Llama2、通义千问、文心一言、ChatGLM **按表现来说基本是不可用的远远低于我们的期望和模型提供方所宣传的效果。一方面这些大模型在能力和成熟度上仍然还需努力另一方面 Appilot 在对接这些大模型时还需要用到更多的提示词优化、微调等技术进行完善。
此次评测只是阶段性的评测考虑到目前大模型领域仍然高速发展GPT-4-Turbo、通义千问2.0、ChatGLM3 等更新的大模型版本还未正式上线未来我们将保持每半年一次的评测频率持续跟进主流大模型在 AI agent 场景下对 DevOps 这样的垂直领域的实际应用效果。也会加入更多的评测内容例如中文对话、更完善的用例设计、更多的大模型等更加综合具体地评估各个大模型的表现。
接下来我们来看详细的评测过程。
测试案例
因为 LLM 输出不稳定在本测试中每个测试案例均运行多次取其中最优结果。
测试环境 测试设备Apple M1 Pro 笔记本 Kubernetes本地部署 K8s 集群版本为1.27.4 Appilotmain 分支最新版本安装步骤github.com/seal-io/appilot#quickstart Walrus版本为 0.3.1并在 default 项目下创建了 dev、test 和 qa 环境每个环境都连接了本地的 K8s 集群和阿里云。安装步骤https://seal-io.github.io/docs/zh/quickstart
Case 0列出当前环境的所有服务
目标测试 LLM 是否具备调用工具和按照提示词输出的能力。
输入list services
预期正确调用list_services工具来获取当前环境的服务。
01 GPT-4 可以看出 GPT-4 能正确调用list_services工具并将结果简化格式化输出几个常用字段。
02 Llama2 输入 list services 后 Appilot 直接报错原因是 Llama2 没有按照 Prompt 规定的格式进行输出缺少了 Action Input 关键字所以 LangChain 默认解析失败修改正则表达式后可以正常输出。 不过输出为原始格式并没有像 GPT-4 那样按照 Appilot 预置的 Prompt 要求将输出内容用 markdown 语法进行格式化输出。
03 通义千问 通义千问可以正常格式化输出与 GPT-4 的结果对比发现缺少 Template Version增加 Service ID判断为不同大模型对输出参数的重要性理解差异。
04 文心一言 接入文心一言后任务报错提示输入文本太长不能超过4800的长度为文心一言的输入长度限制。 即便通过缩减 Appilot 的工具集来减短提示词输入后获取的结果也不尽如人意。
大部分结果无法遵循输出格式。即便一些结果符合提示词要求的格式但基本为编造如上图 my-service 、another-service 等全是不存在的服务都是文心一言伪造的输出即文心一言无法正确调用 list_services 工具。
为了支持后面的测试 Case 能正常运行在使用文心一言时会在保留正确工具的同时尽可能缩减 Appilot 的工具集。
05 ChatGLM ChatGLM 的输出结果也是编造的它所列出的都是不存在的服务与文心一言一致。
本轮评测结果 Case 1部署服务
目标本用例以“在阿里云上部署一个通义千问模型服务”为任务测试 LLM 是否具备调用多个工具完成任务的逻辑推理能力。
输入
deploy a qwen serviceupgrade qwen to instance ecs.c7.16xlarge
预期
获取到通义千问相关的模版使用模版在阿里云上部署一个 qwen 的 ECS 实例;获取原来 qwen 服务的模版信息修改机器类型为 ecs.c7.16xlarge 并更新服务
01 GPT-4
部署通义千问服务 从 Reasoning 的提示和 Walrus 的后台日志中可以看到GPT-4 调用了3个工具来完成任务
find_match_template寻找与部署相关的模版。工具先通过 /v1/templates获取所有模版然后将所有模板返回给 GPT-4问它哪个是 qwen 相关的模版construct_service_to_create 构建要部署的目标模版工具内部使用 RAG 来完成。这里将上一步找到的模版加上原任务内容发送给工具由 RAG 的 Agent 来生成目标模版也就是上图中的 Inputcreate_service创建服务将上一步构建好的模版应用到系统中
部署成功后我们可以在 Walrus 和阿里云的 ECS 控制台看到创建的资源。 升级服务 GPT-4 的实现与创建服务的逻辑链相似但新增了一个步骤即通过 get_template_schema 工具来获取已经部署的 qwen 服务随后对 qwen 服务进行更新。
02 Llama2
部署通义千问服务 Llama2 将输入中的 qwen service 识别为一个模版的名称所以查找模版失败了。把输入改为 deploy a qwenLlama2 即可正确部署服务。这里可以看出 Llama2 的逻辑推理能力有些差距。 然而部署成功后 Llama2 “自作聪明”地给出一段建议内容是关于在服务部署成功后应该怎么做。可惜这不是提示词中规定的格式因此 Appilot 识别失败报错。
升级服务 Llama2 期望使用一个名为 qwen-ecs-upgrade模版来进行升级服务所以第一步就失败了。 一样可以看出 Llama2 的逻辑推理能力有所欠缺。
03 通义千问
部署通义千问服务 404 | GET /v1/templates/qwen_service/versions?perPage-1200 | GET /v1/templates?perPage-1
404 | GET /v1/templates/{template_name: qwen}/versions?perPage-1结合错误日志和 Walrus 后台日志可以得知
使用 deploy a qwen service作为输入时通义千问直接以qwen_service作为模版名称调用get_template_schema工具获取qwen_service模版所以失败了。使用deploy qwen作为输入通义千问能调用find_matching_template工具来查找模版但是结果输出为一个 json 结构并将其作为下一步 get_template_schema的输入所以也失败了。 升级服务
因为前一步无法创建服务所以先手动创建了一个 qwen 服务。 通义千问将任务错误识别为部署一个新的服务反而“阴差阳错”地执行了上一步的任务。
可以看出通义千问对需要处理多步骤的复杂任务的逻辑推理能力也有所欠缺。
04 文心一言
部署通义千问服务 部署提示已经构造了服务对象。 打开 VERBOSE 开关查看原始提示词看到文心一言编造了一系列调用记录。
升级服务 这里看到文心一言输出的 json 结构也是编造的。
05 ChatGLM
部署通义千问服务 部署提示已经构造了服务对象但实际并没有。 同样ChatGLM 编造了一系列调用记录。
升级服务 ChatGLM 声称完成了升级但检查系统发现也是幻觉。
本轮评测结果 Case 2在K8s上部署从源码构建的spring-boot服务
目标测试 LLM 逻辑推理和 RAG 模版生成能力。
输入
deploy seal-demo/spring-boot-docker-sample:feature, configure registry auth with project env, push image to rainfd/spring预期 获取到从源码部署相关的模版填入目标的 GitHub 地址、Docker Hub 相关环境变量和镜像名称最后成功部署。
01 GPT-4 推理逻辑与 Case1 一致能正确填入输入中的 image 和 GitHub 地址并使用环境变量配置 Registry 认证相关的两个参数。
02 Llama2 Llama2 将输入中的 GitHub 仓库地址识别为模版名称 spring-boot-docker-sample所以直接失败了。
03 通义千问 通义千问将输入的deploy service 识别为模版名称可以推断通义千问没有理解这个输入的正确含义。
04 文心一言 文心一言仍未能按照规定的提示词进行输出而是输出一个自己伪造的 json 结构并将一些任务相关的内容填入到伪造的 json 内容中。
05 ChatGLM ChatGLM 能够调用正确的工具并构建了部署服务的请求体但推理能力较差导致缺失了部分配置使得虽然创建了服务但最终的部署没有成功。
本轮评测结果 Case 3切换环境、过滤服务、克隆环境
目标测试 LLM 的逻辑推理和工具调用能力。
输入
switch env to qalist all nginx services with the name testclone qa env to staging env
预期
默认的 Context 为dev环境将当前的 Context 切换到 qa 环境获取当前环境的所有服务过滤出所有名字带有 test字段而且跟 nginx 相关的服务 test1和 test2 test3为 spring 服务不应列出调用 clone_environment 工具克隆qa环境到 staging 环境
01 GPT-4
切换环境、过滤服务 GPT-4 能正确完成切换环境和过滤服务的操作。
克隆服务 克隆环境成功后可以在 Walrus 中看到一个新的 staging 环境并且其中正常部署着与 qa 环境相同的3个服务。
02 Llama2
切换环境 从 Reasoning 可以看到在 Llama2 的推理步骤中第一步尚能正确理解任务但是第二步开始跑偏最终从切换环境一步步跑偏到要执行部署任务。
过滤服务 从 Llama2 的“错误结果”可以看到已经调用 list_services获取了当前环境的所有服务但需要进一步过滤时直接返回了不遵循格式的输出导致 Appilot 无法识别而报错。
克隆环境 Llama2 能正确理解任务并调用 clone_environment工具但是输入伪造了一个 id。
03 通义千问
切换环境 通义千问能够正确切换环境。
过滤服务 通义千问似乎也能正确调用 list_services工具但是结果为空。 打开 VERBOSE 开关查看原始提示词发现通义千问产生了已经将结果返回的幻觉也没有进一步按照要求过滤服务。
克隆环境 通义千问克隆环境调用正确。
04 文心一言
切换环境 文心一言输出的 json 结果是 change_context工具的输入但是project_name 是伪造实际名称为default。
过滤服务 文心一言这里输出的格式虽然符合提示词中的格式要求但是从 Reasoning 中看到并没有调用工具获取当前环境的服务而是伪造了一个结果。
克隆环境 文心一言的输出格式错误但看起来似乎只是格式不对但 Action 中的工具还是错的不存在 clone_env 这个工具正确的是 clone_environment。
05 ChatGLM
切换环境 ChatGLM 可以正确切换环境。
过滤服务 ChatGLM 对服务过滤的结果是编造的。
克隆环境 虽然推理逻辑不太对但 ChatGLM 选择了正确的工具调用完成了克隆环境。
本轮评测结果 Case 4查看故障服务尝试诊断故障并修复问题
目标测试 LLM 对诊断场景的逻辑推理能力。
当前 test 环境包含了两个异常的服务 输入
diagnose app-1fix app-1diagnose app-2
预期
诊断出 app-1 服务使用的镜像 nginx:a.b.c 为错误的镜像更新服务修复为正确的镜像标签诊断出 app-2 服务日志中的代码错误。
01 GPT-4
诊断修复 app-1 服务 可以看到 GPT-4 正确利用现有的工具获取 app-1 服务的相关信息包括服务详情、服务相关的资源和服务日志。识别到错误后更新了 app-1 服务将错误的 Image 修改为正确的 nginx:latest 。
诊断 app-2 服务 GPT-4 获取 app-2的日志后诊断代码文件 Application.java 在16行附近有一个 str 的值是 null所以不能调用 String.length()方法。
我们可以看看在原始代码中 commit 引入的错误https://github.com/seal-demo/spring-boot-docker-sample/commit/147e087d9368e60cd0402d864964cadf8e1daacb。与 GPT-4 描述的完全一致。 02 Llama2
诊断app-1服务 从前几步看似乎 Llama2 能理解诊断任务并不断获取 app-1的相关信息但是在获取服务详情的那一步报错。
404 | HTTP/1.1 | GET /v1/projects/485034729423254044/environments/485040610525327900/services/{
service_id: app-1
}/resources
404 | HTTP/1.1 | GET /v1/projects/485034729423254044/environments/485040610525327900/services/{
service_id: app-1
}查看 Walrus 日志发现Llama2 将{service_id: app-1}作为输入来查询服务所以任务中断。
03 通义千问
诊断app-1服务 Reasoning 中看到通义千问能理解任务但是获取服务日志失败。
400 | GET /v1/projects/485034729423254044/environments/485040610525327900/services/app-1/resources/app-1.0.0.1/log?keywebtailLines100查看 Walrus 日志得知通义千问伪造了一个不存在的 resource导致日志获取失败。正确的方式是先通过 get_service_resources 来获取 app-1关联的容器资源再将容器名作为输入来获取日志。
04 文心一言
诊断app-1服务 400 | GET /v1/projects/485034729423254044/environments/485040610525327900/services/app-1/resources/app-1/log?keyapptailLines100结果与通义千问类似文心一言似乎能理解诊断的任务调用工具来获取服务 app-1的相关信息但在使用工具获取日志时编造了 resource 的名字因此获取日志失败。
05 ChatGLM
诊断app-1服务 ChatGLM 其结果是与实际情况无关的幻觉。
在本 Case 中除了 GPT-4 以外评测的其它大模型都无法通过第一个较为简单的诊断任务更别说更复杂的第二个任务了。
本轮评测结果 成本对比
这里以 Case 0 为例测试在 Appilot 中输入 list services 时调用基础工具 list_service 需要的相关耗费美元兑人民币按1:7折算 注其中 Llama2 模型按照本次测试使用的 AWS ml.g5.48xlarge 实例包年包月价格$6.515/小时非并发推理计算) 总 结
根据上述评测过程在 Appilot 的应用场景下可以得出以下结论
市面上的所有预训练大语言模型中针对类似于 Appilot 的 AI agent 场景GPT-4 依然独领风骚。跟 GPT-4 相比其他大语言模型还有较大的差距主要体现在以下三个方面 遵循提示词格式的能力AI agent 通常具有较长上下文的提示词大语言模型需要遵循提示词中规定的输出格式来获取调用的工具和输入参数。如果大模型返回结果的格式无法遵循要求几乎无法解析成为下一步工具调用的输入 逻辑推理能力GPT-4 能够完成多个工具调用的推理链条配合完成复杂任务其他模型的推理能力不足难以完成需要多步骤调用工具完成目标的复杂任务 输出的稳定性即使将输出多样性的参数 temperature 调至最低在输入相同的情况下一些大语言模型依然会产生不稳定的输出。 除了 GPT-4 以外其余评测的4款大语言模型的具体体验如下 Llama2如果是简单输入场景Llama2 能跟对应的工具进行关联。大部分能根据提示词找到对应工具并按照规定格式正确输出内容。如果输入复杂完成任务需要多个工具的配合那么它极少地展现它的复杂推理能力更多时间是答非所问。即便正确调用工具后偶尔还会输出一些看似与输入相关但实则与提示词规定无关的内容。 通义千问在简单输入的场景下通义千问一般都能正确调用工具获取结果相较 Llama2 稳定。但在复杂输入的场景下千问的推理能力短板也暴露出来了基本无能为力。 文心一言4800的输入限制几乎使得文心一言直接“退赛”即使精简了 Appilot 的工具集从测试效果上看文心一言也是这几个模型中最差的不仅大多数情况下都不能按照提示词规定的格式输出内容还常常编造与提示词和输入完全无关的结果幻觉过多。 ChatGLM与通义千问类似部分简单场景下可以获取预期结果但无法处理需要多步骤执行的复杂任务。 除上述几个模型外作者还尝试了其他的模型例如 Xwin-LM-70B-V0.1、Mistral-7B-Instruct-v0.1 等模型但它们的测试结果与文心一言的结果类似基本无法按照提示词给定的格式进行输出直接无法使用。
按实际表现来说除了 GPT-4 以外的这些大模型基本是不可用的远远低于我们的期望和模型提供方所宣传的效果。一方面这些大模型在能力和成熟度上仍然还需努力另一方面 Appilot 在对接这些大模型时还需要用到更多的提示词优化、微调等技术进行完善。
从模型的耗时和成本对比可以看到GPT-4 虽然优秀但费用相对高昂。其它预训练大语言模型的测试表现虽然不佳但从成本和实际落地的需求场景出发未来依然具备一定的潜力。因此后续工作可以考虑两个方向 针对特定的垂直领域基于 Llama2 等开源大语言模型进行微调从而提升性能和可靠性。除此之外还可以使用量化和其他推理加速的手段降低大语言模型部署成本和推理的耗时帮助 AI agent 类 LLM 应用真正落地。 基于通义千问之类的大模型即具备基础能力且部署成本较低通过提示词优化、使用嵌入Embedding技术以及进行 Few-shot 学习等优化方向来增强 LLM 应用的准确性。 上述大语言模型的测试汇总记录如下 此次评测只是阶段性的评测考虑到目前大模型领域仍然高速发展GPT-4-Turbo、通义千问2.0、ChatGLM3 等更新的大模型版本还未正式上线未来我们将保持每半年一次的评测频率持续跟进主流大模型在 AI agent 场景下对 DevOps 这样的垂直领域的实际应用效果。也会加入更多的评测内容例如中文对话、更完善的用例设计、更多的大模型等更加综合具体地评估各个大模型的表现。 相关链接 [ Appilot ]: https://github.com/seal-io/appilot [ Walrus ]: https://github.com/seal-io/walrus [ GPT ]: https://chat.openai.com/ [ Llama ]: https://ai.meta.com/llama/ [ 文心一言 ]: https://yiyan.baidu.com/ [ 通义千问 ]https://qianwen.aliyun.com/ [ 阿里云灵积平台 ]https://dashscope.aliyun.com/ [ ChatGLM ]: https://chatglm.cn/
