AI 專案維運移交怎麼做?讓內部團隊接手不掉球的交接教學

交付一個 AI 專案,最容易被低估的不是模型準不準,而是三個月後客戶團隊自己能不能扛住它。我們看過太多案子,系統上線那天煙火放完,顧問一撤場,accuracy 開始悄悄往下掉,沒人看得懂告警,也沒人知道該找誰。

所謂 AI 維運移交,指的是把一套已上線 AI 系統的「持續運作能力」完整交給客戶內部團隊的過程,包含日常操作手冊 (runbook)、值班應變機制 (on-call)、以及模型退化偵測與再訓練決策權。它交的不是程式碼壓縮檔,是「這套系統壞掉時,你們知道怎麼辦」的能力。

大部分失敗的交接,都死在同一個誤會上:以為交付等於交程式碼。

為什麼「只交程式碼」的 AI 維運移交一定會出事

傳統軟體交接,把 repo、部署腳本、架構圖交出去,對方工程師讀得懂就接得住。因為傳統系統的行為是確定的:輸入一樣,輸出一樣,壞了會報錯。

AI 系統不是。它會在沒有任何程式碼變動的情況下,自己慢慢變差。上游資料分布變了、使用者問法變了、外部知識過期了,模型的答案就開始飄。這種退化不會拋出 exception,不會讓監控轉紅,它只會讓使用者慢慢覺得「這東西好像變笨了」,然後停止使用。

我們有個製造業客戶,交接時工程文件寫得非常漂亮,對方 IT 也真的讀懂了整套 RAG 架構。半年後回訪,系統還在跑,但檢索命中率從 82% 掉到 61%。原因很蠢:他們新增了兩條產線,產生一批新料號文件,沒有人知道要把這些文件灌進知識庫,因為交接時沒有人教他們「知識庫是會過期的、誰該負責餵它」。

程式碼沒壞。壞的是沒被交出去的那套知識。

Runbook:把「顧問腦袋裡的判斷」寫成可執行步驟

Runbook 是交接的地基,但九成的 runbook 都寫成了系統說明書,而不是應變手冊。

好的 AI runbook 不是描述「這個服務是什麼」,而是回答「當某件事發生時,值班的人第一步做什麼」。它應該是以故障場景為索引的。我們要求每一份交付的 runbook 至少涵蓋這幾類情境,而且每一項都要有明確的判斷門檻與升級路徑:

故障場景	觸發訊號	第一線動作	何時升級
回答明顯變差	使用者負評率 > 5% 或人工抽檢命中率 < 70%	檢查知識庫最近更新、比對 prompt 版本	連續兩天未回穩
延遲飆高	P95 回應 > 8 秒	檢查向量庫負載、LLM API 狀態頁	影響 > 20% 請求
幻覺/亂答	出現捏造數據或引用不存在文件	開啟嚴格檢索模式、降 temperature	涉及對外或合規內容,立即升級
成本異常	單日 token 花費超預算 1.5 倍	查是否有異常長對話或濫用	疑似攻擊或迴圈呼叫

重點在最後兩欄。「何時升級」這件事,是顧問在現場靠經驗默默在做的判斷,如果不寫下來,客戶團隊接手後只會有兩種極端:小事狂 call 人,或大事拖到爆掉才發現。把門檻數字化,才算真的交出去了。

On-call:交的不是排班表,是責任邊界

很多人以為交 on-call 就是給對方一個 PagerDuty 帳號、排個輪值。那只是把電話轉接過去,責任沒轉移。

真正要交的是三件事。第一,告警要能連到具體的人和動作,而不是丟進一個沒人看的頻道。我們的做法是每一條告警規則都必須對應 runbook 裡的一個場景編號,收到告警的人點進去就知道翻哪一頁,不需要在半夜理解整套架構。

第二,要區分「AI 特有故障」和「一般系統故障」的值班分工。資料庫掛了、容器重啟,客戶原本的 SRE 就能處理;但模型退化、檢索品質下降這類問題,需要懂一點 ML 判斷的人。交接時如果不把這條界線畫清楚,結果就是所有 AI 相關告警全被推給那個「碰過 AI 的倒楣工程師」,而他其實也沒被授權做再訓練決策。

第三,也是最容易漏的:交接後前四到六週,顧問要留在 on-call 輪值裡當第二線,而不是拍拍屁股走人。我們把這段叫「共同值班期」。前兩週由客戶接第一線、我們兜底;確認他們能獨立處理幾次真實事故後,才真正退出。交接不是一個交付日,是一段爬坡曲線。

模型退化偵測:把「系統會變笨」變成看得見的數字

這是知識移交裡技術含量最高、卻最常被跳過的一塊。

要讓客戶團隊能獨立守住品質,你得先在交接前就建好一套讓退化「可被看見」的機制,再連同判讀方法一起交出去。至少要包含三層:一是線上代理指標,像使用者負評率、追問率、對話中途放棄率,這些不需要標註就能即時反映體感變差;二是定期離線評測,維護一組固定的黃金測試題,每週自動跑一次算分,分數掉了就是警訊;三是資料漂移監測,追蹤進來的問題分布跟當初訓練/建庫時差多少。

但建好儀表板只是一半。另一半是交出「看到數字之後怎麼決策」。分數掉 3% 是正常波動還是該行動?該補知識庫、調 prompt、還是真的要重新微調?這套判斷邏輯必須寫成決策樹交給對方,並且明確標出哪些動作客戶團隊可以自己做、哪些要回頭找我們。否則儀表板再漂亮,也只是一面沒人看得懂的牆。

我們通常會在交接時陪客戶團隊完整跑一次「偵測到退化 → 定位原因 → 執行修復 → 驗證回穩」的循環,用一個真實或刻意注入的退化案例當教材。讀懂儀表板跟親手救過一次,是完全不同的兩種掌握程度。

交接完成的標準,不是簽字,是他們獨立救過一次

判斷一次 AI 維運移交是否真的成功,我們只看一件事:在顧問完全不介入的情況下,客戶團隊能不能自己偵測、定位並修復一次真實的品質下滑。做不到,就代表你交的還是程式碼,不是能力。

這也是為什麼我們始終相信,Demo 很美不算數,系統上線且客戶自己扛得住、還在持續用,才算真的交付完成。把工程師嵌進客戶現場、陪他們走完第一段真實維運的爬坡,而不是丟一包文件就走,是我們認為 AI 專案唯一站得住的交接方式。