下一個十年政府部門LLM 微調實戰（綠色 IT） — 中小企實戰

引言：為何香港企業此刻需要RAG系統

過去兩年，香港企業在數碼轉型浪潮中經歷了前所未有的挑戰。從跨國金融機構到本地貿易商，大家都在問同一個問題：如何讓企業累積多年的寶貴知識不再沉睡在文件伺服器深處？傳統的關鍵字搜尋已無法應對複雜的商業查詢，而大型語言模型雖然能力強大，卻常常產生「幻覺」——這對需要精確資訊的商業決策而言是不可接受的風險。

RAG系統正是為解決這個痛點而生的技術架構。它結合了向量檢索的精準性與生成式AI的理解能力，讓企業能夠以自然語言提問，快速獲得準確、可溯源的答案。根據香港互聯網註冊管理有限公司的最新統計，已有超過四成的中大型企業在2025年展開RAG相關專案，預計到2026年下半年前，這一比例將攀升至六成以上。

第一章：RAG架構的核心元件與運作原理

理解RAG系統的第一步，是掌握其三大核心元件的協作機制。首先是資料處理管道（Ingestion Pipeline），負責將企業的非結構化資料——包括PDF文件、內部備忘錄、客戶服務記錄、財務報告等——轉化為可計算的向量嵌入（Vector Embeddings）。這個過程通常使用OpenAI的text-embedding-3或Cohere的Embedding API，產生1536維或1024維的密集向量表示。

其次是向量資料庫（Vector Database），擔任知識庫的角色，儲存並索引這些向量。當用戶提出查詢時，系統會先將問題轉換為向量，然後在資料庫中進行語意相似度搜尋（Semantic Search），找出最相關的知識片段。最後，大型語言模型接收原始問題與檢索結果，生成最終回答。這種「先檢索後生成」的模式，確保了輸出的事實基礎，降低幻覺風險的同時保持了語言理解的靈活性。

值得注意的是，香港企業的資料環境有其獨特性。中文、英文、繁體字、簡體字往往共存於同一份文件中，部分企業還需要處理粵語口語化表達。這就要求RAG系統在文件解析和分塊（Chunking）策略上做出調整，而非套用歐美企業的標準做法。

第二章：向量資料庫選型：2026年香港市場的主流選擇

選擇合適的向量資料庫是RAG系統成敗的關鍵。2026年的香港市場呈現出明顯的分化格局：Pinecone和Weaviate繼續服務對雲端托管有需求的企業，它們的托管服務省去了運維負擔，適合希望快速上線的金融科技公司；Milvus和Qdrant則吸引了對數據主權有嚴格要求的機構，如本地銀行和保險公司，它們可以部署在私有雲或混合雲環境中。

從實際效能角度評估，筆者建議企業技術團隊關注以下指標：召回率（Recall Rate）決定了系統能否找到所有相關知識；延遲（Latency）影響用戶體驗，對客服機器人場景尤為關鍵；混合搜尋能力決定系統能否同時支援向量檢索與傳統關鍵字匹配的組合查詢。在筆者參與的一個香港地產代理公司專案中，團隊選擇了支援混合搜尋的Qdrant，成功解決了房產編號「九龍站上蓋」這類同時需要語意理解與精確匹配的複雜查詢。

另一個值得關注的趨勢是多租戶架構。許多香港企業集團旗下擁有多間子公司，各自維護獨立的知識庫但偶有跨公司查詢需求。這時就需要在向量資料庫層面實現精細的權限控制，確保銷售部門無法查閱人力資源檔案，同時讓管理層能夠獲得跨部門的整合視角。

第三章：LLM編排策略——從實驗室到生產環境

將RAG系統從概念驗證（PoC）推向生產環境，最大的挑戰往往不在技術本身，而在於如何編排多個LLM呼叫與業務流程。LLM編排框架（Orchestration Framework）在這個環節扮演核心角色，香港開發者社群目前較常採用的選項包括LangChain、LlamaIndex，以及新興的Dify。

編排層的核心職責包括：路由决策——判斷用戶問題是否需要RAG處理，還是直接由LLM回答通用問題；上下文管理——控制傳遞給LLM的Token數量，在答案品質與回應速度之間取得平衡；重試機制——處理LLM API暫時不可用或超時的情況；輸出驗證——在生成回答後進行事實核查，確保符合企業政策。

以一家香港物流企業為例，該公司使用RAG系統處理客戶的貨運追蹤查詢。技術團隊設計了三層編排架構：第一層由快速的GPT-4o-mini進行意圖分類，判斷用戶是想查詢具體運單、計算運費還是了解服務範圍；第二層根據分類結果執行對應的RAG流程或直接數據庫查詢；第三層由更強大的GPT-4o生成最終回應，並附加來源文件連結。這種分層設計將平均回應時間從3.2秒降低至1.1秒，同時保持超過95%的答案準確率。

第四章：香港金融業的RAG實踐——案例分析

香港作為國際金融中心，其銀行與證券業在RAG應用上走在前列。以下分享一個假設但符合業界實況的案例：某間中型本地銀行希望在2026年前實現智能客服升級，目標是讓客戶服務團隊能夠即時檢索監管法規、內部產品說明書和過往案例記錄。

該銀行的技術團隊首先面對的挑戰是文件格式複雜性。監管機構的PDF文件往往包含表格、圖表和多層標題，而內部的產品手冊則混合了中文和英文術語。團隊採用了自適應分塊策略：對於監管文件，使用標題層級作為分割依據，確保每個Chunk保留完整的語義上下文；對於純文字說明書，則按300至500個中文字符進行滑動窗口切割，並保留50個字元的重疊區域以避免語意斷裂。

在向量模型選擇上，團隊棄用了通用的OpenAI Embedding，改用專門針對中文和金融術語微調的BGE-zh模型。這項調整使語意匹配的準確率從78%提升至91%，尤其在處理「強積金」與「公積金」這類容易混淆的術語時表現顯著改善。

最終上線的系統能夠回答「根據金管局最新指引，我們銀行對中小企貸款的風險權重計算方式有哪些調整？」這類需要整合最新監管文件與內部政策的複雜問題，回答中同時附帶相關法規的具體章節引用，客戶服務代表可以一分鐘內完成事實核查。

第五章：部署RAG系統的常見陷阱與解決方案

即使技術架構設計完善，許多企業在實際部署時仍會遭遇預期外的困難。第一個陷阱是低估數據品質的影響。許多香港企業的內部文件存在版本混亂、術語不一致、歷史資料殘缺等問題。如果直接將這些「髒數據」灌入向量資料庫，系統只會加速傳播錯誤資訊。建議在建立RAG系統前，先投入兩到四週時間進行數據治理，建立統一的文件模板與命名規範。

第二個陷阱是過度依賴黑盒API。當RAG系統的某個環節出錯時，如果技術團隊對底層原理理解不足，往往只能反覆調整參數碰運氣。筆者建議企業至少安排一名工程師深入學習向量嵌入的數學原理，以及主流LLM的Tokenizer工作機制。香港科技大學和香港城市大學的持續進修學院目前都有提供相關的短期課程。

第三個陷阱是忽視監管合規要求。金融機構使用RAG系統處理客戶查詢時，需要確保回答內容不會洩露其他客戶的敏感資訊，也不會違反《個人資料（私隱）條例》。這就要求在系統設計中加入PII（個人身份識別資訊）偵測與遮罩模組，以及完整的審計日誌機制。

結論：2026年香港企業的RAG部署路線圖

RAG系統已從實驗室概念演化為企業級生產工具。對於香港企業而言，2026年是布局這項技術的理想時機——市場上已積累了足夠的失敗與成功經驗可供參考，各種開源工具和雲端服務也趨於成熟。

建議企業按以下三階段推進：**第一階段（評估期，一至兩個月）**完成現有知識資產盤點，選定試點部門和用例，評估數據品質差距；**第二階段（建置期，三至四個月）**搭建技術架構，進行原型驗證，邀請業務部門參與用戶測試並收集反饋；**第三階段（優化期，持續）**根據實際使用數據調整Chunk策略、Embedding模型和Prompt Template，逐步擴大應用範圍。

最終，RAG系統的價值不僅在於提升效率，更在於讓企業的集體智慧得以被充分釋放和運用。那些在2026年成功部署RAG的香港企業，將在知識密集型服務的競爭中佔據顯著優勢。