掌握API建模：基本概念和實踐
在不同的階段，我們有不同的關(guān)注點：
在此時，LLM 的工程化便是一個跨越不同領(lǐng)域的復(fù)雜數(shù)據(jù)工程活動。將這樣的工程標(biāo)準(zhǔn)化、跨不同部門協(xié)作、持續(xù)迭代下去，則會是我們未來的新挑戰(zhàn)。
以 API 為例，我們將上述的三個階段分解為六步：
針對于不同的場景下，可能略有差異。
在清晰地了解工程過程之后，我們便需要繼續(xù)深入架構(gòu)領(lǐng)域，分析我們能怎么去實現(xiàn)。我們定義的第一步是：識別軟件工程資產(chǎn)。即在分析如何實現(xiàn)目標(biāo)之前，需要梳理和了解已有的軟件工程過程，以及過程中產(chǎn)生的資產(chǎn)，包括文檔、代碼、測試用例等等，以便更好地利用這些資產(chǎn)，并將其與 LLM 進(jìn)行結(jié)合，進(jìn)而來提升研發(fā)效率。
在這個階段，我們采用了經(jīng)典的用戶旅程分析方法：
上圖中，包含了五個要素：
隨后，圍繞于我們產(chǎn)出的軟件工程資產(chǎn)，便可以進(jìn)行 LLM 微調(diào)試點與探索。
在我們的 LLM 賦能的 API 全生命周期里，我們定義的四個關(guān)鍵資產(chǎn)是：API 規(guī)范和結(jié)構(gòu)、軟件需求（用戶故事）、領(lǐng)域模型、API specs。
由于大語言模型本身是文本，所以我們需要對現(xiàn)有的架構(gòu)資產(chǎn)進(jìn)行 “語言建?！?，簡單來說就是將文本結(jié)構(gòu)化，轉(zhuǎn)變?yōu)樘囟ǖ?、易于閱讀和解析的格式，即領(lǐng)域特定語言（DSL），諸如于 markdown 表格、UML 等。
在同一個場景之下，我們預(yù)期 LLM 能返回固定格式的數(shù)據(jù)，方便我們結(jié)合到工具中。盡管沒有可信的來源證明：OpenAI 在語料階段使用 markdown 作為數(shù)據(jù)，但是從經(jīng)常性輸出 markdown 的結(jié)構(gòu)和 ChatGPT 的渲染來看，markdown 是其中一種 LLM 友好的格式。如：
隨后，我們定義了 API 的 “語言模型”：
與普通的 markdown 表格差別并大。只是呢，我們在 request、response、error response 中使用了類 json 的格式表示。
這里還有一個關(guān)鍵點是，編寫一個針對于該格式的校驗器，一旦出錯可以重來，以提升數(shù)據(jù)質(zhì)量、降低出錯率等。
在訓(xùn)練之前，我們需要準(zhǔn)備一些數(shù)據(jù)，對于現(xiàn)有的 LLM，我們通常采用如下的：instruction、input、output 的結(jié)構(gòu)方式，并由人或者現(xiàn)有的 AI API 來輔導(dǎo)我們進(jìn)行數(shù)據(jù)準(zhǔn)備。
出自《A Survey of Large Language Models》
在進(jìn)行 MVP 階段數(shù)據(jù)處理時，可以考慮多種方式結(jié)合：
如下是我們根據(jù) Swagger、Postman 創(chuàng)建數(shù)據(jù)集的過程：
微調(diào)通常不是一次就能完成的，我們需要結(jié)合 self-instruct 的模式構(gòu)建一些通用的指令、prompt。不過，考慮到大部分公司都有 AI 專家能更好地幫助解決這個問題。
為了評估微調(diào)、訓(xùn)練的結(jié)果，我們需要構(gòu)建一個增量引導(dǎo)的指標(biāo)。而在 AI 編程領(lǐng)域，OpenAI 開源的 HumanEval 數(shù)據(jù)集提供了一個非常好的示例。
HumanEval 通過單元測試自動評估代碼示例的正確性。包含了 164 個帶有單元測試的原始編程問題的數(shù)據(jù)集。以用于評估語言理解力、算法和簡單的數(shù)學(xué)，其中一些可與簡單的軟件面試問題相媲美。
在某種程度上也作為了其它 AI 在語言模型的標(biāo)準(zhǔn)，CodeGen、CodeGeeX 也采用它來進(jìn)行評估。如下是 CodeGeeX 的評估結(jié)果示例：
對于 API 來說，我們同樣也正在設(shè)計相似類似的方式來構(gòu)建。如下是我們微調(diào)完的 RESTful API 示例：
這里還有幾個問題要考慮：
盡管指標(biāo)可以作為一種評價工作或項目進(jìn)展的方法，但過度依賴指標(biāo)可能產(chǎn)生指標(biāo)驅(qū)動的風(fēng)險。但是，我們可以通過構(gòu)建基于反饋的平臺工程，來優(yōu)化并解決這個問題。
在構(gòu)建了第一個 MVP 之時，我們也在探索如何與工具結(jié)合在一起。如在我們的場景之下，采用的是 IDE 插件，便需要開發(fā) IDE 插件來實現(xiàn)。
而針對于 IDE 來說，其過程比較簡單，如下圖所示：
雖然語法分析難度雖然高了一點點，但是并不是主要的挑戰(zhàn)。主要的挑戰(zhàn)是，如何去進(jìn)行交互設(shè)計。
如在 GitHub Copilot 的插件便有非常好的體驗，支持多種不同交互（快捷鍵、Inlay、工具欄等）、Code Completion 模式等。在編輯模式內(nèi)，通過 Intellij IDEA 自帶的 InlayModel，可以支持：Inline，AfterLine，Block 三種不同的模式。
考慮到，過往我們已經(jīng)有了大量的體驗設(shè)計經(jīng)驗，由于需要注意的點是：AI 時代是否有更好的交互方式？
與常規(guī)應(yīng)用的度量不同，對于 AI 產(chǎn)品來說，我們需要非常、非常、非常關(guān)注于用戶對結(jié)果的反饋，并持續(xù)收集這些數(shù)據(jù)：接受、不接受、改進(jìn)后的版本（按需）。
與 ChatGPT 不實用的 Like、Dislike 相比，針對于軟件資產(chǎn)來說，企業(yè)更容易獲得改進(jìn)后的版本，如對于需求的進(jìn)一步完善。
以代碼為例，在 AI 編程工具里，當(dāng)用戶 accept 或者 reject 代碼之后，我們就可以記錄下這些信息。同時，如果用戶對代碼進(jìn)行改動，我們還能將其作為后續(xù)訓(xùn)練的數(shù)據(jù)集。
因此，在我們構(gòu)建端到端的工具時，需要設(shè)計好內(nèi)部的平臺工程，強化反饋回路，以使我們的 AI 更加智能。
利用大語言模型技術(shù)，能幫助我們汲取來自不同領(lǐng)域的優(yōu)秀 API 設(shè)計經(jīng)驗和方法，同時融合研發(fā)組織自身的經(jīng)驗和實踐，以及主流的 API 規(guī)范。這有助于提高架構(gòu)中的 API 設(shè)計效率和質(zhì)量，從而增強整體架構(gòu)的服務(wù)能力和開放性。而具體的提升效果如何，以及引入LLM增強的架構(gòu)治理方式及路徑是否會有所變化，還需要更多的實際應(yīng)用場景來進(jìn)一步驗證。
我們也會在 ArchGuard 架構(gòu)治理平臺中，持續(xù)嵌入相應(yīng)的指標(biāo)和實踐，歡迎大家關(guān)注：https://github.com/archguard/ 。
參考資料：
文章轉(zhuǎn)自微信公眾號@phodal
鍵.png)
