金融服務最佳 RAG 管線：面向 PII 密集資料的氣隙檢索

財務報表、客戶 PII 和威脅情報資料必須留在氣隙環境中。這不是偏好——而是監管要求。然而大多數 RAG 管線供應商假設嵌入、向量資料庫託管和模型推理需要網際網路連線。這一假設在第一份文件匯入之前就將它們排除在了討論之外。

本文介紹如何建構一個完全在本地執行的金融服務 RAG 管線，在無暴露風險的情況下處理 PII 密集文件，並滿足治理該產業的合規框架。

為什麼標準 RAG 管線在金融服務中會失敗

典型的 RAG 管線將文件發送到雲端嵌入 API，將向量儲存在託管資料庫中，並在推理時呼叫雲端 LLM。這三個步驟中的每一個都會為大多數金融機構創造合規違規。

嵌入 API 呼叫傳輸原始文件文字。 當金融分析師查詢關於客戶投資組合的 RAG 系統時，檢索步驟將文件分塊——包含帳戶號碼、社會安全號碼、交易記錄——發送到外部 API。在大多數監管框架下，這就是資料洩露，無論 API 提供商是否聲稱自己通過了 SOC 2 合規。

託管向量資料庫在外部儲存文件表示。 儘管嵌入不是人類可讀的，但它們可以被反轉以重建近似的文件內容。將它們儲存在第三方基礎設施上意味著 PII 已經離開了你的安全邊界。

雲端 LLM 推理暴露查詢上下文。 檢索到的分塊與使用者查詢結合，被發送到雲端模型。完整的上下文視窗——包括來自檢索文件的 PII——現在在別人的伺服器上。

氣隙 RAG 管線消除了所有三個故障點。每個組件都在你的網路邊界內執行。沒有資料外流。

塑造架構的合規要求

金融服務 RAG 部署必須滿足重疊的監管框架。架構不是可選的——它由以下要求決定。

SOC 2 Type II

SOC 2 Type II 稽核評估至少六個月期間的控制措施。對於 RAG 管線，這意味著：

存取控制，控制誰可以查詢哪些文件集合
稽核日誌記錄，記錄每次檢索和推理事件，包含使用者身分、時間戳記、檢索到的文件和查詢文字
變更管理，涵蓋模型更新、嵌入模型切換和索引重建
靜態加密，用於向量儲存和文件儲存
傳輸加密，用於管線組件之間的所有內部 API 呼叫

GDPR（第 17、20、25、35 條）

GDPR 適用於任何處理歐盟公民資料的金融機構，無論該機構總部位於何處。

被遺忘權（第 17 條）： 你必須能夠從向量儲存中刪除特定個人的資料，並在不包含該資料的情況下重新索引。雲端託管嵌入使這幾乎無法驗證。
資料可攜性（第 20 條）： RAG 系統必須能夠以可攜式格式匯出與資料主體相關的所有資料。
設計即保護資料（第 25 條）： PII 必須在每個階段——匯入、分塊、嵌入、儲存、檢索和生成——被識別並採取適當的保護措施。
DPIA（第 35 條）： 在部署大規模處理 PII 的 AI 系統之前，需要進行資料保護影響評估。

MiFID II 記錄保存

MiFID II 要求金融公司保留與客戶交易相關的所有通訊和決策記錄。如果 RAG 驅動的系統參與投資研究、風險評估或客戶溝通，每次查詢和每個生成的回應都必須保留至少五年——在某些司法管轄區為七年。

這意味著 RAG 管線需要一個不可變的稽核日誌，每個事件包含以下欄位：時間戳記、使用者身分、查詢文字、檢索到的文件 ID 及相關性評分、生成的回應和模型版本。

氣隙 RAG 架構

面向金融資料的氣隙 RAG 管線有五個階段，全部在網路邊界內執行。

第一階段：文件匯入和 PII 偵測

原始文件進入管線——財務報表、KYC 表格、交易記錄、合規報告。在任何處理之前，PII 偵測步驟識別並標記敏感欄位：帳戶號碼、社會安全號碼、稅務 ID、姓名、地址、出生日期。

這就是 Ertas Data Suite 的 PII Redactor 發揮作用的地方。作為無需網際網路的桌面應用程式執行，它掃描傳入文件並標記每個金融識別碼。標記的 PII 元資料隨文件通過管線傳遞，在下游實現欄位級存取控制。

第二階段：分塊和預處理

標記的文件被分割成適合檢索的塊。金融文件需要領域感知的分塊：

表格感知分割將財務表格作為原子單元保留，而不是跨塊拆分列
章節邊界偵測保持監管文件章節（風險因素、管理層討論、財務報表）的完整性
元資料傳播確保每個塊繼承其來源文件的 PII 標記

第三階段：本地嵌入生成

開源嵌入模型在本地執行。無需 API 呼叫。3 億到 5 億參數範圍的模型（如 E5-large 或 BGE-large）可在普通硬體上生成高品質嵌入——單個 GPU 甚至純 CPU 推理即可處理較小的文件集合。

嵌入生成是批次處理過程。10 萬個文件塊的集合可以在單張 NVIDIA T4 上在兩小時內完成嵌入。

第四階段：本地向量儲存和檢索

向量儲存在本地執行。Qdrant、Milvus 或 Weaviate 等開源選項作為自託管服務部署在你的網路內。沒有資料外流。

檢索查詢在本地執行。當使用者查詢系統時，查詢使用相同的本地模型進行嵌入，相似性搜尋在本地向量儲存上執行，傳回 top-k 個塊——全部在氣隙邊界內完成。

第五階段：本地推理與稽核日誌記錄

本地部署的 LLM 使用檢索到的上下文生成回應。模型、查詢和檢索到的塊永遠不會離開你的基礎設施。每個推理事件都記錄到不可變稽核儲存中，具有完整的溯源資訊：檢索了哪些文件、哪個使用者發起了查詢、生成了什麼回應。

比較：雲端 RAG vs. 氣隙 RAG 用於金融服務

維度	雲端託管 RAG	氣隙 RAG（Ertas）
PII 暴露風險	高——文件文字發送到外部 API	無——所有處理在本地
SOC 2 Type II 稽核	需要供應商 SOC 2 報告和共享責任模型	完全在你的稽核邊界內
GDPR 被遺忘權	難以驗證跨第三方系統的刪除	完全控制——本地刪除和重新索引
MiFID II 記錄保存	稽核日誌分散在供應商和內部系統之間	單一不可變日誌儲存在本地
網際網路依賴	嵌入、向量資料庫和推理都需要	無——完全氣隙運行
PII 脫敏	手動或第三方服務（資料離開邊界）	Ertas PII Redactor——本地，無需網際網路
嵌入模型控制	供應商選擇，可能未經通知就更改	你選擇並版本控制模型
延遲	不穩定——取決於 API 回應時間	可預測——僅限本地網路
成本模型	按 token 和按查詢計費，隨使用量增長	固定基礎設施成本，無按查詢計費
供應商鎖定	高——專有嵌入、向量格式	無——全程開源組件

PII 處理：成敗攸關的要求

金融服務 RAG 最大的差異化因素是 PII 處理。大多數 RAG 管線將 PII 視為別人的問題。在金融服務中，PII 就是核心資料。

一流的敏感文件 RAG 管線必須在三個層面處理 PII：

嵌入前脫敏。 某些 PII 欄位（社會安全號碼、完整帳戶號碼）應在嵌入前被脫敏或令牌化。嵌入應編碼文件的語意內容，而不編碼可恢復的 PII。Ertas PII Redactor 自動處理金融識別碼類型。

欄位級存取控制。 不同使用者應在檢索結果中看到不同級別的 PII。審查反洗錢警報的合規官需要完整的帳戶詳情。查詢市場評論的研究分析師則不需要。RAG 管線必須在檢索時執行這些控制，而不僅僅在 UI 層。

刪除和重新索引。 當客戶行使被遺忘權時，管線必須刪除從該客戶文件衍生的所有塊，從儲存中移除相應向量，並驗證沒有殘留資料。使用本地向量儲存這很簡單。使用雲端託管的則幾乎無法驗證。

硬體要求

面向中型金融機構（處理 50,000 到 500,000 份文件）的氣隙 RAG 管線需要適度的硬體：

嵌入伺服器： 1x NVIDIA T4 16GB 或等效。純 CPU 對於少於 50,000 個塊的集合是可行的，但批次重新索引較慢。
向量儲存： 64GB RAM，1TB NVMe SSD。隨集合大小線性擴展。
推理伺服器： 1x NVIDIA T4 16GB 用於 7B-8B 參數模型。增加第二張用於高可用性。
稽核日誌儲存： 僅附加儲存，按五到七年的保留期規劃。500GB 涵蓋大多數部署。

總硬體成本通常在 $20,000 到 $50,000 之間——在金融服務查詢量下，這只是年度雲端 RAG API 成本的一小部分。

入門指南

面向金融資料的氣隙 RAG 管線的最快路徑是從 PII 處理開始。如果你的 PII 偵測和脫敏管線紮實，架構的其餘部分遵循標準模式。

Ertas Data Suite 將 PII Redactor 作為其本地桌面應用程式的一部分提供。它處理通用 PII 工具遺漏的金融識別碼——各種帳戶號碼格式、跨司法管轄區的稅務 ID 模式和機構特定的參考號碼。無需網際網路連線。每個脫敏決策都有完整的稽核記錄。

在此基礎上，將其與開源嵌入模型和自託管向量儲存配對。面向企業金融服務的最佳 RAG 管線是那種沒有資料離開你的邊界的——而且你可以向每個提出要求的稽核員證明這一點。