1. 從零搭建AI工程能力為什么“手搓一遍”比調(diào)包更值錢這兩年AI應(yīng)用開發(fā)的門檻肉眼可見地降低了。一個剛?cè)胄械拈_發(fā)者借助現(xiàn)成的框架和API可能一個下午就能跑通一個對話機(jī)器人或者一個RAG問答系統(tǒng)。但如果你真的在團(tuán)隊里帶過人、做過線上項目就會發(fā)現(xiàn)一個很尷尬的現(xiàn)象很多人能跑通Demo卻說不清楚一次推理請求背后到底發(fā)生了什么模型加載慢在哪里、顯存為什么爆了、token是怎么被切分的、向量檢索的召回率為什么上不去一問三不知?！癮i-engineering-from-scratch”這個標(biāo)題本質(zhì)上說的就是一件事把AI工程里那些被框架封裝掉的環(huán)節(jié)自己動手實(shí)現(xiàn)一遍。它不是讓你去從頭訓(xùn)練一個大模型那既不現(xiàn)實(shí)也沒必要而是讓你把推理服務(wù)、數(shù)據(jù)處理、檢索增強(qiáng)、評估監(jiān)控這些工程鏈路的核心模塊用最樸素的方式親手搭一遍。做完之后你對整個系統(tǒng)的掌控力和只會調(diào)包的人完全不在一個層次。這篇文章適合三類人一是剛轉(zhuǎn)行做AI應(yīng)用、只會調(diào)API想補(bǔ)底層認(rèn)知的開發(fā)者二是有后端或數(shù)據(jù)工程背景、想切入AI方向的工程師三是帶團(tuán)隊的技術(shù)負(fù)責(zé)人想搞清楚AI工程到底有哪些坑、該怎么給團(tuán)隊定技術(shù)規(guī)范。我會把整條鏈路的搭建思路、關(guān)鍵取舍、實(shí)測踩過的坑都攤開講盡量讓你看完就能自己動手復(fù)現(xiàn)。需要先說明一點(diǎn)下面涉及的具體參數(shù)、工具選型都是基于我在實(shí)際項目中的常見實(shí)踐給出的合理方案不是唯一答案。你要根據(jù)自己的硬件條件、數(shù)據(jù)規(guī)模、團(tuán)隊技術(shù)棧去調(diào)整重點(diǎn)是理解每一步“為什么這么做”。2. 動手之前先想清楚AI工程到底在工程什么2.1 把“模型”和“工程”分開看很多人一上來就糾結(jié)模型選型覺得模型選對了項目就成功了一半。實(shí)際做下來你會發(fā)現(xiàn)在一個真實(shí)的AI應(yīng)用里模型只是其中一個組件而且往往是相對穩(wěn)定的那個。真正消耗你80%精力的是模型之外的那一圈東西數(shù)據(jù)怎么進(jìn)來、怎么切、怎么存、怎么檢索、怎么拼裝成prompt、怎么控制并發(fā)、怎么監(jiān)控質(zhì)量、怎么迭代。我習(xí)慣把AI工程拆成四層來看。最底層是基礎(chǔ)設(shè)施層包括算力、顯存管理、模型加載與推理引擎往上是數(shù)據(jù)層包括文檔解析、分塊、向量化、存儲與檢索再往上是編排層負(fù)責(zé)把檢索結(jié)果、對話歷史、系統(tǒng)指令組裝成最終輸入并管理多輪狀態(tài)最上面是應(yīng)用與評估層面向具體業(yè)務(wù)場景同時負(fù)責(zé)質(zhì)量監(jiān)控和效果評估。從零搭建就是把這四層里最核心的模塊各實(shí)現(xiàn)一個最小可用版本。這樣拆的好處是你不會被某個框架的抽象概念繞暈。任何一個AI框架你都能把它對應(yīng)到這四層里看它到底幫你做了什么、隱藏了什么。當(dāng)你遇到問題時也能快速定位是哪一層出了毛病。2.2 最小可用系統(tǒng)該包含哪些模塊如果你時間有限我建議優(yōu)先實(shí)現(xiàn)這四個模塊它們覆蓋了AI工程最核心的能力文本分塊器把長文檔切成適合模型處理的片段這是RAG的地基切得好不好直接決定檢索質(zhì)量。向量化與檢索把文本轉(zhuǎn)成向量存起來并實(shí)現(xiàn)相似度檢索理解embedding和索引的基本原理。推理服務(wù)封裝把模型加載、請求處理、并發(fā)控制、超時重試封裝成一個穩(wěn)定的服務(wù)。評估腳本用一批標(biāo)注好的問答對量化你的系統(tǒng)到底好不好而不是憑感覺。這四個模塊做完你就有了一個能跑、能測、能迭代的完整閉環(huán)。后面再往上加緩存、加多路召回、加重排序都是在堅實(shí)的地基上做增量。2.3 一個容易被忽略的前提先定義“好”的標(biāo)準(zhǔn)我在早期項目里犯過一個典型錯誤花了兩周把系統(tǒng)搭起來跑起來感覺“還行”但老板問“準(zhǔn)確率多少”我答不上來。因?yàn)闆]有評估標(biāo)準(zhǔn)你根本不知道系統(tǒng)是在進(jìn)步還是在退步。所以在動手寫代碼之前先花半天時間做一件事準(zhǔn)備一個評估集。哪怕只有50條數(shù)據(jù)每條包含一個問題和一個標(biāo)準(zhǔn)答案或者標(biāo)準(zhǔn)答案的關(guān)鍵要點(diǎn)。這個評估集會貫穿你整個開發(fā)過程每次改動后跑一遍看指標(biāo)是漲是跌。沒有它你的所有優(yōu)化都是盲人摸象。這是我從零搭建AI系統(tǒng)時認(rèn)為最重要、也最容易被跳過的一步。3. 文本分塊RAG效果的天花板往往在這里就被決定了3.1 為什么固定長度分塊是個陷阱大部分教程教你分塊就是按固定字符數(shù)切比如每500字一塊重疊50字。這個方法實(shí)現(xiàn)簡單但在真實(shí)文檔上效果很差。原因很簡單文檔是有語義結(jié)構(gòu)的一個完整的論述可能橫跨800字你從中間切斷前半塊講了一半的論點(diǎn)后半塊接著講結(jié)論兩塊單獨(dú)看都不完整檢索時匹配到的都是殘缺信息。我實(shí)測過一個技術(shù)文檔庫固定長度分塊和按語義分塊在同一個評估集上的召回準(zhǔn)確率差了將近20個百分點(diǎn)。這個差距不是靠換更好的embedding模型能補(bǔ)回來的因?yàn)樾畔⒃谇蟹蛛A段就已經(jīng)被破壞了。正確的思路是按語義邊界切分。最基礎(chǔ)的做法是按段落切段落本身就是作者劃分的語義單元。如果段落太長再在段落內(nèi)部按句子切。句子邊界識別可以用簡單的標(biāo)點(diǎn)規(guī)則也可以用輕量的分句工具。核心原則是盡量保證每一塊是一個語義完整的單元而不是機(jī)械地湊字?jǐn)?shù)。3.2 分塊大小的權(quán)衡沒有標(biāo)準(zhǔn)答案只有場景答案分塊大小到底設(shè)多少是問得最多的問題。我的經(jīng)驗(yàn)是它取決于你的檢索粒度和模型上下文窗口兩個因素。塊太小比如100字檢索時匹配很精準(zhǔn)但單塊信息量不足模型拿到后可能答不完整。塊太大比如2000字信息量夠了但檢索時噪聲變多而且一塊里可能包含多個主題相似度計算會被稀釋。我一般會在300到800字之間做實(shí)驗(yàn)用評估集跑一遍看哪個區(qū)間的召回和答案質(zhì)量最好。還有一個技巧是分層分塊。把文檔同時切成大塊和小塊小塊用于精準(zhǔn)檢索檢索到之后把對應(yīng)的大塊或者大塊加上相鄰塊喂給模型。這樣兼顧了檢索精度和上下文完整性。這個思路在工程上實(shí)現(xiàn)起來不復(fù)雜但效果提升很明顯。3.3 元數(shù)據(jù)分塊時順手做的事后面能省大力氣分塊的時候千萬別只存文本內(nèi)容。至少要把這些元數(shù)據(jù)一起存下來來源文檔ID、塊在文檔中的位置序號、所屬章節(jié)標(biāo)題、塊的字符數(shù)。這些信息在后續(xù)檢索、去重、展示引用來源時都會用到。我踩過一個坑早期分塊只存了文本后來要做“引用溯源”功能需要知道每個答案來自哪篇文檔的哪一段結(jié)果發(fā)現(xiàn)根本追溯不了只能把整個庫重新處理一遍。所以分塊階段多存幾個字段成本極低收益極高。另外如果文檔有標(biāo)題層級結(jié)構(gòu)把章節(jié)標(biāo)題拼接到塊內(nèi)容前面一起做向量化能顯著提升檢索效果。因?yàn)闃?biāo)題本身就是對內(nèi)容的強(qiáng)概括相當(dāng)于給每個塊加了一個語義標(biāo)簽。4. 向量化與檢索把“找相似”這件事做扎實(shí)4.1 Embedding模型選型別只看排行榜選embedding模型很多人直接看公開榜單排名。榜單有參考價值但你的場景和榜單的評測場景可能完全不同。榜單大多測的是通用語義相似度而你的業(yè)務(wù)文檔可能有大量專業(yè)術(shù)語、縮寫、內(nèi)部黑話。我的做法是選兩三個候選模型用你自己的評估集各跑一遍檢索看召回率。候選模型里至少要有一個是支持中文或多語言的因?yàn)楹芏嘤⑽陌駟喂谲娫谥形纳媳憩F(xiàn)會打折。另外要考慮模型的維度和推理成本維度越高檢索越慢、存儲越大如果效果差距不大優(yōu)先選維度低的。還有一個實(shí)際因素模型能不能本地部署。如果你的數(shù)據(jù)敏感、不能出內(nèi)網(wǎng)那就只能選能本地跑的模型。這個約束會直接砍掉一批候選所以要在選型早期就確認(rèn)清楚。4.2 相似度計算余弦相似度不是唯一選擇向量檢索最常用的是余弦相似度它衡量的是方向上的接近程度對向量長度不敏感。這在大多數(shù)場景下是合理的因?yàn)閑mbedding模型通常會把語義相近的文本映射到相近的方向上。但有些場景下歐氏距離或者點(diǎn)積可能更合適。點(diǎn)積在向量已歸一化時等價于余弦相似度計算更快。如果你的embedding模型輸出已經(jīng)歸一化直接用點(diǎn)積就行省一次計算。我實(shí)測下來在歸一化向量上點(diǎn)積和余弦的結(jié)果完全一致但點(diǎn)積的矩陣運(yùn)算更快尤其在大規(guī)模檢索時差距明顯。實(shí)現(xiàn)檢索時最樸素的做法是暴力遍歷所有向量算相似度。數(shù)據(jù)量小的時候比如幾千條完全夠用而且結(jié)果精確。數(shù)據(jù)量上萬之后就要考慮近似最近鄰索引了。但我的建議是先用暴力檢索跑通全流程確認(rèn)效果達(dá)標(biāo)后再考慮換索引優(yōu)化速度。過早引入復(fù)雜索引調(diào)試成本高而且可能引入精度損失。4.3 檢索質(zhì)量差先別怪模型檢索效果不好很多人第一反應(yīng)是換更好的embedding模型。但根據(jù)我的經(jīng)驗(yàn)問題往往出在更前面分塊沒切好、查詢和文檔的表述方式差異太大、或者沒有做查詢改寫。一個立竿見影的技巧是查詢擴(kuò)展。用戶的問題往往很短比如“怎么配置超時”而文檔里寫的是“超時參數(shù)的設(shè)置方法”。直接拿短查詢?nèi)z索可能匹配不上。可以在檢索前用一個小模型或者規(guī)則把查詢擴(kuò)展成幾個同義表述分別檢索后合并結(jié)果。這個改動不大但召回率提升很明顯。另一個技巧是混合檢索向量檢索負(fù)責(zé)語義匹配關(guān)鍵詞檢索比如BM25負(fù)責(zé)精確匹配。兩者結(jié)果加權(quán)融合。對于包含專有名詞、型號、代碼的查詢關(guān)鍵詞檢索能補(bǔ)上向量檢索的短板。我在實(shí)際項目里基本都會上混合檢索純向量檢索在專業(yè)領(lǐng)域文檔上經(jīng)常漏召。5. 推理服務(wù)封裝讓模型穩(wěn)定跑起來比調(diào)通難得多5.1 模型加載顯存、精度與啟動速度的三角把模型加載起來跑通一次推理和把它封裝成一個能扛住并發(fā)、穩(wěn)定運(yùn)行的服務(wù)中間隔著一整個工程。第一個要面對的就是顯存問題。模型加載占用的顯存主要取決于參數(shù)量和精度。以常見的7B模型為例FP16精度下大約需要14GB顯存INT8量化后降到7GB左右INT4量化后只要4GB上下。如果你的顯卡顯存有限量化是必選項。但量化會帶來精度損失需要評估損失是否可接受。加載策略上我建議服務(wù)啟動時一次性加載常駐顯存而不是每次請求都加載。每次加載模型動輒幾十秒請求響應(yīng)時間根本沒法看。常駐顯存雖然占資源但換來了穩(wěn)定的低延遲。如果顯存實(shí)在緊張可以考慮多模型共享或者按需加載加緩存但復(fù)雜度會上升不少。5.2 并發(fā)控制別讓請求把服務(wù)打垮模型推理是計算密集型任務(wù)同時處理太多請求會導(dǎo)致顯存溢出或者響應(yīng)時間飆升。必須做并發(fā)控制。最直接的方式是限制同時處理的請求數(shù)用一個信號量或者隊列來控制。超出的請求排隊等待而不是直接拒絕。隊列長度也要設(shè)上限超過上限就快速失敗返回“服務(wù)繁忙”避免請求無限堆積拖垮整個服務(wù)。另一個關(guān)鍵是批處理。如果多個請求同時到達(dá)可以把它們拼成一個batch一起推理能顯著提升吞吐量。但批處理會增加單個請求的延遲因?yàn)橐葴惻?。所以要在吞吐和延遲之間找平衡點(diǎn)通常設(shè)一個很小的等待窗口比如幾十毫秒窗口內(nèi)到達(dá)的請求合并處理。超時和重試也要設(shè)計好。推理請求設(shè)一個合理的超時時間超時后釋放資源。對于可重試的錯誤比如臨時資源不足做有限次數(shù)的重試但要注意重試不能加劇擁塞最好帶退避策略。5.3 流式輸出體驗(yàn)提升的關(guān)鍵細(xì)節(jié)對話類應(yīng)用如果等模型全部生成完再返回用戶要盯著屏幕等好幾秒體驗(yàn)很差。流式輸出讓token一個個吐出來用戶馬上能看到反饋感知延遲大幅降低。實(shí)現(xiàn)流式輸出需要在推理引擎層面支持逐token返回然后在服務(wù)層用SSE或者WebSocket推給前端。這里有個坑流式輸出時如果中途出錯已經(jīng)吐出去的內(nèi)容沒法收回所以要在開始流式輸出前做好參數(shù)校驗(yàn)和資源檢查盡量把錯誤擋在前面。還有一個細(xì)節(jié)是首token延遲。用戶感知的響應(yīng)速度主要取決于第一個token多久出來。優(yōu)化首token延遲可以從prompt長度、模型預(yù)熱、KV緩存復(fù)用幾個方向入手。prompt越短首token越快所以檢索回來的上下文要精簡別一股腦全塞進(jìn)去。6. 評估與迭代沒有度量就沒有優(yōu)化6.1 評估集怎么建才靠譜評估集的質(zhì)量直接決定你優(yōu)化的方向?qū)Σ粚?。我的建議是評估集要覆蓋三類問題事實(shí)型答案在文檔里有明確出處、推理型需要綜合多處信息、邊界型文檔里沒有答案系統(tǒng)應(yīng)該拒答。每類問題都要有比例根據(jù)你的業(yè)務(wù)場景調(diào)整。如果業(yè)務(wù)里大部分是事實(shí)型查詢那事實(shí)型占比就高一些。邊界型問題特別重要因?yàn)楹芏嘞到y(tǒng)在遇到不知道的問題時會胡編評估集里必須有這類樣本才能測出系統(tǒng)的“誠實(shí)度”。標(biāo)注答案時不要只寫一個標(biāo)準(zhǔn)答案最好把關(guān)鍵要點(diǎn)列出來。因?yàn)槟Ｐ蜕傻拇鸢副硎隹赡芎蜆?biāo)準(zhǔn)答案不同但要點(diǎn)覆蓋了就算對。評估時可以用要點(diǎn)召回率來衡量比精確匹配更合理。6.2 自動化評估用模型評模型人工評估準(zhǔn)確但慢不適合快速迭代?？梢杂靡粋€能力較強(qiáng)的模型來做自動評估給它問題、標(biāo)準(zhǔn)要點(diǎn)、系統(tǒng)答案讓它判斷答案覆蓋了哪些要點(diǎn)、有沒有編造。用模型評估要注意幾點(diǎn)評估用的模型能力要明顯強(qiáng)于被評估的系統(tǒng)否則評不準(zhǔn)評估的prompt要寫清楚評分標(biāo)準(zhǔn)最好給幾個示例評估結(jié)果要做抽樣人工復(fù)核確認(rèn)自動評估和人工判斷的一致性。我一般會抽10%的樣本人工核對如果一致性低于90%就要調(diào)整評估prompt。除了答案質(zhì)量還要監(jiān)控檢索命中率正確文檔有沒有被檢索到和拒答準(zhǔn)確率該拒答的有沒有拒答。這兩個指標(biāo)能幫你定位問題出在檢索層還是生成層。6.3 迭代的優(yōu)先級先修召回再調(diào)生成系統(tǒng)效果不好時優(yōu)化順序很關(guān)鍵。我的經(jīng)驗(yàn)是先確保檢索能召回正確文檔再優(yōu)化生成質(zhì)量。如果正確文檔根本沒被檢索到生成模型再強(qiáng)也答不出來這時候調(diào)prompt是白費(fèi)力氣。判斷方法很簡單看評估集里答錯的樣本正確文檔是否在檢索結(jié)果里。如果不在就是召回問題去優(yōu)化分塊、embedding、查詢擴(kuò)展、混合檢索。如果在但答案還是錯才是生成問題去優(yōu)化prompt、上下文組織、模型選型。這個排查順序能幫你避免在錯誤的方向上浪費(fèi)時間。我見過太多團(tuán)隊一上來就瘋狂調(diào)prompt結(jié)果發(fā)現(xiàn)根因是分塊把關(guān)鍵信息切碎了。7. 那些文檔里不會寫的實(shí)操心得7.1 關(guān)于工具選型的一點(diǎn)個人偏見從零搭建不等于什么都自己寫。向量存儲、推理引擎這些輪子該用現(xiàn)成的就用自己寫一遍是為了理解原理不是為了重復(fù)造輪子。我的原則是核心邏輯自己實(shí)現(xiàn)通用基礎(chǔ)設(shè)施用成熟方案。比如向量檢索的索引結(jié)構(gòu)自己實(shí)現(xiàn)一個暴力檢索理解原理就夠了生產(chǎn)環(huán)境還是用成熟的向量庫。但有一個東西我建議自己寫評估腳本。因?yàn)樵u估邏輯和你的業(yè)務(wù)強(qiáng)相關(guān)現(xiàn)成工具往往不夠靈活。自己寫一個評估腳本想加什么指標(biāo)就加什么指標(biāo)迭代起來最順手。7.2 數(shù)據(jù)清洗的投入被嚴(yán)重低估大家聊AI工程都在聊模型、聊框架很少有人聊數(shù)據(jù)清洗。但實(shí)際項目里數(shù)據(jù)清洗占的時間經(jīng)常超過一半。PDF解析出來的文本可能帶亂碼、頁眉頁腳、表格錯位網(wǎng)頁抓下來的內(nèi)容有導(dǎo)航欄、廣告、無關(guān)鏈接。這些噪聲不清理后面分塊和檢索全是垃圾進(jìn)垃圾出。我的建議是在數(shù)據(jù)清洗階段多花時間建立一套可復(fù)用的清洗規(guī)則。比如統(tǒng)一去除頁眉頁腳、合并被錯誤換行切斷的句子、過濾過短的碎片塊。這些規(guī)則一旦建好后續(xù)所有文檔都能受益。7.3 日志和可觀測性要提前埋系統(tǒng)上線后出問題如果沒有日志排查起來就是災(zāi)難。從第一天起就要把關(guān)鍵環(huán)節(jié)的日志埋好每次請求的查詢內(nèi)容、檢索到的文檔ID和相似度分?jǐn)?shù)、最終prompt的長度、模型輸出的token數(shù)、各階段耗時。這些日志不僅能用于排錯還能用于分析。比如你發(fā)現(xiàn)某類查詢的檢索相似度普遍偏低就知道這類查詢需要特殊處理。可觀測性不是上線后才考慮的事而是從搭建第一天就要設(shè)計進(jìn)去的。7.4 版本管理不只是代碼AI系統(tǒng)里除了代碼要版本管理數(shù)據(jù)、prompt、模型、索引都要版本管理。你換了一版分塊策略重新生成了索引如果沒記錄過兩周你都不知道線上跑的是哪版。prompt改了一個詞效果變了沒有版本記錄就無從對比。我的做法是給每次重要的變更打一個版本號記錄變更內(nèi)容、對應(yīng)的評估指標(biāo)。這樣任何時候都能回溯也能快速回滾到效果最好的版本。這個習(xí)慣看起來麻煩但能幫你省下大量“到底哪版效果好”的扯皮時間。8. 從能跑到好用下一步可以往哪走把上面這套最小系統(tǒng)搭完你已經(jīng)超過了大多數(shù)只會調(diào)包的人。但AI工程的深度遠(yuǎn)不止于此。如果還想繼續(xù)深入我建議往這幾個方向走。第一個方向是性能優(yōu)化。研究KV緩存復(fù)用、連續(xù)批處理、投機(jī)解碼這些推理加速技術(shù)把吞吐和延遲再壓一壓。這些技術(shù)在大規(guī)模服務(wù)里收益非常明顯。第二個方向是多路召回與重排序。在向量檢索和關(guān)鍵詞檢索之外加入基于知識圖譜的檢索、基于規(guī)則的檢索再用一個重排序模型對多路結(jié)果統(tǒng)一打分。這是提升復(fù)雜場景效果的有效手段。第三個方向是Agent化。讓系統(tǒng)不只是被動問答而是能調(diào)用工具、拆解任務(wù)、多步推理。這需要在編排層做大量工作也是當(dāng)前AI應(yīng)用最活躍的方向。但無論往哪走底層那套“分塊、檢索、推理、評估”的基本功都是繞不開的。把地基打牢上面的樓才蓋得高。我自己從零搭過幾套系統(tǒng)之后最大的體會是AI工程沒有魔法所有的效果提升都來自對每個環(huán)節(jié)的扎實(shí)理解和反復(fù)調(diào)優(yōu)。那些看起來“聰明”的系統(tǒng)背后都是這些笨功夫堆出來的。