大多数RAG故障都始于检索之前：文档已经过时，OCR漏掉了表格，来源没有负责人，权限元数据丢失，已经删除的合同仍留在向量存储中，或者扫描版PDF包含无人审核的隐藏文本。系统仍会自信作答，因为摄取流水线把“存在文本”等同于“可以安全使用的知识”。
安全文档摄取是对企业知识实施来源控制。它决定哪些内容可以进入检索系统、谁可以查看、如何跟踪时效性、如何进行删除，以及如何发现不良输入。
本文介绍摄取层：PDF、OCR、元数据、权限、保留和运营检查。
如果用户无权在源系统中访问某份文档，也就不应在RAG系统中访问它的文本块、嵌入、摘要或缓存答案。权限元数据不可省略。
摄取流水线
生产流水线应有明确的阶段：
- 来源登记。
- 数据分类。
- 文件安全检查。
- 文本提取和OCR。
- 结构保留。
- 附加元数据。
- 权限映射。
- 分块和嵌入。
- 质量检查。
- 发布索引。
- 保留和删除处理。
具体工具可以不同，但控制点不可缺少。
阶段1：来源登记
不要仅仅因为某个随机文件夹容易连接，就将其摄取。
应为每个来源记录：
- 来源名称，
- 权威记录系统，
- 来源负责人，
- 数据负责人，
- 允许的用户或角色，
- 文档类型，
- 敏感度等级，
- 保留规则，
- 更新频率，
- 删除行为，
- 复核计划。
来源示例：
- 公开帮助中心，
- 内部客服手册，
- 销售资料，
- 客户合同，
- 人力资源政策，
- 工程运行手册，
- 产品文档，
- 会议文字记录。
这些来源不应全部进入具有相同权限的同一个索引。
阶段2：提取前对数据分类
应在模型或嵌入服务提供商看到内容之前，对来源进行分类。
实用的分类包括：
| 类别 | 示例 | 默认处理原则 |
|---|---|---|
| 公开 | 已发布文档、营销页面 | 允许广泛检索 |
| 内部 | 手册、流程文档 | 仅限公司内部，按角色筛选 |
| 机密 | 合同、客户详情、财务 | 仅限受限角色，采用更严格的日志记录 |
| 受监管/敏感 | 健康、法律、人力资源、薪资、安全事件 | 除非获得明确批准，否则避免摄取 |
分类不仅是合规手续，还决定内容能否发送到托管的嵌入API、存储在共享向量数据库中、写入日志，或用于评估示例。
阶段3：文件安全检查
文档可能带有恶意，也可能只是已经损坏。
提取前应：
- 根据白名单检查文件类型，
- 实施文件大小限制，
- 在环境有相应要求时扫描恶意软件，
- 拒绝加密文件，除非存在获批的解密路径，
- 拒绝包含不受支持的嵌入对象的文件，
- 规范化文件名，
- 存储原始文件哈希，
- 记录文件的上传者或连接者。
如果非管理员用户可以上传文档，这一点尤其重要。仅限管理员摄取可以降低风险，但不能消除风险。
大多数RAG技术栈不会自动提供防病毒和内容解除武装控制。如果不可信用户可以上传文件，应在解析前增加真正的文件安全层。
按照防护严格程度逐级提高，这一层在实践中可以采用：至少使用签名扫描器（ClamAV级别）；在隔离且禁止出站访问的容器中进行解析——PDF和办公文档格式解析器长期存在大量CVE，因此应把解析器本身视为攻击面；对于真正不可信的输入，还可以使用内容解除武装与重建（CDR），通过重建文件的干净副本来避免信任原文件。大多数中小企业流水线需要前两项；当外部人员可以提交文档时，再加入CDR。
阶段4：文本提取和OCR
在实践中，PDF并不是一种单一格式。有些包含可选择文本，有些是扫描件，还有些包含分栏、表格、脚注、表单、批注、印章或隐藏文本层。
应根据文档类型选择提取路径：对原生数字PDF使用文本优先提取器（PyMuPDF或pdfplumber级别）；对结构化文档使用布局感知转换器（Docling或Unstructured级别——能更好地保留表格和阅读顺序）；仅对真正的扫描件使用OCR（自托管方案以Tesseract为基准；扫描质量较差且数据分类允许时，可以使用云OCR服务）。
对于阈值，不要照搬博客文章中的通用OCR置信度阈值，而应使用自己的文档样本进行校准。实用的做法是划分两个区间：低于下限的页面直接拒绝；处于上下限之间的页面进入人工审核队列；高于上限的页面继续流转。上下限的具体数值取决于扫描仪、文档年代和语言。
针对我们所在市场还有一点需要注意：爱沙尼亚语OCR比英语OCR更难。Tesseract虽然提供爱沙尼亚语模型，但对õ/ä/ö/ü、老式打字档案以及爱沙尼亚语与俄语混合文档的识别准确率差异很大，因此在确定引擎前，应使用具有代表性的自有档案样本进行试点比较。对于爱沙尼亚公司而言，这项半天即可完成的试点，能避免日后四分之一的隐性检索失败。
跟踪提取质量：
- 提取方法，
- 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：保留和删除（GDPR第17条在这里落地）
RAG系统往往会在无意中比源系统更长久地保留数据。
正是在这个阶段，GDPR的删除权（第17条）从政策声明变成工程要求：收到删除请求时，如果数据副本仍留在流水线其他位置，“我们删除了源文件”就不是一个站得住脚的回答。删除必须覆盖：
- 原始文件缓存，
- 提取文本，
- 文本块，
- 嵌入，
- 摘要，
- 缩略图或渲染页面，
- 评估样本，
- 法律要求删除的日志，
- 根据政策处理的备份。
删除文档或撤销访问权限后，检索应停止返回相应文本块。理想情况下，系统应支持对敏感来源进行硬删除，并为备份制定有记录的保留规则。
跟踪：
- deletedAt，
- deletedBy或来源事件，
- 删除原因，
- 下游清理状态，
- 验证结果。
不要依赖“我们已从UI中删除”。向量存储和缓存很容易被遗忘。
阶段11：运营责任归属
每个来源都需要负责人，每位负责人都需要复核周期。
应为每个来源明确：
- 谁批准摄取，
- 谁批准权限变更，
- 谁复核过时文档，
- 谁处理提取失败，
- 谁响应数据删除请求，
- 谁调查检索错误。
如果某个来源无人负责，就不应进入生产RAG系统。
要点总结
安全的RAG摄取以最有价值的方式保持平实：它让检索变得可预测。
核心控制包括：
- 登记来源，
- 对数据分类，
- 解析前检查文件，
- 衡量提取质量，
- 保留结构，
- 附加元数据，
- 在检索前执行权限，
- 测试未授权访问，
- 支持删除，
- 指定负责人。
优质答案源于优质来源，安全答案源于良好的来源控制。
