通义千问, 文心一言, ChatGLM, GPT-4, Llama2, DevOps 能力评测
引言
“克隆 dev 環(huán)境到 test 環(huán)境，等所有服務(wù)運行正常之后，把訪問地址告訴我”，“檢查所有項目，告訴我有哪些服務(wù)不正常，給出異常原因和修復(fù)建議”，在過去的工程師生涯中，也曾幻想過能夠通過這樣的自然語言指令來完成運維任務(wù)，如今 AI 助手 Appilot 利用 LLM 蘊藏的神奇力量，將這一切變成了現(xiàn)實。
?
今年9月，數(shù)澈軟件Seal （以下簡稱“Seal”）開源了一款面向 DevOps 場景的 AI 助手 Appilot（github.com/seal-io/appilot），讓工程師通過自然語言交互即可實現(xiàn)應(yīng)用管理、環(huán)境管理、故障診斷、混合基礎(chǔ)設(shè)施編排等應(yīng)用生命周期管理功能。
?
目前 Appilot 以 GPT-4 為基準進行開發(fā)測試。GPT-4 是當(dāng)前最強的大模型之一，能夠?qū)⒁粋€復(fù)雜任務(wù)按照思維鏈條分解為多個可以單獨執(zhí)行的子任務(wù)，并根據(jù)返回繼續(xù)執(zhí)行新的子任務(wù)，表現(xiàn)出極強的表達和推理能力。在開發(fā)過程中，GPT-4 也常常給作者帶來意想不到的驚喜。但是較慢的推理速度，相對昂貴的使用費用，還有潛在的數(shù)據(jù)安全問題，都讓我們期待是否能通過使用國產(chǎn)在線 LLM 服務(wù)或者部署私有開源的 LLM 來完成同樣的管理任務(wù)。
?
本文將探討在 Appilot 的場景下，GPT 以外的 LLM 有著怎樣的表現(xiàn)。
?
基本工作原理
在評測之前，我們先簡單地介紹 Prompt 工程和 Appilot 實現(xiàn)的基本原理。
?
Walrus
Walrus 是一款開源的基于平臺工程理念、以應(yīng)用為中心、以完整應(yīng)用系統(tǒng)自動化編排交付為目標進行設(shè)計開發(fā)的云原生應(yīng)用平臺。在本文中，Appilot 將使用 Walrus 作為基座進行應(yīng)用管理（Walrus 并非 Appilot 唯一指定基座，您可以接入熟悉的平臺，例如 Kubernetes）。
?
在 Walrus 中，項目作為應(yīng)用系統(tǒng)的工作空間，每個項目可管理多個應(yīng)用環(huán)境，例如應(yīng)用的開發(fā)、測試、預(yù)發(fā)布、生產(chǎn)、雙活、灰度等環(huán)境，在每個環(huán)境中可以使用 Walrus 模板部署多種類型的服務(wù)，包括運行在 K8s 上或彈性容器實例上的容器化應(yīng)用、傳統(tǒng)部署應(yīng)用、RDS 之類的各種公有云資源，以及配置 LB/DNS 等各種私有基礎(chǔ)設(shè)施資源等。
?
RAG
RAG 的全稱為 Retrieval-Augmented Generation，即檢索增強生成。目前 LLM 主要用于文本生成，生成效果取決于預(yù)訓(xùn)練的數(shù)據(jù)。如果問題涉及到訓(xùn)練數(shù)據(jù)領(lǐng)域外的知識，獲取正確答案的概率就會大幅降低。例如 GPT-4 的訓(xùn)練數(shù)據(jù)截止到 2021 年 9 月，如果提問 2022 年新增的名詞，GPT-4 則無法給出正確答案。
?
為了解決這一問題，可以在 Prompt 時引入外部數(shù)據(jù)源，配合原始任務(wù)來生成更好的結(jié)果，這一方法也被稱為檢索增強（Retrieval-Augmented）。
?
在 Appilot 中，部署服務(wù)需要對應(yīng)的模板，這個模板的定義由底層的云原生應(yīng)用平臺 Walrus 提供。在每次執(zhí)行一個部署任務(wù)時，Appilot 會先從 Walrus 找出相關(guān)的模板，然后將其和原始任務(wù)一起發(fā)送給 LLM，由 LLM 選擇對應(yīng)的模板，生成最終的服務(wù)部署配置。
?
Agent
LLM 在自然語言理解方面的突破，使得人機交互的門檻大大降低——我們可以像與人溝通一樣與機器進行交流。
?
但僅靠 LLM，只能完成一些文本、圖片生成的任務(wù)。為了釋放 LLM 的全部潛力，我們要構(gòu)建一個系統(tǒng)，以獲取外部信息和應(yīng)用外部工具來解決實際問題，這就是 Agent 的用武之地。
?
下圖是 Agent 的實現(xiàn)框架，LLM 作為 Agent 的大腦，負責(zé)理解任務(wù)、拆分任務(wù)、并調(diào)用工具執(zhí)行任務(wù)，每次生成工具的調(diào)用歷史記錄，通過任務(wù)結(jié)果分析和工具調(diào)用不斷循環(huán)，最終得出目標結(jié)果。之前爆紅的全自動人工智能助手 AutoGPT 也是采用這一思路實現(xiàn)。
?
在 Appilot 的實現(xiàn)中，我們遵循相同的設(shè)計，把應(yīng)用管理相關(guān)的工具集放到 Prompt 中，讓 LLM 來決定如何調(diào)用工具。
?
模型選擇
我們選擇以下5個流行的 LLM 加入本次的評測范圍。
?
GPT-4
?
GPT-4 是現(xiàn)階段效果最好的 LLM，Appilot 也是基于 GPT-4 進行開發(fā)，所以本次測試將其作為基準。
?
Llama2
?
Llama2 是 Meta 公司發(fā)布的開源模型，因其不錯的性能和可免費商用，引起廣泛關(guān)注。本次測試使用的是 Llama2 的Llama2-70B-Chat 模型，部署在 AWS 的 Sagemaker 平臺上，使用的機器規(guī)格是ml.g5.48xlarge。
?
通義千問
?
通義千問是阿里云研發(fā)的大語言系列模型，在 Huggingface 和魔搭社區(qū)上有對應(yīng)的開源版本。本次測試使用的是阿里云靈積平臺上在線版本的Qwen-14B-Chat模型。
?
文心一言
?
文心一言是百度研發(fā)的大語言模型，近期發(fā)布了 4.0 版本。本次測試使用的是百度智能云上在線版本的ERNIE-Bot-4模型。
?
ChatGLM
?
ChatGLM 是由清華大學(xué) KEG 實驗室和智譜 AI 基于千億基座模型 GLM-130B 開發(fā)的支持中英雙語的對話語言模型，具備多領(lǐng)域知識、代碼能力、常識推理及運用能力。支持與用戶通過自然語言對話進行交互，處理多種自然語言任務(wù)。本次測試使用的是智譜 AI 在線版本的 ChatGLM-Turbo 模型。
?
省流版（TL;DR）
先放評測結(jié)論：在市面上的所有預(yù)訓(xùn)練大語言模型中，針對 Appilot 這樣的 AI agent 場景，GPT-4 依然是“名列前茅”的優(yōu)等生，獨一檔的存在。
?
注：本評測僅針對 Appilot 所面向的使用 AI agent 來進行應(yīng)用管理的場景，評測結(jié)果僅為一家之言，不做為對其它 LLM 應(yīng)用領(lǐng)域大模型效果的排名依據(jù)。
?
除了 GPT-4 以外，其余4款大語言模型（**Llama2、通義千問、文心一言、ChatGLM **）按表現(xiàn)來說基本是不可用的，遠遠低于我們的期望和模型提供方所宣傳的效果。一方面這些大模型在能力和成熟度上仍然還需努力，另一方面 Appilot 在對接這些大模型時，還需要用到更多的提示詞優(yōu)化、微調(diào)等技術(shù)進行完善。
?
此次評測只是階段性的評測，考慮到目前大模型領(lǐng)域仍然高速發(fā)展，GPT-4-Turbo、通義千問2.0、ChatGLM3 等更新的大模型版本還未正式上線，未來我們將保持每半年一次的評測頻率，持續(xù)跟進主流大模型在 AI agent 場景下，對 DevOps 這樣的垂直領(lǐng)域的實際應(yīng)用效果。也會加入更多的評測內(nèi)容，例如中文對話、更完善的用例設(shè)計、更多的大模型等，更加綜合具體地評估各個大模型的表現(xiàn)。
?
接下來，我們來看詳細的評測過程。
?
測試案例
因為 LLM 輸出不穩(wě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 項目下創(chuàng)建了 dev、test 和 qa 環(huán)境，每個環(huán)境都連接了本地的 K8s 集群和阿里云。（安裝步驟：https://seal-io.github.io/docs/zh/quickstart）
?
Case 0：列出當(dāng)前環(huán)境的所有服務(wù)
目標：測試 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é)果簡化，格式化輸出幾個常用字段。
?
02 Llama2
輸入 list services 后 Appilot 直接報錯，原因是 Llama2 沒有按照 Prompt 規(guī)定的格式進行輸出，缺少了 Action Input 關(guān)鍵字，所以 LangChain 默認解析失敗，修改正則表達式后可以正常輸出。
?
不過輸出為原始格式，并沒有像 GPT-4 那樣按照 Appilot 預(yù)置的 Prompt 要求，將輸出內(nèi)容用 markdown 語法進行格式化輸出。
?
03 通義千問
通義千問可以正常格式化輸出，與 GPT-4 的結(jié)果對比發(fā)現(xiàn)，缺少 Template Version，增加 Service ID，判斷為不同大模型對輸出參數(shù)的重要性理解差異。
?
04 文心一言
接入文心一言后，任務(wù)報錯，提示輸入文本太長，不能超過4800的長度，為文心一言的輸入長度限制。
?
即便通過縮減 Appilot 的工具集來減短提示詞輸入后，獲取的結(jié)果也不盡如人意。
?
大部分結(jié)果無法遵循輸出格式。即便一些結(jié)果符合提示詞要求的格式，但基本為編造，如上圖 my-service 、another-service 等全是不存在的服務(wù)，都是文心一言偽造的輸出，即文心一言無法正確調(diào)用 list_services 工具。
?
為了支持后面的測試 Case 能正常運行，在使用文心一言時，會在保留正確工具的同時，盡可能縮減 Appilot 的工具集。
?
05 ChatGLM
ChatGLM 的輸出結(jié)果也是編造的，它所列出的都是不存在的服務(wù)，與文心一言一致。
?
本輪評測結(jié)果
?
Case 1：部署服務(wù)
目標：本用例以“在阿里云上部署一個通義千問模型服務(wù)”為任務(wù)，測試 LLM 是否具備調(diào)用多個工具完成任務(wù)的邏輯推理能力。
?
輸入：
- deploy a qwen service
- upgrade qwen to instance ecs.c7.16xlarge
?
預(yù)期：
- 獲取到通義千問相關(guān)的模版，使用模版在阿里云上部署一個 qwen 的 ECS 實例;
- 獲取原來 qwen 服務(wù)的模版信息，修改機器類型為
ecs.c7.16xlarge并更新服務(wù)；
?
01 GPT-4
部署通義千問服務(wù)
?
從 Reasoning 的提示和 Walrus 的后臺日志中可以看到，GPT-4 調(diào)用了3個工具來完成任務(wù)：
-
find_match_template尋找與部署相關(guān)的模版。工具先通過/v1/templates獲取所有模版，然后將所有模板返回給 GPT-4，問它哪個是 qwen 相關(guān)的模版； -
construct_service_to_create構(gòu)建要部署的目標模版，工具內(nèi)部使用 RAG 來完成。這里將上一步找到的模版，加上原任務(wù)內(nèi)容，發(fā)送給工具，由 RAG 的 Agent 來生成目標模版，也就是上圖中的 Input； -
create_service創(chuàng)建服務(wù)，將上一步構(gòu)建好的模版應(yīng)用到系統(tǒng)中；
?
部署成功后，我們可以在 Walrus 和阿里云的 ECS 控制臺看到創(chuàng)建的資源。
?
?
升級服務(wù)
?
GPT-4 的實現(xiàn)與創(chuàng)建服務(wù)的邏輯鏈相似，但新增了一個步驟，即通過 get_template_schema 工具來獲取已經(jīng)部署的 qwen 服務(wù)，隨后對 qwen 服務(wù)進行更新。
?
02 Llama2
部署通義千問服務(wù)
?
Llama2 將輸入中的 qwen service 識別為一個模版的名稱，所以查找模版失敗了。把輸入改為 deploy a qwen，Llama2 即可正確部署服務(wù)。這里可以看出 Llama2 的邏輯推理能力有些差距。
?
然而，部署成功后 Llama2 “自作聰明”地給出一段建議，內(nèi)容是關(guān)于在服務(wù)部署成功后應(yīng)該怎么做。可惜這不是提示詞中規(guī)定的格式，因此 Appilot 識別失敗報錯。
?
升級服務(wù)
?
Llama2 期望使用一個名為 qwen-ecs-upgrade模版來進行升級服務(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é)合錯誤日志和 Walrus 后臺日志，可以得知：
- 使用
deploy a qwen service作為輸入時，通義千問直接以qwen_service作為模版名稱，調(diào)用get_template_schema工具獲取qwen_service模版，所以失敗了。 - 使用
deploy qwen作為輸入，通義千問能調(diào)用find_matching_template工具來查找模版，但是結(jié)果輸出為一個 json 結(jié)構(gòu)，并將其作為下一步get_template_schema的輸入，所以也失敗了。
?
升級服務(wù)
?
因為前一步無法創(chuàng)建服務(wù)，所以先手動創(chuàng)建了一個 qwen 服務(wù)。
?
通義千問將任務(wù)錯誤識別為部署一個新的服務(wù)，反而“陰差陽錯”地執(zhí)行了上一步的任務(wù)。
?
可以看出通義千問對需要處理多步驟的復(fù)雜任務(wù)的邏輯推理能力也有所欠缺。
?
04 文心一言
部署通義千問服務(wù)
?
部署提示已經(jīng)構(gòu)造了服務(wù)對象。
?
打開 VERBOSE 開關(guān)查看原始提示詞，看到文心一言編造了一系列調(diào)用記錄。
?
升級服務(wù)
這里看到文心一言輸出的 json 結(jié)構(gòu)也是編造的。
?
05 ChatGLM
部署通義千問服務(wù)
?
部署提示已經(jīng)構(gòu)造了服務(wù)對象，但實際并沒有。
?
同樣，ChatGLM 編造了一系列調(diào)用記錄。
?
升級服務(wù)
?
ChatGLM 聲稱完成了升級，但檢查系統(tǒng)發(fā)現(xiàn)也是幻覺。
?
本輪評測結(jié)果
?
Case 2：在K8s上部署從源碼構(gòu)建的spring-boot服務(wù)
目標：測試 LLM 邏輯推理和 RAG 模版生成能力。
?
輸入：
deploy seal-demo/spring-boot-docker-sample:feature, configure registry auth with project env, push image to rainfd/spring
?
預(yù)期：
獲取到從源碼部署相關(guān)的模版，填入目標的 GitHub 地址、Docker Hub 相關(guān)環(huán)境變量和鏡像名稱，最后成功部署。
?
01 GPT-4
推理邏輯與 Case1 一致，能正確填入輸入中的 image 和 GitHub 地址，并使用環(huán)境變量配置 Registry 認證相關(guān)的兩個參數(shù)。
?
02 Llama2
Llama2 將輸入中的 GitHub 倉庫地址識別為模版名稱 spring-boot-docker-sample，所以直接失敗了。
?
03 通義千問
?
通義千問將輸入的deploy service 識別為模版名稱，可以推斷通義千問沒有理解這個輸入的正確含義。
?
04 文心一言
文心一言仍未能按照規(guī)定的提示詞進行輸出，而是輸出一個自己偽造的 json 結(jié)構(gòu)，并將一些任務(wù)相關(guān)的內(nèi)容填入到偽造的 json 內(nèi)容中。
?
05 ChatGLM
ChatGLM 能夠調(diào)用正確的工具并構(gòu)建了部署服務(wù)的請求體，但推理能力較差，導(dǎo)致缺失了部分配置，使得雖然創(chuàng)建了服務(wù)，但最終的部署沒有成功。
?
本輪評測結(jié)果
?
Case 3：切換環(huán)境、過濾服務(wù)、克隆環(huán)境
目標：測試 LLM 的邏輯推理和工具調(diào)用能力。
?
輸入：
- switch env to qa
- list all nginx services with the name test
- clone qa env to staging env
?
預(yù)期：
- 默認的 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 中看到一個新的 staging 環(huán)境，并且其中正常部署著與 qa 環(huán)境相同的3個服務(wù)。
?
02 Llama2
切換環(huán)境
?
從 Reasoning 可以看到，在 Llama2 的推理步驟中，第一步尚能正確理解任務(wù)，但是第二步開始跑偏，最終從切換環(huán)境一步步跑偏到要執(zhí)行部署任務(wù)。
?
過濾服務(wù)
?
從 Llama2 的“錯誤結(jié)果”可以看到已經(jīng)調(diào)用 list_services獲取了當(dāng)前環(huán)境的所有服務(wù)，但需要進一步過濾時，直接返回了不遵循格式的輸出，導(dǎo)致 Appilot 無法識別而報錯。
?
克隆環(huán)境
?
Llama2 能正確理解任務(wù)并調(diào)用 clone_environment工具，但是輸入偽造了一個 id。
?
03 通義千問
切換環(huán)境
?
通義千問能夠正確切換環(huán)境。
?
過濾服務(wù)
?
通義千問似乎也能正確調(diào)用 list_services工具，但是結(jié)果為空。
?
打開 VERBOSE 開關(guān)查看原始提示詞，發(fā)現(xiàn)通義千問產(chǎn)生了已經(jīng)將結(jié)果返回的幻覺，也沒有進一步按照要求過濾服務(wù)。
?
克隆環(huán)境
?
通義千問克隆環(huán)境調(diào)用正確。
?
04 文心一言
切換環(huán)境
?
文心一言輸出的 json 結(jié)果是 change_context工具的輸入，但是project_name 是偽造，實際名稱為default。
?
過濾服務(wù)
?
文心一言這里輸出的格式雖然符合提示詞中的格式要求，但是從 Reasoning 中看到并沒有調(diào)用工具獲取當(dāng)前環(huán)境的服務(wù)，而是偽造了一個結(jié)果。
?
克隆環(huán)境
?
文心一言的輸出格式錯誤，但看起來似乎只是格式不對，但 Action 中的工具還是錯的，不存在 clone_env 這個工具，正確的是 clone_environment。
?
05 ChatGLM
切換環(huán)境
?
ChatGLM 可以正確切換環(huán)境。
?
過濾服務(wù)
?
ChatGLM 對服務(wù)過濾的結(jié)果是編造的。
?
克隆環(huán)境
?
雖然推理邏輯不太對，但 ChatGLM 選擇了正確的工具調(diào)用完成了克隆環(huán)境。
?
本輪評測結(jié)果
?
Case 4：查看故障服務(wù)，嘗試診斷故障并修復(fù)問題
目標：測試 LLM 對診斷場景的邏輯推理能力。
?
當(dāng)前 test 環(huán)境包含了兩個異常的服務(wù)：
?
輸入：
- diagnose app-1
- fix app-1
- diagnose app-2
?
預(yù)期：
- 診斷出 app-1 服務(wù)使用的鏡像
nginx:a.b.c為錯誤的鏡像； - 更新服務(wù)，修復(fù)為正確的鏡像標簽；
- 診斷出 app-2 服務(wù)日志中的代碼錯誤。
?
01 GPT-4
診斷修復(fù) app-1 服務(wù)
?
可以看到 GPT-4 正確利用現(xiàn)有的工具獲取 app-1 服務(wù)的相關(guān)信息，包括服務(wù)詳情、服務(wù)相關(guān)的資源和服務(wù)日志。識別到錯誤后，更新了 app-1 服務(wù)，將錯誤的 Image 修改為正確的 nginx:latest 。
?
診斷 app-2 服務(wù)
?
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服務(wù)
?
從前幾步看，似乎 Llama2 能理解診斷任務(wù)，并不斷獲取 app-1的相關(guān)信息，但是在獲取服務(wù)詳情的那一步報錯。
?
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 日志得知，通義千問偽造了一個不存在的 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)信息，但在使用工具獲取日志時，編造了 resource 的名字，因此獲取日志失敗。
?
05 ChatGLM
診斷app-1服務(wù)
?
ChatGLM 其結(jié)果是與實際情況無關(guān)的幻覺。
?
在本 Case 中，除了 GPT-4 以外評測的其它大模型都無法通過第一個較為簡單的診斷任務(wù)，更別說更復(fù)雜的第二個任務(wù)了。
?
本輪評測結(jié)果
?
成本對比
這里以 Case 0 為例，測試在 Appilot 中輸入 list services 時，調(diào)用基礎(chǔ)工具 list_service ，需要的相關(guān)耗費（美元兌人民幣按1:7折算）：
?
注：其中 Llama2 模型按照本次測試使用的 AWS ml.g5.48xlarge 實例包年包月價格$6.515/小時（非并發(fā)推理計算)
?
總 結(jié)
根據(jù)上述評測過程，在 Appilot 的應(yīng)用場景下，可以得出以下結(jié)論：
?
市面上的所有預(yù)訓(xùn)練大語言模型中，針對類似于 Appilot 的 AI agent 場景，GPT-4 依然獨領(lǐng)風(fēng)騷。跟 GPT-4 相比，其他大語言模型還有較大的差距，主要體現(xiàn)在以下三個方面：
-
遵循提示詞格式的能力：AI agent 通常具有較長上下文的提示詞，大語言模型需要遵循提示詞中規(guī)定的輸出格式來獲取調(diào)用的工具和輸入?yún)?shù)。如果大模型返回結(jié)果的格式無法遵循要求，幾乎無法解析成為下一步工具調(diào)用的輸入；
-
邏輯推理能力：GPT-4 能夠完成多個工具調(diào)用的推理鏈條，配合完成復(fù)雜任務(wù)，其他模型的推理能力不足，難以完成需要多步驟調(diào)用工具完成目標的復(fù)雜任務(wù)；
-
輸出的穩(wěn)定性：即使將輸出多樣性的參數(shù) temperature 調(diào)至最低，在輸入相同的情況下，一些大語言模型依然會產(chǎn)生不穩(wěn)定的輸出。
?
除了 GPT-4 以外，其余評測的4款大語言模型的具體體驗如下：
-
Llama2：如果是簡單輸入場景，Llama2 能跟對應(yīng)的工具進行關(guān)聯(lián)。大部分能根據(jù)提示詞找到對應(yīng)工具，并按照規(guī)定格式正確輸出內(nèi)容。如果輸入復(fù)雜，完成任務(wù)需要多個工具的配合，那么它極少地展現(xiàn)它的復(fù)雜推理能力，更多時間是答非所問。即便正確調(diào)用工具后，偶爾還會輸出一些看似與輸入相關(guān)，但實則與提示詞規(guī)定無關(guān)的內(nèi)容。
-
通義千問：在簡單輸入的場景下，通義千問一般都能正確調(diào)用工具獲取結(jié)果，相較 Llama2 穩(wěn)定。但在復(fù)雜輸入的場景下，千問的推理能力短板也暴露出來了，基本無能為力。
-
文心一言：4800的輸入限制幾乎使得文心一言直接“退賽”，即使精簡了 Appilot 的工具集，從測試效果上看，文心一言也是這幾個模型中最差的，不僅大多數(shù)情況下都不能按照提示詞規(guī)定的格式輸出內(nèi)容，還常常編造與提示詞和輸入完全無關(guān)的結(jié)果，幻覺過多。
-
ChatGLM：與通義千問類似，部分簡單場景下可以獲取預(yù)期結(jié)果，但無法處理需要多步驟執(zhí)行的復(fù)雜任務(wù)。
?
除上述幾個模型外，作者還嘗試了其他的模型，例如 Xwin-LM-70B-V0.1、Mistral-7B-Instruct-v0.1 等模型，但它們的測試結(jié)果與文心一言的結(jié)果類似，基本無法按照提示詞給定的格式進行輸出，直接無法使用。
?
按實際表現(xiàn)來說，除了 GPT-4 以外的這些大模型基本是不可用的，遠遠低于我們的期望和模型提供方所宣傳的效果。一方面這些大模型在能力和成熟度上仍然還需努力，另一方面 Appilot 在對接這些大模型時，還需要用到更多的提示詞優(yōu)化、微調(diào)等技術(shù)進行完善。
?
從模型的耗時和成本對比可以看到，GPT-4 雖然優(yōu)秀，但費用相對高昂。其它預(yù)訓(xùn)練大語言模型的測試表現(xiàn)雖然不佳，但從成本和實際落地的需求場景出發(fā)，未來依然具備一定的潛力。因此，后續(xù)工作可以考慮兩個方向：
-
針對特定的垂直領(lǐng)域，基于 Llama2 等開源大語言模型進行微調(diào)，從而提升性能和可靠性。除此之外還可以使用量化和其他推理加速的手段，降低大語言模型部署成本和推理的耗時，幫助 AI agent 類 LLM 應(yīng)用真正落地。
-
基于通義千問之類的大模型，即具備基礎(chǔ)能力且部署成本較低，通過提示詞優(yōu)化、使用嵌入（Embedding）技術(shù)以及進行 Few-shot 學(xué)習(xí)等優(yōu)化方向來增強 LLM 應(yīng)用的準確性。
?
上述大語言模型的測試匯總記錄如下：
?
此次評測只是階段性的評測，考慮到目前大模型領(lǐng)域仍然高速發(fā)展，GPT-4-Turbo、通義千問2.0、ChatGLM3 等更新的大模型版本還未正式上線，未來我們將保持每半年一次的評測頻率，持續(xù)跟進主流大模型在 AI agent 場景下，對 DevOps 這樣的垂直領(lǐng)域的實際應(yīng)用效果。也會加入更多的評測內(nèi)容，例如中文對話、更完善的用例設(shè)計、更多的大模型等，更加綜合具體地評估各個大模型的表現(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/
[ 阿里云靈積平臺 ]：https://dashscope.aliyun.com/
[ ChatGLM ]: https://chatglm.cn/
?
總結(jié)
以上是生活随笔為你收集整理的通义千问, 文心一言, ChatGLM, GPT-4, Llama2, DevOps 能力评测的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 把财富化为阴德，福泽子孙
- 下一篇： 揭开“速效壮阳药”的可怕面纱