大模型效能工具之智能 CommitMessage
01 背景
随着大型语言模型的迅猛增长,各种模型在各个领域的应用如雨后春笋般迅速涌现。在研发全流程的效能方面,也出现了一系列贯穿全流程的提效和质量工具,比如针对成本较高的 Oncall,首先出现了高质量的 RAG 助手;在开发阶段的 Copilot、Comate、Tabnine 等辅助编程应工具;在测试阶段,也有缺陷检查、安全合规检查、智能 Code Review 等工具;哪怕在交付阶段,也有替代人工的自动化 Agent...
当使用 git commit 提交代码时,需要写繁杂的 CommitMessage,有时候写了后却不符合提交规范被 hook,有时候还被 CodeReview 的同学点评写不到点上...智能 CommitMessage 就是这样一个小助手,帮你按照提交规范自动生成符合规范的 CommitMessage。
以百度 APP 的提交规范为例,规范包括提交类别、产品版本、需求卡片、变更摘要等,其中类别又包括:功能、更新、优化、提测、上车、Merge、FixBug 等,手动抒写较为复杂。
按照 CommitMessage 的组合标准,可以分为两个部分:规范格式 + 变更摘要:
![](https://static001.geekbang.org/infoq/49/492fb26fe81ff44ab37d332729fb2b19.png)
CommitMessage 组成部分
普通摘要类:提交规范格式 + 变更摘要
FixBug 类:提交规范格式 + 变更摘要(包括 bug 原因、影响、修复方式等)
其中运用大模型能力生成变更摘要部分,而提交规范格式及其他标签由个性化插件定制,即可对不同业务线/产品线可定制符合提交规范的 CommitMessage。
智能 CommitMessage 的最终使用效果如下:查看原文
![](https://static001.geekbang.org/infoq/b6/b672d6a619da5a2dbf356841cb876277.png)
git aicommit 用法示例
下面就以智能 CommitMessage 为例,介绍下大模型效能工具开发流程,主要包括:
简单的功能设计
应用指标和模型评估指标
大模型数据处理过程
模型性能优化的几种方式
02 功能与设计
用户入口一:git aicommit
Git 是高效便捷的版本控制系统,虽然百度 APP 移动端已经多仓库化,随着组件化进程的完善,有至少有一半的需求不需要跨仓库提交而使用 Git。
用户入口二:mgit aicommit
MGit (https://github.com/baidu/m-git)是百度自研的一套开源的、基于 Git 的多仓库管理工具,针对多仓库的应用场景安全地、高效的管理多个 Git 仓库,在基础版本之上增加 MGit 插件即可扩展或者修改原命令。
对入口的基本要求:
Git/MGit 入口的使用不影响原有 git/mgit commit 功能的使用,只是能力扩展
保证 Git 和 MGit 的入口分离的同时,保证功能统一,低成本维护
处理方式:抽象实现共用模块 git-aicommit,该模块由 MGit 插件和 Git alias 命令直接调用,开发语言选型 ruby,便于 MGit 插件直接调用。
git-aicommit 模块:提取所有提交仓库中 Git 暂存区内的变更内容,请求模型服务生成 Commit Message。
![](https://static001.geekbang.org/infoq/ec/ecc3c49bfc40b0cc1a4a88e374876efb.png)
MGit/Git 入口,即用户使用入口,对于 MGit 插件可以参考 MGit 如何扩展(https://github.com/baidu/m-git);Git Alias 按如下配置即可:
个性化插件:提交规范的格式定制,任何不同的提交规范均可定制为独立的插件,详细参考下面自定义提交规范章节。
模型服务:接受 git-aicommit 模块的请求,调用 LLM 生成 CommitMessage 摘要内容,加载对应的个性化插件生成最终的 CommitMessage。
03 评估指标
管理学之父彼得·德鲁克说过:“If you can't measure it, you can't manage it.”。
度量指标对于模型选择、后续 Prompt 调优以及 SFT 都至关重要,因为它决定了优化的标准。
生成 CommitMessage 时,既需要理解变更的代码,也需要生成对应的摘要、评估影响等,生成式大模型适合此类任务,当前生成式大模型在市面上也百花齐放,经过综合评估使用成本(包括数据管理、部署运维、性能调优、Prompt 和模型评估)、生成质量、安全风险等方面的考虑,我们选择了百度智能云千帆平台的 ERNIE4(文心 4)。
针对此类摘要任务,常用的度量指标有 BLEU Score、ROUGE Score、BERT Score、PPL、MSE 等,结合生成 CommitMessage 的任务特性,最终确定模型和产品的核心指标:
模型性能指标:MSE(Mean Squared Error,均方误差),用于衡量生成的文本序列与参考 CommitMessage 的文本序列之间的语义相似度;
用户使用指标:AR(Acceptance Rate,直接采纳率),也叫用户直接满足度,针对模型服务生成的 CommitMessage,用户直接采纳的次数相对于总的使用次数的占比
均方误差 MSE(Mean Squared Error)
参考 CommitMessage 的文本序列,指高质量的、简洁的、准确的、标准的 CommitMessage,客观标准是至少包括:为什么修改(Why)、改了什么(What)、影响面(可选),主观标准是人工筛选并提取。
根据定义,计算 MSE 即计算两段文本的语义相似度差值,简单的分为如下三个步骤:
1.文本 Embedding 向量化:
将两段文本转换为向量表示。大模型时代 Embedding 的方式太多太多了,这里依然直接选用了千帆的 Embedding 方式。
2.向量差异计算:
计算两段文本的向量表示间的差异或距离时,我们选择使用余弦相似度;尽管欧几里得距离和马氏距离也是常用的方法,但针对 CommitMessage 这种长度不一致的向量时,余弦相似度表现更为准确。
3.均方误差计算:
将差异或距离平方,然后计算平均值以得到均方误差。
其中,xi 和 yi 是两段文本在第 i 个维度上的表示,n 是维度数量。
本文多次提交两个概念:
参考 CommitMessage:可以是 RD 生成已提交入库的,也可以由大模型生成、经过人工标注的保证质量的 CommitMessage,作为评估的标准 yi
生成 CommitMessage:由大模型生成的 CommitMessage,评估输入的判定项 xi
直接采纳率 AR(Adoption Rate)
总的使用次数包括 3 个结果:
直接采纳数 CA
编辑采纳数 CE
拒绝数 CR
![](https://static001.geekbang.org/infoq/b8/b81e7c232ba13f622fc5f04dc433c735.png)
04 数据处理
大模型应用开发为了更好的性能(包括生成质量、效率、准确度、采纳率),数据处理的成本投入较高,通常占据整个应用开发投入的相当大的比例,有时甚至可能超过模型训练和调优的工作量。总之,有效和高效的数据处理是提升模型性能的关键因素,因此在项目计划和资源分配中应给予足够的重视和投入。
数据处理的目标就是管理(增删改/标查)好数据集,产物是各类数据集,数据集的最终应用场景是模型的性能优化(模型选择、Prompt 优化、SFT),也就是说,如果不做性能优化,就可以不用做数据处理。
数据集与性能优化的关系如下:
评估集,模型选择、Prompt 调优、SFT 后都需要评估集对本次调优进行评估,是否比之前的好,是否达到调优的效果
训练集,指用于 SFT 的标注数据,根据特征从总数据集中筛选
验证集,验证集是用来调整模型超参数,避免过拟合或欠拟合
测试集,SFT 后测试是否达到 SFT 的目的,比如针对某个异常 case 评估其泛化能力
异常集,标注环节明确的低质量的 CommitMessage 数据,特别是大模型生成未被直接采纳的数据
![](https://static001.geekbang.org/infoq/15/1547e80f861db8e0d6f32970baebf7ba.png)
这里介绍下大体的过程及其作用,细节不做展开:
定义数据结构:模型数据(需求/bug 卡片标题、变更数据)、参考 CommitMessage、类别数据(是否 bug、变更行、仓库数)、辅助分析数据(产品线、平台、作者、Topic)等
数据采集:来源于:①线上模型服务生成的 CommitMessage;②存量 RD 已提交入库的 CommitMessage;③其他开源数据集
数据清洗:去噪、去重等处理,确保数据的质量和可用性
标注与注释:标注本条数据作为参考 CommitMessage 的质量,其他辅助分析信息
分类与管理:抽样配比、过滤筛选、查看等
根据我们当前的数据体量,选择了 Pandas(https://pandas.pydata.org/)作为数据处理工具,它对小规模数据和单机环境提供了够用的数据处理和分析功能。然而,随着数据体量的逐步增大,Spark(https://spark.apache.org/)将是一个不错的选择。
05 性能优化
性能优化的目标是提升性能指标,包括核心指标均方误差 MSE 和生成效率,进而提升用户直接采纳率 AR,手段包括如下三种:
停止标记(Stop Token),可提升生成效率
Prompt 优化,可优化 MSE 指标和提升生成效率
SFT 可优化 MSE 指标
5.1 停止标记
当模型对 Prompt 理解不完全时,容易生成多余的解释或注意事项等无效内容,生成更多的 Token 导致生成效率降低(生成效率与生成的 Token 长度直接相关),而所有 Transformer 模型中都设计有停止标记,比如智能 CommitMessage 里调用模型的输出是一个 Markdown 的 json,以“%STOP%”结尾,可指定停止标识为“%STOP%”以提高生成效率。
5.2 Prompt 优化
简单说 Prompt 优化就是设计和优化输入 Prompts 以获得期望的输出。看似一个简单的 NLP 任务,却又叫 Prompt 工程?因为需要让大模型更好的理解期望的需求,确实涉及多学科的知识,比如融合语言学、心理学、计算机科学、数据科学,也包括整套工程方法:系统设计、实验设计、质量控制、项目管理等等方面。智能 CommitMessage 里涉及的两个优化点:
限制输出内容,明确要求
CommitMessage 调用模型的输出要求是 Markdown 的 json,如果模型输出不是正常的 json 将导致解析异常,此时在 Prompt 中明确要求『请仅输出内容,不要做任何解释』可避免生成无效内容,提高生成效率和准确性。
Few-shot
Prompt 优化里有个优化在限制输出样式的情况下非常有效 --Few-shot,以示例让大模型理解并限制输出样式,要求输出一个 Markdown 的多行的 json 数据,样例:
这里的样例不是一个标准的 json 格式(多行换行时缺少“,”),大模型可能按照该格式输出,也可能按照正确的 json 格式输出,所以存在一个异常问题的不确定性,可通过完善该 Few-shot 完全避免该问题:
这里有个类似的概念:Prompt Tuning,Few-shot 和 Prompt Tuning 都是优化和调整大型语言模型输入提示的方法,但有着本质上的区别:
![](https://static001.geekbang.org/infoq/9a/9af598bda42ee467441d8c44fe67fb9f.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
附上智能 CommitMessage 的部分 Prompt(持续优化中):
5.3 SFT
因为文心 4 的模型能力已经有非常出色的生成能力,在这种大模型上做 SFT 成本非常高,所以一般会采用 ERNIE-lite 版本或者 ERNIE-Speed 版本,但是性能稍逊一筹,那如何保证在 ERNIE-Speed 版本中 SFT 后既能不降低整体性能,又能优化低质量 case?
这里可以采用 MoE(Mixture of Experts)的策略,用一个分类器来结合 ERNIE4 + (ERNIE-Speed + SFT)各自的优势,即请求优先经过一个分类器,根据请求的特征进行分类请求 ERNIE4 或者经过 SFT 后的 ERNIE-Speed 模型,如下图示例:
![](https://static001.geekbang.org/infoq/9e/9ebc82706240a3979fc0f183a8d4b117.png)
部署前记得 SFT 评估数据集的全量评估,MSE 优于线上保证本次 SFT 后的 ERNIE-Speed 模型比上次的更好。
SFT 的全过程应该包含四个步骤:
确定目标:优化某个/某类低质量的数据 case,微调后达到评估多少分值
数据准备:基于该 case 提取低质量 case 的特征,向数据集里筛选出训练集、验证集和测试集
SFT 过程:如上图所示
评估部署:根据抽样配比的评估集进行全量评估,保证本次 SFT 后的 ERNIE-Speed 模型比上次的更好
06 自定义提交规范
由于大模型只生成核心的变更摘要或者 Fixbug 的相关信息,而最终需要组合成各式各样的提交规范格式,所以可以将变化抽象为接口,可扩展 python package 实现接口达成自定义符合提交规范的 CommitMessage,按需动态加载实现的插件。
抽象接口如下:
加载某个插件的某个版本时,根据 pkg_resources 判定是已加载,然后配合 importlib 进行 import_module 或者 reload 即可实现动态加载插件
07 未来
大模型对各类语言的代码理解上展现了卓越的能力,但对专有词汇、特定配置、固定格式等的理解依然存在不足,都需要合适的数据集来逐步优化;并且 git diff 获取的变更内容有限,受限于模型 Token 的限制,理解时缺少代码的上下文、依赖关系的关联导致生成质量存在瓶颈,结合 RAG 或许是一个较好的方式;使用入口的交互性、自定义提交规范都可以更 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 工程 大模型的应用与实践:https://zhuanlan.zhihu.com/p/668200325
推荐阅读:
评论