文档处理公司 Reducto 创始工程师 Omar Alhait：PDF 遮蔽框下的数据仍可被提取

2025 年 11 月，美国众议院监督委员会公开了爱泼斯坦案相关文件。JMail 团队——由 Riley Walls 和 Luke Igel 在发布当晚用五小时搭建——把这些文件做成了一个可以像登录邮箱一样浏览的界面，随后扩展出 JFlights、JDrive、JPhotos 等应用。Reducto 负责解析其中超过三百万页文档，包括遮蔽 PDF、扫描件、复杂表格和大量不同人的手写记录。

Reducto 创始工程师 Omar Alhait 在 2026 年 AI Engineer 世界博览会上描述了一个他在处理飞行日志时遇到的意外：部分 PDF 中画了黑色方框遮蔽文字，但 Reducto 同时解析 PDF 元数据，而不仅仅是渲染后的图像。黑色方框在视觉上遮住了内容，底层的文本数据仍然完整可读。Alhait 的原话是你不可能在 PDF 上贴一个方框就期望它真的被完全遮蔽了。他进一步说明，有些文件的遮蔽确实做对了，有些则没有——这取决于原始文件的制作者是否真正理解了 PDF 的图层结构。

对 JMail 团队来说，这意味着他们必须自己再做一层遮蔽处理，确保原本应被隐去的信息在最终产品中同样不可见。Alhait 用一句话概括了这个困境：我们的工具工作得有点太好了。

提取能力越强，越容易违反文档本身的披露意图。

这个失败模式之所以在演示中容易被掩盖，是因为少量样本通常看不出问题。Alhait 回忆，在首批文件公开的那个夜晚，他为了尽快完成解析而全力推送吞吐量，结果反复触发了基础设施告警，值班工程师 Alvin 在深夜给他发消息说兄弟，你能不能慢一点。小规模的 Studio 测试能验证单篇文档的提取结果是否合理，但无法暴露三百万页语料在并发、格式多样性和遮蔽一致性上的真实表现。

Alhait 给出的评估路径分两步：先用少量文档在 Studio 中做直观检查（他称之为 vibe evals），确认输出看起来合理；然后扩展到一百或一千篇相关文档，用适当的配置做系统评估。他特别强调，配置本身影响评估结果——客户可能用不合适的 API 设置测试一个供应商，得到的数字并不代表该供应商在正确配置下的表现。因此有意义的比较必须包含实际使用的处理设置，而不仅仅是供应商名称。

在解析与提取的关系上，Alhait 说明 Reducto 的管线是先解析（恢复文档结构），再提取（按 schema 请求特定字段）。解析输出成为提取的输入，这一分离使得中间操作成为可能：例如对一本数学教材，先解析内容，再按章节边界切分，最后对每一章分别执行提取以生成章节摘要。提取 schema 是画布上的画笔——它决定系统返回什么，但正确性仍取决于能否从文档中实际提取出所请求的信息。

关于 schema 生成，Alhait 区分了两种方式：常规生成仅基于用户请求，通过一次快速 LLM 调用构建 JSON schema；增强生成则先解析文档，再根据文档实际内容定制字段描述。后者让 schema 更接近真实材料的结构，但增强生成本身不能确立跨语料的提取准确率——这仍然需要后续的系统评估来验证。

需要保留的边界：以上全部是 Reducto 团队对 JMail 项目的经验描述，不是独立基准或性能证明。团队在对话中拒绝透露解析和提取使用的具体模型，也未提供比较结果或评估协议来确立其声称的性能优势。遮蔽问题反映的是特定政府文件的处理方式，不能推广为所有 PDF 遮蔽的普遍缺陷。评估建议（先少量检查再系统扩大）本身接近工程常识，其增量价值在于与具体失败案例的绑定——吞吐量压力、配置依赖的评估失真和遮蔽穿透——这些只在规模化时才同时出现。