從經驗判斷到自動化閘門：AI 開發流程規模化的真正關鍵

AI 系統開發的規模化挑戰，其核心瓶頸並非算力或演算法，而是如何系統性地處理人類專家的隱性知識（tacit knowledge）。許多關鍵的品質判斷，如「模型表現夠不夠好」、「資料漂移是否在可接受範圍」，往往仰賴模糊的經驗。真正的工程成熟度，體現在將這些模糊的判斷，轉譯為具體、可量測、可自動執行的機器檢查條件（machine-checkable gates）。這不僅是流程優化，更是將 AI 開發從手工作坊提升為可治理、可預測的工業化生產體系的關鍵一步。

為什麼傳統 AI 開發流程難以規模化？

許多團隊在導入機器學習時，會自然而然地沿用傳統軟體開發的生命週期（SDLC），但在實務上很快就會遇到瓶頸。以 AWS 提出的 AI 開發生命週期（AI-DLC）為例，其早期版本（v1.0）在實際部署後，發現最大的摩擦力來自於人工的「合否判定」（Go/No-Go Decision）環節。

想像一個場景：當新模型訓練完成，資深資料科學家或領域專家需要憑藉經驗，檢視數十個樣本的預測結果，判斷「這個版本比上一個好」或「在某些邊界案例上表現不佳」。然而，這種看似直觀的判斷，卻帶來了幾個根本性的問題，阻礙了 AI 開發的規模化：

• 主觀且不一致： 兩位專家可能做出不同判斷。同一個專家在不同時間，也可能因為情境不同而有不同的標準。
• 難以追溯與重現： 當幾個月後系統出現問題，我們很難回頭釐清當初「通過」的具體理由是什麼。決策的脈絡遺失了。
• 成為組織的知識瓶頸： 整個團隊的開發速度，被少數幾位專家的時間與精力所限制。這使得平行開發與快速迭代變得極為困難。

這種依賴「老師傅」點頭的模式，在本質上是一種手工作坊式的生產。它或許能在專案初期快速啟動，但完全不具備規模化的潛力。當模型數量從 1 個變成 100 個，或更新頻率從每季一次變成每天數次，這個人工閘門就會徹底癱瘓整個開發流程。

如何將人類的模糊判斷轉譯為機器可驗證的條件？

AWS 在 AI-DLC Workflows 2.0 中提出的核心解法，正是要系統性地「蒸餾」這些人類專家的判斷力。目標是將隱性的、模糊的「好壞感覺」，轉化為一系列顯性的、可自動執行的檢查程式碼。這個過程，我認為是 MLOps 走向成熟的關鍵，也是一種重要的工程治理實踐。

具體來說，這個轉譯過程可以拆解成幾個步驟：

1. 解構判斷： 與領域專家深入訪談，釐清他們在做判斷時，腦中到底在想什麼。他們看的是哪些指標？是準確率、召回率，還是特定類別的錯誤率？他們是否在尋找某些不該出現的特定模式？例如，在一個金融詐欺偵測模型中，專家可能特別在意「是否將高價值客戶的正常交易誤判為詐欺」。
2. 定義量化指標： 將這些質化的觀察，轉化為可以量化的指標。前述的例子，就可以定義成一個指標：「VIP 客戶群體的偽陽性率（False Positive Rate）必須低於 0.1%」。同樣地，「模型反應速度不能變慢」可以定義成「P95 延遲必須小於 200 毫秒」。
3. 設定自動化閘門： 將這些帶有明確閾值的指標，寫成自動化測試腳本，並整合進 CI/CD/CT（持續整合/持續交付/持續訓練）的管線中。例如，在每次模型訓練完成後，自動執行一個評估腳本，檢查 F1-score 是否大於 0.85、VIP 偽陽性率是否低於 0.1%、延遲是否小於 200ms。所有條件都滿足，模型才能自動推進到下一個階段。

我們的目標，是讓人類的專業知識成為規則的來源，而不是流程執行的瓶頸。

這個轉變，讓資深專家的知識得以沉澱和規模化。他們不再需要親自審批每一個版本，而是將精力投入到設計與維護更完善的「品質閘門」上。這也讓資淺的工程師，能在這些明確的護欄內，安全地進行實驗與交付。

這對 AI 工程治理意味著什麼？

將隱性判斷轉化為自動化閘門，其意義遠不止於提升效率。它是一個深刻的工程治理命題，代表著 AI 系統開發從「藝術」走向「工程」的轉變。

在Google 提出的 MLOps 成熟度模型中，最高層級的特徵之一就是自動化的治理與監控。當我們的品質標準被程式碼所定義，這意味著：

• 可稽核性（Auditability）： 任何一個部署上線的模型，我們都能精確地追溯它通過了哪些品質檢查，以及當時的具體指標數值。這對於金融、醫療等高度監管的行業至關重要。
• 可預測性（Predictability）： 開發流程的產出變得更加穩定。我們能更有信心地進行快速迭代，因為有自動化的安全網捕捉品質衰退。這降低了「好心辦壞事」的風險，例如為了修正一個小問題，卻意外導致整體性能下降。
• 知識的規模化（Scalability of Knowledge）： 組織的智慧不再只存在於少數人的大腦中，而是沉澱在可共享、可版本控制、可持續演進的程式碼庫裡。這正是知識蒸餾（Knowledge Distillation）概念在工程流程層面的體現。

許多團隊在談論 MLOps 時，往往聚焦在工具鏈的搭建，例如如何串接 TFX 或 MLflow。但工具只是載體，更核心的挑戰在於組織與文化的轉變：我們是否願意投入時間，將那些看似「只可意會，不可言傳」的專家直覺，一步步轉譯成冷冰冰但絕對可靠的程式碼？唯有跨出這一步，AI workflow 的規模化才真正成為可能。

延伸閱讀

• The Amazon SageMaker Studio IDE for end-to-end ML development
• MLOps: Continuous delivery and automation pipelines in machine learning
• A Systematic Review of Model Evaluation in Machine Learning

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。