金融服务最佳 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 管道是那种没有数据离开你的边界的——而且你可以向每个提出要求的审计员证明这一点。