https://yennj12.js.org/yennj12_blog_V4/tags/safety/Recent content in Safety on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 22 Jun 2026 04:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase15-part2-self-improvement-safety-zh/Mon, 22 Jun 2026 01:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase15-part2-self-improvement-safety-zh/大多數工程師把安全當成事後的 checklist。 真正的 AI 工程師在架構第一行就把安全嵌入設計核心。 自我改進讓模型更強大；安全技術棧讓這份強大不會反噬使用者。 兩者缺一，你只是在玩一把沒有安全裝置的槍。 面試情境 你的公司正在部署一個能夠自主執行程式碼、搜尋網路、並呼叫內部 API 的 AI Agent。產品 VP 問你：「如果這個 Agent 被攻擊者注入惡意指令，最壞的情況是什麼？你會怎麼在不犧牲能力的前提下設計防禦架構？」 一、核心問題：自我改進的工程機會與安全風險 1.1 為什麼自我改進讓工程師又期待又害怕 2025 年末到 2026 年，生產環境中的 AI Agent 已從「問答機器」進化為「能夠修改自身行為的系統」。Self-Refinement 讓模型在推論時迭代改寫輸出；Constitutional AI 讓模型以原則自我審查；RLVR（Reinforcement Learning from Verifiable Rewards）讓模型從可驗證的結果信號中自我強化。 這三項技術加在一起，意味著一件事：模型的行為邊界不再是靜態的。這對工程師是機會，也是惡夢。 機會在於：每次推論都是一次微小的「學習」，系統越用越精準。 惡夢在於：如果攻擊者能夠注入惡意目標函數，系統會自我強化朝錯誤方向走，而且速度比你想像的快。 1.2 2026 年三大安全威脅面 威脅類型 典型攻擊向量 最壞後果 2026 發生率 提示注入（Prompt Injection） 惡意使用者輸入覆蓋系統提示 資料外洩、未授權操作 生產事故中佔 34% 越獄（Jailbreak） 繞過安全訓練的對話技巧 有害內容生成 OWASP LLM Top 10 第一位 行動劫持（Action Hijacking） 透過 RAG 文件注入惡意工具呼叫 刪除資料、外部 API 濫用 2026 Q1 新興威脅 這篇文章的核心主張：自我改進機制與安全防禦必須共設計（co-designed），不能分開考慮。https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part36-eval-pipeline-zh/Fri, 05 Jun 2026 14:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part36-eval-pipeline-zh/Eval Pipeline 和 Eval 的差別： Eval 是你跑一次、拿到一個分數。 Eval Pipeline 是每次系統改變，自動跑、自動比較、自動擋住退化。 法律合約系統漏掉一個風險條款的損失可能是千萬。 靠人記得去跑評估，不夠。 面試情境 面試官：「客戶是一家法律事務所，剛上線了一個合約審查 AI 系統。他們問：每次你們更新 Prompt 或換模型版本，我怎麼知道品質沒有退化？法務長說，如果 AI 漏掉一個風險條款，損失可能是千萬。請設計一個讓客戶可以信任的 Eval Pipeline。」 一、核心問題：為什麼需要 Pipeline Eval（一次性）的問題： 現在的品質：Faithfulness = 0.87 ← 你知道 下週改了 Prompt 之後：? ← 你不知道 三個月後換了模型版本之後：? ← 你更不知道 沒有 Pipeline： 需要有人記得每次改動後去跑評估 → 沒人記得 → 品質退化不被發現 → 客戶先發現 有 Pipeline： 每次 Prompt / 模型 / 資料 變更 → 自動觸發評估 → 分數低於閾值 → 自動擋住部署 → 品質退化在影響用戶之前被系統發現 Eval Pipeline 是把「品質管控」從人工流程變成自動化系統。 這是 POC 到生產的核心差距之一。 二、Eval Pipeline 的四層架構 ┌───────────────────────────────────────────────────────────────────┐ │ Layer 1：黃金資料集（Ground Truth） │ │ 「正確答案是什麼」的標準，由領域專家建立 │ └──────────────────────────────┬────────────────────────────────────┘ │ 每次評估都用同一份資料集 ▼ ┌───────────────────────────────────────────────────────────────────┐ │ Layer 2：離線評估（Offline Eval） │ │ 每次部署前，對黃金資料集跑 RAGAS + Safety，產出指標報告 │ └──────────────────────────────┬────────────────────────────────────┘ │ 評估結果 vs 上一版 baseline ▼ ┌───────────────────────────────────────────────────────────────────┐ │ Layer 3：CI/CD 品質閘門（Quality Gate） │ │ 分數低於閾值 → 自動阻止部署；通過 → 繼續 Canary 部署 │ └──────────────────────────────┬────────────────────────────────────┘ │ 部署到生產後持續監控 ▼ ┌───────────────────────────────────────────────────────────────────┐ │ Layer 4：線上評估（Online Eval） │ │ 生產流量的持續品質監控，偵測 Data Drift 和 Performance Drift │ └───────────────────────────────────────────────────────────────────┘ 三、Layer 1：黃金資料集的設計原則 黃金資料集的每一筆記錄： { "id": "Q042", "query": "這份合約的違約金條款是否符合台灣民法第 250 條？", "context": ["第 3 頁段落.https://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 前一階段： 從零開始，建立基線。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase18-part2-governance-zh/Mon, 22 Jun 2026 04:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase18-part2-governance-zh/大多數工程師把 AI 治理當成法務部門的事，等監管機關發函才開始補文件； 正確答案是：治理是系統設計的一等公民，在模型進 production 的第一天就必須量測公平性、記錄資料來源、控制隱私洩露量。 不做治理不是「省力」，是把合規風險、偏見訴訟、資料外洩的成本推遲到最貴的時間點——上線之後。 工程師不需要成為法律專家，但必須懂得把監管義務翻譯成系統元件和可量測的指標。 面試情境 你的團隊正要在 EU 市場推出一個信用評分 AI 系統，PM 說「先上線再合規」，CTO 問你：從工程架構角度，最低限度需要做哪些治理元件才能在 EU AI Act 生效後合法營運？如果資料集中有性別和種族代理變數，你打算怎麼處理偏見？隱私工程用什麼機制確保 GDPR 合規？ 一、核心問題：AI 治理為什麼是工程師的問題 AI 治理在過去五年從「道德宣示」進化為「法律義務」。EU AI Act 在 2024 年正式生效，預計 2026 年高風險系統進入強制合規期；NIST AI RMF 已成為美國聯邦採購的事實標準；中國、英國、加拿大相繼推出對等框架。 工程師為什麼不能把這件事推給法務？ 合規義務落在系統層：EU AI Act Article 9 要求「risk management system」必須以技術文件佐證，不是 policy PDF，是可追溯的程式碼和日誌 偏見來自資料 pipeline：統計公平性的破壞點在特徵工程、訓練集採樣、評估集分割——法務無法在那裡插手 隱私洩露是技術問題：差分隱私的 epsilon 預算、聯邦學習的梯度聚合——這些是數學和工程，不是合約條款 稽核需要系統支撐：監管機關要看 model card、訓練資料來源、版本歷史、A/B 決策記錄——這些必須在 CI/CD 裡自動生成 信用評分這個域的具體風險： EU AI Act 分類：高風險（Annex III, 5b — access to essential private services） GDPR Article 22：禁止純自動化決策影響個人法律地位，除非有明確告知和申訴機制 美國 FCRA/ECOA：對抵押貸款、信用卡的公平貸款義務，違規罰款可達 $1M/天 偏見訴訟：2021 年美國有 12 件 AI 信用歧視集體訴訟，和解金從 $2M 到 $98M 二、三個演進階段（POC → MVP → Scale） ╔══ Phase 1：POC / < 5K 用戶 ══╗ 目標：最低限度治理，讓系統能合法上線做受控測試