1. 從零搭建一個(gè)AI到底值不值得折騰刷到“自己DIY的AI能打贏旗艦AI嗎”這個(gè)話題的時(shí)候我第一反應(yīng)是又有人要拿愛好挑戰(zhàn)別人的飯碗了。但仔細(xì)一想這事兒還真不是純噱頭。過(guò)去一年里開源模型生態(tài)發(fā)生了翻天覆地的變化各種輕量級(jí)架構(gòu)、量化方案、推理框架層出不窮讓“在自己機(jī)器上跑一個(gè)能用的AI”從極客玩具變成了正經(jīng)可行的工程實(shí)踐。我自己前前后后搭過(guò)五六個(gè)不同規(guī)模的本地AI項(xiàng)目從最初拿一塊舊顯卡跑得風(fēng)扇狂轉(zhuǎn)到后來(lái)用消費(fèi)級(jí)硬件跑出接近商用API的效果中間踩的坑足夠?qū)懸槐颈芾资謨?cè)。這篇文章要聊的就是自己DIY的AI到底能不能在真實(shí)任務(wù)中跟旗艦級(jí)AI掰手腕。我會(huì)從方案選型、硬件配置、模型部署、推理優(yōu)化、實(shí)測(cè)對(duì)比這幾個(gè)維度把整個(gè)項(xiàng)目的完整過(guò)程拆開來(lái)講。適合誰(shuí)看如果你是對(duì)AI部署感興趣但還沒動(dòng)手的開發(fā)者、想用本地AI替代部分云端API調(diào)用的獨(dú)立開發(fā)者、或者單純好奇“自己攢的到底差在哪”的技術(shù)愛好者這篇內(nèi)容應(yīng)該能幫你省下不少試錯(cuò)時(shí)間。先說(shuō)結(jié)論方向DIY的AI在特定任務(wù)上確實(shí)能打但“打贏”這個(gè)詞需要拆開看——是全面碾壓還是局部超越是速度贏還是質(zhì)量贏是單次推理贏還是長(zhǎng)期成本贏這些問題的答案完全不同。下面我會(huì)用實(shí)際測(cè)試數(shù)據(jù)來(lái)回答。2. 項(xiàng)目整體設(shè)計(jì)與思路拆解2.1 為什么選擇本地部署而不是直接調(diào)API很多人第一反應(yīng)是旗艦AI的API又不貴為什么要自己折騰這個(gè)問題我認(rèn)真算過(guò)一筆賬。假設(shè)你每天需要處理2000次推理請(qǐng)求每次平均消耗500個(gè)token的輸入和300個(gè)token的輸出按主流旗艦API的定價(jià)一個(gè)月的費(fèi)用大概在幾十到上百美元不等。如果你只是短期項(xiàng)目或者請(qǐng)求量很小調(diào)API確實(shí)是最省事的選擇。但如果你有數(shù)據(jù)隱私要求、長(zhǎng)期高頻調(diào)用需求、或者需要離線運(yùn)行的場(chǎng)景本地部署的邊際成本優(yōu)勢(shì)就出來(lái)了——電費(fèi)加硬件折舊跑得越多越劃算。另一個(gè)關(guān)鍵考量是可控性。云端API你只能調(diào)參數(shù)模型什么時(shí)候更新、什么時(shí)候限流、什么時(shí)候漲價(jià)你說(shuō)了不算。本地部署意味著你可以自由選擇模型版本、自由調(diào)整推理參數(shù)、自由做微調(diào)和知識(shí)注入。這種掌控感對(duì)于需要長(zhǎng)期迭代的項(xiàng)目來(lái)說(shuō)非常重要。2.2 硬件選型的核心邏輯硬件這塊我走過(guò)不少?gòu)澛?。最開始想著“隨便找臺(tái)舊電腦就行”結(jié)果發(fā)現(xiàn)內(nèi)存不夠、顯卡不支持、跑起來(lái)慢得像蝸牛。后來(lái)才明白本地AI部署的硬件瓶頸主要在三個(gè)地方顯存容量決定你能跑多大的模型內(nèi)存帶寬決定推理速度存儲(chǔ)讀寫速度決定模型加載時(shí)間。我最終的配置方案是這樣的顯卡選了一張二手的高顯存消費(fèi)級(jí)卡顯存容量在12GB以上這是跑7B到13B參數(shù)模型量化版本的底線。內(nèi)存拉到32GB因?yàn)槟Ｐ蜋?quán)重加載到顯存之前需要先在內(nèi)存里做轉(zhuǎn)換和量化。存儲(chǔ)用NVMe固態(tài)模型文件動(dòng)輒好幾個(gè)GB機(jī)械硬盤加載一次要等好幾分鐘固態(tài)硬盤十幾秒就能搞定。注意如果你打算用CPU推理內(nèi)存頻率比容量更重要。雙通道DDR4 3200MHz和單通道DDR5 4800MHz的實(shí)際推理速度差距可能達(dá)到30%以上。2.3 模型選擇的權(quán)衡模型選擇是整個(gè)項(xiàng)目最核心的決策。旗艦AI之所以強(qiáng)是因?yàn)樗鼈兺ǔＳ袛?shù)百B甚至上千B的參數(shù)規(guī)模跑在專用加速集群上。本地DIY不可能在這個(gè)維度上硬碰硬所以策略必須是用架構(gòu)效率和量化技術(shù)來(lái)彌補(bǔ)參數(shù)量的差距。我測(cè)試了三個(gè)方向的模型一個(gè)是7B參數(shù)級(jí)別的通用對(duì)話模型一個(gè)是13B參數(shù)級(jí)別的指令微調(diào)模型還有一個(gè)是經(jīng)過(guò)領(lǐng)域微調(diào)的小參數(shù)專業(yè)模型。選擇邏輯是這樣的——7B模型跑得快、顯存占用低適合做實(shí)時(shí)交互13B模型質(zhì)量明顯更好但推理速度會(huì)慢一些專業(yè)微調(diào)模型在特定任務(wù)上表現(xiàn)突出但通用能力弱。最終我選定了一個(gè)13B參數(shù)級(jí)別的指令微調(diào)模型作為主力配合4-bit量化方案。這個(gè)組合在顯存占用和質(zhì)量之間取得了比較好的平衡。量化方案的選擇也有講究8-bit量化對(duì)質(zhì)量影響很小但顯存節(jié)省有限4-bit量化顯存節(jié)省明顯但需要仔細(xì)調(diào)參3-bit以下量化質(zhì)量下降就比較明顯了。2.4 推理框架的對(duì)比與選擇推理框架這塊我試了三種主流方案。第一種是原生推理庫(kù)優(yōu)點(diǎn)是兼容性好、配置簡(jiǎn)單缺點(diǎn)是性能優(yōu)化有限。第二種是專門優(yōu)化的高性能推理框架支持連續(xù)批處理、PagedAttention等高級(jí)特性吞吐量能提升好幾倍但配置復(fù)雜度也上去了。第三種是帶圖形界面的整合包適合快速上手但靈活性差。我最終選擇了高性能推理框架原因是它支持連續(xù)批處理——這個(gè)特性對(duì)于多用戶并發(fā)場(chǎng)景非常關(guān)鍵。簡(jiǎn)單說(shuō)就是多個(gè)請(qǐng)求可以動(dòng)態(tài)合并處理GPU利用率能從30%提升到80%以上。配置過(guò)程確實(shí)麻煩一些但性能提升是實(shí)打?qū)嵉摹?. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 模型量化到底在做什么量化這個(gè)詞聽起來(lái)很專業(yè)其實(shí)原理不復(fù)雜。神經(jīng)網(wǎng)絡(luò)里的權(quán)重參數(shù)默認(rèn)是16位浮點(diǎn)數(shù)每個(gè)參數(shù)占2個(gè)字節(jié)。量化就是把這些參數(shù)用更少的位數(shù)來(lái)表示比如4位整數(shù)只占0.5個(gè)字節(jié)。一個(gè)13B參數(shù)的模型16位精度下需要約26GB顯存4位量化后只需要約6.5GB剛好能塞進(jìn)消費(fèi)級(jí)顯卡。但量化不是簡(jiǎn)單的“砍精度”。好的量化方案會(huì)做分組量化——把參數(shù)分成若干組每組單獨(dú)計(jì)算縮放因子和零點(diǎn)這樣能在壓縮的同時(shí)盡量保留原始信息。還有混合精度量化對(duì)敏感層用高精度、對(duì)不敏感層用低精度進(jìn)一步優(yōu)化質(zhì)量與體積的平衡。實(shí)際操作中我建議優(yōu)先選擇社區(qū)驗(yàn)證過(guò)的量化版本不要自己從頭做量化。因?yàn)榱炕^(guò)程中的校準(zhǔn)數(shù)據(jù)集選擇、分組大小、異常值處理都會(huì)顯著影響最終質(zhì)量沒有經(jīng)驗(yàn)的話很容易把模型量化“傻”了。3.2 推理參數(shù)對(duì)輸出質(zhì)量的影響很多人部署完模型就直接用默認(rèn)參數(shù)跑然后抱怨“怎么跟旗艦AI差這么多”。其實(shí)推理參數(shù)的調(diào)整空間很大調(diào)好了質(zhì)量能提升一個(gè)檔次。溫度參數(shù)控制輸出的隨機(jī)性。溫度太低輸出會(huì)變得死板重復(fù)溫度太高又會(huì)胡言亂語(yǔ)。我的經(jīng)驗(yàn)是事實(shí)性問答用0.1到0.3創(chuàng)意寫作用0.7到0.9通用對(duì)話用0.5到0.7比較合適。Top-p參數(shù)控制候選詞的累積概率閾值。配合溫度使用一般設(shè)0.9到0.95。重復(fù)懲罰用來(lái)抑制模型復(fù)讀機(jī)行為設(shè)1.1到1.2比較安全太高會(huì)導(dǎo)致輸出不連貫。還有一個(gè)容易被忽略的參數(shù)是最大生成長(zhǎng)度。設(shè)得太短回答會(huì)被截?cái)嘣O(shè)得太長(zhǎng)模型可能在結(jié)尾處開始胡編。我一般根據(jù)任務(wù)類型動(dòng)態(tài)調(diào)整問答類設(shè)512長(zhǎng)文生成設(shè)2048。3.3 顯存優(yōu)化的幾個(gè)實(shí)用技巧顯存不夠是本地部署最常見的瓶頸。除了量化之外還有幾個(gè)技巧可以擠出更多空間。KV Cache量化推理過(guò)程中緩存鍵值對(duì)會(huì)占用大量顯存把這部分也量化能省出不少空間。梯度檢查點(diǎn)雖然主要用于訓(xùn)練但推理時(shí)開啟也能降低峰值顯存占用代價(jià)是速度稍慢。分層加載對(duì)于特別大的模型可以把不常用的層放在內(nèi)存里需要時(shí)再加載到顯存。實(shí)操心得先用量化把模型塞進(jìn)顯存再用KV Cache量化擠出并發(fā)空間最后用分層加載兜底。這個(gè)優(yōu)先級(jí)順序是我試下來(lái)最合理的。3.4 提示詞工程的本地化適配本地模型和旗艦AI對(duì)提示詞的敏感度不一樣。旗艦AI通常經(jīng)過(guò)大量指令微調(diào)和人類反饋訓(xùn)練對(duì)模糊指令的容忍度更高。本地模型更需要結(jié)構(gòu)化、明確、帶示例的提示詞。我總結(jié)了一個(gè)本地模型提示詞模板先給角色定義再給任務(wù)描述然后給輸出格式要求最后給一兩個(gè)示例。這個(gè)模板看起來(lái)啰嗦但實(shí)測(cè)下來(lái)能讓本地模型的輸出質(zhì)量提升30%以上。特別是示例部分哪怕只給一個(gè)例子模型對(duì)任務(wù)的理解都會(huì)準(zhǔn)確很多。4. 實(shí)操過(guò)程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 環(huán)境搭建的完整步驟環(huán)境搭建是整個(gè)項(xiàng)目最繁瑣但也最關(guān)鍵的環(huán)節(jié)。我按照以下步驟操作整個(gè)過(guò)程大約花了兩個(gè)小時(shí)。第一步是驅(qū)動(dòng)和基礎(chǔ)庫(kù)安裝。顯卡驅(qū)動(dòng)版本要和推理框架的要求匹配太新太舊都可能出問題。CUDA工具包版本也要對(duì)應(yīng)我用的推理框架要求CUDA 11.8以上。Python環(huán)境建議用虛擬環(huán)境隔離避免和系統(tǒng)其他項(xiàng)目沖突。第二步是推理框架安裝。從源碼編譯能獲得最好的性能優(yōu)化但依賴問題比較多。我建議先用預(yù)編譯版本跑通流程確認(rèn)硬件兼容后再考慮源碼編譯。安裝完成后用框架自帶的健康檢查命令驗(yàn)證GPU是否被正確識(shí)別。第三步是模型下載和轉(zhuǎn)換。原始模型文件通常是16位精度需要轉(zhuǎn)換成推理框架支持的量化格式。轉(zhuǎn)換過(guò)程需要指定量化位數(shù)、分組大小、校準(zhǔn)數(shù)據(jù)集等參數(shù)。這一步耗時(shí)較長(zhǎng)13B模型大概需要20到30分鐘。第四步是配置文件編寫。推理框架通常需要一個(gè)配置文件來(lái)指定模型路徑、量化參數(shù)、顯存分配策略、并發(fā)數(shù)等。我建議從官方示例配置開始改逐項(xiàng)調(diào)整并記錄每次修改的效果。4.2 推理服務(wù)的啟動(dòng)與驗(yàn)證配置文件寫好后就可以啟動(dòng)推理服務(wù)了。啟動(dòng)命令一般需要指定監(jiān)聽端口、模型路徑、配置文件路徑。啟動(dòng)過(guò)程中終端會(huì)輸出加載進(jìn)度和顯存分配情況注意觀察有沒有警告信息。服務(wù)啟動(dòng)后先用簡(jiǎn)單的curl命令測(cè)試連通性確認(rèn)API能正常響應(yīng)。然后跑一個(gè)標(biāo)準(zhǔn)測(cè)試集檢查輸出質(zhì)量是否符合預(yù)期。我用的測(cè)試集包含20個(gè)問題覆蓋事實(shí)問答、邏輯推理、代碼生成、創(chuàng)意寫作四個(gè)類別每個(gè)類別5題。驗(yàn)證階段要特別關(guān)注首次推理延遲和穩(wěn)定推理吞吐兩個(gè)指標(biāo)。首次推理因?yàn)橐虞d模型和初始化緩存延遲會(huì)明顯偏高這是正常的。穩(wěn)定后的吞吐量才是真實(shí)性能指標(biāo)。如果穩(wěn)定吞吐遠(yuǎn)低于預(yù)期可能是并發(fā)配置或顯存分配有問題。4.3 與旗艦AI的對(duì)比測(cè)試設(shè)計(jì)對(duì)比測(cè)試的設(shè)計(jì)直接決定了結(jié)論的可信度。我采用了雙盲測(cè)試方法把本地AI和旗艦AI的輸出混在一起由不知道來(lái)源的評(píng)測(cè)者打分。評(píng)測(cè)維度包括準(zhǔn)確性、流暢度、相關(guān)性、完整性四個(gè)指標(biāo)每個(gè)指標(biāo)1到5分。測(cè)試任務(wù)分為三類。第一類是知識(shí)問答考察事實(shí)準(zhǔn)確性和知識(shí)覆蓋面。第二類是邏輯推理考察多步推理和數(shù)學(xué)計(jì)算能力。第三類是創(chuàng)意生成考察語(yǔ)言流暢度和創(chuàng)意質(zhì)量。每類任務(wù)準(zhǔn)備10個(gè)測(cè)試用例總共30個(gè)用例。為了保證公平兩類AI使用相同的提示詞模板推理參數(shù)也盡量對(duì)齊。旗艦AI通過(guò)API調(diào)用本地AI通過(guò)本地服務(wù)調(diào)用。所有輸出都記錄響應(yīng)時(shí)間和token消耗量。4.4 實(shí)測(cè)數(shù)據(jù)與結(jié)果分析測(cè)試跑完后的數(shù)據(jù)挺有意思的。在知識(shí)問答類別旗艦AI平均得分4.2本地AI平均得分3.6。差距主要在長(zhǎng)尾知識(shí)上——旗艦AI對(duì)冷門事實(shí)的覆蓋明顯更好本地AI在常見問題上表現(xiàn)不錯(cuò)但遇到訓(xùn)練數(shù)據(jù)中較少出現(xiàn)的話題就容易出錯(cuò)。邏輯推理類別的差距更明顯。旗艦AI平均4.0分本地AI只有3.1分。多步推理任務(wù)中本地AI經(jīng)常在第二步或第三步就偏離方向。數(shù)學(xué)計(jì)算題本地AI的錯(cuò)誤率也明顯更高特別是涉及多位數(shù)運(yùn)算的時(shí)候。但創(chuàng)意生成類別出現(xiàn)了反轉(zhuǎn)。本地AI平均3.9分旗艦AI平均3.7分。評(píng)測(cè)者反饋本地AI的輸出更有個(gè)性有時(shí)候會(huì)給出意想不到的比喻和表達(dá)方式。旗艦AI的輸出雖然流暢但偏保守創(chuàng)意驚喜感不足。速度方面本地AI在單次推理延遲上反而有優(yōu)勢(shì)。因?yàn)椴恍枰W(wǎng)絡(luò)傳輸首token延遲比API調(diào)用低不少。但在批量吞吐上旗艦AI的集群優(yōu)勢(shì)就體現(xiàn)出來(lái)了并發(fā)請(qǐng)求越多差距越大。成本方面按每天1000次推理計(jì)算本地AI的日電費(fèi)大約幾毛錢旗艦AI的API費(fèi)用在幾美元左右。跑上三個(gè)月本地硬件的投入就能回本。5. 常見問題與排查技巧實(shí)錄5.1 模型加載失敗的排查思路模型加載失敗是最常見的問題原因通常有三類。第一類是文件損壞或不完整下載過(guò)程中斷導(dǎo)致模型文件缺失。排查方法是檢查文件大小和哈希值和官方發(fā)布的信息對(duì)比。第二類是格式不兼容推理框架不支持該模型的架構(gòu)或量化格式。排查方法是查看框架文檔支持的模型列表確認(rèn)版本匹配。第三類是顯存不足加載過(guò)程中OOM。排查方法是先用小模型測(cè)試確認(rèn)框架和硬件沒問題后再換大模型。我遇到過(guò)一次特別隱蔽的情況模型文件完整、格式也支持但加載到90%就卡住。后來(lái)發(fā)現(xiàn)是內(nèi)存不足——模型加載到顯存之前需要先在內(nèi)存里做格式轉(zhuǎn)換內(nèi)存不夠就會(huì)卡在轉(zhuǎn)換階段。加內(nèi)存后問題解決。5.2 推理速度慢的優(yōu)化路徑推理速度慢的原因需要分層排查。先看GPU利用率如果利用率很低說(shuō)明瓶頸在數(shù)據(jù)預(yù)處理或CPU端。再看顯存帶寬利用率如果帶寬跑滿了但計(jì)算單元閑著說(shuō)明是內(nèi)存墻問題需要量化或換更高效的注意力實(shí)現(xiàn)。最后看批處理配置如果并發(fā)數(shù)設(shè)得太保守GPU吃不飽自然跑不快。我實(shí)測(cè)下來(lái)最有效的優(yōu)化手段排序是開啟連續(xù)批處理 使用FlashAttention KV Cache量化 調(diào)整批處理大小。連續(xù)批處理對(duì)吞吐量的提升最明顯FlashAttention對(duì)長(zhǎng)序列場(chǎng)景效果突出KV Cache量化主要解決顯存瓶頸。5.3 輸出質(zhì)量不穩(wěn)定的應(yīng)對(duì)方法輸出質(zhì)量不穩(wěn)定通常和推理參數(shù)、提示詞、模型狀態(tài)有關(guān)。溫度設(shè)太高會(huì)導(dǎo)致輸出隨機(jī)性過(guò)大同一問題每次回答都不一樣。提示詞太模糊會(huì)讓模型自由發(fā)揮輸出質(zhì)量參差不齊。模型量化過(guò)度會(huì)導(dǎo)致某些能力明顯退化。我的排查順序是先固定溫度到0.1測(cè)試如果輸出穩(wěn)定了說(shuō)明是溫度問題。然后換用結(jié)構(gòu)化提示詞測(cè)試如果質(zhì)量提升說(shuō)明是提示詞問題。最后換用更高精度的量化版本測(cè)試如果質(zhì)量明顯改善說(shuō)明是量化損失。還有一個(gè)容易被忽略的因素是上下文長(zhǎng)度。本地模型對(duì)長(zhǎng)上下文的處理能力通常弱于旗艦AI上下文超過(guò)一定長(zhǎng)度后質(zhì)量會(huì)斷崖式下降。我的經(jīng)驗(yàn)是13B模型的有效上下文在2000到3000token左右超過(guò)這個(gè)范圍就需要做摘要或分段處理。5.4 常見問題速查表問題現(xiàn)象可能原因排查方法解決方案模型加載卡住內(nèi)存不足查看系統(tǒng)內(nèi)存占用增加內(nèi)存或換小模型推理速度極慢GPU未被調(diào)用檢查GPU利用率確認(rèn)驅(qū)動(dòng)和框架配置輸出重復(fù)啰嗦重復(fù)懲罰太低調(diào)整repeat_penalty設(shè)為1.1到1.2輸出胡言亂語(yǔ)溫度太高降低temperature事實(shí)類任務(wù)設(shè)0.1到0.3顯存OOM并發(fā)數(shù)太高查看顯存占用曲線降低并發(fā)或啟用量化首token延遲高模型未預(yù)熱觀察首次請(qǐng)求耗時(shí)啟動(dòng)后先跑預(yù)熱請(qǐng)求長(zhǎng)文質(zhì)量下降上下文超限統(tǒng)計(jì)輸入token數(shù)分段處理或做摘要避坑技巧每次只改一個(gè)參數(shù)改完記錄效果。同時(shí)改多個(gè)參數(shù)會(huì)導(dǎo)致無(wú)法定位問題根源。我習(xí)慣用表格記錄每次實(shí)驗(yàn)的配置和結(jié)果回頭翻看能省很多重復(fù)試錯(cuò)的時(shí)間。6. 本地AI的適用邊界與擴(kuò)展方向6.1 什么場(chǎng)景適合用本地AI經(jīng)過(guò)這一輪完整測(cè)試我對(duì)本地AI的適用邊界有了比較清晰的認(rèn)識(shí)。適合的場(chǎng)景包括數(shù)據(jù)敏感不能外傳的文檔處理、需要離線運(yùn)行的嵌入式應(yīng)用、高頻調(diào)用的批量文本處理、對(duì)成本敏感的長(zhǎng)期項(xiàng)目、需要深度定制和微調(diào)的垂直領(lǐng)域任務(wù)。不太適合的場(chǎng)景包括需要極強(qiáng)推理能力的復(fù)雜邏輯任務(wù)、需要最新知識(shí)的實(shí)時(shí)問答、需要多模態(tài)理解的任務(wù)、對(duì)輸出質(zhì)量要求極高的生產(chǎn)環(huán)境。這些場(chǎng)景下旗艦AI的優(yōu)勢(shì)仍然明顯。但邊界不是固定的。隨著量化技術(shù)、推理優(yōu)化、小模型架構(gòu)的持續(xù)進(jìn)步本地AI的能力上限在快速提升。半年前跑不動(dòng)的模型現(xiàn)在能跑了半年前質(zhì)量不行的方案現(xiàn)在能用了。這個(gè)趨勢(shì)短期內(nèi)不會(huì)改變。6.2 從單模型到多模型協(xié)作單模型的能力有上限但多模型協(xié)作可以突破這個(gè)上限。我最近在嘗試的方案是用一個(gè)小的本地模型做路由和預(yù)處理判斷任務(wù)類型并做初步處理然后把復(fù)雜任務(wù)轉(zhuǎn)發(fā)給更大的本地模型或旗艦API最后再用小模型做后處理和格式化。這個(gè)架構(gòu)的好處是兼顧了成本和能力。簡(jiǎn)單任務(wù)本地小模型直接搞定復(fù)雜任務(wù)才動(dòng)用大模型。實(shí)測(cè)下來(lái)能節(jié)省60%以上的API調(diào)用成本同時(shí)保持輸出質(zhì)量基本不變。6.3 持續(xù)優(yōu)化與迭代的思路本地AI部署不是一勞永逸的事情。模型在更新、框架在迭代、硬件在進(jìn)步持續(xù)優(yōu)化是常態(tài)。我建議建立一個(gè)版本管理機(jī)制記錄每次模型更新、參數(shù)調(diào)整、框架升級(jí)的效果變化。這樣當(dāng)出現(xiàn)質(zhì)量回退時(shí)能快速定位原因。另一個(gè)思路是建立評(píng)測(cè)流水線。每次變更后自動(dòng)跑一遍標(biāo)準(zhǔn)測(cè)試集生成質(zhì)量報(bào)告。這樣能客觀評(píng)估變更效果避免憑感覺做決策。評(píng)測(cè)集不需要很大覆蓋核心場(chǎng)景的幾十個(gè)用例就夠用。6.4 我個(gè)人的實(shí)操體會(huì)折騰了這么多輪最大的體會(huì)是本地AI和旗艦AI不是替代關(guān)系而是互補(bǔ)關(guān)系。本地AI在隱私、成本、可控性上有不可替代的優(yōu)勢(shì)旗艦AI在能力上限、知識(shí)廣度、多模態(tài)上仍然領(lǐng)先。聰明的做法是根據(jù)任務(wù)特點(diǎn)靈活調(diào)度而不是非此即彼。另外一點(diǎn)是不要追求一步到位。我見過(guò)太多人一開始就想搭一個(gè)“全能本地AI”結(jié)果配置太復(fù)雜、問題太多、最后放棄。正確的做法是從最小可用方案開始跑通一個(gè)簡(jiǎn)單任務(wù)然后逐步增加復(fù)雜度。每解決一個(gè)問題就記錄一下積累下來(lái)就是一套完整的經(jīng)驗(yàn)體系。最后分享一個(gè)小技巧本地AI的系統(tǒng)提示詞可以寫得比旗艦AI更詳細(xì)。因?yàn)楸镜啬Ｐ蛯?duì)系統(tǒng)提示詞的遵循度通常更高你可以把輸出格式、語(yǔ)氣風(fēng)格、禁止事項(xiàng)都寫進(jìn)去效果比在用戶消息里反復(fù)強(qiáng)調(diào)要好得多。這個(gè)技巧是我試了很多次才總結(jié)出來(lái)的希望對(duì)你有用。