Databricks Document Intelligence 实现实时处理，但准确性成为瓶颈

Databricks 于 10 月 14 日将 Document Intelligence 变为实时服务，把四项文档操作从后台管道带入实时应用和智能体工作流。其新的同步接口让软件能够在用户等待期间解析、提取、分类和路由文件。这使产品从数据准备服务转变为运营组件，但也让每一个错误字段更加接近业务决策。

此次发布瞄准了企业 AI 中一个常见的缺口。企业会收到合同、发票、理赔材料、报告和演示文稿，其中包含应用程序无法直接利用的信息。Databricks 表示，其企业客户每天合计处理数百万份文档，但许多工作流仍依赖人工阅读文件并重新录入选定的细节。

其解决方案是一组 REST API，即应用程序可直接调用的 Web 接口。解析、提取和分类现已正式可用。另一项用于选择下一步操作或路由目的地的决策 API 仍处于 beta 阶段。

竞争关键不在于软件能否读取 PDF。Microsoft、Google、Amazon 以及专业供应商早已提供文档处理 API。Databricks 押注的是，客户会重视从传入文件到受治理数据、智能体操作或人工审核界面的更短路径。

这种整合才是真正的重要事件。但它也带来了核心考验：实时文档处理只有在延迟、准确性、引用、权限和人工审核作为一个整体协同工作时才有价值。

Databricks Document Intelligence 从管道转向实时决策

此次发布将文档处理转变为应用运行时服务，而不只是定时数据管道中的另一个环节。

Databricks 此前重点强调面向文档集合的 SQL 函数和大规模处理。当企业需要为档案建立索引、准备检索数据或分析积压内容时，这些工具仍然很有用。新的 API 则针对另一时刻：文档进入应用程序后的几秒钟内。

根据实时 API 发布公告，应用程序可在文件到达时调用四项操作。每项操作负责工作流中的不同部分。

ai_parse_document 将文件转换为结构化内容。它在保留文本的同时呈现表格和图形，随后返回边界框，以标识信息在原始页面中的位置。

ai_extract 提取由开发者定义的字段，例如发票总额、合同续约日期或索赔人姓名。可选的引用和置信度评分使应用程序能够将每个结果与支撑证据关联起来。

ai_classify 将文档或提取出的项目归入客户业务分类体系中的标签。例如，法律受理系统可能需要区分保密协议、主服务协议或工作说明书。

ai_decide 评估内容并选择下一步操作。该操作可能将文档发送到特定队列、请求人工审核，或引导智能体转向另一项工具。与另外三项操作不同，这一决策接口以 beta 版本发布。

这些 API 共同支持同步工作流，即调用方在继续执行前等待结果。这对于交互式应用很重要。律师可以上传一份合同，并立即获得已预填当事方、日期、续约条款和通知期限的表单。律师可以在批准记录前核实每个值。

应付账款系统也可以遵循类似路径。它可以识别发票、提取供应商和采购订单编号，然后判断该文件是否需要审核。保险门户可以在将理赔附件分配给理算员之前对其进行分类。

这并非 Databricks Document Intelligence 首次亮相。Databricks 于 2025 年 11 月以公开预览形式推出 ai_parse_document，并将其定位为面向企业数据团队、可通过 SQL 访问的解析器。该公司表示，客户当时已经在并行处理数百万份文档。

2026 年 10 月的发布改变了这项能力的部署位置。开发者不再需要让每次交互都等待定时管道，也不必围绕批处理作业构建面向应用的服务。他们可以从软件和智能体工作流中调用同一功能层。

这听起来像是一次小幅接口变更，但在运营层面影响要大得多。批处理流程可以容忍延迟验证和人工清理。实时应用则必须在用户仍在场时决定显示、信任、拒绝或升级哪些内容。

实时 API 将数据平台置于交易路径之中

Databricks 正在要求客户将其湖仓平台放置在文档触发实际业务操作的更近位置。

传统文档管道将摄取与操作分离。文件进入存储，定时流程读取文件，提取的数据最终出现在表格或下游系统中。这一模式适用于分析、档案搜索以及其他可接受数分钟或数小时延迟的任务。

但当文档本身开启一笔交易时，这一模式就不那么适用。供应商希望发票进入审批流程。客户等待理赔进入正确的队列。律师希望在离开受理界面前获得提取出的条款。

同步 API 压缩了这一顺序。它们让应用程序请求文档理解、接收结构化响应，并在一次交互中继续执行。这种架构可以减少团队此前在文档解析器和业务应用之间维护的定制服务。

Databricks 还将 API 层与其更广泛的平台连接起来。其处理文档描述了使用相同底层函数的三种方式：可视化 Agent Bricks 界面、SQL 函数和 REST API。

这种一致性很重要，因为实验系统和生产系统往往会出现分歧。团队可能在可视化工具中验证架构，通过 SQL 处理历史文档，然后在应用程序内暴露相同的提取行为。使用相关接口可以减少这些阶段之间的转换工作。

该平台还为结果提供了共同的目标位置。解析后的内容可以流入 Delta 表、搜索索引、仪表板或智能体。Unity Catalog 可以对文档工作流产生的数据应用访问控制、治理和血缘追踪。

这给独立文档处理技术栈带来了压力。许多企业目前组合使用云存储、光学字符识别、提取模型、路由代码、向量数据库和应用服务。每一项连接都会增加身份边界、重试策略、数据副本和可观测性界面。

Databricks 并未消除这些工程要求。它的观点是，其中更多部分可以置于同一个受治理环境中。对于已经在那里运行数据和 AI 工作负载的客户而言，整合的价值可能比解析基准上的细微差异更有分量。

同一策略也让 Databricks 与主要云平台展开竞争。Google Document AI 可以将文档数字化、提取实体、分类文件、拆分复合文档包，并将结果与其他 Google Cloud 服务连接。它为不同文档类型提供专用处理器和自定义模型。

Azure 文档模型涵盖文本、布局、表格、键值对、预构建业务文档、自定义提取和自定义分类。Microsoft 还将这些能力与其更广泛的应用和 AI 平台相结合。

Amazon 为单页文档的近实时分析提供同步 Textract 操作，同时建议将多页处理转向异步工作流。其同步处理涵盖文本检测、文档分析、费用分析和身份证件使用场景。

因此，Databricks 进入的是一个成熟类别。其优势必须来自周边系统：受治理的企业数据、应用程序、智能体、分析和文档操作共享同一个控制平面。

其机制是解析、核验、分类，然后行动

该产品最重要的设计选择不只是提取，而是围绕每个提取值提供的证据和控制机制。

文档智能体不能安全地将每一个模型响应都视为事实。合同包含嵌套条款。发票采用不一致的版式。理赔材料中混有不同附件、手写备注和低质量扫描件。即使是很小的提取错误，也可能改变付款、期限或路由结果。

Databricks 通过返回的不只是纯文本来应对这一问题。其解析器呈现表格、图形、页面结构和空间信息。边界框标识与输出关联的区域，使界面能够在源页面上高亮支撑材料。

提取还可以包含引用和置信度评分。引用会告诉审核者该值的来源。置信度评分则估计系统对该值的确定程度。两者都不能保证正确性，但都能帮助开发者构建审核策略。

以合同受理应用为例。系统首先将文件解析为结构化内容。分类功能识别协议类型。提取功能请求当事方、日期、续约条款和通知期限。随后，应用程序将这些字段与源引用一并展示给律师。

工作流不应对每个字段一视同仁。置信度较低的公司地址可能很容易修正。置信度较低的终止期限则可能需要强制审核，因为其业务后果更严重。

同样的原则也适用于发票。应用程序可能自动接受已识别的供应商名称，同时将与采购订单数据冲突的总额升级处理。最佳工作流会将模型输出与业务规则及权威记录相结合。

这正是湖仓定位变得有意义的地方。解析后的文档不必与结构化数据隔离。提取结果可以在智能体继续执行前，与供应商记录、理赔数据库、客户账户或合同清单进行核对。

智能体又增加了一层。智能体可以决定调用哪个 API、解读返回的结构、查询其他系统并提出操作建议。但每增加一步，故障面也会扩大。即使提取正确，如果智能体使用了错误的策略或工具，仍可能导致错误决策。

Databricks 将 Agent Bricks 描述为其用于构建和治理基于业务数据运行的智能体的环境。其 2026 年 4 月的智能体平台更新强调了身份、权限、模型访问、编排和可观测性。

这些能力让文档 API 承担了更广泛的角色。Document Intelligence 不再仅仅充当解析器，而成为智能体能够在更长流程中调用的工具。采购智能体可以读取发票，将其与订单进行比对，识别差异，并将案例发送给正确的审批人。

对于会产生重要影响的工作，人工检查环节仍然不可或缺。人类参与审核意味着，系统执行操作前由人员检查选定的输出结果。当软件提供聚焦的证据，而不是要求某人重新通读整个文件时，这种做法最有价值。

这种方法类似于设计良好的 AI 知识库。价值不在于存储更多文本，而在于保留来源信息、访问规则，以及足以判断答案所需的上下文。

更快的结果也让错误更快产生影响

将提取功能纳入实时工作流能够缩短等待时间，但也压缩了在错误影响其他系统之前发现它们的时间窗口。

Databricks 尚未针对这些新的同步 API 发布独立、特定工作负载下的准确率结果。该公司此前表示，ai_parse_document 以低于领先系统的成本实现了具有竞争力的质量。这些说法部分基于内部基准测试，因此买方应将其视为公司主张，而非普适性结论。

文档准确率会随输入分布而变化。干净的数字生成发票与拍摄的收据表现不同。格式一致的合同模板，比数十年积累的扫描协议更容易处理。表格、手写内容、页面旋转、印章和重叠标记都可能影响结果。

因此，真正的评估单位应是客户自身的文档集。团队应测试有代表性的文件，包括损坏的扫描件、非常规布局、多语言内容、长文档和罕见类别。平均准确率可能掩盖最关键案例中的严重错误。

按字段评估也比一个总体分数更有用。系统可能能够可靠识别供应商，却难以处理手写总额；也可能正确分类标准协议，却混淆不常见的修订条款。这些差异应决定自动化可被允许应用在哪些环节。

延迟同样需要仔细审查。“实时”描述的是一种交互模式，而不是每个文件都能获得相同响应时间的保证。单页发票、包含图表的演示文稿和长篇合同，对处理能力的要求各不相同。

应用设计者必须决定处理耗时过长时应如何应对。界面可以让用户继续等待、返回部分结果、将任务移入队列，或请求稍后复核。每种选择都会影响用户信任和系统复杂性。

可用性是另一项问题。当文档处理成为交互路径的一部分时，API 中断可能会阻塞接收流程，而不只是延迟后台任务。生产系统需要超时机制、重试规则、幂等性和备用队列。

ai_decide 的 Beta 状态尤其值得关注。解析和提取信息属于边界明确的任务；决定下一步如何处理，则将模型解读与业务权限连接起来。这是更大一步的治理挑战，尤其是在法律、金融、医疗保健或保险工作流中。

审慎的设计会将建议与执行分离。决策服务可以提出路径建议，但确定性规则应强制执行权限和高风险约束。当证据不足或操作可能带来实质性后果时，仍应保留人工审批。

安全性声明也需要谨慎解读。Databricks 表示，Document Intelligence 会将客户数据保留在工作区和所在区域内，不会将其存储用于模型训练，并继承 Unity Catalog 的治理能力。买方仍需核实其配置下的区域可用性、审计要求、保留设置和合规义务。

竞争对手也面临类似权衡。Google 根据处理器分别规定同步和批处理请求的限制。Microsoft 提供多种模型和部署选择，各自支持不同的输入类型并具有不同的生命周期。AWS 则区分同步单页操作和异步多页处理。

这些差异意味着，任何通用基准测试都无法选出正确的系统。买方需要在同一工作负载上评估字段准确率、分类质量、响应时间、审核工作量、故障恢复能力和集成成本。

核心竞争在于集成控制与专业化服务之争

Databricks 以工作流整合参与竞争，而云服务商和专业供应商则可凭借成熟的处理器、更广泛的模板或更深入的文档专业能力应对。

Microsoft、Google 和 Amazon 已占据稳固位置，因为它们的文档服务与存储、身份、无服务器计算和应用基础设施紧密相连。已经深度投入某一云平台的客户，可能更倾向这些原生连接，而不是将工作流迁移到另一个平台。

Google 提供 OCR、表单、布局、分类、拆分和行业文档处理器。其 Enterprise Document OCR 支持超过 200 种语言，而在线与批处理的页面限制则因处理器而异。这些细节对于全球化和高吞吐量部署至关重要。

Microsoft 提供发票、收据、合同、身份证明文件、金融表单和税务文件的预构建模型，同时也支持自定义提取和分类。当用例与现有模型高度匹配时，这个目录可以减少配置工作。

对于文件和应用已经部署在 AWS 上的组织，Amazon Textract 仍具有重要意义。其同步与异步接口的组合支持不同的延迟和文档大小要求，不过团队可能还需要额外服务来实现更广泛的智能体编排。

专业供应商可通过领域聚焦来竞争。专为保险理赔、抵押贷款材料或应付账款设计的产品，可能已包含验证规则、审核界面和运营集成，而通用数据平台未必开箱即用地提供这些能力。

Databricks 采取了相反的方法。它希望文档智能像平台原语一样运作。团队可以通过可视化界面、SQL 或 REST 使用同一组能力，也可以将提取字段与受治理的表关联，并将结果提供给分析工具或智能体。

当企业已经在 Databricks 中集中管理数据、权限、管道和 AI 工作负载时，这一主张会更具吸引力。当文档运营位于其他地方，或专业处理器能够提供明显更高的字段准确率时，其吸引力则会下降。

供应商整合也存在取舍。更少的集成可以减少运营工作，但对单一平台更深的依赖可能提高迁移成本。解析后的表示、工作流逻辑、治理策略和智能体工具，都可能与承载它们的平台紧密绑定。

企业应区分可移植组件与平台特定组件。字段模式、评估集、路由规则和预期输出可以保留在任何单一实现之外的文档中。这会让日后比较供应商或替换表现较弱的组件更容易。

团队还应保留原始文档和源引用。结构化字段对自动化很有用，但它们是对来源的解读。审计人员和审核者需要一条可靠路径，回溯至文件、页面、区域、提取版本和审批历史。

当员工需要重新查阅支持材料时，可搜索的个人或团队资料库能够补充运营处理流程。专注于知识融合的工具可以帮助用户将文档与笔记及其他上下文联系起来，而事务系统则负责正式路由和审批。

更广泛的转变已经很明确。文档处理不再局限于档案数字化。供应商如今希望提取出的内容成为智能体和业务软件的即时上下文。Databricks 正押注于：决定这一市场的将是治理与集成能力，而不只是 OCR。

三个信号将显示实时押注是否奏效

下一阶段取决于可衡量的生产环境表现，而不是另一份功能清单。

第一个信号是来自真实企业工作负载的独立证据。客户应关注已发布的评估，了解其在不同文档类型上的字段级准确率、引用、置信度校准和响应时间。

置信度校准尤其重要。经过良好校准的系统，在更可能出错时会给出更低的置信度。这让开发者能够设定有意义的阈值，而不是把该分数当作装饰性元数据。

只有披露工作流边界时，客户案例研究才有价值。“处理了数百万份文档”的说法，几乎无法说明自动化质量。更有参考价值的指标包括更正率、审核时间、直通式处理率，以及在执行前捕获的错误数。

如果 Databricks 客户报告称人工审核减少，同时下游错误没有增加，该公司的集成方法将获得更多可信度。如果团队仍需要大量验证层和专业解析器，整合的论点就会被削弱。

第二个信号是 ai_decide 从 Beta 走向正式发布的路径。Databricks 需要展示开发者如何约束决策、检查理由、测试路由行为、管理版本并从错误中恢复。

建议与获得授权的操作之间的区别应保持清晰可见。企业会希望拥有策略控制，以防概率模型绕过必要审批，或访问超出用户权限范围的数据。

若正式发布包含明确的评估、审计和控制功能，将支持这样一种观点：文档智能体能够在生产工作流中运行。若 Beta 状态长期持续，或治理模型有限，则表明提取能力的发展快于安全的决策自动化。

第三个信号是竞争对手的回应。Microsoft、Google、Amazon 和专业供应商都可以改进同步处理、智能体集成、治理或工作流工具。市场将检验 Databricks 是否提供了独特的运营模式，还是仅为熟悉的文档任务增加了另一个端点。

关注客户如何组装最终系统。如果他们将 Databricks 的治理和智能体与外部解析器结合使用，专业化可能仍比整合更有价值。如果他们用 Databricks 技术栈替代多项服务，其平台论点就会更有力。

对于开发者而言，实际的下一步是开展受控试点。选择一种文档类型，定义必填字段，并建立包含常见及困难案例的测试集。在将工作流连接到会产生重要后果的操作之前，衡量准确率、延迟、审核工作量和恢复行为。

对于企业买方而言，治理应从评估之初就纳入考量。询问文件和输出存储在哪里、哪种身份可访问每项资源、引用如何保留，以及哪些操作需要人工参与。一旦处理发生在实时交易期间，这些问题就变得更加重要。

Databricks Document Intelligence 现在已具备参与此类交易所需的接口。剩下的问题是，客户能否信任从文档到达到业务操作的完整链路。请在自己的文件上测试这条链路，并将每个缺乏支持依据的置信度分数视为继续让审核者参与的理由。