01 背景

隨著大型語言模型的迅猛增長，各種模型在各個領(lǐng)域的應(yīng)用如雨后春筍般迅速涌現(xiàn)。在研發(fā)全流程的效能方面，也出現(xiàn)了一系列貫穿全流程的提效和質(zhì)量工具，比如針對成本較高的Oncall，首先出現(xiàn)了高質(zhì)量的RAG助手；在開發(fā)階段的Copilot、Comate、Tabnine等輔助編程應(yīng)工具；在測試階段，也有缺陷檢查、安全合規(guī)檢查、智能Code Review等工具；哪怕在交付階段，也有替代人工的自動化Agent…

當(dāng)使用git commit提交代碼時，需要寫繁雜的CommitMessage，有時候?qū)懥撕髤s不符合提交規(guī)范被hook，有時候還被CodeReview的同學(xué)點評寫不到點上…智能CommitMessage就是這樣一個小助手，幫你按照提交規(guī)范自動生成符合規(guī)范的CommitMessage。

以百度APP 的提交規(guī)范為例，規(guī)范包括提交類別、產(chǎn)品版本、需求卡片、變更摘要等，其中類別又包括：功能、更新、優(yōu)化、提測、上車、Merge、FixBug等，手動抒寫較為復(fù)雜。

按照CommitMessage的組合標(biāo)準(zhǔn)，可以分為兩個部分：規(guī)范格式 + 變更摘要：

CommitMessage組成部分

• 普通摘要類：提交規(guī)范格式 + 變更摘要
• FixBug類：提交規(guī)范格式 + 變更摘要（包括bug原因、影響、修復(fù)方式等）

其中運用大模型能力生成變更摘要部分，而提交規(guī)范格式及其他標(biāo)簽由個性化插件定制，即可對不同業(yè)務(wù)線/產(chǎn)品線可定制符合提交規(guī)范的CommitMessage。

智能CommitMessage的最終使用效果如下：查看原文

git aicommit 用法示例

下面就以智能CommitMessage為例，介紹下大模型效能工具開發(fā)流程，主要包括：

• 簡單的功能設(shè)計
• 應(yīng)用指標(biāo)和模型評估指標(biāo)
• 大模型數(shù)據(jù)處理過程
• 模型性能優(yōu)化的幾種方式

02 功能與設(shè)計

用戶入口一：git aicommit

Git是高效便捷的版本控制系統(tǒng)，雖然百度APP移動端已經(jīng)多倉庫化，隨著組件化進程的完善，有至少有一半的需求不需要跨倉庫提交而使用Git。

用戶入口二：mgit aicommit

MGit?(https://github.com/baidu/m-git)是百度自研的一套開源的、基于Git的多倉庫管理工具，針對多倉庫的應(yīng)用場景安全地、高效的管理多個Git倉庫，在基礎(chǔ)版本之上增加MGit插件即可擴展或者修改原命令。

對入口的基本要求：

1. Git/MGit入口的使用不影響原有g(shù)it/mgit commit功能的使用，只是能力擴展
2. 保證Git和MGit的入口分離的同時，保證功能統(tǒng)一，低成本維護

處理方式：抽象實現(xiàn)共用模塊git-aicommit，該模塊由MGit插件和Git alias命令直接調(diào)用，開發(fā)語言選型ruby，便于 MGit 插件直接調(diào)用。

git-aicommit模塊：提取所有提交倉庫中Git暫存區(qū)內(nèi)的變更內(nèi)容，請求模型服務(wù)生成Commit Message。

• MGit/Git入口，即用戶使用入口，對于MGit插件可以參考MGit如何擴展(https://github.com/baidu/m-git)；Git Alias按如下配置即可：

# 給 git 添加 Alias：git aicommit
$ git config --global alias.aicommit '!f() { ruby -e '''require "git-aicommit"; MGit::GitAICommit.run(ARGV);''' -- "$@"; }; f'

• 個性化插件：提交規(guī)范的格式定制，任何不同的提交規(guī)范均可定制為獨立的插件，詳細參考下面自定義提交規(guī)范章節(jié)。
• 模型服務(wù)：接受git-aicommit模塊的請求，調(diào)用LLM生成CommitMessage摘要內(nèi)容，加載對應(yīng)的個性化插件生成最終的CommitMessage。

03 評估指標(biāo)

管理學(xué)之父彼得·德魯克說過：“If you can’t measure it, you can’t manage it.”。

度量指標(biāo)對于模型選擇、后續(xù)Prompt調(diào)優(yōu)以及SFT都至關(guān)重要，因為它決定了優(yōu)化的標(biāo)準(zhǔn)。

生成CommitMessage時，既需要理解變更的代碼，也需要生成對應(yīng)的摘要、評估影響等，生成式大模型適合此類任務(wù)，當(dāng)前生成式大模型在市面上也百花齊放，經(jīng)過綜合評估使用成本（包括數(shù)據(jù)管理、部署運維、性能調(diào)優(yōu)、Prompt和模型評估）、生成質(zhì)量、安全風(fēng)險等方面的考慮，我們選擇了百度智能云千帆平臺的ERNIE4（文心4）。

針對此類摘要任務(wù)，常用的度量指標(biāo)有BLEU Score、ROUGE Score、BERT Score、PPL、MSE等，結(jié)合生成CommitMessage的任務(wù)特性，最終確定模型和產(chǎn)品的核心指標(biāo)：

• 模型性能指標(biāo)：MSE（Mean Squared Error，均方誤差），用于衡量生成的文本序列與參考CommitMessage的文本序列之間的語義相似度；
• 用戶使用指標(biāo)：AR（Acceptance Rate，直接采納率），也叫用戶直接滿足度，針對模型服務(wù)生成的CommitMessage，用戶直接采納的次數(shù)相對于總的使用次數(shù)的占比

均方誤差MSE（Mean Squared Error）

參考CommitMessage的文本序列，指高質(zhì)量的、簡潔的、準(zhǔn)確的、標(biāo)準(zhǔn)的CommitMessage，客觀標(biāo)準(zhǔn)是至少包括：為什么修改（Why）、改了什么（What）、影響面（可選），主觀標(biāo)準(zhǔn)是人工篩選并提取。

根據(jù)定義，計算MSE即計算兩段文本的語義相似度差值，簡單的分為如下三個步驟：

1.文本Embedding向量化：

• 將兩段文本轉(zhuǎn)換為向量表示。大模型時代Embedding的方式太多太多了，這里依然直接選用了千帆的Embedding方式。

2.向量差異計算：

• 計算兩段文本的向量表示間的差異或距離時，我們選擇使用余弦相似度；盡管歐幾里得距離和馬氏距離也是常用的方法，但針對CommitMessage這種長度不一致的向量時，余弦相似度表現(xiàn)更為準(zhǔn)確。

3.均方誤差計算：

• 將差異或距離平方，然后計算平均值以得到均方誤差。
• 
• 其中，xi 和 yi 是兩段文本在第 i 個維度上的表示，n 是維度數(shù)量。

本文多次提交兩個概念：

參考CommitMessage：可以是RD生成已提交入庫的，也可以由大模型生成、經(jīng)過人工標(biāo)注的保證質(zhì)量的CommitMessage，作為評估的標(biāo)準(zhǔn)yi

生成CommitMessage：由大模型生成的CommitMessage，評估輸入的判定項xi

直接采納率AR（Adoption Rate）

總的使用次數(shù)包括3個結(jié)果：

• 直接采納數(shù) CA
• 編輯采納數(shù) CE
• 拒絕數(shù) CR

04 數(shù)據(jù)處理

大模型應(yīng)用開發(fā)為了更好的性能（包括生成質(zhì)量、效率、準(zhǔn)確度、采納率），數(shù)據(jù)處理的成本投入較高，通常占據(jù)整個應(yīng)用開發(fā)投入的相當(dāng)大的比例，有時甚至可能超過模型訓(xùn)練和調(diào)優(yōu)的工作量。總之，有效和高效的數(shù)據(jù)處理是提升模型性能的關(guān)鍵因素，因此在項目計劃和資源分配中應(yīng)給予足夠的重視和投入。

數(shù)據(jù)處理的目標(biāo)就是管理（增刪改/標(biāo)查）好數(shù)據(jù)集，產(chǎn)物是各類數(shù)據(jù)集，數(shù)據(jù)集的最終應(yīng)用場景是模型的性能優(yōu)化（模型選擇、Prompt優(yōu)化、SFT），也就是說，如果不做性能優(yōu)化，就可以不用做數(shù)據(jù)處理。

數(shù)據(jù)集與性能優(yōu)化的關(guān)系如下：

• 評估集，模型選擇、Prompt調(diào)優(yōu)、SFT后都需要評估集對本次調(diào)優(yōu)進行評估，是否比之前的好，是否達到調(diào)優(yōu)的效果
• 訓(xùn)練集，指用于SFT的標(biāo)注數(shù)據(jù)，根據(jù)特征從總數(shù)據(jù)集中篩選
• 驗證集，驗證集是用來調(diào)整模型超參數(shù)，避免過擬合或欠擬合
• 測試集，SFT后測試是否達到SFT的目的，比如針對某個異常case評估其泛化能力
• 異常集，標(biāo)注環(huán)節(jié)明確的低質(zhì)量的CommitMessage數(shù)據(jù)，特別是大模型生成未被直接采納的數(shù)據(jù)

這里介紹下大體的過程及其作用，細節(jié)不做展開：

• 定義數(shù)據(jù)結(jié)構(gòu)：模型數(shù)據(jù)（需求/bug卡片標(biāo)題、變更數(shù)據(jù)）、參考CommitMessage、類別數(shù)據(jù)（是否bug、變更行、倉庫數(shù)）、輔助分析數(shù)據(jù)（產(chǎn)品線、平臺、作者、Topic）等
• 數(shù)據(jù)采集：來源于：①線上模型服務(wù)生成的CommitMessage；②存量RD已提交入庫的CommitMessage；③其他開源數(shù)據(jù)集
• 數(shù)據(jù)清洗：去噪、去重等處理，確保數(shù)據(jù)的質(zhì)量和可用性
• 標(biāo)注與注釋：標(biāo)注本條數(shù)據(jù)作為參考CommitMessage的質(zhì)量，其他輔助分析信息
• 分類與管理：抽樣配比、過濾篩選、查看等

根據(jù)我們當(dāng)前的數(shù)據(jù)體量，選擇了Pandas(https://pandas.pydata.org/)作為數(shù)據(jù)處理工具，它對小規(guī)模數(shù)據(jù)和單機環(huán)境提供了夠用的數(shù)據(jù)處理和分析功能。然而，隨著數(shù)據(jù)體量的逐步增大，Spark(https://spark.apache.org/)將是一個不錯的選擇。

05 性能優(yōu)化

性能優(yōu)化的目標(biāo)是提升性能指標(biāo)，包括核心指標(biāo)均方誤差MSE和生成效率，進而提升用戶直接采納率AR，手段包括如下三種：

• 停止標(biāo)記（Stop Token），可提升生成效率
• Prompt優(yōu)化，可優(yōu)化MSE指標(biāo)和提升生成效率
• SFT可優(yōu)化MSE指標(biāo)

5.1 停止標(biāo)記

當(dāng)模型對Prompt理解不完全時，容易生成多余的解釋或注意事項等無效內(nèi)容，生成更多的Token導(dǎo)致生成效率降低（生成效率與生成的Token長度直接相關(guān)），而所有Transformer模型中都設(shè)計有停止標(biāo)記，比如智能CommitMessage里調(diào)用模型的輸出是一個Markdown的json，以“%STOP%”結(jié)尾，可指定停止標(biāo)識為“%STOP%”以提高生成效率。

5.2?Prompt優(yōu)化

簡單說Prompt優(yōu)化就是設(shè)計和優(yōu)化輸入Prompts以獲得期望的輸出?？此埔粋€簡單的NLP任務(wù)，卻又叫Prompt工程？因為需要讓大模型更好的理解期望的需求，確實涉及多學(xué)科的知識，比如融合語言學(xué)、心理學(xué)、計算機科學(xué)、數(shù)據(jù)科學(xué)，也包括整套工程方法：系統(tǒng)設(shè)計、實驗設(shè)計、質(zhì)量控制、項目管理等等方面。智能CommitMessage里涉及的兩個優(yōu)化點：

1. 限制輸出內(nèi)容，明確要求

CommitMessage調(diào)用模型的輸出要求是Markdown的json，如果模型輸出不是正常的json將導(dǎo)致解析異常，此時在Prompt中明確要求『請僅輸出內(nèi)容，不要做任何解釋』可避免生成無效內(nèi)容，提高生成效率和準(zhǔn)確性。

2. Few-shot

Prompt優(yōu)化里有個優(yōu)化在限制輸出樣式的情況下非常有效 --Few-shot，以示例讓大模型理解并限制輸出樣式，要求輸出一個Markdown 的多行的 json 數(shù)據(jù)，樣例：

按以下格式輸出CommitMessage，只是一個markdown的代碼片段，包含在"```json"?和?"```"內(nèi)，『請僅輸出內(nèi)容，不要做任何解釋』:
```json
{"summary": string  // 少于30字的中文，簡潔的、準(zhǔn)確的描述Git Commit Message"reason": string  // 分析修復(fù)方式，詳細描述這個bug出現(xiàn)的具體原因，可以引用代碼，少于60字"fixup": string  // 分析修復(fù)方式，簡潔、準(zhǔn)確的描述修復(fù)方式，可以引用代碼，少于30字
}
```

這里的樣例不是一個標(biāo)準(zhǔn)的json格式（多行換行時缺少“,”），大模型可能按照該格式輸出，也可能按照正確的json格式輸出，所以存在一個異常問題的不確定性，可通過完善該Few-shot完全避免該問題：

按以下格式輸出CommitMessage，只是一個markdown的代碼片段，包含在"```json" 和 "```"內(nèi)，『請僅輸出內(nèi)容，不要做任何解釋』:
```json
{"summary": string,  // 少于30字的中文，簡潔的、準(zhǔn)確的描述Git Commit Message"reason": string,  // 分析修復(fù)方式，詳細描述這個bug出現(xiàn)的具體原因，可以引用代碼，少于60字"fixup": string  // 分析修復(fù)方式，簡潔、準(zhǔn)確的描述修復(fù)方式，可以引用代碼，少于30字
}
```

這里有個類似的概念：Prompt Tuning，Few-shot 和 Prompt Tuning都是優(yōu)化和調(diào)整大型語言模型輸入提示的方法，但有著本質(zhì)上的區(qū)別：

附上智能CommitMessage的部分Prompt（持續(xù)優(yōu)化中）：

通俗易懂的角色描述：基于需求描述和實現(xiàn)該需求的git diff變更代碼，自動生成規(guī)范的git提交信息。 
需求描述的標(biāo)題如下：{{%title}}git diff變更代碼如下：
(DIFF-START)
{{%git_diff}} 
(DIFF-END)任務(wù)拆解
1.  解析需求標(biāo)題： 
提取關(guān)鍵信息，如功能點、問題點等。
對文本進行清洗，去除無關(guān)字符和格式。
2.  分析git diff變更代碼：
識別變更的文件和代碼塊。
分析代碼變更的類型（如新增、修改、刪除等）。
3.  生成Commit Message：
結(jié)合需求標(biāo)題以及代碼變更分析，編寫Commit Message。 
確保提取的內(nèi)容符合對應(yīng)項的要求，如“summary: 少于30字的中文，簡潔的、準(zhǔn)確的描述Git Commit Message”等。
4.  驗證Commit Message： 
檢查Commit Message是否清晰、準(zhǔn)確。
5.  按以下格式輸出CommitMessage，只是一個markdown的代碼片段，包含在"`json" 和 "`"內(nèi)，『請僅輸出內(nèi)容，不要做任何解釋』:
```json
{"summary": string  // 少于30字的中文，簡潔的、準(zhǔn)確的描述Git Commit Message
}
```%STOP%

5.3?SFT

因為文心4的模型能力已經(jīng)有非常出色的生成能力，在這種大模型上做SFT成本非常高，所以一般會采用ERNIE-lite版本或者ERNIE-Speed版本，但是性能稍遜一籌，那如何保證在ERNIE-Speed版本中SFT后既能不降低整體性能，又能優(yōu)化低質(zhì)量case？

這里可以采用MoE（Mixture of Experts）的策略，用一個分類器來結(jié)合ERNIE4 + （ERNIE-Speed + SFT）各自的優(yōu)勢，即請求優(yōu)先經(jīng)過一個分類器，根據(jù)請求的特征進行分類請求ERNIE4或者經(jīng)過SFT后的ERNIE-Speed模型，如下圖示例：

部署前記得SFT評估數(shù)據(jù)集的全量評估，MSE優(yōu)于線上保證本次SFT后的ERNIE-Speed模型比上次的更好。

SFT的全過程應(yīng)該包含四個步驟：

1. 確定目標(biāo)：優(yōu)化某個/某類低質(zhì)量的數(shù)據(jù)case，微調(diào)后達到評估多少分值
2. 數(shù)據(jù)準(zhǔn)備：基于該case提取低質(zhì)量case的特征，向數(shù)據(jù)集里篩選出訓(xùn)練集、驗證集和測試集
3. SFT過程：如上圖所示
4. 評估部署：根據(jù)抽樣配比的評估集進行全量評估，保證本次SFT后的ERNIE-Speed模型比上次的更好

06 自定義提交規(guī)范

由于大模型只生成核心的變更摘要或者Fixbug的相關(guān)信息，而最終需要組合成各式各樣的提交規(guī)范格式，所以可以將變化抽象為接口，可擴展python package實現(xiàn)接口達成自定義符合提交規(guī)范的CommitMessage，按需動態(tài)加載實現(xiàn)的插件。

抽象接口如下：

from abc import ABC, abstractmethodclass IPluginHook(ABC):"""插件實現(xiàn)的接口定義"""@abstractmethoddef hook_prepare(self, ctx):"""準(zhǔn)備"""@abstractmethoddef hook_is_fix_bug(self, ctx) -> bool:"""是否fixbug的提交類型，默認(rèn)false"""@abstractmethoddef hook_language(self, ctx) -> Language:"""生成語言，默認(rèn)中文"""@abstractmethoddef hook_generate_variables(self, ctx):"""生成模板的變量"""@abstractmethoddef hook_generate_message(self, ctx) -> str:"""根據(jù)模板和變量，生成CommitMessage@warning: 該方法插件必須實現(xiàn)，否則將報出異常"""

加載某個插件的某個版本時，根據(jù)pkg_resources判定是已加載，然后配合 importlib進行import_module或者reload即可實現(xiàn)動態(tài)加載插件

def __install_plugin(pkg_name: str, version: str):"""安裝插件"""subprocess.check_call([sys.executable, '-m', 'pip', 'install', f"{pkg_name}=={version}"])return __load_module(pkg_name, force=True)def __load_module(pkg_name: str, force: bool = False):"""加載module"""module_name = __module_name(pkg_name)loaded_module = sys.modules.get(module_name)if loaded_module is not None:if force:m = importlib.reload(loaded_module)importlib.reload(pkg_resources)return mreturn loaded_modulem = importlib.import_module(module_name)importlib.reload(pkg_resources)return m

07 未來

大模型對各類語言的代碼理解上展現(xiàn)了卓越的能力，但對專有詞匯、特定配置、固定格式等的理解依然存在不足，都需要合適的數(shù)據(jù)集來逐步優(yōu)化；并且git diff獲取的變更內(nèi)容有限，受限于模型Token的限制，理解時缺少代碼的上下文、依賴關(guān)系的關(guān)聯(lián)導(dǎo)致生成質(zhì)量存在瓶頸，結(jié)合RAG或許是一個較好的方式；使用入口的交互性、自定義提交規(guī)范都可以更AI，總之：AI Native 尚未成功，同志仍須努力。

——————END——————

參考資料：

[1] LangChain：https://www.langchain.com/

[2] git：https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases

[3] pandas：https://pandas.pydata.org/

[4] Spark：https://spark.apache.org/

[5] 百度千帆：https://console.bce.baidu.com/qianfan/overview

[6] Prompt工程 大模型的應(yīng)用與實踐：https://zhuanlan.zhihu.com/p/668200325

推薦閱讀：

基于afx透明視頻的視覺增強前端方案

百度一站式數(shù)據(jù)自助分析平臺（TDA）建設(shè)

淺析如何加速商業(yè)業(yè)務(wù)實時化

登錄系統(tǒng)演進、便捷登錄設(shè)計與實現(xiàn)

一文帶你完整了解Go語言IO基礎(chǔ)庫

?