人工智慧專案的兩個結局
一個AI專案的結束有兩種形式。第一種是啟動，每個人都會慶祝。第二種則是更安靜的結束，幾個月的後，當供應商改變表格、法規調整，或模型版本退役，系統開始提供較差的答案時發生。這時問題簡單：誰來修復？
如果誠實的回答是「我們必須重新召回諮詢師」，那麼你購買的不是系統，而是租用了一個，而計費表仍在運行。
實際的所有權意味著什麼
所有權不是一堆在最後一天交給你的文件。它是在公司內具備的四種實用能力：
- 運作：有人知道如何檢查系統當下是否正常運作，並在出現問題時得到通知。
- 調整：有人可以修改規則、添加文檔來源或更新提示，而不需要開展支持工單。
- 評判：有人能區分好輸出和壞輸出，並提供證據而非印象。
- 替換：你了解系統依賴於什麼、遷移成本是多少，以及誰才能完成工作。
大多數交接僅提供第一種能力，而忽略其他三種。這就是為何系統會偏離正軌。
重要的文檔
文檔是為了滿足合同條款而撰寫的，因此它描述著無人會觸及的架構，並省略了人們真正需要的事項。保持清單簡短，並堅持以下幾點：
- 故障處理手冊：最可能出現的五個問題、它們從外面看起來是什麼，以及每個問題的前三步驟。為當值人員撰寫，而非為工程師。
- 評估集：100到200個真實案例及其正確答案，由負責該工作的人員同意。這是整個專案中最有價值的工件。
- 變更日誌及原因：不僅記錄配置內容，還要記錄規則存在的理由。沒有原因的規則會被下一個人刪除。
- 依賴關係和成本表：每個模型、API和供應商；每月成本；合同續約日期；如果消失會導致什麼斷線。
- 數據地圖：數據去向、誰能查看以及保留時間。法律和安全團隊可能在不預警的情況下需要這份文檔。
其他文檔可選。如果文件無法幫助某人運作、調整、評判或替換系統，它只是裝飾品。
你需要的三個人
你不需要聘用一個機器學習團隊。你需要三個具體的人員，並且應該在專案開始前而非最後一個月指定他們。
- 業務所有者：決定系統應做什麼，並承擔預算。他們批准變更並拒絕範圍擴張。這不是技術性角色。
- 技術保管人：能閱讀配置、進行受控變更、測試並將其部署到生產環境的人。通常是現有開發人員或IT工程師，他們無需構建模型，但必須能夠修改和部署現有模型。
- 質量所有者：來自系統服務於該部門的資深理賠處理員、護理主管或支援團隊領導。他們維護評估集並決定「好」是什麼樣子。沒有這個角色，幾週內品質將成為主觀意見。
總體內部成本：通常是一份全職人員的費用，一旦系統穩定後。失敗模式不是開支，而是沒有人指定負責。
在可以抱怨之前測試交接
不要接受文檔作為轉移證明。在諮詢師還在合同範圍內的最後幾週進行一次實時測試。
選擇一個真實的變更——在知識庫中添加新產品、收緊拒絕回答系統規則，或更換更新後的價格表。請你的團隊在諮詢師在場但保持靜默的情況下進行變更。計時它。然後讓你的質量所有者運行評估集並確認其他東西沒有破損。
如果你的團隊能在一天內完成這一切，你就擁有了系統。如果需要一周時間且有三個問題，你發現了在發票結束前需要關閉的缺口。任何結果都比在合同開始時寫入這些要有價值得多。
將此納入合同條款。交接里程碑、指定接收團隊和監督變更測試，在工作開始後談判比在開始前更容易。
我們在Hercules A就是這樣建造的，這意味著我們的專案結束。這就是目標。評估一個AI專案的好壞，不是諮詢師一年後嵌入的深度，而是你的內部人員能否自信地改變系統而無需呼叫任何人。