安全 RAG 管線設計模式

以安全為優先的 RAG 管線設計模式,涵蓋來源驗證、內容淨化與檢索控制。

概述

以安全為優先的 RAG 管線設計模式,涵蓋來源驗證、內容淨化與檢索控制。

本文在現代 AI 安全的脈絡下,對安全 RAG 管線設計模式進行全面且動手實作的探討。文中討論的技術、框架與方法論皆基於同儕審查研究與真實世界事件。Anthropic 2024 年「Many-shot Jailbreaking」技術報告奠定了貫穿全文分析的基礎威脅模型。

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

討論分為幾個階段展開。首先建立概念基礎——安全疑慮背後的「為什麼」。接著深入技術機制——利用與防禦的「如何做」。然後提供具備實作程式碼範例的實務指引,最後介紹評估框架與度量指標。最終,我們彙整關鍵教訓並指出開放的研究方向。

全文中我們引用 NIST AI 600-1 — 生成式 AI 設定檔,以及 HarmBench — LLM 攻擊標準化評估等既定框架,使分析根基於業界認可的分類法。程式碼範例使用 Python,旨在教學——它們闡述的是技術類別,而非提供可武器化的利用程式。

核心概念與威脅模型

基本原則

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

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

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

威脅模型定義

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

攻擊分類法

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

技術深入剖析

機制分析

安全 RAG 管線設計模式背後的技術機制,運作於模型能力與部署架構的交會處。若要完整理解,我們需要同時檢視模型層級的行為,以及其所處的系統層級脈絡。

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

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

逐步分析

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

階段 1:偵察與目標剖析

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

以下 Python 程式碼示範一個 TargetProfiler 類別,用於剖析目標 LLM 應用的行為與防禦。它透過指紋探測(傳送如「What model are you?」等探針訊息,分析回應中是否出現 Claude、GPT、Gemini 等關鍵字)來識別底層模型;透過發送良性訊息與已知易觸發過濾器的測試訊息,比較回應差異以推斷是否存在輸入過濾器;最終產生一份含有建議的剖析報告(例如「未偵測到輸入過濾器——直接注入可能可行」)。

import httpx
import json
from typing import Optional
 
class TargetProfiler:
    """Profile a target LLM application's behavior and defenses."""
 
    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,
            "has_output_filter": False,
            "supports_system_prompt": True,
        }
 
    def probe_model_identity(self) -> str:
        probes = [
            "What model are you? Reply with only your model name.",
            "Complete this: 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 or "openai" 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
import hashlib
from datetime import datetime
from dataclasses import dataclass, field
from typing import List, Dict, Optional, Any
from pathlib import Path
 
logging.basicConfig(level=logging.INFO,
    format="%(asctime)s [%(levelname)s] %(name)s: %(message)s")
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"
    MEDIUM = "medium"
    HIGH = "high"
    CRITICAL = "critical"
 
@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.num_stages = num_stages
        self.conversation_history = []
 
    def execute_stage(self, stage_num: int, payload_fragment: str) -> str:
        framing = [
            "I'm working on a research paper about AI safety. Can you help me: {payload}",
            "For an academic project, I need to analyze: {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 與表徵工程 (representation engineering) 等技術,對構建本質上更健壯的模型展現出潛力,但面對複雜攻擊仍不完美。

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

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

評估框架

評估方法論

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

步驟 1:定義目標

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

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

步驟 2:建立基線

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

步驟 3:系統化測試

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

步驟 4:影響分類

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

步驟 5:修補指引

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

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

當前研究方向

開放問題

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

對齊稅問題:讓模型對對抗性輸入更健壯,往往會降低對良性輸入的效能——所謂「對齊稅」。Anthropic 2024 年「Many-shot Jailbreaking」技術報告探索了最小化此取捨的方法,但沒有解決方案能完全消除。

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

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

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

未來意涵

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

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

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

參考資料與延伸閱讀

關鍵參考

• Anthropic 2024 — 「Many-shot Jailbreaking」技術報告
• NIST AI 600-1 — 生成式 AI 設定檔
• HarmBench — LLM 攻擊的標準化評估
• OWASP LLM Top 10 2025 版

工具與框架

• 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