RAG 失败可能在检索之前就开始：文档过时、表格遗漏、来源无归属、权限元数据丢失、未删除的向量、矛盾的隐藏文本或不安全的文件。
安全文档摄取是对企业知识实施来源控制。它决定哪些内容可以进入检索系统、谁可以查看、如何跟踪时效性、如何进行删除，以及如何发现不良输入。
本文介绍摄取层：PDF、OCR、元数据、权限、保留和运营检查。
如果用户无权在源系统中访问某份文档，也就不应在 RAG 系统中访问它的文本块、嵌入、摘要或缓存答案。权限元数据不可省略。
摄取流水线
生产流水线应有明确的阶段：
- 来源注册。
- 数据分类。
- 文件安全检查。
- 文本提取和 OCR。
- 结构保留。
- 元数据附加。
- 权限映射。
- 分块与嵌入。
- 质量检查。
- 索引发布。
- 保留与删除处理。
- 运营归属。
具体工具可以不同，但控制点不可缺少。
阶段 1：来源登记
不要仅仅因为某个随机文件夹容易连接，就将其摄取。
应为每个来源记录：
- 来源名称，
- 权威记录系统，
- 来源负责人，
- 数据负责人，
- 允许的用户或角色，
- 文档类型，
- 敏感度等级，
- 保留规则，
- 更新频率，
- 删除行为，
- 复核计划。
来源示例：
- 公开帮助中心，
- 内部客服手册，
- 销售资料，
- 客户合同，
- 人力资源政策，
- 工程运行手册，
- 产品文档，
- 会议文字记录。
这些来源不应全部进入具有相同权限的同一个索引。
阶段 2：提取前对数据分类
应在模型或嵌入服务提供商看到内容之前，对来源进行分类。
实用的分类包括：
| 类别 | 示例 | 默认处理原则 |
|---|---|---|
| 公开 | 已发布文档、营销页面 | 允许广泛检索 |
| 内部 | 手册、流程文档 | 仅限公司内部，按角色筛选 |
| 机密 | 合同、客户详情、财务 | 仅限受限角色，采用更严格的日志记录 |
| 受监管/敏感 | 健康、法律、人力资源、薪资、安全事件 | 除非获得明确批准，否则避免摄取 |
分类不仅是合规手续，还决定内容能否发送到托管的嵌入 API、存储在共享向量数据库中、写入日志，或用于评估示例。
阶段 3：文件安全检查
文档可能带有恶意，也可能只是已经损坏。
提取前应：
- 根据允许列表检查文件类型，
- 实施文件大小限制，
- 在环境有相应要求时扫描恶意软件，
- 拒绝加密文件，除非存在获批的解密路径，
- 拒绝包含不受支持的嵌入对象的文件，
- 规范化文件名，
- 存储原始文件哈希，
- 记录文件的上传者或连接者。
如果非管理员用户可以上传文档，这一点尤为重要。仅限管理员上传可以降低一条威胁路径，但并不能使被入侵、恶意、过大或格式错误的文档变得安全。连接器和 URL 上传也需要允许列表中的来源、重定向和 DNS 控制、认证范围、速率限制以及 SSRF 测试。
如果不可信用户可以上传文件，在解析之前应实施文件安全层。使用维护良好的 OWASP 文件上传速查表作为基准，并对所选解析器和存储路径进行威胁建模。对于更广泛的检索威胁模型（包括投毒、权限泄露、提示注入和不安全输出），还应使用 OWASP RAG 安全速查表。
候选控制措施包括依据文件内容验证允许的类型、限制文件大小和归档解压后的体积、随机化存储名称、扫描恶意软件特征、在限制资源且禁止出站网络的隔离环境中解析，以及在威胁模型需要时采用内容净化与重构（CDR）。没有任何单一扫描器能够证明文件安全。
阶段 4：文本提取和 OCR
在实践中，PDF 并不是一种单一格式。有些包含可选择文本，有些是扫描件，还有些包含分栏、表格、脚注、表单、批注、印章或隐藏文本层。
根据文档类型选择提取路径：对原生数字 PDF 使用文本优先提取器，对结构化文档使用布局感知转换器，对扫描件使用 OCR。工具选择必须依据经过基准测试的布局和表格准确性、语言支持、许可证、补丁流程和数据边界。
对于阈值，不要照搬博客文章中的通用 OCR 置信度阈值，而应使用自己的文档样本进行校准。实用的做法是划分两个区间：低于下限的页面直接拒绝；处于上下限之间的页面进入人工审核队列；高于上限的页面继续流转。上下限的具体数值取决于扫描仪、文档年代和语言。
对于爱沙尼亚语和混合语言的档案，应在基准测试中包含变音符号、较早的打字机页面、表格、邮戳以及爱沙尼亚语和俄语混合示例。确认所选的 OCR 引擎具备所需的语言数据，然后在具有代表性的页面上测量字符、单词、字段和表格的准确性。不要承诺一个统一的试点持续时间。
跟踪提取质量：
- 提取方法，
- OCR 置信度，
- 页数，
- 提取字符数，
- 表格提取状态，
- 检测到的语言，
- 没有文本的页面，
- 解析器警告。
不应让低质量提取结果悄无声息地进入索引。应将其送审，或标记为低置信度。
常见问题：
- 分栏阅读顺序错误，
- 表格行错误合并，
- 每个文本块都重复页眉，
- 扫描页完全缺失，
- 忽略手写注释，
- 隐藏文本层与可见扫描内容冲突，
- OCR 错误转换账号。
对于高价值文档，应抽查渲染页面与提取文本是否一致。
阶段 5：保留结构
RAG 系统需要的不只是文本，还需要足够的结构，才能生成实用且有来源依据的答案。
应保留：
- 标题，
- 标题路径，
- 章节编号，
- 页码，
- 表格标题，
- 列表边界，
- 文档版本，
- 生效日期，
- 来源 URL 或存储路径。
分块时应附带标题和页码引用。只写着“以下规定适用”、却没有前置标题的文本块，是薄弱的证据。
对于表格，应决定：
- 以 Markdown 形式保留表格，
- 转换为结构化 JSON，
- 同时存储文本和结构化行，
- 在获得更好的解析器前将其排除。
如果使用场景依赖精确的价格、日期、限额或阈值，就不要假装表格提取问题已经解决。
阶段 6：附加元数据
每个文本块都应携带能在检索过程中保留下来的元数据：
{
"sourceId": "policy-2026-expenses",
"documentId": "doc_123",
"tenantId": "tenant_a",
"visibility": "internal",
"allowedRoles": ["finance", "leadership"],
"sensitivity": "confidential",
"sourceOwner": "Finance",
"version": "2026-02",
"lastReviewedAt": "2026-02-10",
"effectiveFrom": "2026-03-01",
"page": 7,
"headingPath": ["Travel", "Hotel limits"],
"contentHash": "sha256:..."
}
元数据为策略强制执行提供输入，本身并不会执行策略。应用程序必须验证可信元数据的来源，并在发布、检索、缓存、引用、生成和导出等边界实施授权控制。
阶段 7：权限映射
必须在检索结果到达模型之前执行权限控制；如果身份或策略可能发生变化，还须在答案、引用、缓存或导出等边界再次执行。
正确模式：
- 用户提出问题。
- 应用根据身份验证信息确定租户、用户、角色、群组和数据权限。
- 检索器根据权限筛选候选文本块。
- 只对已获授权的文本块进行排序。
- 模型只接收允许的文本块。
错误模式：
- 广泛检索。
- 把所有可能相关的文本块发送给模型。
- 在提示词中写道：“仅使用用户有权访问的文本块作答。”
错误模式已经把数据暴露给模型上下文。
如果源权限很复杂，应从更窄的范围开始。漏掉一个答案，也好过泄露一份机密文档。
阶段 8：分块和嵌入
分块不仅是搜索调优决策，也是安全和质量决策。
指导原则：
- 文本块不得跨越权限边界。
- 不要把公开文本和机密文本合并到同一个文本块中。
- 包含标题和来源引用。
- 避免包含无关章节的巨大文本块。
- 避免因过小而丢失上下文的文本块。
- 当源文本或元数据发生变化时重新嵌入。
- 存储嵌入模型及其版本。
对于敏感来源，应确认嵌入服务提供商、向量存储和日志是否获准处理相应数据类别。
阶段 9：质量关卡
将来源发布到生产检索前，应运行以下检查：
- 所有文档都有负责人，
- 所有文本块都有权限元数据，
- 过时文档已被标记，
- 提取失败的页面已排除或经过审核，
- 示例问题能检索到预期来源，
- 未授权用户检索到的受限文本块数量为零，
- 已删除文档不再出现在搜索结果中，
- 引用指向有效的来源位置，
- 文档中的可疑指令被隔离为内容，而不会得到执行。
最后一点非常重要。文档可能包含提示注入。摄取流水线不应悄悄删除所有此类文本，因为用户可能需要知道文档写了什么，而删除内容可能破坏证据。运行时必须把检索到的内容保留在数据通道中，不能让它授予工具权限或更改策略；还要独立验证工具参数，并要求人工批准后果重大的操作。
阶段 10：以原子方式发布索引版本
不要让只完成部分摄取的文档，或混有新旧权限的数据，进入当前使用的索引。应先构建候选索引或带版本的命名空间，然后：
- 冻结源/版本清单和内容哈希值；
- 验证文档数量、提取失败情况、权限覆盖范围、重复策略、嵌入模型/版本以及具有代表性的授权/未授权查询；
- 记录候选版本、源版本、测试结果、审批人和回滚目标；
- 在存储支持的情况下，原子性地将别名或应用程序指针切换至已批准的版本；
- 使检索缓存和答案缓存失效，或对其进行版本控制；
- 上线切换后监控错误、访问拒绝、空检索和流向旧版本的流量。
如果向量存储不支持原子性版本切换，请在应用程序端实现发布状态，排除不完整记录，并在上线切换期间测试并发读取。权限撤销和紧急来源删除不得等待完整重建：应在索引之外强制执行当前授权，立即拒绝受影响的来源，清除相关缓存，并通过生命周期工作流清理所有衍生数据。
回滚应恢复最后一个已批准的索引指针，但不应恢复被撤销的访问权限或删除的数据。测试回滚不应恢复已被替代的 ACL、已删除文档、被污染的来源或过时的缓存答案。
阶段 11：保留与删除
RAG 系统往往会在无意中比源系统更长久地保留数据。
GDPR 第 17 条 定义了在特定条件和例外情况下的删除权。合格的法律顾问必须确定适用的义务和任何合法的保留要求。系统仍需为每一份副本和衍生数据建立清单，并提供相应的生命周期操作：
- 原始文件缓存，
- 提取的文本，
- 分块内容，
- 嵌入向量，
- 摘要，
- 缩略图或渲染页面，
- 评估样本，
- 日志，需有批准的最小化和保留依据，
- 备份，需有记录的过期策略和恢复行为。
当文档被删除或访问权限被撤销时，检索和响应缓存应在规定的时间范围内停止返回该文档。删除流程必须涵盖派生存储，并防止旧备份或延迟的摄取任务使该记录重新出现。
跟踪：
- deletedAt，
- deletedBy 或来源事件，
- 删除原因，
- 下游清理状态，
- 验证结果。
不要只相信“我们已从 UI 中删除”。向量存储和缓存很容易被遗忘。
阶段 12：运营责任归属
每个生产来源都需要一名承担责任的负责人，并根据变更频率和影响设定复核触发条件或周期。
应为每个来源明确：
- 谁批准摄取，
- 谁批准权限变更，
- 谁复核过时文档，
- 谁处理提取失败，
- 谁响应数据删除请求，
- 谁调查检索错误。
如果某个来源无人负责，就不应进入生产 RAG 系统。
来源治理，而非保证
安全的 RAG 摄取需要有意识地治理来源。它让检索行为和失败情况更容易观察和测试，但并不能保证生成的答案本身正确或安全。
核心控制包括：
- 登记来源，
- 对数据分类，
- 解析前检查文件，
- 衡量提取质量，
- 保留结构，
- 附加元数据，
- 在检索前强制执行权限控制，
- 测试未授权访问，
- 支持删除，
- 指定负责人。
来源质量和来源控制是答案质量与安全所必需的输入，而非保证。请端到端验证检索、授权、基于来源作答、拒答、工具使用和生命周期行为。
