RAG管道的审计追踪：欧盟AI法案第30条对检索系统的要求

欧盟AI法案于2024年8月生效。对于运行检索增强生成管道并为高风险应用提供数据的企业来说，合规时钟正在滴答作响。第11、12、13和30条针对技术文档、自动日志记录、透明度和注册提出了具体要求——这些要求不仅适用于生成响应的模型，还适用于决定模型看到什么的每个上游系统。

如果您的RAG管道摄取文档、对其分块、嵌入、存储在向量数据库中，并为语言模型检索上下文，那么每一个步骤现在都在监管范围之内。问题不是您是否需要审计追踪。问题是您今天拥有的审计追踪能否经受住合规性评估。

什么使系统成为"高风险"

欧盟AI法案在附件III中定义了高风险AI系统。该列表包括用于就业和工人管理、信用评分、保险承保、执法、移民和庇护处理、基本服务获取以及司法管理的系统。如果您的RAG管道为这些用例中的任何一个提供数据，第11至13条的全部要求均适用。

分类是基于目的而非技术。为聊天机器人检索产品常见问题的RAG管道不是高风险的。同样的管道架构为医疗决策支持工具检索临床指南则很可能是高风险的。这种区别很重要，因为高风险系统的文档和日志记录要求是详细的、规范性的且可强制执行的。

企业往往低估了其内部AI工具中有多少符合条件。使用RAG提取职位描述和政策文件来排序候选人的人力资源筛选工具完全属于附件III的范围。检索监管文本以帮助分析师起草提交给金融监管机构报告的合规工具也是如此。

这些条款究竟要求什么

四个条款构成了RAG管道审计追踪义务的核心。

第11条 — 技术文档

第11条要求高风险AI系统的提供者在系统投放市场或投入使用之前编制技术文档。对于RAG管道，这意味着记录用于摄取的数据源、分块和预处理逻辑、嵌入模型及其版本、向量存储配置、检索策略（相似度阈值、top-k、重新排序）以及在传递给生成模型之前组装检索上下文的提示词模板。

这不是一次性工作。文档必须在系统的整个生命周期中保持更新。每次更换嵌入模型、更改分块策略或添加新数据源时，技术文档都必须反映这些变化。

第12条 — 记录保存和自动日志记录

第12条要求高风险AI系统的设计和开发具备在系统运行时自动记录事件（日志）的能力。对于RAG管道，这转化为每个阶段的日志记录：

• 摄取：摄取了哪些文档、何时、由谁、应用了什么预处理
• 分块：文档如何拆分、使用了什么块大小和重叠设置、产生了多少块
• 嵌入：哪个嵌入模型和版本产生了向量、每批次的时间戳
• 存储：向量何时写入存储、任何去重或更新操作
• 检索：对于每个查询，检索了哪些块、它们的相似度分数、应用了任何重新排序、以及传递给模型的最终上下文窗口
• 生成：发送给LLM的提示词、收到的响应、以及任何后处理或过滤

日志必须足以重建系统对任何给定输出的行为。如果监管机构询问为什么检索了特定的上下文片段——或为什么没有检索——您需要能够用带有时间戳的证据来回答。

第13条 — 透明度和向部署者提供信息

第13条要求高风险AI系统的设计确保其运行足够透明，使部署者能够解释系统的输出。对于RAG管道，这意味着最终用户或部署者必须能够理解哪些来源影响了特定响应。

这不仅仅是列出检索到的文档。它要求可追溯性：能够将响应追溯通过检索步骤、通过向量存储、通过嵌入、通过分块，一直到原始来源文档和对答案有贡献的特定段落。

第30条 — 在欧盟数据库中注册

第30条要求高风险AI系统的提供者和部署者在将系统投放市场之前在欧盟数据库中注册该系统。注册包括系统预期目的的描述、所使用数据的类别以及有关系统性能和局限性的信息。如果您的RAG管道是已注册高风险系统的组件，其架构和数据源将成为注册记录的一部分。

实用的日志记录架构

满足这些要求需要一种日志记录架构，将RAG管道视为一等可审计系统，而不是附加在推理上的事后补充。

摄取层

进入管道的每个文档都需要一个来源记录：源URL或文件路径、摄取时间戳、操作员ID、文件哈希以及应用的任何转换（OCR、格式转换、元数据提取）。如果文档被更新，系统必须记录差异——什么发生了变化、何时以及为什么触发了更新。

处理层

分块和嵌入是大多数RAG管道失去审计保真度的地方。团队记录最终向量但不记录产生它们的中间步骤。合规的管道记录每个文档使用的分块参数、任何清理或标准化前后的原始块以及嵌入模型版本及其配置。当重新训练或更换嵌入模型时，日志必须捕获更改前后的状态。

检索层

每个检索操作都产生一条审计记录：输入查询、搜索参数、带分数的候选块、任何重新排序或过滤以及向下游传递的最终上下文。这是第13条透明度要求最为关键的层。日志必须支持回答这个问题："对于这个特定输出，系统考虑了什么信息，排除了什么？"

数据质量层

原始日志记录是必要的但不充分的。合规性评估不仅会询问什么数据进入了管道，还会询问数据是否适合其目的。这就是自动化质量检查成为审计追踪一部分的地方——对块的相关性进行评分、检测嵌入分布中的异常以及标记超出预期参数的文档。

在Ertas中的实现

Ertas在设计时就将这种审计架构作为基础层，而不是合规附加组件。管道中的每个转换——从原始文件上传到向量存储条目——都带有时间戳和操作员ID记录。完整的数据谱系得以保留：可以将任何向量追溯通过其嵌入、其块和其源文档。

质量评分器评估传入数据并产生成为审计记录一部分的质量指标。异常检测器标记嵌入分布、块长度和源元数据中的统计异常值——提供有记录的证据，证明管道持续监控数据质量，而不仅仅是在部署时。

当合规性评估要求证明系统的训练和检索数据符合质量标准时，这些记录已经是结构化且可导出的。Ertas生成的审计报告直接映射到第11和12条的文档要求，涵盖数据来源、处理参数、质量分数和检索日志。

评估中最可能暴露的常见差距

根据第11至13条的要求，以下是在RAG管道合规性评估中最可能浮出水面的差距：

**嵌入模型没有版本控制。**如果无法证明在特定日期生效的向量是由哪个嵌入模型版本产生的，就无法重建该时期的系统行为。

**分块参数未记录。**许多团队硬编码分块设置，从不记录。当设置更改时，没有记录之前的配置是什么或更改何时发生。

**检索日志缺少否定证据。**记录检索到的内容很简单。记录被考虑和排除的内容——以及原因——更困难，但第13条的透明度要求要求必须这样做。

**没有数据质量文档。**在没有质量检查的情况下摄取文档意味着没有证据表明供给高风险系统的数据是适当的。合规性评估将此标记为系统性差距。

**没有审计记录的手动流程。**如果人工策展人从管道中选择或移除文档，该决定必须以与自动化操作相同的严格性进行记录。

展望未来

欧盟AI法案对RAG管道审计追踪的要求并不含糊。如果您的检索系统为高风险应用提供数据，您需要在每个管道阶段进行自动日志记录、与系统变化保持同步的技术文档、让部署者能够将输出追溯到来源的透明度机制，以及证明适合目的的数据质量证据。

将此视为设计约束的组织——从一开始就将审计追踪构建到管道架构中——会发现合规很简单。试图将日志记录改造到现有管道上的组织会发现它昂贵、脆弱且永远不完整。

该法规并不要求您停止构建RAG系统。它要求您构建RAG系统时确保每一步都有记录、每个转换都可追溯、每个输出都可以解释。这不仅仅是良好的合规。这是良好的工程。