引言

“克隆 dev 環(huán)境到 test 環(huán)境，等所有服務(wù)運(yùn)行正常之后，把訪問地址告訴我”，“檢查所有項(xiàng)目，告訴我有哪些服務(wù)不正常，給出異常原因和修復(fù)建議”，在過去的工程師生涯中，也曾幻想過能夠通過這樣的自然語言指令來完成運(yùn)維任務(wù)，如今?

AI 助手 Appilot

?利用 LLM 蘊(yùn)藏的神奇力量，將這一切變成了現(xiàn)實(shí)。 ? 今年9月，數(shù)澈軟件Seal （以下簡稱“Seal”）開源了一款面向 DevOps 場景的 AI 助手 Appilot（github.com/seal-io/appilot），讓工程師通過自然語言交互即可實(shí)現(xiàn)應(yīng)用管理、環(huán)境管理、故障診斷、混合基礎(chǔ)設(shè)施編排等應(yīng)用生命周期管理功能。 ? 目前 Appilot 以 GPT-4 為基準(zhǔn)進(jìn)行開發(fā)測試。GPT-4 是當(dāng)前最強(qiáng)的大模型之一，能夠?qū)⒁粋€(gè)復(fù)雜任務(wù)按照思維鏈條分解為多個(gè)可以單獨(dú)執(zhí)行的子任務(wù)，并根據(jù)返回繼續(xù)執(zhí)行新的子任務(wù)，表現(xiàn)出極強(qiáng)的表達(dá)和推理能力。在開發(fā)過程中，GPT-4 也常常給作者帶來意想不到的驚喜。但是較慢的推理速度，相對(duì)昂貴的使用費(fèi)用，還有潛在的數(shù)據(jù)安全問題，都讓我們期待是否能通過使用國產(chǎn)在線 LLM 服務(wù)或者部署私有開源的 LLM 來完成同樣的管理任務(wù)。 ? 本文將探討在 Appilot 的場景下，GPT 以外的 LLM 有著怎樣的表現(xiàn)。 ? 基本工作原理

在評(píng)測之前，我們先簡單地介紹 Prompt 工程和 Appilot 實(shí)現(xiàn)的基本原理。 ? Walrus Walrus 是一款開源的基于平臺(tái)工程理念、以應(yīng)用為中心、以完整應(yīng)用系統(tǒng)自動(dòng)化編排交付為目標(biāo)進(jìn)行設(shè)計(jì)開發(fā)的云原生應(yīng)用平臺(tái)。在本文中，Appilot 將使用 Walrus 作為基座進(jìn)行應(yīng)用管理（Walrus 并非 Appilot 唯一指定基座，您可以接入熟悉的平臺(tái)，例如 Kubernetes）。 ? 在 Walrus 中，項(xiàng)目作為應(yīng)用系統(tǒng)的工作空間，每個(gè)項(xiàng)目可管理多個(gè)應(yīng)用環(huán)境，例如應(yīng)用的開發(fā)、測試、預(yù)發(fā)布、生產(chǎn)、雙活、灰度等環(huán)境，在每個(gè)環(huán)境中可以使用 Walrus 模板部署多種類型的服務(wù)，包括運(yùn)行在 K8s 上或彈性容器實(shí)例上的容器化應(yīng)用、傳統(tǒng)部署應(yīng)用、RDS 之類的各種公有云資源，以及配置 LB/DNS 等各種私有基礎(chǔ)設(shè)施資源等。 ? RAG RAG 的全稱為 Retrieval-Augmented Generation，即檢索增強(qiáng)生成。目前 LLM 主要用于文本生成，生成效果取決于預(yù)訓(xùn)練的數(shù)據(jù)。如果問題涉及到訓(xùn)練數(shù)據(jù)領(lǐng)域外的知識(shí)，獲取正確答案的概率就會(huì)大幅降低。例如 GPT-4 的訓(xùn)練數(shù)據(jù)截止到 2021 年 9 月，如果提問 2022 年新增的名詞，GPT-4 則無法給出正確答案。 ? 為了解決這一問題，可以在 Prompt 時(shí)引入外部數(shù)據(jù)源，配合原始任務(wù)來生成更好的結(jié)果，這一方法也被稱為檢索增強(qiáng)（Retrieval-Augmented）。 ? 在 Appilot 中，部署服務(wù)需要對(duì)應(yīng)的模板，這個(gè)模板的定義由底層的云原生應(yīng)用平臺(tái) Walrus 提供。在每次執(zhí)行一個(gè)部署任務(wù)時(shí)，Appilot 會(huì)先從 Walrus 找出相關(guān)的模板，然后將其和原始任務(wù)一起發(fā)送給 LLM，由 LLM 選擇對(duì)應(yīng)的模板，生成最終的服務(wù)部署配置。 ? Agent LLM 在自然語言理解方面的突破，使得人機(jī)交互的門檻大大降低——我們可以像與人溝通一樣與機(jī)器進(jìn)行交流。 ? 但僅靠 LLM，只能完成一些文本、圖片生成的任務(wù)。為了釋放 LLM 的全部潛力，我們要構(gòu)建一個(gè)系統(tǒng)，以獲取外部信息和應(yīng)用外部工具來解決實(shí)際問題，這就是 Agent 的用武之地。 ? 下圖是 Agent 的實(shí)現(xiàn)框架，LLM 作為 Agent 的大腦，負(fù)責(zé)理解任務(wù)、拆分任務(wù)、并調(diào)用工具執(zhí)行任務(wù)，每次生成工具的調(diào)用歷史記錄，通過任務(wù)結(jié)果分析和工具調(diào)用不斷循環(huán)，最終得出目標(biāo)結(jié)果。之前爆紅的全自動(dòng)人工智能助手 AutoGPT 也是采用這一思路實(shí)現(xiàn)。

在 Appilot 的實(shí)現(xiàn)中，我們遵循相同的設(shè)計(jì)，把應(yīng)用管理相關(guān)的工具集放到 Prompt 中，讓 LLM 來決定如何調(diào)用工具。 ? 模型選擇

我們選擇以下5個(gè)流行的 LLM 加入本次的評(píng)測范圍。 ?

GPT-4

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

Llama2

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

通義千問

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

文心一言

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

ChatGLM

? ChatGLM 是由清華大學(xué) KEG 實(shí)驗(yàn)室和智譜 AI 基于千億基座模型 GLM-130B 開發(fā)的支持中英雙語的對(duì)話語言模型，具備多領(lǐng)域知識(shí)、代碼能力、常識(shí)推理及運(yùn)用能力。支持與用戶通過自然語言對(duì)話進(jìn)行交互，處理多種自然語言任務(wù)。本次測試使用的是智譜 AI 在線版本的?ChatGLM-Turbo?模型。 ? 省流版（TL;DR）

先放評(píng)測結(jié)論：

在市面上的所有預(yù)訓(xùn)練大語言模型中，針對(duì) Appilot 這樣的 AI agent 場景，GPT-4 依然是“名列前茅”的優(yōu)等生，獨(dú)一檔的存在

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

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

此次評(píng)測只是階段性的評(píng)測

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

因?yàn)?LLM 輸出不穩(wěn)定，在本測試中每個(gè)測試案例均運(yùn)行多次，取其中最優(yōu)結(jié)果。 ? 測試環(huán)境 測試設(shè)備：Apple M1 Pro 筆記本

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

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

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

?

Case 0：列出當(dāng)前環(huán)境的所有服務(wù)

目標(biāo)

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

輸入

：list services ?

預(yù)期

：正確調(diào)用list_services工具來獲取當(dāng)前環(huán)境的服務(wù)。 ? 01 GPT-4

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

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

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

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

接入文心一言后，任務(wù)報(bào)錯(cuò)，提示輸入文本太長，不能超過4800的長度，為文心一言的輸入長度限制。

即便通過縮減 Appilot 的工具集來減短提示詞輸入后，獲取的結(jié)果也不盡如人意。 ? 大部分結(jié)果無法遵循輸出格式。即便一些結(jié)果符合提示詞要求的格式，但基本為編造，如上圖?my-service?、another-service?等全是不存在的服務(wù)，都是文心一言偽造的輸出，即文心一言無法正確調(diào)用?list_services?工具。 ?

為了支持后面的測試 Case 能正常運(yùn)行，在使用文心一言時(shí)，會(huì)在保留正確工具的同時(shí)，盡可能縮減 Appilot 的工具集

。 ? 05 ChatGLM

ChatGLM 的輸出結(jié)果也是編造的，它所列出的都是不存在的服務(wù)，與文心一言一致。 ? 本輪評(píng)測結(jié)果

Case 1：部署服務(wù)

目標(biāo)

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

輸入

： deploy a qwen service

upgrade qwen to instance ecs.c7.16xlarge

?

預(yù)期

： 獲取到通義千問相關(guān)的模版，使用模版在阿里云上部署一個(gè) qwen 的 ECS 實(shí)例;

獲取原來 qwen 服務(wù)的模版信息，修改機(jī)器類型為?ecs.c7.16xlarge?并更新服務(wù)；

?

01 GPT-4

部署通義千問服務(wù)

?

從 Reasoning 的提示和 Walrus 的后臺(tái)日志中可以看到，GPT-4 調(diào)用了3個(gè)工具來完成任務(wù)： find_match_template尋找與部署相關(guān)的模版。工具先通過?/v1/templates獲取所有模版，然后將所有模板返回給 GPT-4，問它哪個(gè)是 qwen 相關(guān)的模版；

construct_service_to_create?構(gòu)建要部署的目標(biāo)模版，工具內(nèi)部使用 RAG 來完成。這里將上一步找到的模版，加上原任務(wù)內(nèi)容，發(fā)送給工具，由 RAG 的 Agent 來生成目標(biāo)模版，也就是上圖中的 Input；

create_service創(chuàng)建服務(wù)，將上一步構(gòu)建好的模版應(yīng)用到系統(tǒng)中；

?

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

?

升級(jí)服務(wù)

?

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

部署通義千問服務(wù)

?

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

然而，部署成功后 Llama2 “自作聰明”地給出一段建議，內(nèi)容是關(guān)于在服務(wù)部署成功后應(yīng)該怎么做?？上н@不是提示詞中規(guī)定的格式，因此 Appilot 識(shí)別失敗報(bào)錯(cuò)。 ?

升級(jí)服務(wù)

?

Llama2 期望使用一個(gè)名為?qwen-ecs-upgrade模版來進(jìn)行升級(jí)服務(wù)，所以第一步就失敗了。 一樣可以看出 Llama2 的邏輯推理能力有所欠缺。 ? 03 通義千問

部署通義千問服務(wù)

? ?

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

? 結(jié)合錯(cuò)誤日志和 Walrus 后臺(tái)日志，可以得知： 使用?deploy a qwen service作為輸入時(shí)，通義千問直接以qwen_service作為模版名稱，調(diào)用get_template_schema工具獲取qwen_service模版，所以失敗了。

使用deploy qwen作為輸入，通義千問能調(diào)用find_matching_template工具來查找模版，但是結(jié)果輸出為一個(gè) json 結(jié)構(gòu)，并將其作為下一步?get_template_schema的輸入，所以也失敗了。

?

升級(jí)服務(wù)

? 因?yàn)榍耙徊綗o法創(chuàng)建服務(wù)，所以先手動(dòng)創(chuàng)建了一個(gè) qwen 服務(wù)。 ?

通義千問將任務(wù)錯(cuò)誤識(shí)別為部署一個(gè)新的服務(wù)，反而“陰差陽錯(cuò)”地執(zhí)行了上一步的任務(wù)。 ? 可以看出通義千問對(duì)需要處理多步驟的復(fù)雜任務(wù)的邏輯推理能力也有所欠缺。 ? 04 文心一言

部署通義千問服務(wù)

?

部署提示已經(jīng)構(gòu)造了服務(wù)對(duì)象。 ?

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

升級(jí)服務(wù)

這里看到文心一言輸出的 json 結(jié)構(gòu)也是編造的。 ? 05 ChatGLM

部署通義千問服務(wù)

?

部署提示已經(jīng)構(gòu)造了服務(wù)對(duì)象，但實(shí)際并沒有。 ?

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

升級(jí)服務(wù)

?

ChatGLM 聲稱完成了升級(jí)，但檢查系統(tǒng)發(fā)現(xiàn)也是幻覺。 ? 本輪評(píng)測結(jié)果

Case 2：在K8s上部署從源碼構(gòu)建的spring-boot服務(wù)

目標(biāo)

：測試 LLM 邏輯推理和 RAG 模版生成能力。 ?

輸入

： deploy seal-demo/spring-boot-docker-sample:feature, configure registry auth with project

env

, push image to rainfd/spring ?

預(yù)期

： 獲取到從源碼部署相關(guān)的模版，填入目標(biāo)的 GitHub 地址、Docker Hub 相關(guān)環(huán)境變量和鏡像名稱，最后成功部署。 ? 01 GPT-4

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

Llama2 將輸入中的 GitHub 倉庫地址識(shí)別為模版名稱?spring-boot-docker-sample，所以直接失敗了。 ? 03 通義千問 ?

通義千問將輸入的deploy service 識(shí)別為模版名稱，可以推斷通義千問沒有理解這個(gè)輸入的正確含義。 ? 04 文心一言

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

ChatGLM 能夠調(diào)用正確的工具并構(gòu)建了部署服務(wù)的請(qǐng)求體，但推理能力較差，導(dǎo)致缺失了部分配置，使得雖然創(chuàng)建了服務(wù)，但最終的部署沒有成功。 ? 本輪評(píng)測結(jié)果

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

目標(biāo)

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

輸入

： switch env to qa

list all nginx services with the name test

clone qa env to staging env

?

預(yù)期

： 默認(rèn)的 Context 為dev環(huán)境，將當(dāng)前的 Context 切換到?qa?環(huán)境；

獲取當(dāng)前環(huán)境的所有服務(wù)，過濾出所有名字帶有?test字段，而且跟 nginx 相關(guān)的服務(wù)?test1和?test2，?test3為 spring 服務(wù)，不應(yīng)列出；

調(diào)用?clone_environment?工具，克隆qa環(huán)境到?staging?環(huán)境；

?

01 GPT-4

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

?

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

克隆服務(wù)

?

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

切換環(huán)境

?

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

過濾服務(wù)

?

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

克隆環(huán)境

?

Llama2 能正確理解任務(wù)并調(diào)用?clone_environment工具，但是輸入偽造了一個(gè) id。 ? 03 通義千問

切換環(huán)境

?

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

過濾服務(wù)

?

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

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

克隆環(huán)境

?

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

切換環(huán)境

?

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

過濾服務(wù)

?

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

克隆環(huán)境

?

文心一言的輸出格式錯(cuò)誤，但看起來似乎只是格式不對(duì)，但 Action 中的工具還是錯(cuò)的，不存在?clone_env?這個(gè)工具，正確的是?clone_environment。 ? 05 ChatGLM

切換環(huán)境

?

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

過濾服務(wù)

?

ChatGLM 對(duì)服務(wù)過濾的結(jié)果是編造的。 ?

克隆環(huán)境

?

雖然推理邏輯不太對(duì)，但 ChatGLM 選擇了正確的工具調(diào)用完成了克隆環(huán)境。 ? 本輪評(píng)測結(jié)果

Case 4：查看故障服務(wù)，嘗試診斷故障并修復(fù)問題

目標(biāo)

：測試 LLM 對(duì)診斷場景的邏輯推理能力。 ? 當(dāng)前 test 環(huán)境包含了兩個(gè)異常的服務(wù)：

輸入

： diagnose app-1

fix app-1

diagnose app-2

?

預(yù)期

： 診斷出 app-1 服務(wù)使用的鏡像?nginx:a.b.c?為錯(cuò)誤的鏡像；

更新服務(wù)，修復(fù)為正確的鏡像標(biāo)簽；

診斷出 app-2 服務(wù)日志中的代碼錯(cuò)誤。

?

01 GPT-4

診斷修復(fù) app-1 服務(wù)

?

可以看到 GPT-4 正確利用現(xiàn)有的工具獲取 app-1 服務(wù)的相關(guān)信息，包括服務(wù)詳情、服務(wù)相關(guān)的資源和服務(wù)日志。識(shí)別到錯(cuò)誤后，更新了?app-1?服務(wù)，將錯(cuò)誤的 Image 修改為正確的?nginx:latest?。 ?

診斷 app-2 服務(wù)

?

GPT-4 獲取?app-2的日志后，診斷代碼文件 Application.java 在16行附近，有一個(gè) str 的值是 null，所以不能調(diào)用?String.length()方法。 ? 我們可以看看在原始代碼中 commit 引入的錯(cuò)誤，https://github.com/seal-demo/spring-boot-docker-sample/commit/147e087d9368e60cd0402d864964cadf8e1daacb。與?GPT-4 描述的完全一致。

? 02 Llama2

診斷app-1服務(wù)

?

從前幾步看，似乎 Llama2 能理解診斷任務(wù)，并不斷獲取 app-1的相關(guān)信息，但是在獲取服務(wù)詳情的那一步報(bào)錯(cuò)。 ? 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"}作為輸入來查詢服務(wù)，所以任務(wù)中斷。 ? 03 通義千問

診斷app-1服務(wù)

?

Reasoning 中看到通義千問能理解任務(wù)，但是獲取服務(wù)日志失敗。 ?

400

|

GET

/v1/projects/

485034729423254044

/environments/

485040610525327900

/services/app-

1

/resources/app-

1.0

.

0.1

/

log

?

key

=web&tailLines=

100

查看 Walrus 日志得知，通義千問偽造了一個(gè)不存在的 resource，導(dǎo)致日志獲取失敗。正確的方式是先通過?get_service_resources?來獲取?app-1關(guān)聯(lián)的容器資源，再將容器名作為輸入來獲取日志。 ? 04 文心一言

診斷app-1服務(wù)

?

400

|

GET

/v1/projects/

485034729423254044

/environments/

485040610525327900

/services/app-

1

/resources/app-

1

/

log

?

key

=app&tailLines=

100

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

診斷app-1服務(wù)

?

ChatGLM 其結(jié)果是與實(shí)際情況無關(guān)的幻覺。 ? 在本 Case 中，除了 GPT-4 以外評(píng)測的其它大模型都無法通過第一個(gè)較為簡單的診斷任務(wù)，更別說更復(fù)雜的第二個(gè)任務(wù)了。 ? 本輪評(píng)測結(jié)果

成本對(duì)比

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

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

? 總 結(jié)

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

市面上的所有預(yù)訓(xùn)練大語言模型中，針對(duì)類似于 Appilot 的 AI agent 場景，GPT-4 依然獨(dú)領(lǐng)風(fēng)騷

。跟 GPT-4 相比，其他大語言模型還有較大的差距，主要體現(xiàn)在以下三個(gè)方面：

遵循提示詞格式的能力

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

邏輯推理能力

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

輸出的穩(wěn)定性

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

? 除了 GPT-4 以外，其余評(píng)測的4款大語言模型的具體體驗(yàn)如下：

Llama2

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

通義千問

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

文心一言

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

ChatGLM

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

? 除上述幾個(gè)模型外，作者還嘗試了其他的模型，例如 Xwin-LM-70B-V0.1、Mistral-7B-Instruct-v0.1 等模型，但它們的測試結(jié)果與文心一言的結(jié)果類似，基本無法按照提示詞給定的格式進(jìn)行輸出，直接無法使用。 ? 按實(shí)際表現(xiàn)來說，除了 GPT-4 以外的這些大模型基本是不可用的，遠(yuǎn)遠(yuǎn)低于我們的期望和模型提供方所宣傳的效果。一方面這些大模型在能力和成熟度上仍然還需努力，另一方面 Appilot 在對(duì)接這些大模型時(shí)，還需要用到更多的提示詞優(yōu)化、微調(diào)等技術(shù)進(jìn)行完善。 ? 從模型的耗時(shí)和成本對(duì)比可以看到，GPT-4 雖然優(yōu)秀，但費(fèi)用相對(duì)高昂。其它預(yù)訓(xùn)練大語言模型的測試表現(xiàn)雖然不佳，但從成本和實(shí)際落地的需求場景出發(fā)，未來依然具備一定的潛力。因此，后續(xù)工作可以考慮兩個(gè)方向：

針對(duì)特定的垂直領(lǐng)域

，基于 Llama2 等開源大語言模型進(jìn)行微調(diào)，從而提升性能和可靠性。除此之外還可以使用量化和其他推理加速的手段，降低大語言模型部署成本和推理的耗時(shí)，幫助 AI agent 類 LLM 應(yīng)用真正落地。

基于通義千問之類的大模型

，即具備基礎(chǔ)能力且部署成本較低，通過提示詞優(yōu)化、使用嵌入（Embedding）技術(shù)以及進(jìn)行 Few-shot 學(xué)習(xí)等優(yōu)化方向來增強(qiáng) LLM 應(yīng)用的準(zhǔn)確性。

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

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

相關(guā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/

[ 阿里云靈積平臺(tái) ]：https://dashscope.aliyun.com/

[ ChatGLM ]:?https://chatglm.cn/

?