點這里??星標(biāo)關(guān)注，獲取最新資訊！
在上一篇文章 【GitHub Copilot產(chǎn)品經(jīng)理和微軟MVP告訴你：企業(yè)是否需要訓(xùn)練自己的代碼大模型？- 微軟MVP全球峰會紀(jì)行】中，我以GitHub Copilot作為案例，和大家分析了企業(yè)進行私有化模型訓(xùn)練的6個基本要素。但這其實是一個未完成的話題。
企業(yè)內(nèi)部存在大量的私域數(shù)據(jù)是客觀事實，從代碼生成角度來看，私有的框架、公用代碼組件、內(nèi)部編碼規(guī)范、內(nèi)部接口定義和說明以及內(nèi)部業(yè)務(wù)邏輯這些內(nèi)容客觀存在；即便不適合采用私有化訓(xùn)練的方式，我們也必須找到解決這些問題的有效方式。
在本篇中，我將延續(xù)這個話題和大家聊一聊幾個大家在大模型領(lǐng)域經(jīng)常聽到的技術(shù)：提示詞工程、RAG（檢索增強式生成）和模型微調(diào)，分析一下這3個技術(shù)之間到底是怎樣的一種關(guān)系。更重要的是，對于企業(yè)技術(shù)管理者來說，如何構(gòu)建一種機制，讓企業(yè)內(nèi)部具備應(yīng)對大模型應(yīng)用這種全新應(yīng)用類型的持續(xù)改進機制。本篇的內(nèi)容仍然是基于我和前文提到的三位重要人物的對話，包括：微軟全球副總裁Julia Liuson 潘正磊，GitHub Copilot的產(chǎn)品經(jīng)理 Ryan J. Salva，GitHub Next 團隊的負(fù)責(zé)人 Idan Gazit ；我也參考了OpenAI DevDay上的一些視頻和其他一些技術(shù)資料，都列在本文的結(jié)尾，供大家翻閱；除了這些參考，本文的大部分內(nèi)容也是基于我和我的團隊在AISE和SmartCode開發(fā)過程中的經(jīng)驗整理而成。希望對大家有所幫助。
在企業(yè)中引入AI能力是當(dāng)前所有企業(yè)管理者都在考慮的問題，但并不是所有人都意識到，AI能力不是獨立的，它需要融入到企業(yè)現(xiàn)有的管理和工程場景中，用全新的方式重構(gòu)這些場景，最終演化出我們從未見過的新場景。
延續(xù)上一篇中有關(guān)電和電器的比喻，大模型是電，企業(yè)應(yīng)用就是各種電器。
因此，大模型應(yīng)用不會是獨立的系統(tǒng)，而是為現(xiàn)有的系統(tǒng)注入新的能力，它的影響面會從一些當(dāng)前顯而易見的場景逐漸蔓延到那些我們現(xiàn)在還想不到的部分。這個過程需要企業(yè)內(nèi)幾乎所有人都參與其中。對于企業(yè)管理者而言，如何構(gòu)建一套AI時代下適合企業(yè)IT系統(tǒng)演進的全新策略和路線圖，才是真正的關(guān)鍵問題。
大模型應(yīng)用工程能力建設(shè)（SE4AI）
回到大模型應(yīng)用系統(tǒng)制定問題。即便企業(yè)不符合上文中提到的 6個私有訓(xùn)練的基本要求，讓模型能夠適應(yīng)企業(yè)的私有代碼仍然是我們需要解決的問題。
企業(yè)需要的是定制化大模型應(yīng)用方案，而模型訓(xùn)練只是其中一條路徑而已，我們需要對所有可行的技術(shù)路線有充分認(rèn)知，才能找到更加高效、可擴展、經(jīng)濟可行的最適合企業(yè)的方案。
下圖我們整理的 大模型應(yīng)用的工程能力建設(shè) 整體思路：
構(gòu)建大模型應(yīng)用是一個典型的迭代過程，這個構(gòu)建過程需要從應(yīng)用場景出發(fā)，先搞清楚我們要做什么，然后再去優(yōu)化大模型應(yīng)用系統(tǒng)的性能、質(zhì)量和用戶體驗。企業(yè)引入大模型更是如此，不能只把電纜接到家里，沒有電器設(shè)備，電沒有任何價值。當(dāng)前市場最大的問題是，真正能夠落地的大模型應(yīng)用太少，因為“電壓”不穩(wěn)定（大模型的輸出不穩(wěn)定），“發(fā)電廠太少”（GPT國內(nèi)用不了，開源模型和國內(nèi)商用模型在內(nèi)部部署又缺少算力），所以很多應(yīng)用場景還處于探索階段。
在眾多應(yīng)用中，AI智能編碼是少數(shù)已經(jīng)被證明的可落地的應(yīng)用場景，GitHub Copilot實際上就是全球第一款真正具備百萬級付費用戶量的大模型應(yīng)用，它本身就已經(jīng)證明了AI智能編碼確實可以大幅提高開發(fā)者的工作效率，解決實際問題。以下數(shù)據(jù)來自2022年的開發(fā)者調(diào)研 [2]
與市場上其他類型的大模型應(yīng)用不同，GitHub Copilot 在 ChatGPT 出現(xiàn)之前就已經(jīng)正式投入使用，到現(xiàn)在為止已經(jīng)迭代了近3年的時間，微軟和GitHub在這個過程中積累大量的實踐經(jīng)驗 [3]。在這次和GitHub產(chǎn)品總監(jiān)Ryan J. Salva溝通之后，對GitHub Copilot 是如何同時應(yīng)用提示詞工程、RAG和模型微調(diào)三種方法持續(xù)改進代碼生成效果的過程有了深入了解，以下是對這三種方法的優(yōu)缺點以及如何綜合利用三種方法的一些總結(jié)。
兩個優(yōu)化維度
如果你使用過任何大模型應(yīng)用，就會發(fā)現(xiàn)這類應(yīng)用有兩個特點：1) 不確定性，與傳統(tǒng)應(yīng)用不同，模型的輸出是不確定的，即使給它完全一樣的輸入，它也會給出不盡相同的答復(fù)。這種特性對于日常應(yīng)用業(yè)務(wù)OK，但是如果要在企業(yè)內(nèi)用來處理具體業(yè)務(wù)問題，就必須提高這個穩(wěn)定性。2) 靜態(tài)性，模型一旦訓(xùn)練好，就無法再補充數(shù)據(jù)，因此模型不會了解你自己組織內(nèi)部的年假規(guī)定，代碼規(guī)范。如何讓大模型掌握這些數(shù)據(jù)是另外一個需要解決的問題。
針對這兩個問題，參考本文開頭的路線圖，我們可以看到對于大模型應(yīng)用的場景優(yōu)化，有2個關(guān)鍵的優(yōu)化維度。基于這兩個維度的綜合優(yōu)化過程，最終可以推動我們持續(xù)改進大模型應(yīng)用的性能，質(zhì)量和用戶體驗。
行為優(yōu)化：這個維度主要關(guān)注模型的行為，是教會模型去按照我們希望方式做事，包括：輸出內(nèi)容的格式、語氣、偏好；甚至生成固定格式的請求以便調(diào)用其他服務(wù)。這個維度主要解決模型輸出形式上的穩(wěn)定性。
上下文優(yōu)化：這個緯度主要關(guān)注私域數(shù)據(jù)，是讓模型知道它所不知道的事情，包括：模型訓(xùn)練中從未見過的數(shù)據(jù)，比如內(nèi)部代碼、文檔、規(guī)范、策略等。這個維度主要解決模型輸出內(nèi)容上的相關(guān)性。
科技一般指科學(xué)技術(shù)。社會上習(xí)慣于把科學(xué)和技術(shù)連在一起，統(tǒng)稱為科學(xué)技術(shù)。統(tǒng)稱為科學(xué)技術(shù)，簡稱科技。實際二者既有密切聯(lián)系，又有重要區(qū)別。
三個優(yōu)化方法
提示詞工程，RAG和模型微調(diào)三種方法，可以分別解決輸出形式上的穩(wěn)定性和內(nèi)容上的相關(guān)性問題，但是不同的方法對這兩個問題也有不同的側(cè)重點。以下分別解釋說明。
方法1 - 提示工程（Prompt Engineering）
這是最經(jīng)濟可行，也是見效最快的方式；在生成式AI（GenAI）這個領(lǐng)域中大家經(jīng)常聽說的 零樣本/多樣本學(xué)習(xí)（Zero-short/Few-short learning）或者 上下文引導(dǎo)學(xué)習(xí)（in-context learnning）其實都是提示詞工程中的一些具體方法和技巧。
在實際應(yīng)用中，應(yīng)該首先考慮使用提示工程的方式優(yōu)化大模型應(yīng)用，這是成本最低，見效最快的方式。提示詞工程可以同時為模型補充上下文（上下文優(yōu)化）和優(yōu)化模型的行為（行為優(yōu)化）。因此提示詞工程可以同時在以上2個維度上幫助我們提升模型的性能、質(zhì)量和用戶體驗，讓我們可以更快達到目標(biāo)。對任何應(yīng)用場景，我們都不建議在還沒有嘗試提示工程的前提下就開始引入RAG或者微調(diào)。
在AISE和SmartCode系統(tǒng)的研發(fā)過程中，我們已經(jīng)形成一個標(biāo)準(zhǔn)化的優(yōu)化流程，那就是：先定義好一個應(yīng)用場景，然后首先進行提示詞的調(diào)試，只有當(dāng)提示詞工程無法達到預(yù)期效果時才會引入RAG和微調(diào)。另外，因為大模型的應(yīng)用場景眾多，用戶會不停提出各種類型的場景需求，最佳的解決方案是將提示工程的能力直接賦予用戶。簡單來說，提供用戶可自助創(chuàng)建的提示詞模板的功能模塊，并允許用戶自己在內(nèi)部進行分享這些模板，最后對模板的使用情況進行監(jiān)控，將那些有共性的模板提升為系統(tǒng)級甚至內(nèi)置的模板。很多時候，用戶經(jīng)過摸索可以很快構(gòu)建出高效的提示詞解決自己的問題。而作為應(yīng)用系統(tǒng)來說，我們需要提供的是這種能力，而不是將各種提示詞都封裝起來不讓用戶去碰。提示詞模板本身就是一種和大模型溝通的工具，用戶在問題驅(qū)動下構(gòu)建出的模板非常簡單高效。
當(dāng)然，提示詞模板也可能變得非常復(fù)雜，當(dāng)你發(fā)現(xiàn)自己構(gòu)建的模板越來越長，越來越復(fù)雜，但是仍然無法滿足要求。這就是引入RAG或者微調(diào)的信號。
方法2 - 檢索增強式內(nèi)容生成（RAG - Retrieval Augmented Generation）
RAG并不是某種系統(tǒng)/工具/產(chǎn)品，RAG是一種為模型補充知識的方法。首先，任何的大模型一旦訓(xùn)練完成就變成了一個靜態(tài)的文件，它只存儲了在訓(xùn)練過程中提供給它的知識（數(shù)據(jù)）。因此，當(dāng)你問ChatGPT自己公司內(nèi)部有關(guān)年假的相關(guān)規(guī)定，它必定無法準(zhǔn)確回答，而且還會給出誤導(dǎo)性的答案。
為了解決這個問題，最簡單的方式就是先告訴大模型這些規(guī)定，然后再讓它回答。這種方式就是提示詞工程中的多樣本學(xué)習(xí)（few-short learning）。同時，大模型是沒有記憶的，你提出的每一個問題其實對他來說都是全新的問題。你可能會覺得ChatGPT是有記憶的，這是因為 ChatGPT 本身就是一個大模型應(yīng)用（它背后的模型是GPT系列模型，包括：GPT 3.5， GPT4， DALL-E等）OpenAI本身在ChatGPT這個應(yīng)用層上開發(fā)了大量的功能讓用戶可以更友好的和這些模型進行交互。因此，ChatGPT會幫助用戶存儲對話歷史，并在你發(fā)送新的問題的時候?qū)v史記錄插入對話消息中，這樣模型才知道你之前跟他說過的內(nèi)容。在我們使用ChatGPT的過程中，它后面的大模型其實并不知道在和誰進行對話，而是機械快速的處理著一次次完全互不相干的請求。回到模型記憶的問題，ChatGPT的這種做法問題也很明顯，當(dāng)歷史消息太多時，消息長度會超出模型能夠處理的窗口大小，從而引發(fā)上下文丟失的問題，當(dāng)你持續(xù)和ChatGPT對話時，會發(fā)現(xiàn)他會逐漸遺忘之前的信息，就是這個原因。
當(dāng)我們需要為模型提供更多上下文的時候，就需要用到RAG技術(shù)。RAG是在給模型發(fā)送消息之前首先進行內(nèi)容檢索，從其他數(shù)據(jù)源把相關(guān)的數(shù)據(jù)先提取出來，然后插入到當(dāng)前對話消息中給到模型，這樣就解決了既要讓模型知曉大量它不知道的知識，又避免消息窗口不夠的局限。
你可能會問，你這里沒有提到數(shù)據(jù)嵌入（embedding）和向量數(shù)據(jù)庫，也能叫做RAG嗎？實際上，只要通過檢索的方式為模型補充了上下文數(shù)據(jù)，就是一種RAG的實現(xiàn)。數(shù)據(jù)嵌入和向量數(shù)據(jù)庫只是提供了一種基于語義搜索的數(shù)據(jù)檢索方式，雖然這種方式和當(dāng)前的生成式AI技術(shù)有很緊密的聯(lián)系，但這并不是RAG技術(shù)的必要組成部分。
方法3 - 微調(diào) (Fine-tuning）
現(xiàn)在業(yè)界有各種不同的說法，比如：遷移訓(xùn)練（Transfer training），再訓(xùn)練（re-training），微調(diào)（fine-tuning）。甚至很多人會將數(shù)據(jù)嵌入（embedding）也稱為訓(xùn)練，這其實是一種誤導(dǎo)。微調(diào)之所以稱為微調(diào)，就是因為微調(diào)不是從零開始，是基于一個預(yù)訓(xùn)練好的基礎(chǔ)模型通過繼續(xù)訓(xùn)練來調(diào)整模型行為的方式來完成的。這個過程所使用的數(shù)據(jù)量遠(yuǎn)遠(yuǎn)小于預(yù)訓(xùn)練模型所需要的數(shù)據(jù)量（基本在基礎(chǔ)訓(xùn)練量的1%左右 [5]），只需要能夠可以在一定程度上改變模型的行為就夠了。微調(diào)的作用主要是對模型的行為進行調(diào)整，雖然也可以通過這個過程為模型補充數(shù)據(jù)，但是并不能保證模型就一定會按照你補充的數(shù)據(jù)回答問題，因為模型并不是一個確定性系統(tǒng)。這種調(diào)整需要構(gòu)建在模型本身已經(jīng)具備的能力上，這個過程和我們所說的熟能生巧和舉一反三的過程很像。
我們以小學(xué)生要學(xué)習(xí)二元一次方程的解法為例，要學(xué)習(xí)二元一次方程那么首先需要學(xué)會基本的數(shù)字，大小的概念和基本的運算能力。這個獲得基礎(chǔ)能力的過程有點像預(yù)訓(xùn)練基礎(chǔ)模型，當(dāng)小朋友做了足夠多的基礎(chǔ)運算題目以后，會對基礎(chǔ)運算產(chǎn)生認(rèn)知能力。有了這個基礎(chǔ)認(rèn)知能力，再通過一些例子幫助小朋友建立對未知數(shù)的認(rèn)知，同時配合一些練習(xí)來使用未知數(shù)和整數(shù)、小數(shù)、分?jǐn)?shù)這些基礎(chǔ)數(shù)字混合以后進行運算，這樣小朋友就會產(chǎn)生對二元一次方程的認(rèn)知能力。后面這個過程其實就是微調(diào)過程。我們在學(xué)習(xí)數(shù)學(xué)的過程中會發(fā)現(xiàn)，自己在后來掌握更加復(fù)雜的運算方式所需要的練習(xí)數(shù)量會逐步減少。但是無論怎樣，即使你的數(shù)學(xué)基礎(chǔ)再好，要掌握一種新的運算都是需要一定練習(xí)量的。
機器學(xué)習(xí)技術(shù)作為生成式AI的基礎(chǔ)，其實就是建立在模仿人類認(rèn)知的基礎(chǔ)上構(gòu)建的。
對模型進行微調(diào)最重要的是數(shù)據(jù)的準(zhǔn)備和處理，你需要對于自己的微調(diào)目標(biāo)有清晰的認(rèn)知，微調(diào)工程師需要充分理解每一條數(shù)據(jù)應(yīng)該有怎樣的結(jié)果，因為所有的訓(xùn)練數(shù)據(jù)都是為了讓模型去模仿，以便可以在生成下一個token的時候增強你所希望生成內(nèi)容的概率。從這個角度看，僅僅具備數(shù)據(jù)科學(xué)背景的工程師是不足以完成特定領(lǐng)域模型微調(diào)的，這個團隊必須同時具備數(shù)據(jù)科學(xué)背景和微調(diào)相關(guān)的領(lǐng)域知識才能有效完成微調(diào)操作，比如：在 AI輔助智能編碼領(lǐng)域，就需要數(shù)據(jù)科學(xué)工程師和軟件工程/DevOps工程師配合。
如何選擇提示工程，RAG或者微調(diào)
這3個方法不是非此即彼的關(guān)系，而是相互配合的關(guān)系。對于任何問題，我們都建議將提示工程的方式作為起點，當(dāng)經(jīng)過一段時間的優(yōu)化以后，如果發(fā)現(xiàn)提示詞已經(jīng)變得非常復(fù)雜，甚至模板內(nèi)容都已經(jīng)快要占滿整個模型輸入窗口，但是仍然無法獲得穩(wěn)定的模型輸出，那么就應(yīng)該考慮采用微調(diào)或者RAG來解決問題了。
判斷后續(xù)路線的標(biāo)準(zhǔn)其實也不復(fù)雜，我們只需要關(guān)注提示工程產(chǎn)出的提示詞模板的一些特性就可以做出明確的判斷
-
如果在模板中大部分的內(nèi)容是模型不知道的知識，這些知識的內(nèi)容又來自其他的數(shù)據(jù)源，知識內(nèi)容不停變動，以至于你不得不創(chuàng)建多個不同模板來實現(xiàn)不同場景，那么應(yīng)該開始引入RAG進行下一步的優(yōu)化。
-
如果模板中的內(nèi)容大部分是各種格式的示例，你的目的也是希望模型能夠模仿這些示例來輸出內(nèi)容，但是即便這些示例已經(jīng)占滿了模板，模型輸出仍然不夠穩(wěn)定，那么應(yīng)該開始引入微調(diào)進行下一步的優(yōu)化。
提示工程可以同時解決知識和行為的問題，但是會受限于模型數(shù)據(jù)窗口大小；RAG能解決知識補充問題但是不擅長改變模型行為，微調(diào)可以改變模型行為但是不適合為模型補充知識。
復(fù)雜的提示詞還會消耗大量token，造成模型響應(yīng)速度降低（如果使用按token收費的模型服務(wù)，還會造成成本增加），采用微調(diào)方式可以將特定任務(wù)固化在模型中，后續(xù)調(diào)用的速度會大幅提升，也更加節(jié)省token。不過，微調(diào)過程會一次性產(chǎn)生大額成本投入，更適合那些高頻的固定任務(wù)。在 AI輔助智能編碼 領(lǐng)域，我們一般會針對代碼解釋，代碼糾錯，單元測試生成這些場景進行模型微調(diào)以實現(xiàn)更優(yōu)化的性能，輸出穩(wěn)定性和更友好的輸出格式。
在具體應(yīng)用場景的實踐中，應(yīng)該根據(jù)特定場景的需要組合使用3種方法，具體是否要走到RAG，微調(diào)或者RAG+微調(diào)哪個階段才能達到目標(biāo)，要根據(jù)應(yīng)用驗證的結(jié)果而定。對于日常使用來說，用戶感覺好用往往就可以作為完整結(jié)果了。但對于企業(yè)應(yīng)用的工程化方法，我們需要有可評估的量化標(biāo)準(zhǔn)才行。
大模型應(yīng)用驗證（測試）
大模型應(yīng)用效果的驗證和傳統(tǒng)軟件的評估效果不同，因為大模型本身的通用性和非確定性，造成即便是一個特定場景，我們無法窮舉所有的輸入可能性；對于同樣的輸入，我們也無法確定模型的標(biāo)準(zhǔn)化輸出。類似這樣的通用性和不確定的特點決定了傳統(tǒng)的測試方法對大模型應(yīng)用是無法直接使用的，我們必須探索一種適合大模型應(yīng)用的驗證/測試方式。
以下圖這個場景為例，我們給模型輸入了完全一樣的提示詞：“如何計算等邊三角形的面積，請使用Python代碼生成一個計算方法”。但是模型給出的輸出卻不完全一致，如果我們仔細(xì)閱讀模型的輸出，會發(fā)現(xiàn)雖然輸出的格式，內(nèi)容有所區(qū)別，但是關(guān)鍵部分和核心內(nèi)容的含義卻是一致的。注意：這個測試使用的是同一個模型。
-
傳統(tǒng)應(yīng)用是確定性的：同樣的輸入一定有同樣的輸出
-
大模型應(yīng)用是不確定性的：同樣的輸入不一定有同樣的輸出，不同的輸入也可以有同樣的輸出，輸出的內(nèi)容雖然不相等但是含義一致。
充分認(rèn)識到大模型應(yīng)用與傳統(tǒng)應(yīng)用的不同，我們才能有針對性的對傳統(tǒng)測試、驗收方式進行重構(gòu)，以便適應(yīng)大模型應(yīng)用本身的特點。傳統(tǒng)軟件工程中的自動化測試，CI/CD流水線，單元測試等實踐對大模型應(yīng)用仍然有效。但是我們需要重構(gòu)這些流程中所使用的工具和方法。比如：針對大模型應(yīng)用的單元測試，我們?nèi)匀豢梢圆捎?define-exec-eval 的模式進行用例的設(shè)計，但是其中define和eval步驟的實現(xiàn)方式都需要進行重構(gòu)：
-
Define - 測試目標(biāo)的定義往往需要我們盡量窮舉所有的測試場景，這一點在傳統(tǒng)軟件工程上是可行的，因為系統(tǒng)本身是確定性；但是在大模型應(yīng)用上窮舉法就是不可行的，因為大模型應(yīng)用所面對的場景和傳統(tǒng)應(yīng)用場景有非常大的不同。比如：大模型應(yīng)用可以幫助我們分析軟件需求，這樣一個場景就是無法通過傳統(tǒng)軟件工程方法來窮舉的，我們必須尋求其他辦法；同樣，在傳統(tǒng)軟件應(yīng)用上，我們也不會提出這類的應(yīng)用場景，因為依靠常識就知道這種場景是不可行的。
-
Eval - 在測試驗證環(huán)節(jié)上，這個區(qū)別更加明顯。因為大模型輸出不確定性屬性，同樣的輸入會產(chǎn)生每次都不一致的輸出，這些輸出雖然在形式/用詞/格式上有所區(qū)別，他們之間的語義上又存在聯(lián)系。傳統(tǒng)測試基于等式的驗證方式明顯無法適應(yīng)這樣的輸出特性。
大模型的應(yīng)用驗證是AI時代帶來的全新的軟件工程問題，業(yè)界普遍有3種實現(xiàn)路徑：基于統(tǒng)計學(xué)算法的驗證方式，基于模型的驗證方式和人工驗證。基于統(tǒng)計的驗證方式使用一些算法來驗證模型輸出與預(yù)期結(jié)果的相似度，有代表性的方法包括：BLEU (BiLingual Evaluation Understudy) ，ROUGE (Recall-Oriented Understudy for Gisting Evaluation) ，METEOR (Metric for Evaluation of Translation with Explicit Ordering)，Levenshtein distance 等等。基于模型的驗證方法采用大模型來驗證大模型的輸出，相比基于統(tǒng)計的驗證方法提供更好的普適性，但是在系統(tǒng)構(gòu)建，運行效率和成本上會帶來很大挑戰(zhàn)，有代表性的框架包括：RAGUS，DeepEval 等。人工驗證就是讓測試人員或者用戶直接對模型輸出進行反饋和打分，雖然這種方法效率更低，實際上卻是現(xiàn)在最準(zhǔn)確的評估方式，畢竟大模型應(yīng)用的最終用戶是人，人本身的智能足以應(yīng)對模型輸出的不確定性。
另外，針對RAG和微調(diào)的兩種路徑，驗證的方式和采用的指標(biāo)也會有所不同，以下列出一些常見的驗證指標(biāo)，供大家參考：
大模型應(yīng)用驗證是 SE4AI 領(lǐng)域的一個比較有代表性的工程問題，在面向大模型應(yīng)用的交付流水線中，其實還有很多其他的環(huán)節(jié)也需要采用同樣的思路進行重構(gòu)。
小結(jié)
本文延續(xù)模型私有化訓(xùn)練的問題，對當(dāng)前比較常見的大模型應(yīng)用優(yōu)化方式：提示工程，RAG和微調(diào)三種方法的優(yōu)缺點進行了分析和比較。我們需要了解這三種方式并不是孤立互斥的，而是互相推動的，企業(yè)大模型應(yīng)用最終的形態(tài)往往是這三種方法綜合使用的結(jié)果。
我們誠摯邀請您出席5月25日在北京舉辦的【研發(fā)效能·創(chuàng)享大會—IDCF五周年專場】，親身體驗現(xiàn)場的交流與分享。
在大會上，本文作者徐磊老師將深入解讀《AI驅(qū)動軟件工程提升企業(yè)個性化代碼生成準(zhǔn)確率的核心實踐》，我們期待您的蒞臨，共同探討技術(shù)發(fā)展的前沿動態(tài)。
會議規(guī)模：本次大會將設(shè)有6大主題議程，1個主會場和2個分會場，預(yù)計將有300余位行業(yè)同仁參會。
我們榮幸地邀請到了徐磊、何勉、張樂、肖然、姚冬、王立杰等15位行業(yè)內(nèi)的頂尖技術(shù)專家，他們將圍繞軟件行業(yè)的最新技術(shù)、趨勢和熱點話題進行主題演講和深度討論。
會議嘉賓：徐磊，英捷創(chuàng)軟CEO/首席架構(gòu)師/微軟最有價值專家MVP/GitHub Star/GitHub Copilot中國區(qū)授權(quán)服務(wù)團隊負(fù)責(zé)人，華為云MVP，工信教考《研發(fā)效能（DevOps）工程師》認(rèn)證講師，IDCF社區(qū)聯(lián)合發(fā)起人。
分享簡介：AI驅(qū)動代碼生成已經(jīng)是被業(yè)界普遍認(rèn)可的生成式AI商業(yè)價值，大模型訓(xùn)練普遍采用開源和公開代碼進行訓(xùn)練，在未優(yōu)化的情況下難以在企業(yè)內(nèi)部達到較高的生成準(zhǔn)確率。如何提升AI編碼大模型面對企業(yè)個性化代碼時的生成準(zhǔn)確率是這一領(lǐng)域的難點問題。
本次分享將從如何提高生成代碼準(zhǔn)確率話題展開，深入探討個性化訓(xùn)練和RAG技術(shù)，在解決企業(yè)個性化代碼生成準(zhǔn)確率上的優(yōu)缺點和技術(shù)細(xì)節(jié)。通過AISE在大型金融機構(gòu)內(nèi)的實際使用案例和反饋說明企業(yè)級AI輔助研發(fā)產(chǎn)品的落地核心要點和收益。
??來現(xiàn)場聽連續(xù)18年微軟MVP（最有價值專家）徐磊老師的分享
??點擊文末，閱讀原文，或掃碼報名。早鳥優(yōu)惠、企業(yè)團購，此時不搶更待何時？？
售票說明:
1.坐席有限,先到先得。
2.請掃描二維碼或點擊“閱讀原文”購票。
3.可添加工作人員微信：小柒17822079720，隨時掌握大會動態(tài)。
