作者 | rhino

自 “Prompt工作手冊” 發(fā)布以來，我持續(xù)研究大模型能力的應(yīng)用及研發(fā)方法，結(jié)合產(chǎn)業(yè)發(fā)展，在研發(fā)框架和模型應(yīng)用上有了新的思考，并形成了新的方法論，希望我們的能力不僅僅停留在模型研發(fā)的某一階段，而能貫穿在研發(fā)全流程之上。本文介紹了我們近半年的工作成果，通過對研發(fā)框架的工程化，我們大幅降低了模型應(yīng)用研發(fā)的成本，讓人人都能開發(fā)大模型應(yīng)用。

一、寫在前面

1. 大模型應(yīng)用是未來也是現(xiàn)在

“大模型” 爆發(fā)至今已有 2 年的時間，行業(yè)持續(xù)火熱，模型基礎(chǔ)能力持續(xù)升級。2024.9. OpenAI 發(fā)布的 “O1” 模型為領(lǐng)域再一次帶來了新的突破，期間多模態(tài)也持續(xù)展現(xiàn)了令人驚喜的發(fā)展。于此同時，成本的降低與效率的提升也在持續(xù)進行，讓大模型融入到了更多的場景之上。但相對的，在模型基礎(chǔ)能力突飛猛進的背景下，“模型應(yīng)用” 的發(fā)展就顯得相形見絀，從 “領(lǐng)域模型” 到 “AI原生應(yīng)用” 再到 “AI-Agent”，這些應(yīng)用層的概念均獲得了極高的熱度，但時至今日，人們也沒有看到新時代的到來，AI應(yīng)用并沒有如人們預(yù)期的一樣爆發(fā)，其原因是什么呢？

我們可以從 “2024 Gartner AI 技術(shù)成熟度曲線” 中得到一些啟發(fā)，“Generative AI” 即如今大模型使用的底層技術(shù)，已經(jīng)到了 “期望膨脹期” 和 “泡沫破裂期” 的邊界點上。這個敏感的節(jié)點表明，在前期的發(fā)展中，領(lǐng)域已經(jīng)積累了大量的 “偽創(chuàng)新”，且在未來的一段時間里，偽創(chuàng)新會被大量的清洗，留下那些真的“金子”，穩(wěn)步爬升，直至成熟。從這個角度，“AI應(yīng)用” 對曲線來說似乎還是一個 “過早” 的話題，“穩(wěn)步爬升” 期才是應(yīng)用會大量爆發(fā)的時期，這在其他科技領(lǐng)域的發(fā)展中也可以被觀察到（PC互聯(lián)網(wǎng)，移動互聯(lián)網(wǎng)）。

而這與大多數(shù)人的感受似乎有所差異，我們可以很明顯的感知到大模型能力的強大，并且實際上，我們也已經(jīng)在很多場景中使用它了，那為什么現(xiàn)在 “AI應(yīng)用” 似乎還是為時過早，還是有些沒到時候呢？上面這張趨勢圖中除了 “Generative AI” ，還有包含很多技術(shù)點，代表了AI各個領(lǐng)域的發(fā)展?fàn)顟B(tài)，其中不乏和大模型相關(guān)的領(lǐng)域，如：

• 發(fā)展期：AI Engineering，Model Ops，Prompt Engineering
• 萌芽期：Multiagent Systems，Decision Intelligence，AI-Ready Data，F(xiàn)irst-Principles AI，AGI

我們稍加觀察就可以發(fā)現(xiàn)，這些與 “AI應(yīng)用” 相關(guān)的領(lǐng)域，大多還處于 “發(fā)展期” 和 “萌芽期”。這些技術(shù)都是模型應(yīng)用開發(fā)的關(guān)鍵節(jié)點，對模型的應(yīng)用效果起到了決定性的影響。例如，我們最熟悉的 “Prompt Engineering”，一個幾乎和大模型同時誕生的概念，在領(lǐng)域發(fā)展期間得到了持續(xù)的關(guān)注和研究，但直至今日依然處于發(fā)展的早期階段。再如，近期火熱的 “Multiagent System”，對于模型的應(yīng)用效果，尤其是工業(yè)化的應(yīng)用效果，至關(guān)重要，在2023年就被認(rèn)為是未來最重要的技術(shù)之一，但時至今日依然處于 “萌芽期”。

如果我們綜合觀察這些技術(shù)的現(xiàn)狀，不難得到一個結(jié)論：應(yīng)用技術(shù)的落后成為了模型應(yīng)用的關(guān)鍵阻礙。

在領(lǐng)域的發(fā)展中，持續(xù)有一種聲音存在：模型的效果的根本取決于模型的基礎(chǔ)能力，在模型基礎(chǔ)能力的高速發(fā)展時期，不應(yīng)該過多做應(yīng)用層的事，基于當(dāng)前模型能力做的工作，可能被一次模型升級徹底推翻。這種想法不無道理，但站在今天的視角下，我們看到模型基礎(chǔ)能力的發(fā)展速度在明顯衰減，人們對模型應(yīng)用的需求持續(xù)增長，各項模型應(yīng)用的基礎(chǔ)能力仍待增強。所以，要做出更好的模型應(yīng)用，不能再像以前一樣，僅僅依靠模型能力的升級，而是要把盡力投入到模型應(yīng)用技術(shù)的建設(shè)當(dāng)中。

以上，我從領(lǐng)域發(fā)展的角度，闡述了應(yīng)用側(cè)技術(shù)的不成熟是大模型難以應(yīng)用的關(guān)鍵，并引出了我們希望通過模型應(yīng)用層的工作，讓模型能力更好的落地。下面我就來具體分析，應(yīng)用側(cè)技術(shù)的不成熟，對模型能力的應(yīng)用產(chǎn)生了哪些阻礙？我們具體想做什么？

2. 什么阻礙了模型應(yīng)用？

首先，我們再來重新看看前文中提到的這些應(yīng)用層能力，我們可以大致把他們劃分為2種，一種是幫助開發(fā)者更好的完成模型能力的研發(fā)和部署，另一種是更好的利用模型能力產(chǎn)生更好的應(yīng)用效果。

模型應(yīng)用的研發(fā)&部署：AI Engineering，Model Ops，Prompt Engineering

模型應(yīng)用效果：

• 綜合行為能力：Agent，MultiAgent Systems
• 推理能力：Decision Intelligence，F(xiàn)irst-Principles AI
• 數(shù)據(jù)能力：AI-Ready Data

這也就對應(yīng)了模型在實際應(yīng)用階段的問題：開發(fā)成本高，應(yīng)用效果差。

(1) 模型研發(fā)成本高昂

首先，需要對我們所說的模型應(yīng)用加以說明。一方面看，即便不使用任何技術(shù)，今天的大模型依然可以產(chǎn)生令人驚喜的效果，但當(dāng)我們要將其應(yīng)用到工作中時，就會發(fā)現(xiàn)其存在的各種問題，例如：穩(wěn)定性，準(zhǔn)確性，可控性，以及 “對齊” 問題等等，而我們討論的也正是這種場景。

為了解決這些問題，我們就需要使用一些技術(shù)，例如：

• Prompt工程：通過優(yōu)化Prompt框架，影響模型的輸入，獲得更好的效果。
• 模型訓(xùn)練：通過數(shù)據(jù)訓(xùn)練的方式，影響模型的參數(shù)，獲得更好的效果。
• RAG & 知識庫：賦予模型檢索外部數(shù)據(jù)的能力，以補充模型知識不足的問題，獲得更好的效果。
• Agent系統(tǒng)：通過拓展模型的能力(記憶，插件，多模型調(diào)度)，以及構(gòu)建由多個模型組成的系統(tǒng)，獲得更好的輸出。

這些技術(shù)即便有對應(yīng)的工具支持，也都有較高的使用門檻，需要使用者具備一定的專業(yè)能力，這也就對模型的研發(fā)造成了不小的成本。即便是其中技術(shù)難度相對較低的 “Prompt 工程”，也已經(jīng)不斷發(fā)展中積累了不少的技巧，還包含不同模型之間的分別，“非技術(shù)人員” 想要掌握并不簡單。

其次，即便開發(fā)者掌握了一些技術(shù)（可以完成Prompt的編寫），也很難獨立完成模型應(yīng)用的研發(fā)。整體的研發(fā)流程不僅是單一模塊的工作，涉及 “數(shù)據(jù)”，“算法”，“工程” 等多個模塊，包含 “數(shù)據(jù)準(zhǔn)備”，“數(shù)據(jù)標(biāo)注”，“問題建模”，“能力研發(fā)”，“效果評測”，“模型調(diào)試”，“上線部署”，“落地應(yīng)用”，“優(yōu)化迭代” 等多個階段，是一項系統(tǒng)化的工程，這也對模型的應(yīng)用造成極大的成本。

因此，即便人人都可以在和模型 “聊天” 的時候感受到模型能力的強大，但并非人人都能真的應(yīng)用模型。

(2) 模型效果優(yōu)化困難

前文說了模型的開發(fā)成本，此處還需要說明模型的應(yīng)用效果，兩者有所關(guān)聯(lián)，但不完全一致。由于大模型的基礎(chǔ)能力所限，即便模型能力在不斷更新迭代，其依然存在若干無法根治的問題，例如：

• 知識不足：模型并非知識庫，在很多時候會展現(xiàn)出知識上的不足，尤其是在應(yīng)對： “高時效性知識” ，“專業(yè)領(lǐng)域知識” ，“業(yè)務(wù)領(lǐng)域知識”。
• 推理能力不足：目前的大多數(shù)模型，都存在推理能力不足的問題，尤其是在面對數(shù)理問題時，甚至無法完成最基礎(chǔ)的數(shù)理邏輯，即便是在 “O1“ 發(fā)布以來，推理能力仍然被認(rèn)為是如今大模型最需提升的能力之一。
• 穩(wěn)定性不足：自大模型誕生以來，“不穩(wěn)定性” 就是被人們談?wù)撟疃嗟膯栴}，今天我們可以看到“幻覺”問題已經(jīng)大幅減少，但效果上的不穩(wěn)定依然存在，并且實際影響到了模型的“可控性”，目前還沒有得到很好的解決。

當(dāng)然，我們有一些技術(shù)手段來應(yīng)對這些問題，例如：

• RAG：從行業(yè)的趨勢，慢慢長成了行業(yè)的共識，很好的解決了 “知識不足” 的問題， 時至今日已經(jīng)演化出多中類型的方法，已應(yīng)對不同種類的數(shù)據(jù)，并且知識應(yīng)用的效果也得到了大幅的提升。
• Hidden COT：O1 模型的發(fā)布在模型推理上帶來的新的突破，從OpenAI官網(wǎng)的文章及各種的采訪中，我們可以大致了解到 O1 使用了 Hidden COT 的技術(shù)。如果分析OpenAI官網(wǎng)給出的例子的話，會發(fā)現(xiàn)它確實能通過這樣逐步拆分，提升其推理能力，并在這樣逐步的思考中，意識到之前犯的錯誤，并自動進行修正。這種問題切分和錯誤修正的能力對于模型能做長鏈條思考及解決復(fù)雜任務(wù)非常重要。
• Agent & MultiAgent：要讓模型真的在應(yīng)用中發(fā)揮效果，僅僅讓模型 “聊天” 是遠(yuǎn)遠(yuǎn)不夠的。我們可以賦予模型更多的能力，讓他幫我們?nèi)ネ瓿蓪嶋H的任務(wù)，讓他有記憶，會計劃，能執(zhí)行。同時，我們可能還需要更多的模型加入，組建一個由Agent組成的團隊，去完成更加復(fù)雜的任務(wù)

這些技術(shù)可以幫助我們更好的應(yīng)用模型的能力，讓他發(fā)揮出更好的效果。然而，這些技術(shù)還都處于“萌芽期”，還在不斷的產(chǎn)生和迭代。換句話說，只有用好這些“技術(shù)”，模型才能在應(yīng)用中展現(xiàn)出令人滿意的“效果”，即便是對專業(yè)的技術(shù)人員，這也是一項不太容易的工作。這些技術(shù)中的存在的專業(yè)壁壘，也對模型應(yīng)用的研發(fā)造成了不小的困難。

3. 模型應(yīng)用研發(fā)的痛點

痛點：模型效果難優(yōu)化，成本高，技術(shù)挑戰(zhàn)大

如前文所述，模型應(yīng)用的開發(fā)成本高，應(yīng)用效果差。這使得，即便大模型的基礎(chǔ)能力十分強大，大家也無法真的把他應(yīng)用起來。

大模型的能力本是通用的，大家對未來的暢想，也是希望他是通往AGI的道路。但由于他極高的研發(fā)成本，和不可靠的應(yīng)用效果，模型應(yīng)用從通用走向了定制，開發(fā)模式也變成了集中化的閉源模式，并且，這并不是一兩個模塊的改進就可以解決的，而是整個研發(fā)流程都需要進行的優(yōu)化。

目前市場上也不乏有一些單一環(huán)節(jié)的研發(fā)工具，如：Prompt工具，模型訓(xùn)練工具，模型調(diào)度工具。這些工具無疑是降低了研發(fā)環(huán)節(jié)的成本，并提供了一定的效果保障。但如果我們要讓每個人都能完成模型的應(yīng)用，這還遠(yuǎn)遠(yuǎn)不夠。單一環(huán)節(jié)工具帶來的降本增效，往往是面向開發(fā)人員的，并沒有起到降低專業(yè)壁壘的作用。要降低應(yīng)用模型的成本，首先要降低研發(fā)流程的成本，讓每個人都能較低成本的完成這個研發(fā)過程，比單一環(huán)節(jié)的優(yōu)化更為重要。

尤其是對于大模型的領(lǐng)域化應(yīng)用而言，依賴算法專業(yè)人員集中式的構(gòu)建領(lǐng)域能力，不僅與大模型通用化的發(fā)展趨勢不符，也不能滿足領(lǐng)域的訴求。只有讓領(lǐng)域內(nèi)的專家（非算法開發(fā)人員）自己完成模型的應(yīng)用，搭建類似開源的能力研發(fā)生態(tài)，才能真的做到模型能力的領(lǐng)域化，畢竟領(lǐng)域最重要的價值，是領(lǐng)域內(nèi)的人，而并非紙面上的知識和技術(shù)。

二、讓人人都能開發(fā)大模型應(yīng)用

前文分析了我們希望解決的問題，以及我們想達(dá)到的效果。我們希望可以降低模型的研發(fā)成本，提升模型研發(fā)的效率和應(yīng)用的效果，讓每個人都能完成模型能力的應(yīng)用。

近 1 年多的時間里，我一直在探索大模型和“質(zhì)效”領(lǐng)域的結(jié)合，希望可以將模型能力融入到業(yè)務(wù)的質(zhì)效工作當(dāng)中，在 “測試用例”，“缺陷”，“需求”，“代碼” 等領(lǐng)域中完成了若干嘗試，其中也有不少能力在業(yè)務(wù)落地，并取得成效。但在工作中，也遇到了一些明顯的阻礙：

模型研發(fā)效率無法匹配領(lǐng)域訴求：質(zhì)效領(lǐng)域是一個貫穿產(chǎn)品研發(fā)周期的領(lǐng)域，其中包含大量的領(lǐng)域訴求，僅僅“測試用例”相關(guān)的模型能力點，就可以做到上百個。并且在領(lǐng)域和業(yè)務(wù)常年的積累下，訴求的定制化嚴(yán)重，可復(fù)用性差。而在這種情況下，模型能力從研發(fā)到應(yīng)用落地的周期為，“1個/人月”，與領(lǐng)域訴求存在巨大差距。

模型研發(fā)人員無法掌握領(lǐng)域?qū)I(yè)：質(zhì)效領(lǐng)域的每個模塊都包含著大量的專業(yè)知識和專家經(jīng)驗，結(jié)合復(fù)雜的業(yè)務(wù)知識，模型研發(fā)人員很難完全掌握，而這些領(lǐng)域往往又不具備大量的數(shù)據(jù)，在模型研發(fā)過程中就十分依賴研發(fā)者的專業(yè)能力，而這些復(fù)雜的專業(yè)能力又不是非領(lǐng)域人員可以輕松掌握的，這無論是對模型能力的研發(fā)效率還是應(yīng)用效果都造成了極大的苦難。

無法與領(lǐng)域?qū)＜医⒏咝У膮f(xié)作模式：領(lǐng)域?qū)＜姨峁I(yè)知識和指導(dǎo)是模型重要的輸入之一，但由于算法與領(lǐng)域均包含較高的專業(yè)壁壘，且模型研發(fā)流程不規(guī)范，導(dǎo)致很難建立高效的協(xié)作模型，領(lǐng)域?qū)＜业闹R很難傳導(dǎo)至模型。

這些問題并不專屬“質(zhì)效”領(lǐng)域，對于大多數(shù)模型應(yīng)用的場景都存在類似的問題：領(lǐng)域?qū)＜覠o法應(yīng)用模型，模型開發(fā)人員不了解領(lǐng)域知識。

因此，我們希望降低模型應(yīng)用的研發(fā)成本，降低專業(yè)壁壘，提高模型的研發(fā)效率。讓領(lǐng)域內(nèi)的人都能完成模型應(yīng)用的研發(fā)，都能完成模型能力的應(yīng)用。以此讓模型能力更好的在領(lǐng)域內(nèi)落地，持續(xù)推進大模型的領(lǐng)域化。

目標(biāo)：讓人人都能完成大模型應(yīng)用

• 人人：對大模型(AI)不了解的人(領(lǐng)域?qū)＜?
• 完成：低成本的滿足自己的訴求，并達(dá)到穩(wěn)定的效果
• 大模型應(yīng)用：能在實際場景中落地，并產(chǎn)生應(yīng)用效果

三、大模型研發(fā)框架

為了達(dá)到前文中闡述的目標(biāo)，我們希望打造一個模型應(yīng)用的研發(fā)工具，可以幫助大家降低模型研發(fā)的成本，提升模型研發(fā)的效率。與目前市場上的模型研發(fā)的工具不同，目前的研發(fā)框架在效率和效果上可以提供一定的幫助，但并未降低模型研發(fā)的專業(yè)比例，大多還是面向技術(shù)人員，對用戶提出了不小的技術(shù)門檻。

我們希望通過大模型能力的加持，對整體研發(fā)流程進行改進，讓用戶僅需處理“任務(wù)”維度的信息即可完成研發(fā)。類似于 “2024百度世界大會” 上發(fā)布的“秒噠”工具，一款不用寫代碼就能實現(xiàn)任意想法，輸入自然語言或PRD，即可生成應(yīng)用，無需技術(shù)與設(shè)計經(jīng)驗的無代碼開發(fā)工具。我們也希望研發(fā)一個針對模型能力的 “MultiAgent” 系統(tǒng)，通過簡單的輸入即可完成模型應(yīng)用的生成。

與現(xiàn)有模型研發(fā)工具的差異：

• 面向所有人：我們希望可以讓所有人都可以低成本的實現(xiàn)一項模型能力，而非僅僅針對專業(yè)人員
• 我們本身就是一個多智能體系統(tǒng)：我們希望搭建由多智能體組成的系統(tǒng)，具備各個環(huán)節(jié)的模型研發(fā)能力，盡可能降低各個環(huán)節(jié)的成本
• 不僅僅是針對單一模塊：我們并不想成為某一單一環(huán)節(jié)的增效工具，而是希望從目標(biāo)出發(fā)，作用于研發(fā)全流程上。

1. 從 “Prompt工程” 到 “模型研發(fā)框架”

正如我們之前論述的，我們希望賦能在研發(fā)全流程上，而非單一的研發(fā)環(huán)節(jié)。但實際上，最初我們想做的和很多人一樣，僅僅是一個 “Prompt工具”，這里的心路歷程是怎樣的呢？

“Prompt” 是影響模型效果最直接的變量，領(lǐng)域中充斥了大量對Prompt的研究，我也并不例外。在大模型應(yīng)用的探索中，為了更好的讓Prompt產(chǎn)生穩(wěn)定的效果，為了提升對Prompt的管理能力，以及Prompt生成的效率，我花了不少時間聚焦在Prompt框架的研究上、。

對于 “Prompt工程” 的框架化進而產(chǎn)生了工程化的想法，是否可以通過將“Prompt工程”工具化，幫助開發(fā)者自動完成Prompt的編寫和優(yōu)化呢？事實上，無論是方法，框架，產(chǎn)品，這類工具在市場上都并不少見：

• 算法：APE ，APO，OPRO
• 技術(shù)框架：DsPy 提示詞工程自動優(yōu)化框架(一種自動優(yōu)化提示詞的方法)
• GitHub - stanfordnlp/dspy: DSPy: The framework for programming—not prompting—foundation models

關(guān)于 DSPy | AI工具中文文檔

產(chǎn)品：

• Prompt優(yōu)化_大模型服務(wù)平臺百煉(Model Studio)-阿里云幫助中心
• PromptPerfect - AI Prompt Generator and Optimizer
• Prompt優(yōu)化 - ModelBuilder

這些產(chǎn)品都可以幫助用戶完成Prompt的生產(chǎn)，他們了解各類大模型的特點，善于使用各種Prompt技巧性，并可以通過算法結(jié)合數(shù)據(jù)不斷對Prompt進行優(yōu)化。這無疑對 Prompt 的生產(chǎn)和管理提供了極大的幫助，在大模型日新月異的今天，即便是Prompt專家也很難熟悉每種模型的特點，和每一種Prompt技巧，這些工具是一個很好的幫手，可以顯著提升Prompt編寫的效率和效果。

但如果我們進一步思考，即便Prompt工程對模型效果十分重要，但他只是一種技巧，并非模型研發(fā)的 “第一性”。甚至在很多場景下，人們會對該使用什么技巧產(chǎn)生爭論，例如 “Prompt” 和 “模型訓(xùn)練” 的爭論。

基于目前大模型自身強大的能力，我們認(rèn)為模型研發(fā)的 “第一性” 就是 “提升應(yīng)用效果”，用戶不需要也不應(yīng)該了解模型研發(fā)背后的技術(shù)，只需要對當(dāng)下的任務(wù)負(fù)責(zé)，對當(dāng)前的效果負(fù)責(zé)即可，而比起提供若干的Prompt技巧，對“提升應(yīng)用效果”更有幫助的問題或許是：

• 如何評估效果：目前的Prompt好不好，效果怎么樣？
• 如何 debug：模型犯了某種錯誤，我該如何調(diào)試？
• 如何優(yōu)化模型：模型某些方面的能力不夠強，我該怎么辦？
• 如何應(yīng)用模型：我怎么把模型用到工作中？

這些問題均不指向某個單一的研發(fā)模塊，而是更全面的指向整個研發(fā)流程。大家需要的不僅是一段段的Prompt，而是一個可以幫助我們不斷提升模型應(yīng)用效果的工具。因此，我們最終把目標(biāo)轉(zhuǎn)向了模型研發(fā)流程的工具化，希望這個工具能讓每個人能具備應(yīng)用模型的能力。

2. 模型研發(fā)流程

簡單來說，我們就是希望在“大模型應(yīng)用研發(fā)”的過程中，用AI的方式，幫助用戶做一些工作，首先我們先來看看大模型應(yīng)用研發(fā)的過程：

結(jié)合我在模型應(yīng)用研發(fā)上的探索，目前的模型應(yīng)用研發(fā)工作可以大致分為如下幾個環(huán)節(jié)：

(1) 建模：首先我們要對問題進行定義，明確需要模型為我們做什么。從業(yè)務(wù)視角看，我們要把模型能力引入到業(yè)務(wù)中，首先要把問題定義清楚，這是模型應(yīng)用的關(guān)鍵，類似傳統(tǒng)研發(fā)中需求的產(chǎn)出，只有明確了需求和目標(biāo)，才能進行后續(xù)的研發(fā)和調(diào)試。同時，我們需要將業(yè)務(wù)問題翻譯為技術(shù)語言，用AI思路對問題進行轉(zhuǎn)換，也就是完成問題建模的過程。這個過程往往容易被忽略，但對后續(xù)研發(fā)十分重要（最簡單的：模型輸入什么？模型輸出什么？）

(2) 數(shù)據(jù)：數(shù)據(jù)是大模型的3大關(guān)鍵要素之一（算法，算力，數(shù)據(jù)），與任務(wù)對應(yīng)的數(shù)據(jù)是模型的主要輸入，是模型訓(xùn)練和調(diào)試的主要依據(jù)，應(yīng)盡可能覆蓋任務(wù)的假設(shè)空間。數(shù)據(jù)標(biāo)注任務(wù)是其中最苦難的環(huán)節(jié)，很多情況下，我們僅能找到數(shù)據(jù)的 “輸入” 部分，而無法得到數(shù)據(jù)的 “輸出”，此時就需要我們進行標(biāo)注，在今天的大模型時代，AI標(biāo)注成為了常用的解決方案，后文還會展開介紹。

(3) 模型：在前面的兩個步驟中，我們準(zhǔn)備好了模型的輸入，下面就需要根據(jù)這些輸入進行具體的模型調(diào)試，優(yōu)化模型在任務(wù)中的效果。這是模型研發(fā)過程的主要工作，可能會分為多個部分：

• 模型選型：首先我們需要依據(jù)任務(wù)類型，以及我們對應(yīng)用的要求，選擇合適的大模型進行調(diào)試。通常我們會進行一些輕量的實驗，輔助初步的選擇。
• Prompt工程：在選擇好模型后，我們就需要根據(jù)我們的任務(wù)對Prompt進行調(diào)試。隨著領(lǐng)域的不斷發(fā)展，Prompt工程已經(jīng)積累的大量技巧，也產(chǎn)生了一些方法框架，以及相應(yīng)的工具。理論上，如果模型能力足夠強大，我們僅僅通過 “Prompt工程” 即可完成效果的調(diào)試。
• 其他優(yōu)化技術(shù)：“Prompt + 模型” 已經(jīng)構(gòu)成了模型應(yīng)用的最小單元，但實際上，這往往并不能產(chǎn)生令人滿意的效果。因此，在這個基礎(chǔ)上，我們還需要增加一些額外的調(diào)試手段，例如：“RAG”，“訓(xùn)練”，“CoT” 等等，以此進一步提升模型的效果。
• Agent & MultiAgent：當(dāng)我們處理的問題更加復(fù)雜時，單純的模型語言能力無法滿足我們的訴求，我們需要賦予模型環(huán)境感知、自主理解、決策制定，執(zhí)行行動等能力，讓其處理更加復(fù)雜的任務(wù)。同時，我們的任務(wù)也可能包含多個推理階段，需要我們引入多個Agent的能力，通過系統(tǒng)級的模型調(diào)度來完成

模型的調(diào)試方法很多，且在不斷的更新迭代當(dāng)中，這里僅僅羅列其中最主要的一些方法。是否需要使用，以及如何使用，往往需要結(jié)合任務(wù)的具體情況以及模型現(xiàn)狀來進行判斷，這往往依賴模型研發(fā)人員的經(jīng)驗，也是模型研發(fā)過程中專業(yè)壁壘最高的部分。

(4) 效果評測：在我們調(diào)試模型的過程中，以及初步完成模型調(diào)試后，我們都需要對模型的效果進行評測。通常的方法就是應(yīng)用模型在我們實現(xiàn)準(zhǔn)備的數(shù)據(jù)上盡性推理，并計算模型推理結(jié)果和實際結(jié)果的差異。對于不同的任務(wù)會應(yīng)用不同的評估指標(biāo)，但總體來看，均是度量兩者間的相似度。比起量化的指標(biāo)結(jié)果，模型在評測過程中出現(xiàn)的問題更加重要，針對badcase的分析，是模型進一步提升效果的關(guān)鍵。

(5) 持續(xù)優(yōu)化調(diào)試：模型調(diào)試不是一個一蹴而就的單向過程，在領(lǐng)域持續(xù)發(fā)展的今天，即便基礎(chǔ)模型都會持續(xù)更新，其中的若干優(yōu)化方法更是在不斷的迭代當(dāng)中。即便是模型上線應(yīng)用以后，分析badcase并不斷提升模型效果，也是一個持續(xù)不斷的過程。

(6) 部署&運維：當(dāng)模型效果達(dá)到應(yīng)用標(biāo)準(zhǔn)后，我們就需要進行模型的部署，將其融入到我們的應(yīng)用場景當(dāng)中。無論是通過接口，定時任務(wù)，還是通過定制的工程開發(fā)，我們需要讓模型能力盡可能的貼合我們的應(yīng)用場景，讓模型在應(yīng)用中產(chǎn)生效果。

在過去1年多的時間里，我們一直在業(yè)務(wù)中探索大模型和質(zhì)效領(lǐng)域的結(jié)合，嘗試應(yīng)用大模型能力解決業(yè)務(wù)的質(zhì)效問題，完成了多項能力研發(fā)，并在業(yè)務(wù)落地，下面用一個實際例子，更直觀的解釋模型研發(fā)的過程。

在業(yè)務(wù)質(zhì)效能力的建設(shè)中，“用例檢查” 任務(wù)通過大模型能力的引入，發(fā)現(xiàn)“測試用例”中存在的問題，輔助“測試用例”質(zhì)量提升，緩解業(yè)務(wù)因用例導(dǎo)致的漏測問題。在 “用例檢查” 要發(fā)現(xiàn)的具體問題上，“二義性” 問題是其中最典型的問題之一，也是目前應(yīng)用最廣成效最多的能力之一。我們希望引入大模型能力，對用例進行檢查，發(fā)現(xiàn) “測試用例” 中存在的二義性問題：

建模：

a. 問題定義：對用例中存在的 “二義性” 問題進行分析，并對其引起的漏側(cè)問題進行分析，找到其中的典型案例，確定 “二義性” 定義，補充必要的業(yè)務(wù)知識和專業(yè)知識。

b. 問題建模：用技術(shù)語言對問題進行描述，檢查問題實際是一個 “分類任務(wù)” ，我們需要根據(jù)用例的“標(biāo)題”，“步驟”，“預(yù)期結(jié)果”對用例進行分類，將用例分為2類：“存在二義性問題” 和 “不存在二義性問題”。

數(shù)據(jù)：

a. 原始數(shù)據(jù)采集：我們的數(shù)據(jù)輸入就是用例內(nèi)容，目前業(yè)務(wù)有近20w+的用例數(shù)據(jù)，數(shù)據(jù)儲備充足

b. 數(shù)據(jù)清洗/計算：任務(wù)聚焦在對用例內(nèi)容的檢查，因此無需做過多的計算，僅需對數(shù)據(jù)格式進行統(tǒng)一，并篩選出適合用于模型調(diào)試的數(shù)據(jù)即可。

c. 數(shù)據(jù)標(biāo)注：雖然業(yè)務(wù)的用例儲備充足，但由于過往沒有經(jīng)歷系統(tǒng)化的檢查，因此沒有充足的標(biāo)注信息。因此我們引入了 AI 標(biāo)注的手段，應(yīng)用 GPT4 對用例進行了粗標(biāo)，并人工進行確認(rèn)，獲得了 500條 左右的標(biāo)注數(shù)據(jù)

模型：

a. 模型選型：由于任務(wù)的敏感性和成本的要求，我們無法直接使用閉源的外部模型，而是選擇了在公司內(nèi)部私有部署的 qpilot-chat（底層是ChatGLM，由Qpilot團隊微調(diào)得到）。

b. Prompt工程：結(jié)合我們的任務(wù)定義和數(shù)據(jù)，我們進行了多輪的 Prompt調(diào)試 工作，在“定義”，“任務(wù)描述”，“要求”，“限制條件” 等多個方面對進行了多次的優(yōu)化，產(chǎn)出了多版 Prompt，反復(fù)提升模型效果。

c. RAG：測試用例不僅與領(lǐng)域?qū)I(yè)結(jié)合緊密，與業(yè)務(wù)知識也有很大的關(guān)聯(lián)，因此我們引入RAG技術(shù)，結(jié)合知識庫，對 “業(yè)務(wù)專用詞”，”領(lǐng)域?qū)Ｓ迷~“ 進行解釋，提升能力的應(yīng)用效果以及在各個業(yè)務(wù)的適應(yīng)度。

d. CoT&穩(wěn)定性提升：為了提升能力的穩(wěn)定性，引入了CoT模塊，拆分思維鏈，并增加“反思”等機制，緩解小模型的幻覺問題，提升能力的穩(wěn)定性。

e. 格式限制&條件限制：抽象模型的各類“限制模塊”，作為單獨的推理環(huán)節(jié)，結(jié)合模型調(diào)度能力，在任務(wù)推理的各個環(huán)節(jié)提升模型的可控性和穩(wěn)定性。

f. Agent & MultiAgent：對整體系統(tǒng)而言，我們?yōu)槟Ｐ驮黾印坝洃浾{(diào)度”，“插件調(diào)度”，“條件限制” 等多項能力，尤其是在格式限制和條件限制方面，抽象模型的各類“限制模塊”，作為單獨的推理環(huán)節(jié)，結(jié)合模型調(diào)度能力，在任務(wù)推理的各個環(huán)節(jié)提升模型的可控性和穩(wěn)定性。

效果評測：在模型調(diào)試過程中，我們進行了多次的模型效果評測，計算模型在數(shù)據(jù)集上的“準(zhǔn)確率”，“精確率”，“召回率”等指標(biāo)。并持續(xù)對badcase進行分析，指導(dǎo)模型的優(yōu)化方向。

部署&運維：為了讓模型能力更好的在業(yè)務(wù)中落地，我們提供了多種應(yīng)用方式：api接口，定時檢查任務(wù)，以及我們結(jié)合業(yè)務(wù)的實際應(yīng)用場景，進行了專項的工程化開發(fā)，研發(fā)智能用例平臺，承載用例的檢查和問題的修復(fù)。同時我們?yōu)榱俗寵z查問題得到更好的閉環(huán)解決，我們將檢查問題和Tapd打通，并制作質(zhì)量看板對數(shù)據(jù)進行分析，通過推送等方式進行業(yè)務(wù)觸達(dá)，切實推動問題閉環(huán)解決。

3. 我們要做什么

前文中，我們結(jié)合示例敘述了模型應(yīng)用的研發(fā)流程，我們希望引入大模型能力，為用戶承擔(dān)這個流程中的部分工作，以此提升模型研發(fā)的效率，降低模型研發(fā)的成本和技術(shù)壁壘，讓人人都可以完成模型能力的應(yīng)用。因此，我們需要進一步分析，具體要在哪些環(huán)節(jié)提供幫助。下圖用3中顏色進行了標(biāo)識，分別表示研發(fā)流程中需要用戶負(fù)責(zé)的，系統(tǒng)負(fù)責(zé)的，以及共同負(fù)責(zé)的部分。

建模：

a. 問題定義：問題定義是與具體任務(wù)最為相關(guān)的部分，用戶需要明確希望大模型為自己做什么，并進行清晰的定義，此步重點在用戶需求的定義，由用戶獨立負(fù)責(zé)。

b. 問題建模：把問題定義轉(zhuǎn)換為技術(shù)語言，對于非技術(shù)人員并不簡單，但由于是模型研發(fā)的基礎(chǔ)輸入，且依然屬于用戶需求的范疇，知識表現(xiàn)形式有所差異，因此也需要用戶獨立負(fù)責(zé)。工具會根據(jù)任務(wù)類型，通過清晰的模版定義幫助用戶，但內(nèi)容的編寫還是由用戶完成。

數(shù)據(jù)：

a. 原始數(shù)據(jù)采集：除了問題的建模，用戶還需要提供一定量級的輸入數(shù)據(jù)，此處指的是原始數(shù)據(jù)，并不包含標(biāo)注信息，因此僅與任務(wù)內(nèi)容相關(guān)，需要用戶獨立負(fù)責(zé)。工具會以插件的形式提供一定的數(shù)據(jù)獲取能力，例如從Tapd，騰訊文檔讀取數(shù)據(jù)。

b. 數(shù)據(jù)清洗/計算：我們可能還需要在原始數(shù)據(jù)的基礎(chǔ)上進行一定的清洗/計算，但并非必要環(huán)節(jié)，工具會提供一定的能力支持，如：格式解析，格式整理，但主體由用戶獨立負(fù)責(zé)。

c. 數(shù)據(jù)標(biāo)注：標(biāo)注是數(shù)據(jù)準(zhǔn)備階段最困難的工作，我們往往僅能批量獲取任務(wù)輸入部分的數(shù)據(jù)，而無法獲取任務(wù)的輸出部分，若依賴人工標(biāo)注則往往會產(chǎn)生較高的成本。工具會提供一定的AI標(biāo)注能力，事前應(yīng)用能力較強的閉源模型（混元，GPT4）對數(shù)據(jù)進行粗標(biāo)，再結(jié)合人工確認(rèn)，低成本的和用戶共同完成數(shù)據(jù)標(biāo)注工作

模型：

模型階段的所有工作都可以由系統(tǒng)自動處理，但為了提升用戶的定制化程度，在某些環(huán)節(jié)用戶可以進行一定程度的干預(yù)：

a. 模型選型：工具會結(jié)合業(yè)務(wù)的實際情況（數(shù)據(jù)類型，復(fù)雜程度，成本）推薦合適的模型，用戶也可以手動選擇進行更改

b. Prompt工程：工具具備強大的Prompt編寫和優(yōu)化能力，可以根據(jù)用戶的前序輸入自動進行Prompt的生成。

c. 其他模型調(diào)試技術(shù)：“基礎(chǔ)模型 + Prompt” 已經(jīng)構(gòu)成了模型應(yīng)用的最小單元，但我們往往為了達(dá)到更好的效果，需要引入更多的技術(shù)模塊進行優(yōu)化。工具會結(jié)合任務(wù)的實際情況，進行技術(shù)的選取和使用，自動完成效果的優(yōu)化工作。

效果評測：在完成一次模型調(diào)試后，模型就會對事前提供的數(shù)據(jù)進行推理，產(chǎn)出每條數(shù)據(jù)的推理結(jié)果，并結(jié)合具體的任務(wù)類型，產(chǎn)出評測指標(biāo)，如：準(zhǔn)確率，精確率，召回率，F(xiàn)1-score 等。

持續(xù)優(yōu)化調(diào)試：

理根據(jù)評測的實際結(jié)果，我們需要對模型的效果進行持續(xù)的優(yōu)化迭代，在工具的幫助下，這是一個半自動化的過程：

a. 數(shù)據(jù)驅(qū)動的自動優(yōu)化：工具會對評測數(shù)據(jù)中的badcase進行分析，并基于分析結(jié)果，調(diào)用模型調(diào)試環(huán)節(jié)中的各個模塊，對模型效果進行優(yōu)化（Prompt優(yōu)化，RAG，reflection，等等）

b. 人為驅(qū)動的半自動優(yōu)化：對于評測結(jié)果中的共性問題，可以人為進行分析和抽象，形成對應(yīng)的限制目標(biāo)，如：“輸出格式需滿足 xxx ”，“過濾輸入中的url”，“xxx 情況不屬于類別 A ”，等等。通過自然語言對優(yōu)化目標(biāo)進行描述，工具即可完成相應(yīng)的優(yōu)化。

部署&運維：

為了讓研發(fā)的模型能力得到實際應(yīng)用，我們提供了多種應(yīng)用方式，希望可以盡量貼近模型的應(yīng)用場景。最基礎(chǔ)的，我們對所有能力均提供：

a. API接口：提供統(tǒng)一的API接口能力，方便在各種場景中即成。

b. 定時任務(wù)：僅需要簡單的腳本編寫，即可部署定時任務(wù)，定期批量對模型能力進行應(yīng)用。

同時，我們還在探索各種其他的能力集成方式，如：

c. 智能用例平臺：對于質(zhì)效域能力，尤其是測試用例的相關(guān)的能力，我們已經(jīng)自主研發(fā)了智能用例平臺作為承載，用戶可以將各項子能力一鍵在平臺中完成上線。

d. 聊天驅(qū)動的agent能力：通過 "聊天機器人" 的方式對能力進行部署，用戶可以通過聊天對搭建的能力進行調(diào)用。

e. Tapd + 看板：用戶可以將模型輸出的結(jié)果直接連通至Tapd，并結(jié)合數(shù)據(jù)看板進行結(jié)果的查看和處理。

4. 總結(jié)

前文中已經(jīng)詳細(xì)闡述了，為了達(dá)到目標(biāo)，我們希望在模型研發(fā)流程中提供哪些幫助。實際上，我們自身就是一個 “MultiAgent” 系統(tǒng)，讓用戶只需要 “明確需求”，“提供數(shù)據(jù)” 就可以無代碼的完成模型應(yīng)用的研發(fā)。并通過這種方式，不斷積累領(lǐng)域能力，推進模型應(yīng)用在領(lǐng)域中的發(fā)展，建立類似開源的研發(fā)環(huán)境，真正實現(xiàn)模型能力的領(lǐng)域化。

四、構(gòu)建模型能力的Agent系統(tǒng)

前文中介紹了，我們希望達(dá)成的目標(biāo)，以及我們具體要做的事。下面我就針對工具的幾個關(guān)鍵模塊，從技術(shù)角度，簡單闡述我們是如何做到的。

1. 建模

建模部分是模型調(diào)試階段最重要的信息輸入，相當(dāng)于功能的需求文檔，只有將需求定義清洗，才能保證模型的效果符合預(yù)期。與前文中介紹的一致，建模由2個環(huán)節(jié)組成：問題定義，問題建模。

對問題定義而言，用戶可以根據(jù)業(yè)務(wù)應(yīng)用的視角進行任意問題的定義，但對問題建模而言就需要增加一定的限制。兩者在內(nèi)容上并無差異，但在視角上有所差別。首先是要區(qū)分任務(wù)的類型，將任務(wù)首先映射到對應(yīng)到常見的AI任務(wù)類型上，如：

• 基礎(chǔ)任務(wù)類型：分類，聚類，生成，回歸
• 綜合任務(wù)類型：信息抽取，文本總結(jié)，問答，關(guān)鍵詞抽取

這其中的每種任務(wù)類型，都可以在應(yīng)用層演化出多種任務(wù)，例如前文中提到的 “用例檢查”，就是 “分類” 任務(wù)的一種。而每種任務(wù)類型內(nèi)，是有共性存在的，這也就在一定程度上，構(gòu)成工具可以成立的底層基礎(chǔ)。工具對每種任務(wù)類型的共性部分進行封裝，每種任務(wù)類型對應(yīng)相應(yīng)的研發(fā)流程，通過這種封裝和復(fù)用，降低應(yīng)用任務(wù)的研發(fā)成本。例如：所有分類任務(wù)在 Prompt 上有共性的成分，可以應(yīng)用相似的Prompt結(jié)構(gòu)。

由于這個階段十分重要，為了確保建模的過程可以提供足夠的信息，工具為每種任務(wù)類型定義了相應(yīng)的模版，輔助用戶完成問題的建模，例如分類的模版如下：

用戶需要根據(jù)任務(wù)的實際情況，確定任務(wù)類型，并填寫相應(yīng)的模版，完成對任務(wù)的建模。在模版的填寫上，由于此處是用戶唯一的輸入方式，目前沒有引入任何的智能填寫手段，可能會涉及多處的描述和定義，也是后期調(diào)試模型需要重點修改優(yōu)化的地方，是影響模型效果的重要因素之一。此處內(nèi)容的具體填寫標(biāo)準(zhǔn)與任務(wù)復(fù)雜程度和模型能力均有關(guān)系，無法產(chǎn)出統(tǒng)一的標(biāo)準(zhǔn)，考慮到可能存在的不確定性和填寫的成本，用戶可以通過先簡單填寫，再在后續(xù)調(diào)試過程中逐步優(yōu)化的方式完成填寫工作。

2. 數(shù)據(jù)

數(shù)據(jù)也是任務(wù)的關(guān)鍵輸入之一，在后續(xù)的多個調(diào)試，訓(xùn)練，評測步驟中均會得到應(yīng)用。由于數(shù)據(jù)與任務(wù)定義強相關(guān)的特性，數(shù)據(jù)準(zhǔn)備工作也需要用戶完成。工具中的所有對象均以任務(wù)維度進行管理，用戶在模型調(diào)試前，需要上傳任務(wù)對應(yīng)的數(shù)據(jù)集，以完成準(zhǔn)備工作。

工具對數(shù)據(jù)并沒有過多的要求，每種任務(wù)類型會有相應(yīng)的數(shù)據(jù)格式要求。但總體上看，數(shù)據(jù)集僅需簡單的包含模型的 “輸入-輸出” 即可。同時，盡量保證對任務(wù)假設(shè)空間的覆蓋，以保證更好的效果。

此處還會涉及數(shù)據(jù)標(biāo)注的工作，通常會造成較高的人力成本。工具支持使用大型模型對數(shù)據(jù)進行標(biāo)注，并應(yīng)用這些數(shù)據(jù)訓(xùn)練小模型，這種方式已經(jīng)逐漸成為了共識的做法，其有效性也在有多篇論文中得到了論證。其中最有代表性的：

• S3框架：通過使用大型語言模型來縮小小型模型在合成數(shù)據(jù)集和真實任務(wù)數(shù)據(jù)分布之間的差距。實驗結(jié)果表明，S3框架在多個自然語言處理（NLP）任務(wù)上均取得了顯著的性能提升，相較于其他基線方法，如ZeroGen和GoldGen，S3能夠顯著提高小型模型的性能：相比ZeroGen提高了9.48%，相比GoldGen提高了2.73%，且最多能比基于人工標(biāo)注的數(shù)據(jù)訓(xùn)練的小型模型提高15.17%。
• FreeAL框架：該框架通過大模型時代的主動學(xué)習(xí)技術(shù)實現(xiàn)大小模型協(xié)同工作，達(dá)到Human-Free的數(shù)據(jù)標(biāo)注。在協(xié)同訓(xùn)練期間，LLM作為主動標(biāo)注者灌輸其粗粒度知識，而下游SLM則作為學(xué)生過濾出高質(zhì)量的上下文樣本，以反饋LLM以供后續(xù)標(biāo)簽精煉。對八個基準(zhǔn)數(shù)據(jù)集的大量實驗表明，F(xiàn)reeAL在沒有任何人工監(jiān)督的情況下極大地增強了SLM和LLM的零樣本性能

我們也在工具中集成了這種AI標(biāo)注的能力，即應(yīng)用大型模型（混元，GPT4）幫助用戶進行粗標(biāo)，再由人工確認(rèn)后，完成標(biāo)注工作。

3. 模型

模型效果調(diào)試是模型研發(fā)流程中成本最大，技術(shù)壁壘最高的階段，也是工具最主要的價值。理論上，用戶只需完成“建模”和“數(shù)據(jù)”的相關(guān)工作，工具就可以自主完成模型應(yīng)用的研發(fā)，并通過多個模塊的方法保證應(yīng)用的效果。下面我就具體介紹一下，其中幾個重要模塊的實現(xiàn)方法。

(1) MultiAgent System

相對于大語言模型，智能體（Agent）是一個更廣泛的概念，是一個能夠獨立做出決策并實際執(zhí)行任務(wù)的實體，而大語言模型僅僅是一種通過分析大量的文本數(shù)據(jù)來學(xué)習(xí)語言模式和結(jié)構(gòu)，從而能夠執(zhí)行文本任務(wù)的模型。大語言模型自身不具備執(zhí)行任務(wù)的能力，卻可以很好為智能體做出決策，并驅(qū)動智能體完成交互任務(wù)。顯然，在大多數(shù)任務(wù)中，我們僅僅擁有語言模型是遠(yuǎn)遠(yuǎn)不夠的，對我們的工具而言也是如此，我們需要智能體幫助我們完成一個個任務(wù)的執(zhí)行。

對于由多個智能體組成的系統(tǒng)，我們可以稱為 “多智能體系統(tǒng)”（MultiAgent System），在這些系統(tǒng)中，多個智能體可以協(xié)同工作以完成復(fù)雜的任務(wù)。這項技術(shù)自2023年底至今，持續(xù)獲得了學(xué)術(shù)界和產(chǎn)業(yè)界的關(guān)注，誕生了大量的研究，比如：

• MetaGPT：一種新穎的元編程框架，將高效的人工工作流融入到基于LLM的多智能體協(xié)作中。其將復(fù)雜的開發(fā)任務(wù)分解為分配給不同角色的特定可操作過程（例如Product Manager, Architect, Engineer等等）。
• AutoGen：通過Multi-agent框架設(shè)置各類完成各種復(fù)雜任務(wù)，如論文中列舉的：解數(shù)學(xué)題，檢索增強問答，代碼生成，國際象棋，等等。

我們的工具也是一個 “多智能體系統(tǒng)”，通過多個“智能體”的協(xié)作，完成模型應(yīng)用的開發(fā)。同時產(chǎn)出的每項模型能力也都是基于多智能體的系統(tǒng)，幫助用戶在各種復(fù)雜場景中完成任務(wù)。

上圖展示了系統(tǒng)的大致結(jié)構(gòu)，整體分為6個Agent模塊，每個模塊包含多項模型能力，覆蓋從模型能力研發(fā)到優(yōu)化迭代的完整研發(fā)過程

• 綜合調(diào)度Agent：系統(tǒng)的決策中心，負(fù)責(zé)對輸入進行理解并對任務(wù)進行分析和拆解，制定執(zhí)行計劃，并調(diào)度各個模塊。
• Prompt Agent：負(fù)責(zé) Prompt 的編寫和管理工作，結(jié)合Prompt框架完成編寫，并結(jié)合效果不斷優(yōu)化。
• 模型訓(xùn)練Agent：負(fù)責(zé)模型的訓(xùn)練，調(diào)度各類模型訓(xùn)練腳本，處理訓(xùn)練數(shù)據(jù)集，串聯(lián)模型訓(xùn)練流程，完成模型訓(xùn)練。
• 能力調(diào)度Agent：負(fù)責(zé)根據(jù)實際情況調(diào)度各種能力優(yōu)化模型效果，如：RaG，CoT Reflection 等，每種子能力也作為執(zhí)行Agent，且支持橫向擴展
• 插件調(diào)度Agent：負(fù)責(zé)在各個環(huán)節(jié)調(diào)用外部插件，如：數(shù)據(jù)獲取，格式轉(zhuǎn)換。插件獨立于模型研發(fā)過程，為系統(tǒng)提供額外的能力加持。
• 意見理解Agent：負(fù)責(zé)理解評測結(jié)果，根據(jù)BadCase和認(rèn)為修改意見給出修改建議，提供給綜合調(diào)度Agent，進行持續(xù)的優(yōu)化迭代。

為了讓 Agent 模塊內(nèi)部以及多個 Agent 之間可以高效協(xié)作，我們采用了4層的職責(zé)劃分框架，也在底層構(gòu)成了 Agent 的統(tǒng)一結(jié)構(gòu)。如上圖所示，我們將Agent職責(zé)劃分為了：Decison（決策），Plan（規(guī)劃），Action（執(zhí)行），Result（結(jié)果）。

• Decision 決策：負(fù)責(zé)分析當(dāng)前任務(wù)，理解輸入和上下文，覺定要應(yīng)用的系統(tǒng)能力，以及各項能力的具體應(yīng)用方式。
• Plan 規(guī)劃：負(fù)責(zé)規(guī)劃能力的具體實施方式，規(guī)劃工作流程，并指導(dǎo)執(zhí)行層有序開展工作。
• Action 執(zhí)行：負(fù)責(zé)具體任務(wù)的實施，完成每個原子單元的任務(wù)，并串聯(lián)各個模塊的工作，產(chǎn)生最終的執(zhí)行結(jié)果。
• Result 結(jié)果：負(fù)責(zé)匯集執(zhí)行層的結(jié)果并反饋至決策層，作為決策層下一步工作的主要輸入。

為了幫助大家更直觀的理解各個層級的實際作用，我們在上圖中以 “Prompt 編寫” 環(huán)節(jié)為例，展示了各個環(huán)節(jié)的工作。這個框架構(gòu)成了Agent的最小工作單元，不僅是單一模塊的工作，對于多個Agent的組成的復(fù)雜系統(tǒng)，也同樣是由這樣的結(jié)構(gòu)組成的。

以上，我們描繪了系統(tǒng)的整體框架，下面為了讓大家更好的了解系統(tǒng)的運作方式，對其中的幾個關(guān)鍵的 Agent 模塊進行進一步介紹。

(2)Prompt Agent

Prompt Agent 負(fù)責(zé) Prompt 的編寫工作，是模型調(diào)試環(huán)節(jié)最重要的模塊之一，對模型效果起到了很關(guān)鍵的作用。自探索大模型應(yīng)用以來，就在Prompt工程上進行了若干探索，結(jié)合應(yīng)用經(jīng)驗，構(gòu)建了Prompt框架。把一個Prompt拆分成了 “立角色 + 述問題 + 定目標(biāo) + 補要求” 這四個部分，并在其之上引入了統(tǒng)一的研發(fā)流程，實現(xiàn)了Prompt編寫的框架化。

我們基于這套統(tǒng)一的的研發(fā)流程，建立了Prompt Agent，可以根據(jù)用戶需求自動完成 Prompt 的編寫。包含Prompt模版中各個部分的編寫和整體Prompt的優(yōu)化重寫，在內(nèi)容和格式上均對Prompt提供質(zhì)量保障。

要說明的是，Prompt 是模型效果提升的一種方式，即：通過影響模型的輸入，讓模型獲得更好的應(yīng)用效果，而并非僅僅是一段“文本”。我們前文中所有的描述都是以 “任務(wù)” 維度進行的，而一個 “任務(wù)” 可能不止包含一次模型推理，可能由多次模型推理構(gòu)成，而每次模型推理都有對應(yīng)的輸入，也就對應(yīng)著各自推理階段的 Prompt。因此，Prompt的數(shù)量應(yīng)該與模型推理的次數(shù)一致，而并非一個任務(wù)只包含一個。

任務(wù)的拆分則與 “CoT” 技術(shù)相關(guān)，與傳統(tǒng)的直接輸入到輸出的映射不同，CoT通過將任務(wù)拆分為多個環(huán)節(jié)提升模型的效果，即：輸入 ——>思維鏈——> 輸出。這種方式是目前證實，提升模型推理能力最有效的手段之一，GPT-o1 就是通過強化學(xué)習(xí)與CoT的結(jié)合實現(xiàn)了模型在推理能力上的巨大提升。而這一過程可能是隱含與模型單次推理內(nèi)的，也可能是顯性表現(xiàn)在多次模型推理的編排上的。

我們應(yīng)用這種思想，首先對任務(wù)的思維鏈進行拆分，將任務(wù)拆分為多個推理環(huán)節(jié)，并針對各個推理環(huán)節(jié)生成prompt，以此提升模型在任務(wù)中整體的應(yīng)用效果，同時提升模型的穩(wěn)定性和可控性。

為了不造成額外的成本，并保證工具在任務(wù)上的通用性，任務(wù)拆分同樣會由Agent完成，不需要用戶額外介入。在Agent將任務(wù)拆分為多個階段后會完成各個階段的Prompt編寫，最終產(chǎn)生任務(wù)的整體Prompt及調(diào)度流程。

(3) 能力調(diào)度 Agent

除Prompt的編寫外，對模型效果影響最大的就是各種額外能力的引入了。這類能力在定位上，與模型自身的推理相獨立，但可以在模型推理的各個環(huán)節(jié)產(chǎn)生作用，其中最具代表性的就是 “RAG” 技術(shù)。

“RAG” 已經(jīng)從行業(yè)的發(fā)展趨勢，變成的行業(yè)的共識，通過對文檔的檢索和生成為大模型補充來自外部的相關(guān)數(shù)據(jù)與上下文，通過數(shù)據(jù)的方式引導(dǎo)大模型生成正確的回答，并彌補大模型知識的不足。類似這樣的技術(shù)還在不斷的發(fā)展當(dāng)中，且針對具體的業(yè)務(wù)場景，用戶可能需要用到更加定制的外部能力，因此我們對這一層進行了抽象，將各個能力作為 "子Agent" 作用于模型推理的各個階段，并通過調(diào)度Agent進行能力的調(diào)用，通過這種方式提升工具的可擴展性。

目前的能力調(diào)度主要作用于模型能力的3個階段

(1) 前處理階段：事前對用戶輸入的數(shù)據(jù)進行處理，以便讓大模型更好的理解，并在其之上完成推理，包含的能力類型有：

a. 數(shù)據(jù)解析：對于特別復(fù)雜的數(shù)據(jù)，或包含內(nèi)容較多的數(shù)據(jù)，需要事先對數(shù)據(jù)進行理解，如：需求文檔，多模態(tài)數(shù)據(jù)，大段長文本。通過文本理解，文本總結(jié)，關(guān)鍵詞理解 等方法，對數(shù)據(jù)進行分析，以便讓模型更好的理解。

b. 數(shù)據(jù)格式化：按照指定格式對數(shù)據(jù)進行整理，可以結(jié)合Prompt讓模型更有針對行的利用數(shù)據(jù)，提升模型效果

c. 異常數(shù)據(jù)檢查：事先發(fā)現(xiàn)異常的輸入數(shù)據(jù)，避免對模型造成誤導(dǎo)，提升模型的穩(wěn)定性

(2) 模型推理階段：影響模型的推理過程，以求獲得更好的推理效果，包含的能力類型有：

a. Prompt修改：在 prompt 中增加額外的補充信息，或修改 prompt 內(nèi)容，提升模型的效果。RAG 就是這類能力的典型代表，通過引入額外的知識數(shù)據(jù)或上下文數(shù)據(jù)，彌補模型在數(shù)據(jù)上的不足。

b. 要求限制：通過認(rèn)為的限制條件，提升模型效果的可控型，典型的黑/白名單，輸出字?jǐn)?shù)限制，就屬于這項能力的范疇。

(3) 后處理階段：對模型的輸出結(jié)果進行處理，在格式和內(nèi)容上貼合應(yīng)用的需求，并進一步提升輸出結(jié)果的穩(wěn)定性，包含的能力類型有：

a. 結(jié)果格式轉(zhuǎn)換：對輸出結(jié)構(gòu)的格式進行限制，例如轉(zhuǎn)換成規(guī)定的json格式，以便在業(yè)務(wù)場景中應(yīng)用。

b. 結(jié)果內(nèi)容轉(zhuǎn)換：模型輸出的內(nèi)容可能包含不需要的部分，或不直接包含我們預(yù)期的內(nèi)容，分類任務(wù)就是其中的典型場景，我們需要將模型輸出的內(nèi)容轉(zhuǎn)換為對應(yīng)的類別。

c. 結(jié)果校驗：為了提升模型輸出的準(zhǔn)確率，可以引入額外的測試/校驗邏輯，例如常用的反思機制，可以有效的提升模型輸出的穩(wěn)定性。

這其中的每項能力我們均當(dāng)作一個agent對待，在底層結(jié)構(gòu)上進行統(tǒng)一，由決策，規(guī)劃，執(zhí)行，結(jié)果組成（如前文中介紹），規(guī)范各項能力的開發(fā)方式和應(yīng)用方式，提升能力的可拓展性。在能力的應(yīng)用上，我們具備 “Agent自主調(diào)度” 的能力，也支持人為干預(yù)的方式，可以在各個環(huán)節(jié)內(nèi)調(diào)用對應(yīng)的能力。

用戶可以根據(jù)需求自己完成各個類型能力的定義，在某種程度上，每一個可服用的“模型應(yīng)用”都可以成為一個通用的外部能力，被應(yīng)用在其他的模型能力上，這些能力的增加也構(gòu)成了工具成長的潛力，也是我們后續(xù)要繼續(xù)探索的重點方向之一。

4. 調(diào)試 & 優(yōu)化

模型效果提升不是一個一蹴而就的單向工程，需要我們在實驗的應(yīng)用中不斷優(yōu)化提升，其依據(jù)大多來自：

• BadCase 數(shù)據(jù)：實驗和應(yīng)用數(shù)據(jù)是優(yōu)化最主要的輸入，尤其是其中的 BadCase，是模型效果提升的關(guān)鍵依據(jù)，通過對Bad Case 的分析和修復(fù)，不斷提升模型的應(yīng)用效果。
• 規(guī)則要求：除數(shù)據(jù)外，我們可能還會引入一些規(guī)則或要求，基于人為經(jīng)驗對模型效果進行分析，并進行干預(yù)，以此提升模型效果。
• 基礎(chǔ)能力升級：除任務(wù)維度的優(yōu)化外，模型系統(tǒng)基礎(chǔ)能力的提升也會影響模型的應(yīng)用效果，尤其是在領(lǐng)域快速發(fā)展的時期，底層模型或技術(shù)的迭代，可能會對應(yīng)用效果帶來質(zhì)的改變。

如前文所述，為了提升模型研發(fā)效率，降低模型研發(fā)成本，我們同樣采用Agent驅(qū)動的方式輔助完成調(diào)試優(yōu)化工作。

如上圖所示，調(diào)試模型效果的途徑有 2 種：

(1) Agent驅(qū)動的半自動方式：將自然語言和數(shù)據(jù)輸入給 Agent，Agent將進行分析和理解，形成修改意見傳遞至任務(wù)的“綜合調(diào)度Agent”，再傳遞至模型的各個環(huán)節(jié)進行修正，其輸入主要有2類：

a. BadCase 數(shù)據(jù)：在一輪模型研發(fā)完成后，系統(tǒng)會在數(shù)據(jù)集上進行評測，產(chǎn)出BadCase數(shù)據(jù)，BadCase 數(shù)據(jù)會作為模型調(diào)試的主要輸入，傳遞至下一輪迭代當(dāng)中。模型上線應(yīng)用后產(chǎn)生的數(shù)據(jù)同樣會進入這個自迭代的閉環(huán)當(dāng)中，用數(shù)據(jù)自驅(qū)動的方式完成模型優(yōu)化。

b. 人為規(guī)則要求：除數(shù)據(jù)自迭代外，用戶可以自行對模型效果進行分析，并依據(jù)經(jīng)驗對模型的要求或規(guī)則，為了提升這些要求對模型效果的可控性，我們依據(jù)要求類型提供了填寫模版（如：輸出格式類要求，特殊處理類要求，過濾類要求），并研發(fā)了單獨的模塊進行處理，以提升模型的可控性。這些要求和規(guī)則僅需通過自然語言描述即可。同時在規(guī)則的實現(xiàn)上，我們依舊沿用前文中提到的agent架構(gòu)，讓要求獨立可插拔，以此支持要求的拓展及上下線等操作。

(2) 修改輸入的人工方式：在本章的前幾節(jié)中，我們介紹了任務(wù)的主要輸入，包含建模部分的定義及任務(wù)相關(guān)的數(shù)據(jù)集，這些內(nèi)容由用戶負(fù)責(zé)，是用戶控制任務(wù)的主要途徑。同時，在 “能力調(diào)度” 模塊中，部分能力agent也需要用戶額外的輸入，例如與RAG能力相關(guān)的知識庫。在調(diào)試模型效果的過程中，用戶可以通過修改這些輸入來直接完成對模型的影響，可能包含：

a. 修改定義：定義會直接影響任務(wù)Prompt以及整體的推理流程，可以幫助模型理解任務(wù)，規(guī)范模型的行為，是非常重要的輸入之一。

b. 增加數(shù)據(jù)：數(shù)據(jù)是模型調(diào)試和訓(xùn)練的依據(jù)，結(jié)合模型現(xiàn)有的問題補充對應(yīng)的數(shù)據(jù)，是很有效的優(yōu)化手段。

c. 擴充知識庫：在外部能力調(diào)度中，RAG對模型效果起到了很大的影響，尤其是在專業(yè)領(lǐng)域內(nèi)應(yīng)用時，可以彌補模型專業(yè)知識不足，業(yè)務(wù)知識不足的問題，并可以進一步約束模型的輸出，根據(jù)任務(wù)補充相應(yīng)的知識庫可以很好的提升模型在任務(wù)上的應(yīng)用效果。

我們可以通過以上方法，盡量低成本的進行模型效果的調(diào)試，但即便我們引入了相應(yīng)的Agent能力和數(shù)據(jù)驅(qū)動的方法，這一步驟也十分依賴開發(fā)人員的經(jīng)驗和專業(yè)能力，如何幫助用戶更好的完成這一過程是我們還需長期摸索的話題。

五、最佳實踐

目前，我們的工具已經(jīng)完成了初版研發(fā)，并在實際工作中應(yīng)用落地。結(jié)合近1年多時間里我們在質(zhì)效領(lǐng)域的探索，我們應(yīng)用工具完成了多項模型能力的研發(fā)落地，在保證效果的前提下獲得了大幅的效率提升和成本降低，下面我詳細(xì)介紹一下我們目前的應(yīng)用成果。

1. 研發(fā)效率提升最佳實踐

(1) 效率低帶來的痛點

在過去一年多里，我們在業(yè)務(wù)中持續(xù)探索模型能力和質(zhì)效工作的結(jié)合，已完成了8項模型能力的研發(fā)落地，覆蓋了 “用例域”，“缺陷域”，“代碼域” 中的多個痛點場景。即便各項模型能力都在業(yè)務(wù)得到的應(yīng)用落地，并切實取得成效，我們距離業(yè)務(wù)的質(zhì)效訴求還是有較大差距。

業(yè)務(wù)質(zhì)效訴求貫穿產(chǎn)研的各個環(huán)節(jié)，需求量大，能力繁雜，業(yè)務(wù)分隔度高，僅 “用例域” 的單項任務(wù)就可能產(chǎn)生幾十個模型能力點。相比之下，目前 1 項模型能力從研發(fā)到落地就需要 “1人月” 的研發(fā)成本，造成了產(chǎn)能和需求的巨大差距。面對這種現(xiàn)狀，我們急需提升模型研發(fā)的效率，提升對業(yè)務(wù)需求的覆蓋度。

(2) 實踐成效

在大模型和 “缺陷域” 質(zhì)效問題結(jié)合的探索中，業(yè)務(wù)希望可以引入模型能力，對 “用戶反饋” 進行檢查，發(fā)現(xiàn) “用戶反饋” 中存在的嚴(yán)重問題，并進行特殊關(guān)注，確保嚴(yán)重問題的跟進解決。通常 “用戶反饋” 問題的嚴(yán)重程度由 2 方面判斷：“反饋量”，“反饋內(nèi)容”。反饋量可以很直觀的獲得，但反饋內(nèi)容的嚴(yán)重程度則依賴人為經(jīng)驗判斷，這就存在 “反饋量小，反饋內(nèi)容嚴(yán)重” 的問題被遺漏的風(fēng)險。

根據(jù)業(yè)務(wù)經(jīng)驗，在業(yè)務(wù)中，目前已確定了 “10+” 種需要監(jiān)控的嚴(yán)重問題，如：隱私相關(guān)問題，白屏相關(guān)問題，消息無法導(dǎo)入問題，聊天記錄損壞問題，等等。我們需要構(gòu)建模型能力，對這些檢查點進行覆蓋。

通過工具的引入，我們在 “2周” 內(nèi)就完成了 “2項” 模型能力的研發(fā)（“隱私相關(guān)問題”，“白屏相關(guān)問題”），并通過工具完成了能力的部署應(yīng)用，成功將模型能力從0到1的拓展到了“用戶反饋”相關(guān)的問題中。每 1 項模型能力的研發(fā)成本從 “1人月” 降低至 “1人周”，且準(zhǔn)確率均保持在 80% 以上，效率提升數(shù)倍。

(3) 效率提升詳情

通過工具的應(yīng)用，我們將本需要 “1人月” 完成的工作壓縮至了 “1人周”，這得益于工具對模型研發(fā)環(huán)節(jié)的框架化和工具化，具體表現(xiàn)在：

• 建?？蚣芑和ㄟ^前文中提到的 “建模” 模版，我們明確了定義任務(wù)所需要填寫的內(nèi)容，指導(dǎo)完成研發(fā)前的定義和數(shù)據(jù)準(zhǔn)備工作，通過明確目標(biāo)的工作流程提升這個階段的工作效率（由 “2天” 提升至 “1天”）
• 輔助數(shù)據(jù)標(biāo)注：系統(tǒng)具備借助強大閉源模型（混元，GPT）輔助數(shù)據(jù)標(biāo)注的能力，通過模型進行數(shù)據(jù)粗標(biāo)，再人工進行確認(rèn)，大幅提升了數(shù)標(biāo)注的效率（“2天” 提升至 “0.5天”）
• Prompt 編寫：通過對 Prompt 編寫環(huán)節(jié)的工具化，以及Agent能力的建設(shè)，我們無需人工進行編寫和反復(fù)調(diào)試，僅需輸入 “建模定義” 和 “數(shù)據(jù)” 即可應(yīng)用 Agent 完成prompt的編寫工作。（由 “3天” 提升至 “0.5天”）
• 能力調(diào)用：工具對多種能力進行了封裝，并通過Agent能力完成各項能力的自主調(diào)用，省去了能力開發(fā)和引入的成本。在本項任務(wù)中，工具引入了：RAG 知識庫，CoT，格式標(biāo)準(zhǔn)化，反思，專用詞解釋，等多項能力，并結(jié)合任務(wù)狀況進行調(diào)用，無需進行二次開發(fā)（由 “1周” 提升至 “1天”）
• 插件調(diào)用：除了模型能力外工具內(nèi)還封裝了一些插件，可在研發(fā)流程的各個階段進行調(diào)用。在本項任務(wù)中，只用了 “騰訊文檔讀寫插件”，“Tapd數(shù)據(jù)讀寫插件”，“數(shù)據(jù)格式轉(zhuǎn)換插件”，避免了二次開發(fā)的成本。（“1天” 提升至 “1小時”）
• 上線部署：工具提供模型能力的自動部署能力，可通過配置產(chǎn)生接口供用戶調(diào)用。此外我們還提供多種部署方式：如結(jié)合用戶提供的腳本完成定時任務(wù)的部署；在本項任務(wù)中，我們通過工具將能力部署為定時任務(wù)，定期對用戶反饋數(shù)據(jù)進行檢查。（由 “3天” 提升至 “1天”）
• 流程串聯(lián)：研發(fā)框架除提升各個單一模塊的效率外，還對模型研發(fā)的整體了流程進行了規(guī)范化和串聯(lián)，提升了研發(fā)過程的流程效率（由 “3天” 提升至 “1天”）
• 效果調(diào)試&優(yōu)化：系統(tǒng)支持多種調(diào)試方法，并引入了相應(yīng)的Agent能力和數(shù)據(jù)驅(qū)動的方法，半自動的輔助完成模型效果的調(diào)試。相較于傳統(tǒng)基于評測結(jié)果的人工調(diào)試方法，大幅提升了調(diào)試效率（由 “1周” 提升至 “2天”）

2. 研發(fā)成本下降最佳實踐

(1) 成本高帶來的痛點

在我們探索大模型和質(zhì)效工作的結(jié)合中，大多模型研發(fā)工作均有開發(fā)人員承擔(dān)，但質(zhì)效領(lǐng)域具備較高專業(yè)深度和廣度，且與業(yè)務(wù)關(guān)系緊密，具備很高的業(yè)務(wù)復(fù)雜度。模型開發(fā)人員在專業(yè)和業(yè)務(wù)上均存在不足，導(dǎo)致模型開發(fā)與領(lǐng)域人員的訴求存在差距，不僅增加了模型開發(fā)的成本，還降低了模型實現(xiàn)的效果。

如前文所述，大模型能力的領(lǐng)域化，不應(yīng)當(dāng)僅僅局限于能力的開發(fā)，而應(yīng)當(dāng)賦予領(lǐng)域?qū)I(yè)人員應(yīng)用模型的能力，是一個 “授之以漁” 的過程。為了更好進行模型能力的領(lǐng)域化，我們希望通過工具，讓領(lǐng)域內(nèi)的專業(yè)人員也可以完成模型能力的研發(fā)。

(2) 實踐成效

在大模型和 “用例域” 質(zhì)效問題結(jié)合的探索中，“用例檢查” 是其中應(yīng)用最廣效果最顯著的能力，通過對測試用例的檢查，發(fā)現(xiàn)測試用例中存在的問題，以此提升用例質(zhì)量，解決因用例原因?qū)е侣﹤?cè)引發(fā)的線上問題。目前，我們已經(jīng)完成了6個檢查點的建設(shè)，可以有效發(fā)現(xiàn)用例中存在的問題，并推動修復(fù)，切實保證已覆蓋的檢查點無相關(guān)線上問題。

但測試用例的檢查點眾多，且存在業(yè)務(wù)區(qū)分，結(jié)合 “用例checklist”業(yè)務(wù)已經(jīng)積累了200+個檢查點，若持續(xù)采用集中式的孵化模式，難以滿足業(yè)務(wù)訴求。因此，希望通過工具的引入，讓業(yè)務(wù)的質(zhì)量同學(xué)也可以完成檢查點的開發(fā)，共同在領(lǐng)域中建設(shè)模型能力。

通過工具的引入，我們與質(zhì)量同學(xué)合作，在 “2周” 內(nèi)就完成了 “2項” 用例檢查能力的研發(fā)（“殺進程用例缺失檢查”，“寫操作用例缺失檢查”）。在沒有模型開發(fā)人員介入的情況下，僅由 “質(zhì)量同學(xué)” 進行輸入，即完成了能力的研發(fā)，準(zhǔn)確率均在 80% 以上。

通過如上定義，及少量數(shù)據(jù) 即可完成模型能力的研發(fā)。在調(diào)試過程中，結(jié)合模型的評測結(jié)果，也可低成本的，通過 “修改定義” 和 “補充數(shù)據(jù)” 完成模型效果的提升。同時，我們還針對用例檢查的應(yīng)用場景，提供了更方便的部署方式，除提供 API 接口外，檢查能力可以一鍵上線至 “智能用例平臺”（用例檢查的應(yīng)用平臺），并可自動創(chuàng)建定時任務(wù)，定期對用例進行檢查。通過這種方式，我們?nèi)溌返慕档土四Ｐ湍芰Φ难邪l(fā)成本，在保證質(zhì)量的前提下，讓質(zhì)量人員也可以完成模型能力的研發(fā)。

(3) 成本降低詳情

如上圖中所示的模型研發(fā)流程，工具為用戶自助完成了大量的研發(fā)工作，用戶僅需完成任務(wù)維度的輸入，即可完成模型能力的研發(fā)，從而大幅降低了模型研發(fā)過程的成本和技術(shù)比例，其中：

用戶負(fù)責(zé)：

a. 問題定義：確定檢查點定義

b. 問題建模：將檢查任務(wù)翻譯為分類任務(wù)，并填寫對應(yīng)的建模模版

c. 原始數(shù)據(jù)采集：采集任務(wù)需要用到的 “測試用例” 數(shù)據(jù)

d. 數(shù)據(jù)清洗/計算：統(tǒng)一 “測試用例” 數(shù)據(jù)結(jié)構(gòu)，無需額外的清洗/計算

工具與用戶協(xié)同負(fù)責(zé)：

a. 數(shù)據(jù)標(biāo)注：應(yīng)用 “混元” 模型對數(shù)據(jù)進行粗標(biāo)，再有人工確認(rèn)，完成標(biāo)注工作

b. 調(diào)試&優(yōu)化：工具利用 badcase 數(shù)據(jù) 及 人為歸納的問題 自主對模型系統(tǒng)進行優(yōu)化，最終保證準(zhǔn)確率達(dá)到應(yīng)用標(biāo)準(zhǔn)（>80%）。

工具負(fù)責(zé)：

a. 模型調(diào)試：模型階段的所有工作均有工具負(fù)責(zé)，在保證效果的前提下調(diào)度工具中的多個Agent系統(tǒng)，完成模型能力建設(shè)

b. 效果評測：在數(shù)據(jù)集上自動產(chǎn)出評測結(jié)果，計算 準(zhǔn)確率，召回率，精確率 等指標(biāo)。

c. 部署運維：工具自動完成模型能力的上線，除提供 API 接口外，檢查能力可以一鍵上線至 “智能用例平臺”（用例檢查的應(yīng)用平臺），并可自動創(chuàng)建定時任務(wù)，定期對用例進行檢查。

六、寫在最后

1. 從 “Prompt框架” 到 “模型研發(fā)工具”

在一年多的模型應(yīng)用探索當(dāng)中，我們進行了多項模型能力的研發(fā)和應(yīng)用，期間持續(xù)對模型的應(yīng)用效果提升和研發(fā)流程進行研究和實踐。此前的很長時間里，我們都認(rèn)為 Prompt 是模型應(yīng)用的鑰匙，對模型的應(yīng)用效果起到?jīng)Q定性的作用，如何又快又好的完成Prompt，是模型應(yīng)用研發(fā)的關(guān)鍵。

但隨著領(lǐng)域的發(fā)展和研究的深入，我們越來越能感受到 Prompt 并不是模型的全部（雖然依然很重要），尤其是在 Agent，MultiAgent 技術(shù)持續(xù)發(fā)展的今天，Prompt在模型效果中所占的比重越來越小。就如本文開篇提到的，模型應(yīng)用相關(guān)的技術(shù)對模型應(yīng)用效果是否重要，但 “Prompt工程” 只是眾多應(yīng)用技術(shù)的其中之一。

于是，我們把目光放大到了整個 “模型研發(fā)流程” 當(dāng)中，而不僅僅關(guān)注某項單一的技術(shù)，模型研發(fā)的 “第一性” 就是 “提升應(yīng)用效果”，而非不斷的優(yōu)化單一環(huán)節(jié)的能力，通過對研發(fā)框架的優(yōu)化不斷提升模型的應(yīng)用效果，才是我們應(yīng)當(dāng)做的正確的事。

2. 總結(jié) & 后續(xù)規(guī)劃

目前，我們初步完成了工具的研發(fā)和應(yīng)用嘗試，希望可以通過工具帶來的效率提升和成本下降，進一步推動大模型的領(lǐng)域化。大模型被認(rèn)為是通往 AGI 的道路，但現(xiàn)存的模型開發(fā)模式不僅沒有像通用化發(fā)展，反而在近一步限制模型的通用性以求得其在領(lǐng)域中的穩(wěn)定性，這種偏閉源的開發(fā)模式，無論是在效果上，還是在效率上，都不符合大模型發(fā)展的趨勢。我們希望可以通過我們的工具，讓領(lǐng)域中的人都可以加入到模型能力的研發(fā)上，建立更開源的開發(fā)模式，讓領(lǐng)域中的人具備使用大模型的能力，才是真的領(lǐng)域化。

在技術(shù)上，本文開篇論述了一些對趨勢的觀察，這些曲線未必都正確，但模型應(yīng)用層技術(shù)的發(fā)展一定是領(lǐng)域中不可或缺的一部分，且對于模型的應(yīng)用效果而言，會起到越來越重要的作用。而目前，我們應(yīng)用層建設(shè)的成熟度還遠(yuǎn)遠(yuǎn)不夠，持續(xù)提升 “MultiAgent System” 的能力，不斷引入更多的模型能力，豐富應(yīng)用插件，并和用戶形成更好的協(xié)作模式，都是未來要努力的方向。

本文中敘述的觀點多有主觀判斷的成分，僅是個人結(jié)合應(yīng)用研發(fā)經(jīng)驗的若干想法，大模型相關(guān)技術(shù)還在持續(xù)的高速發(fā)展當(dāng)中，非常期待和大家交流。