這幾年大家在各種 AI 活動上，應該都看過很多很厲害的 Demo，模型能推理、能對話、能自動完成複雜任務，看起來什麼都做得到，但真實世界的企業導入，是另一回事，客戶的資料是亂的，需求是發散的，系統用了十幾年，而且第一次見面時，客戶多半還是對 AI 半信半疑。
CloudMile 萬里雲接觸過上千個大大小小的專案，有金融業、有半導體，也有很多看起來很簡單，做下去才知道完全不是那麼一回事。
一開始可能只是一個部門的需求，結果做到後來，每個部門都想加入自己的功能，我們甚至需要猜客戶那些沒有說清楚的需求，累積多了之後，我們發現很多客戶遇到的問題，其實都很像，有人不知道該從哪裡開始導入 AI；有人做到一半，需求越來越多；有人 AI 已經上線了，才開始擔心資料安全、權限控管，或是不知道 AI 到底有沒有亂回答。
原來企業導入 AI，不是一個模型、一個工具就能解決的事情，而是需要一個完整的導入流程，而這件事，也讓我們越來越認同「FDE」這個角色的重要性。
先從 FDE 這個角色講起，要解決客戶問題，你不能只是坐在辦公室裡
國外把處理這種混亂的角色叫做 FDE，前線部署工程師（Forward Deployed Engineer），這個角色最早由 Palantir 提出，獲得 OpenAI、Anthropic 等 AI 公司認同並積極擴張類似團隊。
FDE 的核心概念是模型本身不是產品，「可靠度」才是產品，意思是，再強的模型或工具，如果沒辦法在企業裡穩定運作，對客戶來說就沒有價值。
坐在辦公室把功能寫完，只能做出工具；真正解決問題，需要一直走進客戶現場，看他們怎麼工作、怎麼卡住、怎麼使用，最後交付一套真的能穩定運作的系統。
CloudMile 萬里雲的工程團隊，其實就是用這樣的思維陪每個客戶導入 AI，走過這麼多專案之後，我們也整理出一套自己的流程，我們認為一個 AI 導入專案，大概都會經過五個階段。
階段一：接到客戶需求，先訪談，不要先寫程式
我們給自己的定位，比較像可以做全身健康檢查的醫院，當每個客戶走進來說「我想做 AI」，通常我們不會直接開藥，而是先做完整的檢查，我們會透過幾個問題訪問客戶：
你現在最痛的是什麼，不是想做什麼，是什麼事情每天在消耗你的團隊；這個專案有沒有編列預算，預算的規模，決定了方案該怎麼設計，沒有對齊預算就開的規格，不然都是白做；你們內部的流程長什麼樣子⋯⋯等等的。
最後，也是最重要的，就是這個專案要拍板定案是「誰說了算？」，因為推動 AI 導入，最怕的是談了三個月，才發現真正能決定的人根本還沒進來。
那我們主要會檢查什麼？
除了聊他們希望的模型、了解他們的概念，再來會聊資料，AI 很像一個人，它的個性、談吐、知識，都是被餵進去的資料養成的，這在 AI 工程裡有一句老話：「Garbage in, garbage out」，餵進去的是垃圾，出來的就是垃圾，所以跟客戶談導入之前，第一件事是盤點你手上到底有哪些資料、品質如何、放在哪裡、乾不乾淨。
不過訪談還是有一個天生的限制，用講的，客戶說不清楚自己要什麼。
有次我們收到一家企業想做 HR 系統，一開始需求很單純是用 AI 分析履歷，節省人資篩選工時，因為口頭很難說明 AI 能做到什麼程度，我們後來直接做了一個 demo，讓人資上傳履歷，AI 自動分析，給出評估結果。
不過 demo 一出來，事情開始有了變化，客戶看到成品後，想法一路長出來，先是要調整 UI/UX、加入 PM，接著要串接外部人力銀行平台，最後甚至提出，能不能做一個 AI Agent 直接當面試官？需求從一位總監開始，擴散到內部系統、外部供應商，越提越發散。
需求不是問出來的，是做出來之後才浮現的，而且只要是團隊決心要找到問題並坐下來訪談，「需求蔓延」這個狀況一定會出現。
但我們怎麼讓這件事情收斂？當然不會每個需求都接下來，而是把範疇重新框住，像客戶提出「AI 面試官」的時候，我們沒有直接說不行，而是先做了一版出來，讓大家實際看到它的樣子，再一起討論，結果做出來之後，大家反而看清楚了，這個功能離真正的痛點太遠，投入跟回報不成比例，最後我們一起決定先收掉，把力氣集中回履歷分析這件事並把它做好。
階段二：對焦範疇，弄清楚「到底要做什麼」，比寫程式更花時間
很多人以為 AI 專案最花時間的是開發、調模型，我們原本也這樣以為，直到做了一個零售通路的專案，他們的問題其實很經典，上游供應商提供的商品圖檔沒有命名、沒有分類，每批進貨還會附上採購單、產證、發票等多份文件，內部同仁需要一張一張比對品名、規格這些欄位有沒有一致，品項越多，人工流程就越吃緊，也越容易出錯。
所以我們替他們做了兩套工具，一套用多模態模型，同時理解圖片與文字，自動分類商品圖檔並擷取資訊；另一套負責辨識各種文件，擷取關鍵欄位、交叉比對，再產出差異報告。
看起來真正困難的是模型，但專案做完後，我們回頭翻了一下工時，反而被數字嚇了一跳，整個專案的時間裡，光是需求確認跟方案設計，就占了接近三成，也就是說，在第一行正式程式碼都還沒開始寫之前，我們已經花了將近三分之一的時間一直在跟客戶確認：「到底要做什麼？」
一開始我們也覺得這個比例是不是太高了，但走過更多專案之後，我們反而很確定，這個時間不能省，因為前面少花一天，後面往往就要花更多時間改程式。
階段三：開發與測試，工程師想像的流程，跟使用者真正工作的方式，是兩回事
開發階段最大的敵人，不是技術，而是自己的想像。
工程師想像的使用流程，跟使用者真實的工作方式，可能是不一樣的，有一個文件比對的專案，讓我們對這件事印象很深。
客戶每次進貨都會收到多份相關文件，人員要逐一核對品名、數量這些欄位有沒有一致，我們替他們做了一套 AI 自動比對的系統，而第一版有個設計假設，我們認為，使用者一定會把所有文件準備齊才會開始分析，這個假設在設計會議上聽起來完全合理，文件齊了才比得完整，沒有人覺得有問題。
結果上線測試才發現，使用者根本不是這樣工作的，文件是分批到位的，有些還在對方手上，他們常常只有兩三份，就想先跑一次比對，先抓出有問題的地方，剩下的到了再補。我們原本設計的是一個「等所有人到齊才開飯」的系統，但真實的工作現場，是人到了就先上菜，後來放寬了限制，讓工具去配合人的工作節奏，而不是要求人配合工具。
同一個專案裡，另一個更小的問題，系統比對文件時，如果某個欄位抓不到資料，畫面會顯示「None」，工程師看得懂這是空值，但對使用者來說，那就是四個不知道什麼意思的英文字母混在整張表格裡，系統其實有標出問題，只是它講的語言使用者聽不懂，最後我們只改了一個很小的地方，把 None 全部標成紅色，再把文件之間對不起來的地方，自動整理成一段人看得懂的話，查核的人不用再逐格掃表，一眼就知道哪裡有狀況。
很多不是模型的問題，追到最後，都是資料品質的問題，以及它有沒有貼合真實的使用情境。
階段四：驗收與上線維運，不要讓客戶用「聊天的感覺」評估 AI
AI 跟傳統軟體最大的不同，是它的輸出帶有不確定性，同樣一句話，不同時間送進去，都可能得到不同答案，所以驗收不能靠感覺，我們不會請客戶坐下來跟 AI 聊幾句，就說它好不好，而是會建立一整套 Evaluation（系統化評估 AI 品質）的機制，例如在金融專案裡，曾經做過 NL to SQL（自然語言轉資料庫查詢，讓使用者直接用白話文詢問資料）。
我們會拿過去三個月的真實交易資料建立基準，再請人工手寫查詢，作為標準答案，最後比較 AI 與人工結果的差異，AI 的品質如果是靠「測試起來的感覺」來決定好壞其實很危險，如果跟客戶共同確認一組測試資料，寫進驗收標準，可以比較準確定義，什麼叫做好、什麼叫做可以接受。
雖然 AI 的不確定性沒有辦法消除，但可以管理，而且上線不是終點，隨著資料改變、使用情境改變，AI 的行為也可能會偏離當初驗收時的樣子。
它不一定會當機，更常見的是，它開始一本正經地回答錯誤的內容，所以每一個 Agent，我們都會持續放進 Evaluation 框架裡追蹤，金融業追求的是接近零錯誤；零售、遊戲、Web3 等產業，則有不同的容錯空間。
同一套方法，不同產業，驗收標準也不同，走到這裡，我們原本以為，每個專案都只是不同公司的不同問題，後來才發現不同產業、不同規模的客戶，反而一直卡在同樣幾件事情，當同樣的問題在一個又一個客戶身上反覆出現，我們開始意識到這已經不是某一個專案的問題了。
而這個故事，就是下一篇真正想分享的內容。
(本文訊息由 CloudMile 萬里雲提供，內文與標題經 TechOrange 修訂後刊登。新聞稿 / 產品訊息提供，可寄至：[email protected]，經編輯檯審核並評估合宜性後再行刊登。圖片來源：CloudMile 萬里雲。）
