實施人工智能：企業在擴展模型方面存在哪些錯誤

高管們正在向人工智能投入數百萬美元，但 BCG 2025 年的一項研究發現，只有約5% 的公司從人工智能中大規模獲得了可衡量的價值，而大多數公司卻很少看到或根本沒有。與此同時，多項調查顯示，由於數據貧乏、治理薄弱和商業價值不明確，超過一半的人工智能項目從未投入生產或在概念驗證後被放棄。

問題不在於缺乏聰明的模型。問題在於這些模型如何日復一日地運行、擁有和維護。換句話說，人工智能運營是最大的風險和最大的優勢所在。

這篇客座文章探討了為什麼擴展人工智能如此頻繁地失敗，戰壕中出現了什麼問題，以及運營優先的方法如何改變軌跡。

為什麼大多數企業擴展人工智能都失敗了？

大多數大型組織都不缺乏人工智能實驗。麥肯錫最新的人工智能現狀調查顯示，幾乎所有受訪者都表示在某些地方使用了人工智能，但只有一小部分人看到了持續的企業級影響。

實踐中會發生什麼：

• 跨業務部門啟動了數十個概念驗證
• 少數在演示中看起來很有希望
• 很少有人能夠通過安全審查、集成工作和真實的用戶反饋

在這種模式之下存在一些可預見的問題：

• 人工智能是一種一次性的“舉措”而不是一種運營能力
  人工智能被視為一個有開始和結束日期的項目。有一個預算週期、一個供應商、一個儀表板、一個演示文稿。我們缺少的是把人工智能視為一種需要路線圖、所有權和運行預算的產品的觀點。
• 忽視生產環境的試點
  許多試點默默地依賴於手工整理的數據集、手動特徵工程或單個高級用戶。這些都不存在於實時生態系統中。當團隊嘗試將相同的工件投入生產時，從數據訪問到延遲行為的一切都會立即發生變化。
• 沒有擴大規模的經濟觀點
  董事會聽說過有關生產力提高 10 倍的故事。他們很少看到的是基礎設施、可觀察性、模型更新和變更管理的成本視圖。如果沒有這一點，當第一波項目令人失望時，期望就會螺旋式上升，人工智能最終會被列入“失敗的創新”名單。

大多數企業人工智能擴展手冊仍然假設，一旦選擇了正確的模型和平台，剩下的主要是執行細節。事實上，你設計和運行人工智能操作的方式通常比你首先選擇哪種大型語言模型更重要。

常見的操作陷阱

當我查看失敗或停滯的人工智能計劃時，我幾乎總是發現相同的操作模式。

你在野外看到的陷阱

在這些症狀的背後，一些結構性問題不斷顯現：

• 碎片化的數據供應鏈
  用於訓練、測試和服務的數據來自不同的路徑，但數據管理服務統一這些管道以減少漂移和不穩定。模型在測試中表現良好，但在生產中表現不佳，因為輸入分佈和新鮮度完全不同。
• 跨界協作
  數據科學家擁有筆記本。平台團隊擁有自己的集群。企業主擁有 KPI。沒有人擁有從概念到退休的整個生命週期。每次交接都會帶來延誤、返工和與期望的微妙不匹配。
• 操作風險被視為事後考慮
  一旦產品即將推出，法律、合規性和安全性就會被納入討論範圍。他們看到了完整的解決方案，提出了合理的擔憂，然後項目陷入停滯。感覺就像“治理正在阻礙人工智能”，而真正的問題是後期參與。

如果沒有人工智能運營策略，飛行員就會陷入困境。你最終會得到一些有趣的工作，但這些工作永遠不會融入公司的運作方式。

MLOps 是人工智能操作中缺失的一環

MLOps 通常被描述為“機器學習的 DevOps”。這個定義在技術上是正確的，但它低估了正在發生的事情。在實踐中，MLOps 是將模型轉變為可運行的系統並將其與實際業務成果聯繫起來的學科。

您可以將AI 操作視為 MLOps 必須結合在一起的三個層：

• 資產

對 MLOps 採用的研究表明，工作流程編排、可重複性、版本控制和監控等實踐都與更高的用戶滿意度和更好的結果相關。這聽起來很抽象，直到您注意到缺少這些實踐時故障模式是多麼具體。

MLOps 不是一次性購買的工具類別。它是讓您的數據科學、平台和產品團隊作為一個系統運行的運營支柱。這就是為什麼它是嚴肅的人工智能運營計劃的核心。

在現實生活中發揮作用的治理和監控

許多企業通過編寫長篇政策文件來應對人工智能風險。很少有人能夠將這些文檔轉化為構建和運行模型的團隊的日常工作。

成熟的人工智能運營傾向於將治理構建為三個實際循環：

• 技術監控迴路

最近的行業分析指出，糟糕的數據治理和薄弱的人工智能監管已經成為許多人工智能項目預計在未來 1-2​​ 年內失敗或被取消的主要原因。

我合作過的最成功的組織將這些循環視為其人工智能運營手冊的一部分，而不是單獨的“風險舉措”。他們盡可能地實現自動化（數據沿襲、訪問控制檢查、偏差檢測），並在需要判斷的地方花費人力。

成功擴展人工智能的案例​​​​研究

為了具體說明這一點，讓我們看一下兩種經常出現的匿名模式。

案例研究 1：從概念驗證劇場到 AI 製作

一家全球零售商在各個試點階段擁有 40 多個人工智能用例：需求預測、動態定價、營銷個性化和商店運營。任何時候都只有兩個處於活動狀態，並且都需要持續的人工干預。

關鍵問題：

• 每個團隊都建立了自己的管道和基礎設施模式
• 沒有監控、數據訪問或模型部署的共享標準
• 企業主將人工智能視為“IT 項目”，而不是其損益表的一部分

該公司改變策略，成立了一個小型中央人工智能運營小組，負責三項職責：

• 定義和維護參考 MLOps 堆棧（數據攝取模式、訓練和服務管道、實驗跟踪、模型註冊）。
• 制定並執行可觀察性、治理和成本報告的標準。
• 指導業務團隊將人工智能用例視為具有所有者、成功指標和路線圖的產品。

18 個月內：

• 從想法到首次產品發布的時間從 9-12 個月縮短至約 8 週
• 超過 20 個模型使用共享工具運行，而不是定制腳本
• 季度審查將每個用例與對利潤和庫存的可衡量影響聯繫起來

有趣的部分是沒有改變的部分。底層模型保持相當相似。這一步驟的變化來自於通過共享操作進行規範的企業人工智能擴展，而不是來自奇異的新算法。

案例研究 2：工業人工智能在與現實接觸中仍能生存

一家工業製造商嘗試對關鍵設備使用預測維護模型。第一次嘗試失敗了。根據歷史傳感器數據訓練的模型在離線測試中看起來很準確，但在生產中卻產生了太多的誤報。技術人員不再關注。

內部審查發現了三個根本原因：

• 訓練數據的清理方式並未反映真實的傳感器噪聲
• 實時管道缺少訓練中出現的兩個關鍵信號
• 沒有人描繪出模型預測將如何改變技術人員的工作流程

在第二次嘗試中，團隊將這項工作重新定義為企業人工智能擴展問題，而不是數據科學競賽。

他們：

• 為傳感器流定義了明確的“數據契約”，並保證採樣頻率、單位和丟失數據處理
• 實施了從攝取到服務的統一 MLOps 管道，因此重新訓練的模型可以以最小的摩擦投入生產
• 讓技術人員參與設計，並根據實際情況調整閾值和警報格式

現在的監測包括漂移指示器和現場反饋。當模型開始退化時，再訓練是通過相同的標準化管道進行的，而不是一次性的救援項目。

一年之內，目標資產類別的計劃外停機時間大幅減少。最重要的變化是整個管道的可靠性，而不是模型準確性的大幅躍升。

從這裡到哪裡去？

如果您認真對待擴展模型，請首先將人工智能操作視為一流學科：

• 繪製 2-3 個高價值用例從數據攝取到報廢的完整生命週期
• 確定使模型保持活力的每個手動步驟、交接和“影子流程”
• 決定 MLOps 堆棧的哪些元素將被共享，固執己見的默認值
• 將治理和監控構建到這些默認設置中，而不是將它們置於頂層

在下一波人工智能浪潮中發揮重要作用的組織並不是那些擁有最華麗演示的組織。他們能夠月復一月地悄悄地運行和發展數十種生產模型，而不會出現戲劇性的情況。如果你能讓人工智能操作達到那種成熟程度，那麼你的故事的其餘部分就會開始水到渠成。