一句話說明

FDE 的 AI 導入工作分成 Discovery、POC、Pilot、Production 四個階段，每個階段都有不同的目標和挑戰。

為什麼 AI 導入需要 FDE？

很多企業買了 AI 工具或訂閱了 LLM API 之後，發現事情沒有想像中簡單。工具裝好了，但不知道怎麼接上自己的資料。模型跑起來了，但回答的品質不如預期。做了一個 demo 很漂亮，但要上正式環境的時候，資安部門、IT 部門、法務部門全部跳出來說不行。

這就是 FDE 存在的原因。FDE 是那個把 AI 技術從「看起來很厲害的 demo」變成「企業真的在用的系統」的人。這個過程通常分成四個階段。

階段一：Discovery（需求探索）

Discovery 是整個專案的起點。這個階段的目標是搞清楚三件事：客戶到底想解決什麼問題、有什麼資料可以用、AI 是不是正確的解法。

理解客戶痛點

FDE 到客戶現場的第一件事，通常是訪談。這裡說的訪談是直接坐下來和不同部門的人聊天，了解他們日常工作的流程和瓶頸，和填問卷式的需求調查完全不同。

常見的訪談對象包括：直接使用者（每天做這件事的人）、他們的主管（關心效率和成本）、IT 部門（管系統和資安）、高階主管（決定預算和優先順序）。

一個好的 FDE 在這個階段會問很多「為什麼」：為什麼這個流程要花這麼長時間？為什麼這份報告要人工做？為什麼之前試過的方案沒有成功？

資料盤點

AI 系統的品質取決於資料的品質。在 Discovery 階段，FDE 需要做一次資料盤點：

有哪些資料可以用？格式是什麼？存在哪裡？

資料的品質如何？有沒有缺值、重複、不一致的問題？

資料的敏感度等級是什麼？哪些資料可以送到外部的 LLM API、哪些必須留在地端？

資料量有多大？是幾百份文件還是幾百萬筆紀錄？

可行性評估

根據訪談和資料盤點的結果，FDE 需要評估 AI 在這個場景是否可行。有些問題聽起來很適合用 AI 解決，但實際上可能因為資料不足、需求太模糊或準確度要求太高而不適合。

這個階段最常見的陷阱是客戶說「我想用 AI」，但其實他們的問題用一個簡單的規則引擎或資料庫查詢就能解決。好的 FDE 會誠實地告訴客戶：你不需要 AI，用這個更簡單的方法就行了。

Discovery 階段的產出通常是一份評估報告，包含問題定義、資料現況、建議方案和預估時程。

階段二：POC（概念驗證）

POC 的目標是用最少的時間和資源，證明 AI 在這個場景能不能用。重點是做一個足以回答「這條路走不走得通」的原型，不需要做出完整的產品。

選模型

根據客戶的需求和限制，FDE 需要選擇適合的 AI 模型：

如果客戶允許用雲端 API：GPT-4o、Claude、Gemini 都是常見選項。要考量的因素包括中文能力、Context Window 大小、成本和延遲。

如果客戶要求地端部署：Llama、Mistral 等開源模型是主要選項。需要評估硬體需求、量化後的效能損失、以及 推論 速度是否符合需求。

如果是特定領域任務：可能需要考慮 Fine-tuning 或用 RAG 來補足模型的領域知識。

建立 RAG Pipeline

企業 AI 最常見的應用場景是讓 AI 回答公司內部文件的問題。這需要建立一個 RAG pipeline：

  1. 文件處理：把 PDF、Word、HTML 等格式的文件轉成純文字。台灣企業常用的格式還包括掃描的文件（需要 OCR）和表格密集的 Excel 檔。

  2. Chunking：選擇適合文件類型的切割策略。法律合約適合用語意切割，技術文件適合用標題切割，客服對話適合用對話輪次切割。

  3. Embedding：選一個對中文效果好的 Embedding 模型，把文字段落轉成向量。

  4. 向量資料庫：部署向量資料庫，存放所有的向量。在 POC 階段，用 Chroma 或 FAISS 通常就夠了。

  5. 查詢和生成：寫好 Prompt 模板，把查詢結果組合成 LLM 的輸入，產生回答。

展示給利害關係人

POC 做完之後，最重要的一步是 demo。FDE 需要準備一場簡報，向客戶的決策者展示：AI 系統能做到什麼、還做不到什麼、如果要上正式環境需要什麼投資。

好的 demo 不是只展示成功案例。FDE 應該也要展示系統的限制：它會答錯什麼類型的問題、在什麼情況下效能會變差、有哪些邊界情況還沒處理。

POC 階段的常見問題：

用太乾淨的測試資料：demo 的時候看起來很好，但接上真實資料就崩潰。

忽略延遲：POC 可能一個查詢要等 10 秒，demo 的時候客戶不介意，但上線後使用者會抱怨太慢。

不算成本：忘了估算 LLM API 的呼叫成本，上線後帳單嚇死人。

階段三：Pilot（試運行）

POC 證明可行之後，下一步是 Pilot——在有限的範圍內接上真實資料和真實使用者，看系統在現實條件下的表現。

接真實資料

POC 可能用了幾十份文件做測試，Pilot 要接上客戶的完整資料集。這時候會遇到各種 POC 時沒碰到的問題：

資料格式不一致：同一類文件，不同部門的格式不一樣。

資料量暴增：幾十份文件的向量資料庫和幾萬份文件的向量資料庫，效能表現完全不同。

資料更新頻率：客戶的文件不是靜態的，需要設計增量更新的機制。

Edge Case 處理

真實使用者會用各種你想不到的方式使用系統。Pilot 階段是收集這些邊界情況的最好時機：

使用者用台語混中文發問。

使用者問的問題跟系統的知識範圍完全無關。

使用者把敏感資訊貼進輸入框。

使用者期待 AI 做系統設計上不支援的事情（例如修改資料、發 email）。

FDE 需要根據這些情況調整 System Prompt、加入 AI Guardrails、或修改 Chunking 策略。

安全審查

在 Pilot 接上真實資料之前，資安審查是必經步驟。FDE 需要和客戶的資安團隊一起確認：

資料分類有沒有做？哪些資料可以送到 LLM API、哪些不行？

存取控制有沒有設好？不同使用者能不能看到不同的文件？

輸出過濾有沒有做？AI 的回答有沒有可能洩漏不該顯示的資訊？

日誌有沒有記？每次 AI 的輸入輸出有沒有被記錄下來，方便事後稽核？

Prompt Injection 防護做了沒？有沒有人可以透過精心設計的輸入來繞過系統的限制？

使用者訓練

AI 系統再好，使用者不會用也是白搭。FDE 需要做使用者訓練，教他們：

怎麼問問題可以得到更好的答案（基本的 Prompt Engineering 技巧）。

系統的限制是什麼，哪些問題不應該問它。

遇到問題的時候要怎麼回報。

階段四：Production（正式上線）

Pilot 驗證可行後，接下來是正式部署到生產環境。

部署架構

生產環境的架構比 POC 複雜很多。FDE 需要考慮：

高可用性：系統掛了怎麼辦？需不需要多個副本？

自動擴展：使用量突然增加的時候能不能自動擴容？

災難復原：資料備份策略是什麼？

安全架構：AI Gateway 設定、API 金鑰管理、網路隔離。

監控

上線之後不是就結束了，FDE 需要建立監控機制：

效能監控：回應時間、查詢成功率、LLM API 的延遲。

品質監控：AI 回答的正確率怎麼衡量？有沒有定期的人工抽查機制？

成本監控：每天的 Token 使用量、API 呼叫次數、向量資料庫的儲存成本。

安全監控：異常查詢偵測、敏感資料外洩告警。

成本控制

企業 AI 的成本常常超出預期。FDE 可以從幾個方向幫客戶控制成本：

模型分級：簡單的問題用便宜的小模型，複雜的問題才用貴的大模型。

Prompt Caching：重複的查詢可以快取結果，減少 API 呼叫次數。

Context Window 最佳化：不要每次都塞滿整個 context window，只放真正需要的內容。

批次處理：不需要即時回應的任務可以批次處理，利用離峰時段的較低費率。

實際場景範例

企業內部知識庫

一家有 500 人的科技公司想讓員工可以用 AI 搜尋內部文件（技術文件、HR 政策、產品規格）。

Discovery：盤點發現有 3,000 份文件散在 Confluence、Google Drive 和 SharePoint 裡，格式包括 Markdown、PDF 和 Word。

POC：用 100 份核心文件建了一個 RAG 原型，用 OpenAI 的 API。兩週內做完 demo。

Pilot：接上全部 3,000 份文件，開放 50 人試用一個月。發現搜尋品質的主要瓶頸是 Chunking 策略需要針對不同文件類型調整。

Production：部署到公司的 GCP 環境，加上 SSO 驗證和 AI Guardrails，全公司上線。

客服自動化

一家電商想用 AI 處理 70% 的客服問題，減少客服人力。

Discovery：分析了過去半年的客服對話紀錄，發現 60% 的問題集中在訂單查詢、退換貨和商品規格。

POC：建了一個能回答這三類問題的 AI 客服，接上訂單資料庫做即時查詢（用 Function Calling）。

Pilot：在一個客服渠道上線，只處理簡單問題，複雜的轉人工。一個月後 AI 處理了 45% 的問題，準確率 88%。

Production：優化後 AI 處理率提升到 65%，加上即時轉人工機制和滿意度調查，全渠道上線。

台灣企業 AI 導入的挑戰

FDE 在台灣做 AI 導入，會碰到一些在其他市場比較少遇到的挑戰：

中文 NLP 的複雜性：繁體中文的 Tokenizer 效率不如英文，同樣的內容需要更多 Token，成本更高。加上台灣的商業文件常常中英混用，對 Embedding 模型的挑戰更大。

資料隱私法規：台灣的個人資料保護法對資料的蒐集、處理和利用有嚴格規範。FDE 在設計架構時需要確保符合法規要求，特別是涉及個資的場景。

混合雲需求：很多台灣企業（特別是金融和政府）要求敏感資料不能離開台灣。FDE 需要設計混合架構：地端處理敏感資料，只把脫敏後的資料或 embedding 送到雲端的 LLM API。

預算限制：台灣企業的 AI 預算通常比矽谷公司小。FDE 需要更精準地控制成本，可能更常使用開源模型或較便宜的 API 方案。

決策速度：台灣企業的 AI 採購決策流程通常比較長，FDE 需要更多耐心在 Discovery 和 POC 階段說服各層級的利害關係人。

安全考量與限制

AI 導入過程中，每個階段都有對應的安全檢查重點：

Discovery 階段：確認客戶的資料分級標準、了解法規限制、簽好保密協議。

POC 階段：不要用真實敏感資料做 POC。如果必須使用真實資料，確保在安全的隔離環境中操作。

Pilot 階段：這是安全審查的重點。資料存取控制、輸出過濾、Prompt Injection 防護、日誌記錄，每一項都要做到位。

Production 階段：持續監控安全事件、定期做安全掃描、有事件回應計畫。

跨階段注意事項：

不要把開發環境的 API key 用到生產環境。

每次部署都做依賴套件的安全掃描。

建立資料刪除機制——客戶要求刪除資料的時候，你要能做到。

定期檢查 LLM 供應商的資料處理政策有沒有變更。

知識檢測

讀完文章後，測試一下你對這個主題的理解。

常見問題

POC 到 Production 通常要多久？

看專案的複雜度。一個簡單的 RAG 知識庫，從 POC 到上線可能 2-3 個月。涉及多系統整合的複雜場景，可能要 6-12 個月。最常拖延的原因通常是組織內部的決策流程和資安審查，技術面反而不是瓶頸。

客戶的期望太高怎麼辦？

這是 FDE 最常遇到的挑戰之一。管理期望最有效的方法是在 Discovery 階段就誠實地說明 AI 的限制，然後在 POC 階段用實際的數據來佐證。與其承諾「AI 可以解決所有問題」，不如說「我們可以先解決這個特定的問題，成功之後再擴展範圍」。

資料品質很差怎麼辦？

這太常見了。FDE 的選擇通常有三個：花時間清理資料（成本高但效果好）、調整方案來容忍髒資料（例如用更強的模型或更多的 prompt engineering）、或是誠實地告訴客戶「資料品質達到某個標準之前，AI 的效果會有限」。通常是三者的混合。

客戶想要完全地端部署，但效能不夠怎麼辦？

這在台灣很常見。解法包括：用 量化 過的小模型減少硬體需求、設計混合架構讓非敏感的查詢走雲端 API、或是協助客戶採購適合的 GPU 硬體。有時候也需要和客戶討論，是否某些非敏感的任務可以放寬地端部署的要求。

總結

FDE 的 AI 導入工作是一個從模糊到清晰、從原型到產品的過程。Discovery 搞清楚問題、POC 驗證可行性、Pilot 在真實環境中測試、Production 正式上線。每個階段都有不同的挑戰和安全考量。

在台灣做 AI 導入，中文 NLP、資料隱私法規和混合部署需求是三個最常遇到的額外挑戰。好的 FDE 不只是把系統部署上去，而是在整個過程中幫客戶做出正確的技術決策、管理好利害關係人的期望、確保安全合規，讓 AI 系統真正產生商業價值。

想了解 FDE 這個角色的完整背景，可以閱讀 FDE 是什麼。想知道成為 FDE 需要哪些技能，參考 FDE 技能指南。

參考資料