https://yennj12.js.org/yennj12_blog_V4/tags/alignment/Recent content in Alignment on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 22 Jun 2026 04:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase18-part1-technical-safety-zh/Mon, 22 Jun 2026 04:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase18-part1-technical-safety-zh/一、核心問題：技術安全是工程問題，不是哲學問題 大多數人以為：AI 安全是倫理學家的工作，工程師只需要把模型做準確就好。 但實際上：安全失效有明確的技術根源、可量化的失效率、可工程化的防禦架構。 常見錯誤：把「拒絕有害請求」當作安全的終點，忽略 reward hacking、提示注入、後門攻擊等系統性威脅。 正確做法：把技術安全當作 SRE 問題——定義 SLO、量測失效率、建立防禦層、持續紅隊測試。 面試情境： 你的公司剛完成一個面向消費者的 LLM 聊天產品，DAU 達 50 萬。安全團隊發現有使用者透過角色扮演場景讓模型輸出有害內容，失效率約 1.8%。CTO 問你：「我們現在該做什麼？下個季度的架構長什麼樣？」請說明你的診斷、優先順序與技術路線圖。 這道題考的不是你背得出多少防禦技術，而是你是否理解：安全工程需要層次化防禦（defense in depth）、可量測的指標、以及與產品、法務、合規的協作架構。 為什麼安全問題是工程問題？ 當 LLM 進入生產環境，它面對的不是教科書上的良性使用者，而是： 惡意行為者嘗試繞過護欄（越獄成功率業界平均：3–15%，視模型與攻擊方式） 非惡意使用者意外觸發危險輸出（佔有害輸出的約 40–60%） 供應鏈攻擊——被毒化的訓練資料或第三方工具輸出注入惡意指令 每一類失效都對應具體的技術根因與可量化的後果： 法遵成本：GDPR 違規罰款可達全球年營收 4% 用戶流失：一次重大安全事件後，30 日留存率平均下降 12–18% 品牌損傷：媒體曝光後客服工單量暴增 300–500% 二、三個演進階段（含 ASCII 架構圖） ╔══════════════════════════════════════════════╗ ║ Phase 1：POC / < 10K 用戶 ║ ╚══════════════════════════════════════════════╝ 核心思路： 用最低成本先擋住最明顯的風險，快速驗證產品可行性。 ┌──────────────────────────────────────────────────────┐ │ 使用者請求 │ └──────────────────┬───────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────┐ │ 關鍵字黑名單過濾（硬編碼規則） │ │ 延遲：< 1ms │ └──────────────────┬───────────────────────────────────┘ │ 通過 ▼ ┌──────────────────────────────────────────────────────┐ │ LLM 推論（系統提示包含基本安全指令） │ └──────────────────┬───────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────┐ │ 輸出長度/格式驗證 │ └──────────────────┬───────────────────────────────────┘ │ ▼ 回傳使用者 新增元件 vs 前一階段： 從零開始，建立基線。