Reducto平台背景与核心能力

Palak Agarwal作为Reducto的开发者关系负责人，首先介绍了公司的定位与成就。Reducto是一个智能文档平台，旨在帮助团队将混乱的非结构化文档转化为AI可准确使用的数据。在过去三年中，公司从包括Accel、Benchmark在内的投资者处筹集了108百万美元资金，并处理超过20亿份文档，客户涵盖Harvey Square及全球前五的对冲基金。Palak指出，虽然让前沿模型处理干净的PDF并不困难，但企业文档大多是非结构化的，包括扫描件、旋转页面和图表等复杂情况。

Reducto作为模型前的处理层，采用基于光栅化的方法模拟人类阅读文档的方式。其核心在于代理OCR框架（Agentic OCR Framework），该机制不依赖单次传递即做出决定，而是让模型标记不确定之处、进行修正后再进入下一步。Palak强调：“我们处理复杂的布局以及后处理，以便您可以专注于构建实际产品。”该平台具备解析、拆分、提取、编辑和分类五大核心能力，为后续的高难度文档处理奠定了技术基础。

JMail项目的起源与规模

JMail项目源于2023年11月爱泼斯坦文件发布后的一个快速原型开发。由Riley Walls和Luke在5小时内构建，最初是Gmail的分叉版本，允许用户以爱泼斯坦的身份登录收件箱。随着时间推移，该项目扩展为包含J Drive、J Flight、J Amazon等在内的完整套件。Palak自豪地分享道：“到2月份，已有超过4.5亿次访问和1800万用户获得JMail的访问权限。”

Reducto负责解析所有上传至该平台的文档，数量高达300万页。这些文件包括经过删减的PDF、扫描件以及混乱的政府档案。Palak描述了处理对象的多样性：“这涵盖了从极其复杂的表单和表格到许多人凌乱手写的各种内容。”这一庞大的数据处理量不仅验证了Reducto的技术稳定性，也使其成为JMail生态系统的核心支撑。Palak随后将技术细节的讲解权移交给联合创始人兼工程师Omar Alhait。

手写文档解析的技术挑战与解决方案

Omar Alhait回顾了项目初期的技术瓶颈。他提到，团队在思考如何利用Reducto应对这一文化转型事件时，与Kino的创始人Luke进行了讨论。Omar回忆道：“我们都在谈论构建什么会很有趣……然后这个想法像滚雪球一样发展起来，即如果我们可以假装自己是杰弗里·爱泼斯坦登录电子邮件会怎样。”然而，从概念到产品化之间存在着巨大的技术障碍，即文档解析的准确性问题。

Omar特别指出封面页（Cover Sheet）是一个典型的复杂案例，他建议观众亲自尝试：“我敦促你们如果没有做过这件事，就把这个封面页发送给ChatGPT并看看结果有多准确。”他解释说，“这是一个非常复杂的问题，布局很难理解，阅读顺序也具有一定的主观性。”为了克服这一瓶颈，团队开发了专门的配置来解析爱泼斯坦及其关联人的飞行记录（J Flight）。这些记录多为潦草的手写文档，对OCR技术提出了极高要求。

解析流程演示与精度验证

Omar展示了Reducto在J Flight项目中的具体工作流程。为了提取爱泼斯坦及其关联人的飞行历史，团队需要将文档解析后应用特定的提取配置（Extraction Config）。Omar演示了Reducto Studio的自助服务功能，用户可以将任何文档放入画布并点击运行，“配置我们所有的功能和特性，查看实时结果。”这一过程允许工程师在大规模扩展之前进行小规模测试。

在处理过程中，团队需要应对各种干扰因素，如文档中的删减部分（Redactions）。Omar以涉及伍迪·艾伦（Woody Allen）的文件为例，展示了系统如何处理敏感信息遮挡下的文本提取。他强调：“我要确保我们的提取准确性符合我的预期。”通过这种迭代式的配置调整，Reducto成功解决了手写体和复杂布局带来的解析难题，为JMail及其衍生应用提供了可靠的数据支持。

快速提取基础设施的压力测试

在应对Epstein文件（JMail）这一大规模文档解析任务时，Reducto团队采用了统一的提取Schema来处理多种用例。这种单一架构的高效性使得文档解析能够极速完成，但同时也给后端基础设施带来了巨大压力。在首批文件发布的那个夜晚，演讲者因高频次的解析请求多次深夜呼叫值班工程师Alvin。由于系统承受了极高的负载压力，Alvin不得不通过消息提醒演讲者“慢一点”。尽管过程紧张，团队最终在截止时间内成功完成了所有文档的解析工作。这一经历证明了该平台在处理突发高并发任务时的稳定性与可扩展性，为后续产品化奠定了坚实基础。

从基准数据到多产品线衍生

一旦建立了经过验证的文档语料库作为“Ground Truth”（基准真相），Reducto团队便迅速将其转化为多种不同的产品形态。演讲者提到，基于同一套解析成果，他们衍生出了包括Jazm、Jlights、Gemini以及他亲自参与的JCAL在内的众多产品。这种“一次提取，多次复用”的策略极大地提升了研发效率。核心逻辑在于简化部署流程：用户只需将文档输入平台，即可立即开始数据可视化并快速投入生产环境。通过直接调用API或运行Pipeline代码片段，开发者可以即时获取结构化数据。这种极简的工作流设计是Reducto产品的核心优势，旨在让用户无需复杂配置即可实现从非结构化文档到可用数据的快速转化。

Schema生成的两种策略对比

在互动环节，演讲者演示了如何通过创建新的提取Pipeline来解析简历（Resume），并重点探讨了Schema生成的两种模式。第一种是“开箱即用的快速生成”，通过简单的LLM调用直接根据用户描述构建JSON Schema。这种方式适合需要迅速看到结果的场景，但可能缺乏对文档细微之处的捕捉。第二种是“增强型Schema生成”（Enhanced Schema Generation），建议用户先解析部分文档，让系统理解文档的具体内容和语境后，再针对性地优化Schema描述。演讲者强调，如果追求对文档细微特征的精准捕捉，应先运行解析再增强Schema；若仅求速度，则直接使用快速生成即可。这种灵活性使得平台既能满足紧急需求，也能适应高精度要求。

数据隐私与红标处理的严肃性

针对用户关于“加载状态”和数据处理准确性的疑问，演讲者深入解释了PDF元数据解析中的红标（Redaction）问题。他指出，简单的视觉遮挡并不等于真正的数据删除。在Epstein文件中，部分红标处理存在严重缺陷，导致敏感信息未被彻底清除。这给JMail团队带来了巨大的合规与法律风险。由于原始红标质量参差不齐，团队不得不重新进行严格的二次审核和清理工作。演讲者强调，处理此类数据时责任重大，必须确保所有意图被红标的信息真正消失，以避免潜在的法律纠纷。Reducto工具在处理这些复杂文档时表现出的高精度解析能力，反而凸显了原始红标工作的不足，迫使团队投入更多精力确保数据隐私的绝对安全。

复杂Schema的嵌套限制与扩展能力

在文档解析领域，面对包含数百个字段的复杂数据结构时，系统的Schema（模式）设计至关重要。演讲者指出，曾遇到过包含 156个字段 的Schema案例，这些字段往往指向完全不同的数据需求。为了应对这种复杂性，Reducto对Schema的嵌套层级进行了限制，通常建议控制在 4到5层 以内。尽管有此限制，系统仍具备高度的灵活性，允许用户请求尽可能多的信息，技术上仍能将其适配进Schema中。这种设计旨在平衡结构的清晰度与数据的完整性。

"I urge you to kind of put our schema to the test... maybe like four or five layers. But in if you want, you know, ask for everything in the world, you can still technically be able to fit it in a schema."

这种架构允许用户在保持逻辑清晰的同时，获取详尽的数据输出。对于需要处理海量异构数据的场景，这种 有限的嵌套深度 既防止了结构过于臃肿导致解析错误，又通过扁平化或浅层嵌套的方式保留了数据的丰富性。用户被鼓励亲自测试这一特性，以验证其在实际复杂文档处理中的表现。

实体解析与引用定位的后处理机制

在数据提取之后，实体解析（Entity Resolution） 是确保数据可用性的关键环节。Reducto在提取阶段后进行了大量的后处理工作，主要目的是将分散的数据片段关联起来。例如，系统使用专门的 引用模型（Citation Model） 来确定提取出的每一条数据源自文档的哪个具体位置。这一过程解决了从非结构化文本中精准定位来源的瓶颈问题。

演讲者提到，Nvidia近期发表了一篇关于此问题的论文（可能名为 "Find Everything"），旨在解决文档中引用确定的速度瓶颈。Reducto的技术团队也在这一领域深入探索，通过模型协作来优化数据溯源的准确性。这种 提取与定位分离 的策略，使得系统不仅能知道“是什么”，还能清楚指出“在哪里”。

"We are doing a decent amount of post-processing to basically link um you know entities together... we have like a citation model, right? Where we know we have one model that could be responsible for extraction... and then there might be another model that's also responsible for once this data is extracted, where is each piece kind of extracted from."

混合OCR技术与图像内容的智能处理

针对包含图表或图像的文档，Reducto采用了 混合OCR模型（Hybrid OCR Model） 来智能决定处理优先级。系统并非单一依赖光学字符识别，而是根据文档类型动态调整策略：有时优先提取严格的OCR数据以保留视觉信息，有时则侧重从PDF元数据中提取结构化文本。这种 智能优先级配置 解决了传统OCR在处理复杂版面时的局限性。

在演示中，演讲者展示了如何通过重新运行解析流程来返回图表信息。这一功能依赖于底层对文档结构的深入理解，能够区分正文与插图区域。对于数学教科书等包含大量公式和图表的文档，系统会先解析整体结构，识别章节起止点，再针对每个区域进行特定的提取任务（如生成章节摘要）。这种 分治策略 使得Parse成为后续所有智能文档处理功能的基础。

"We have a specific OCR uh like you know configuration that you can enable here that will pri figure out kind of intelligently what to prioritize... in some cases we will actually pick out like just you know strict OCR data or we might pick out like um you know metadata from the PDF."

基准测试策略与行业评估现状

关于模型性能的量化对比，Reducto承认目前缺乏统一的行业标准基准。演讲者指出，大多数客户在评估文档提取服务时，通常会 自建基准测试集 进行点对点（Head-to-Head）比较。由于不同客户对API的使用方式和配置参数各异，直接对比往往存在偏差。因此，Reducto倾向于与客户紧密合作，指导其优化配置以发挥模型最大潜力。

虽然公司自信其为市场领先的文档提取解决方案，但承认需要更多 行业可见的数据点 来支撑这一主张。未来几个月，Reducto计划发布一些基准测试结果，以展示其性能优势。然而，核心观点是：在缺乏统一标准的情况下，用户仍需通过系统性测试（如从简单的视觉评估扩展到数百份文档的系统性验证）来确认最佳方案。

"Benchmarking is like something that you know we're prioritizing a lot... especially because somebody who is testing who wants to do document extraction might not know where to go or who's better right without actually testing themselves."

"The real deeper answer here is you typically have to make your own benchmarks unfortunately... gather a simple data set you can do some like vibe eval just look in studio see if the outputs make sense and then as you want to scale it out then get 100 documents a thousand documents do something more systematic."

产品形态：从粗糙原型到行业通用解法

在探讨如何将Reducto的解析能力产品化时，演讲者坦诚地表示初期方案相当简陋。最初构建的是一个基于RAG（检索增强生成）的聊天机器人应用，允许用户询问关于邮件的任何内容。虽然这种形态对记者群体可能极具价值，但面对海量数据时显得力不从心。演讲者指出，对于数百万甚至数千万用户而言，单纯的技术提取不足以构成完整产品。以Gmail为例，其庞大的用户基数证明了在优秀的文档提取解决方案之上构建良好的用户体验产品才是关键。这种“组合拳”模式不仅适用于Gmail案例，更是整个行业处理非结构化数据的真实写照。用户不需要手动扫描数百万份文档，而是通过工具快速检索和提取信息。非结构化数据无处不在，核心在于如何高效提取并灵活应用。

结论

Reducto通过代理OCR框架与混合处理策略，成功解决了JMail项目中300万页复杂文档（含手写、删减及混乱布局）的高精度解析难题，验证了其在高并发压力下的系统稳定性。其核心优势在于“一次提取、多次复用”的架构及实体引用定位能力，显著提升了从非结构化数据到可用数据的转化效率。

然而，该技术并非万能。面对红标缺陷需人工二次审核以规避法律风险；Schema嵌套存在4-5层限制以防结构臃肿。此外，行业缺乏统一基准测试标准，性能评估依赖客户自建数据集进行点对点比较。最终结论表明：单纯的技术提取不足以构成完整产品，必须在高精度解析之上构建优秀的用户体验与合规机制。