1. 從概念到生產(chǎn)Jev 決策系統(tǒng)的架構(gòu)全景與設(shè)計(jì)哲學(xué)1.1 為什么需要“決策系統(tǒng)”而不是“又一個(gè)模型”過去兩年我參與過三個(gè)不同行業(yè)的 AI 決策類項(xiàng)目從電商動態(tài)定價(jià)到供應(yīng)鏈補(bǔ)貨再到內(nèi)容平臺的推薦策略。一個(gè)反復(fù)出現(xiàn)的現(xiàn)象是團(tuán)隊(duì)花大力氣訓(xùn)了一個(gè)模型離線指標(biāo)很漂亮一上線就崩。問題往往不在模型本身而在于整個(gè)系統(tǒng)缺少“決策”這一層——模型只負(fù)責(zé)預(yù)測但預(yù)測不等于決策。Jev 這個(gè)項(xiàng)目標(biāo)題里最核心的詞其實(shí)是“決策系統(tǒng)”而不是“模型”。這兩者的區(qū)別我用一個(gè)生活化的類比來解釋模型像是一個(gè)經(jīng)驗(yàn)豐富的醫(yī)生能根據(jù)化驗(yàn)單判斷你得了什么病而決策系統(tǒng)像是一個(gè)完整的診療方案它要綜合考慮醫(yī)生的判斷、你的過敏史、醫(yī)保報(bào)銷范圍、藥品庫存、甚至你明天有沒有重要會議不能吃嗜睡的藥。模型只輸出概率決策系統(tǒng)輸出的是“接下來該做什么”。Jev 要解決的核心問題就是讓 AI 從“會預(yù)測”進(jìn)化到“會決策”。它適合誰來參考我認(rèn)為有三類人最值得往下看一是正在做 AI 應(yīng)用但卡在“模型上線效果打折”的工程師二是需要向業(yè)務(wù)方解釋“為什么 AI 給出的建議不能直接用”的產(chǎn)品經(jīng)理三是想了解下一代 AI 系統(tǒng)架構(gòu)長什么樣的技術(shù)管理者。1.2 核心設(shè)計(jì)思路分層解耦與反饋閉環(huán)Jev 的架構(gòu)設(shè)計(jì)遵循一個(gè)很樸素但極難做好的原則預(yù)測與決策分離決策與執(zhí)行分離。我見過太多項(xiàng)目把模型推理和業(yè)務(wù)規(guī)則揉在一個(gè)服務(wù)里結(jié)果改一條規(guī)則要重新部署整個(gè)模型服務(wù)調(diào)一個(gè)閾值要等半天。Jev 的做法是把系統(tǒng)切成四層每一層只做一件事。第一層是感知層負(fù)責(zé)把原始數(shù)據(jù)變成模型能吃的特征。這一層的關(guān)鍵不是特征工程有多花哨而是特征一致性——離線訓(xùn)練用的特征和線上推理用的特征必須來自同一套定義。我踩過的坑是離線用 Python 算的特征線上用 Java 重寫了一遍結(jié)果因?yàn)楦↑c(diǎn)數(shù)精度和空值處理邏輯不同線上效果直接掉五個(gè)點(diǎn)。Jev 在這一層強(qiáng)制使用特征注冊中心所有特征定義只寫一次離線和線上都從注冊中心拉取。第二層是預(yù)測層跑模型推理。這一層 Jev 沒有追求“大模型”而是強(qiáng)調(diào)多模型集成與不確定性量化。為什么因?yàn)闆Q策系統(tǒng)最怕的不是預(yù)測不準(zhǔn)而是預(yù)測“不知道自己不準(zhǔn)”。一個(gè)模型給出 0.9 的置信度另一個(gè)給出 0.6決策層需要知道這個(gè)差異才能決定是直接執(zhí)行還是轉(zhuǎn)人工。Jev 在這一層會同時(shí)輸出預(yù)測值和置信區(qū)間這是它和普通推理服務(wù)的本質(zhì)區(qū)別。第三層是決策層這是 Jev 最核心的部分。它接收預(yù)測結(jié)果結(jié)合業(yè)務(wù)約束庫存、預(yù)算、合規(guī)紅線、實(shí)時(shí)上下文用戶當(dāng)前狀態(tài)、系統(tǒng)負(fù)載、以及長期目標(biāo)不是最大化單次點(diǎn)擊而是最大化用戶生命周期價(jià)值輸出一個(gè)或多個(gè)可執(zhí)行的動作。這一層的實(shí)現(xiàn)方式我后面會詳細(xì)拆這里先點(diǎn)明一個(gè)關(guān)鍵設(shè)計(jì)決策層不包含任何模型它是純規(guī)則引擎加優(yōu)化求解器。這樣做的好處是決策邏輯可解釋、可審計(jì)、可熱更新業(yè)務(wù)方也能看懂。第四層是執(zhí)行與反饋層負(fù)責(zé)把決策變成實(shí)際動作并收集動作后的真實(shí)反饋。這一層最容易被忽視但它是整個(gè)系統(tǒng)能持續(xù)進(jìn)化的前提。沒有反饋閉環(huán)決策系統(tǒng)就是一個(gè)開環(huán)控制器遲早會漂移。1.3 與常見架構(gòu)的對比為什么不是“模型即服務(wù)”市面上很多 AI 系統(tǒng)走的是“模型即服務(wù)”路線把模型包成一個(gè) API業(yè)務(wù)方調(diào)用 API 拿預(yù)測結(jié)果自己寫 if-else 做決策。這種模式在簡單場景下能用但一旦決策邏輯復(fù)雜起來就會變成技術(shù)債的重災(zāi)區(qū)。我整理了一個(gè)對比表方便你判斷自己的項(xiàng)目該不該上 Jev 這種架構(gòu)。維度模型即服務(wù)Jev 決策系統(tǒng)架構(gòu)決策邏輯位置散落在業(yè)務(wù)代碼中集中在決策層統(tǒng)一管理規(guī)則更新需要改代碼、重新部署熱更新分鐘級生效可解釋性弱決策鏈路斷裂強(qiáng)每層輸出可追溯多目標(biāo)權(quán)衡難通常只優(yōu)化單一指標(biāo)內(nèi)置多目標(biāo)優(yōu)化求解器反饋閉環(huán)通常沒有強(qiáng)制要求閉環(huán)驅(qū)動進(jìn)化適用場景簡單分類、排序動態(tài)定價(jià)、資源調(diào)度、風(fēng)控、推薦策略這個(gè)表不是要否定模型即服務(wù)而是想說當(dāng)你的決策涉及多個(gè)約束、多個(gè)目標(biāo)、需要快速迭代規(guī)則時(shí)Jev 這種分層架構(gòu)的長期維護(hù)成本會低很多。短期看它多寫了幾層代碼長期看它省的是無數(shù)次“改一行規(guī)則等一天上線”的痛苦。2. 核心模塊拆解從特征到?jīng)Q策的完整鏈路2.1 特征注冊中心解決離線在線一致性的唯一正解特征不一致是 AI 系統(tǒng)上線效果打折的第一大殺手。我做過一個(gè)統(tǒng)計(jì)在我經(jīng)手的項(xiàng)目里超過六成的“離線好線上差”問題根因都是特征計(jì)算邏輯不一致。Jev 的解法是引入特征注冊中心所有特征必須注冊后才能使用。具體怎么操作首先定義一個(gè)特征描述文件包含特征名、數(shù)據(jù)類型、計(jì)算邏輯、數(shù)據(jù)來源、更新頻率、負(fù)責(zé)人。這個(gè)文件用 YAML 寫放在 Git 里管理。然后特征注冊中心會根據(jù)這個(gè)描述自動生成離線和線上兩套計(jì)算代碼。離線走 Spark 或 Flink 批處理線上走輕量級流式計(jì)算但計(jì)算邏輯的“真值”只有一份。這里有個(gè)關(guān)鍵細(xì)節(jié)時(shí)間旅行查詢。訓(xùn)練模型時(shí)你需要的是“當(dāng)時(shí)”的特征值而不是“現(xiàn)在”的特征值。比如你要預(yù)測用戶會不會買某個(gè)商品特征里包含“用戶過去 7 天瀏覽次數(shù)”這個(gè)“過去 7 天”是相對于樣本時(shí)間點(diǎn)的不是相對于今天的。Jev 的特征注冊中心支持按時(shí)間戳查詢歷史特征快照這是很多自研特征平臺容易漏掉的功能。注意特征注冊中心不是一上來就要建得很重。我建議先從核心的 20 個(gè)特征開始跑通離線在線一致性校驗(yàn)流程再逐步遷移。一上來就全量遷移很容易因?yàn)闅v史特征邏輯混亂而卡住。2.2 預(yù)測層的不確定性量化讓模型“知道自己不知道”普通推理服務(wù)只輸出一個(gè)預(yù)測值Jev 要求輸出三個(gè)東西預(yù)測值、置信區(qū)間、以及一個(gè)“分布外檢測”標(biāo)志。為什么這么設(shè)計(jì)因?yàn)闆Q策層需要根據(jù)不確定性來決定動作的激進(jìn)程度。舉個(gè)例子在動態(tài)定價(jià)場景中如果模型預(yù)測“漲價(jià) 5% 能提升利潤 3%”但置信區(qū)間很寬比如利潤變化可能在 -2% 到 8% 之間決策層就應(yīng)該選擇更保守的漲價(jià)幅度或者先做小流量實(shí)驗(yàn)。如果置信區(qū)間很窄決策層可以更激進(jìn)。實(shí)現(xiàn)不確定性量化的方法有好幾種Jev 默認(rèn)用的是分位數(shù)回歸 蒙特卡洛 Dropout的組合。分位數(shù)回歸直接輸出 P10、P50、P90 三個(gè)分位點(diǎn)蒙特卡洛 Dropout 在推理時(shí)多次前向傳播得到預(yù)測分布的近似。兩者結(jié)合既能捕捉數(shù)據(jù)噪聲帶來的不確定性也能捕捉模型本身的不確定性。我實(shí)測下來這套方案在樹模型和深度模型上都能用但深度模型的蒙特卡洛 Dropout 推理成本會高一些。如果延遲敏感可以只用分位數(shù)回歸或者用輕量級的貝葉斯最后一層。關(guān)鍵是不要為了不確定性而犧牲太多延遲決策系統(tǒng)對延遲的容忍度通常比純預(yù)測系統(tǒng)更低。2.3 決策層的規(guī)則引擎與優(yōu)化求解器決策層是 Jev 的靈魂。它由兩部分組成規(guī)則引擎和優(yōu)化求解器。規(guī)則引擎負(fù)責(zé)硬約束過濾優(yōu)化求解器負(fù)責(zé)在可行域內(nèi)找最優(yōu)解。規(guī)則引擎我推薦用 Drools 或 Easy Rules但 Jev 的設(shè)計(jì)里有一個(gè)特殊要求規(guī)則必須帶優(yōu)先級和生效時(shí)間窗口。優(yōu)先級解決規(guī)則沖突生效時(shí)間窗口解決“大促期間臨時(shí)提權(quán)”這類需求。規(guī)則用 DSL 寫業(yè)務(wù)方也能看懂。我見過一個(gè)團(tuán)隊(duì)讓業(yè)務(wù)方直接用 Excel 配置規(guī)則然后寫了個(gè)轉(zhuǎn)換器把 Excel 變成 DSL效果出奇地好——業(yè)務(wù)方覺得自己掌控了決策技術(shù)方也不用天天被追著改規(guī)則。優(yōu)化求解器負(fù)責(zé)在多個(gè)目標(biāo)之間找平衡。Jev 默認(rèn)支持線性規(guī)劃、整數(shù)規(guī)劃和多目標(biāo)遺傳算法。選哪個(gè)取決于你的問題結(jié)構(gòu)如果目標(biāo)和約束都是線性的用線性規(guī)劃最快如果有整數(shù)變量比如“要么選 A 要么選 B”用整數(shù)規(guī)劃如果目標(biāo)函數(shù)很復(fù)雜、非凸用遺傳算法或模擬退火。這里有個(gè)實(shí)操心得不要追求全局最優(yōu)追求“足夠好且穩(wěn)定”。決策系統(tǒng)不是學(xué)術(shù)競賽業(yè)務(wù)方要的是可解釋、可復(fù)現(xiàn)、不會今天一個(gè)樣明天一個(gè)樣的決策。我通常會把求解器的收斂容差設(shè)得寬松一些比如 1% 以內(nèi)就認(rèn)為收斂這樣求解速度快而且結(jié)果更穩(wěn)定。2.4 反饋閉環(huán)從“開環(huán)控制”到“閉環(huán)進(jìn)化”反饋閉環(huán)是 Jev 區(qū)別于普通 AI 系統(tǒng)的關(guān)鍵。沒有閉環(huán)系統(tǒng)就是一個(gè)開環(huán)控制器環(huán)境變了它不知道效果掉了它也不知道。Jev 的閉環(huán)設(shè)計(jì)包含三個(gè)環(huán)節(jié)動作記錄、效果歸因、策略更新。動作記錄很簡單每次決策層輸出動作后執(zhí)行層要把動作、上下文、時(shí)間戳、以及后續(xù)的真實(shí)反饋都記錄下來。這里的關(guān)鍵是記錄要足夠細(xì)不能只記“最終轉(zhuǎn)化了沒有”要記中間過程。比如推薦場景要記曝光、點(diǎn)擊、停留時(shí)長、滑動深度、甚至用戶表情如果有攝像頭權(quán)限的話。效果歸因是難點(diǎn)。一個(gè)動作的效果往往被多個(gè)因素混雜怎么知道是決策系統(tǒng)起了作用還是大盤自然波動Jev 默認(rèn)用雙重差分法做歸因把用戶隨機(jī)分成實(shí)驗(yàn)組和對照組實(shí)驗(yàn)組走 Jev 決策對照組走舊策略比較兩組的差異。如果沒有條件做隨機(jī)實(shí)驗(yàn)可以用傾向得分匹配或合成控制法但因果推斷的強(qiáng)度會弱一些。策略更新不是自動改模型而是自動調(diào)整決策層的參數(shù)。比如規(guī)則引擎里的閾值、優(yōu)化求解器的權(quán)重。Jev 支持基于貝葉斯優(yōu)化的參數(shù)自動調(diào)優(yōu)但我的建議是初期不要開自動調(diào)優(yōu)先手動調(diào)幾輪建立對系統(tǒng)的直覺。自動調(diào)優(yōu)很容易過擬合到短期指標(biāo)把長期目標(biāo)犧牲掉。3. 生產(chǎn)環(huán)境落地從零搭建 Jev 系統(tǒng)的實(shí)操步驟3.1 環(huán)境準(zhǔn)備與依賴選型搭建 Jev 系統(tǒng)不需要特別高端的硬件但需要合理的組件選型。我按最小可用集群來列一下計(jì)算資源3 臺 8 核 16G 的云主機(jī)起步。一臺跑特征注冊中心和離線計(jì)算一臺跑預(yù)測服務(wù)一臺跑決策引擎和反饋收集。如果流量大預(yù)測服務(wù)可以水平擴(kuò)展。存儲PostgreSQL 存特征元數(shù)據(jù)和決策日志Redis 存實(shí)時(shí)特征和緩存對象存儲存模型文件和離線特征快照。消息隊(duì)列Kafka 或 Pulsar用于解耦特征計(jì)算、預(yù)測請求和反饋收集。模型服務(wù)可以用 TorchServe、Triton 或自己寫 FastAPI。Jev 不綁定具體框架但要求模型服務(wù)支持批量推理和動態(tài)批處理。規(guī)則引擎Drools 或 Easy Rules如果規(guī)則簡單自己寫一個(gè)輕量級 DSL 解析器也行。優(yōu)化求解器OR-Tools 或 SciPyPython 生態(tài)里這兩個(gè)最成熟。依賴版本我建議鎖定不要用 latest。我踩過的坑是OR-Tools 某個(gè)小版本升級后整數(shù)規(guī)劃的默認(rèn)求解器變了導(dǎo)致同樣的輸入輸出結(jié)果不一樣排查了兩天才發(fā)現(xiàn)是版本問題。所以生產(chǎn)環(huán)境一定要鎖版本并且把版本號寫進(jìn)部署文檔。3.2 特征注冊中心的搭建與遷移第一步定義特征描述文件。我拿一個(gè)電商場景舉例feature_name: user_7d_view_count data_type: int description: 用戶過去7天瀏覽次數(shù) source: user_behavior_log computation: | SELECT user_id, COUNT(*) as value FROM behavior_log WHERE event_type view AND event_time BETWEEN {start_time} AND {end_time} GROUP BY user_id update_frequency: hourly owner: data_team這個(gè)文件放在 Git 里每次修改都要走 PR 流程。特征注冊中心監(jiān)聽 Git 變更自動觸發(fā)離線和線上代碼生成。第二步跑一致性校驗(yàn)。注冊中心會定期抽樣一批用戶分別用離線和線上邏輯計(jì)算特征值比較差異。差異超過閾值的特征會被標(biāo)記為“不一致”需要負(fù)責(zé)人排查。我建議這個(gè)校驗(yàn)每天跑一次結(jié)果發(fā)到群里讓所有人都能看到。第三步逐步遷移。不要一次性把所有特征都遷進(jìn)來先遷核心的 20 個(gè)跑一周穩(wěn)定后再遷下一批。遷移過程中新舊特征并行計(jì)算決策層先用舊特征等新特征穩(wěn)定后再切換。提示特征注冊中心的最大價(jià)值不是技術(shù)而是組織。它強(qiáng)制要求每個(gè)特征有明確的負(fù)責(zé)人和計(jì)算邏輯消滅了“這個(gè)特征是誰算的、怎么算的”這類扯皮問題。3.3 預(yù)測服務(wù)的部署與不確定性輸出預(yù)測服務(wù)我推薦用 Triton因?yàn)樗С謩討B(tài)批處理和多種模型格式。如果團(tuán)隊(duì)規(guī)模小用 FastAPI 加 ONNX Runtime 也夠用。關(guān)鍵是要在預(yù)測服務(wù)里實(shí)現(xiàn)不確定性輸出。以分位數(shù)回歸為例模型訓(xùn)練時(shí)用分位數(shù)損失函數(shù)同時(shí)輸出 P10、P50、P90。推理時(shí)服務(wù)返回這三個(gè)值決策層根據(jù) P10 和 P90 的差距來判斷不確定性。蒙特卡洛 Dropout 的實(shí)現(xiàn)稍微復(fù)雜一點(diǎn)在模型里保留 Dropout 層推理時(shí)開啟 Dropout前向傳播 N 次通常 N20 到 50得到 N 個(gè)預(yù)測值然后算均值和標(biāo)準(zhǔn)差。N 越大不確定性估計(jì)越準(zhǔn)但延遲越高。我實(shí)測下來N20 在大多數(shù)場景下夠用延遲增加不到 50ms。如果延遲要求極嚴(yán)可以用深度集成的簡化版訓(xùn)練 3 到 5 個(gè)不同初始化的模型推理時(shí)同時(shí)跑用預(yù)測值的方差作為不確定性。這種方法延遲是單模型的 3 到 5 倍但不確定性估計(jì)更可靠。3.4 決策引擎的規(guī)則編寫與優(yōu)化求解決策引擎的規(guī)則用 DSL 寫我設(shè)計(jì)了一個(gè)簡單的語法rule 庫存不足時(shí)禁止促銷 when inventory 10 and action.type promotion then reject(庫存不足禁止促銷) priority 100 end規(guī)則引擎按優(yōu)先級從高到低執(zhí)行高優(yōu)先級規(guī)則可以否決低優(yōu)先級規(guī)則的動作。生效時(shí)間窗口用 cron 表達(dá)式配置比如大促期間臨時(shí)提權(quán)。優(yōu)化求解器負(fù)責(zé)在可行動作集合里找最優(yōu)。我拿動態(tài)定價(jià)舉例目標(biāo)是最大化利潤約束是價(jià)格不能低于成本、不能高于競品價(jià)格的 120%、庫存不能為負(fù)。用線性規(guī)劃求解變量是價(jià)格目標(biāo)函數(shù)是 (價(jià)格 - 成本) * 預(yù)測銷量約束是線性的。如果目標(biāo)函數(shù)非線性比如銷量是價(jià)格的指數(shù)函數(shù)可以用序列二次規(guī)劃或遺傳算法。我通常先用線性規(guī)劃跑一版如果效果不夠好再換非線性求解器。不要一上來就用最復(fù)雜的求解器簡單方案往往夠用。3.5 反饋閉環(huán)的埋點(diǎn)與歸因分析反饋埋點(diǎn)要在執(zhí)行層做不要在決策層做。決策層只負(fù)責(zé)輸出動作執(zhí)行層負(fù)責(zé)把動作變成實(shí)際請求并記錄請求結(jié)果。埋點(diǎn)數(shù)據(jù)要包含決策 ID、動作類型、動作參數(shù)、上下文特征、時(shí)間戳、以及后續(xù)的反饋事件。歸因分析我推薦用雙重差分法。具體操作把用戶隨機(jī)分成實(shí)驗(yàn)組和對照組實(shí)驗(yàn)組走 Jev 決策對照組走舊策略。跑一周后比較兩組的核心指標(biāo)差異。如果差異顯著說明 Jev 有效如果不顯著需要排查是決策邏輯問題還是實(shí)驗(yàn)設(shè)計(jì)問題。如果沒有條件做隨機(jī)實(shí)驗(yàn)可以用中斷時(shí)間序列在某個(gè)時(shí)間點(diǎn)切換策略比較切換前后的指標(biāo)變化。但這種方法容易受大盤趨勢影響需要做季節(jié)性調(diào)整。4. 常見問題與排查技巧實(shí)錄4.1 決策系統(tǒng)上線后效果不如離線評估這是最常見的問題沒有之一。我總結(jié)了一個(gè)排查清單按優(yōu)先級排序排查項(xiàng)可能原因解決方法特征一致性離線在線特征計(jì)算邏輯不同用特征注冊中心統(tǒng)一邏輯跑一致性校驗(yàn)數(shù)據(jù)泄漏離線特征包含了未來信息檢查特征計(jì)算的時(shí)間窗口確保只用歷史數(shù)據(jù)分布偏移線上數(shù)據(jù)分布和訓(xùn)練數(shù)據(jù)不同監(jiān)控特征分布發(fā)現(xiàn)偏移后重新訓(xùn)練決策延遲線上決策太慢錯過最佳時(shí)機(jī)優(yōu)化求解器降低不確定性計(jì)算開銷反饋延遲反饋信號來得太晚閉環(huán)失效用短期代理指標(biāo)替代長期指標(biāo)我踩過最坑的一次是數(shù)據(jù)泄漏離線特征里包含了“用戶過去 30 天是否購買”但這個(gè)特征在預(yù)測時(shí)點(diǎn)其實(shí)還不知道。修正后離線 AUC 從 0.85 掉到 0.78但線上效果反而提升了。所以離線指標(biāo)高不一定好關(guān)鍵是一致性。4.2 規(guī)則沖突與優(yōu)先級混亂規(guī)則多了之后沖突是必然的。比如一條規(guī)則說“庫存低于 10 禁止促銷”另一條說“大促期間所有商品必須參與促銷”。這兩條規(guī)則同時(shí)生效時(shí)系統(tǒng)該聽誰的Jev 的解法是優(yōu)先級 互斥組。每條規(guī)則有優(yōu)先級高優(yōu)先級規(guī)則可以否決低優(yōu)先級規(guī)則。同時(shí)規(guī)則可以分組同組規(guī)則互斥只能有一條生效。比如“庫存規(guī)則組”和“大促規(guī)則組”互斥大促期間大促規(guī)則組生效庫存規(guī)則組暫時(shí)掛起。實(shí)操心得規(guī)則不要超過 50 條。超過 50 條后沖突排查會變得極其困難。如果業(yè)務(wù)邏輯真的很復(fù)雜把規(guī)則拆成多個(gè)決策層每層只處理一類約束。比如第一層過濾硬約束第二層做多目標(biāo)優(yōu)化第三層做個(gè)性化微調(diào)。4.3 優(yōu)化求解器不收斂或求解時(shí)間過長優(yōu)化求解器不收斂通常是因?yàn)閱栴}定義有問題。我遇到過幾種情況可行域?yàn)榭占s束太緊沒有滿足所有約束的解。解決方法是放寬約束或者引入軟約束允許違反但加懲罰項(xiàng)。目標(biāo)函數(shù)無界目標(biāo)函數(shù)在某些方向上可以無限優(yōu)化。解決方法是加邊界約束。整數(shù)變量太多整數(shù)規(guī)劃是 NP 難的變量多了求解時(shí)間指數(shù)增長。解決方法是減少整數(shù)變量或者用啟發(fā)式算法求近似解。求解時(shí)間過長的話可以設(shè)置時(shí)間上限比如 100ms 內(nèi)必須返回返回當(dāng)前最優(yōu)解可能不是全局最優(yōu)。決策系統(tǒng)對延遲敏感寧可要一個(gè) 100ms 內(nèi)的“足夠好”解也不要一個(gè) 10 秒后的“完美”解。4.4 反饋數(shù)據(jù)稀疏或延遲反饋數(shù)據(jù)稀疏是冷啟動階段的常見問題。新用戶沒有歷史行為新商品沒有銷售記錄決策系統(tǒng)缺乏依據(jù)。Jev 的解法是分層決策冷啟動階段用群體統(tǒng)計(jì)特征等個(gè)體數(shù)據(jù)積累夠了再切換到個(gè)性化決策。反饋延遲是另一個(gè)問題。比如金融風(fēng)控場景一個(gè)決策的對錯可能要等幾個(gè)月才能確認(rèn)。這時(shí)候可以用代理指標(biāo)用短期可觀測的指標(biāo)如點(diǎn)擊、停留來近似長期目標(biāo)如轉(zhuǎn)化、留存。代理指標(biāo)和長期目標(biāo)的相關(guān)性需要定期驗(yàn)證相關(guān)性下降時(shí)要重新選擇代理指標(biāo)。注意代理指標(biāo)不是萬能的。我見過一個(gè)團(tuán)隊(duì)用“點(diǎn)擊率”作為“用戶滿意度”的代理結(jié)果系統(tǒng)學(xué)會了標(biāo)題黨點(diǎn)擊率上去了但用戶留存掉了。代理指標(biāo)一定要和長期目標(biāo)做相關(guān)性分析相關(guān)性低于 0.5 就要警惕。4.5 系統(tǒng)可解釋性與業(yè)務(wù)方信任決策系統(tǒng)最怕業(yè)務(wù)方不信任。業(yè)務(wù)方問“為什么給這個(gè)用戶漲價(jià) 5%”你回答“因?yàn)槟Ｐ洼敵龅摹睒I(yè)務(wù)方當(dāng)場就炸了。Jev 的可解釋性設(shè)計(jì)從三個(gè)層面入手第一決策日志全記錄。每次決策都記錄輸入特征、預(yù)測值、置信區(qū)間、觸發(fā)的規(guī)則、求解器輸出。業(yè)務(wù)方可以查任意一次決策的完整鏈路。第二反事實(shí)解釋。對于關(guān)鍵決策系統(tǒng)可以生成“如果某個(gè)特征變了決策會怎么變”的解釋。比如“如果庫存多 10 件就不會拒絕促銷”。這種解釋業(yè)務(wù)方最容易理解。第三規(guī)則可視化。規(guī)則引擎的規(guī)則用 DSL 寫可以渲染成流程圖業(yè)務(wù)方一眼就能看懂決策邏輯。我見過一個(gè)團(tuán)隊(duì)把規(guī)則流程圖打印出來貼在會議室業(yè)務(wù)方開會時(shí)直接指著圖討論效率極高。5. 從生產(chǎn)反饋中沉淀的架構(gòu)演進(jìn)方向5.1 決策系統(tǒng)的可觀測性建設(shè)Jev 上線后我最大的體會是可觀測性不是錦上添花是生死攸關(guān)。決策系統(tǒng)比普通服務(wù)復(fù)雜得多出問題時(shí)排查鏈路很長。我建議從第一天就建好三張看板第一張是決策質(zhì)量看板監(jiān)控決策的采納率、執(zhí)行率、以及業(yè)務(wù)指標(biāo)。如果采納率突然下降說明決策和業(yè)務(wù)預(yù)期脫節(jié)了。第二張是系統(tǒng)健康看板監(jiān)控預(yù)測延遲、求解器耗時(shí)、規(guī)則命中率、特征缺失率。任何一個(gè)指標(biāo)異常都可能導(dǎo)致決策質(zhì)量下降。第三張是數(shù)據(jù)漂移看板監(jiān)控輸入特征的分布變化。特征分布漂移是模型失效的前兆早發(fā)現(xiàn)早處理。這三張看板我用 Grafana 搭的數(shù)據(jù)源是 Prometheus 加 PostgreSQL。搭建成本不高但收益極大。有一次特征缺失率從 0.1% 漲到 5%看板報(bào)警后我們十分鐘內(nèi)定位到是上游數(shù)據(jù)源變更避免了更大的事故。5.2 多決策系統(tǒng)協(xié)同與沖突消解當(dāng)一個(gè)業(yè)務(wù)有多個(gè)決策系統(tǒng)時(shí)比如定價(jià)系統(tǒng)、推薦系統(tǒng)、風(fēng)控系統(tǒng)同時(shí)運(yùn)行沖突是必然的。定價(jià)系統(tǒng)想漲價(jià)推薦系統(tǒng)想推低價(jià)商品吸引點(diǎn)擊風(fēng)控系統(tǒng)覺得這個(gè)用戶有風(fēng)險(xiǎn)要限制。三個(gè)系統(tǒng)各說各話執(zhí)行層聽誰的Jev 的解法是引入決策仲裁層。每個(gè)決策系統(tǒng)輸出動作時(shí)附帶一個(gè)“置信度”和“影響范圍”。仲裁層根據(jù)全局目標(biāo)對多個(gè)動作做加權(quán)融合或優(yōu)先級排序。比如全局目標(biāo)是最大化長期利潤仲裁層會給定價(jià)系統(tǒng)的動作更高權(quán)重如果全局目標(biāo)是提升用戶活躍推薦系統(tǒng)的權(quán)重更高。仲裁層的實(shí)現(xiàn)可以用簡單的加權(quán)投票也可以用多目標(biāo)優(yōu)化。我建議初期用加權(quán)投票簡單可解釋。等業(yè)務(wù)復(fù)雜了再上多目標(biāo)優(yōu)化。5.3 從規(guī)則驅(qū)動到學(xué)習(xí)驅(qū)動的漸進(jìn)路徑Jev 的決策層目前是規(guī)則驅(qū)動加優(yōu)化求解這是有意為之。規(guī)則驅(qū)動可解釋、可審計(jì)、可熱更新適合生產(chǎn)環(huán)境。但長期看純規(guī)則驅(qū)動會遇到瓶頸規(guī)則越寫越多維護(hù)成本越來越高而且規(guī)則之間的交互效應(yīng)很難人工預(yù)測。我的建議是走漸進(jìn)路徑先用規(guī)則驅(qū)動跑通閉環(huán)積累決策日志和反饋數(shù)據(jù)然后用這些數(shù)據(jù)訓(xùn)練一個(gè)“決策策略模型”學(xué)習(xí)規(guī)則引擎的決策模式最后用策略模型輔助規(guī)則引擎比如用模型推薦規(guī)則參數(shù)或者用模型處理規(guī)則覆蓋不到的邊緣情況。這條路徑的關(guān)鍵是不要一步到位。我見過團(tuán)隊(duì)直接上強(qiáng)化學(xué)習(xí)做決策結(jié)果因?yàn)榉答佅∈韬湍M環(huán)境不真實(shí)學(xué)了三個(gè)月還不如規(guī)則引擎。規(guī)則驅(qū)動雖然笨但它穩(wěn)定、可解釋、業(yè)務(wù)方信任。學(xué)習(xí)驅(qū)動是方向但要走得穩(wěn)。5.4 成本控制與資源優(yōu)化決策系統(tǒng)的成本主要在三塊計(jì)算、存儲、人力。計(jì)算成本來自預(yù)測服務(wù)和優(yōu)化求解器存儲成本來自決策日志和特征快照人力成本來自規(guī)則維護(hù)和模型迭代。計(jì)算成本優(yōu)化預(yù)測服務(wù)用動態(tài)批處理把多個(gè)請求合并成一個(gè)批次推理GPU 利用率能提升 3 到 5 倍。優(yōu)化求解器設(shè)置時(shí)間上限避免長時(shí)間求解。非核心決策可以降級到輕量級模型。存儲成本優(yōu)化決策日志不要全量存存最近 30 天更早的歸檔到冷存儲。特征快照按需存不要每個(gè)時(shí)間點(diǎn)都存。人力成本優(yōu)化規(guī)則用 DSL 寫讓業(yè)務(wù)方也能參與維護(hù)。模型迭代自動化用 CI/CD 流水線跑訓(xùn)練和評估。我見過一個(gè)團(tuán)隊(duì)把模型迭代周期從兩周縮短到兩天靠的就是自動化流水線。5.5 安全與合規(guī)的底線設(shè)計(jì)決策系統(tǒng)涉及業(yè)務(wù)核心邏輯安全合規(guī)是底線。Jev 的設(shè)計(jì)里包含幾個(gè)強(qiáng)制要求第一決策可審計(jì)。每次決策的完整鏈路必須記錄保留至少 6 個(gè)月。審計(jì)時(shí)能還原任意一次決策的輸入、邏輯和輸出。第二規(guī)則變更留痕。誰在什么時(shí)候改了哪條規(guī)則改前改后是什么全部記錄。規(guī)則變更要走審批流程不能隨便改。第三敏感決策雙人復(fù)核。涉及用戶權(quán)益的決策如風(fēng)控拒絕、定價(jià)調(diào)整要支持雙人復(fù)核機(jī)制。一個(gè)人提交另一個(gè)人確認(rèn)后才能生效。第四降級預(yù)案。決策系統(tǒng)故障時(shí)要有降級方案。比如切換到默認(rèn)策略或者轉(zhuǎn)人工處理。降級預(yù)案要定期演練確保真出問題時(shí)能快速切換。這些要求看起來繁瑣但真出問題時(shí)能救命。我經(jīng)歷過一次規(guī)則配置錯誤導(dǎo)致大規(guī)模誤判因?yàn)橛袑徲?jì)日志十分鐘內(nèi)定位到問題規(guī)則并回滾避免了更大的損失。6. 個(gè)人實(shí)操體會與后續(xù)擴(kuò)展思路6.1 踩過的最大的三個(gè)坑第一個(gè)坑是過早優(yōu)化。項(xiàng)目初期我就想把特征注冊中心建得很完善結(jié)果花了兩個(gè)月搭平臺業(yè)務(wù)需求已經(jīng)變了。后來學(xué)乖了先用最小可用版本跑通閉環(huán)再逐步完善。特征注冊中心從 20 個(gè)特征起步半年后才擴(kuò)展到 200 個(gè)。第二個(gè)坑是忽視業(yè)務(wù)方參與。技術(shù)團(tuán)隊(duì)閉門造車規(guī)則寫得再漂亮業(yè)務(wù)方不認(rèn)。后來我強(qiáng)制要求每條規(guī)則必須有業(yè)務(wù)方確認(rèn)規(guī)則 DSL 也設(shè)計(jì)得盡量像自然語言。業(yè)務(wù)方參與后規(guī)則質(zhì)量明顯提升因?yàn)楹芏鄻I(yè)務(wù)約束是技術(shù)團(tuán)隊(duì)根本想不到的。第三個(gè)坑是反饋閉環(huán)斷掉。有一次上游數(shù)據(jù)源變更反饋數(shù)據(jù)沒進(jìn)來系統(tǒng)跑了三天才發(fā)現(xiàn)。那三天決策質(zhì)量持續(xù)下降但因?yàn)闆]監(jiān)控反饋數(shù)據(jù)沒人發(fā)現(xiàn)。后來加了反饋數(shù)據(jù)監(jiān)控超過一小時(shí)沒數(shù)據(jù)就報(bào)警。6.2 給不同規(guī)模團(tuán)隊(duì)的建議小團(tuán)隊(duì)3 人以下不要上全套 Jev 架構(gòu)太重了。先用一個(gè) Python 腳本跑通“特征-預(yù)測-決策-反饋”的最小閉環(huán)驗(yàn)證業(yè)務(wù)價(jià)值。驗(yàn)證通過后再逐步拆分成服務(wù)。中型團(tuán)隊(duì)5 到 10 人可以上 Jev 的核心模塊但不要追求大而全。特征注冊中心、預(yù)測服務(wù)、決策引擎、反饋收集這四個(gè)模塊先跑起來?？捎^測性用開源方案不要自研。大型團(tuán)隊(duì)10 人以上可以上全套架構(gòu)但要警惕過度工程。我見過大團(tuán)隊(duì)把決策系統(tǒng)拆成十幾個(gè)微服務(wù)結(jié)果調(diào)用鏈路太長延遲高得沒法用。服務(wù)拆分要適度按業(yè)務(wù)邊界拆不要按技術(shù)分層拆。6.3 后續(xù)可以擴(kuò)展的方向Jev 目前聚焦在單決策系統(tǒng)的架構(gòu)和落地。后續(xù)可以往幾個(gè)方向擴(kuò)展一是多決策系統(tǒng)協(xié)同前面提到的仲裁層是一個(gè)方向。多個(gè)決策系統(tǒng)如何共享特征、共享反饋、協(xié)同優(yōu)化是一個(gè)有意思的問題。二是決策系統(tǒng)的自動化調(diào)優(yōu)。目前規(guī)則參數(shù)和求解器權(quán)重還是手動調(diào)后續(xù)可以用貝葉斯優(yōu)化或強(qiáng)化學(xué)習(xí)自動調(diào)。但要注意過擬合風(fēng)險(xiǎn)自動調(diào)優(yōu)的目標(biāo)函數(shù)要包含長期指標(biāo)。三是決策系統(tǒng)的仿真環(huán)境。在真實(shí)環(huán)境做實(shí)驗(yàn)成本高、風(fēng)險(xiǎn)大?？梢越ㄒ粋€(gè)仿真環(huán)境用歷史數(shù)據(jù)模擬決策效果快速迭代策略。仿真環(huán)境的關(guān)鍵是保真度太簡化的仿真會誤導(dǎo)決策。四是決策系統(tǒng)的聯(lián)邦學(xué)習(xí)。多個(gè)業(yè)務(wù)方各有數(shù)據(jù)但不想共享原始數(shù)據(jù)?？梢杂寐?lián)邦學(xué)習(xí)聯(lián)合訓(xùn)練模型各自保留數(shù)據(jù)只共享模型參數(shù)。這在隱私敏感場景下很有價(jià)值。6.4 一個(gè)實(shí)用小技巧最后分享一個(gè)我在多個(gè)項(xiàng)目里驗(yàn)證過的小技巧決策日志里加一個(gè)“決策理由”字段。這個(gè)字段不是給機(jī)器看的是給人看的。每次決策輸出時(shí)用自然語言生成一句話解釋比如“因?yàn)閹齑娴陀陂撝登矣脩魞r(jià)格敏感度高選擇不漲價(jià)”。這個(gè)字段的生成可以用模板也可以用一個(gè)小語言模型。成本很低但收益極大。業(yè)務(wù)方查日志時(shí)一眼就能看懂決策邏輯不用去翻特征和規(guī)則。我見過一個(gè)團(tuán)隊(duì)因?yàn)檫@個(gè)字段業(yè)務(wù)方對決策系統(tǒng)的信任度大幅提升規(guī)則評審會從兩小時(shí)縮短到半小時(shí)。這個(gè)技巧的本質(zhì)是決策系統(tǒng)不僅要會決策還要會解釋決策。解釋能力是決策系統(tǒng)被業(yè)務(wù)方接受的關(guān)鍵也是技術(shù)團(tuán)隊(duì)和業(yè)務(wù)團(tuán)隊(duì)之間的橋梁。