https://yennj12.js.org/yennj12_blog_V4/tags/model-governance/Recent content in Model Governance on YennJ12 Engineering BlogHugo -- gohugo.ioen-usFri, 24 Jul 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-system-on-native-aws-part7-foundation-model-customization-governance-zh/Fri, 24 Jul 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-system-on-native-aws-part7-foundation-model-customization-governance-zh/大部分人聽到「模型不夠好」的第一反應是 fine-tune。於是花了三週標資料、燒了一筆 GPU 錢、訓出一個模型——然後發現它在你沒測到的地方變笨了,而且沒人記得訓練資料是哪來的、當初為什麼這樣調。 企業客製模型的真正難點,從來不是「怎麼訓」,而是「怎麼治理」:什麼情況才該 fine-tune(多數時候你其實該用 RAG)、訓練資料的來源與授權可追溯嗎、模型上線前過了哪些評估關卡、誰簽核的、出事能不能回滾到上一版。 沒有治理的 fine-tune,是把一個黑箱換成一個更貴、更難解釋的黑箱。 這是 Part 7:當你決定動模型本身時,如何讓每一步都可稽核、可評估、可回溯。 一、情境與痛點:先問「該不該客製」,再問「怎麼客製」 先講一個殘酷的事實:大多數「模型不夠好」的問題,不該用 fine-tune 解。 企業常見的三種「不夠好」,對應三種不同的解法: 症狀 根因 正解 ────────────────────────────────────────────────────────────────────── 答不出公司內部知識 模型沒看過你的資料 RAG(Part 1/6),不是 fine-tune 不遵守特定格式/語氣/流程 行為沒對齊 Prompt 工程 → 不夠再 fine-tune 懂領域但術語/風格不對(醫療/法律/金融) 領域分佈偏移 Fine-tune / 領域續訓 要把大模型能力壓進便宜小模型 成本/延遲 蒸餾(Distillation) 用 fine-tune 解「知識缺失」是最常見的錯誤:你以為把公司文件拿去訓練模型就會記住,實際上它只學到「風格」,知識還是會忘、會幻覺,而且文件一更新你就得重訓。知識問題永遠先用 RAG。 真正該 fine-tune 的場景很窄但很真實:當你要的是「行為/風格/領域分佈」的改變,而且 prompt 怎麼調都到不了——例如讓模型穩定輸出特定 JSON schema、用醫療術語但保持謹慎語氣、模仿公司特有的客服話術。這時 fine-tune 才有意義。 而一旦你決定動模型,企業的重心立刻從「技術」轉向「治理」:這是 Part 7 的核心。 二、系統目的:功能與非功能需求 功能需求: 一個決策框架:輸入問題類型,輸出該用 RAG / Prompt / Fine-tune / 蒸餾。 資料準備管線:蒐集、清洗、去識別化、格式化訓練資料,並記錄來源(lineage)。 訓練:支援 Bedrock 客製模型(託管 fine-tune)與 SageMaker 自訂訓練。 模型註冊:每個模型版本進 Model Registry,附評估結果與 Model Card。 評估關卡:自動評估(準確、安全、偏見)通過才能進入審批。 審批工作流:人工簽核後才部署,可一鍵回滾。 非功能需求: