【金融GAI先行者經驗：玉山金控】從單一應用邁向規模化發展，自建GAI開發框架支持不同業務需求

兩年前，玉山金控就開始布局生成式AI。從單一GenAI應用切入，一路發展出多款應用服務。今年初，玉山金更正式推出多功能的生成式AI平臺GENIE，可透過API方式，將GenAI整合到不同的應用場景和內部系統中，讓生成式AI更容易落地到多種工作流程中。

今年上半年，玉山透過GENIE平臺推出了11項生成式AI應用服務，包含基礎和進階應用服務。前者包括了純文字和圖片生成、會議記錄生成和摘要總結翻譯等基礎服務，每項應用服務都能適用於多種場景。後者則是可以開發進階版的GenAI應用服務，提供特定場景、更複雜的功能。例如，法規文件比對、市場資訊摘要和生成，或運用客服資料進行顧客情緒分析。

在發展通用技術平臺的過程中，玉山也不斷搜集更多適用GAI的場景，他們不僅關注舊場景，也探索因新技術誕生的新場景，更歸納出不同場景快速上手GenAI的作法。玉山銀行智能金融處資深副總工程師林鉦育透露：「要用新架構瞄準新場景，先從RAG（檢索增強生成）開始。」

不過，到了今年下半年，隨著內部GAI應用發展數量和需求逐漸增加，玉山關注的焦點逐漸轉向，開始思考如何讓GAI應用走向規模化。

一方面，不同業務單位有相似需求，需要共用的開發框架，讓同樣功能的元件，重複運用到不同場景，快速支持業務單位發展GAI應用。另一方面，玉山也開始設想，若未來需要將GAI發展至更多特殊場景，如配合集團海外戰略，得將服務推往國外，甚至是非英文語系國家中，「我們要怎麼做？」玉山銀行智能金融處主任工程師徐銘霞開始思考更長期的課題。

短期內，玉山需要一個GenAI開發框架，快速支持業務單位各種需求，但考慮到框架的永續性，玉山期望，開發框架也能彈性擴充，日後遇到從未接觸過的場景，也能快速因應。這個框架，不僅要讓開發者靈活運用各種元件打造GAI應用，還要整合新、舊元件，讓開發者發展GAI新元件同時，也能運用玉山過往的AI技術元件。

現成開發框架存在限制，無法滿足彈性需求

一開始，玉山考慮採用現成的GenAI開發框架，進行可行性評估後發現，無法滿足他們的需求。

首先，現成開發框架仍有不少限制。以目前流行的GenAI框架LangChain為例，這個框架將既有GenAI元件封包成固定形式，難以因應複雜的金融業務邏輯來調整。「 有些資料處理過程需要結合業務邏輯，它（框架）沒辦法做到。」徐銘霞說。特別是，要整合行內資料時，玉山技術團隊發現，「我們的資料結構不能夠契合這套框架。」

現成開發框架無法因應業務需求調整，甚至難以串接行內資料，最終也導致，用LangChain開發出來的GenAI應用成效，不如玉山的預期。

另外，由於GenAI技術尚在高速發展，部分現成開發框架迭代速度快，甚至更新版本時，不提供向下相容。對企業而言，這些情況徒增不少維運困擾，不適合長期運用。

再來，當玉山想要整合新、舊元件時，發現「要將既有元件整合至現成框架，並不容易。」玉山銀行智能金融處主任工程師陳建安說。

早在2018年，玉山就開始大力推動AI，發展至今，累積了不少自製的技術元件，包括語音辨識、圖片辨識、搜尋引擎等。這些過往發展的AI技術基礎，雖有利玉山快速發展GenAI，卻也延伸出新的技術挑戰。

評估後發現行不通，玉山技術團隊決定不採用現成框架，而是模擬現成框架的架構，自行打造一個專屬玉山的GenAI開發框架。

從單一應用實作經驗起步，模擬現成框架設計，自建各種元件

玉山的作法是，模仿現成GenAI開發框架的設計架構，自行打造其中的各種元件。玉山用一隻GenAI應用的開發過程來實作，慢慢將這套應用開發模式，發展成一套完整開發框架。

今年中，玉山技術團隊從頭打造出一款人資GenAI助手，開發過程中，玉山技術團隊自行開發了數個技術元件，例如，表格資料萃取、文件檔案萃取、簡報資料萃取等元件。並且，技術團隊也和業務單位合作，根據使用者需求來回調整，「自己可以直接調整內部元件，就不會被框架綁死。」徐銘霞說。

玉山這套自製GenAI框架，未來可以運用在其他場景，例如理專助手等財務知識場景，甚至也能擴展到客服場景。考量到未來這套框架需整合既有技術元件，目前玉山正在進行元件標準化作業，要讓新、舊元件都容易善用。

不僅要打造開發框架，長遠目標是發展業務人員使用的AI開發平臺

雖然，玉山現階段目標是打造GAI開發框架，不過，玉山更長遠的目標是，打造一套「可供業管快速迭代生成式AI應用的框架，」陳建安說：「這個框架不只鎖定開發者，而是要讓業務單位可以提供自己的知識。」例如，未來的框架中可以提供低程式碼或無程式碼平臺，讓業務人員可以動手嘗試開發GAI應用。

比起直接提供封裝完成的GAI應用，玉山更期望的是，業務人員也能靈活取用技術元件，來開發各種應用。

早在過往玉山發展RPA技術時，就用半自動模式，「每一隻RPA程式，都得有人按下按鈕才會執行。」林鉦育解釋，為了做到靠人員監督RPA，玉山過去曾大規模訓練員工學習RPA技術，「讓使用者掌握基礎技術知識，業務人員才有能力思考如何將技術運用在業務場景。」

玉山也將同樣的技術發展策略，套用到Chatbot發展，同樣由業務人員提供相關知識，來完成各項Chatbot應用。「我們想像GAI未來也會朝這個方向發展。」陳建安說。

GENIE不僅是行員助手，還是讓行員能和技術元件溝通的入口

為了讓業務人員可以掌握基礎GAI知識，玉山除了在內部舉辦教育訓練，也期望透過GENIE平臺，讓業務人員先動手嘗試，對技術累積一定程度了解，「至少讓他們認知AI是什麼模樣。」陳建安說。

甚至，玉山對GENIE平臺的想像，不僅是能加速業務流程、解決業務問題的行員OA助手，還是一個能讓業務人員與各種元件溝通的介面，「像是一個入口，背後疊加了許多服務。」陳建安解釋，當業務人員和GENIE平臺互動時，表面上看似在平臺上進行對話，實際卻是運用了平臺背後串接的各式元件，包括玉山自有的影像辨識、語音辨識等技術元件。

今年9月初，玉山更近一步推出了GENIE 2.0平臺，不僅提升平臺背後串接的模型服務，也改善使用者介面設計，讓開發者更靈活收集使用者回饋。更關鍵的升級是，「直接抽換了底層，讓GENIE可以擴充其他元件。」林鉦育解釋，GENIE 2.0和1.0的最大差異，是從固定架構走向可擴充式的架構，「現在可以將第三方API放進平臺。」不只外部業者的API，連玉山既有發展的AI元件，也能用同樣的API形式整合到GENIE平臺。

GENIE 2.0的登場，為玉山GenAI邁向規模化的發展之路，提供了更加強大的基礎。

 玉山GenAI平臺GENIE從1.0走到2.0 

今年上半年，玉山推出GENIE平臺1.0版，有兩大特色：API化服務和檢索增強生成（RAG）技術。一方面，GENIE是一隻獨立的API，可以整合到多種延伸應用服務，內部系統可以透過API串接來使用GENIE的功能。另一方面，玉山自建豐富的金融知識庫，藉RAG技術，來提升LLM模型回應金融領域問題的精準度。不過，1.0版的GENIE無法彈性增加其他元件，都得靠客製開發來整合。

 玉山GenAI平臺GENIE1.0 

到了今年9月，玉山推出GENIE2.0版，不僅改善了使用者介面設計和平臺背後串接的模型服務，更把平臺基礎架構抽換成可擴充的架構，容易整合更多功能元件。

 玉山GenAI平臺GENIE2.0 

甚至，GENIE的定位，也從單一API，成為一個能讓業務人員與各種元件溝通的介面。當業務人員和GENIE互動時，表面上是在平臺上進行對話，實際上運用了平臺背後串接的各式元件。除了既有Chatbot服務，玉山內部前端系統也能直接介接GAI應用服務，讓GenAI在無形中輔助業務人員完成工作任務。圖片來源／玉山金控

 建立標準化評測機制，加速測試LLM模型 

 回應有效性 

玉山的GAI應用主要由業務人員和開發人員共同協作完成。業務人員會先提供業務情境，由開發人員提供初版提示，待業務人員拿到提示後，可以在GENIE平臺上進行測試，並和開發人員討論模型回應結果，雙方合作修改多個提示版本後，協作打造出一款GenAI應用。

不過，在修改提示階段，業務人員需要測試多種情境，並和開發人員來回確認測試情境結果，耗時又耗力。

為了加速業務人員測試各種情境，玉山針對各個業務場景，額外設置測試集，透過LLM來為GAI應用評分，將GAI應用評測機制標準化。

建立評測機制後，省下一半的GAI應用開發時長

在建立標準化測試流程時，玉山技術團隊會根據應用類型，切割出需要測試片段和測試種類，明確定義測試流程。再來，業務單位會負責提供測試資料集，包括真人回應的標準答案，以及標準答案對應分數。接著，技術團隊再運用這套資料集，比對真人回應和模型回應結果，以此建立模型回應評分機制。

目前，玉山的測試集可分為兩類，一類是針對搜尋任務設計的測試集，另一類是針對回應內容設計的測試集。

以人資助手為例，由於人資經常舉辦考試，因此，玉山技術團隊使用LLM模擬參與考試的行員。當業務人員修改提示，可以對照LLM參與考試的作答分數，來評測模型回應優劣。若LLM作答分數高，代表業務人員修改的提示、產出的模型回應內容有效，反之，若LLM考試分數低，則代表業務人員需要再修改模型回應。這是玉山其中一種測式模型回應內容的形式。

另外，針對搜尋任務，玉山金控技術團隊在測試集中設計多種搜尋結果，讓業務人員可以判斷測試情境能否有效讓模型搜尋到正確資料，和正確回答問題。例如，當業務人員輸入特定測試情境，業務人員可以得知，模型在測試情境中能否搜尋到正確答案，以及能否正確回答問題，或是，模型能搜尋到部分答案，但無法完全回答問題。另外，LLM會針對模型回應的正確性進行評分，協助業務人員加速測試各種情境。

玉山尚未建立評測機制前，開發人員需和技術人員反覆確認不同測試情境結果，單一應用歷經半年開發時長，才正式上線。建立評測機制後，則節省近一半開發時間，以玉山近期上線的小型事業徵信小幫手為例，僅花三個月，就從實驗走到正式上線。

 相關報導