本機推理遷移上線一個月後，我們才發現漏掉的三行設定

上個月我們將線上推理從雲端 API 切換到本機 router，流量數據相當亮眼：P95 延遲從 1400ms 降至 220ms，月底帳單節省了約七成。我們按照計畫完成切換、觀察一週並匯報結果。

一週後，一位使用者回報說，他最近幾次長對話中引用了自己三天前的另一段話，而且引用的對象錯誤。這不是幻覺，而是檢索庫發生了記錄衝突。我們重現三次才命中一次，定位問題花了一天時間：在雲端 API 時期，閘道器中有一段請求日誌的脫敏邏輯，順手將使用者自訂 ID 的分隔符統一改為底線。本機 router 沒有這段邏輯，ID 原樣進入資料庫。導致舊資料庫中兩個互不相干的使用者 ID 發生衝突。

遷移時我們進行了全鏈路回歸測試，規格書（spec）中也寫入了「自訂 ID 唯一性校驗」這一項，但執行時使用的是測試資料——由於測試資料的 ID 從未發生過衝突，因此規格書測試全部通過（全綠），我們便上線了。

沒有人做錯事，但機制缺少了一環：遷移類工作沒有強制環節去檢查舊系統中的隱性副作用。

現在我們的做法改變了，雖然笨拙，但有效：

第一，遷移前將上一代閘道器的設定、中介軟體、路由規則逐條列成清單，每條只允許標記三種狀態：明確遷移、確認不需要、未確認。第三類項目若未清零則不許開工。第一版清單共 47 條，有 9 條停留在「未確認」，事故來源就是其中之一。

第二，測試資料不能是乾淨的。ID 庫中必須故意放入一組已知會衝突的 ID，目的不是檢驗檢索功能正常運作，而是檢驗發生衝突時是否有警報。以前測試庫是手工建立的，從未發生過衝突，因此從未發現警報路徑根本不存在。

第三，流量切換不使用瞬时開關。新舊兩套系統先並行處理一小段真實流量，雙方接收同一請求，比對輸出差異，若超過閾值則不許切換。第一版並行時差異率為 0.3%，當時設定的閾值是 0.5%，於是我們上線了。如果閾值是 0.1%，這個問題就會在上線前暴露出來。

成本是實打實的：清單整理一次大約需要兩個人天，比對腳本花費兩個晚上。我們用這些時間換取了一次避免「由使用者先發現問題」的機會，三個月內同類問題沒再出現。樣本太小，不足以構成結論，但對我們自己來說，這比規格書全綠更令人信服一些。