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