AI輔助編程測評與企業實踐-蔣志偉.pdf

《AI輔助編程測評與企業實踐-蔣志偉.pdf》由會員分享，可在線閱讀，更多相關《AI輔助編程測評與企業實踐-蔣志偉.pdf（42頁珍藏版）》請在三個皮匠報告上搜索。

1、AI 輔助編程真實測評與企業落地實踐作者：蔣志偉個人簡要蔣志偉愛好技術的架構師參與 OpenTelemetry 開源社區曾 0-1 搭建美團 APP 的推薦、搜索服務曾負責 Q 上億用戶機票搜索、低價推薦系統有旅游GDS(全球分銷系統)的技術專利開源項目基于場景的AI編程測評集https:/ Bengio 團隊嵌入技術，將高維稀疏的數據通過神經網絡或其他算法映射到低維稠密的 向量 空間，尤其Word Embedding 詞向量普遍用于 NLP 領域Embedding2013 GoogleWord2Vec 模型生成詞向量成為自然語言處理的標配方法，通過上下文來預測當前詞語的 CBOW 訓練方法，

2、為后來神經網絡語言模型的發展奠定了基礎Word2Vec2017 Google OpenAITransformer 模型在翻譯任務上超過之 前最優秀的循環神經網絡模型采用Attention Layers重點解決多義詞問題，基于此的 GPT 模型讓AIGC 極大發展TransformerCode LLM（代碼生成大語言模型）的發展人工智能對自然語言的上下文推理、一詞多義理解能力的加持。讓場景契合的輔助編程領域有了快速的發展輔助編程相關場景任務一般有三大類：代碼-代碼：包含代碼補全、代碼修復 代碼-文本：代碼解釋、代碼優化、代碼異常排查 文本-代碼：通過高級提示詞 Prompt 做代碼生成(單元測試

3、、API、SQL、數據建模等)Code LLM：代碼生成大語言模型的發展關鍵模型與項目2024.7 CodeGeeX4 https:/ DeepSeek-V2 https:/ LLM測評數據集問題現有的Code LLM測評工具通常使用有限的訓練數據以HumanEval、MBPP 代表代碼模型評測數據幾年沒更新模型測試訓練、測試數據不足現有的Code LLM測評原理只關注代碼結果的正確性，看不到代碼的可讀性、完整性、通用性等維度的信息評估標準單一各家公布自家測試結果，測評是黑盒的狀態將測評集放到訓練集中訓練，好比拿著標準答案答考題，測評分數會虛高測評打分原理造假容易代碼大模型各家評測基數差異巨大

4、Github上公布的測評結果明顯有水分Meta Code Llama智譜 CodeGeeX 4阿里巴巴 CodeQwen北大 aiXcoderDeepSeek Coder V2 同樣大模型不同測評來源，評分不一樣基本常識性錯誤代碼大模型評測集工作原理最常用的測評：Human Eval OpenAI 發布的一個評估大型語言模型在代碼生成方面表現的基準測試。它包含164個設計的Python編程任務，每個任務有多個單元測試，通過評估模型生成的代碼是否能通過這些單元測試來評判模型的能力1根據測評文件編程任務給出prompt，調用大模型生成完整代碼，保存到一個樣本文件的completion字段中用JSO

5、N格式定義好編程任務，保存測評集在文件中2代碼大模型評測集工作原理4用程序讀取樣本文件，批量把任務生成中代碼和任務的單元測試代碼合并成一個完整的程序3假設樣本文件叫samples.jsonl，調用叫 evaluate_functional_correctness 函數完成1-4的步驟批量動態執行每個任務程序，如果單元測試用例通過，返回passed，最后調用passk 的算法測評打分5passk 打分算法簡單來造個假1部署 Humman Eval 測評環境準備編程任務、答案樣本2簡單用測試集和問題集運行打分效果，passk 分值 0.16簡單修改測試集數據，增加正確答案樣本4passk 分值 明

6、顯提高,達到 0.4993業界都自家測評打分沒有透明渠道造假成本太低基于場景功能的測評測試集02基于編程場景的測評編程使用場景從日常編程習慣，按頻率和功能進行工具的對比測評，如代碼補全、缺陷查找、代碼調優、報錯排查、代碼解釋等提示詞生成能力提示詞生成功能代碼的能力，如API文檔、單元測試、代碼注釋、參考模版編寫新模塊等能力的對比測評業務建模能力輔助編程能更多讀懂我們的業務邏輯，參與框架設計，如數據庫表設計、項目構建、根據數據模型生成Service代碼客觀加主觀判定不能只局限程序對錯簡單打分，要加入更多判斷標準：成熟度、完整度、易用性、語言特性等實際編程出發看到真正的價值代碼補全提示從代碼上下文

7、補全的結果，對比其理解和輸出的準確能力上下文理解基于已有的代碼模版和示例，新的示例自動補全的準確性和代碼風格的統一性能力統一風格能力考慮國內的正常使用，測評基于國內輔助編程平臺，同時參考 Github Copliot。我認為的第一梯隊產品去比較為了避嫌，暫且A、B、C表示。最后有測評總結報告，列出第一梯隊和測評產品完整對比結果代碼補全提示補全一般，代碼注解不一致差、幾乎沒法用優秀、體驗非常棒，內容風格一致統一風格能力這是有關電商產品庫的真實代碼先設計好類目表LsCategory相關數據庫操作模版示例參考LsCategory 模版，對比輔助生成電商 Spu 實例效果AABC代碼補全提示這是有關機

8、票搜索的真實的代碼，search方法根據入參搜索條件返回搜索結果上下文理解能力先輸入文字注釋，看看A、B、C 各自代碼補全效果：CBAB、C 理解了注釋的意圖，拿了不存在的入參屬性A 理解想表達意圖同時，給出了代碼庫中正確方法，也秒懂打印日志的意圖測評維度不同項目案例逐行提示、多行提示測評代碼補全總的代碼采納率作為測評標準長期統計，A代碼采納率略高，上下文能力一般，幻覺多高頻缺陷查找導致CPU100%的死循環、各種嚴重的內存溢出、基本業務邏輯錯誤、線程并發死鎖問題這類缺陷特點：常年高頻發生、對業務影響大、往往花更多的精力進行線上排查和修復常見致命缺陷高頻缺陷查找導致CPU100%的死循環pub

9、lic class endlessLoop public static void main(String args)int count=0;while(count 10)if(count=3)continue;System.out.println(count);count+;舉個例子ABC左邊是一個常見的死循環Case，A、B、C都沒有發現這個致命問題，用ChatGPT 明確告知會導致無限循環和修復建議。這種程序往往導致線上服務無法工作高頻缺陷查找綜合打分：借鑒Human Eval 打分思路，根據高頻缺陷查找場景分析有沒有缺陷正確與否進行開源測評集：同時講主觀答案進行提示詞模版優化轉換成客觀答

10、案https:/ 測評維度檢查標簽里的Java代碼，有沒有死循環的情況。返回XML標簽格式結果，格式,如果有，status返回1，沒有status返回0，不知道status返回-1.BA測評集20+，A、B 在70%識別缺陷，C 不到60%測評初步結論報錯排查的測評從產品角度看實用性編譯錯誤階段運行失敗階段產品體驗測評維度：排查入口的友好性B、C 產品編譯階段排查功能實用A、Github Copliot 沒有編譯階段報錯排查的功能B報錯排查的測評運行階段的報錯修復A、B、C 插件在失敗信息中異常排查的幫助鏈接AB多種典型場景測試和驗證、排查多個運行失敗的Case示例：配置錯誤的環境路徑，找不到

11、服務啟動失敗Github Copliot 插件并不支持這項功能A、C 排查錯誤根因更高輔助編程工具箱CA編程過程中，常用到一些工具類過去本地實現，后來借助saas工具AI 工具箱的集成，因為大模型具備自定義提示詞能力，工具類更通用更有效率C、A 工具箱設計實用AI生成能力的可行性測評03高級功能生成能力零代碼生成可運行的單元測試用例，考慮測試邊界，保持風格、規范統一幾乎零代碼生成準確的API文檔，文檔可讀性高、保持風格、規范統一*代碼注釋*版本控制提交注釋生成風格統一、可讀性高參考現有代碼庫模版*仿寫實例的能力API文檔單元測試表設計和SQL生成低代碼平臺能力參考生成數據建模單元測試生成能力代

12、碼采納率：可用性，普遍生成單元測試編譯不過這個點比較不好評判，基于開銷考慮，單元測試沒有帶上完備上下文更細粒度化的方法測試生成能力、測試邊界能力 產品上 A 有友好的方法粒度單元測試入口 A、B生產代碼有更豐富的邊界測試Case，C比較簡單 仿寫支持的能力：A支持選擇仿寫模版文件其它手動輸入仿寫文件的內容Token，非常不便利重要測評維度單元測試生成能力API級別單元測試可用性：比如A產品生產基本可用的Postman測試模版，B和C生成模版不可用測評的維度AA 自動生成 Postman API 請求模版Postman 調用添加商品類目的API請求API測試用例驗證成功Token生成API方法的

13、 Postman Collection 2的JSON文件模版其中指定了地址127.0.0.1和端口號8099參考表結構 create table ls_category.API文檔生成能力相同提示詞，文檔的風格差異大不同用途性質的API文檔，要清晰表達出來Prompt生成完整的API文檔：帶上入參、出參詳細介紹，給出完整示例，格式markdown，給前端調用BAC選取5-6個項目的API服務API 方法少，簡單A、B、C 很好的生成了文檔API 方法多，入參出參復雜A、B 較好完整文檔，C 入參、出參不完整測評結果參考現有代碼模塊仿寫新實例提示詞設計非常重要RAG檢索代碼庫的上下文能力友好的產

14、品交互方式A根據模版，生成類似的實例代碼ABCB、C仿寫能力都很差、不準確A支持選擇代碼文件，仿寫和參考代碼高度一致，有很強的復用性數據建模能力通過業務系統描述數據庫表字段、表結構關系的理解能力和準確度表設計根據業務需求，表結構基礎架構上，生成可運行SQL的能力SQL 生成根據技術需求，生成項目構建的能力項目構建建模后，理解業務邏輯，0-1 構建、部署、啟動項目的文檔能力低代碼能力表設計和SQL用技術語言輸入提示詞，生成表設計，包含表與表的關系，完整的SQL多個實際項目，考驗代碼大模型業務場景理解能力和推理能力，同時考量正確率和完整度測評維度設計一個商品庫表：里面有sku表、spu表、類目ca

15、tegory表;spu和category關系：spu里面有一級、二級、三級類目信息 spu和sku關系：一個spu 對應多個sku，區別在于規格，規格多有個值，可以用JSON方式保存為一個字段。sku包含第三級類目的信息Prompt電商系統產品庫表設計BAB 在表設計、業務理解更完整：比如表字段描述、復雜字段業務示例表設計和SQL直接用業務語言輸入提示詞，看看對業務理解和代碼更高要求的生成能力視頻點播教學系統，設計表，產品需求如下：視頻管理：視頻列表、視頻搜索、上下架視頻、新增上傳視頻課程管理：課程列表、課程搜索、上下架課程、新增課程、課程關聯視頻、課程分類、一個課程會有一個或者多個視頻分類管

16、理：新增分類、新增一級分類、一級分類下新增二級分類、分類排序、刪除分類視頻數據記錄表：每個用戶觀看視頻最大時間，觀看視頻的完成比，記錄每個用戶的id、name視頻統計信息表：每個視頻觀看人數、觀看次數、觀看完成比(每個用戶觀看視頻95%表示視頻觀看完成)每個表都有如下的幾個字段:remarks.返回結果:所有表所有字段和字段說明的SQL語句Prompt視頻教學系統產品需求文檔ABCA 表設計漏掉了一個重要的用戶播放記錄表，表名不太符合規范B、C根據產品文檔描述，沒有設計E-R圖下，完整的將所有表生成出來項目構建和低代碼能力思考輸出主觀、考量維度多、往往不是看一次性輸出，包括續寫能力系統差異、復

17、雜程度很難統一測評一個 Vue+Bootstrap 的手機端的商城 功能描述：一個商城首頁、購物車頁、個人中心Prompt前端Vue的商城項目開源構建、低代碼項目模版提示詞更細粒度維度觀察：區分系統、區分語言、用途開源項目，讓專業領域的人給出細節的建議一個 Maven 項目，希望將 Mysql 的表 用 mybatis+Springboot 封裝成Dao，mybatis plus 版本 3.5.5，Springboot 版本 3.1.7，Mysql 驅動 8.0.13，完成pom.xml，同時寫 Dao、Service、Controller 示例PromptJava Maven 項目搭建用Py

18、thon 實現企業內部用戶授權服務的完整代碼PromptPython 搭建授權系統借鑒低代碼平臺，從使用場景看實用性提示詞模版設計體現了未來架構師、高級工程師編程能力的價值開源積累通用的項目提示詞，完善項目模版，幫助研發團隊提效不同用途的定位決定提示詞風格https:/ 輔助編程案例Turing helps leading AI and enterprise companies enhance LLM performance for reasoning, Turing increases developer productivity by over 30%with Duet AITuring

19、宣傳為他們服務工程師帶來了30%提效baidu團隊百度營銷服務團隊案例有超過半數的工程師在使用其輔助日常編碼工作。截至目前，百度營銷服務團隊已有超過95%的工程師使用文心快碼進行研發提效，文心快碼（Baidu Comate）代碼生成占比29.42%RAG 檢索增強能力A 提供RAG新建知識庫管理后臺RAG收錄檢索企業的代碼庫、知識庫能力A 的編程智能問答中，匹配收錄知識庫的內容AB 支持RAG收錄企業自身代碼庫能力開源代碼大模型支持微調用訓練框架Factory-LLaMA 對開源代碼大模型進行微調加入企業代碼減小幻覺真實場景提效如何量化業界以代碼采納率作為一個主要的量化指標其它指標：智能問答使

20、用次數更容易量化功能指標：API文檔、回歸測試、數據建模.企業統計輔助編程提效的方案企業真實的提效如何統計代碼采納率、智能問答頻率一個重要參考指標 40-50%項目評審階段：企業項目開發分工，輔助編程量化任務比周期性對項目開發周期、提測項目質量(Bug 數和修復時長）、Bugfix 情況(線上故障解決時間)歷史對比ABB 相對 A 還增加了工程師智能問答和輔助功能使用次數的統計企業提效體系化的解決方案輔助編程流程 SOP 化，從需求分析、技術評審、架構設計、技術分工，每個環節把AI輔助能力考慮進來，替代人工企業足夠的決心和資源，長期持久的計劃。適合場景：系統可復制強、微服務化。研發團隊初中級工

21、程師比重大提效過程建立高效的團隊協作機制，產品、技術、測試之間，技術團隊內部充分條件SOP企業自身業務場景在系統設計上微服務和PaaS 化，未來系統趨向低代碼甚至零代碼平臺團隊協作低代碼開發輔助編程工具測評總結：實際場景混合使用測評的產品核心子功能A產品B產品C產品其它國內產品基礎功能代碼補全優秀一般不足一般缺陷查找不足一般勉強不足報錯排查一般一般一般不足代碼解釋優秀優秀一般一般高級能力單元測試一般勉強不足不足API文檔優秀優秀一般模版代寫優秀一般不足數據建模勉強優秀一般企業級方案RAG檢索增強一般一般不支持不足量化提效勉強一般不支持開源透明不支持不支持支持私有化能力未知未知一般總評還有很大的成長空間沒法生產使用判斷等級：優秀、一般、勉強、不足(實際場景不可用)、不支持謝謝蔣志偉 2024.08.19