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

关注并星标🌟 ⌈Seal软件⌋ 💻

获取平台工程及应用部署最佳实践

“克隆 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 进行开发，所以本次测试将其作为基准。

通义千问

通义千问是阿里云研发的大语言系列模型，在 Huggingface 和魔搭社区上有对应的开源版本。本次测试使用的是阿里云灵积平台上在线版本的Qwen-14B-Chat模型。

ChatGLM

ChatGLM 是由清华大学 KEG 实验室和智谱 AI 基于千亿基座模型 GLM-130B 开发的支持中英双语的对话语言模型，具备多领域知识、代码能力、常识推理及运用能力。支持与用户通过自然语言对话进行交互，处理多种自然语言任务。本次测试使用的是智谱 AI 在线版本的 ChatGLM-Turbo 模型。

先放评测结论：在市面上的所有预训练大语言模型中，针对 Appilot 这样的 AI agent 场景，GPT-4 依然是“名列前茅”的优等生，独一档的存在。

除了 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工具来获取当前环境的服务。

可以看出 GPT-4 能正确调用list_services工具，并将结果简化，格式化输出几个常用字段。

输入 list services 后 Appilot 直接报错，原因是 Llama2 没有按照 Prompt 规定的格式进行输出，缺少了 Action Input 关键字，所以 LangChain 默认解析失败，修改正则表达式后可以正常输出。

即便通过缩减 Appilot 的工具集来减短提示词输入后，获取的结果也不尽如人意。

大部分结果无法遵循输出格式。即便一些结果符合提示词要求的格式，但基本为编造，如上图 my-service 、another-service 等全是不存在的服务，都是文心一言伪造的输出，即文心一言无法正确调用 list_services 工具。

为了支持后面的测试 Case 能正常运行，在使用文心一言时，会在保留正确工具的同时，尽可能缩减 Appilot 的工具集。

ChatGLM 的输出结果也是编造的，它所列出的都是不存在的服务，与文心一言一致。

 Case 1：部署服务

输入：

1. deploy a qwen service

2. upgrade qwen to instance ecs.c7.16xlarge

预期：

1. 获取到通义千问相关的模版，使用模版在阿里云上部署一个 qwen 的 ECS 实例；

2. 获取原来 qwen 服务的模版信息，修改机器类型为 ecs.c7.16xlarge 并更新服务；

部署通义千问服务

1.  find_match_template寻找与部署相关的模版。工具先通过  /v1/templates获取所有模版，然后将所有模板返回给 GPT-4，问它哪个是 qwen 相关的模版；

2. construct_service_to_create 构建要部署的目标模版，工具内部使用 RAG 来完成。这里将上一步找到的模版，加上原任务内容，发送给工具，由 RAG 的 Agent 来生成目标模版，也就是上图中的 Input；

3.  create_service创建服务，将上一步构建好的模版应用到系统中；

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

升级服务

部署通义千问服务

升级服务

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

部署通义千问服务

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

1.  使用 deploy a qwen service作为输入时，通义千问直接以qwen_service作为模版名称，调用get_template_schema工具获取qwen_service模版，所以失败了。

2. 使用deploy qwen作为输入，通义千问能调用find_matching_template工具来查找模版，但是结果输出为一个 json 结构，并将其作为下一步 get_template_schema的输入，所以也失败了。

升级服务

因为前一步无法创建服务，所以先手动创建了一个 qwen 服务。

部署通义千问服务

升级服务

部署通义千问服务

升级服务

输入：

deploy seal-demo/spring-boot-docker-sample:feature, configure registry auth with project env, push image to rainfd/spring

预期：

获取到从源码部署相关的模版，填入目标的 GitHub 地址、Docker Hub 相关环境变量和镜像名称，最后成功部署。

目标：测试 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 环境；

切换环境、过滤服务

GPT-4 能正确完成切换环境和过滤服务的操作。

克隆服务

克隆环境成功后，可以在 Walrus 中看到一个新的 staging 环境，并且其中正常部署着与 qa 环境相同的3个服务。

过滤服务

克隆环境

切换环境

通义千问能够正确切换环境。

过滤服务

克隆环境

切换环境

过滤服务

克隆环境

切换环境

过滤服务

克隆环境

目标：测试 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 服务日志中的代码错误。

诊断修复 app-1 服务

诊断 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 描述的完全一致。

诊断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关联的容器资源，再将容器名作为输入来获取日志。

诊断app-1服务

诊断app-1服务

根据上述评测过程，在 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 这样的垂直领域的实际应用效果。也会加入更多的评测内容，例如中文对话、更完善的用例设计、更多的大模型等，更加综合具体地评估各个大模型的表现。