先聊個很多人都會問的問題AI 工程AI Engineering到底是不是個“新瓶裝舊酒”的概念我自己的判斷是它不是。早幾年我們講機器學(xué)習(xí)、深度學(xué)習(xí)重心大多放在模型訓(xùn)練——調(diào)參、刷榜誰 AUC 高誰厲害。但到了今天一個模型能不能真正落地、能不能持續(xù)穩(wěn)定地服務(wù)業(yè)務(wù)靠的遠不只是訓(xùn)練。數(shù)據(jù)怎么管、特征怎么算、模型怎么部署、上線之后怎么監(jiān)控、效果變差了怎么撈回來這些環(huán)節(jié)加在一起才是完整閉環(huán)。而這個整體能力就是 AI 工程。幾年前沒有人給你規(guī)劃好這條路網(wǎng)上資料要么偏算法理論要么偏純后端能把這整條鏈路串起來講的極少。這個“ai-engineering-from-scratch”要解決的就是這個痛點從頭梳理 AI 工程到底學(xué)什么、做什么、怎么一步步做成適合剛?cè)腴T想走 AI 工程方向的同學(xué)也適合已經(jīng)在做后端或算法、想補齊工程能力的人。下文就是我從零到一完整跑通這個體系的實戰(zhàn)筆記純干貨不繞彎。1. AI 工程到底是什么為什么值得從頭搭建1.1 先搞清楚 AI 工程和傳統(tǒng)軟件工程的區(qū)別很多人第一次聽說 AI 工程下意識會把它理解成“會寫 Python 調(diào)模型”。如果只是這樣那和算法工程師有什么區(qū)別行業(yè)里現(xiàn)在普遍接受的一種定義是AI 工程是面向 AI 應(yīng)用的軟件工程實踐它把模型當(dāng)作系統(tǒng)的一個組件而不是全部。換句話說AI 工程師的職責(zé)是讓 AI 能力以穩(wěn)定、可維護、可擴展的方式嵌入業(yè)務(wù)。對比傳統(tǒng)軟件工程最核心的區(qū)別有兩個。第一傳統(tǒng)軟件的邏輯是確定性優(yōu)先——輸入 A輸出 B行為可預(yù)期。模型的邏輯是概率性的——同一個 prompt 或者同一批特征結(jié)果可能有波動。所以工程上必須增加一層兜底和校驗比如閾值判斷、降級方案、結(jié)果合理性檢查。第二傳統(tǒng)軟件的生命周期里測試數(shù)據(jù)和真實數(shù)據(jù)分布通常一致模型應(yīng)用則經(jīng)常出現(xiàn)“離線效果好、線上效果崩”的窘境。數(shù)據(jù)分布漂移這個變量傳統(tǒng)軟件工程師幾乎不需要考慮但對 AI 工程來說是家常便飯。所以 AI 工程不是算法工程師的“下位替代”也不是普通后端的“加個模型接口”。它是一個更綜合的位置既要懂模型的基本工作原理又得具備軟件工程的紀(jì)律性還得有數(shù)據(jù)敏感度。這也是為什么業(yè)界常說“AI 工程師是 transformer 時代的全棧工程師”——不是說你什么都會而是說你需要具備跨層協(xié)調(diào)能力。1.2 從零搭建的必要性不經(jīng)歷底層談何上層這輪大模型浪潮帶來了很多“低門檻”工具比如封裝好的 SDK、托管服務(wù)、微調(diào)平臺。我舉雙手贊成用工具提效但我強烈不建議一上來就直接懟高層服務(wù)。理由很簡單你不親手跑一遍訓(xùn)練、評估、部署、監(jiān)控的完整流程你根本不知道哪個環(huán)節(jié)會出問題出了問題也不知道該看哪里。舉個很典型的例子。有人用了托管的模型 API 做問答應(yīng)用線上反饋偶爾出現(xiàn)胡說八道的情況。他第一反應(yīng)是換個更強的模型結(jié)果換了還是有問題。后來排查才發(fā)現(xiàn)問題出在他處理用戶輸入時把一些關(guān)鍵上下文截斷了模型根本沒拿到足夠信息。這個錯如果他自己寫過完整的 RAG 鏈路一眼就能定位但如果他只接觸過 API 調(diào)用就很容易在“模型不行”的錯誤方向上反復(fù)內(nèi)耗。這就是 from scratch 的核心價值不是為了復(fù)古是為了建立“故障直覺”。你親手寫過數(shù)據(jù)處理腳本才知道臟數(shù)據(jù)長什么樣自己部署過推理服務(wù)才知道延遲瓶頸往往卡在序列化和網(wǎng)絡(luò)傳輸上自己寫過評估腳本才明白人工評測在真實場景里有多不可靠。這些認知是任何工具替代不了的。2. 核心能力地圖先畫清楚要學(xué)什么再動手2.1 技術(shù)棧全景從底到頂?shù)牧鶄€層次真要系統(tǒng)學(xué)習(xí) AI 工程我建議把它拆成六層來看每一層都有明確的交付物和驗收標(biāo)準(zhǔn)。這樣學(xué)起來不會迷失方向因為每一層都可以單獨驗證。第一層是編程基礎(chǔ)與工程素養(yǎng)以 Python 為主必須熟悉面向?qū)ο蟆㈩愋妥⒔?、虛擬環(huán)境、git 工作流。第二層是數(shù)學(xué)與機器學(xué)習(xí)基礎(chǔ)重點不是推導(dǎo)公式而是要理解損失函數(shù)、梯度下降、過擬合、評估指標(biāo)這些概念背后的直覺。第三層是深度學(xué)習(xí)框架PyTorch 為主要做到能自己寫訓(xùn)練循環(huán)、自定義數(shù)據(jù)集、斷點續(xù)訓(xùn)。第四層是模型應(yīng)用與微調(diào)包括預(yù)訓(xùn)練模型的加載、prompt 工程、指令微調(diào)、參數(shù)高效微調(diào)。第五層是推理與部署包括模型量化、服務(wù)化、容器化、GPU 資源管理。第六層是數(shù)據(jù)與評估體系包括數(shù)據(jù)清洗、標(biāo)注規(guī)范、離線評估、線上監(jiān)控。很多人會問數(shù)學(xué)到底要學(xué)到什么程度我的建議是你不需要會推導(dǎo) transformer 的全部公式但必須理解以下幾個概念向量與矩陣乘法做 attention 時能跟上、概率分布理解困惑度和采樣、損失函數(shù)與梯度理解訓(xùn)練和過擬合、以及統(tǒng)計顯著性理解 A/B 實驗。到這一步就夠支撐任何工程決策。2.2 關(guān)鍵思維轉(zhuǎn)變從“模型優(yōu)先”到“系統(tǒng)優(yōu)先”真正動手做項目之后我發(fā)現(xiàn)初學(xué)者最容易卡住的不是技術(shù)而是思維。算法背景的人容易困在“我要把模型效果調(diào)到最好”這個單點目標(biāo)里后端背景的人容易困在“接口能用就行”的功能交付里。AI 工程要求的是一種系統(tǒng)思維你需要在效果、成本、延遲、可維護性之間做權(quán)衡。舉個真實例子。在公司做智能客服的過程中我們評估過兩個方案一個是直接調(diào)用商用大模型 APIanswer 質(zhì)量高但每次調(diào)用成本高延遲波動大另一個是用小模型加本地知識庫answer 質(zhì)量略低但成本幾乎為零延遲穩(wěn)定在 100ms 內(nèi)。單看模型效果方案一完勝但放到真實業(yè)務(wù)里客服系統(tǒng)日均調(diào)用量幾十萬次成本差是數(shù)量級的而且延遲一高用戶立刻感知到頁面卡頓。最終我們選了方案二再用 prompt 優(yōu)化和意圖識別兜底把質(zhì)量差距壓縮到可接受范圍。這就是“系統(tǒng)優(yōu)先”的典型決策過程。在你的第一個項目里就要有意識地去記錄和權(quán)衡這類指標(biāo)而不是只盯著 accuracy 或者 BLEU。這個習(xí)慣越早建立后面做真實項目時越不吃虧。3. 從零到一實操搭建一個完整的 AI 工程小項目3.1 項目選型為什么是“本地知識庫問答”前面講了一堆理念下面我們用一個小項目把這些串起來構(gòu)建一個基于本地知識庫的問答系統(tǒng)。這個項目非常適合入門原因有三個。第一它覆蓋了完整鏈路——數(shù)據(jù)處理、向量化、檢索、模型生成、服務(wù)封裝、評估一個都不少。第二它不需要昂貴資源本地 CPU 也能跑。第三它非常貼近企業(yè)真實需求你做完之后能直接講出這個故事的價值。整體架構(gòu)分成五塊知識庫文檔解析、文本切分、向量化與存儲、檢索、生成回答。對應(yīng)的技術(shù)棧我分別選了python-docx 和 pypdf 做文檔解析RecursiveCharacterTextSplitter 做文本切分text2vec-base-chinese 或 bge-small-zh 做向量化FAISS 做向量存儲和檢索最后用 ChatGLM 或 Qwen 等開源模型做生成。你可能會問為什么不上 RAG 框架比如 LangChain、LlamaIndex不是不能而是我先建議你手工過一遍。手寫過一遍之后你才能深刻理解哪些步驟耗時、哪些參數(shù)影響大、哪些環(huán)節(jié)容易出問題。之后再上框架你才算是在用框架而不是被框架用。3.2 步驟一文檔解析與文本切分第一步是準(zhǔn)備幾份產(chǎn)品說明文檔比如把公司的某產(chǎn)品手冊導(dǎo)出成 PDF 和 Word 兩種格式。這時候你立刻會遇到第一個工程問題PDF 解析出來的文本經(jīng)常帶亂碼、多余換行和頁碼信息。我的處理流程是這樣先寫一個解析函數(shù)從不同文件類型抽取純文本再寫一個清洗函數(shù)統(tǒng)一做去特殊符號、合并斷行、去空白字符最后打印前 500 字符做目檢。注意這一步千萬不能省因為后續(xù)文本切分和向量化的質(zhì)量完全取決于這一步。文本切分是個容易被忽略但極其關(guān)鍵的環(huán)節(jié)。切太短語義不完整檢索時噪聲很大切太長向量表示被稀釋而且超出 embedding 模型的最大輸入長度。實踐經(jīng)驗是先用 200 到 500 字作為初始窗口大小重疊 50 到 100 字。這里的“重疊”是為了保證跨段落的語義不斷裂。修改切分參數(shù)之后一定要抽樣檢查切分結(jié)果我在實際項目里發(fā)現(xiàn)過切出來的文本是一半表格一半正文的情況這種質(zhì)量是沒法檢索的。3.3 步驟二向量化與檢索實現(xiàn)接下來是向量化。小規(guī)模場景直接用 CPU 跑 text2vec 或者 bge 就夠。關(guān)鍵點有三個第一模型要統(tǒng)一查詢和文檔必須用同一個 embedding 模型否則向量空間不一致第二文本要歸一化超長文本截斷、空文本過濾第三向量要歸一化余弦相似度才能正確計算。存儲我建議先用 FAISS本地文件存儲即可。你只存兩樣?xùn)|西原始文本和向量。入庫前還要維護一個 id 映射方便后續(xù)檢索返回原文本。檢索邏輯看起來簡單——對 query 做向量化然后查 top-k——但實際有幾個坑。第一個坑是混合檢索單靠向量檢索遇到專業(yè)術(shù)語或縮寫時容易召回不準(zhǔn)確。實操解法是疊加 BM25 關(guān)鍵詞檢索用加權(quán)融合的方式綜合排序。第二個坑是重排序rerank初篩 top 50再精排成 top 5效果提升非常明顯。第三個坑是閾值過濾即使相關(guān)性分數(shù)不高系統(tǒng)也會硬返回結(jié)果導(dǎo)致答非所問。正確做法是設(shè)定一個最低相似度閾值低于閾值就返回“知識庫中未找到相關(guān)信息”。3.4 步驟三生成回答與 Prompt 設(shè)計生成階段的關(guān)鍵是寫好系統(tǒng)提示詞system prompt。這里的經(jīng)驗法則是先給角色定位再給任務(wù)約束再給知識上下文最后給回答格式。以一個實際模板為例我的提示詞是“你是企業(yè)智能助理。請只依據(jù)提供的知識片段回答用戶問題每句話都需要有依據(jù)如果知識片段中不含所需信息請直接說明不知道不要編造?；卮鹂刂圃?5 條要點以內(nèi)。知識片段如下xxx。用戶問題xxx”。這個模板里有幾個值得注意的細節(jié)。第一“每句話都需要有依據(jù)”這句話能顯著減少幻覺因為模型被要求對自己生成的內(nèi)容進行隱含的“溯源”檢查。第二“不要編造”比“如實回答”更直接行為約束更明確。第三限制答案長度可以避免模型堆砌冗長文本。第四把知識片段放在用戶問題之前讓注意力機制在推理時更聚焦于知識內(nèi)容。這些都是低成本高收益的優(yōu)化建議直接抄。3.5 步驟四把服務(wù)封裝成可調(diào)用接口一個可交付的系統(tǒng)最終要變成服務(wù)。我選擇的是 FastAPI理由很簡單自帶 OpenAPI 文檔、異步支持、Pydantic 校驗、部署方便。你需要構(gòu)建兩個接口一個負責(zé)寫入知識數(shù)據(jù)入庫一個負責(zé)查詢問答query 進來、answer 出去。接口設(shè)計有幾個工程細節(jié)。第一個是統(tǒng)一響應(yīng)結(jié)構(gòu)比如 {“code”: 0, “data”: {...}}不要讓前端同學(xué)猜你的字段。第二個是超時控制模型推理可能很慢必須設(shè)置合理的請求超時避免連接堆積。第三個是并發(fā)控制本地小模型在同一時間只能處理少量請求可以用 Semaphore 限制并發(fā)數(shù)收到超過負荷的請求時直接返回 503 提示稍后重試而不是拖死進程。我在這步踩過一個很深的坑第一次部署用的是同步阻塞方式結(jié)果兩個人同時提問時第二個人硬生生等了 30 秒。理論上模型推理本來就慢但是用異步代理把模型推理放到一個線程池里之后至少能讓其他請求先響應(yīng)起來體感好了很多。這個優(yōu)化很小但是系統(tǒng)穩(wěn)定性的關(guān)鍵。4. 評估體系你做的系統(tǒng)好不好要用數(shù)據(jù)說話4.1 離線評估別只看準(zhǔn)確率要看細粒度很多初學(xué)者做 RAG 系統(tǒng)評估的時候只會看“幾道題答對了幾道”然后報告一個準(zhǔn)確率。這在真實項目里遠遠不夠。我建議建立三套評估維度檢索質(zhì)量、生成質(zhì)量、端到端質(zhì)量。檢索質(zhì)量用 Recallk 和 MRR。簡單理解就是正確答案是否出現(xiàn)在檢索返回的前 k 條里排得靠不靠前這個指標(biāo)能獨立驗證你的 embedding 選擇和切分策略。生成質(zhì)量用 faithfulness 和 answer relevance。Faithfulness 檢查生成內(nèi)容是否有知識庫依據(jù)相關(guān)性檢查回答是否契合問題。這兩個指標(biāo)在生成式模型上比準(zhǔn)確率更有意義因為它們能抓住“答非所問”和“胡編亂造”這兩類高頻問題。最實用的做法是準(zhǔn)備 50 條覆蓋不同難度的測試問題逐條手動打分并記錄錯誤類型。每次改動系統(tǒng)比如換了切割參數(shù)、換了 embedding 模型、改了 prompt都用同一套測試集重新評估用得分變化來指導(dǎo)決策。沒有這套基線你后面做的“優(yōu)化”全是拍腦袋。4.2 線上監(jiān)控讓問題在產(chǎn)品化之前暴露離線評估做得再好線上也會出現(xiàn)新問題比如用戶問了知識庫里沒有的東西、用戶輸入里帶錯別字、知識庫文檔更新后沒有同步向量庫。我建議至少做三層的線上日志監(jiān)控。第一層是請求日志記錄 query、檢索結(jié)果、最終回答、延遲和 token 消耗。第二層是效果評價定期抽檢日志讓業(yè)務(wù)人員給回答打標(biāo)簽統(tǒng)計“優(yōu)質(zhì)回答率”。第三層是數(shù)據(jù)漂移監(jiān)控統(tǒng)計新 query 和知識庫的相似度分布如果相似度持續(xù)降低說明用戶的問法在變可能需要更新知識庫。在 Python 中做好這兩類監(jiān)控套路已經(jīng)相對成熟日志直接輸出到 JSON Lines 文件再定時用腳本聚合統(tǒng)計指標(biāo)按天歸檔做成最簡單的小報表。早期項目不需要復(fù)雜監(jiān)控平臺先把數(shù)據(jù)和工具鏈搭好后面自然知道怎么擴展。5. 常見問題與排查方向速查做這個項目時我一邊寫代碼一邊記錄了踩坑日志最終積累了下面這份排查速查表。如果你在做同類項目時遇到問題可以直接對照定位。癥狀大概率原因排查方向檢索結(jié)果驢唇不對馬嘴切分單位過大/過小或 embedding 模型與查詢不匹配檢查切分文本確認查詢和文檔使用同一向量模型回答總是“不知道”檢索到的知識片段與問題無關(guān)降低 top-k 閾值檢查重排序邏輯查看檢索片段原文回答出現(xiàn)幻覺內(nèi)容prompt 約束不足檢索片段為空時仍硬答強化 prompt 行為約束加入相似度閾值邏輯知識片段為空時直接拒答服務(wù)延遲很高模型無并發(fā)控制序列化影響CPU 推理增加緩存批量加載模型并發(fā)信號量量化模型用戶輸入稍變就答不出來依賴單路檢索增加同義詞改寫、拼寫糾錯或混合檢索策略知識庫更新后系統(tǒng)不生效增量更新未實現(xiàn)檢查新增文檔是否寫入向量庫冪等性校驗顯存/內(nèi)存持續(xù)增長推理框架緩存未釋放定期加載測試用對象復(fù)用替代頻繁創(chuàng)建模型對象prompt 改了但效果沒變化緩存命中舊答案檢查緩存 key 是否包含 prompt 版本號上面這張表是我最常用的排查起點。現(xiàn)實中的問題往往不是單點故障而是鏈路多個環(huán)節(jié)疊加因此排查時要按“數(shù)據(jù) → 檢索 → prompt → 生成 → 部署”這條鏈路逐層過別一上來就懷疑模型。6. 下一步怎么往深處走6.1 從 MVP 到可用的系統(tǒng)還需要補什么手工搭建完基礎(chǔ)知識庫問答之后下一步我會按優(yōu)先級補三塊工程能力。第一塊是自動化評測流水線把 4.1 節(jié)里那套離線評估腳本接入 CI/CD每次改代碼自動跑一遍回歸測試避免“改壞了一處過了兩周才發(fā)現(xiàn)”。第二塊是知識庫管理后臺支持批量上傳文檔、增量更新向量庫、人工修正錯誤回答并反饋到知識庫。第三塊是多路召回的進一步升級比如引入意圖識別、FAQ 精確匹配、甚至多跳檢索來處理更復(fù)雜的問題。這里插一句個人經(jīng)驗很多項目死于“過度設(shè)計”。如果你只是做一個 Demo不必一上來就上 Cranium 和龐大的 RAG 框架先把核心鏈路跑通再按真實數(shù)據(jù)暴露出的問題逐步迭代。框架只是手段問題才是引領(lǐng)者。6.2 技能棧的縱向延伸三條可選路線走完這個項目你已經(jīng)具備了 AI 工程的全鏈路基本盤。在此基礎(chǔ)上可以按職業(yè)興趣選擇縱向深入。第一條是算法縱深路線繼續(xù)深入模型訓(xùn)練學(xué)指令微調(diào)、強化學(xué)習(xí)、模型評估方法論、推理優(yōu)化。適合想走向算法專家路線的同學(xué)。第二條是工程縱深路線學(xué)更多性能優(yōu)化、分布式推理、GPU 調(diào)度、自動擴縮容和云原生部署走向平臺工程方向。第三條是數(shù)據(jù)縱深路線深耕數(shù)據(jù)質(zhì)量、標(biāo)注體系、數(shù)據(jù)版本管理、合成數(shù)據(jù)技術(shù)。大模型時代數(shù)據(jù)能力越來越值錢走這條路的人相對少但缺口很大。這幾條路線并不是互斥的。我的建議是先用主線打通全鏈路再用支線補強一兩個方向。AI 工程最忌諱的就是“啥都接觸啥都不精”。7. 一些實際的經(jīng)驗體會最后聊幾句實在話。我見過很多人學(xué) AI 工程時最大的阻礙不是資料少而是“怕”字——怕數(shù)學(xué)看不懂怕環(huán)境配不好怕模型跑不起來。我的體會是大部分 AI 工程問題你動手去碰它就已經(jīng)解決一半了。環(huán)境變量報錯就一行行看模型推理慢就做性能分析數(shù)據(jù)臟就寫好清洗腳本這些東西沒有捷徑但都是確定性的只要人肯坐在那里逐步磨總能磨出來。另一個特別想說的點是要盡早養(yǎng)成把自己的過程沉淀成文檔和腳本的習(xí)慣。做這個項目時我記了一本“踩坑手冊”后來它直接變成了團隊的新人培訓(xùn)材料。AI 工程里很多隱形知識是跑在空氣里的只存在于某個人的工作經(jīng)歷里你寫下來它才成為可復(fù)用的資產(chǎn)?，F(xiàn)在你手里的這份資料本質(zhì)上也是這么來的。我不建議你按部就班每一步都抄一遍而是帶著“如果這里出問題了會怎樣”的疑問去過代碼。跑通一遍之后再試著換一個領(lǐng)域的小項目比如做一個簡歷匹配助手、做一個內(nèi)部信息檢索機器人。一個項目能讓你學(xué)會流程兩個不同領(lǐng)域的項目才能讓你學(xué)會遷移而遷移能力才是 AI 工程真正值錢的地方。