大多數公司嘗試人工智慧的結果都是失敗的墓碑
它是一個包含演示文稿、幾個休眠的 Slack 頻道和幾項在演示中表現不錯但最終停止運作的試行計劃的資料夾。沒有人故意讓它們失敗，它們只是從未進入日常使用狀態。
舒適的故事是這些都是便宜的實驗，所以損失不大。這個故事是錯誤的。一個從未進入生產階段的試行計劃成本遠高於建造它的費用，而最大的成本甚至不會出現在帳單上。
試行計劃實際花費了什麼？
從可計量的地方開始。一個試行計劃消耗工程時間、供應商費用以及同意測試的人員的注意力。但測試試行計劃的人通常不是閒置資源。他們通常是你最強大的操作員，因為他們對流程有足夠的了解，可以判斷人工智慧是否有所幫助。他們花時間評估不產生任何成果的工具，每小時都是從只有他們才能完成的工作中拿走的時間。
然後還有數據工作。大多數嚴肅的試行計劃需要有人清理記錄、標記範例或連接到實時系統。這個努力是真實且持久的——但只有在試行計劃成功的情況下。當它停滯不前，清潔的數據會過期，整合也會關閉。你付錢建造資產，卻讓它過期了。
從未記錄在帳戶上的成本
最昂貴的部分是失敗的試行計劃對所有觀察者造成的影響。
第一個受害者是可信度。當一個有希望的工具展示給團隊後消失，人們會明白人工智慧項目只是表演。下一次你提出一個項目時，最強的操作員——正是你需要的人——會選擇退出，因為他們已經見證過這種結局了。你不是從零開始一個新試行計劃，你是從負數開始，而且是自己累積的懷疑。
第二個受害者是時間。在你的試行計劃陷入評估僵局期間，基礎模型仍在改進，競爭對手仍在交付。你原本希望抓住的優勢並不存在於演示中，而在於實用用戶依賴系統的數月積累學習過程中。一個從未交付的試行計劃給你帶來了任何好處。
試行計劃為何會停滯不前？
試行計劃很少因為技術不成熟而失敗。它們停滯的原因是在寫下第一行代碼之前就存在：
- 沒有權限負責交付的擁有者。 如果試行計劃由「創新」贊助，但不是由將運行它的團隊贊助，它就沒有進入生產的途徑。
- 從未明確定義成功標準。 如果在事先沒有同意什麼結果會導致部署，那麼每一個結果都看起來令人印象深刻，「讓我們繼續探索」。
- 最後一步超出範圍。 許可、監控、錯誤處理和支援被視為後想，因此一個可運作的原型仍需數月時間才能安全依賴。
- 試行計劃解決了演示問題，而非實際工作。 它對乾淨的案例表現出色，但忽略了構成大部分實際工作的髒亂 30%。
請注意，這些都不是模型問題。它們是關於所有權、範圍和承諾的決策——在開始之前做出的決策。
以將要交付為目標進行試行計劃
解決方法是停止將試行計劃視為技術問題，而是將其視為生產的第一階段。在開始前，指定負責生產的工具的所有者並給予他們否決權。寫下單個觸發部署的數字和清潔關閉的數字。將未光彩的最後一步工作——訪問、監控、模型錯誤時的備用方案——納入試行計劃範圍內，而不是將其放在之後。選擇一個實際的工作流程和實際的體積，而非展示。
這會慢一些開始，但正是這個原因。少數旨在交付的試行計劃會勝過繁忙的實驗管道，在結果上以及你與團隊保持的信心上都更好。
在 Hercules A，當客戶的人工智慧努力停滯不前時，我們首先尋找的不是更好的模型，而是缺失的所有者以及未定義的終點線。技術很少是瓶頸。
試行計劃並不因為它工作而成功。它的成功是因為人們依賴它，如果它消失他們會注意到。任何短於這一點的都是你已經付出但尚未計算的成本。