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