編輯 |鄭麗媛出品 | CSDN（ID：CSDNnews）在 21 世紀(jì)的科技浪潮中，AI 無疑是最為耀眼的明星之一。隨著技術(shù)的不斷演進(jìn)，如今 AI 已逐漸從實驗室走向?qū)嶋H應(yīng)用，其中 AI 編程工具的興起以及大型語言模型（LLM）的廣泛應(yīng)用，更是將 AI 技術(shù)的發(fā)展推向了新的高潮。
為此，在 11 月 14-15 日于北京正式拉開帷幕的 2024 全球機(jī)器學(xué)習(xí)技術(shù)大會上，我們圍繞“AI 編程與大模型應(yīng)用創(chuàng)新”這一主題，邀請了來自阿里、 騰訊、百度、字節(jié)跳動、智譜、商湯科技、騰、小米和 360 等 12 位一線技術(shù)專家。他們從 AI 編碼助手、大模型推理優(yōu)化到 AI Agent 的應(yīng)用探索，全面解析了技術(shù)變革中的核心趨勢與實踐路徑，共同探討 AI 技術(shù)在軟件開發(fā)、生產(chǎn)力提升及應(yīng)用創(chuàng)新上的無限可能。
陳鑫AI 研發(fā)產(chǎn)品進(jìn)化論：從 AI 編碼助手到 AI 程序員在 AI 技術(shù)的飛速發(fā)展下，AI 編程作為當(dāng)前技術(shù)發(fā)展的熱點(diǎn)領(lǐng)域，不僅展現(xiàn)出極大的應(yīng)用潛力，也對開發(fā)者社區(qū)帶來了深遠(yuǎn)影響。以通義靈碼為例，其總下載量已突破 700 萬次，為開發(fā)者編寫了超過 10 億行代碼，并且還在快速增長。
然而，阿里云通義靈碼技術(shù)負(fù)責(zé)人陳鑫指出，目前 AI 編程工具的發(fā)展還處于初期階段，其功能和體驗仍存在諸多不足，如代碼生成質(zhì)量不穩(wěn)定、開發(fā)者不會寫復(fù)雜的提示詞、不知如何與 AI 高效對話，同時在代碼補(bǔ)全之外，他們也希望 AI 工具能輔助完成更多復(fù)雜任務(wù)。
那么，要如何解決這些問題，讓開發(fā)者真正感受到 AI Coding 帶來的高效與便利？
對此，陳鑫提出了四個滿足開發(fā)者訴求的關(guān)鍵技術(shù)方向：模型、數(shù)據(jù)、擴(kuò)展和智能體。
（1）模型：模型是 AI 代碼助手的核心，也是決定其能力上限的關(guān)鍵。要想在代碼生成、補(bǔ)全以及問答任務(wù)中表現(xiàn)出色，可從兩個方面入手：優(yōu)化代碼補(bǔ)全模型以及訓(xùn)練專用任務(wù)模型。
（2）數(shù)據(jù)：代碼庫的數(shù)據(jù)體量龐大且復(fù)雜，如何高效利用這些數(shù)據(jù)，是提升 AI 代碼助手能力的又一關(guān)鍵。例如，可對代碼庫進(jìn)行準(zhǔn)確的分析和檢索；使用企業(yè)上傳的規(guī)范代碼樣例，指導(dǎo)開發(fā)者生成符合標(biāo)準(zhǔn)的代碼；集成企業(yè)內(nèi)部系統(tǒng)的上下文數(shù)據(jù)，進(jìn)一步提升模型的準(zhǔn)確性。
（3）擴(kuò)展：通過引入自定義指令和上下文管理功能，我們可以解決提示詞編寫困難的問題。同時，智能體技術(shù)也將進(jìn)一步擴(kuò)展模型的能力邊界，例如支持更復(fù)雜的代碼任務(wù)、生成可用的測試代碼或完成代碼重構(gòu)。
（4）智能體：目前 AI 代碼助手還只是作為一種簡單的輔助工具出現(xiàn)，開發(fā)者的工作方式并未因此徹底改革，而智能體將有望突破代碼助手的能力上限。
陳鑫表示，代碼智能體的發(fā)展大致可劃分為三個階段：簡單輔助（人類完成絕大部分工作）→智能助手（人類和 AI 協(xié)作工作）→AI 主導(dǎo)（AI 完成絕大部分工作）。在這個過程中，開發(fā)者將感受到智能體帶來全新體驗。
首先，AI 編碼能力從片段級到多文件級。代碼助手的能力會從單文件簡單的片段級別注釋生成、單測生成、代碼優(yōu)化等，進(jìn)化到多文件級別的編碼任務(wù)，例如需求實現(xiàn)、批量測試用例生成、多文件代碼評審、批量代碼重構(gòu)、三方依賴升級等。
其次，可端到端地完成一個完整編碼任務(wù)。開發(fā)者只需要輸入準(zhǔn)確的需求和上下文，AI可自主完成從需求理解、任務(wù)規(guī)劃、代碼生成、DIFF生成全過程。開發(fā)者無需從零開始編碼，而是基于AI生成結(jié)果完成任務(wù)。
再者，會有更多的復(fù)雜步驟實現(xiàn)自動化。例如，AI 可進(jìn)一步實現(xiàn)上下文自動感知、編程工具自動使用、自動功能驗證、自我反思迭代等自動化能力，進(jìn)一步釋放開發(fā)者的生產(chǎn)力。
最重要的是，智能體將成為可以信任的編程伙伴。隨著模型能力、Agent 能力的成熟，開發(fā)者可以更加信任 AI，并傾向于盡可能多的編碼任務(wù)交給 AI 完成，即所謂的“信任拐點(diǎn)“。
基于以上目標(biāo)，陳鑫提到目前通義靈碼也推出了一系列智能體級別的“AI 程序員”，例如可輔助需求實現(xiàn)的 Dev Agents，全自動修復(fù)缺陷的 Bugfix Agents 以及全自動生成單測的 UnitTest Agents。
張少博：基于 CodeGeex 的 AI Coding 實踐與探索面對同一個 MVP（創(chuàng)建最小可行性產(chǎn)品）項目，碼齡 19 年的資深工程師 Alex vs. 碼齡僅 4 年的年輕工程師 Hamid，你認(rèn)為誰的開發(fā)進(jìn)度會更快？一周后的結(jié)果顯示：利用現(xiàn)代 AI 編程工具的 Hamid，其項目進(jìn)度為 95%，而完全依靠手動編程的 Alex 只完成了 7%“這個案例，直觀展現(xiàn)了 AI 編程工具在開發(fā)效率上的巨大優(yōu)勢�！敝亲V AI CodeGeex 高級算法工程師張少博表示。
在此背景下，智譜自 2022 年起堅持對基于 GLM 大模型基座的 CodeGeeX 不斷迭代，并于 2024 年 7 月正式發(fā)布了最新一代 CodeGeeX 4 系列模型，大幅增強(qiáng)了代碼領(lǐng)域各項能力：使用單一模型，即可支持代碼補(bǔ)全、代碼生成、代碼解釋、代碼注釋、工具調(diào)用；具備項目級問答、聯(lián)網(wǎng)搜索、編寫提交信息等全面能力，覆蓋了編程開發(fā)的各種場景。
在模型研發(fā)之外，張少博指出將模型能力轉(zhuǎn)化為實際應(yīng)用是技術(shù)落地的重要一步。
功能的設(shè)計并非憑空想象，而是依賴于對用戶需求的深入了解和分析。張少博表示，CodeGeeX 4 的更新方向很大程度上基于開發(fā)者生態(tài)調(diào)查報告，其結(jié)果揭示了開發(fā)者在實際工作中對 AI 工具的期待與需求。為此，智譜設(shè)計并實現(xiàn)了一系列功能，包括代碼補(bǔ)全、代碼解釋、代碼注釋生成等基礎(chǔ)功能，以及項目級問答、聯(lián)網(wǎng)搜索等高級功能。
以項目級問答為例，目前這是一項開發(fā)者既需要又難以實現(xiàn)的高級功能。該功能如果開發(fā)成功，可為開發(fā)者節(jié)省大量時間、顯著提升開發(fā)效率。本質(zhì)上來說，項目級問答的核心是語義檢索（Retrieval-Augmented Generation, RAG），然而在傳統(tǒng) RAG 流程中，張少博認(rèn)為有幾個可優(yōu)化模塊：
（1）文件切分
文件切分是代碼解析的基礎(chǔ)步驟，直接影響檢索的上下文準(zhǔn)確性。但是單純基于長度的切分方式容易破壞代碼邏輯，而基于關(guān)鍵詞切分雖能保留更多邏輯，但仍可能丟失上下文信息�；诖�，CodeGeeX 4 引入了抽象語法樹（AST）提取代碼結(jié)構(gòu)節(jié)點(diǎn)，重新組織代碼片段，確保切分后保留完整的上下文和結(jié)構(gòu)信息。
（2）向量模型
向量模型的核心是將代碼與自然語言轉(zhuǎn)化為可比較的表征，進(jìn)而實現(xiàn)高效檢索。然而開源通用向量模型在代碼場景能力有限，如 BGE-V3 的準(zhǔn)確率僅為 50% 左右，準(zhǔn)確率較高的閉源模型成本又太高。對于這個問題，張少博指出：可自研模型并針對代碼語義特性進(jìn)行微調(diào)。
（3）檢索策略
單一的相似度檢索策略無法滿足復(fù)雜問題的需求。對此，可采用“摘要生成”和“重排序”進(jìn)行優(yōu)化：為每段代碼片段生成文件信息及總結(jié)性摘要，提升問答相關(guān)性；將用戶問題與代碼片段一同輸入模型，使模型能同時理解問題和片段，提高相關(guān)性判斷精度。
（4）問答模型
如果問答模型能支持更長的上下文、處理更多片段，就能適應(yīng)更復(fù)雜的問題。為了實現(xiàn)這個目標(biāo)，可進(jìn)行階段式訓(xùn)練以激發(fā)其長文本能力，同時結(jié)合短文本和長文本數(shù)據(jù)訓(xùn)練，確保模型也保留短文本性能。
（5）用戶提問
用戶的提問質(zhì)量對模型回答的質(zhì)量有直接影響。但在真實場景中，開發(fā)者往往提問不夠清晰，甚至可能帶有歧義。在接收到用戶查詢后，首先要識別意圖判斷是否啟動全面分析流程，其次根據(jù)問題分類進(jìn)行優(yōu)化處理：對于無關(guān)問題（如簡單問候）快速響應(yīng)，對抽象問題（如“這個項目做了什么”）進(jìn)行任務(wù)拆解，對代詞和模糊表達(dá)的問題（如“第一個文件”）進(jìn)行消歧。
江波：豆包MarsCode，智能編程的探索實踐正如字節(jié)跳動豆包MarsCode團(tuán)隊算法專家江波所說，智能編程這項技術(shù)在近 20 年間不斷演進(jìn)，近年來的爆發(fā)式發(fā)展卻尤為矚目，其中 GitHub Copilot 的成功更是在業(yè)界引起了很大關(guān)注：借助 OpenAI GPT-3 和 CodeX 模型，它顯著提升了代碼補(bǔ)全場景下的性能和準(zhǔn)確度。
參考 GitHub Copilot 的成功經(jīng)驗，豆包MarsCode團(tuán)隊在 2022 年初開始探索代碼補(bǔ)全領(lǐng)域的發(fā)展路徑：從基于開源 LLM 模型構(gòu)建 MVP，組建算法、工程和產(chǎn)品一體的智能編程助手團(tuán)隊，到構(gòu)建代碼 LLM 評測集和自動評測系統(tǒng)以及數(shù)據(jù)鏈路和線上 A/B 測試體系，到今年 6 月發(fā)布國內(nèi)版豆包MarsCode Al編程助手，并最新引入了基于 Chat 的 Copilot 和代碼補(bǔ)全 Pro 功能。
從開發(fā)者對 AI 編程的需求來看，大致可分為代碼生成、代碼理解、問題修復(fù)和知識問答這四種場景。其中，關(guān)于代碼生成中的代碼補(bǔ)全功能，江波基于豆包MarsCode的經(jīng)驗總結(jié)了三個核心要素：
（1）倉庫級上下文感知引擎：自研 ContextModule 引擎，負(fù)責(zé)召回相似代碼片段、符號定義、歷史光標(biāo)瀏覽片段、代碼編輯歷史等，實現(xiàn)倉庫級上下文感知。
（2）自研代碼補(bǔ)全模型：完全自主自研，包括預(yù)訓(xùn)練數(shù)據(jù)爬取、清洗以及 Fill-In-the-Middle 增強(qiáng)訓(xùn)練、Repo-Level 拼接等，針對特定語言、特定框架精調(diào)，實現(xiàn)極低的推理時延。
（3）前后處理策略：基于靜態(tài)分析工具對補(bǔ)全代碼進(jìn)行語法正確性校驗，提供必要的后處理，確保內(nèi)容的連貫以及語法完整性。
同時，江波指出代碼補(bǔ)全的測評指標(biāo)不應(yīng)只看采納率：雖然采納率能被直觀感受，但無法帶來優(yōu)化指導(dǎo)意見為此，應(yīng)使用更全面、合理的指標(biāo)：CPO（Character per Opportunity）= (嘗試率) x (反饋率) x (采納率) x (每次采納平均 token 數(shù)) x (token 平均字符長度)。
不過，一般的代碼補(bǔ)全都專注于編寫全新代碼，無法勝任存量代碼的修改和刪除�；诖�，豆包MarsCode引入了代碼補(bǔ)全 Pro 功能：可根據(jù)前置編輯的內(nèi)容，去預(yù)測下一次編輯的位置和內(nèi)容，甚至可實現(xiàn)單文件多處、倉庫內(nèi)跨文件編輯點(diǎn)位預(yù)測與跳轉(zhuǎn)。據(jù)江波介紹，該功能背后的實踐思路為：基于豆包大模型，通過大量開源倉庫歷史 Commit 中建模從歷史編輯生成當(dāng)前編輯推薦。
在代碼修復(fù)方面，江波建議可采取多 Agent 協(xié)作的方式進(jìn)行優(yōu)化：讓不同的 Agent 擔(dān)任特定任務(wù)（如定位問題、分析錯誤、生成修復(fù)代碼），相互配合完成復(fù)雜任務(wù)；同時，結(jié)合外部工具進(jìn)行代碼結(jié)構(gòu)分析、報錯細(xì)化和邏輯驗證。除此之外，要想在項目問答中實現(xiàn)“準(zhǔn)、快、簡”，在模型方面可加強(qiáng)長文理解和動態(tài) Prompt 渲染，整體上也可以集成聯(lián)網(wǎng)搜索功能以解決開發(fā)者的通用研發(fā)問答。
在演講最后，江波對智能編程的未來進(jìn)行了一番展望。在他看來，短期內(nèi)可期待模型結(jié)構(gòu)與效率提升、長文理解能力加強(qiáng)、實現(xiàn)多模態(tài)及推理與反思能力，但從長期來看，Scaling Law 的局限性和 Test-time Compute 還存在很大的不確定性不過整體而言，他認(rèn)為 span style="background-color:rgb(255, 255, 255);font-size:15px;letter-spacing:1px">AI 輔助編程仍將逐漸演進(jìn)為 AI 驅(qū)動編程，隨著智能體不斷發(fā)展，軟件開發(fā)將被持續(xù)革命。
徐曉強(qiáng)：大模型到智能體，軟件研發(fā)流程變化了什么？自上世紀(jì)六十年代「軟件工程」這個概念被提出以來，這幾十年來該領(lǐng)域已沉淀了一套全面且復(fù)雜的研發(fā)流程。從需求階段，到開發(fā)測試，再到最后的產(chǎn)品發(fā)布，整個流程存在的核心哲學(xué)就是：保證研發(fā)活動快而有序近年來 AI 技術(shù)的演進(jìn)，更是給傳統(tǒng)研發(fā)注入了新動力。
百度文心快碼架構(gòu)師徐曉強(qiáng)指出，目前大量公司正在使用或探索 AI：40% 的公司已經(jīng)在業(yè)務(wù)中應(yīng)用 AI；42% 的公司正在內(nèi)部探索 AI。但是，LLMs 的助力范圍仍然有限：
●缺乏深入思考：只會將推理結(jié)果一股腦輸出，不會考慮信息完整性、、沒能和用戶的意圖深層結(jié)合起來。
●能力單一：只會在特定場景發(fā)揮作用，不會考慮環(huán)境等信息。
●需要人工介入：人工投入占比較高，不會自主去完成某個特定工作的整個流程。
面對這些問題，徐曉強(qiáng)提出了一個疑問：能否進(jìn)一步挖掘大模型的能力，使其對研發(fā)流程有更深層次的改變？這個答案，或許就是智能體（Agent）。
根據(jù)維基百科上 Agent 的定義，“一個可以觀察周圍環(huán)境并作出行動以達(dá)到某個目標(biāo)的自主實體，通常是指（但不一定是）一個軟件程序”，徐曉強(qiáng)總結(jié) Agent 的原理就是：以 LLM 為基礎(chǔ)，通過思考 & 記憶，執(zhí)行工具 & 行動，讓開發(fā)者委能夠托 Agent 自主完成任務(wù)。
基于此，徐曉強(qiáng)介紹了百度文心快碼在這方面的具體實踐，即它在六大場景推出的智能體應(yīng)用。
（1）續(xù)寫智能體：傳統(tǒng)的代碼續(xù)寫方式往往局限于靜態(tài)上下文中，僅依靠光標(biāo)位置進(jìn)行插入，且無法感知開發(fā)者的真實意圖和環(huán)境變化。而續(xù)寫智能體可思考動作與代碼邏輯之間的關(guān)系，支持多點(diǎn)動作，記憶用戶操作歷史，多維理解意圖，并聯(lián)動多種工具，集成更多開發(fā)環(huán)境。
（2）問答智能體：傳統(tǒng)代碼問答依賴搜索引擎，但常因信息不足、匹配度低而效果不佳，大模型雖有幫助，對復(fù)雜問題仍難精確回答。而問答智能體可通過問題分析與意圖識別能力，結(jié)合后臺代碼驗證以提供更針對性的回答，并反思用戶反饋提升服務(wù)質(zhì)量、滿足個性化需求。
（3）Debug 智能體：傳統(tǒng)錯誤修復(fù)方法耗時費(fèi)力易出錯，且難以關(guān)聯(lián)多次錯誤，改正還可能引入新錯誤，不符合業(yè)務(wù)需求。Debug 智能體通過全程模型自主思考、逐步排查 bug 根源，并加入驗證環(huán)節(jié)，顯著提升修復(fù)效果，最后執(zhí)行命令、與 IDE 聯(lián)動，保證修復(fù)結(jié)果正確。
（4）單測智能體：傳統(tǒng)單元測試依賴手動編寫腳本，效率低且成本高，自動生成腳本冗余且缺乏針對性。為解決此問題，單測智能體采用新策略：理解業(yè)務(wù)邏輯，多工具協(xié)同確保測試準(zhǔn)確；反饋執(zhí)行結(jié)果，感知覆蓋率，識別冗余；提醒業(yè)務(wù)邏輯錯誤，指導(dǎo)修正。
（5）安全智能體：在傳統(tǒng)的安全檢查中，靜態(tài)掃描存在局限，且手動修復(fù)要求開發(fā)者學(xué)習(xí)漏洞原理與解決方案，成本高昂。而在安全智能體的幫助下，可打通從掃描到修復(fù)的全鏈路，自動掃描并修復(fù)代碼，最后通過思考來優(yōu)化修復(fù)策略，提高了修復(fù)效率并確保系統(tǒng)的安全性。
（6）全棧編程智能體：為了整體提高開發(fā)效率和代碼質(zhì)量，全棧編程智能體需要滿足更大的任務(wù)背景（從靜態(tài)的文件代碼到整個項目），實現(xiàn)更豐富的生成行為（從純代碼文本到文件級的增、刪、改），提供更智能的人機(jī)交互（基于任務(wù)的多輪調(diào)整與優(yōu)化）。
徐曉強(qiáng)表示在 Agent 的加持下， 目前 AI 正在重構(gòu)軟件研發(fā)流程和范式。在演講最后，他還向開發(fā)者發(fā)出倡議：不要只是單純地使用 AI，而要真正地去和 AI 協(xié)同工作。
張功貫：大數(shù)據(jù)研效場景的智能化探索圍繞“大數(shù)據(jù)研效場景的智能化探索”這一主題，騰訊平臺智能技術(shù)架構(gòu)師張功貫帶來了富有深刻洞見的精彩演講。
在大數(shù)據(jù)場景中，隨著智能化技術(shù)的逐步落地，各個角色的工作內(nèi)容和分工協(xié)作需要進(jìn)一步明確和分析。張功貫指出，大數(shù)據(jù)研效場景中的角色通常可劃分為三類：負(fù)責(zé)業(yè)務(wù)邏輯的數(shù)據(jù)科學(xué)家/分析師（DA），負(fù)責(zé)數(shù)據(jù)邏輯的數(shù)據(jù)倉庫工程師（DE），以及負(fù)責(zé)底層技術(shù)的引擎/運(yùn)維工程師（SE）。
雖然這三類角色的關(guān)注點(diǎn)各不相同，但在研效場景中，所有業(yè)務(wù)點(diǎn)都離不開成本、效率、穩(wěn)定性的考量基于此，張功貫強(qiáng)調(diào) AI4Data（AI for Data）的能力模型，要圍繞成本、效率和穩(wěn)定性來打造智能化能力，具體可分為 AI4DataSystem 和 AI4DataWareHouse。
●AI4DataSystem 能力落地
在 AI4DataSystem 的構(gòu)建過程中，以傳統(tǒng)機(jī)器學(xué)習(xí)結(jié)合專家經(jīng)驗為基礎(chǔ)打造一套完整的思路體系。
對于任何數(shù)據(jù)系統(tǒng)或智能化系統(tǒng)來說，可控性都是至關(guān)重要的。因此可在數(shù)據(jù)感知方面投入大量精力，將其細(xì)化到 JVM 粒度的數(shù)據(jù)采集，準(zhǔn)確把握關(guān)鍵性能指標(biāo)。同時，建立一個 360° 的指標(biāo)評估體系，支撐到任務(wù)、進(jìn)程粒度的數(shù)據(jù)上卷和下鉆能力，量化那些背后看不見的內(nèi)容。
而在大數(shù)據(jù)生態(tài)環(huán)境中，從業(yè)務(wù)系統(tǒng)到大數(shù)據(jù)引擎，組件鏈路復(fù)雜且調(diào)用路徑冗長，問題排查效率較低。為解決這一痛點(diǎn)，張功貫提出：開發(fā)一個全鏈路診斷系統(tǒng)，使其能針對每個組件設(shè)置診斷點(diǎn)，結(jié)合已采集到的指標(biāo)數(shù)據(jù)，快速定位問題所在。
除此之外，在智能調(diào)優(yōu)方面，基于對實際進(jìn)程運(yùn)行數(shù)據(jù)（如 CPU、內(nèi)存等）的感知，結(jié)合白盒+黑盒的優(yōu)化機(jī)制，可節(jié)省超過 50% 的內(nèi)存成本 + 30% 的 CPU 成本，實現(xiàn)對資源利用率的優(yōu)化控制。
●AI4DataWareHouse 能力落地
AI4DataWareHouse 的核心目標(biāo)是從業(yè)務(wù)視角出發(fā)，為數(shù)據(jù)分析師提供更高效、更直觀的支持。通常情況下，如 SQL 生成、診斷、SQL 優(yōu)化等數(shù)倉生產(chǎn)、數(shù)據(jù)分析工作，都是從既定的 SQL 邏輯往引擎下層推進(jìn)，因此缺乏對業(yè)務(wù)邏輯算法重構(gòu)的能力。但張功貫指出：LLM 的出現(xiàn)，突破了這層限制。
不同于只考慮算力、技術(shù)計算算法問題的基于系統(tǒng)引擎的優(yōu)化改進(jìn)，基于業(yè)務(wù)的 SQL 優(yōu)化將更多考慮業(yè)務(wù)邏輯、業(yè)務(wù)算法上的合理性這也正是 SQL-Copilot 智能體的作用。然而，大模型業(yè)務(wù)在落地過程中，仍面臨四大關(guān)鍵問題：大模型的幻覺問題、文本的長度問題、業(yè)務(wù)的可迭代性問題以及業(yè)務(wù)結(jié)果可評測性問題。
針對上述問題，張功貫分享了一些系統(tǒng)性的解決方案：
（1）對于幻覺問題和可迭代性問題，可引入 SQL 問題分類模型。先將問題細(xì)分為多個類別，再根據(jù)不同類別的特點(diǎn)進(jìn)行更有針對性的優(yōu)化與調(diào)整，逐步迭代解決方案，以此減少幻覺問題的發(fā)生。
（2）對于業(yè)務(wù)結(jié)果的可驗證性問題，可建立一套“雙跑機(jī)制”的驗證方案，即每天對優(yōu)化前后的 SQL 執(zhí)行情況進(jìn)行抽樣對比，以此來監(jiān)測系統(tǒng)在 SQL 智能優(yōu)化方面帶來的實際業(yè)務(wù)效果。
通過對數(shù)千個數(shù)據(jù)分析場景案例的觀察，張功貫表示引入 SQL 智能體后，其業(yè)務(wù)評測數(shù)據(jù)得到了顯著提升：結(jié)果一致率達(dá)到 71.05%，正向優(yōu)化占比為 73.58%，正向優(yōu)化提升時間均值高達(dá) 85.37s，正向優(yōu)化提升比例均值也達(dá)到了 30.58%。
提及對于未來的下一步規(guī)劃，張功貫指出目前 SQL 智能體在數(shù)倉場景中的落地還存在挑戰(zhàn)：由于 SQL 語句變得很長，會導(dǎo)致嚴(yán)重的幻覺問題�；诖�，他提供了一些思考：首先，可將復(fù)雜的 SQL 語句進(jìn)行切分再提交給大模型處理，以降低單次處理的復(fù)雜度；其次，針對長文本場景對大語言模型進(jìn)行微調(diào)，例如引入一些壓縮機(jī)制，以提高模型處理長 SQL 語句的能力。
張濤有用到好用：AI 生產(chǎn)力工具如何放大 AI 能力近年來，生成式 AI 的發(fā)展在各類場景中表現(xiàn)出了強(qiáng)大的潛力，特別是在代碼生成和編程輔助領(lǐng)域。而隨著代碼模型與解決方案的演進(jìn)成熟，商湯科技 Copilot 應(yīng)用技術(shù)負(fù)責(zé)人張濤指出目前 AI 在開發(fā)場景的需求已被驗證：60% 以上開發(fā)者正在使用 AI 編程助手，獨(dú)立任務(wù)對比實驗中總體工作時間減少了 55%。
在張濤看來，代碼大模型的核心競爭力在于如何發(fā)揮AI優(yōu)勢，助力代碼開發(fā)。聚焦到程序員身上，就是為其解決痛點(diǎn)（揚(yáng)長補(bǔ)短的使用能力）并減輕壓力（新的解決問題的體驗）。
從程序員視角出發(fā)，構(gòu)建編程工具主要有四個階段：LLM、Code LLM、Code Copilot 和 Code Agent。在開發(fā)場景中，目前大家常見的 AI 代碼助手就類似于 Code Copilot，其工作流程主要包括三個方面：
●代碼補(bǔ)全：不僅支持多種編程語言，還能抓取倉庫級信息，確保補(bǔ)全建議既準(zhǔn)確又上下文相關(guān)。
●對話問答：無論是解決特定的代碼問題，還是基于知識庫進(jìn)行更廣泛的技術(shù)咨詢，都能迅速給出答案。此外還具備執(zhí)行內(nèi)置代碼任務(wù)的能力，比如代碼重構(gòu)、代碼翻譯、代碼糾錯以及單元測試生成。
●開發(fā)協(xié)助：除了自動生成 Commit Message 外，還允許開發(fā)者使用預(yù)設(shè)的智能體/自定義智能體來輔助日常開發(fā)任務(wù)，為團(tuán)隊協(xié)作提供了極大便利。
“如果我們不僅想生成代碼，還想把它的功能擴(kuò)展得更多，應(yīng)該再做一些什么優(yōu)化？”張濤指出，這就是從 Code Copilot 迭代到 Code Agent 了。首先，可以通過如添加網(wǎng)絡(luò)檢索和 API 調(diào)用等工具調(diào)用，來滿足僅需簡單獲取信息、基本只調(diào)用一個 API 的簡單場景。其次，面對需串聯(lián)很多 API 調(diào)用、組合多種功能接口的復(fù)雜場景，張濤建議引入代碼運(yùn)行沙盒，即：Agent 根據(jù)用戶需求生成代碼后直接在沙盒中運(yùn)行，驗證其功能是否符合預(yù)期；當(dāng)需求表述模糊時，可通過代碼迭代將任務(wù)逐步細(xì)化；此外，沙盒環(huán)境還能捕獲運(yùn)行中的錯誤并提供調(diào)試信息，讓 Agent 可以自動修復(fù)問題。
基于此，Code Agent 的應(yīng)用就不僅局限于代碼場景，而是可以向數(shù)據(jù)分析等其他領(lǐng)域擴(kuò)展其中，商湯科技推出的 AI 數(shù)據(jù)分析工具“小浣熊”就是典型案例之一。
緊接著，面對代碼大模型是否能成為“銀彈”的這個問題，張濤表示要先從第一步做起：讓代碼大模型在當(dāng)前的開發(fā)場景基礎(chǔ)上，進(jìn)一步擴(kuò)展其適用范圍，幫助更多團(tuán)隊成員高效完成工作。雖然代碼大模型的起點(diǎn)是開發(fā)工作，但還有許多與開發(fā)并列的重要崗位，例如完成需求分析與制定優(yōu)先級的產(chǎn)品經(jīng)理、規(guī)劃迭代周期并跟蹤進(jìn)展的項目經(jīng)理、負(fù)責(zé)內(nèi)部版本驗收的測試人員，以及完成部署上線及實時處理告警的運(yùn)維工程師。
經(jīng)過需求分析，張濤發(fā)現(xiàn)這些崗位的任務(wù)中約 80% 可以利用當(dāng)前代碼大模型的能力完成，另外如用戶界面設(shè)計或圖像處理等需求，也可以通過引入多模態(tài)組件，在未來的技術(shù)框架中得到支持。
最后關(guān)于生產(chǎn)力工具形態(tài)的選擇，張濤也總結(jié)了他的兩個觀點(diǎn)：
（1）相較于 LUI（語言界面），GUI（圖形界面）形態(tài)更能打造最佳場景體驗。因為 LUI 在描述復(fù)雜需求時存在局限性，如表達(dá)不清和“幻覺”問題，導(dǎo)致效率不高，尤其是在編程等需要精確邏輯的任務(wù)中。
（2）以 AI+ 而非 +AI 形式來打造 AI Native 應(yīng)用。縱觀全局的產(chǎn)品定義和功能需求，他指出以數(shù)據(jù)為中心驅(qū)動產(chǎn)品設(shè)計，更易于形成 All In One 的綜合工具形態(tài)，降低上下文切換成本。
張君：大模型推理加速的優(yōu)化實踐推理，作為大模型從訓(xùn)練到應(yīng)用的關(guān)鍵環(huán)節(jié)，其速度和準(zhǔn)確性直接關(guān)系到模型的實際效用。如何有效加速大模型的推理過程，也已然成為 AI 領(lǐng)域亟待解決的關(guān)鍵問題之一�；谶@個話題，騰生態(tài)技術(shù)專家張君帶來了“大模型推理加速的優(yōu)化實踐”的主題演講。
現(xiàn)階段而言，大模型推理主要面臨三大技術(shù)挑戰(zhàn)。首先是計算和內(nèi)存需求高：超大模型參數(shù)、超長序列等是大模型的發(fā)展趨勢，大計算和內(nèi)存需求高。其次是延遲和吞吐量之間的平衡：自回歸算力利用率低，低時延高吞吐難以兼顧。最后是推理成本逐漸增加：大模型應(yīng)用場景走向多元化，從單模態(tài)到多模態(tài)，再到 OpenAI o1，使得計算量和顯存進(jìn)一步增加，推理的時間和成本也隨之增長。
針對這些挑戰(zhàn)，學(xué)術(shù)界和工業(yè)界提出了很多大模型推理加速技術(shù)。其中張君指出，在實際業(yè)務(wù)場景中，通過從算子層、算法層和框架層對推理的加速，可極大提升大模型的推理能力。
●算子層優(yōu)化：利用算子加速庫如 ONNX Runtime 或 TVM，或手工進(jìn)行算子融合將多個基本算子融合成一個復(fù)雜算子，減少內(nèi)存訪問次數(shù)，加快計算速度。
●算法層優(yōu)化：通過算法層面的修改或者創(chuàng)新，如模型分片策略優(yōu)化，投機(jī)采樣，量化壓縮等手段，減少存儲空間和計算資源的需求，提高推理速度。
●框架層優(yōu)化：推理的部署形態(tài)，大部分都以框架（引擎）實現(xiàn)，在框架層實現(xiàn)數(shù)據(jù)、計算調(diào)度、內(nèi)存分片等操作，如 Continous Batching，PageAttention，PD 分離部署等。
基于此，張君詳細(xì)介紹了騰大模型推理框架 MindIE-LLM 及其進(jìn)行的一系列加速實踐。從框架架構(gòu)來看，MindIE-LLM 主要分成五個部分：LLM Manager，Text Generator，Modeling，Distributed 和 Quantization。針對各種核心問題，MindIE-LLM 實行了 PD 分離部署、多機(jī)推理 & 通信計算融合以及并行解碼等多種優(yōu)化操作，以全方位提升模型推理效率和用戶體驗。
除此之外，為了顯著提升 Transformer 模型的訓(xùn)練和推理速度，騰 Transformer 領(lǐng)域加速庫 ATB（Ascend Transformer Boost）也應(yīng)運(yùn)而生：基于華為 Ascend AI 處理器，專門為 Transformer 模型的訓(xùn)練和推理而設(shè)計。具體來說，ATB 加速庫功能體現(xiàn)在以下幾個方面：
（1）提供原生的高性能基礎(chǔ) Operation，包括單算子，融合算子，通信算子，量化算子等。
（2）提供 Operation 接口原型和 Plugin 框架，用戶可以自己開發(fā) AscendC 算子。
（3）提供構(gòu)圖接口，用戶可以使用原生的 Operation 和 Plugin Operation 組成復(fù)雜的算子圖。
（4）提供維測 log 接口和 profiling 接口，使用問題定位和性能分析。
為此，ATB 也采用了一系列優(yōu)化策略：內(nèi)存優(yōu)化中間張量、tilling data、scratch memory統(tǒng)一管理，執(zhí)行之前提前規(guī)劃內(nèi)存地址，做到地址的最大復(fù)用；全局 tiling 緩存一次性全部加載所有 op tilling data；流水并行調(diào)度策略異步執(zhí)行圖計算，在 NPU 仍在計算時，提前準(zhǔn)備下一個圖的計算資源。
最后展望未來，張君提出了三種具有前瞻性的可能性。首先，他設(shè)想通過開發(fā)更為極致的壓縮量化算法，甚至探索 Transformer 模塊功能的替代方案，以實現(xiàn)計算量的進(jìn)一步縮減。其次，針對 Prefill 和 Decode 兩大環(huán)節(jié)，張君思考了是否有可能設(shè)計專門的硬件解決方案，分別針對 bound 和 IO bound 問題進(jìn)行優(yōu)化。最后，他還提出了異構(gòu)加速的思路，即考慮將那些與當(dāng)前硬件不親和的計算任務(wù)轉(zhuǎn)移到 CPU 上執(zhí)行，充分利用CPU強(qiáng)大的多核并行處理能力來實現(xiàn)加速。
高鵬至：小米在 AI Agent 上的思考和探索在過去的兩三年里，我們見證了大語言模型（LLMs）在參數(shù)規(guī)模和通用能力上的飛速發(fā)展，但人類與大語言模型的交互方式卻較為單一：通常是以文本為輸入，輸出同樣的文本結(jié)果。
這種簡單的交互方式在處理復(fù)雜任務(wù)時，往往難以滿足實際需求于是，Agent 的概念被提出并迅速引發(fā)關(guān)注。小米大模型團(tuán)隊高級算法工程師高鵬至指出，Agent 工作流更適合解決復(fù)雜問題：任務(wù)拆解，子任務(wù)分配以及多 Agent 合作。
目前，Agent 已在代碼生成、工作流自動化、個人助理、機(jī)器人等多個領(lǐng)域廣泛應(yīng)用，并展現(xiàn)出強(qiáng)大的潛力。而從小米的角度來看，手機(jī)依然是未來十年的個人計算中心，同時智能家居場景又擁有豐富的感知設(shè)備和復(fù)雜場景，基于此高鵬至表示：Agent + 手機(jī)/智能家居是“天作之合”。
他認(rèn)為，Agent 在手機(jī)上會有三種未來形態(tài)：
●工具學(xué)習(xí)：Agent 通過調(diào)用 APP 的服務(wù)或內(nèi)容完成任務(wù)，即利用 API 或工具接口，與單個 APP 深度集成，從而精準(zhǔn)完成任務(wù)。
● GUI Agent：大模型與多模態(tài)技術(shù)結(jié)合，可以直接理解手機(jī)屏幕內(nèi)容，解析 GUI（圖形用戶界面）的布局與操作邏輯，即 Agent 能夠模擬用戶點(diǎn)擊、滑動等交互動作，完成操作。
●中心化 Multi-Agent：當(dāng)單個 APP 無法解決復(fù)雜任務(wù)時，需要借助多個 APP 的協(xié)同操作，即 Multi-Agent 通過任務(wù)分解和子任務(wù)調(diào)度，實現(xiàn)任務(wù)鏈路的高效運(yùn)作。
自去年開始，小米大模型團(tuán)隊在 Agent 方面做了許多探索。其中，高鵬至重點(diǎn)介紹了 ToolPlanner，一種工具增強(qiáng)的 LLM，用于多粒度指令的路徑規(guī)劃和反饋。關(guān)于 ToolPlanner 的工作動機(jī)，高鵬至表示主要來源于兩個核心問題：一是在真實場景中，用戶通常不會使用帶有API名稱的指令，而是用更自然的語言來描述他們的意圖；二是之前的工作關(guān)注大模型能否最終生成一個合理的答案，而忽略了它們的指令遵循能力。
在進(jìn)入具體的工作討論前，他強(qiáng)調(diào)了該項目的一些關(guān)鍵背景：
（1）與外部工具交互的方案原型。ToolPlanner 的核心思想源自于 ICLR 2023 中 ReAct 相關(guān)論文，其方案可簡單總結(jié)為 Thought-Action-Observation 的循環(huán)操作，若模型認(rèn)為任務(wù)已完成，則模型可以跳出循環(huán)并生成答案。
（2）數(shù)據(jù)原型。ToolPlanner 用到的數(shù)據(jù)集是 ToolBench，它是當(dāng)前最大規(guī)模的 API 級別工具學(xué)習(xí)數(shù)據(jù)集之一，包含了 16K+ 個 API 和 12K+ 個用 ChatGPT 生成的數(shù)據(jù)示例。
（3）常見的工具增強(qiáng) LLM 結(jié)構(gòu)。工具增強(qiáng)大模型通常由外部工具池、檢索器和主模型組成，在每一輪中，大模型可以進(jìn)行思考、與外部工具交互、提出解決方案和重新開始（可選）這幾項操作。
其中，由于 ToolBench 數(shù)據(jù)集在設(shè)計上具有一定局限性，缺乏對用戶自然語言意圖的全面覆蓋，小米團(tuán)隊基于此構(gòu)建了 MGToolBench。它通過引入多粒度用戶指令，模擬了用戶表達(dá)意圖的不同層次，旨在更真實地反映實際場景中用戶可能提出的問題。另外，ToolPlanner 的訓(xùn)練策略上共有兩個階段：階段一，利用 Cross-Entropy Loss 的正常 SFT；階段二，Rank Responses to align Human Feedback（RRHF）。
在演講最后，高鵬至展示了部分實驗結(jié)果，顯示 ToolPlanner 在許多任務(wù)中都表現(xiàn)優(yōu)異并超越了 GPT-4 等最先進(jìn)的模型，驗證了多粒度指令能更好地與用戶的使用習(xí)慣對齊。
圓桌論壇：大模型應(yīng)用創(chuàng)新與實踐在 AI 技術(shù)快速發(fā)展的浪潮中，大模型的崛起正在重塑各行各業(yè)的應(yīng)用場景和實踐方式。如何將大模型的潛力轉(zhuǎn)化為實際的生產(chǎn)力，成為學(xué)術(shù)界和產(chǎn)業(yè)界共同關(guān)注的焦點(diǎn)。
在本次以“大模型應(yīng)用創(chuàng)新與實踐”為主題的圓桌對話中，Athena Labs CTO 王興明擔(dān)任主持，與來自學(xué)術(shù)和工業(yè)界的三位重量級嘉賓深入探討這一領(lǐng)域的機(jī)遇與挑戰(zhàn)：中國石油大學(xué)（北京）人工智能學(xué)院計算機(jī)系系主任呂仲琪，通義實驗室高級搜索算法專家丁瑞雪，以及 360 人工智能研究院知識圖譜與文檔理解算法負(fù)責(zé)人劉煥勇。他們結(jié)合各自的研究與實踐經(jīng)歷，共同探索大模型在實際應(yīng)用中的創(chuàng)新路徑與未來前景，為我們揭示技術(shù)落地背后的思考與洞察。
在大模型的創(chuàng)新應(yīng)用與實踐之間，“POC 一分鐘，上線一整年”這句話或許是許多企業(yè)做 RAG 的真實寫照。對于中國石油大學(xué)（北京）副教授，人工智能學(xué)院計算機(jī)系系主任呂仲琪來說，學(xué)術(shù)界的研究往往停留在 POC 階段，直接上線的機(jī)會較少。為了感受這個體驗，他們試著將 RAG 技術(shù)應(yīng)用到石油領(lǐng)域：圍繞石油行業(yè)相關(guān)數(shù)據(jù)做了一個數(shù)據(jù)集，而該領(lǐng)域的數(shù)據(jù)多分布于邊緣設(shè)備，難以匯聚到互聯(lián)網(wǎng)，且高度專業(yè)化，當(dāng)前開源的大語言模型難以理解。通過這次嘗試，呂仲琪強(qiáng)調(diào)，并不存在哪個行業(yè)不適合做 RAG，反而是那些尚未被廣泛開發(fā)的行業(yè)，往往更容易誕生創(chuàng)新應(yīng)用。
而針對大模型實踐過程中的多樣化數(shù)據(jù)，尤其是包含文本、圖片等多模態(tài)信息的數(shù)據(jù)，通義實驗室高級搜索算法專家丁瑞雪指出，在實際操作中需要采用靈活而高效的技術(shù)方案。具體來說，在處理多模態(tài)數(shù)據(jù)時，通常會分別為文本和圖片建立獨(dú)立的向量索引，同時根據(jù)需求選擇統(tǒng)一嵌入或分開處理的方式。盡管后者的架構(gòu)更復(fù)雜，但能顯著提升效果。到了數(shù)據(jù)召回階段，可采用單路或多路召回策略，將文本和圖片關(guān)聯(lián)數(shù)據(jù)綜合返回。而為了實現(xiàn)更高效的整合，她表示可以設(shè)計一個在線 Agent 來負(fù)責(zé)判斷如何組織數(shù)據(jù)，例如是通過 OCR 將圖片轉(zhuǎn)化為文本，還是直接調(diào)用多模態(tài)大模型完成聯(lián)合推理等。
最后，圍繞 AI 如何變現(xiàn)這個行業(yè)難題，360 人工智能研究院知識圖譜及文檔理解算法方向負(fù)責(zé)人劉煥勇指出，想要通過 RAG（檢索增強(qiáng)生成）技術(shù)賺錢，需要綜合考慮市場定位、技術(shù)實現(xiàn)和實際應(yīng)用。首先，關(guān)鍵是找到有支付能力的客戶群體，資金充裕的大型機(jī)構(gòu)可能是更理想的目標(biāo)，因為中小企業(yè)通常預(yù)算有限。其次，在選擇應(yīng)用場景時，應(yīng)避免進(jìn)入已被大模型廣泛覆蓋且競爭激烈的領(lǐng)域，如通用客服，這類場景容易被大模型壓制，難以形成優(yōu)勢。相反，應(yīng)聚焦在特定領(lǐng)域的高門檻應(yīng)用，例如石油行業(yè)的特殊需求，結(jié)合自身技術(shù)積累和行業(yè)壁壘，才能實現(xiàn)差異化競爭。
