企业处理各种文档类型，包括发票、采购订单、法律合同和技术手册。手动处理速度缓慢，容易出错，并消耗大约 15-25% 的员工时间。早期的自动化方法(例如,机器人流程自动化 (RPA ) 、 光学字符识别 (OCR) 和工作流工具)减轻了一些负担,但产生了僵硬的漏斗、高昂的维护开销和单个业务团队之间的相互孤立采用。

文档包含纯文本处理无法保留的丰富结构上下文（例如，表格层次结构、空间字段关系和交叉引用部分）。将文档剥离为纯文本会丢弃使提取准确有用的业务上下文，这会降低下游分析、人工智能 (AI) 推理和流程自动化的质量。

为有效起见,智能文档处理 (IDP) 系统必须按类型对文档进行分类,从变量布局中准确提取结构化数据,并以受管、可查询的形式向下游系统提供这些数据。境内流离失所者还必须大规模处理文档的可变性,而不需要每种新文档格式的每个模板配置,而且它们必须集中起来并在各业务部门之间访问。这一挑战因关键问题的数量而变得更加复杂:非结构化数据约占所有企业数据的 80%,其中大部分以文档形式累积在_客户关系管理 (CRM)_ 系统、AI 客服人员和分析平台之外的文件系统、云存储和内容存储库中。

Data 360 文档 AI 是 Data 360 中的 Salesforce 文档处理功能，旨在解决这一差距。它使用_大语言模型 (LLM)、光学字符识别 (OCR)、自然语言处理 (NLP) 和_机器学习 (ML) 来提取、分类和分析非结构化和半结构化文档内容。输出是结构化、受管和可查询的数据,集成到_Data 360_漏斗中,_Agentforce_代理、分析工具和自动化工作流可以通过标准界面访问它,而无需自定义提取或转换层。

企业数据平台处理结构化的列表式数据。但是，大多数企业数据都是以文档的形式到达的，CRM、ERP、AI 客服人员和分析漏斗仍然无法访问，直到有人手动提取它。这是架构差距，不是工作流问题。

早期的方法结合了手动重新密钥、基于规则的 OCR 和 RPA 脚本。这些方法在小范围内有效，但它们无法处理现代企业生成的文档类型的数量、种类和速度。基于规则的工具需要每个布局变体的明确模板。任何格式更改都会中断提取，并需要开发人员、新模板和部署周期。

大规模而言，这会产生脆弱的点解决方案，没有集中治理、共享模式和实现 AI 就绪的路径。不一致的提取漏斗会向下游传播。换句话说,分析会继承数据不一致、AI 模型产生不可靠的输出以及_个人健康信息 (PHI)_ 和_个人身份信息 (PII)_ 等受监管内容缺乏系统的治理。

LLM 提取没有显式模板的字段。单个模式配置控制跨布局变体、语言和格式的提取，这会适应文档，而不是要求文档符合固定结构。这将文档处理从维护繁重的孤立操作转移到了受管的集中功能。

Data 360 文档 AI 概述，显示批处理和事务漏斗如何将非结构化文档转换为受管、可查询的数据

Data 360 文档 AI 通过两个漏斗在 Data 360 平台中操作文档处理。

  • _批处理漏斗_通过接收、身份解析、计算见解、激活、分析和 Agentforce 激活来路由提取的数据。
  • _事务处理漏斗_公开了同步返回结构化 JSON 的 REST API，这允许架构师将文档派生的数据路由到 Salesforce SObjects、Data 360 Data Lake 对象/数据模型对象 (DLO/DMO) 漏斗或外部数据库和仓库，而无需批量设置开销。

在这两种情况下，提取的数据会进入受管的、模式驱动的模型，而不是分散的点工具集。

Data 360 文档 AI 是 Data 360 平台中的 Salesforce 本地_智能文档处理 (IDP)_ 功能。它将非结构化和半结构化文档内容转换为可完全参与整个 Data 360 生命周期的受管、可查询的数据。

Data 360 文档 AI 是 Data 360 中的 Salesforce 本地_智能文档处理 (IDP)_ 功能。它接收非结构化和半结构化文档,使用声明性模式配置提取结构化数据,并将该数据传递到_Data 360_漏斗,进行协调、身份解析、分析和 Agentforce 激活。

Data 360 文档 AI 支持两种处理模式：

  • **批量处理：**在事件驱动的基础上处理在_非结构化数据_模型对象 (UDMO) 中定义的大型文档集。
  • **事务处理：**通过 REST API 处理单个文档，并同步返回结构化 JSON 负载。然后，架构师可以通过 MuleSoft、Apex 标注或 Einstein Trust Layer (ETL) 漏斗将该有效载荷路由到 Data 360 DLO/DMO 漏斗、Salesforce SObjects 或外部数据库和仓库。目标层是由延迟、治理和数据驻留要求驱动的架构决策。

文档 AI 目前支持 PDF 文件、图像文件（JPEG、PNG）和手写文档。

Data 360 文档 AI 将四种处理技术整合到一个受管漏斗中。每个组件处理文档到数据生命周期的不同阶段：

  • **光学字符识别 (OCR)：**在 LLM 处理之前，将扫描图像、手写内容和基于图像的 PDF 转换为机器可读的文本。建议至少 150 DPI 才能可靠地提取。
  • **大型语言模型 (LLM)：**使用用户选择的模型，通过 Einstein LLM 网关路由提取。LLM 与 JSON 模式配置一起接收 OCR 输出，并返回结构化提取负载。正在计划未来实施_双子座_和其他型号。
  • **自然语言处理 (NLP)：**通过结构化提示工程，直接在 LLM 中执行上下文理解、实体识别、日期解析和语义字段提取 — 模式定义的提示和 OCR 输出作为唯一的输入。所有 LLM 交互都通过 ETL 路由，ETL 对模型提供商实施零数据保留，并在到达模型之前屏蔽基于文本的输入中的 PII。不使用单独的 NLP 发动机。
  • **多模式处理：**将 PDF 中的嵌入图像作为单独的提取输入进行处理，这允许 LLM 从图表、图像渲染表和混合内容页面中提取数据，而 OCR 无法单独解析这些数据。

除了四种处理技术之外,文档 AI 还处理：

  • **Einstein Trust 层：**通过 ETL 路由所有 LLM 交互，ETL 对模型提供商实施零数据保留，并在输入到达 LLM 之前屏蔽 PII，但多模态数据（例如，通过_文档 AI_ 处理的附加文档）除外，目前不支持 PII 屏蔽，数据按原样发送到外部模型。ETL 仅控制 LLM 交互路径。写入_数据湖对象 (DLO)_ 的提取数据按原样存储;静态字段级屏蔽必须通过下游数据治理控制来解决。
  • 文件大小限制：文档 AI 处理每个请求最多 10 MB 的文件。LLM 上下文长度限制可能会进一步限制在此边界内处理密集的多页文档。

部署 Data 360 文档 AI 的企业架构师应在承诺实施设计之前应用这些原则。

  • 在设计模式之前，选择漏斗。_批处理_和_事务_处理漏斗在接收模型、模式绑定、目标灵活性和延迟方面有所不同。在定义模式之前，确认每个用例需要哪个漏斗非常重要，因为改造增加了可以避免的返工。
  • **在文档类型级别设计模式。**与使用每个用例配置相比，为每个文档类型使用单个精心制作的模式更具可维护性，并且也是提取质量的最大杠杆。正确执行此操作需要使用一组不同的文档（包括边缘个案），而不是从单个示例进行设计。在_字段_、_表格_和_模式_级别迭代使用提示来查找差距，然后在最终确定之前根据多个文档样本测试和改进它们。请记住，在一个文档上运行良好的模式可能不如其他文档，因此广度和迭代至关重要。模式灵活性（包括删除不能跨文档类型可靠地提取的列）同样重要。保留引入噪声或不一致性的字段会破坏整体提取质量，因此将列移除视为一流的设计决策非常重要。
  • **为每个字段组选择正确的目标层。**推动 CRM 工作流或批准的字段会写入 SObject。正在丰富统一简档或摘要分析的字段属于 DLO/DMO 漏斗。为外部系统提供服务的字段属于 RDBMS 层。请谨记，单个模式可能会同时扇出到多个层。
  • **在处理受管内容之前，强制执行治理。**监管数据需要在每个层进行保护。这就是为什么在提取的数据存储在输出_数据湖对象 (DLO)_ 后，配置 PII 掩码、数据分类标记和基于属性的访问控制 (ABAC) 非常重要_。_这提供了基于数据分类、用户角色和组织上下文的微调的实施和上下文感知访问。_治理_分为两条路径:ELT 治理 LLM 交互,而存储在 DLO 中的提取数据必须通过_数据空间_配置、_权限集_和 ABAC 策略直接在 DLO 和数据库级别单独治理。这些控制必须在存储层（而不仅仅是应用程序层）保持一致性，因此无论接收后如何访问数据，访问限制都保持不变。请谨记，即使其他层配置正确，任何层中的间隙都可能向下游暴露受管数据。
  • **在生产前设计失败模式。**在第一个生产批处理运行之前，解决空字段处理、OCR 质量阈值、文件大小预验证、LLM 上下文溢出、RDBMS 写入幂等和信用预算限制。这些不是边缘个案，而是可预测的故障表面，必须在漏斗设计中明确处理，而不是在运行时发现。
  • **将置信度分数视为一流的路由信号，而不是事后诊断。**提取结果携带字段级置信值，该置信值从基础模型输出的对数概率 (logprob) 中派生。对于每个提取的字段、表格或列，分数反映了模型对提取值的令牌级确定性。这使得置信度分数成为基于统计的信号，足够可靠，可以作为 HitL 升级阈值的主门。使用置信度分数来系统地识别低质量提取，并针对低置信度字段值、模糊的模式匹配或重复的漏斗失败启动 HITL 检查点，而不是依赖启发式或手动抽查。当自动恢复不可能时，HITL 支持的置信度评分确保人的判断被准确地应用于需要的地方。
  • 与模式设计并行设计激活路径。文档 AI 的价值来自能够在 Salesforce 工作流和客服人员中激活提取的数据。它允许您设计 Agentforce 行动、流_和_计算见解，与提取模式设计同时进行，而不是在之后。

文档 AI 在两个漏斗中操作：

  • 用于高用量、UDMO 备份处理的_批处理_漏斗
  • 用于实时 API 驱动提取的_事务__处理_漏斗

两个漏斗共享相同的模式配置合同和 ETL 治理，但它们在文档进入系统的方式以及提取的数据到达的位置方面有所不同。

让我们仔细看看每个漏斗。

_批处理_漏斗处理由 UDMO 定义的重复文档集。它适用于计划或事件驱动的用例,其中文档从企业存储中摄取,然后经过文档提取,并交付给_Data 360 DLO/DMO_漏斗进行协调、身份解析和激活。

真实场景

每天,保险公司都会收到来自提供商入口网站的数千份医疗索赔文档,这些文档以 PDF 格式上传到 Amazon S3。UDMO 定义范围内文档集，并在 24 小时内将所有索赔 PDF 发送到/claims/incoming/存储桶。

保险公司医疗索赔的批处理漏斗,从接收到协调、身份解析和 Agentforce 激活

文档从企业源系统接收到 Data 360 中，没有物理重复。支持的来源包括 Amazon S3、Google Cloud Storage、Salesforce CRM 文件对象、MuleSoft 协调的_漏斗和直接 API 上传。在 无头 360 部署中，文档通过云存储连接器或绕过 CRM 层的_接收 API 接收。模型上下文协议 (MCP) 服务器将摄取公开为外部 AI 客服人员和 LLM 客户端的可调用工具。

接收后，原始文档会存储为_非结构化数据_湖对象 (UDLO ) , 这些对象会映射到每个文档的物理位置和元数据，而无需移动或转换源文件。

示例：

索赔 PDF 通过云存储连接器从 S3 接收到 Data 360 中。每个文档存储为指向 S3 对象的 UDLO。不会出现物理重复。

文档 AI 根据模式配置处理每个 UDLO，该模式配置定义了要提取的字段及其目标数据类型。UDMO 定义了哪些文档在范围内。LLM（GPT-4o、Gemini 或 Claude）读取每个文档并返回结构化提取负载。

示例：

文档 AI 根据定义字段的索赔模式处理每个 UDLO，例如：ClaimID、PatientName、DiagnosticCode、BillingAmount 和 ServiceDate。然后，LLM 读取每个 PDF，并返回结构化提取负载。

在提取数据后，它会保留在 DLO 中，即 Data 360 的原始存储层。DLO 保留提取的字段，而不强加业务逻辑，这为下游转换和可追溯性保留了准确的物理表示。UDLO 保留对源文档的引用，以在漏斗中的任何一点启用字段级谱系。

示例：

所有提取的字段都位于_索赔 DLO_ 中，该 DLO 保留了每个索赔的原始、准确的表示，具有可追溯到源 PDF 的完整谱系。

DLO 字段映射到与标准 Customer 360 数据模型_一致的 DMO。这是文档派生数据从原始提取字段转换到具有业务意义的实体的边界。发票 DLO 映射到_发票 DMO，CustomerID 和 BillingAmount 等字段成为连接密钥，并匹配统一数据模型中的属性。统一的文档数据通过 CRM 和事务数据使用的相同界面参与细分、_计算见解_和激活。

示例：

索赔 DLO 映射到_索赔 DMO_。PatientID 和 PolicyNumber 字段成为将索赔记录链接到统一患者简档的连接密钥。

统一的 DMO 数据参与身份解析。提取的字段(例如客户名称、电子邮件地址或客户编号)作为匹配密钥，将文档记录链接到_统一个人 (Gold Records)_，从而缩小了文档与简档之间的差距。

示例：

提取字段(例如 PatientName、DateOfBirth 和 PolicyNumber)作为身份解析的匹配密钥，将索赔记录链接到正确的_统一个人_。即使同一患者在文档中出现的名称拼写略有不同，也会发生这种情况。

架构师定义_计算见解_，这是跨统一文档数据（例如，各种发票行项目的总支出、合同续订风险分数和索赔严重性指数）计算的汇总度量。

示例：

_计算见解_计算 Agentforce 查询的统一索赔数据中的 TotalClaimsPerPatient、AverageClaimAmount 和 HighRiskClaimScore。

Agentforce 客服人员、Tableau、市场营销平台和 Salesforce SObject 都可以访问统一的身份解析数据。目标层是受延迟、治理和数据驻留要求驱动的架构决策。

示例：

索赔裁定 Agentforce 代理_向 Data 360 DMO 和 CI 查询，以查找优先审查的高风险索赔。Tableau 仪表板显示索赔量和异常趋势。批准的索赔记录循环回_索赔 SObject，以启动付款工作流。

在 无头 360 架构中，激活通过_查询 API_、发布/订阅 API 或云数据仓库激活目标直接路由到外部系统。然后，MCP 服务器找到统一的文档数据和_计算见解_作为外部 AI 客服人员的可调用工具。

_事务处理_漏斗在运行时处理单文档提取，没有 UDMO 或预摄取的 UDLO，这适合事件驱动的用例（例如，客户上传表格、客服人员收到 PDF 或在事务处理工作流中启动提取的外部系统）。ETL 治理同样适用于两个漏斗。

真实场景

在申请贷款时，银行客户通过银行的移动应用程序上传水电费账单的 PDF。该事件会实时启动提取，这意味着不涉及预先摄取的 UDLO 或 UDMO。

显示贷款申请人水电费实时同步 REST API 提取的交易处理漏斗

在调用 API 之前，架构师必须在 Data 360 中定义和存储模式，该模式以 JSON 模式_格式指定字段、数据类型和提取指令。每个模式被分配一个唯一的_模式 ID。在运行时，调用应用程序引用模式 ID，以将提取逻辑集中在 Data 360 中，而不是将其嵌入应用程序代码。

示例：

该银行的团队在 Data 360 中有一个预定义的ProofOfAddress模式，它指定了CustomerName、AddressLine1、City、PostCode 和 DocumentDate 等字段。此信息存储为可由_模式 ID_ 引用的版本化配置。

调用应用程序在单个 REST API 请求中提交文档和方案 ID 作为 base64 编码的有效负载或文件引用。不需要 UDLO 摄取。文档 AI 应用文档提取，并根据提供的模式返回结构化输出。

示例：

移动应用程序在单个 REST API 调用中将水电费作为 base64 编码的有效负载与ProofOfAddress模式 ID 一起提交。此过程不需要 UDLO 摄取步骤。

LLM 根据模式处理 OCR 输出，并同步返回结构化 JSON 负载。在文档中找不到的字段将返回为 null。呼叫者拥有完整的 JSON 响应，并继续路由。

示例：

文档 AI 将 OCR 应用于 PDF，LLM 返回带有提取的地址字段的结构化 JSON 负载。未找到的字段（例如，如果账单中缺少PostCode）将返回为 null。

提取后，JSON 负载可以路由到一个或多个目标层，这取决于用例：

  • **Salesforce SObject：**通过 Apex 或 CRM 工作流和批准的 Flow 直接映射到 SObject 字段。
  • **Data 360 DLO/DMO 漏斗：**路由到 DLO 进行协调、身份解析、_计算见解_和 Agentforce 基础训练。
  • **外部 RDBMS 或数据仓库：**通过 MuleSoft、Apex 标注、_平台事件_或 ETL 为 Salesforce 外部的系统路由。
  • **自定义集成：**将结构化 JSON 负载返回到调用应用程序，以存储在任何外部系统或数据存储中。
  • **下游流或客服人员：**将结构化的 JSON 输出直接传递给下游流或客服人员，而无需任何持久化到 SObject 中。对于在更大的自动化或客服人员工作流中使用_文档 AI_ 作为实时提取步骤的客户，这是常见的模式。

请谨记，单个模式可能同时扇出到多个层，不同的字段组从同一个提取点路由到不同的目标。

示例：

ProofOfAddress 负载可能一次扇出到三层(例如,CustomerName 和 AddressLine1 写入_联系人 SObject_ ) , 从而启动地址验证_流_。然后,完整的有效载荷路由到DLO进行协调和风险评分,副本路由到银行的KYC系统,通过_MuleSoft_进行监管合规记录。

一旦写入，提取的数据会立即在目标系统中激活。对于 SObject 目标，触发器、流和审批流程会在更新插入的记录中激活。对于_DLO/DMO_目标,数据进入_协调和身份解析_漏斗和Agentforce上下文。对于外部 RDBMS 目标，写入完成后，下游查询即可获得数据。

示例：

_地址验证流_会在更新插入的_联系_人记录中立即激活，这将推动贷款申请进入下一阶段。Agentforce _贷款官员 Agent_从 Data 360 中找到经过核实的地址，KYC 系统记录提交的文件以供审计。

文档 AI 最适合特定的架构条件。在这些条件之外应用它会产生不必要的复杂性和额外的成本。

作为架构师，在承诺将 Document AI 作为提取机制之前，评估这些标准非常重要。

在以下情况下使用文档 AI：

  • **文档是主要数据源。**所需信息仅以文档形式存在，并且无法从结构化 API 或数据库中获得（例如，扫描的合同、实验室报表、接收表单或保险索赔）。
  • **文档布局因来源而异。**相同文档类型来自多个供应商、合作伙伴或区域，字段位置和格式不同。模式驱动的 LLM 提取适应，无需每个布局维护。
  • **提取的数据必须提供给 Data 360 或 Agentforce。**提取必须参与身份解析、_计算见解_或 Agentforce 基础训练。文档 AI 直接传递到 DLO/DMO 漏斗中，没有单独的 ETL 层。
  • **数量证明了受控自动化的合理性。**文档量超出了手动处理所能处理的范围，而没有可衡量的人工成本或数据质量风险。
  • 文档包含监管内容。PHI、PII 或财务数据必须在到达 LLM 之前通过零数据保留、PII 屏蔽层进行路由。ETL 会本地满足这一点。对于不需要在任何时间点保留提取内容的客户，也应考虑_事务 API_ 流，该流直接向调用应用程序返回结构化输出，而无需写入任何 SObject 或数据存储。
  • **用例由事件驱动。**文档在运行时到达（例如，客户上传、客服人员 PDF 附件或外部系统触发器）。_事务处理_漏斗处理同步的单文档提取，无需批量设置。

在以下情况下，请勿使用文档 AI：

  • **源数据已结构化。**如果上游系统公开 REST API、数据库表或结构化文件（例如 CSV、JSON 或 XML），请使用标准 Data 360 连接器。通过 LLM 提取漏斗运行结构化数据会增加延迟和信用成本，而不会带来额外的好处。
  • **文档使用固定模式由机器生成。**系统从具有稳定布局的已知 ERP 或计费平台生成的 PDF 更适合确定性解析器。LLM 提取专为可变性而设计，并将其应用于固定模式文档浪费上下文和信用。
  • 精度要求超过 LLM 置信度阈值。文档 AI 不能保证 100% 的提取准确性。缺少或不正确的字段值具有重大财务、法律或临床风险的用例需要 HITL 验证步骤。在没有验证工作流的情况下，不要将 Document AI 用作高风险决策的唯一提取层。
  • **文档超出平台约束。**当前的 10MB 文件大小限制和 LLM 上下文长度约束使得 Document AI 不适合大型或密集文档，而无需预处理来在平台外拆分和重新组合它们。
    • **注意：**在 Salesforce，我们正在积极改进这些验收防护栏，以扩展支持的文件大小、页面计数和文件扩展名。制约因素将继续向前发展。

让我们仔细看看几个使用 UDMO 源对象支持的_文档 AI 批处理_漏斗的场景。在这些情况下,提取的数据通过_Data 360 DLO/DMO_漏斗路由,用于协调、身份解析、_计算见解_和 Agentforce 激活。每个用例最适合计划或事件驱动的高用量文档处理。

Agentforce Sales：合同和发票智能

合同 PDF 通过_批处理_漏斗从云存储中摄取。该模式提取 ContractValue、Re RenewalDate、PaymentTerms 和 CounterpartyName，然后将其映射到_客户_和_合同_ DMO。_计算见解_会导出续订风险分数。Agentforce 会在续订时段关闭前提醒客户主管，这消除了手动合同审核和错过的续订。

Agentforce 服务：个案转移和 Knowledge 基础训练

调查 PDF 和个案附件通过_批量_漏斗接收。模式提取情绪指标、问题类别和解决说明，然后将其映射到_个案_和_Knowledge 文章_ DMO。Agentforce 会在个案打开时查询协调 Knowledge 库，并找到相关的故障排除步骤，这可以减少客服人员的搜索开销。

Agentforce Health:临床文档处理

实验室报告、接收 PDF 和手写临床表格通过_批量_漏斗接收。该模式提取字段 – – 包括_患者 ID_、诊断代码、药物名称_和_测试结果 – – 然后将其映射到_Health Cloud_ DMO，该模式支持符合HIPAA的护理协调和临床研究工作流。

金融服务：贷款和税务文档自动化

通过批量漏斗接收的贷款申请、纳税申报和损益表。该模式提取字段，包括 AnnualIncome、TaxYear 和 EmployerName，然后将其映射到_财务客户_ DMO。_计算见解_将文档派生的收入数据和 CRM 数据结合起来，以促进自动化信用风险评分。Agentforce 会在客户服务交互期间内联查找提取的贷款详细信息。此模式直接支持在 Salesforce Agent Enterprise Solutions 开发人员中心发布的贷款资格预审客服人员用例。

HR:劳动力文档处理

入职文档、税务表格和认证 PDF 通过_批量_漏斗接收。提取的字段映射到_员工记录_ DMO，然后链接到_统一员工_简档。特定_流_根据提取的数据启动入职任务和合规检查。此模式直接支持自动恢复处理客服人员用例。文档 AI 从简历 PDF 中提取技能、就业历史和资格,Agentforce 然后将其用于根据开放角色标准匹配候选人,并将其路由到招聘工作流。

专业服务：建议和研究智能

建议书版面和研究报告通过_批量_漏斗接收。提取的框架、基准和参与汇总映射到自定义 DMO，然后为向量搜索建立索引。Agentforce 在查询时检索上下文相关的推荐，这些推荐基于提取的文档内容。这种模式扩展了Ground Agentforce on Website Content 模式。文档通过 Document AI 进行索引，客服人员响应的基础功能与通过 Data 360 连接器进行索引的网站内容相同。

HIPAA 合规状态：

本文描述的_Health Cloud_模式将ETL控制(例如,零数据保留和PHI屏蔽)应用于文本输入。这些控制措施本身并不构成 HIPAA 认证。在承诺在这些上下文中使用基于_文档 AI_ 的架构之前，专为受监管临床环境设计的架构师必须向 Salesforce 合规团队确认当前的 HIPAA 认证状态。

让我们仔细看看几个场景，它们使用不绑定到 UDMO 的模式调用_文档 AI_ REST API。提取的 JSON 负载在运行时直接同步路由到外部系统。

供应链：供应商发票处理到 ERP

当_供应商发票_ PDF 到达受监控的存储桶或电子邮件网关时，事件触发器会调用带有发票和预定义模式 ID 的_文档 AI_ REST API。该模式提取 VendorID、InvoiceNumber、LineItems、TotalAmount、TaxAmount 和 DueDate。JSON 负载通过 MuleSoft 路由到具有_空_字段验证和幂等更新插入逻辑的 _ERP 应付款_模块，这消除了供应商格式可变性的模板维护。

法律操作：合同审查到 CLM

当_合同_ PDF 上传到法律入口网站时，后端会同步调用_文档 AI_ REST API。该模式提取 GoverningLaw、IndemnityCapAmount、TerminationNoticePeriod、AutoRenewalClause 和 CounterpartySignatory。JSON有效载荷通过_Apex_标注路由到_合同生命周期管理_系统。任何未找到的字段都将返回为 null，CLM 会将默认义务规则应用于缺失值。

保险索赔：第一份损失处理通知

当保单持有人提交_第一份损失通知 (FNOL)_ 表单时，后端入口网站会同步调用 Document AI REST API。该模式提取 PolicyNumber、EventDate、EventLocation、DamageDescription、Sc claimerName 和 ContactPhone。JSON 有效载荷通过 Apex 标注或 ETL 路由到_索赔管理数据_库，这将创建一个预先填充的索赔记录，供理算员在正式索赔开始之前审查。

在进入生产之前，您必须为这些失败场景创建设计。

  • **空字段处理：**LLM 对于它无法找到或无法自信地提取的字段返回 null。在写入任何具有 NOT NULL 约束或必需匹配密钥的目标之前，请在方案设计时验证空处理逻辑，并在集成层中实施默认值或拒绝逻辑。
  • **OCR 质量降级：**OCR 精度在低于 150 DPI、手写不规则或扫描有噪音时下降。错误读取会作为没有错误信号的损坏输入传播到 LLM 提取中。在摄取时强制实施最低扫描质量，并对数字和日期字段实施置信度阈值检查。
  • **模式版本不匹配：**在计划批处理作业后更新模式配置会使正在处理的文档与以前的版本进行比较，以前的版本会产生丢失或重命名的字段，从而破坏下游映射。明确版本模式，并将更新与批处理作业计划协调。
  • **文件大小限制：**超过 10MB 的文档将被拒绝。在没有配置监控的情况下，批处理漏斗失败是静默的，事务调用者会收到 4xx 错误。在摄取时预验证文件大小并实施预处理，以拆分或压缩经常接近限制的文档。
  • **LLM 上下文溢出：**密集或多页文档可能会超出 LLM 上下文窗口的 10MB 限制。LLM 会静默删除超出上下文的内容。实施分块策略，按页面范围拆分文档，并在将它们转移到目标之前重新组合提取的字段。
  • **影响提取的信任层掩码:**ETL 在提示级别操作，而不是文档级别，因此屏蔽不适用于通过_文档 AI_ 的文档内容。依赖于文档中 PII 值的模式字段不受 ETL 屏蔽策略的影响。
  • 外部 RDBMS 写入幂性：_事务处理_漏斗没有外部 RDBMS 目标的内置幂等性。_集成层_重试会创建重复行，除非写入逻辑明确处理重复数据消除。在所有外部写入路径上使用文档指纹或外部 ID 实施幂等更新插入。
  • **贷项用完中期：**大批量运行可能会在处理所有文档之前耗尽 Digital Wallet 信用，从而产生下游步骤视为完整的不完整的 DLO 数据集。将消耗警报设置为可用信用的 75% 和 90%，并将批次大小限制在每个周期的信用预算范围内。
  • 模式字段限制 — 架构约束：文档 AI 对模式配置中的根级字段强制实施 50 个字段的限制。这是设计时间约束，而不是运行时错误，架构师必须在数据模型和方案设计期间考虑它。
    • 对于需要更广泛提取的用例：
      • 无情地确定优先级。将模式缩小到推动自动化价值的字段，而不是详尽无遗的文档覆盖范围。
      • 利用嵌套对象（最多 3 个级别；仅限源对象的批处理模式）减少根级字段计数，而不牺牲提取深度。
      • 跨多个针对不同文档部分的_文档 AI_ 配置分解复杂文档，并将结果写入在 Data 360 中下游连接的单独 DLO。
  • API 速率限制：文档 AI 强制规定每个租户每分钟最多 50 次提取 API 调用。理论上限是每分钟 300 次呼叫,由 _Einstein LLM 网关_控制。高用量事务集成的设计必须具有指数回退、请求排队和租户级吞吐量预算。不要假设突发容量在多租户生产环境中可用。
  • API 延迟简档：文档 AI 提取 API 完全同步。典型的响应时间为 5-15 秒，并且因文件大小和模式复杂性而异。
    • 这直接影响到集成架构：
      • 将呼叫方超时设置为最少 30 秒。
        • 不要在具有次秒级 SLA 要求的流中调用_文档 AI_。
        • 根据_批处理_漏斗的速率限制上限，将延迟计入吞吐量计算。
  • 加密和密码保护的文档：文档 AI 不处理受密码保护的文件(打开文件需要用户密码)或使用所有者/权限密码加密的 PDF，包括正常打开但在 _PDF 权限_层限制复制、打印或编辑的文件。
    • 此约束位于摄取边界：
      • 设计_文档接收_漏斗，以在加密文件到达_文档 AI_ 之前检测并将其路由到_拒绝_或_手动处理_路径。
      • 不要依赖运行时错误处理作为主门。

Data 360 文档 AI 与 Salesforce _良好架构框架_的多个支柱保持一致。

  • **Trust:**ETL 对 LLM 提供商实施零数据保留，在到达模型之前屏蔽 PII 输入，并扫描输出中的敏感内容。架构师必须将这种态势扩展到静态提取的数据。DLO 中的字段级掩码不会被 ETL 应用，它需要下游_数据空间_策略和_权限集_。
  • 可靠性：“设计注意事项”部分中的每个失败模式 — 空字段提取、OCR 错误读取、模式版本不匹配、文件大小泄露、LLM 上下文溢出、ETL 屏蔽干扰、RDBMS 写入幂等和信用耗尽 — 都代表不同的失败类，并带有记录的检测信号和解析路径。
  • **卓越运营(变更管理):**模式驱动的提取模型将提取逻辑与文档布局分离。当供应商更改发票格式或更新监管表单时，架构师只需要更新一个模式配置，而不是修改集成代码。
  • **卓越运营(可维护性):**在 Data 360 中集中模式配置，而不是在应用程序代码中嵌入提取逻辑，使提取意图明确、版本化和可审计。所有下游目标都使用相同的模式合同，无论其目标层如何。
  • 卓越运营(集成重用):文档 AI 公开了跨多个集成表面的提取：REST API、Apex、Flow、MuleSoft、Agentforce _Actions_和MCP服务器。单个模式配置同时扇出到多个目标层，而无需重新构建每个使用者的提取能力。
  • **资源和成本优化：**漏斗选择指导、10 MB 文件大小边界和预汇编 LLM 上下文长度约束代表性能感知的设计决策。“_何时使用”部分正式确定了_文档 AI 不是正确工具时的条件（例如，亚秒级延迟要求、完全结构化的源数据和固定模式的机器生成的文档）。

这是在 Sandbox 环境中配置 Data 360 文档 AI 的结构化起点。在转移到生产之前，完成 Sandbox 中的所有阶段。

在开始配置之前，您必须确认：

  • **文件大小：**验证代表性文档大小是否小于 10MB。
  • **漏斗：**确认用例是否需要_批处理_漏斗（UDMO 支持的、高用量）或_事务处理_漏斗（API 驱动的、单文档）。这推动了所有后续配置。
  • **目标层：**确认提取的数据位于何处 — Salesforce SObject、Data 360 DLO/DMO、外部 RDBMS 或组合。
  • **Agentforce 依赖性：**在部署任何基于 Agentforce 的文档处理之前，请确认通过 ETL 设置在您的组织中启用了支持的 LLM（例如，GPT-4o）。Agentforce 是_文档 AI_ 的硬平台先决条件。整个_文档 AI_ 功能表面 – – 包括所有提取 API – – 在 Agentforce 在目标组织中处于活动状态之前不可用。将此因素纳入组织就绪评估和配置顺序。请为 API 可用性留出几分钟时间，以稳定启用后的状态。
  • **Agentforce 禁用影响：**如果在配置和部署_文档 AI_后禁用 Agentforce，将立即阻止所有提取处理(UI和API)。这同样适用于模型禁用。禁用基础模型对_文档 AI_ 可用性的影响相同。在这两种情况下，现有的模式配置都会保留下来并保持可见 — 不会发生配置或数据丢失 — 但在 Agentforce 和模型重新启用之前，该功能是完全不能操作的。设计操作手册，将 Agentforce 可用性和模型启用视为_文档 AI_ 健康依赖性。
  • **信用消耗/定价：**对于从代表性示例文档中得出的 TCO 估计，使用 Data 360 信用或 Flex Credit。
  • **创建模式配置。**在 Data 360 文档 AI 设置中，以 _JSON 模式_格式定义提取字段、数据类型和指令。对于_批处理_漏斗，将其绑定到 UDMO。对于_事务处理_漏斗，在没有源对象的情况下创建它。记录模式 ID。
  • **将字段名称与目标层对齐。**将字段名称与 DLO 列定义、SObject API 名称或 RDBMS 列名称匹配。名称不一致会在集成层中产生映射开销。
  • **配置 UDMO 源对象（仅限批处理）。**定义范围内的文档并配置摄取源连接性（例如，S3、Google Cloud Storage、Salesforce Files 或 MuleSoft）。确认接收服务帐户具有所需的 IAM 或 OAuth 凭据范围。
  • **应用 PII 屏蔽策略。**在处理任何受管内容之前，请在 ETL 设置中配置_数据屏蔽_策略。定义在输入到达 LLM 之前屏蔽哪些字段类型（PHI、PII 和财务标识符）。不要推迟这一步。
  • **分配数据空间范围和权限集。**将处理范围限定到适当的_数据空间_，并配置_权限集_，以控制模式创建、批处理作业执行、REST API 调用和下游激活。
  • **配置 API 身份验证（仅限事务处理漏斗）。**使用 OAuth 范围 cdp_ingest_api 和 api 创建_连接的应用程序_。对于组织内部调用者，使用链接到_外部凭据_的_命名凭据_。对于外部调用程序，配置 OAuth 2.0 客户端凭据或 JWT 不记名流。在继续之前，测试并验证提取。
  • **SObject 写回：**实施 Apex (@InvocableMethod) 或 Flow 元素，将 JSON 响应字段映射到 SObject 字段。将 Database.upsert() 与外部 ID 一起使用，以防止重复。对目标 SObject 字段应用_字段级安全_性。
  • **Data 360 DLO/DMO 漏斗：**将提取的 DLO 字段映射到符合 Customer 360 数据模型_的 DMO。配置身份解析规则，将文档记录链接到_统一个人。为 Agentforce 定义_计算见解_并添加 DMO。对于事务处理漏斗，请先通过_接收_ API 将 JSON 负载路由到 DLO。
  • **外部 RDBMS 或数据仓库：**选择集成模式：MuleSoft(现有集成结构)、Apex HTTP 标注(轻量级、组织本地)、具有_发布/订阅_者_的平台事件_(事件驱动)或 ETL(高用量批次)。在所有外部写入路径上使用文档指纹或外部 ID 实施幂等更新插入。
  • **激活路径：**将 Agentforce 操作连接到模式配置，以进行交互式提取。为自动处理工作流配置_流_或 Apex 触发器，并为每个字段组确定激活目标。
  • **错误处理(仅限事务处理漏斗)。**配置完整的 HTTP 响应表面：200（成功，包括部分 null 响应）、400（错误请求_或_未找到模式 ID）、413（文件超过 10MB）、5xx（服务错误）。对最多 3 次尝试的 5xx 次重试实施指数回退。记录每个呼叫的原始 JSON 响应和方案 ID。
  • **根据示例文档测试模式。**通过 Document AI 界面或 REST API 提交代表性示例。确认提取准确性、字段覆盖率和布局变体之间的空处理。
  • **验证空字段处理。**请确认，所有下游目标都可以处理文档中_未找到字段_的_空_值。请记住，NOT NULL 约束会在没有显式空处理的情况下静默失败。
  • **预验证文件大小。**确认生产文档保持在 10MB 以下。实施预处理，拆分或压缩经常接近限制的文档。
  • **验证端到端提取。**对于_批处理_漏斗，启动完整运行，并确认提取的字段正确到达每个目标层。对于_事务处理_漏斗，通过_集成_层跟踪 JSON 响应到目标。验证 SObject 目标的触发器和流执行、DLO/DMO 目标的身份解析链接以及 RDBMS 目标的幂。
  • **确认信任层行为。**ETL 不对文档内容应用 PII 屏蔽，因此 LLM 将按原样返回提取字段中的 PII 数据。请确认您的模式字段、数据路由和下游存储旨在适当地处理带有 PII 的输出，并确保在平台之外满足任何合规或保留要求。
  • **设置 Digital Wallet 警报。**以可用信用的 75% 和 90% 配置消耗提醒。在每个周期的信用预算中，建立批量大小限制和临时费率估计。
  • **验证批次监控（仅限批次漏斗）。**在 Data 360 监控控制台中查看提取成功率、空字段率和作业完成情况。确认标记从 UDLO 通过 DLO 传播到数据谱系中的 DMO。
  • **验证 API 错误处理（仅限事务处理漏斗）。**测试所有错误条件：413（文档超过 10MB）、400（无效模式 ID）、200（部分为空的有效提取）。请确认重试逻辑在模拟 5xx 响应上触发，而不会创建重复写入。

本文档强调了 Data 360 文档 AI: 的架构基础

  • 两个处理漏斗以及何时使用它们
  • 模式配置模型
  • 目标层决策框架
  • 核心工艺限制
  • 失败模式
  • _结构良好的框架_定线

架构师快速入门指南提供了 Sandbox 概念验证的配置顺序。

核心架构态势支持在_模式_层受控制的文档派生数据，通过 ETL 强制的 LLM 漏斗进行处理，并交付到管理我们所有其他企业数据的相同 Data 360 数据生命周期。

应用这些原则的架构师（选择正确的漏斗、在文档类型级别设计模式以及在生产前设计失败模式）构建了在受监管的行业治理要求下扩展和持久的提取功能。

Yugandhar Bora 是 Salesforce 的软件工程架构师,专门从事_数据和智能_应用程序平台中的数据架构。他领导_企业架构审查委员_会 (EARB) 重点关注数据治理和统一数据模型的举措,同时也为自动化平台配置解决方案做出了贡献。

Ananth Anto 是 Salesforce Data 360 的产品管理总监，负责领导 Document AI 和数据图表_计划。他在班加罗尔与企业客户合作，解决现实世界的文档处理和数据智能挑战。他喜欢探索_生成式 AI (Gen AI) 的_企业_用例。

Nishan Naseer 是 Salesforce 的软件工程架构师，从事_非结构化数据处理_、RAG 漏斗和_文档智能_方面的工作。他热衷于利用 AI 的强大功能来解决现实世界的挑战，并找到解决复杂客户问题的创造性解决方案。