通義千問, 文心一言, ChatGLM, GPT-4, Llama2, DevOps 能力評測

引言

“克隆 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 叢集和阿里雲。（安裝步驟：
   

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=-1200 | GET     /v1/templates?perPage=-1404 | 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 引入的錯誤，  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 ]: 
[ Walrus ]: 
[ GPT ]: 
[ Llama ]: 
[ 文心一言 ]: 
[ 通義千問 ]：
[ 阿里雲靈積平臺 ]：
[ ChatGLM ]: