大家好，我是Ple。我在Reductto担任开发者关系负责人。在深入探讨JMail之前，我想先给大家介绍一下我们的背景。我们是一个代理文档平台，简单来说，就是帮助团队将杂乱无章的非结构化文档转化为AI能够准确使用的数据。为了给大家一些背景信息，在过去三年里，我们从Accel、Benchmark等投资者那里筹集了1.08亿美元，并处理了两亿多份文档，客户包括Harvey、Scale以及一家全球前五的对冲基金。
在这个规模下运营意味着我们基本上处理过你能想到的每一种文档类型。我们也不断迭代Reductto的产品，以应对各种情况。现在，让AI在干净的PDF上使用前沿模型并不困难，但事实是大多数企业文档都是非结构化的。这意味着包括扫描文件、旋转的文件以及图表等，这时候事情就变得非常复杂了。Reductto是位于模型之前的那一层，我们处理复杂的布局以及后处理工作，让你们可以专注于构建实际的产品。
这种方法之所以有效，是因为我们采用了一种基于光栅化的方法，这意味着我们是像人类查看文档那样去看待你的文件，而不是依赖底层的嵌入表示。这一切都由我们的代理OCR框架驱动，该模型不会只做一次尝试就确定答案，而是标记出不确定的内容并进行纠正，然后进入下一步。我们将为大家开放我们的Studio，这次专门为此会话提供了自助服务功能。
总体而言，我们有五大核心能力：解析、拆分、提取、编辑和分类。现在快速举手示意一下，在座有多少人听说过JMail或浏览过JMail？好的，哇，这占了相当大一部分人。但如果有人还没听说过，我会快速介绍一下。JMail最初是由Riley Walls和Luke在去年11月的五小时内构建的，当时爱泼斯坦文件刚刚发布。
其概念基本上是对Gmail的分叉版本，你可以像登录爱泼斯坦的收件箱一样登录JMail，随后它发展成了一个完整的套件。你可以将其想象为J Drive、JFlight、J Amazon、J Photos等等，功能非常多。到二月份时，访问量超过4.5亿次，有1800万用户能够访问JMail。我们非常自豪地分享说，Reductto负责解析了所有的文档。
这不是一个小数目，包括超过300万页的删减版PDF、扫描文档以及混乱的文件。为了让大家有个概念，这些文件涵盖了从极其复杂的表单和表格到众多不同人的凌乱手写笔记等各种内容。现在，我将把时间交给Omar，他是我们的一位创始工程师，去年11月与Jail团队紧密合作。他将为大家进行更详细的技术讲解。
大家好，准备好聊聊文档了吗？太棒了。好的，让我们回到去年11月那个命运攸关的夜晚。当时我正在与创始团队交谈，我们试图找出一种利用Reductto处理这种即将向公众揭晓的变革性文化事件的绝佳方式。碰巧的是，我们与Kino的一位创始人Luke关系非常密切，他就在一楼工作，我们当时都在讨论构建什么会很有趣。
这个想法逐渐演变成：如果你能像杰弗里·爱泼斯坦一样登录邮箱并查看他的邮件，那会怎样？作为一个产品概念非常酷，但有一个很难解决的问题阻碍了我们实现这一目标。大家看这张封面页，如果你以前没试过，建议把它发给ChatGPT看看结果如何，你会发现准确率并不高。这是一个非常复杂的问题，布局难以理解，阅读顺序也具有一定的主观性。
因此我们需要解决这个瓶颈，以便开发下游的这些酷炫产品，Reductto就此登场。接下来我将向大家展示我们之前用于几个产品的工具。好的，让我快速演示一下。哎呀，把它调出来。好了，大家看这个酷炫的产品JFlight。基本上展示了杰弗里·爱泼斯坦及其关联人的飞行历史，他经常飞往各地以及他的岛屿。
阻碍我们发现这些航班信息的主要障碍是那些质量很差的手写文件。如果你觉得刚才那张封面页已经够棘手了，那就想想手写体吧。这里展示了一个我很久以前设置的管道，当时我们试图建立一个好的配置以使解析效果最佳。在这个航班案例中，有一个想法是将此分离为一个独立的产品，让大家可以直接查看他的所有飞行记录。
这意味着提取他所有的航班文档并应用单独的提取配置。接下来我将简要介绍Reductto的工作原理：在文档提取用例中，首先解析文档。你可以将任何想要的文件放入这里并点击运行，配置我们的各种功能以查看实时结果。这是我用来在扩展处理一百万份不同文档之前进行快速检查的画布，以确保提取准确性符合预期。
这里是我们最终得到的结果。大家可以看到其中几份文件有一些我们需要处理的删减内容，比如伍迪·艾伦……
就像我们之前提到的，许多用例都需要通过单一的提取模式来处理。以航班信息为例，我们非常快速地解析了所有文档。这里有个有趣的故事：Alvin在房间里吗？他在的。回想起来，当第一批文件发布时，我每晚可能要给Alvin打几次电话，因为他刚好在那天晚上值班。当时我们正在争分夺秒地解析这些文档，给基础设施带来了相当大的压力。所以深夜里Alvin给我发了一些有趣的消息，比如：“嘿兄弟，你能慢点吗？”但我们最终还是按时完成了任务。
当我们拥有了这样一批可以作为“地面真值”的文档语料库后，我们衍生出了数十种不同的产品。Paula刚才稍微提到了这一点，但我还是要回到Gmail的话题。我们推出了从Jazm到Jlights再到Gemini等各种产品，还有JCAL——这是我亲自参与开发的产品。如果要从这次分享中汲取一个核心要点的话，那就是简洁性：获取模式、检查结果是否符合预期，然后直接部署。
如果我部署这段代码片段——我就在这里重新演示一下我们的用例——我可以直接进行API调用，或者使用一段可以快速调用的管道代码片段。这里的核心理念是：将文档输入平台，然后立即开始可视化数据，并随后将其投入生产环境。我就先讲到这里。关于JMail或Reducto的一般情况，大家还有什么问题吗？在开始互动练习之前。
是的，这是个很好的问题。我们可以为您生成这个模式。我的类比是：您的提取模式就像Reducto画布上的画笔，它决定了您从模式中得到的所有内容。例如，我可以创建一个新的提取管道并调用一个简历模式来解析一些简历——哦抱歉，我马上演示一下。这很简单：我会在这里创建一个新的提取管道。我们可以对文档做很多事情，比如拆分、提取、编辑甚至分类。
好的，我得到了一个有趣的模式。现在轮到我决定这个模式是否令人满意了。它会根据我的要求精确输出结果，但当我插入文档后，我可能会发现这并不是我想要的。所以我有一堆现成的简历要上传并运行测试——希望这回答了你的问题，还有其他问题吗？在等待结果时。
你是指加载状态吗？那只是一个有趣的加载提示，毕竟我们的产品是一系列部署的不同模型和视觉语言模型（VLMs）。抱歉，我没跟上你的思路。哦，这是个很好的问题！如果我理解正确的话……是的。这种特定的模式生成是我刚才使用的开箱即用功能，它只是一个快速的LLM调用，根据我的描述构建JSON模式。
不过我们也有增强型模式生成功能。它的做法是：假设我已经解析了文档，它会取文档中的输出结果，并直接为其定制模式描述。例如，如果你只想快速看到一些结果，我建议用常规的模式生成；但如果你对细微差别更感兴趣，我绝对建议先解析文档再传入。你只需要点击“增强模式生成”。我们会先运行文档，了解其中的内容，从而量身定制这些模式描述。明白了吗？
很酷。你刚才提到了减少（reduction）的问题，对吗？是的。Reducto实际上也会解析PDF元数据。有时候这确实能反映出谁进行了删减操作，而且有时删减做得并不好。因此，作为JMail团队，我们不得不进行大量的额外删减工作。你不能只是在PDF上画个框就指望它被完全删减干净，这显示负责删减的人可能缺乏理解。
对于发布出来的文件，我自己查看时发现情况并非全是如此——有些文件的删减是正确的；但也有些文件中我们能看到是谁进行了删减，这变成了一个非常严肃的问题。因为我们在处理人们的敏感数据，我们的数据被删减是有原因的。你绝对不想最后因此惹上诉讼麻烦。所以我们要承担很大的责任，确保所有意图删减的内容都被真正删除了。我们的工具工作得有点太好了。
对于成千上万种不同的情况，确实如此。这是一个很好的问题。让我举一个例子吧。比如我在周五看到的一个模式（schema），它包含了156个字段，所有这些不同的字段所请求的内容完全不同。所以我建议你们去测试一下我们的模式。我认为我们模式的嵌套限制大约在四到五层左右，但如果你想要获取世界上所有的信息，从技术上讲仍然可以将其适配到一个模式中。
你提到实体解析（entity resolution），能举个例子吗？这是一个好问题。我们在后处理方面做了大量工作，特别是在提取环节。我个人离机器学习底层稍远一些，但我可以告诉你们，我们进行了大量的后处理工作来将实体关联起来。例如，我们有一个引用模型（citation model）。我们知道可能有一个模型负责提取数据，但随后可能有另一个模型负责确定每条被提取的数据具体来自文档的哪个部分。
英伟达（Nvidia）最近发表了一篇我很感兴趣的论文，叫做“Find Everything”之类的名字。他们试图解决引用确定的瓶颈问题以及查找文档中某处引用的速度问题。如果你对这方面感兴趣，我们正在招聘，欢迎会后与我们交流。接下来是提问环节吗？是的，当然可以。
让我看看我上传的简历中是否包含图片。我们有一些图像模型（figure models），主要用于确定……让我重新运行一下，以便它能返回图表信息。这是一个很好的问题。阿尔文（Alvin），你听到了吗？没有，让我解释一下我问阿尔文的原因是因为他负责我们的混合OCR模型。
我们有一个特定的OCR配置可以启用，它能智能地决定优先处理什么。在某些情况下，我们会提取严格的OCR数据；而在其他情况下，我们可能会从PDF中提取元数据。在这方面我们做了很多工作，这并不是一个简单的答案，甚至值得单独开一场讲座来讨论。
坦白说，这正是我们流水线正在做的事情。首先进行解析……让我开启图表返回功能。好的。在我重新运行演示时，我们正在做的是将解析结果输入到下游的提取流水线中。“Parse”（解析）是Reducto最初实现“简化”的核心所在，而在其下游我们可以做很多有趣的事情。
例如，一旦我们获得了解析内容，就可以将文档划分为不同的区域，并确定如数学教科书等内容的章节起止位置。针对每个章节，我们可以基于此进行提取，获取章节摘要等内容。因此，“解析”是所有这些其他智能文档处理功能的基础。
如果我回答这个问题，我明天可能就会失业。（笑声）嗯，请继续。我认为这取决于我们收集的训练数据类型。如果我们发现模型在某些特定数据类型上表现不佳，比如长上下文召回率不高，我们就必须尝试修复它。
对于提取任务来说，这不仅仅是“大海捞针”，而是真正的“在干草堆里找针”。这是一个极具挑战性的研究问题，但我们的机器学习工程师们似乎解决得相当不错。很高兴稍后能进一步交流。是的。（笑声）哦，我们忽略你们了。
大家应该持续关注我们的社交媒体账号，很快就会有消息发布。基准测试（benchmarking）一直是一个讨论热点，也是我们要重点关注的领域，因为想要进行文档提取测试的人可能不知道从何入手或谁更优秀，除非亲自进行测试。
因此，基准测试是我们近期优先推进的工作之一，旨在展示我们的性能表现。我们对模型非常有信心，自认为是市场上领先的文档提取解决方案。但我们需要更多的数据点作为支撑，让行业无需亲自测试或输入整个ARC AGI数据集就能直观地看到Reducto与其他解决方案的对比结果。
是的，我们很快会发布一些基准测试结果。但更深层的答案是：通常你必须建立自己的基准测试。我们的每个客户通常都有自己的评估标准，他们会进行红托（Reducto）与其他竞争对手的直接对比。有时他们可能没有很好地使用我们的API，比如配置错误。
我们会与他们密切合作，指导他们开启特定功能以获取最佳权衡效果，然后由他们自行决定。在这些直接对比中，我们通常在性能上胜出。与大多数项目一样，你可以先收集一个小型数据集进行初步评估（vibe eval），在Studio中查看输出是否合理；当需要规模化时，再使用数百甚至数千份文档进行更系统的评估。
我们团队有很多人与客户合作，帮助您处理邮件。是的……还有更多问题吗？当然有。好吧，确实如此。嗯，我会很诚实地回答这个问题。我想当我在开发这个解决方案时……或者说我在解决这个问题的过程中，我试图弄清楚如何将我们的 Reducto 解析功能产品化。老实说，起初我想出的方案相当粗糙……基本上就是一个 RAG（检索增强生成）聊天机器人应用，您可以询问关于邮件的任何问题。这也许对记者这类人群非常有用……
然而，我想这也证明了数以亿计的用户使用 Gmail 的事实，以及如今仍有数千万用户每周登录。这证明了一点：在优秀的文档提取解决方案之上构建一个精美的产品，将形成强有力的组合拳。是的……你会去阅读三百万份扫描文件吗？老实说，不会。当我看到数据量时，我觉得这对我来说工作量太大了。
但一旦 Omar 把它构建出来，我就登录并开始随机搜索一些名人取乐。这就是它的美妙之处……我认为非结构化数据无处不在。有时你所需要做的就是提取它们，然后随意使用这些数据。这在概念上基本上就是我们要做的所有事情。所以我认为 Gmail 是一个很有趣的例子，但它实际上非常……它完全符合行业内的实际情况。
是的。你看到了吗？过来吧。这仅仅是因为工作艰难……你知道，我们有一个数据标注团队。如果我们要在此基础上训练新模型，我们必须 sift through（筛选）大量文档……并且必须对结果或数据的完整性非常确定。所以简短的回答是……是的，这是一项大量枯燥、繁琐且令人厌烦的工作。
但这正是机器学习模型最终魅力的体现……没有什么能比得上这种极其硬核的分类工作，它会累积起来用于模型训练。然后你可以弄清楚如何交错安排数据……以及如何基于你的训练集进行训练。归根结底，你仍然需要标注这些数据。酷。我想我们可以继续……是的，我们还能再提一个问题，但是嗯……
好的。所以，重复一下这个问题……并让我知道它的准确性如何？但看起来，在某些情况下，你需要在不同的文档之上定制你的逻辑。无论是针对特定模型……有时某些文档中会以特定方式设置元数据，而你希望真正为这些特定用例进行条件配置。这是一个很棒的问题……
这就是我们的代理（Agentic）部分发挥作用的地方。你可以应用所有这些不同的配置，并在单独的模型上应用系统提示……这些模型将执行专门针对你需求的特定处理。例如，如果你想进行复杂的图表提取……假设我有一堆徽标，我想尝试确定像林肯金融和谷歌这样的不同徽标的区别……以及如何区分这些类型的徽标。
我可以在我们的配置中的提示里添加一些额外的颜色信息……以自定义定制我所期望的输出。所以如果你想要某些特定的元数据，比如布局在某些建筑蓝图上可能很难阅读……我会花很多时间在布局提示中进行调整……试图了解我当前的提取解决方案在我的不同建筑蓝图上的映射效果如何。酷吗？这回答你的问题了吗？太棒了。
好吧，现在我们要把这个转变成一个互动练习。所以，如果你们愿意的话……我们会给你们足够的时间。我想我们还有大约 30 分钟。你可以在 studio（工作室）注册，基本上开始使用文档提取解决方案……你会在这里看到一个二维码，你可以直接将其粘贴到 Cloud Code 或 CodeEx（代码执行环境）中……立即开始文档提取。
我们会给你们大约 30 分钟的时间，在剩下的五分钟时……我们很想看看你们完成了什么。我们会准备很多很酷的周边产品和几个奖品，让你们展示在文档提取方面的工作成果……这可以完全只是一个想法和一个单提示（single-shot prompt），但请随意尝试一下。听起来不错吗？
此外，如果你们对如何使用 Reducto 有任何疑问……或者你想加入我们、了解你们的模型和训练方式等，我们很乐意回答。听起来不错吗？