作者 | rhino

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

一、寫在前面

1. 大模型應用是未來也是現在

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

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

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

• 發展期：AI Engineering，Model Ops，Prompt Engineering
• 萌芽期：Multiagent Systems，Decision Intelligence，AI-Ready Data，First-Principles AI，AGI

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

如果我們綜合觀察這些技術的現狀，不難得到一個結論：應用技術的落后成為了模型應用的關鍵阻礙。

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

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

2. 什么阻礙了模型應用？

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

模型應用的研發&部署：AI Engineering，Model Ops，Prompt Engineering

模型應用效果：

• 綜合行為能力：Agent，MultiAgent Systems
• 推理能力：Decision Intelligence，First-Principles AI
• 數據能力：AI-Ready Data

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

(1) 模型研發成本高昂

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

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

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

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

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

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

(2) 模型效果優化困難

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

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

當然，我們有一些技術手段來應對這些問題，例如：

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

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

3. 模型應用研發的痛點

痛點：模型效果難優化，成本高，技術挑戰大

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

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

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

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

二、讓人人都能開發大模型應用

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

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

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

模型研發人員無法掌握領域專業：質效領域的每個模塊都包含著大量的專業知識和專家經驗，結合復雜的業務知識，模型研發人員很難完全掌握，而這些領域往往又不具備大量的數據，在模型研發過程中就十分依賴研發者的專業能力，而這些復雜的專業能力又不是非領域人員可以輕松掌握的，這無論是對模型能力的研發效率還是應用效果都造成了極大的苦難。

無法與領域專家建立高效的協作模式：領域專家提供專業知識和指導是模型重要的輸入之一，但由于算法與領域均包含較高的專業壁壘，且模型研發流程不規范，導致很難建立高效的協作模型，領域專家的知識很難傳導至模型。

這些問題并不專屬“質效”領域，對于大多數模型應用的場景都存在類似的問題：領域專家無法應用模型，模型開發人員不了解領域知識。

因此，我們希望降低模型應用的研發成本，降低專業壁壘，提高模型的研發效率。讓領域內的人都能完成模型應用的研發，都能完成模型能力的應用。以此讓模型能力更好的在領域內落地，持續推進大模型的領域化。

目標：讓人人都能完成大模型應用

• 人人：對大模型(AI)不了解的人(領域專家)
• 完成：低成本的滿足自己的訴求，并達到穩定的效果
• 大模型應用：能在實際場景中落地，并產生應用效果

三、大模型研發框架

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

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

與現有模型研發工具的差異：

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

1. 從 “Prompt工程” 到 “模型研發框架”

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

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

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

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

關于 DSPy | AI工具中文文檔

產品：

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

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

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

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

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

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

2. 模型研發流程

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

結合我在模型應用研發上的探索，目前的模型應用研發工作可以大致分為如下幾個環節：

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

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

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

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

模型的調試方法很多，且在不斷的更新迭代當中，這里僅僅羅列其中最主要的一些方法。是否需要使用，以及如何使用，往往需要結合任務的具體情況以及模型現狀來進行判斷，這往往依賴模型研發人員的經驗，也是模型研發過程中專業壁壘最高的部分。

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

(5) 持續優化調試：模型調試不是一個一蹴而就的單向過程，在領域持續發展的今天，即便基礎模型都會持續更新，其中的若干優化方法更是在不斷的迭代當中。即便是模型上線應用以后，分析badcase并不斷提升模型效果，也是一個持續不斷的過程。

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

在過去1年多的時間里，我們一直在業務中探索大模型和質效領域的結合，嘗試應用大模型能力解決業務的質效問題，完成了多項能力研發，并在業務落地，下面用一個實際例子，更直觀的解釋模型研發的過程。

在業務質效能力的建設中，“用例檢查” 任務通過大模型能力的引入，發現“測試用例”中存在的問題，輔助“測試用例”質量提升，緩解業務因用例導致的漏測問題。在 “用例檢查” 要發現的具體問題上，“二義性” 問題是其中最典型的問題之一，也是目前應用最廣成效最多的能力之一。我們希望引入大模型能力，對用例進行檢查，發現 “測試用例” 中存在的二義性問題：

建模：

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

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

數據：

a. 原始數據采集：我們的數據輸入就是用例內容，目前業務有近20w+的用例數據，數據儲備充足

b. 數據清洗/計算：任務聚焦在對用例內容的檢查，因此無需做過多的計算，僅需對數據格式進行統一，并篩選出適合用于模型調試的數據即可。

c. 數據標注：雖然業務的用例儲備充足，但由于過往沒有經歷系統化的檢查，因此沒有充足的標注信息。因此我們引入了 AI 標注的手段，應用 GPT4 對用例進行了粗標，并人工進行確認，獲得了 500條 左右的標注數據

模型：

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

b. Prompt工程：結合我們的任務定義和數據，我們進行了多輪的 Prompt調試 工作，在“定義”，“任務描述”，“要求”，“限制條件” 等多個方面對進行了多次的優化，產出了多版 Prompt，反復提升模型效果。

c. RAG：測試用例不僅與領域專業結合緊密，與業務知識也有很大的關聯，因此我們引入RAG技術，結合知識庫，對 “業務專用詞”，”領域專用詞“ 進行解釋，提升能力的應用效果以及在各個業務的適應度。

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

e. 格式限制&條件限制：抽象模型的各類“限制模塊”，作為單獨的推理環節，結合模型調度能力，在任務推理的各個環節提升模型的可控性和穩定性。

f. Agent & MultiAgent：對整體系統而言，我們為模型增加“記憶調度”，“插件調度”，“條件限制” 等多項能力，尤其是在格式限制和條件限制方面，抽象模型的各類“限制模塊”，作為單獨的推理環節，結合模型調度能力，在任務推理的各個環節提升模型的可控性和穩定性。

效果評測：在模型調試過程中，我們進行了多次的模型效果評測，計算模型在數據集上的“準確率”，“精確率”，“召回率”等指標。并持續對badcase進行分析，指導模型的優化方向。

部署&運維：為了讓模型能力更好的在業務中落地，我們提供了多種應用方式：api接口，定時檢查任務，以及我們結合業務的實際應用場景，進行了專項的工程化開發，研發智能用例平臺，承載用例的檢查和問題的修復。同時我們為了讓檢查問題得到更好的閉環解決，我們將檢查問題和Tapd打通，并制作質量看板對數據進行分析，通過推送等方式進行業務觸達，切實推動問題閉環解決。

3. 我們要做什么

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

建模：

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

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

數據：

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

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

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

模型：

模型階段的所有工作都可以由系統自動處理，但為了提升用戶的定制化程度，在某些環節用戶可以進行一定程度的干預：

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

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

c. 其他模型調試技術：“基礎模型 + Prompt” 已經構成了模型應用的最小單元，但我們往往為了達到更好的效果，需要引入更多的技術模塊進行優化。工具會結合任務的實際情況，進行技術的選取和使用，自動完成效果的優化工作。

效果評測：在完成一次模型調試后，模型就會對事前提供的數據進行推理，產出每條數據的推理結果，并結合具體的任務類型，產出評測指標，如：準確率，精確率，召回率，F1-score 等。

持續優化調試：

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

a. 數據驅動的自動優化：工具會對評測數據中的badcase進行分析，并基于分析結果，調用模型調試環節中的各個模塊，對模型效果進行優化（Prompt優化，RAG，reflection，等等）

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

部署&運維：

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

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

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

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

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

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

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

4. 總結

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

四、構建模型能力的Agent系統

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

1. 建模

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

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

• 基礎任務類型：分類，聚類，生成，回歸
• 綜合任務類型：信息抽取，文本總結，問答，關鍵詞抽取

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

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

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

2. 數據

數據也是任務的關鍵輸入之一，在后續的多個調試，訓練，評測步驟中均會得到應用。由于數據與任務定義強相關的特性，數據準備工作也需要用戶完成。工具中的所有對象均以任務維度進行管理，用戶在模型調試前，需要上傳任務對應的數據集，以完成準備工作。

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

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

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

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

3. 模型

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

(1) MultiAgent System

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

對于由多個智能體組成的系統，我們可以稱為 “多智能體系統”（MultiAgent System），在這些系統中，多個智能體可以協同工作以完成復雜的任務。這項技術自2023年底至今，持續獲得了學術界和產業界的關注，誕生了大量的研究，比如：

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

我們的工具也是一個 “多智能體系統”，通過多個“智能體”的協作，完成模型應用的開發。同時產出的每項模型能力也都是基于多智能體的系統，幫助用戶在各種復雜場景中完成任務。

上圖展示了系統的大致結構，整體分為6個Agent模塊，每個模塊包含多項模型能力，覆蓋從模型能力研發到優化迭代的完整研發過程

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

為了讓 Agent 模塊內部以及多個 Agent 之間可以高效協作，我們采用了4層的職責劃分框架，也在底層構成了 Agent 的統一結構。如上圖所示，我們將Agent職責劃分為了：Decison（決策），Plan（規劃），Action（執行），Result（結果）。

• Decision 決策：負責分析當前任務，理解輸入和上下文，覺定要應用的系統能力，以及各項能力的具體應用方式。
• Plan 規劃：負責規劃能力的具體實施方式，規劃工作流程，并指導執行層有序開展工作。
• Action 執行：負責具體任務的實施，完成每個原子單元的任務，并串聯各個模塊的工作，產生最終的執行結果。
• Result 結果：負責匯集執行層的結果并反饋至決策層，作為決策層下一步工作的主要輸入。

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

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

(2)Prompt Agent

Prompt Agent 負責 Prompt 的編寫工作，是模型調試環節最重要的模塊之一，對模型效果起到了很關鍵的作用。自探索大模型應用以來，就在Prompt工程上進行了若干探索，結合應用經驗，構建了Prompt框架。把一個Prompt拆分成了 “立角色 + 述問題 + 定目標 + 補要求” 這四個部分，并在其之上引入了統一的研發流程，實現了Prompt編寫的框架化。

我們基于這套統一的的研發流程，建立了Prompt Agent，可以根據用戶需求自動完成 Prompt 的編寫。包含Prompt模版中各個部分的編寫和整體Prompt的優化重寫，在內容和格式上均對Prompt提供質量保障。

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

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

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

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

(3) 能力調度 Agent

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

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

目前的能力調度主要作用于模型能力的3個階段

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

a. 數據解析：對于特別復雜的數據，或包含內容較多的數據，需要事先對數據進行理解，如：需求文檔，多模態數據，大段長文本。通過文本理解，文本總結，關鍵詞理解 等方法，對數據進行分析，以便讓模型更好的理解。

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

c. 異常數據檢查：事先發現異常的輸入數據，避免對模型造成誤導，提升模型的穩定性

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

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

b. 要求限制：通過認為的限制條件，提升模型效果的可控型，典型的黑/白名單，輸出字數限制，就屬于這項能力的范疇。

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

a. 結果格式轉換：對輸出結構的格式進行限制，例如轉換成規定的json格式，以便在業務場景中應用。

b. 結果內容轉換：模型輸出的內容可能包含不需要的部分，或不直接包含我們預期的內容，分類任務就是其中的典型場景，我們需要將模型輸出的內容轉換為對應的類別。

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

這其中的每項能力我們均當作一個agent對待，在底層結構上進行統一，由決策，規劃，執行，結果組成（如前文中介紹），規范各項能力的開發方式和應用方式，提升能力的可拓展性。在能力的應用上，我們具備 “Agent自主調度” 的能力，也支持人為干預的方式，可以在各個環節內調用對應的能力。

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

4. 調試 & 優化

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

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

如前文所述，為了提升模型研發效率，降低模型研發成本，我們同樣采用Agent驅動的方式輔助完成調試優化工作。

如上圖所示，調試模型效果的途徑有 2 種：

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

a. BadCase 數據：在一輪模型研發完成后，系統會在數據集上進行評測，產出BadCase數據，BadCase 數據會作為模型調試的主要輸入，傳遞至下一輪迭代當中。模型上線應用后產生的數據同樣會進入這個自迭代的閉環當中，用數據自驅動的方式完成模型優化。

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

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

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

b. 增加數據：數據是模型調試和訓練的依據，結合模型現有的問題補充對應的數據，是很有效的優化手段。

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

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

五、最佳實踐

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

1. 研發效率提升最佳實踐

(1) 效率低帶來的痛點

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

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

(2) 實踐成效

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

根據業務經驗，在業務中，目前已確定了 “10+” 種需要監控的嚴重問題，如：隱私相關問題，白屏相關問題，消息無法導入問題，聊天記錄損壞問題，等等。我們需要構建模型能力，對這些檢查點進行覆蓋。

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

(3) 效率提升詳情

通過工具的應用，我們將本需要 “1人月” 完成的工作壓縮至了 “1人周”，這得益于工具對模型研發環節的框架化和工具化，具體表現在：

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

2. 研發成本下降最佳實踐

(1) 成本高帶來的痛點

在我們探索大模型和質效工作的結合中，大多模型研發工作均有開發人員承擔，但質效領域具備較高專業深度和廣度，且與業務關系緊密，具備很高的業務復雜度。模型開發人員在專業和業務上均存在不足，導致模型開發與領域人員的訴求存在差距，不僅增加了模型開發的成本，還降低了模型實現的效果。

如前文所述，大模型能力的領域化，不應當僅僅局限于能力的開發，而應當賦予領域專業人員應用模型的能力，是一個 “授之以漁” 的過程。為了更好進行模型能力的領域化，我們希望通過工具，讓領域內的專業人員也可以完成模型能力的研發。

(2) 實踐成效

在大模型和 “用例域” 質效問題結合的探索中，“用例檢查” 是其中應用最廣效果最顯著的能力，通過對測試用例的檢查，發現測試用例中存在的問題，以此提升用例質量，解決因用例原因導致漏側引發的線上問題。目前，我們已經完成了6個檢查點的建設，可以有效發現用例中存在的問題，并推動修復，切實保證已覆蓋的檢查點無相關線上問題。

但測試用例的檢查點眾多，且存在業務區分，結合 “用例checklist”業務已經積累了200+個檢查點，若持續采用集中式的孵化模式，難以滿足業務訴求。因此，希望通過工具的引入，讓業務的質量同學也可以完成檢查點的開發，共同在領域中建設模型能力。

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

通過如上定義，及少量數據 即可完成模型能力的研發。在調試過程中，結合模型的評測結果，也可低成本的，通過 “修改定義” 和 “補充數據” 完成模型效果的提升。同時，我們還針對用例檢查的應用場景，提供了更方便的部署方式，除提供 API 接口外，檢查能力可以一鍵上線至 “智能用例平臺”（用例檢查的應用平臺），并可自動創建定時任務，定期對用例進行檢查。通過這種方式，我們全鏈路的降低了模型能力的研發成本，在保證質量的前提下，讓質量人員也可以完成模型能力的研發。

(3) 成本降低詳情

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

用戶負責：

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

b. 問題建模：將檢查任務翻譯為分類任務，并填寫對應的建模模版

c. 原始數據采集：采集任務需要用到的 “測試用例” 數據

d. 數據清洗/計算：統一 “測試用例” 數據結構，無需額外的清洗/計算

工具與用戶協同負責：

a. 數據標注：應用 “混元” 模型對數據進行粗標，再有人工確認，完成標注工作

b. 調試&優化：工具利用 badcase 數據 及 人為歸納的問題 自主對模型系統進行優化，最終保證準確率達到應用標準（>80%）。

工具負責：

a. 模型調試：模型階段的所有工作均有工具負責，在保證效果的前提下調度工具中的多個Agent系統，完成模型能力建設

b. 效果評測：在數據集上自動產出評測結果，計算 準確率，召回率，精確率 等指標。

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

六、寫在最后

1. 從 “Prompt框架” 到 “模型研發工具”

在一年多的模型應用探索當中，我們進行了多項模型能力的研發和應用，期間持續對模型的應用效果提升和研發流程進行研究和實踐。此前的很長時間里，我們都認為 Prompt 是模型應用的鑰匙，對模型的應用效果起到決定性的作用，如何又快又好的完成Prompt，是模型應用研發的關鍵。

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

于是，我們把目光放大到了整個 “模型研發流程” 當中，而不僅僅關注某項單一的技術，模型研發的 “第一性” 就是 “提升應用效果”，而非不斷的優化單一環節的能力，通過對研發框架的優化不斷提升模型的應用效果，才是我們應當做的正確的事。

2. 總結 & 后續規劃

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

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

本文中敘述的觀點多有主觀判斷的成分，僅是個人結合應用研發經驗的若干想法，大模型相關技術還在持續的高速發展當中，非常期待和大家交流。