面向開發者的AI工程實踐指南

本文旨在為有經驗的軟體工程師提供AI工程化實踐指南。作者擁有15年後端開發經驗，發現LLM引入生產環境後，傳統規則不再適用：系統預設非確定性、輸入為自然語言、單元測試無法評估輸出質量。

AI工程概述

基礎模型是新一代抽象：經過大規模混合語料預訓練，可透過API呼叫適配多種任務，無需重新訓練。例如，Gemini 3.1 Pro既能撰寫營銷郵件，也能分類客服工單、生成SQL、總結百萬token程式碼庫、呼叫工具。工程師的角色轉變為構建圍繞模型的系統，而非模型本身。

基礎模型適用於程式碼、寫作、影像影片、教育、對話、資訊聚合、資料組織、工作流自動化等場景，但不適用於精確算術、即時事實（無接地）、以及任何不能容忍輕微錯誤的場景。

AI工程 vs ML工程 vs全棧工程

ML工程關注模型訓練：資料管道、特徵工程、超引數調優。AI工程關注利用預訓練模型構建應用：提示、檢索、評估、智慧體、推理服務、可觀測性。AI工程師是後端工程師，額外承擔系統接地、持續評估、以及控制成本與延遲的責任。

三層技術棧

• 應用層：提示、RAG、智慧體、UI、業務邏輯。
• 模型開發層：微調、模型合併、蒸餾、資料集工程（可選）。
• 基礎設施層：GPU、推理伺服器、向量資料庫、閘道器、可觀測性。

大多數團隊駐留應用層，僅在必要時下沉。提示工程和RAG達到瓶頸時考慮微調；成本、資料駐留或硬體限制迫使自建推理基礎設施時考慮基礎設施層。

適配LLM的方法

按成本遞增：提示工程（最便宜、最快）、RAG（執行時注入上下文）、微調（改變權重）。預設順序：提示→RAG→微調。不要跳過步驟。

選擇LLM

2026年模型類別：封閉前沿（最高質量、高成本）、封閉中端、封閉廉價（批次任務首選）、開源權重（自建GPU）、專用模型（嵌入、重排序等）。選擇依據：任務適配、成本、延遲、上下文視窗、輸出結構、執行位置。多數團隊應使用多個模型，將低成本請求路由到廉價模型。

規劃AI應用

AI功能規劃不同於傳統功能，因為輸出質量非二進位制。規劃需包含明確的質量檢查點：用例評估（真實問題？機率輸出容忍度？錯誤成本？）、設定預期（開發時間至少為常規功能的2倍，主要用於評估和邊緣情況）、里程碑規劃（快速達到“勉強能用”→評估→生產加固）、持續維護（模型漂移、提示退化、資料變化）。

“勉強能用”里程碑至關重要：儘快交付真實使用者，觀察問題並修復，而非在隔離環境中追求完美。

挑戰

• 開發：提示無法進行確定性單元測試，需提前構建評估資料集。
• 部署：推理慢、昂貴、突發性強，需快取、批處理和路由。
• 維護：模型版本迭代、分詞器變化（如Opus 4.7新分詞器可能增加35% token）、幻覺演變，需監控和紅隊測試。

行業用例與ROI

高回報場景：客服分流、內部文件RAG搜尋、程式碼輔助、文件自動化。低迴報或負回報場景：面向使用者的錯誤答案導致品牌危機、嘗試替換確定性API、無人維護的演示專案。

理解基礎模型

訓練資料決定模型能力。多語言模型在主要語言上表現良好，但長尾語言薄弱。領域專用模型在特定領域有小幅提升，但大多數情況下，通用模型配合RAG在質量和操作簡便性上勝出。

模型架構與規模

主流是僅解碼器Transformer，部分採用混合專家模型。模型規模仍重要，但精心調優的70B模型可擊敗欠調優的400B模型。推理模型（如Gemini 3.1 Pro思考模式、Claude擴充套件思考）將關注點從引數數量轉向測試時計算量。

小語言模型、多模態、領域專用與推理模型

• 小語言模型：可在單GPU執行，適用於分類、路由、簡單摘要等低成本任務。
• 多模態：影像、影片、音訊已成為一等輸入，需決定是否預處理以控制成本。
• 推理模型：內部長思維鏈後響應，適合數學、程式碼、規劃，但更慢更貴。