通义千问, 文心一言, ChatGLM, GPT-4, Llama2, DevOps 能力评测

标签：服务 千问 Llama2 DevOps 文心 GPT 通义

引言

“克隆 dev 环境到 test 环境，等所有服务运行正常之后，把访问地址告诉我”，“检查所有项目，告诉我有哪些服务不正常，给出异常原因和修复建议”，在过去的工程师生涯中，也曾幻想过能够通过这样的自然语言指令来完成运维任务，如今 AI 助手 Appilot 利用 LLM 蕴藏的神奇力量，将这一切变成了现实。
 

今年9月，数澈软件Seal （以下简称“Seal”）开源了一款面向 DevOps 场景的 AI 助手 Appilot（github.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 是现阶段效果最好的 LLM，Appilot 也是基于 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

• Appilot：main 分支最新版本（安装步骤：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 是否具备调用多个工具完成任务的逻辑推理能力。
 

输入：

1. deploy a qwen service
2. upgrade qwen to instance ecs.c7.16xlarge
    

预期：

1. 获取到通义千问相关的模版，使用模版在阿里云上部署一个 qwen 的 ECS 实例;
2. 获取原来 qwen 服务的模版信息，修改机器类型为 ecs.c7.16xlarge 并更新服务；
    

01 GPT-4

部署通义千问服务
 

从 Reasoning 的提示和 Walrus 的后台日志中可以看到，GPT-4 调用了3个工具来完成任务：

1. find_match_template寻找与部署相关的模版。工具先通过 /v1/templates获取所有模版，然后将所有模板返回给 GPT-4，问它哪个是 qwen 相关的模版；
2. construct_service_to_create 构建要部署的目标模版，工具内部使用 RAG 来完成。这里将上一步找到的模版，加上原任务内容，发送给工具，由 RAG 的 Agent 来生成目标模版，也就是上图中的 Input；
3. create_service创建服务，将上一步构建好的模版应用到系统中；
    

部署成功后，我们可以在 Walrus 和阿里云的 ECS 控制台看到创建的资源。
 

 

升级服务
 

GPT-4 的实现与创建服务的逻辑链相似，但新增了一个步骤，即通过 get_template_schema 工具来获取已经部署的 qwen 服务，随后对 qwen 服务进行更新。
 

02 Llama2

部署通义千问服务
 

Llama2 将输入中的 qwen service 识别为一个模版的名称，所以查找模版失败了。把输入改为 deploy a qwen，Llama2 即可正确部署服务。这里可以看出 Llama2 的逻辑推理能力有些差距。
 

然而，部署成功后 Llama2 “自作聪明”地给出一段建议，内容是关于在服务部署成功后应该怎么做。可惜这不是提示词中规定的格式，因此 Appilot 识别失败报错。
 

升级服务
 

Llama2 期望使用一个名为 qwen-ecs-upgrade模版来进行升级服务，所以第一步就失败了。 一样可以看出 Llama2 的逻辑推理能力有所欠缺。
 

03 通义千问

部署通义千问服务
 

 

404 | GET     /v1/templates/qwen_service/versions?perPage=-1

200 | GET     /v1/templates?perPage=-1
404 | GET     /v1/templates/{"template_name": "qwen"}/versions?perPage=-1

 

结合错误日志和 Walrus 后台日志，可以得知：

1. 使用 deploy a qwen service作为输入时，通义千问直接以qwen_service作为模版名称，调用get_template_schema工具获取qwen_service模版，所以失败了。
2. 使用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 的逻辑推理和工具调用能力。
 

输入：

1. switch env to qa
2. list all nginx services with the name test
3. clone qa env to staging env
    

预期：

1. 默认的 Context 为dev环境，将当前的 Context 切换到 qa 环境；
2. 获取当前环境的所有服务，过滤出所有名字带有 test字段，而且跟 nginx 相关的服务 test1和 test2， test3为 spring 服务，不应列出；
3. 调用 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 环境包含了两个异常的服务：

 

输入：

1. diagnose app-1
2. fix app-1
3. diagnose app-2
    

预期：

1. 诊断出 app-1 服务使用的镜像 nginx:a.b.c 为错误的镜像；
2. 更新服务，修复为正确的镜像标签；
3. 诊断出 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?key=web&tailLines=100

查看 Walrus 日志得知，通义千问伪造了一个不存在的 resource，导致日志获取失败。正确的方式是先通过 get_service_resources 来获取 app-1关联的容器资源，再将容器名作为输入来获取日志。
 

04 文心一言

诊断app-1服务
 

400 | GET     /v1/projects/485034729423254044/environments/485040610525327900/services/app-1/resources/app-1/log?key=app&tailLines=100

结果与通义千问类似，文心一言似乎能理解诊断的任务，调用工具来获取服务 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 虽然优秀，但费用相对高昂。其它预训练大语言模型的测试表现虽然不佳，但从成本和实际落地的需求场景出发，未来依然具备一定的潜力。因此，后续工作可以考虑两个方向：

1. 针对特定的垂直领域，基于 Llama2 等开源大语言模型进行微调，从而提升性能和可靠性。除此之外还可以使用量化和其他推理加速的手段，降低大语言模型部署成本和推理的耗时，帮助 AI agent 类 LLM 应用真正落地。

2. 基于通义千问之类的大模型，即具备基础能力且部署成本较低，通过提示词优化、使用嵌入（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/

 

标签：服务,千问,Llama2,DevOps,文心,GPT,通义
From： https://www.cnblogs.com/sealio/p/17819072.html