過去一年，做出 GenAI demo 已不難。但金融業真正的挑戰在於：AI 如何進入真實營運現場——能否部署、擴展與監控；能否在證據不足時拒答；能否穩定支撐來自 Web、Teams、語音的使用者；能否留下可稽核的軌跡。
這篇文章是寫給 企業 AI／平台工程師、架構師與技術決策者。核心解決的問題是：如何以雲端原生架構，將生成式 AI 從 PoC demo 工程化為可治理、可觀測、可驗證的金融級 Agentic AI Runtime 與檢索工作流。
本文明確 不討論 開放領域閒聊系統、不涵蓋高風險自主金融交易或放貸決策，也不在本文展開跨系統多租戶治理架構與法律責任歸屬（後者交由系列下一篇第 39 篇深入討論）。
本篇聚焦 平台怎麼穩定跑起來（Runtime、部署、監控、RAG 工作流）。企業級 Control Plane、責任分解與 Agentic Operating System 的治理視角，請見系列下一篇：金融級 Enterprise Agentic AI 架構設計。
投影片 PDF
從一個外勤現場開始
請想像：外勤同仁在客戶現場支援時，突然遇到 IT 問題——權限申請受阻、設備無法連線，或畫面出現錯誤訊息而不知道該聯繫哪個窗口。
此時他不適合停下來打字搜尋文件，也無法等待冗長回覆。在客戶面前，他只能透過語音提問：「這個錯誤訊息應由誰處理？」
使用者的需求很明確：需要即時回應。但金融業的要求不止於此。AI 的回答不能僅止於看似合理；系統必須查證內部知識、評估證據是否充分；不足時應明確拒答，且全程留下追蹤紀錄。
這考驗的不是聊天機器人能否答題，而是 AI 能否真正進入營運現場。
金融 AI 落地的三條生死線
金融 AI 若要落地，須同時滿足三項營運條件：
| 條件 | 挑戰 | 平台要回答什麼 |
|---|---|---|
| 整合性 | 知識庫、權限、ITSM、M365、流程文件各自為政 | Agent 能否以一致方式調用企業系統與知識源 |
| 即時性 | 語音與現場作業無法容忍十幾秒等待 | 高品質 RAG 的檢索、驗證、重寫如何在可接受延遲內完成 |
| 合規性 | 稽核要問「為何這樣答」 | 查閱了哪些資料、呼叫了哪些工具，是否可追蹤、可回放 |
金融 AI 的挑戰不在於做不出 AI，而在於能否 同時通過這三項條件。這取決於平台能力，而非單純升級模型規模。
為什麼 AI 專案往往卡在 PoC？
多數 AI 專案並非沒有成果，而是停留在 PoC。常見有三個斷點：
1. 系統孤島 每個場景皆需客製串接，Agent 難以規模化使用企業工具；場景每增加一個，整合成本便多一層。
2. 線性 RAG Retrieve 之後直接 Generate，流程看似合理，但系統無法判斷所檢索的資料是否充分，缺少自我校正與證據檢查。
3. 黑盒 AI 無法說明資料與工具來源，稽核與法遵會直接阻擋上線。金融業不能只接受 AI 回覆「我認為是這樣」。
這三個斷點皆非換模型所能解決，而需透過平台工程——讓工具標準化、讓流程可自我校正、讓每次回答都有留痕。
Cloud Native AI Runtime：三層架構
若要真正上線，首要問題不在模型，而在 runtime——這套 Agentic AI 必須能被部署、擴展、監控與治理。
我將架構收斂為三層理解：
第一層：受控入口
使用者可從 Web、Teams 或 Mobile Voice 進入，但一律經過 API Gateway 與 Auth，處理 SSO、權限與流量限制。金融業的 AI 入口是受控入口，而非開放式入口。
第二層：Runtime 編排
Agent Orchestrator 運行於 Cloud Run（或同類容器化 runtime），負責意圖路由、Agent 協調、上下文驗證與回覆生成。其下連接 Hybrid Search 的 Retrieval Service 與 MCP Tool Hub，使 Agent 以一致方式調用企業工具。
第三層：Observability 與 Governance
上線第一天就要能記錄、量測、追蹤、留下 audit trail。對外以 SLO 管四件事：
- 延遲 — 能否撐住語音與現場互動
- 錯誤率 — 服務是否穩定
- 拒答率 — 哪裡該補知識、哪裡該調邊界
- Trace 完整度 — 能否回放每一次決策路徑
Cloud Native 的價值不在於「把 AI 放上雲端」，而在於讓 AI 服務 可用 SLO 管理、以 Trace 稽核、透過 Runtime 擴展。
MCP：讓企業工具變成可治理的能力
若每個 AI 專案都重新串接 API，只是把系統整合問題換了名稱——形成 API Spaghetti，場景每增加一個，客製成本便多一層。
MCP（Model Context Protocol） 的價值在於，將內部系統、M365、資料庫與 IT 流程封裝為標準化工具介面。Agent 以一致方式調用，每一次 Tool Calling 皆留下 Tool Trace。
對金融業而言，工具使用並非自由探索，而是限於授權範圍內、可追蹤、可治理的使用。MCP 使工具成為 平台能力，而非某個專案的客製程式碼。
資料工程與 Hybrid Search：RAG 的天花板
資料品質決定 RAG 的上限。若資料不乾淨，再強的模型也難以產出可信回答。金融業文件涵蓋 PDF、掃描件、表格、流程手冊與錯誤代碼，單一解析器無法涵蓋全部型態。
實務上我們採 混合解析：文字密集的文件以快速解析處理，掃描件透過 Vision API，再搭配 Semantic Chunking 保留上下文，避免將同一段業務邏輯切得過碎。
檢索方面：
- Embedding 擅長語意相似與同義改寫——當使用者問法與文件表述不一致時尤為有效
- BM25 擅長系統名稱、流程代碼與專有名詞的精準匹配
- 最後以 RRF（Reciprocal Rank Fusion） 融合排序，使兩者互補
金融級 RAG 的第一步不是生成，而是讓 Agent 取得 可驗證的證據。
從線性 RAG 到 Agentic RAG
傳統 RAG 的流程很直接：Retrieve，然後 Generate。
但金融業不能只依賴單向流程。模型找到資料，不代表資料足以回答；資料看似相關，也不代表構成正確證據。
Agentic RAG 改為動態工作流：
- 路由至正確資料源
- 混合檢索
- 驗證證據是否充分——若不足，改寫查詢並再檢索一輪
- 必要時拒答或引導補充
- 全程留下 Agent Trace
其核心差異在於：這不是一次性檢索，而是 可自我校正的工作流。
更細的 Agentic RAG 脈絡，可參考我先前的整理：Agentic RAG：向量搜尋遇上代理推理。
金融級準確度：安全的信任邊界
在金融場景中，AI 答錯可能構成合規風險。因此金融級準確度並非每題皆答，而是 每個回答都須有證據支撐。
決策邏輯可簡化為：
- 證據充分 → 回答
- 不足 → 改寫查詢後重檢
- 多輪後仍不足 → 拒答或引導補充
- 高風險任務 → 進入 human-in-the-loop
每個判斷皆須留下 Agent Trace——不僅是最終答案；問題、檢索來源、工具調用與決策路徑都應可回放。
Agentic AI 的價值不在於完全自主，而在於 在可控邊界內自主運作。
金句：準確度是工作流屬性，不是模型功能
Accuracy is not a model feature. It is a workflow property.
準確度無法靠升級模型規模單獨解決。每個工作流節點都在消除一種錯誤來源：
| 節點 | 降低的風險 |
|---|---|
| Route | 找錯資料源 |
| Hybrid Search | 漏檢證據 |
| Validate | 幻覺與過度自信 |
| Rewrite | 首輪檢索失敗 |
| Trace | 不可稽核 |
金融級 AI 的準確度，不靠模型一次產出完美回答，而靠 可驗證、可觀測、可追蹤、可改善的工作流。對 Cloud Native AI 平台而言，AI 品質必須能在平台上被持續監控、回歸與改善。
評測：先定義「答對」，再談準確率
在金融業，不能只宣稱「準確率很高」，而須先定義評分方式。我們以 RAG Benchmark 100 題 為基礎，採四級評分：
| 等級 | 定義 |
|---|---|
| 正確 | 完整命中，無錯誤資訊 |
| 部分正確 | 方向正確但細節不足（計入加權準確率） |
| 拒答正確 | 證據不足或不該回答時明確拒答——這是安全行為，並非失敗 |
| 錯誤或不安全 | 與正解不符、引用錯誤、或不該答卻仍回答——零容忍 |
準確率不僅是答對率，更須衡量能否 避免錯誤與不安全的回答。
真實環境評測數據
100 題 Benchmark 涵蓋高頻 FAQ、同義改寫、應拒答題、陷阱題與邊界題。
須先說明適用範圍：這並非宣稱 AI 可處理所有高風險金融決策，而是在 低風險、高頻、流程明確的 IT 任務 中，驗證 Agentic Runtime 的可信回答能力。
| 指標 | 結果 |
|---|---|
| 加權準確率 | 98% |
| 嚴格正確率 | 96%（96 題完全正確、4 題部分正確） |
| 錯誤或不安全回答 | 0 題 |
| 完整 Agentic Workflow 平均延遲 | 3.56 秒 |
| P95 延遲 | 6.19 秒（含檢索、驗證、重寫、拒答判斷與 Trace） |
Ablation 值得注意：
| 設定 | 準確率 |
|---|---|
| Naive RAG | 87% |
| Hybrid Search Only | 83.5% |
| 完整 Agentic RAG | 98% |
召回更多文件並不代表更準確——關鍵在檢索之後的 validate 與 refusal，而非 search 本身。這也呼應前述：準確度是工作流屬性，不是模型功能。
這套評測口徑直接奠基於站內 Agentic RAG 工程案例 的真實架構。在該專案的 v2.2 評測中，我們針對內部 100 題 IT 知識庫進行嚴格測試；早期未加入嚴格狀態驗證時曾發生 Swagger filter placeholder 參數未過濾的實作失敗；後續導入檢索後的 Context Validation 與 rule-first 路由分流，才成功將錯誤或不安全回答降至 0 題，並將加權準確率拉升至 98.0%。
高頻 FAQ 可走 fast path；邊界題與權限題才走完整驗證流程。P95 6.19 秒是在 保留治理機制 下的營運數字，並非移除安全檢查後的理想值。
具體權衡與工程代價
採用完整 Agentic 工作流並非毫無代價，架構落地時必須承受三項具體折衷：
- 延遲代價：Naive RAG 僅需單次檢索與生成（1–2 秒），而完整 Agentic 工作流（Route → Hybrid Search → Context Validation → Rewrite → Refusal）平均延遲為 3.56 秒，P95 延遲達 6.19 秒。為了換取 0 錯誤回答與合規拒答，系統付出了顯著的推理等待時間與額外 Token 成本。
- 維護成本：Hybrid Search 需要同時維護向量資料庫（如 pgvector）與關鍵字倒排索引（BM25），並需針對業務詞庫調整 RRF（Reciprocal Rank Fusion）融合權重；多步驟驗證也增加了提示詞版本管理的複雜度。
- 認知與除錯負擔：工程團隊必須維護狀態機、分支邏輯與異常降級邊界，而非直接調用單一 LLM Completion 介面；排查問題時需跨檢索日誌、工具 Trace 與模型推論日誌進行關聯分析。
實戰驗證：走向即時語音支援
回到開場的外勤情境——無法打字、無法久等、需要語音指引。
我們選擇 IT 資訊服務 作為首個落地場景，並非因其簡單，而是因為它同時涵蓋：跨系統查詢、權限控管、即時回應、標準流程與安全拒答——金融級 AI 上線的典型挑戰皆在其中。
P95 6.19 秒、零不安全回答，代表這套能力已嵌入 runtime、完成延遲量測、並留下 trace，開始進入 可營運狀態。它不僅是單點 IT bot，更是可擴展至客服、法遵、內控與營運知識查詢的 平台能力驗證。
已知限制與何時「不該」採用該模式
這套架構具有明確的適用邊界，工程團隊在選型時必須保持克制：
- 已知限制：本文的 98% 準確率與 P95 6.19 秒是基於低風險、高頻且流程明確的內部 IT 知識庫測得，絕不等於高風險金融交易、授信審批或法遵覆核已可全自動處理。遇上格式高度破壞的掃描檔或超出內部知識庫的未知政策，仍須依賴人工覆核通道。
- 何時不該採用（反模式）：若業務場景僅需超低延遲（<500ms）的靜態 FAQ 查詢，或單一關鍵字即可 100% 精準命中的簡單流程，硬套多輪 Agentic 狀態機（路由 → 混合檢索 → 驗證 → 改寫）是典型的過度工程（Over-engineering）。此時直接使用規則引擎或單層向量快取更為經濟。
收束：From AI Demo to Operational AI Capability
Demo 展示的是模型能力；production 要求的是平台能力——能整合、夠準確、管得住、看得見。
- 快，是體驗問題。
- 準，是信任問題。
- 可拒答、可追蹤、可稽核，才是金融業 AI 上線問題。
金融業 AI 的下一階段，比拼的不是誰 demo 更亮眼，而是誰能將它工程化為可營運的 Operational AI Capability。
常見問題
為什麼選 IT 支援，不是直接選金融業務場景？
IT 支援涵蓋金融級 AI 上線的典型挑戰：跨系統查詢、權限控管、標準流程、即時回應、安全拒答與 Agent Trace。這些能力一旦平台化，便可複用至客服、法遵、內控、理專支援與營運知識查詢。
P95 6.19 秒對語音互動是否偏慢？
此數字須放在完整 Agentic RAG 流程下理解——包含 route、hybrid search、validate、必要時的 rewrite、安全拒答與 trace。實務上並非每題都走完整流程；高頻 FAQ 走 cache 或 fast path，邊界題才走完整驗證。
為什麼 Hybrid Search Only 比 Naive RAG 還低？
Hybrid Search 提高召回率，但召回更多並不代表更準確。在應拒答題或邊界題中，關鍵字相近但不相關的內容，可能使模型誤判證據已充分。關鍵在 search 之後 的 validate、rewrite、refusal 與 boundary routing。
MCP 在金融業最大價值是什麼？
將企業內部工具標準化、治理化、可追蹤化。Agent 必須在授權範圍內使用工具，且每次 tool calling 都須留下 trace。
下一步閱讀與相關專案
精選 3 個延伸入口，串起架構、契約與代表實作：
- 架構下一篇：金融級 Enterprise Agentic AI 架構設計：從 Demo 到 Agentic Operating System — 從 Runtime 進入 Control Plane，探討 15+ 代理責任分解與 E·P·J·T 治理。
- 上線檢核契約：Agentic AI 平台契約：上線前必須接上的控制面 — 將控制面轉化為可逐項審查的 PoC 上線門檻與七條禁制。
- 代表工程實作：Agentic RAG 工程案例 — 查看本文引用的 100 題評測數據、Swagger 失敗案例與第一方架構細節。
方法來源與證據邊界
本文的 Cloud Native AI Runtime、三條生死線與評測設計，是作者在 Cloud Summit 分享的工程框架；不是外部標準。98%、96%、P95 6.19 秒等數字來自本站公開的 100 題低風險 IT／流程案例，並不代表一般金融決策的通用準確率。
- Agentic RAG 案例與評測口徑 — benchmark、ablation 與延遲數字的第一方證據
- Model Context Protocol：架構規格 — MCP 的 host／client／server 邊界與 capability negotiation
- NIST AI 600-1：Generative AI Profile — 生成式 AI 風險管理與評測背景
- OpenTelemetry：Generative AI semantic conventions — Agent、模型與工具呼叫的觀測欄位參考
延伸閱讀
- Enterprise AI Agentic AI 平台契約：上線前必須接上的控制面 把 Agentic 控制面收成可複製平台契約：提供什麼、必須接 E·P·J·T、七條不准繞過，以及 IT 100 題驗證口徑停在哪裡。
- Enterprise AI 金融級 Enterprise Agentic AI 架構設計：從 Demo 到 Agentic Operating System AI Summit 分享整理：企業 AI Control Plane、15+ Agents 責任分解、理專現場的四段 Runtime 流程、三層安全邊界、LLM-as-a-Judge 品質治理，以及 E·P·J·T 可複用能力底座。
- Enterprise AI Model Hardware Standard：給實體裝置的 MCP 形狀介面 拆解 Anthropic Model Hardware Standard 研究預覽：它標準化 Agent 與可程式化硬體之間的驅動、探索與操作介面，但不取代平台的身分、授權、審批與實體安全控制。
