1. 從概念到生產(chǎn)Jev 決策系統(tǒng)的架構(gòu)選型與核心思路1.1 為什么“決策系統(tǒng)”和“聊天機(jī)器人”是兩回事很多人第一次接觸 Jev 這個(gè)概念時(shí)會(huì)下意識(shí)把它歸類到“又一個(gè) AI 對話工具”里。但如果你的目標(biāo)是把 Jev 從概念推進(jìn)到生產(chǎn)環(huán)境第一件必須想清楚的事就是決策系統(tǒng)和對話系統(tǒng)在架構(gòu)上是完全不同的物種。對話系統(tǒng)的核心指標(biāo)是“回復(fù)得像不像人”而決策系統(tǒng)的核心指標(biāo)是“在給定約束下選出的動(dòng)作是否可解釋、可回溯、可復(fù)現(xiàn)”。這兩者的差異直接決定了技術(shù)棧的選型。對話系統(tǒng)可以容忍一定的隨機(jī)性甚至把隨機(jī)性當(dāng)作“創(chuàng)造力”來賣但決策系統(tǒng)不行一個(gè)生產(chǎn)級(jí)的決策系統(tǒng)同一個(gè)輸入在同一個(gè)版本下必須給出同一個(gè)輸出否則下游的業(yè)務(wù)邏輯就沒法做回歸測試。我在實(shí)際搭建 Jev 類系統(tǒng)的過程中踩過的第一個(gè)大坑就是早期用純 Prompt 編排的方式來做決策。表面上看幾行提示詞就能讓模型輸出一個(gè)“建議動(dòng)作”Demo 跑起來非常漂亮。但一旦接入真實(shí)業(yè)務(wù)流問題就暴露了同一個(gè)訂單狀態(tài)今天問它建議退款明天問它建議換貨后天可能建議人工介入。這種不確定性在演示階段是“智能”在生產(chǎn)階段就是“事故”。所以 Jev 從概念到生產(chǎn)的第一條架構(gòu)原則是把決策邏輯從模型的黑盒里拽出來變成顯式的、可版本管理的組件。模型可以參與決策但不能獨(dú)占決策權(quán)。1.2 三層架構(gòu)感知層、決策層、執(zhí)行層的職責(zé)邊界一個(gè)能落地的 Jev 決策系統(tǒng)我傾向于把它拆成三層每層只做自己該做的事。感知層負(fù)責(zé)把外部世界的原始信號(hào)轉(zhuǎn)成結(jié)構(gòu)化狀態(tài)。比如用戶提交了一條售后請求感知層要做的不是直接讓模型判斷“該不該退款”而是先把訂單號(hào)、商品類目、下單時(shí)間、歷史售后次數(shù)、當(dāng)前庫存狀態(tài)這些字段抽取出來形成一個(gè)標(biāo)準(zhǔn)化的狀態(tài)向量。這一步用規(guī)則引擎或者輕量級(jí)模型都可以關(guān)鍵是輸出格式必須固定。決策層是 Jev 的核心。它接收感知層傳來的狀態(tài)向量輸出一個(gè)或多個(gè)候選動(dòng)作并附帶每個(gè)動(dòng)作的置信度和理由。這里有個(gè)設(shè)計(jì)上的關(guān)鍵取舍決策層到底用單一模型還是多模型投票我的經(jīng)驗(yàn)是生產(chǎn)環(huán)境優(yōu)先考慮“規(guī)則兜底 模型排序”的混合模式。規(guī)則負(fù)責(zé)處理那些邊界清晰、后果嚴(yán)重的場景比如金額超過閾值必須人工審核模型負(fù)責(zé)在規(guī)則劃定的安全區(qū)內(nèi)做精細(xì)化排序。這樣既保留了 AI 的靈活性又不會(huì)讓系統(tǒng)在關(guān)鍵路徑上失控。執(zhí)行層負(fù)責(zé)把決策層的輸出翻譯成具體的 API 調(diào)用、工單流轉(zhuǎn)或者消息推送。這一層最重要的是冪等性和可回滾。Jev 給出的每一個(gè)動(dòng)作執(zhí)行層都要記錄完整的上下文快照一旦發(fā)現(xiàn)決策有誤能夠快速回滾到上一個(gè)穩(wěn)定狀態(tài)。這三層的邊界一旦模糊系統(tǒng)就會(huì)變得難以維護(hù)。我見過不少項(xiàng)目把感知和決策揉在一起結(jié)果就是每次調(diào)整業(yè)務(wù)規(guī)則都要?jiǎng)幽Ｐ吞崾驹~每次換模型又要重新驗(yàn)證業(yè)務(wù)規(guī)則耦合度太高迭代速度反而比純規(guī)則系統(tǒng)還慢。1.3 從概念驗(yàn)證到生產(chǎn)部署的四個(gè)階段Jev 的落地不是一步到位的我把它分成四個(gè)階段每個(gè)階段有明確的退出標(biāo)準(zhǔn)。第一階段是離線回放。拿歷史數(shù)據(jù)跑一遍看決策層的輸出和人工歷史決策的吻合度。這個(gè)階段不追求完全一致重點(diǎn)是找出模型在哪些類型的場景下容易跑偏。吻合度低于 70% 的話不要急著上線先回去檢查感知層的字段抽取是不是漏了關(guān)鍵信息。第二階段是影子模式。系統(tǒng)在線運(yùn)行但決策結(jié)果不真正執(zhí)行只是記錄下來和人工決策做對比。這個(gè)階段通常要跑兩周以上覆蓋足夠多的業(yè)務(wù)周期。影子模式最大的價(jià)值是暴露那些離線數(shù)據(jù)里沒有的長尾場景比如大促期間的異常訂單、系統(tǒng)故障時(shí)的降級(jí)請求。第三階段是灰度執(zhí)行。選擇低風(fēng)險(xiǎn)場景讓 Jev 真正執(zhí)行決策比如小額退款、標(biāo)準(zhǔn)換貨。這個(gè)階段要設(shè)置嚴(yán)格的熔斷機(jī)制一旦決策失敗率超過閾值自動(dòng)切回人工?；叶绕陂g每天都要做決策日志的抽樣復(fù)盤我一般會(huì)抽 50 到 100 條逐條看決策理由是否合理。第四階段是全量生產(chǎn)。這時(shí)候 Jev 已經(jīng)積累了足夠的決策日志和人工反饋可以逐步擴(kuò)大執(zhí)行范圍。但即使在全量階段也要保留人工介入的入口并且定期做決策質(zhì)量的回歸測試。2. 核心細(xì)節(jié)解析Jev 決策系統(tǒng)的關(guān)鍵組件與實(shí)操要點(diǎn)2.1 狀態(tài)表示決策系統(tǒng)的地基Jev 決策質(zhì)量的上限在狀態(tài)表示這一步就已經(jīng)決定了。如果感知層輸出的狀態(tài)向量遺漏了關(guān)鍵維度后面的模型再強(qiáng)也補(bǔ)不回來。我在設(shè)計(jì)狀態(tài)表示時(shí)遵循一個(gè)原則每個(gè)字段都要能回答“這個(gè)字段缺失時(shí)決策會(huì)不會(huì)變”。如果答案是不會(huì)變那這個(gè)字段就是冗余的應(yīng)該砍掉。如果答案是會(huì)變那就要確保這個(gè)字段在線上環(huán)境是穩(wěn)定可獲取的。舉個(gè)例子售后決策場景里“用戶歷史售后次數(shù)”這個(gè)字段很重要但“用戶注冊時(shí)長”可能就沒那么關(guān)鍵。前者直接影響風(fēng)險(xiǎn)判斷后者更多是輔助信息。字段太多不僅增加計(jì)算開銷還會(huì)引入噪聲讓模型學(xué)到一些虛假的相關(guān)性。狀態(tài)表示還有一個(gè)容易被忽視的點(diǎn)時(shí)間窗口。同一個(gè)字段取最近 7 天、30 天還是 90 天的數(shù)據(jù)決策結(jié)果可能完全不同。我的做法是把時(shí)間窗口作為配置項(xiàng)暴露出來在離線回放階段做對比實(shí)驗(yàn)選一個(gè)在驗(yàn)證集上表現(xiàn)最穩(wěn)定的窗口。不要拍腦袋定也不要盲目取“全部歷史”因?yàn)樘眠h(yuǎn)的數(shù)據(jù)可能反映的是完全不同的業(yè)務(wù)環(huán)境。2.2 決策引擎的規(guī)則與模型協(xié)同規(guī)則和模型怎么協(xié)同是 Jev 架構(gòu)里最需要花心思的地方。我試過三種模式各有適用場景。第一種是規(guī)則前置。規(guī)則先做一輪過濾把明顯違規(guī)或者高風(fēng)險(xiǎn)的請求直接攔截剩下的交給模型排序。這種模式適合風(fēng)控類場景規(guī)則負(fù)責(zé)守住底線模型負(fù)責(zé)在安全區(qū)內(nèi)做優(yōu)化。第二種是模型前置。模型先給出候選動(dòng)作和置信度規(guī)則再對高置信度的動(dòng)作做二次校驗(yàn)。這種模式適合推薦類場景模型負(fù)責(zé)發(fā)現(xiàn)機(jī)會(huì)規(guī)則負(fù)責(zé)防止越界。第三種是并行投票。規(guī)則和模型各自獨(dú)立輸出最后用一個(gè)融合層做加權(quán)。這種模式最靈活但也最難調(diào)因?yàn)闄?quán)重怎么定、沖突怎么解都需要大量實(shí)驗(yàn)。我目前在生產(chǎn)環(huán)境用的是規(guī)則前置為主、模型前置為輔的混合模式。具體來說金額超過 500 元的售后請求走規(guī)則前置必須人工審核500 元以下的走模型前置模型給出建議后規(guī)則做快速校驗(yàn)。這個(gè)閾值不是拍腦袋定的是根據(jù)歷史數(shù)據(jù)里人工審核的介入率和誤判成本算出來的。2.3 置信度校準(zhǔn)讓模型的“自信”變得可信模型輸出的置信度如果不做校準(zhǔn)基本沒法直接用。我見過太多模型在明顯該猶豫的時(shí)候給出 0.95 的置信度結(jié)果一執(zhí)行就出錯(cuò)。置信度校準(zhǔn)的常用方法是 Platt Scaling 或者 Isotonic Regression但我想說的是校準(zhǔn)的前提是你有足夠的標(biāo)注數(shù)據(jù)。如果標(biāo)注數(shù)據(jù)只有幾百條校準(zhǔn)反而可能過擬合。這種情況下我更傾向于用分桶的方式做粗校準(zhǔn)把置信度分成 0.5 以下、0.5 到 0.7、0.7 到 0.9、0.9 以上四個(gè)桶每個(gè)桶統(tǒng)計(jì)實(shí)際準(zhǔn)確率然后根據(jù)實(shí)際準(zhǔn)確率來設(shè)定執(zhí)行策略。比如 0.9 以上的桶實(shí)際準(zhǔn)確率只有 0.75那就說明模型在這個(gè)區(qū)間過度自信執(zhí)行時(shí)就要更謹(jǐn)慎。這種粗校準(zhǔn)雖然不夠精細(xì)但在數(shù)據(jù)有限的情況下更穩(wěn)健。還有一個(gè)實(shí)操技巧把置信度和業(yè)務(wù)后果掛鉤。同樣是 0.8 的置信度如果決策后果是“發(fā)一張 5 元優(yōu)惠券”那可以直接執(zhí)行如果后果是“關(guān)閉用戶賬號(hào)”那就必須人工復(fù)核。置信度閾值不是固定的而是隨決策風(fēng)險(xiǎn)動(dòng)態(tài)調(diào)整的。2.4 決策日志生產(chǎn)環(huán)境的黑匣子Jev 上線后決策日志就是你的黑匣子。日志設(shè)計(jì)得好不好直接決定了你排查問題的速度。我要求的決策日志必須包含以下字段請求 ID、時(shí)間戳、狀態(tài)向量快照、規(guī)則命中情況、模型版本、模型原始輸出、校準(zhǔn)后置信度、最終決策、執(zhí)行結(jié)果、人工反饋如果有。這些字段缺一不可尤其是狀態(tài)向量快照和模型版本沒有這兩個(gè)你根本沒法復(fù)現(xiàn)問題。日志的存儲(chǔ)也有講究。我一般用結(jié)構(gòu)化存儲(chǔ)比如 PostgreSQL 或者 ClickHouse方便做聚合查詢。不要用純文本日志排查問題時(shí) grep 起來太痛苦。另外日志要設(shè)置合理的保留周期生產(chǎn)環(huán)境至少保留 90 天重要業(yè)務(wù)建議保留一年。注意決策日志里可能包含用戶敏感信息存儲(chǔ)和訪問都要做脫敏和權(quán)限控制。我通常會(huì)把狀態(tài)向量里的用戶標(biāo)識(shí)字段做哈希處理只保留可關(guān)聯(lián)性不保留原始值。3. 實(shí)操過程Jev 從零到生產(chǎn)的關(guān)鍵環(huán)節(jié)實(shí)現(xiàn)3.1 環(huán)境準(zhǔn)備與依賴管理Jev 系統(tǒng)的環(huán)境準(zhǔn)備我建議從一開始就用容器化方案。不是為了趕時(shí)髦而是因?yàn)闆Q策系統(tǒng)對依賴版本非常敏感。模型推理庫、特征計(jì)算庫、規(guī)則引擎任何一個(gè)版本變動(dòng)都可能影響決策結(jié)果。我的做法是給每個(gè)組件單獨(dú)打鏡像用 Docker Compose 或者 Kubernetes 做編排。模型服務(wù)、規(guī)則服務(wù)、日志服務(wù)各自獨(dú)立通過內(nèi)部 API 通信。這樣升級(jí)某個(gè)組件時(shí)不會(huì)影響其他部分。依賴管理方面Python 環(huán)境我強(qiáng)烈建議用 Poetry 或者 PDM不要用裸 pip。因?yàn)闆Q策系統(tǒng)經(jīng)常需要鎖定模型推理庫的版本裸 pip 的依賴解析在復(fù)雜項(xiàng)目里很容易出問題。下面是一個(gè)典型的依賴聲明示例[tool.poetry.dependencies] python ^3.10 fastapi ^0.104.0 pydantic ^2.4.0 onnxruntime ^1.16.0 scikit-learn ^1.3.0 psycopg2-binary ^2.9.0模型文件的管理也要規(guī)范。我一般會(huì)把模型文件放在對象存儲(chǔ)里用版本號(hào)做路徑區(qū)分比如models/jev-decision/v1.2.3/model.onnx。服務(wù)啟動(dòng)時(shí)根據(jù)配置拉取對應(yīng)版本而不是把模型文件直接打進(jìn)鏡像。這樣換模型不用重新構(gòu)建鏡像回滾也方便。3.2 狀態(tài)向量的構(gòu)建與特征工程狀態(tài)向量的構(gòu)建我分成三步字段抽取、特征計(jì)算、向量拼接。字段抽取是從原始請求里拿到基礎(chǔ)信息。這一步用 Pydantic 做校驗(yàn)和類型轉(zhuǎn)換確保每個(gè)字段的類型和取值范圍符合預(yù)期。比如訂單金額必須是正數(shù)用戶 ID 必須是字符串時(shí)間戳必須是 ISO 格式。特征計(jì)算是在基礎(chǔ)字段上做衍生。比如“用戶歷史售后次數(shù)”需要查數(shù)據(jù)庫“近 7 天退款率”需要做窗口聚合。這些計(jì)算我一般會(huì)做成獨(dú)立的特征服務(wù)用 Redis 做緩存避免每次請求都查庫。向量拼接是把所有特征按固定順序拼成一個(gè)數(shù)組。順序很重要訓(xùn)練和推理必須一致。我通常會(huì)把特征順序?qū)懺谝粋€(gè)配置文件里訓(xùn)練和推理都讀同一個(gè)配置避免人為出錯(cuò)。下面是一個(gè)簡化的特征配置示例features: - name: order_amount type: float source: request - name: user_refund_count_7d type: int source: feature_store window: 7d - name: product_category_risk type: float source: feature_store特征工程里最容易出問題的是訓(xùn)練/推理不一致。離線訓(xùn)練時(shí)用的特征計(jì)算邏輯和線上推理時(shí)用的邏輯必須完全一致。我見過太多項(xiàng)目因?yàn)殡x線用 Pandas 算、線上用 SQL 算導(dǎo)致同一個(gè)特征在兩個(gè)環(huán)境里數(shù)值對不上。解決辦法只有一個(gè)把特征計(jì)算邏輯封裝成共享庫離線和線上都調(diào)同一個(gè)函數(shù)。3.3 決策引擎的部署與灰度策略決策引擎的部署我推薦用藍(lán)綠部署加灰度流量的組合。藍(lán)綠部署保證新版本上線時(shí)舊版本隨時(shí)可以切回來。具體操作是維護(hù)兩套完全獨(dú)立的環(huán)境綠環(huán)境跑當(dāng)前穩(wěn)定版藍(lán)環(huán)境跑新版本。流量切換通過負(fù)載均衡器控制切換前先在藍(lán)環(huán)境跑一輪離線回放和影子測試?；叶攘髁渴窃谒{(lán)綠部署的基礎(chǔ)上進(jìn)一步控制新版本的影響范圍。我一般會(huì)按用戶 ID 哈希做分流先放 1% 的流量到新版本觀察 24 小時(shí)。如果決策失敗率、人工介入率、用戶投訴率這些指標(biāo)沒有明顯惡化再逐步擴(kuò)大到 5%、10%、50%最后全量?；叶绕陂g要重點(diǎn)監(jiān)控的指標(biāo)包括決策執(zhí)行成功率、決策延遲 P99、人工復(fù)核率、決策結(jié)果分布變化。其中決策結(jié)果分布變化最容易被忽視但它往往是最早的預(yù)警信號(hào)。如果新版本上線后某個(gè)動(dòng)作的占比突然從 10% 跳到 30%即使成功率沒降也說明決策邏輯發(fā)生了顯著變化需要人工介入確認(rèn)是否合理。3.4 執(zhí)行層的冪等與回滾設(shè)計(jì)執(zhí)行層是 Jev 和真實(shí)世界交互的最后一環(huán)這里出問題就是真金白銀的損失。冪等設(shè)計(jì)是底線。每個(gè)決策動(dòng)作都要帶一個(gè)唯一的事務(wù) ID執(zhí)行層在處理前先檢查這個(gè) ID 是否已經(jīng)執(zhí)行過。如果已經(jīng)執(zhí)行直接返回上次的結(jié)果不要重復(fù)執(zhí)行。這個(gè)檢查用數(shù)據(jù)庫的唯一索引就能實(shí)現(xiàn)成本很低但能避免大量重復(fù)退款、重復(fù)發(fā)券的事故?；貪L設(shè)計(jì)是保險(xiǎn)。每個(gè)執(zhí)行動(dòng)作都要記錄反向操作所需的信息。比如退款操作要記錄退款金額和收款賬戶回滾時(shí)才能原路退回?；貪L不是萬能的有些操作比如已經(jīng)發(fā)出的短信沒法回滾所以執(zhí)行前要做好風(fēng)險(xiǎn)評(píng)估能回滾的優(yōu)先走可回滾路徑。提示執(zhí)行層的超時(shí)設(shè)置要合理。我一般把決策引擎的超時(shí)設(shè)為 500ms執(zhí)行層的超時(shí)設(shè)為 2s。決策引擎超時(shí)后返回“建議人工介入”執(zhí)行層超時(shí)后觸發(fā)異步重試。不要讓請求無限等待否則會(huì)拖垮整個(gè)鏈路。4. 常見問題與排查技巧實(shí)錄4.1 決策結(jié)果不穩(wěn)定同一輸入不同輸出這是 Jev 上線后最常見的問題。原因通常有三個(gè)模型推理有隨機(jī)性、特征計(jì)算有波動(dòng)、規(guī)則命中順序不確定。模型推理的隨機(jī)性主要來自 Dropout 和采樣策略。生產(chǎn)環(huán)境必須關(guān)閉 Dropout采樣策略要改成貪心或者 Beam Search 固定寬度。如果用的是第三方模型服務(wù)要確認(rèn)它的推理參數(shù)是否固定。特征計(jì)算的波動(dòng)往往來自數(shù)據(jù)延遲。比如“近 7 天退款率”這個(gè)特征如果數(shù)據(jù)庫同步有延遲不同時(shí)間點(diǎn)算出來的值可能不一樣。解決辦法是給特征計(jì)算加上時(shí)間戳對齊所有特征都基于同一個(gè)數(shù)據(jù)快照計(jì)算。規(guī)則命中順序不確定通常是因?yàn)橐?guī)則引擎的優(yōu)先級(jí)配置有問題。我一般會(huì)把規(guī)則按優(yōu)先級(jí)排序同優(yōu)先級(jí)的規(guī)則按規(guī)則 ID 排序確保每次執(zhí)行的順序完全一致。排查這類問題時(shí)我會(huì)用同一個(gè)請求 ID 反復(fù)調(diào)用決策引擎對比每次的輸出。如果輸出有差異就逐層排查先看狀態(tài)向量是否一致再看規(guī)則命中是否一致最后看模型輸出是否一致。定位到具體層之后再深入查該層的日志。4.2 模型置信度虛高為什么 0.95 的置信度也會(huì)出錯(cuò)置信度虛高的根本原因是模型在訓(xùn)練集上過擬合了。訓(xùn)練集里某些模式出現(xiàn)頻率高模型就學(xué)會(huì)了“看到這個(gè)模式就給高置信度”但這些模式在真實(shí)環(huán)境里可能并不穩(wěn)定。解決這個(gè)問題我通常從三個(gè)方向入手。第一是增加訓(xùn)練數(shù)據(jù)的多樣性尤其是那些模型容易過度自信的場景要刻意多采樣一些。第二是引入不確定性估計(jì)比如用 MC Dropout 或者 Deep Ensemble讓模型在不確定時(shí)給出更保守的置信度。第三是做置信度校準(zhǔn)用驗(yàn)證集擬合一個(gè)校準(zhǔn)曲線把模型的原始置信度映射到更接近真實(shí)準(zhǔn)確率的區(qū)間。實(shí)操中我還會(huì)設(shè)置一個(gè)置信度上限。即使模型給出 0.99系統(tǒng)也只認(rèn) 0.95。這個(gè)上限根據(jù)業(yè)務(wù)風(fēng)險(xiǎn)來定高風(fēng)險(xiǎn)場景可以設(shè)到 0.9。這樣做的目的是防止模型在極端情況下給出過于激進(jìn)的置信度給系統(tǒng)留一點(diǎn)安全邊際。4.3 決策延遲過高P99 超過 1 秒怎么辦決策延遲高通常是因?yàn)樘卣饔?jì)算太慢或者模型推理太慢。特征計(jì)算慢最常見的原因是查庫沒有索引或者窗口聚合的數(shù)據(jù)量太大。解決辦法是給特征存儲(chǔ)加緩存把常用的特征預(yù)計(jì)算好推理時(shí)直接讀緩存。緩存更新可以用定時(shí)任務(wù)也可以用事件驅(qū)動(dòng)根據(jù)業(yè)務(wù)對實(shí)時(shí)性的要求來選。模型推理慢如果是大模型可以考慮蒸餾成小模型或者用量化技術(shù)壓縮模型體積。如果是小模型但推理還是慢檢查一下是不是用了 CPU 推理換成 GPU 或者專用推理芯片通常能提升一個(gè)數(shù)量級(jí)。還有一個(gè)容易被忽視的點(diǎn)批處理。如果決策請求是并發(fā)的可以把多個(gè)請求攢成一批一起推理這樣能顯著提升吞吐量。但批處理會(huì)增加單次延遲所以要根據(jù)業(yè)務(wù)對延遲的容忍度來定批處理窗口。我一般會(huì)把窗口設(shè)在 10ms 到 50ms 之間既能提升吞吐又不會(huì)明顯增加延遲。4.4 常見問題速查表問題現(xiàn)象可能原因排查方法解決措施同一輸入不同輸出模型隨機(jī)性、特征波動(dòng)、規(guī)則順序固定請求 ID 反復(fù)調(diào)用逐層對比關(guān)閉 Dropout、特征時(shí)間對齊、規(guī)則排序置信度虛高訓(xùn)練過擬合、缺乏不確定性估計(jì)驗(yàn)證集校準(zhǔn)曲線、分桶統(tǒng)計(jì)準(zhǔn)確率增加數(shù)據(jù)多樣性、MC Dropout、置信度上限決策延遲 P99 超 1s特征查庫慢、模型推理慢分段計(jì)時(shí)定位耗時(shí)環(huán)節(jié)特征緩存、模型量化、批處理灰度期間指標(biāo)惡化新版本決策邏輯變化對比新舊版本決策分布回滾、調(diào)整閾值、重新訓(xùn)練執(zhí)行層重復(fù)操作冪等檢查缺失檢查事務(wù) ID 唯一索引補(bǔ)冪等邏輯、加唯一約束人工復(fù)核率突然升高模型置信度整體下降統(tǒng)計(jì)置信度分布變化檢查特征質(zhì)量、重新校準(zhǔn)4.5 幾個(gè)我踩過的坑和對應(yīng)的經(jīng)驗(yàn)第一個(gè)坑是過早引入復(fù)雜模型。項(xiàng)目初期就用深度模型結(jié)果數(shù)據(jù)量不夠模型學(xué)不到東西還不如規(guī)則系統(tǒng)穩(wěn)定。后來我改成先用規(guī)則跑通流程積累數(shù)據(jù)后再逐步引入模型效果好很多。第二個(gè)坑是忽視決策日志的存儲(chǔ)成本。狀態(tài)向量快照占空間很大一開始沒做歸檔三個(gè)月后日志表就爆了。后來改成熱數(shù)據(jù)存 30 天冷數(shù)據(jù)壓縮后存對象存儲(chǔ)成本降了 80%。第三個(gè)坑是灰度期間只看成功率。成功率沒降就以為沒問題結(jié)果上線后發(fā)現(xiàn)決策分布偏了大量本該人工處理的請求被自動(dòng)執(zhí)行了。后來我在灰度監(jiān)控里加了決策分布對比這個(gè)問題才被及時(shí)發(fā)現(xiàn)。第四個(gè)坑是執(zhí)行層沒有做超時(shí)隔離。某個(gè)下游服務(wù)變慢導(dǎo)致執(zhí)行層線程池被占滿整個(gè)決策鏈路都堵住了。后來給每個(gè)下游服務(wù)單獨(dú)設(shè)了線程池和超時(shí)一個(gè)服務(wù)慢不會(huì)影響其他服務(wù)。這些經(jīng)驗(yàn)說到底就一句話Jev 從概念到生產(chǎn)難點(diǎn)不在模型本身而在模型之外的工程細(xì)節(jié)。狀態(tài)表示、規(guī)則協(xié)同、置信度校準(zhǔn)、日志設(shè)計(jì)、灰度策略、冪等回滾每一個(gè)環(huán)節(jié)都需要認(rèn)真對待。模型可以換但這些工程能力是沉淀下來的換什么模型都用得上。我個(gè)人在實(shí)際操作中的體會(huì)是先把規(guī)則系統(tǒng)跑穩(wěn)再逐步引入模型能力比一上來就追求“全自動(dòng) AI 決策”要靠譜得多。生產(chǎn)環(huán)境要的是穩(wěn)定和可解釋不是炫技。