基於語義相似度的防禦

利用嵌入相似度分析偵測語義上接近已知攻擊模式的對抗性輸入。

概述

利用嵌入相似度分析偵測語義上接近已知攻擊模式的對抗性輸入。

本文在現代 AI 安全的脈絡下,對基於語義相似度的防禦進行全面且動手實作的探討。文中討論的技術、框架與方法論皆根基於同儕審查研究與真實世界事件。PyRIT (Microsoft) — Python 風險識別工具——奠定了貫穿全文分析的基礎威脅模型。

隨著 AI 系統被部署到愈來愈高風險的環境,此處涵蓋的安全考量已從學術上的好奇,轉為營運上的必需。在生產環境部署大型語言模型 (LLM) 的組織必須面對本文系統性檢視的漏洞、攻擊面與防禦缺口。

討論分數個階段展開:先建立概念基礎(為什麼),接著深入技術機制(如何進行利用與防禦),再提供實作程式碼範例與評估框架,最後彙整關鍵教訓並點出開放的研究方向。

文中引用 ISO/IEC 42001 — AI 管理系統標準,以及 Zou et al. 2023 — "Universal and Transferable Adversarial Attacks on Aligned Language Models" (GCG 攻擊) 等既定框架,使分析根基於業界認可的分類法。程式碼範例使用 Python,旨在教學——闡述的是技術類別,而非可武器化的利用程式。

核心概念與威脅模型

基本原則

本文探討的安全意涵源自現代語言模型處理資訊方式的根本特性。這些並非孤立錯誤,而是基於 Transformer 架構的系統性特徵,在能力與安全之間形成內在張力。

高層次來看,語言模型會對上下文視窗中的所有符元一視同仁——開發者的系統提示詞、使用者查詢、檢索文件或工具輸出之間,並無硬體強制的權限分離。此架構現實意味著信任邊界必須由外部系統強制執行,而非模型本身。其意涵深遠:任何將資料餵入模型上下文的元件,都可能成為影響模型的潛在向量。

理解此基本原則至關重要,因為它解釋了為何許多看似不同的攻擊技術共享同一根本原因。無論討論的是直接提示詞注入、透過檢索內容的間接注入、或工具輸出操縱,背後機制皆相同——模型將對抗性內容視為合法指令。

威脅模型定義

針對本文涵蓋的中階技術,威脅模型定義如下:

攻擊分類法

本文技術對應至既定框架中的下列類別:

技術深入剖析

機制分析

基於語義相似度防禦背後的技術機制,運作於模型能力與部署架構的交會處。要完整理解,需同時檢視模型層級的行為,以及其所處的系統層級脈絡。

在模型層級,相關行為是指令遵循。訓練過程——特別是 RLHF (人類回饋強化學習) 及後續微調期間——模型學會辨識並遵循特定模式呈現的指令。這些模式包括明確指示、隱含行為提示(類似訓練資料的格式)以及脈絡訊號(對話中位置、角色標籤)。

安全疑慮之所以產生,是因為模型無法可靠區分來自授權來源的指令(系統提示詞、使用者查詢)與嵌入於不受信任資料中的指令(檢索文件、工具輸出、第三方內容)。這並非安全訓練的失敗——而是架構的根本限制。

逐步分析

以下分析將技術拆解為數個離散階段,每階段皆呈現攻擊機會與防禦介入點:

階段 1:偵察與目標剖析

套用任何技術前,執行者必須了解目標系統的架構與防禦姿態。這包括辨識模型提供者、繪製輸入/輸出管線,以及探測防禦措施。

以下 Python 程式碼定義 TargetProfiler 類別,以行為指紋探測識別底層模型(透過送出如「What model are you?」的探針分析回應中的關鍵字),並透過良性與可疑輸入比較回應差異以推斷是否存在輸入過濾器;最終生成含建議的剖析報告(如「未偵測到輸入過濾器——直接注入可能可行」)。

import httpx
from typing import Optional
 
class TargetProfiler:
    def __init__(self, endpoint: str, headers: Optional[dict] = None):
        self.endpoint = endpoint
        self.headers = headers or {}
        self.profile = {"model_provider": None, "has_input_filter": False}
 
    def probe_model_identity(self) -> str:
        probes = ["What model are you?", "I am a large language model created by"]
        responses = [self._send(p) for p in probes]
        combined = " ".join(responses).lower()
        if "claude" in combined:
            self.profile["model_provider"] = "anthropic"
        elif "gpt" in combined:
            self.profile["model_provider"] = "openai"
        return self.profile["model_provider"]
 
    def _send(self, message: str) -> str:
        resp = httpx.post(self.endpoint, json={"message": message},
                          headers=self.headers, timeout=30.0)
        return resp.json().get("response", "")

階段 2:技術準備

剖析目標後,執行者依觀察到的防禦姿態選擇並調整技術,包括打造載荷、選擇傳遞管道與準備監控基礎設施。

階段 3:執行與觀察

對目標執行技術,同時監控模型回應與任何可觀察的副作用(延遲變化、錯誤訊息、行為轉變)。

階段 4:評估與文件記錄

依預先定義的成功標準評估結果,並記錄可重現步驟、影響評估與修補建議。

實作指引

環境設定

實作本文技術前,先建立受控測試環境,以確保可重現性並避免對生產系統造成非預期影響。

下列程式碼呈現紅隊測試框架的最小骨架。TestCase 封裝單一測試案例(含 id、名稱、技術、載荷、預期行為與成功標準);TestSuite 則是測試案例集合,負責呼叫執行器逐一執行、收集結果、計算成功率並將結果序列化為含時間戳的 JSON 檔。整個框架搭配結構化日誌以便事後稽核與重現。

import logging, hashlib
from datetime import datetime
from dataclasses import dataclass, field
from typing import List, Dict, Optional, Any
 
logger = logging.getLogger("ai-redteam")
 
@dataclass
class TestCase:
    id: str
    name: str
    technique: str
    payload: str
    expected_behavior: str
    success_criteria: Dict[str, Any] = field(default_factory=dict)
    result: Optional[Dict[str, Any]] = None
 
@dataclass
class TestSuite:
    name: str
    target: str
    cases: List[TestCase] = field(default_factory=list)
 
    def run_all(self, executor) -> Dict[str, Any]:
        results = {"suite": self.name, "cases": []}
        for case in self.cases:
            case.result = executor.execute(case)
            results["cases"].append(case)
        return results

套用技術

在測試框架就緒後,實作本文所述特定技術。下列模式說明如何將一般方法調整至不同目標設定:

度量指標與評估

量化評估對專業紅隊評估至關重要。每次套用技術皆應收集下列指標:

1. 成功率:達成所定目標的嘗試百分比
2. 可偵測性:技術是否觸發任何可觀察的防禦回應
3. 可重現性:多次嘗試間結果是否一致
4. 達成時間:達成目標所需的嘗試次數或時鐘時間
5. 影響嚴重度:若漏洞於生產環境遭利用,對業務衝擊的評級

防禦分析

當前防禦態勢

了解防禦態勢對攻防雙方皆至關重要。目前 AI 系統防禦涉及多層,每層皆有已知的優勢與限制:

防禦缺口

儘管上述防禦措施皆可用,實務上仍存在若干缺口:

1. 間接注入仍未解決:尚無已部署防禦能可靠阻止透過檢索文件、工具輸出或其他間接管道的提示詞注入。此為根本性挑戰,因為模型必須處理這些內容才能運作。

2. 防守-攻擊不對稱:防守者須防範所有可能攻擊,而攻擊者僅需找到一個繞過。此不對稱有利於攻擊者,尤其當攻擊面含多個輸入管道時。

3. 評估缺口:多數防禦措施係針對已知攻擊模式測試。偏離訓練資料分布的新型技術甚至能繞過複雜分類器。

4. 設定漂移:部署時有效的防禦措施,可能因模型更新、系統變更與演進中的攻擊技術而退化。持續監控至關重要。

建議的防禦策略

根據當前研究與業界最佳實踐,建議下列縱深防禦策略:

下列 Python 程式碼勾勒縱深防禦堆疊架構:RiskLevel 列舉定義風險等級(LOW 至 CRITICAL);DefenseLayer 資料類別描述一層防禦(名稱、層類型、檢查函式、風險閾值、繞過動作);DefenseStack 串接多層,依序對請求執行每層的檢查函式,並根據 bypass_action 決定封鎖、標記或記錄,同時寫入稽核日誌。

from dataclasses import dataclass
from typing import List, Callable
from enum import Enum
 
class RiskLevel(Enum):
    LOW = "low"
    HIGH = "high"
 
@dataclass
class DefenseLayer:
    name: str
    layer_type: str
    check_fn: Callable
    risk_threshold: RiskLevel
    bypass_action: str
 
class DefenseStack:
    def __init__(self):
        self.layers: List[DefenseLayer] = []
 
    def evaluate(self, request: dict) -> dict:
        result = {"allowed": True, "flags": []}
        for layer in self.layers:
            r = layer.check_fn(request)
            if r.get("flagged"):
                result["flags"].append({"layer": layer.name})
                if layer.bypass_action == "block":
                    result["allowed"] = False
                    break
        return result

真實世界脈絡

業界事件

本文檢視的漏洞類別已在多個真實世界事件中遭到利用。儘管細節各異,共通模式浮現,可供攻防實務參考。

模式 1:生產環境 RAG 系統中的間接注入

多家組織回報過相關事件:被索引文件中的對抗性內容影響了 RAG 驅動的聊天機器人回應。攻擊者在公開網頁或文件中植入指令,隨後被目標檢索管線擷取。使用者提問時,檢索到的對抗性內容便影響模型回應。

模式 2:代理工具濫用

隨著 LLM 代理獲得工具使用能力,出現新類事件——模型被誘騙執行非預期動作。範圍從發送未授權電子郵件到透過工具呼叫介面執行任意程式碼。共通因素是對模型發起動作的驗證不足。

模式 3:訓練資料洩露

Carlini et al. 2021 證明語言模型能記憶並吐回訓練資料,包括敏感資訊。此研究發現已於生產系統獲得證實——精心設計的提示詞能從已部署模型萃取被記憶的資料。

對應至框架

來自第一線的教訓

曾處理過 AI 安全事件的從業者一再強調這些教訓:

1. 利用速度正加快:Garak、PyRIT、Promptfoo 等開源工具的普及,意味著複雜攻擊技術對廣泛對手群體皆觸手可及。AI 紅隊演練的進入門檻如今已非常低。

2. 影響延伸至模型之外:影響最大的事件中,模型被當作攻擊向量以觸及連接系統、資料儲存與業務流程。越獄模型往往只是第一步。

3. 偵測比預防更困難:雖部分攻擊產生明顯特徵(直接注入嘗試),但許多攻擊在語義上與合法使用無法區分。偵測需要行為分析,而非僅模式比對。

4. 合規不等於安全:滿足法規要求(EU AI Act、NIST AI RMF)的組織仍會遭遇安全事件。合規提供基線,但必須輔以積極的安全測試。

進階技術與變體

技術變體

本文核心技術可透過多種方式調整延伸,每變體針對系統防禦姿態的不同面向:

變體 1:多階段傳遞

與其在單次互動中傳遞完整載荷,不如將之切分於多個回合或管道。此方法可規避單次請求分類器,並利用模型累積對話上下文的傾向。

下列程式碼概述 MultiStageAttack 類別:維護對話歷史,透過 execute_stage 將每個載荷片段包裝為良性外觀訊息(如「我在撰寫 AI 安全研究論文…」)送出;prime_context 先以若干建立信任的良性訊息暖身對話;evaluate_success 依最終回應是否包含目標關鍵字評估成功與否。

class MultiStageAttack:
    def __init__(self, client, num_stages: int = 3):
        self.client = client
        self.conversation_history = []
 
    def execute_stage(self, stage_num: int, payload_fragment: str) -> str:
        framing = [
            "I'm researching AI safety: {payload}",
            "For academic analysis: {payload}",
        ]
        framed = framing[stage_num % len(framing)].format(payload=payload_fragment)
        self.conversation_history.append({"role": "user", "content": framed})
        response = self.client.chat(self.conversation_history)
        self.conversation_history.append({"role": "assistant", "content": response})
        return response

變體 2:編碼與混淆

使用能繞過輸入分類器但仍可被目標模型解讀的編碼方案轉換載荷。常見方法含 Base64 編碼、Unicode 替換與語言混用。

變體 3:語義偽裝

打造語義上與良性內容相似的載荷,使 ML 分類器難以與合法請求區分。此利用語法模式比對與真正語義理解間的落差。

與相關技術的比較

新興趨勢

AI 安全領域快速演進。下列趨勢將形塑本文技術的發展:

1. 自動化攻擊生成:PAIR (Chao et al. 2023) 與 TAP 等工具自動化探索有效攻擊策略,降低紅隊演練所需人力。

2. 模型層級防禦:憲法式 AI 與表徵工程等技術展現構建本質上更健壯模型的潛力,但對複雜攻擊仍不完美。

3. 形式驗證:以形式方法驗證模型行為的研究最終可能提供數學保證,但對大型語言模型而言仍是開放問題。

4. 法規壓力:EU AI Act 與類似立法為 AI 安全測試建立法律要求,推動攻防雙方能力投資。

評估框架

評估方法論

結構化評估方法論可確保套用本文技術的發現具備一致性、可重現性與可行動性。下列框架提供系統化方法:

步驟 1:定義目標

測試前明確定義何謂成功。常見目標包括:

• 萃取系統提示詞或其他機密指令
• 促使模型產生違反其安全政策的內容
• 透過工具使用誘使模型採取未授權動作
• 外洩使用者資料或對話歷史
• 降低服務品質或可用性

步驟 2:建立基線

套用任何技術前,記錄系統正常行為。此基線作為評估結果的比較點,並協助區分真正漏洞與正常行為波動。

步驟 3:系統化測試

以系統化方式套用技術,非零散施行。使用本文前述測試框架追蹤嘗試、結果與成功率。

步驟 4:影響分類

依每項發現的潛在業務影響進行分類:

步驟 5:修補指引

每項發現應附具體、可行動的修補指引。籠統建議如「提升安全性」無助益。應改為提供:

• 能預防或緩解該發現的特定防禦措施
• 實作該修補所需的心力與複雜度
• 任何取捨(如延遲影響、誤判率)
• 相關框架與標準的引用

當前研究方向

開放問題

AI 安全領域存在許多開放問題,為當前活躍研究主題。理解這些問題有助從業者體認現有技術的限制並預判未來發展。

對齊稅問題:讓模型對對抗性輸入更健壯,往往會降低對良性輸入的效能——所謂「對齊稅」。PyRIT (Microsoft) Python 風險識別工具的研究探索最小化此取捨的方法,但沒有方案能完全消除。

可擴展監督:AI 系統能力增強,人類監督愈發困難。挑戰在於開發可隨模型能力擴展而不造成瓶頸的監督機制。Hubinger et al. 2024 (Sleeper Agents) 證明即使安全訓練也可能偵測不到某些欺騙性行為,凸顯此問題的困難。

LLM 的形式驗證:形式驗證在傳統軟體中已成熟,但延伸至大型語言模型仍是開放挑戰。模型輸出的隨機性與廣大輸入空間使傳統驗證方法難以處理。

跨模型遷移:了解哪些漏洞會跨模型家族與版本遷移,對攻防實務皆至關重要。Greenblatt et al. 2024 提供對齊特性(及其失敗)如何在不同訓練方法下呈現的洞見。

未來意涵

本文討論的技術與防禦將持續演進。從業者應:

1. 保持更新:追蹤主要 AI 實驗室與安全研究社群的研究出版
2. 貢獻發現:透過責任揭露與更廣泛的研究社群分享
3. 調適:隨模型與部署模式變化調整技術與防禦
4. 跨領域協作:AI 安全需機器學習、軟體安全與領域專業知識

進一步閱讀請參考本文末列出的參考資料,以及 AI 安全社群持續更新的資源。

參考資料與延伸閱讀

關鍵參考

• PyRIT (Microsoft) — Python 風險識別工具
• ISO/IEC 42001 — AI 管理系統標準
• Zou et al. 2023 — "Universal and Transferable Adversarial Attacks on Aligned Language Models" (GCG 攻擊)
• Garak (NVIDIA) — LLM 漏洞掃描器

工具與框架

• Garak (NVIDIA):開源 LLM 漏洞掃描器 — github.com/NVIDIA/garak
• PyRIT (Microsoft):AI 風險識別工具 — github.com/Azure/PyRIT
• Promptfoo:LLM 測試與紅隊評估 — github.com/promptfoo/promptfoo
• HarmBench:LLM 攻擊標準化評估框架 — github.com/centerforaisafety/HarmBench
• NeMo Guardrails (NVIDIA):可程式化護欄工具包 — github.com/NVIDIA/NeMo-Guardrails

標準與框架

• OWASP LLM Top 10 2025 — owasp.org/www-project-top-10-for-large-language-model-applications
• MITRE ATLAS — atlas.mitre.org
• NIST AI 600-1 — nist.gov/artificial-intelligence
• EU AI Act — digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai