1. 從Demo到生產(chǎn)為什么AI應(yīng)用總在最后一公里翻車做過AI應(yīng)用的人都有一個(gè)共同體會(huì)Demo跑通那一刻的興奮往往在生產(chǎn)環(huán)境上線后的第一個(gè)小時(shí)就被徹底澆滅。本地用幾行代碼調(diào)通一個(gè)模型接口輸出一段看起來(lái)像模像樣的結(jié)果這事情的門檻已經(jīng)低到幾乎不存在。但當(dāng)你把同樣的邏輯放到真實(shí)流量、真實(shí)用戶、真實(shí)數(shù)據(jù)面前各種問題就像約好了一樣集中爆發(fā)——響應(yīng)時(shí)間從200毫秒飆到8秒模型輸出時(shí)好時(shí)壞成本賬單一個(gè)月翻十倍出了故障連問題出在哪個(gè)環(huán)節(jié)都定位不到。這就是AI應(yīng)用工程化治理要解決的核心命題。所謂治理不是給模型加個(gè)殼、套個(gè)API網(wǎng)關(guān)就完事而是圍繞AI應(yīng)用從開發(fā)、測(cè)試、部署、監(jiān)控到迭代的全生命周期建立一套可觀測(cè)、可控制、可回滾、可優(yōu)化的工程體系。它涵蓋模型服務(wù)管理、提示詞版本控制、推理成本治理、輸出質(zhì)量監(jiān)控、降級(jí)熔斷策略、數(shù)據(jù)回流機(jī)制等一系列具體工作。這篇文章適合三類人看一是正在把AI Demo往生產(chǎn)推的開發(fā)者二是負(fù)責(zé)AI應(yīng)用穩(wěn)定性的運(yùn)維和平臺(tái)工程師三是需要為AI項(xiàng)目做技術(shù)決策的團(tuán)隊(duì)負(fù)責(zé)人。我會(huì)從整體設(shè)計(jì)思路講起把每個(gè)關(guān)鍵環(huán)節(jié)的選型邏輯、實(shí)操步驟、參數(shù)計(jì)算和踩坑經(jīng)驗(yàn)都攤開來(lái)說(shuō)盡量做到你讀完就能對(duì)照自己的項(xiàng)目動(dòng)手改造。全文基于我在多個(gè)AI應(yīng)用項(xiàng)目中的實(shí)際治理經(jīng)驗(yàn)涉及具體工具時(shí)會(huì)說(shuō)明選型理由涉及參數(shù)時(shí)會(huì)給出計(jì)算過程涉及操作時(shí)會(huì)提供可直接復(fù)現(xiàn)的方案。2. 治理體系的整體設(shè)計(jì)與核心思路拆解2.1 為什么不能把Demo代碼直接搬上生產(chǎn)Demo和生產(chǎn)之間隔著的不是一行部署命令而是整個(gè)工程化思維的差距。Demo的隱含假設(shè)是請(qǐng)求量小、輸入可控、輸出有人工兜底、失敗了大不了重跑。生產(chǎn)環(huán)境的現(xiàn)實(shí)是并發(fā)不可預(yù)測(cè)、輸入五花八門、輸出直接影響用戶體驗(yàn)或業(yè)務(wù)決策、失敗必須自動(dòng)處理。我見過太多團(tuán)隊(duì)把Demo代碼直接包一層Web框架就上線結(jié)果第一周就遇到這些問題模型接口超時(shí)導(dǎo)致整個(gè)請(qǐng)求鏈路卡死、用戶輸入超長(zhǎng)文本把Token預(yù)算打爆、模型返回格式不符合預(yù)期導(dǎo)致下游解析崩潰、同一個(gè)問題不同時(shí)間問得到完全不同的答案引發(fā)用戶投訴。這些問題的根源不在于模型本身而在于缺少一層工程化的治理架構(gòu)。治理體系的設(shè)計(jì)目標(biāo)可以歸納為四個(gè)詞可控、可觀測(cè)、可恢復(fù)、可迭代?？煽厥侵笇?duì)請(qǐng)求、成本、質(zhì)量有明確的約束手段可觀測(cè)是指任何一次調(diào)用都能追溯輸入、輸出、耗時(shí)、成本可恢復(fù)是指出現(xiàn)異常時(shí)有降級(jí)、重試、熔斷機(jī)制可迭代是指能基于真實(shí)數(shù)據(jù)持續(xù)優(yōu)化提示詞和模型配置。2.2 分層治理架構(gòu)的設(shè)計(jì)邏輯我把AI應(yīng)用的治理體系分成四層從下到上依次是模型接入層、服務(wù)編排層、質(zhì)量保障層、運(yùn)營(yíng)監(jiān)控層。這個(gè)分層不是拍腦袋定的而是按照“關(guān)注點(diǎn)分離”的原則讓每一層只解決一類問題層與層之間通過明確的接口交互。模型接入層負(fù)責(zé)統(tǒng)一管理所有模型提供方的接口包括認(rèn)證、限流、重試、超時(shí)設(shè)置。這一層的核心價(jià)值是解耦——業(yè)務(wù)代碼不直接依賴某個(gè)具體模型切換模型時(shí)只改配置不改代碼。服務(wù)編排層負(fù)責(zé)提示詞組裝、上下文管理、多模型路由、結(jié)果后處理。質(zhì)量保障層負(fù)責(zé)輸出校驗(yàn)、格式約束、敏感內(nèi)容過濾、幻覺檢測(cè)。運(yùn)營(yíng)監(jiān)控層負(fù)責(zé)成本統(tǒng)計(jì)、性能指標(biāo)采集、告警、日志歸檔。為什么要這樣分層因?yàn)锳I應(yīng)用的問題往往跨層出現(xiàn)。比如“響應(yīng)慢”可能是模型接入層的超時(shí)設(shè)置不合理也可能是服務(wù)編排層的上下文太長(zhǎng)還可能是質(zhì)量保障層的校驗(yàn)邏輯太重。分層之后排查問題時(shí)有明確的切入點(diǎn)優(yōu)化時(shí)也能精準(zhǔn)定位到某一層。2.3 關(guān)鍵選型背后的考量在治理工具選型上有幾個(gè)關(guān)鍵決策點(diǎn)值得展開說(shuō)。模型接入方式直接用官方SDK還是自建統(tǒng)一網(wǎng)關(guān)我的建議是只要你的應(yīng)用可能用到兩個(gè)以上模型就應(yīng)該自建統(tǒng)一網(wǎng)關(guān)。原因很簡(jiǎn)單官方SDK的接口風(fēng)格、錯(cuò)誤碼、重試策略各不相同業(yè)務(wù)代碼里到處是if-else判斷用哪個(gè)模型維護(hù)成本極高。統(tǒng)一網(wǎng)關(guān)可以用輕量級(jí)方案實(shí)現(xiàn)核心是把不同模型的請(qǐng)求響應(yīng)映射到統(tǒng)一格式。提示詞管理硬編碼在代碼里還是獨(dú)立管理Demo階段硬編碼沒問題生產(chǎn)環(huán)境必須獨(dú)立管理。提示詞是AI應(yīng)用的核心資產(chǎn)需要版本控制、灰度發(fā)布、A/B測(cè)試的能力。我通常用配置文件加版本號(hào)的方式管理配合簡(jiǎn)單的發(fā)布流程不一定要上復(fù)雜的平臺(tái)。監(jiān)控方案自建還是用現(xiàn)成APM如果團(tuán)隊(duì)已有APM體系優(yōu)先接入現(xiàn)有體系減少運(yùn)維負(fù)擔(dān)。如果沒有建議從輕量級(jí)方案起步核心是采集每次調(diào)用的輸入長(zhǎng)度、輸出長(zhǎng)度、耗時(shí)、Token消耗、模型名稱、狀態(tài)碼這幾個(gè)字段存到結(jié)構(gòu)化存儲(chǔ)里用簡(jiǎn)單的看板展示。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 模型接入層的統(tǒng)一網(wǎng)關(guān)實(shí)現(xiàn)統(tǒng)一網(wǎng)關(guān)的核心職責(zé)是屏蔽不同模型提供方的差異。具體來(lái)說(shuō)需要統(tǒng)一四個(gè)方面請(qǐng)求格式、響應(yīng)格式、錯(cuò)誤碼、重試策略。請(qǐng)求格式統(tǒng)一的關(guān)鍵是定義一個(gè)內(nèi)部請(qǐng)求結(jié)構(gòu)包含模型標(biāo)識(shí)、消息列表、溫度參數(shù)、最大Token數(shù)、超時(shí)時(shí)間等字段。然后為每個(gè)模型提供方寫一個(gè)適配器把內(nèi)部請(qǐng)求轉(zhuǎn)換成該提供方的格式。響應(yīng)格式統(tǒng)一則是把不同提供方的返回結(jié)構(gòu)映射成內(nèi)部響應(yīng)結(jié)構(gòu)包含內(nèi)容、Token消耗、結(jié)束原因等字段。錯(cuò)誤碼統(tǒng)一是最容易被忽視但最重要的部分。不同提供方的錯(cuò)誤碼體系完全不同有的用HTTP狀態(tài)碼有的在響應(yīng)體里返回錯(cuò)誤碼有的用異常拋出。統(tǒng)一網(wǎng)關(guān)需要把這些映射成內(nèi)部錯(cuò)誤碼至少區(qū)分這幾類認(rèn)證失敗、限流、超時(shí)、內(nèi)容被攔截、服務(wù)不可用、請(qǐng)求格式錯(cuò)誤。這樣上層業(yè)務(wù)代碼只需要處理內(nèi)部錯(cuò)誤碼不用關(guān)心底層是哪個(gè)模型。重試策略需要區(qū)分錯(cuò)誤類型。認(rèn)證失敗和請(qǐng)求格式錯(cuò)誤重試沒有意義直接失敗。限流和服務(wù)不可用可以重試但要配合指數(shù)退避。超時(shí)是否重試取決于業(yè)務(wù)對(duì)延遲的容忍度如果用戶端等待時(shí)間有限重試可能讓總延遲更長(zhǎng)這時(shí)候更適合降級(jí)到備用模型。# 統(tǒng)一網(wǎng)關(guān)的核心適配器結(jié)構(gòu)示例 class ModelAdapter: def build_request(self, internal_req): # 把內(nèi)部請(qǐng)求轉(zhuǎn)換成具體模型的請(qǐng)求格式 pass def parse_response(self, raw_response): # 把模型響應(yīng)轉(zhuǎn)換成內(nèi)部響應(yīng)格式 pass def map_error(self, raw_error): # 把模型錯(cuò)誤映射成內(nèi)部錯(cuò)誤碼 pass def should_retry(self, internal_error): # 根據(jù)內(nèi)部錯(cuò)誤碼判斷是否重試 pass注意統(tǒng)一網(wǎng)關(guān)本身不能成為單點(diǎn)故障。網(wǎng)關(guān)的超時(shí)設(shè)置必須比模型調(diào)用的超時(shí)設(shè)置更長(zhǎng)否則會(huì)出現(xiàn)網(wǎng)關(guān)已經(jīng)超時(shí)返回但模型調(diào)用還在繼續(xù)的情況造成資源浪費(fèi)。3.2 提示詞版本控制與灰度發(fā)布提示詞是AI應(yīng)用的“源代碼”但很多團(tuán)隊(duì)對(duì)它的管理還不如對(duì)代碼的管理嚴(yán)格。代碼有Git、有Code Review、有版本號(hào)提示詞卻經(jīng)常是某個(gè)人在某個(gè)深夜直接改線上配置。我的做法是把提示詞當(dāng)作配置文件管理每個(gè)提示詞有唯一標(biāo)識(shí)和版本號(hào)存儲(chǔ)在版本控制系統(tǒng)中。發(fā)布流程分三步先在測(cè)試環(huán)境驗(yàn)證新版本提示詞的效果然后用灰度發(fā)布把新版本推給一小部分流量觀察關(guān)鍵指標(biāo)沒有退化后再全量。灰度發(fā)布的關(guān)鍵是流量分配策略。最簡(jiǎn)單的做法是按用戶ID哈希取模比如哈希值小于10的走新版本其余走舊版本。更精細(xì)的做法是按用戶分層比如先讓內(nèi)部用戶用新版本再讓低活躍用戶用最后全量。無(wú)論哪種策略都要保證同一個(gè)用戶在同一會(huì)話中始終使用同一個(gè)版本否則會(huì)出現(xiàn)前后回答風(fēng)格不一致的問題。提示詞版本回滾必須是一鍵操作。我見過因?yàn)樾绿崾驹~導(dǎo)致輸出質(zhì)量下降但回滾流程要走半小時(shí)發(fā)布流程的情況那半小時(shí)里用戶一直在受影響的版本上。所以提示詞配置的加載應(yīng)該是熱加載回滾只需要改一個(gè)版本號(hào)配置。3.3 推理成本治理的參數(shù)計(jì)算成本治理是AI應(yīng)用從Demo到生產(chǎn)必須跨過的坎。Demo階段可能一天調(diào)用幾百次生產(chǎn)環(huán)境一天調(diào)用幾十萬(wàn)次成本差異是數(shù)量級(jí)的。成本治理的第一步是搞清楚錢花在哪里。每次調(diào)用需要記錄輸入Token數(shù)、輸出Token數(shù)、模型單價(jià)、調(diào)用時(shí)間。然后按業(yè)務(wù)維度聚合比如按功能模塊、按用戶群體、按時(shí)間段。這樣能發(fā)現(xiàn)哪些功能消耗了大部分預(yù)算哪些時(shí)段是調(diào)用高峰。第二步是優(yōu)化。優(yōu)化手段按性價(jià)比排序首先是減少無(wú)效調(diào)用比如用戶重復(fù)問同一個(gè)問題、輸入明顯不完整時(shí)直接返回引導(dǎo)而不是調(diào)用模型其次是壓縮輸入把提示詞中冗余的部分刪掉把歷史上下文做摘要而不是全量傳入然后是調(diào)整輸出長(zhǎng)度很多場(chǎng)景不需要模型長(zhǎng)篇大論設(shè)置合理的最大輸出Token數(shù)能顯著降低成本最后才是換更便宜的模型。這里給一個(gè)具體的計(jì)算示例。假設(shè)某功能每天調(diào)用10萬(wàn)次平均輸入500 Token輸出300 Token使用某模型輸入單價(jià)0.001元/千Token輸出單價(jià)0.002元/千Token。那么每天成本是輸入成本 100000 × 500 ÷ 1000 × 0.001 50元輸出成本 100000 × 300 ÷ 1000 × 0.002 60元合計(jì)110元/天。如果把輸入壓縮到300 Token輸出限制到200 Token成本變成輸入30元輸出40元合計(jì)70元/天降低36%。提示成本優(yōu)化不要一刀切。有些場(chǎng)景輸出質(zhì)量比成本重要比如面向付費(fèi)用戶的核心功能有些場(chǎng)景成本敏感比如內(nèi)部工具或免費(fèi)功能。按場(chǎng)景制定不同的成本策略而不是全局統(tǒng)一。3.4 輸出質(zhì)量監(jiān)控的落地方法AI應(yīng)用的輸出質(zhì)量監(jiān)控比傳統(tǒng)軟件難得多因?yàn)椤罢_”沒有明確標(biāo)準(zhǔn)。但生產(chǎn)環(huán)境不能等用戶投訴才發(fā)現(xiàn)問題需要建立自動(dòng)化的質(zhì)量監(jiān)控。我的做法是分三層監(jiān)控。第一層是格式校驗(yàn)檢查輸出是否符合預(yù)期格式比如JSON能否解析、是否包含必填字段、長(zhǎng)度是否在合理范圍。這一層能攔截大部分低級(jí)錯(cuò)誤。第二層是規(guī)則校驗(yàn)針對(duì)業(yè)務(wù)場(chǎng)景定義硬性規(guī)則比如客服場(chǎng)景不能出現(xiàn)競(jìng)品名稱、金融場(chǎng)景不能給出具體投資建議。第三層是模型校驗(yàn)用一個(gè)輕量級(jí)模型或規(guī)則引擎對(duì)輸出做二次判斷比如判斷回答是否與問題相關(guān)、是否包含明顯矛盾。三層監(jiān)控的優(yōu)先級(jí)不同。格式校驗(yàn)必須實(shí)時(shí)攔截不符合格式的直接重試或降級(jí)。規(guī)則校驗(yàn)可以實(shí)時(shí)告警但不必?cái)r截因?yàn)橐?guī)則可能有誤判。模型校驗(yàn)成本較高適合抽樣進(jìn)行比如對(duì)1%的請(qǐng)求做深度校驗(yàn)用于發(fā)現(xiàn)系統(tǒng)性問題。監(jiān)控指標(biāo)需要持續(xù)跟蹤趨勢(shì)。我通常關(guān)注這幾個(gè)指標(biāo)格式錯(cuò)誤率、規(guī)則命中率、用戶負(fù)反饋率、重試率、降級(jí)率。任何一個(gè)指標(biāo)突然上升都意味著可能有問題需要及時(shí)排查。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 從零搭建治理體系的完整步驟假設(shè)你手上有一個(gè)已經(jīng)跑通的AI Demo現(xiàn)在要把它改造成生產(chǎn)級(jí)應(yīng)用。我按實(shí)際操作順序把步驟拆開。第一步是梳理現(xiàn)有調(diào)用鏈路。把Demo中所有調(diào)用模型的地方找出來(lái)記錄每個(gè)調(diào)用點(diǎn)的輸入來(lái)源、輸出去向、調(diào)用頻率、延遲要求。這一步的目的是搞清楚治理的邊界在哪里。第二步是搭建統(tǒng)一網(wǎng)關(guān)。先實(shí)現(xiàn)最基本的請(qǐng)求轉(zhuǎn)發(fā)和響應(yīng)解析把現(xiàn)有調(diào)用點(diǎn)逐個(gè)遷移到網(wǎng)關(guān)上。遷移過程中保持行為一致不要同時(shí)改邏輯否則出問題分不清是遷移導(dǎo)致的還是邏輯改動(dòng)導(dǎo)致的。第三步是接入監(jiān)控。在網(wǎng)關(guān)上埋點(diǎn)記錄每次調(diào)用的關(guān)鍵字段。監(jiān)控?cái)?shù)據(jù)先存下來(lái)看板可以后做但數(shù)據(jù)必須從第一天就開始采集否則后面想分析歷史趨勢(shì)就沒有數(shù)據(jù)。第四步是配置提示詞管理。把硬編碼的提示詞抽出來(lái)放到配置文件中加上版本號(hào)。這一步不需要復(fù)雜的發(fā)布系統(tǒng)先用文件加版本號(hào)的方式跑起來(lái)。第五步是設(shè)置成本預(yù)算和告警。根據(jù)業(yè)務(wù)預(yù)期設(shè)定每日成本上限超過閾值時(shí)告警。告警要分級(jí)比如達(dá)到預(yù)算80%時(shí)提醒達(dá)到100%時(shí)限制非核心功能的調(diào)用。第六步是建立降級(jí)和熔斷機(jī)制。為每個(gè)模型配置備用模型主模型不可用時(shí)自動(dòng)切換。熔斷策略是當(dāng)某個(gè)模型的錯(cuò)誤率超過閾值時(shí)暫時(shí)停止調(diào)用該模型避免持續(xù)失敗拖垮整個(gè)系統(tǒng)。4.2 關(guān)鍵配置參數(shù)的計(jì)算與選擇治理體系中涉及大量參數(shù)配置這里挑幾個(gè)最關(guān)鍵的說(shuō)明計(jì)算邏輯。超時(shí)時(shí)間模型調(diào)用的超時(shí)時(shí)間應(yīng)該根據(jù)業(yè)務(wù)對(duì)延遲的容忍度來(lái)定。如果用戶端等待上限是10秒那么模型調(diào)用超時(shí)應(yīng)該設(shè)置在8秒左右留2秒給網(wǎng)絡(luò)傳輸和結(jié)果處理。如果模型在8秒內(nèi)沒返回直接降級(jí)或返回兜底內(nèi)容不要讓用戶繼續(xù)等。重試次數(shù)重試次數(shù)不是越多越好。假設(shè)單次調(diào)用超時(shí)8秒重試2次意味著最壞情況下用戶要等24秒這顯然不可接受。我的經(jīng)驗(yàn)是對(duì)于延遲敏感的場(chǎng)景最多重試1次且重試的超時(shí)時(shí)間要縮短比如第一次8秒重試時(shí)5秒。對(duì)于延遲不敏感的后臺(tái)任務(wù)可以重試2到3次。熔斷閾值熔斷器的核心參數(shù)是錯(cuò)誤率閾值和熔斷時(shí)長(zhǎng)。錯(cuò)誤率閾值通常設(shè)在50%左右即連續(xù)10次調(diào)用中超過5次失敗就熔斷。熔斷時(shí)長(zhǎng)從30秒起步如果熔斷后恢復(fù)仍然失敗逐步延長(zhǎng)熔斷時(shí)長(zhǎng)最長(zhǎng)不超過5分鐘。上下文長(zhǎng)度上下文長(zhǎng)度直接影響成本和延遲。我的做法是設(shè)置一個(gè)硬上限比如4000 Token超過這個(gè)長(zhǎng)度的歷史對(duì)話做摘要處理。摘要本身也消耗Token所以摘要的觸發(fā)閾值要合理比如歷史對(duì)話超過2000 Token時(shí)才觸發(fā)摘要。4.3 一次完整的故障排查記錄說(shuō)一個(gè)我實(shí)際遇到的故障。某天下午開始AI功能的平均響應(yīng)時(shí)間從1.2秒逐漸上升到4秒但沒有報(bào)錯(cuò)只是變慢。排查過程是這樣的。首先看監(jiān)控看板發(fā)現(xiàn)模型調(diào)用耗時(shí)本身沒有明顯變化但網(wǎng)關(guān)的總處理時(shí)間變長(zhǎng)了。這說(shuō)明問題不在模型側(cè)在網(wǎng)關(guān)側(cè)。然后看網(wǎng)關(guān)的日志發(fā)現(xiàn)請(qǐng)求排隊(duì)時(shí)間變長(zhǎng)了。進(jìn)一步看是連接池被打滿了。為什么連接池會(huì)打滿查了一下發(fā)現(xiàn)是上游業(yè)務(wù)方在下午上線了一個(gè)新功能這個(gè)功能會(huì)批量調(diào)用AI接口每次調(diào)用并發(fā)數(shù)很高。連接池的配置是最大100個(gè)連接新功能的并發(fā)請(qǐng)求把連接占滿了其他請(qǐng)求只能排隊(duì)。解決方案有兩個(gè)一是擴(kuò)大連接池二是給不同業(yè)務(wù)方設(shè)置獨(dú)立的連接池或限流。我選擇了后者因?yàn)閿U(kuò)大連接池只是推遲問題不同業(yè)務(wù)方互相影響才是根本問題。給每個(gè)業(yè)務(wù)方分配獨(dú)立的連接配額后問題解決。這個(gè)故障給我的教訓(xùn)是治理體系必須考慮多租戶場(chǎng)景。即使是內(nèi)部系統(tǒng)不同調(diào)用方的行為模式也可能差異巨大必須做隔離。4.4 數(shù)據(jù)回流與持續(xù)優(yōu)化機(jī)制AI應(yīng)用的治理不是一次性的需要持續(xù)優(yōu)化。優(yōu)化的依據(jù)來(lái)自數(shù)據(jù)回流——把生產(chǎn)環(huán)境中的真實(shí)調(diào)用數(shù)據(jù)收集起來(lái)用于改進(jìn)提示詞、調(diào)整參數(shù)、發(fā)現(xiàn)新問題。數(shù)據(jù)回流的關(guān)鍵是脫敏和采樣。生產(chǎn)數(shù)據(jù)包含用戶隱私不能直接用于分析需要先脫敏。采樣是因?yàn)槿繑?shù)據(jù)太大分析成本高通常采樣1%到5%就足夠發(fā)現(xiàn)趨勢(shì)性問題?；亓鲾?shù)據(jù)的主要用途有三個(gè)。一是發(fā)現(xiàn)bad case把用戶負(fù)反饋的請(qǐng)求找出來(lái)分析是提示詞問題、模型能力問題還是輸入本身有問題。二是優(yōu)化提示詞把典型的好案例和壞案例作為few-shot示例加入提示詞提升效果。三是調(diào)整路由策略如果發(fā)現(xiàn)某類問題在某個(gè)模型上表現(xiàn)更好就調(diào)整路由規(guī)則把這類問題導(dǎo)向那個(gè)模型。我通常每周做一次回流數(shù)據(jù)分析每月做一次提示詞和參數(shù)的批量?jī)?yōu)化。這個(gè)節(jié)奏既能及時(shí)響應(yīng)問題又不會(huì)因?yàn)轭l繁改動(dòng)導(dǎo)致系統(tǒng)不穩(wěn)定。5. 常見問題與排查技巧實(shí)錄5.1 典型問題速查表問題現(xiàn)象可能原因排查方向解決手段響應(yīng)時(shí)間突然變長(zhǎng)連接池打滿、模型側(cè)限流、上下文過長(zhǎng)看網(wǎng)關(guān)排隊(duì)時(shí)間、模型調(diào)用耗時(shí)、輸入Token數(shù)擴(kuò)容連接池、限流、壓縮上下文輸出格式不穩(wěn)定提示詞約束不夠、模型版本變化對(duì)比不同時(shí)間的輸出樣本、檢查模型版本加強(qiáng)格式約束、固定模型版本成本突然上升調(diào)用量增加、輸入輸出變長(zhǎng)、模型切換按維度聚合成本、對(duì)比歷史數(shù)據(jù)限流、壓縮輸入、換模型錯(cuò)誤率上升模型服務(wù)異常、認(rèn)證過期、網(wǎng)絡(luò)問題看錯(cuò)誤碼分布、檢查認(rèn)證配置切換備用模型、更新認(rèn)證用戶負(fù)反饋增加輸出質(zhì)量下降、提示詞改動(dòng)、模型退化分析負(fù)反饋樣本、對(duì)比改動(dòng)前后回滾提示詞、調(diào)整模型5.2 獨(dú)家避坑技巧第一個(gè)坑是忽視冷啟動(dòng)。模型服務(wù)在長(zhǎng)時(shí)間沒有請(qǐng)求后會(huì)進(jìn)入冷啟動(dòng)狀態(tài)第一次請(qǐng)求的延遲可能是正常情況的幾倍。如果業(yè)務(wù)有明顯的波峰波谷比如早上開始服務(wù)時(shí)第一批用戶會(huì)感受到明顯的延遲。解決辦法是設(shè)置定時(shí)預(yù)熱在業(yè)務(wù)高峰前幾分鐘發(fā)幾個(gè)測(cè)試請(qǐng)求把模型服務(wù)喚醒。第二個(gè)坑是提示詞中的隱藏字符。從文檔復(fù)制提示詞時(shí)經(jīng)常帶入不可見字符這些字符可能導(dǎo)致模型行為異常。我遇到過從網(wǎng)頁(yè)復(fù)制提示詞后模型輸出格式完全亂掉的情況排查了很久才發(fā)現(xiàn)是復(fù)制時(shí)帶入了特殊空格。建議提示詞統(tǒng)一用純文本編輯器編輯保存前做一次字符檢查。第三個(gè)坑是過度依賴單一模型。即使某個(gè)模型當(dāng)前表現(xiàn)最好也要準(zhǔn)備備用方案。模型服務(wù)可能因?yàn)楦鞣N原因不可用沒有備用方案意味著業(yè)務(wù)直接中斷。備用模型不一定要同樣強(qiáng)大能提供基本可用的降級(jí)服務(wù)就行。第四個(gè)坑是監(jiān)控?cái)?shù)據(jù)存太少。剛開始做監(jiān)控時(shí)容易只存聚合指標(biāo)不存原始調(diào)用記錄。等出問題時(shí)想查具體某次調(diào)用的輸入輸出發(fā)現(xiàn)沒有存只能干瞪眼。建議原始調(diào)用記錄至少保留7天聚合指標(biāo)保留90天。第五個(gè)坑是忽略小概率錯(cuò)誤。有些錯(cuò)誤發(fā)生率很低比如0.1%容易被忽略。但如果每天調(diào)用10萬(wàn)次0.1%就是100次錯(cuò)誤對(duì)用戶的影響不小。建議對(duì)任何非零的錯(cuò)誤率都保持關(guān)注分析清楚原因再?zèng)Q定是否接受。5.3 治理成熟度自評(píng)清單最后給一個(gè)自評(píng)清單你可以對(duì)照檢查自己的AI應(yīng)用治理到了什么程度。是否有統(tǒng)一的模型接入層切換模型不需要改業(yè)務(wù)代碼是否記錄了每次調(diào)用的輸入輸出、耗時(shí)、Token消耗是否有成本預(yù)算和告警機(jī)制提示詞是否有版本控制和回滾能力是否有輸出格式校驗(yàn)和降級(jí)策略是否有熔斷和重試機(jī)制且參數(shù)經(jīng)過計(jì)算而非拍腦袋是否有數(shù)據(jù)回流機(jī)制定期分析bad case是否有備用模型方案主模型不可用時(shí)能降級(jí)這八條里前四條是基礎(chǔ)做不到的話生產(chǎn)環(huán)境遲早出問題。后四條是進(jìn)階做到之后系統(tǒng)的穩(wěn)定性和迭代效率會(huì)有明顯提升。我個(gè)人在實(shí)際操作中的體會(huì)是治理體系的建設(shè)不要追求一步到位。先把監(jiān)控和統(tǒng)一網(wǎng)關(guān)做起來(lái)這兩個(gè)是基礎(chǔ)中的基礎(chǔ)。有了監(jiān)控?cái)?shù)據(jù)后面所有的優(yōu)化都有依據(jù)有了統(tǒng)一網(wǎng)關(guān)后面所有的策略調(diào)整都有抓手。至于提示詞管理、數(shù)據(jù)回流這些可以隨著業(yè)務(wù)發(fā)展逐步完善。最怕的是一上來(lái)就搭大而全的平臺(tái)結(jié)果平臺(tái)還沒搭完業(yè)務(wù)已經(jīng)等不及了。小步快跑邊用邊改才是AI應(yīng)用治理的正確節(jié)奏。