引言

“克隆 dev 環(huán)境到 test 環(huán)境，等所有服務運行正常之后，把訪問地址告訴我”，“檢查所有項目，告訴我有哪些服務不正常，給出異常原因和修復建議”，在過去的工程師生涯中，也曾幻想過能夠通過這樣的自然語言指令來完成運維任務，如今 AI 助手 Appilot 利用 LLM 蘊藏的神奇力量，將這一切變成了現(xiàn)實。
?

今年9月，數(shù)澈軟件Seal （以下簡稱“Seal”）開源了一款面向 DevOps 場景的 AI 助手 Appilot（github.com/seal-io/appilot），讓工程師通過自然語言交互即可實現(xiàn)應用管理、環(huán)境管理、故障診斷、混合基礎設施編排等應用生命周期管理功能。
?

目前 Appilot 以 GPT-4 為基準進行開發(fā)測試。GPT-4 是當前最強的大模型之一，能夠將一個復雜任務按照思維鏈條分解為多個可以單獨執(zhí)行的子任務，并根據(jù)返回繼續(xù)執(zhí)行新的子任務，表現(xiàn)出極強的表達和推理能力。在開發(fā)過程中，GPT-4 也常常給作者帶來意想不到的驚喜。但是較慢的推理速度，相對昂貴的使用費用，還有潛在的數(shù)據(jù)安全問題，都讓我們期待是否能通過使用國產(chǎn)在線 LLM 服務或者部署私有開源的 LLM 來完成同樣的管理任務。
?

本文將探討在 Appilot 的場景下，GPT 以外的 LLM 有著怎樣的表現(xiàn)。
?

基本工作原理

在評測之前，我們先簡單地介紹 Prompt 工程和 Appilot 實現(xiàn)的基本原理。
?

Walrus

Walrus 是一款開源的基于平臺工程理念、以應用為中心、以完整應用系統(tǒng)自動化編排交付為目標進行設計開發(fā)的云原生應用平臺。在本文中，Appilot 將使用 Walrus 作為基座進行應用管理（Walrus 并非 Appilot 唯一指定基座，您可以接入熟悉的平臺，例如 Kubernetes）。
?

在 Walrus 中，項目作為應用系統(tǒng)的工作空間，每個項目可管理多個應用環(huán)境，例如應用的開發(fā)、測試、預發(fā)布、生產(chǎn)、雙活、灰度等環(huán)境，在每個環(huán)境中可以使用 Walrus 模板部署多種類型的服務，包括運行在 K8s 上或彈性容器實例上的容器化應用、傳統(tǒng)部署應用、RDS 之類的各種公有云資源，以及配置 LB/DNS 等各種私有基礎設施資源等。
?

RAG

RAG 的全稱為 Retrieval-Augmented Generation，即檢索增強生成。目前 LLM 主要用于文本生成，生成效果取決于預訓練的數(shù)據(jù)。如果問題涉及到訓練數(shù)據(jù)領域外的知識，獲取正確答案的概率就會大幅降低。例如 GPT-4 的訓練數(shù)據(jù)截止到 2021 年 9 月，如果提問 2022 年新增的名詞，GPT-4 則無法給出正確答案。
?

為了解決這一問題，可以在 Prompt 時引入外部數(shù)據(jù)源，配合原始任務來生成更好的結果，這一方法也被稱為檢索增強（Retrieval-Augmented）。
?

在 Appilot 中，部署服務需要對應的模板，這個模板的定義由底層的云原生應用平臺 Walrus 提供。在每次執(zhí)行一個部署任務時，Appilot 會先從 Walrus 找出相關的模板，然后將其和原始任務一起發(fā)送給 LLM，由 LLM 選擇對應的模板，生成最終的服務部署配置。
?

Agent

LLM 在自然語言理解方面的突破，使得人機交互的門檻大大降低——我們可以像與人溝通一樣與機器進行交流。
?

但僅靠 LLM，只能完成一些文本、圖片生成的任務。為了釋放 LLM 的全部潛力，我們要構建一個系統(tǒng)，以獲取外部信息和應用外部工具來解決實際問題，這就是 Agent 的用武之地。
?

下圖是 Agent 的實現(xiàn)框架，LLM 作為 Agent 的大腦，負責理解任務、拆分任務、并調(diào)用工具執(zhí)行任務，每次生成工具的調(diào)用歷史記錄，通過任務結果分析和工具調(diào)用不斷循環(huán)，最終得出目標結果。之前爆紅的全自動人工智能助手 AutoGPT 也是采用這一思路實現(xiàn)。

?

在 Appilot 的實現(xiàn)中，我們遵循相同的設計，把應用管理相關的工具集放到 Prompt 中，讓 LLM 來決定如何調(diào)用工具。
?

模型選擇

我們選擇以下5個流行的 LLM 加入本次的評測范圍。
?

GPT-4
?

GPT-4 是現(xiàn)階段效果最好的 LLM，Appilot 也是基于 GPT-4 進行開發(fā)，所以本次測試將其作為基準。
?

Llama2
?

Llama2 是 Meta 公司發(fā)布的開源模型，因其不錯的性能和可免費商用，引起廣泛關注。本次測試使用的是 Llama2 的Llama2-70B-Chat 模型，部署在 AWS 的 Sagemaker 平臺上，使用的機器規(guī)格是ml.g5.48xlarge。
?

通義千問
?

通義千問是阿里云研發(fā)的大語言系列模型，在 Huggingface 和魔搭社區(qū)上有對應的開源版本。本次測試使用的是阿里云靈積平臺上在線版本的Qwen-14B-Chat模型。
?

文心一言
?

文心一言是百度研發(fā)的大語言模型，近期發(fā)布了 4.0 版本。本次測試使用的是百度智能云上在線版本的ERNIE-Bot-4模型。
?

ChatGLM
?

ChatGLM 是由清華大學 KEG 實驗室和智譜 AI 基于千億基座模型 GLM-130B 開發(fā)的支持中英雙語的對話語言模型，具備多領域知識、代碼能力、常識推理及運用能力。支持與用戶通過自然語言對話進行交互，處理多種自然語言任務。本次測試使用的是智譜 AI 在線版本的 ChatGLM-Turbo 模型。
?

省流版（TL;DR）

先放評測結論：在市面上的所有預訓練大語言模型中，針對 Appilot 這樣的 AI agent 場景，GPT-4 依然是“名列前茅”的優(yōu)等生，獨一檔的存在。
?

注：本評測僅針對 Appilot 所面向的使用 AI agent 來進行應用管理的場景，評測結果僅為一家之言，不做為對其它 LLM 應用領域大模型效果的排名依據(jù)。

?文章來源地址http://www.zghlxwxcb.cn/news/detail-752903.html

除了 GPT-4 以外，其余4款大語言模型（**Llama2、通義千問、文心一言、ChatGLM **）按表現(xiàn)來說基本是不可用的，遠遠低于我們的期望和模型提供方所宣傳的效果。一方面這些大模型在能力和成熟度上仍然還需努力，另一方面 Appilot 在對接這些大模型時，還需要用到更多的提示詞優(yōu)化、微調(diào)等技術進行完善。
?

此次評測只是階段性的評測，考慮到目前大模型領域仍然高速發(fā)展，GPT-4-Turbo、通義千問2.0、ChatGLM3 等更新的大模型版本還未正式上線，未來我們將保持每半年一次的評測頻率，持續(xù)跟進主流大模型在 AI agent 場景下，對 DevOps 這樣的垂直領域的實際應用效果。也會加入更多的評測內(nèi)容，例如中文對話、更完善的用例設計、更多的大模型等，更加綜合具體地評估各個大模型的表現(xiàn)。
?

接下來，我們來看詳細的評測過程。
?

測試案例

因為 LLM 輸出不穩(wěn)定，在本測試中每個測試案例均運行多次，取其中最優(yōu)結果。
?

測試環(huán)境

• 測試設備：Apple M1 Pro 筆記本

• Kubernetes：本地部署 K8s 集群，版本為1.27.4

• Appilot：main 分支最新版本（安裝步驟：github.com/seal-io/appilot#quickstart）

• Walrus：版本為 0.3.1，并在 default 項目下創(chuàng)建了 dev、test 和 qa 環(huán)境，每個環(huán)境都連接了本地的 K8s 集群和阿里云。（安裝步驟：https://seal-io.github.io/docs/zh/quickstart）
  ?

Case 0：列出當前環(huán)境的所有服務

目標：測試 LLM 是否具備調(diào)用工具和按照提示詞輸出的能力。
?

輸入：list services
?

預期：正確調(diào)用list_services工具來獲取當前環(huán)境的服務。
?

01 GPT-4

可以看出 GPT-4 能正確調(diào)用list_services工具，并將結果簡化，格式化輸出幾個常用字段。
?

02 Llama2

輸入 list services 后 Appilot 直接報錯，原因是 Llama2 沒有按照 Prompt 規(guī)定的格式進行輸出，缺少了 Action Input 關鍵字，所以 LangChain 默認解析失敗，修改正則表達式后可以正常輸出。
?

不過輸出為原始格式，并沒有像 GPT-4 那樣按照 Appilot 預置的 Prompt 要求，將輸出內(nèi)容用 markdown 語法進行格式化輸出。
?

03 通義千問

通義千問可以正常格式化輸出，與 GPT-4 的結果對比發(fā)現(xiàn)，缺少 Template Version，增加 Service ID，判斷為不同大模型對輸出參數(shù)的重要性理解差異。
?

04 文心一言

接入文心一言后，任務報錯，提示輸入文本太長，不能超過4800的長度，為文心一言的輸入長度限制。
?

即便通過縮減 Appilot 的工具集來減短提示詞輸入后，獲取的結果也不盡如人意。
?

大部分結果無法遵循輸出格式。即便一些結果符合提示詞要求的格式，但基本為編造，如上圖 my-service 、another-service 等全是不存在的服務，都是文心一言偽造的輸出，即文心一言無法正確調(diào)用 list_services 工具。
?

為了支持后面的測試 Case 能正常運行，在使用文心一言時，會在保留正確工具的同時，盡可能縮減 Appilot 的工具集。
?

05 ChatGLM

ChatGLM 的輸出結果也是編造的，它所列出的都是不存在的服務，與文心一言一致。
?

本輪評測結果

?

Case 1：部署服務

目標：本用例以“在阿里云上部署一個通義千問模型服務”為任務，測試 LLM 是否具備調(diào)用多個工具完成任務的邏輯推理能力。
?

輸入：

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 調(diào)用了3個工具來完成任務：

1. find_match_template尋找與部署相關的模版。工具先通過 /v1/templates獲取所有模版，然后將所有模板返回給 GPT-4，問它哪個是 qwen 相關的模版；
2. construct_service_to_create 構建要部署的目標模版，工具內(nèi)部使用 RAG 來完成。這里將上一步找到的模版，加上原任務內(nèi)容，發(fā)送給工具，由 RAG 的 Agent 來生成目標模版，也就是上圖中的 Input；
3. create_service創(chuàng)建服務，將上一步構建好的模版應用到系統(tǒng)中；
   ?

部署成功后，我們可以在 Walrus 和阿里云的 ECS 控制臺看到創(chuàng)建的資源。
?

?

升級服務
?

GPT-4 的實現(xiàn)與創(chuàng)建服務的邏輯鏈相似，但新增了一個步驟，即通過 get_template_schema 工具來獲取已經(jīng)部署的 qwen 服務，隨后對 qwen 服務進行更新。
?

02 Llama2

部署通義千問服務
?

Llama2 將輸入中的 qwen service 識別為一個模版的名稱，所以查找模版失敗了。把輸入改為 deploy a qwen，Llama2 即可正確部署服務。這里可以看出 Llama2 的邏輯推理能力有些差距。
?

然而，部署成功后 Llama2 “自作聰明”地給出一段建議，內(nèi)容是關于在服務部署成功后應該怎么做?？上н@不是提示詞中規(guī)定的格式，因此 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作為模版名稱，調(diào)用get_template_schema工具獲取qwen_service模版，所以失敗了。
2. 使用deploy qwen作為輸入，通義千問能調(diào)用find_matching_template工具來查找模版，但是結果輸出為一個 json 結構，并將其作為下一步 get_template_schema的輸入，所以也失敗了。

?

升級服務
?

因為前一步無法創(chuàng)建服務，所以先手動創(chuàng)建了一個 qwen 服務。
?

通義千問將任務錯誤識別為部署一個新的服務，反而“陰差陽錯”地執(zhí)行了上一步的任務。
?

可以看出通義千問對需要處理多步驟的復雜任務的邏輯推理能力也有所欠缺。
?

04 文心一言

部署通義千問服務
?

部署提示已經(jīng)構造了服務對象。
?

打開 VERBOSE 開關查看原始提示詞，看到文心一言編造了一系列調(diào)用記錄。
?

升級服務

這里看到文心一言輸出的 json 結構也是編造的。
?

05 ChatGLM

部署通義千問服務
?

部署提示已經(jīng)構造了服務對象，但實際并沒有。
?

同樣，ChatGLM 編造了一系列調(diào)用記錄。
?

升級服務
?

ChatGLM 聲稱完成了升級，但檢查系統(tǒng)發(fā)現(xiàn)也是幻覺。
?

本輪評測結果

?

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 相關環(huán)境變量和鏡像名稱，最后成功部署。
?

01 GPT-4

推理邏輯與 Case1 一致，能正確填入輸入中的 image 和 GitHub 地址，并使用環(huán)境變量配置 Registry 認證相關的兩個參數(shù)。
?

02 Llama2

Llama2 將輸入中的 GitHub 倉庫地址識別為模版名稱 spring-boot-docker-sample，所以直接失敗了。
?

03 通義千問

?

通義千問將輸入的deploy service 識別為模版名稱，可以推斷通義千問沒有理解這個輸入的正確含義。
?

04 文心一言

文心一言仍未能按照規(guī)定的提示詞進行輸出，而是輸出一個自己偽造的 json 結構，并將一些任務相關的內(nèi)容填入到偽造的 json 內(nèi)容中。
?

05 ChatGLM

ChatGLM 能夠調(diào)用正確的工具并構建了部署服務的請求體，但推理能力較差，導致缺失了部分配置，使得雖然創(chuàng)建了服務，但最終的部署沒有成功。
?

本輪評測結果

?

Case 3：切換環(huán)境、過濾服務、克隆環(huán)境

目標：測試 LLM 的邏輯推理和工具調(diào)用能力。
?

輸入：

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

預期：

1. 默認的 Context 為dev環(huán)境，將當前的 Context 切換到 qa 環(huán)境；
2. 獲取當前環(huán)境的所有服務，過濾出所有名字帶有 test字段，而且跟 nginx 相關的服務 test1和 test2， test3為 spring 服務，不應列出；
3. 調(diào)用 clone_environment 工具，克隆qa環(huán)境到 staging 環(huán)境；
   ?

01 GPT-4

切換環(huán)境、過濾服務
?

GPT-4 能正確完成切換環(huán)境和過濾服務的操作。
?

克隆服務
?

克隆環(huán)境成功后，可以在 Walrus 中看到一個新的 staging 環(huán)境，并且其中正常部署著與 qa 環(huán)境相同的3個服務。
?

02 Llama2

切換環(huán)境
?

從 Reasoning 可以看到，在 Llama2 的推理步驟中，第一步尚能正確理解任務，但是第二步開始跑偏，最終從切換環(huán)境一步步跑偏到要執(zhí)行部署任務。
?

過濾服務
?

從 Llama2 的“錯誤結果”可以看到已經(jīng)調(diào)用 list_services獲取了當前環(huán)境的所有服務，但需要進一步過濾時，直接返回了不遵循格式的輸出，導致 Appilot 無法識別而報錯。
?

克隆環(huán)境
?

Llama2 能正確理解任務并調(diào)用 clone_environment工具，但是輸入偽造了一個 id。
?

03 通義千問

切換環(huán)境
?

通義千問能夠正確切換環(huán)境。
?

過濾服務
?

通義千問似乎也能正確調(diào)用 list_services工具，但是結果為空。
?

打開 VERBOSE 開關查看原始提示詞，發(fā)現(xiàn)通義千問產(chǎn)生了已經(jīng)將結果返回的幻覺，也沒有進一步按照要求過濾服務。
?

克隆環(huán)境
?

通義千問克隆環(huán)境調(diào)用正確。
?

04 文心一言

切換環(huán)境
?

文心一言輸出的 json 結果是 change_context工具的輸入，但是project_name 是偽造，實際名稱為default。
?

過濾服務
?

文心一言這里輸出的格式雖然符合提示詞中的格式要求，但是從 Reasoning 中看到并沒有調(diào)用工具獲取當前環(huán)境的服務，而是偽造了一個結果。
?

克隆環(huán)境
?

文心一言的輸出格式錯誤，但看起來似乎只是格式不對，但 Action 中的工具還是錯的，不存在 clone_env 這個工具，正確的是 clone_environment。
?

05 ChatGLM

切換環(huán)境
?

ChatGLM 可以正確切換環(huán)境。
?

過濾服務
?

ChatGLM 對服務過濾的結果是編造的。
?

克隆環(huán)境
?

雖然推理邏輯不太對，但 ChatGLM 選擇了正確的工具調(diào)用完成了克隆環(huán)境。
?

本輪評測結果

?

Case 4：查看故障服務，嘗試診斷故障并修復問題

目標：測試 LLM 對診斷場景的邏輯推理能力。
?

當前 test 環(huán)境包含了兩個異常的服務：

?

輸入：

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 正確利用現(xiàn)有的工具獲取 app-1 服務的相關信息，包括服務詳情、服務相關的資源和服務日志。識別到錯誤后，更新了 app-1 服務，將錯誤的 Image 修改為正確的 nginx:latest 。
?

診斷 app-2 服務
?

GPT-4 獲取 app-2的日志后，診斷代碼文件 Application.java 在16行附近，有一個 str 的值是 null，所以不能調(diào)用 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 日志發(fā)現(xiàn)，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關聯(lián)的容器資源，再將容器名作為輸入來獲取日志。
?

04 文心一言

診斷app-1服務
?

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

結果與通義千問類似，文心一言似乎能理解診斷的任務，調(diào)用工具來獲取服務 app-1的相關信息，但在使用工具獲取日志時，編造了 resource 的名字，因此獲取日志失敗。
?

05 ChatGLM

診斷app-1服務
?

ChatGLM 其結果是與實際情況無關的幻覺。
?

在本 Case 中，除了 GPT-4 以外評測的其它大模型都無法通過第一個較為簡單的診斷任務，更別說更復雜的第二個任務了。
?

本輪評測結果

?

成本對比

這里以 Case 0 為例，測試在 Appilot 中輸入 list services 時，調(diào)用基礎工具 list_service ，需要的相關耗費（美元兌人民幣按1:7折算）：

?

注：其中 Llama2 模型按照本次測試使用的 AWS ml.g5.48xlarge 實例包年包月價格$6.515/小時（非并發(fā)推理計算)

?

總 結

根據(jù)上述評測過程，在 Appilot 的應用場景下，可以得出以下結論：
?

市面上的所有預訓練大語言模型中，針對類似于 Appilot 的 AI agent 場景，GPT-4 依然獨領風騷。跟 GPT-4 相比，其他大語言模型還有較大的差距，主要體現(xiàn)在以下三個方面：

• 遵循提示詞格式的能力：AI agent 通常具有較長上下文的提示詞，大語言模型需要遵循提示詞中規(guī)定的輸出格式來獲取調(diào)用的工具和輸入?yún)?shù)。如果大模型返回結果的格式無法遵循要求，幾乎無法解析成為下一步工具調(diào)用的輸入；

• 邏輯推理能力：GPT-4 能夠完成多個工具調(diào)用的推理鏈條，配合完成復雜任務，其他模型的推理能力不足，難以完成需要多步驟調(diào)用工具完成目標的復雜任務；

• 輸出的穩(wěn)定性：即使將輸出多樣性的參數(shù) temperature 調(diào)至最低，在輸入相同的情況下，一些大語言模型依然會產(chǎn)生不穩(wěn)定的輸出。

?

除了 GPT-4 以外，其余評測的4款大語言模型的具體體驗如下：

• Llama2：如果是簡單輸入場景，Llama2 能跟對應的工具進行關聯(lián)。大部分能根據(jù)提示詞找到對應工具，并按照規(guī)定格式正確輸出內(nèi)容。如果輸入復雜，完成任務需要多個工具的配合，那么它極少地展現(xiàn)它的復雜推理能力，更多時間是答非所問。即便正確調(diào)用工具后，偶爾還會輸出一些看似與輸入相關，但實則與提示詞規(guī)定無關的內(nèi)容。

• 通義千問：在簡單輸入的場景下，通義千問一般都能正確調(diào)用工具獲取結果，相較 Llama2 穩(wěn)定。但在復雜輸入的場景下，千問的推理能力短板也暴露出來了，基本無能為力。

• 文心一言：4800的輸入限制幾乎使得文心一言直接“退賽”，即使精簡了 Appilot 的工具集，從測試效果上看，文心一言也是這幾個模型中最差的，不僅大多數(shù)情況下都不能按照提示詞規(guī)定的格式輸出內(nèi)容，還常常編造與提示詞和輸入完全無關的結果，幻覺過多。

• ChatGLM：與通義千問類似，部分簡單場景下可以獲取預期結果，但無法處理需要多步驟執(zhí)行的復雜任務。

?

除上述幾個模型外，作者還嘗試了其他的模型，例如 Xwin-LM-70B-V0.1、Mistral-7B-Instruct-v0.1 等模型，但它們的測試結果與文心一言的結果類似，基本無法按照提示詞給定的格式進行輸出，直接無法使用。
?

按實際表現(xiàn)來說，除了 GPT-4 以外的這些大模型基本是不可用的，遠遠低于我們的期望和模型提供方所宣傳的效果。一方面這些大模型在能力和成熟度上仍然還需努力，另一方面 Appilot 在對接這些大模型時，還需要用到更多的提示詞優(yōu)化、微調(diào)等技術進行完善。
?

從模型的耗時和成本對比可以看到，GPT-4 雖然優(yōu)秀，但費用相對高昂。其它預訓練大語言模型的測試表現(xiàn)雖然不佳，但從成本和實際落地的需求場景出發(fā)，未來依然具備一定的潛力。因此，后續(xù)工作可以考慮兩個方向：

1. 針對特定的垂直領域，基于 Llama2 等開源大語言模型進行微調(diào)，從而提升性能和可靠性。除此之外還可以使用量化和其他推理加速的手段，降低大語言模型部署成本和推理的耗時，幫助 AI agent 類 LLM 應用真正落地。

2. 基于通義千問之類的大模型，即具備基礎能力且部署成本較低，通過提示詞優(yōu)化、使用嵌入（Embedding）技術以及進行 Few-shot 學習等優(yōu)化方向來增強 LLM 應用的準確性。

?

上述大語言模型的測試匯總記錄如下：

?

此次評測只是階段性的評測，考慮到目前大模型領域仍然高速發(fā)展，GPT-4-Turbo、通義千問2.0、ChatGLM3 等更新的大模型版本還未正式上線，未來我們將保持每半年一次的評測頻率，持續(xù)跟進主流大模型在 AI agent 場景下，對 DevOps 這樣的垂直領域的實際應用效果。也會加入更多的評測內(nèi)容，例如中文對話、更完善的用例設計、更多的大模型等，更加綜合具體地評估各個大模型的表現(xiàn)。
?

相關鏈接：
[ 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/

?

到了這里，關于通義千問, 文心一言, ChatGLM, GPT-4, Llama2, DevOps 能力評測的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！