Built Technologies builds an AI-powered document intelligence solution on AWS to power agents across real estate finance

Built Technologies 在 AWS 上构建基于 AI 的文档智能解决方案，为房地产金融领域的代理提供支持 | 人工智能

Built Technologies 在 AWS 上构建基于 AI 的文档智能解决方案，为房地产金融领域的代理提供支持

房地产领域的文档处理复杂且高度依赖人工，影响大规模关键业务决策，这使其成为自动化的重要目标。Built Technologies 是一家房地产金融软件提供商，处理着价值超过 5000 亿美元的房地产项目。该公司在亚马逊 Bedrock 和 AWS 智能文档处理（IDP）加速器上部署了基于 AI 的文档处理引擎。该引擎现在成为贯穿房地产生命周期各类代理产品的基础。在本文中，我们将分享房地产领域对 AI 驱动的文档智能的需求，并深入探讨其架构实现方式。

房地产金融依赖于文档：提款包、贷款协议、发票、保险证明、检查报告以及数十种其他文件。每份文件都包含放款人和利益相关者需要审阅、验证和采取行动的信息。这些文档通常内容冗长、格式不一致、领域特定，且难以通过传统自动化处理。

对于 Built 来说，文档智能并非后台工具。它是一种横向的人工智能能力，构成了新一代代理产品在房地产金融生命周期中推出的基础。无论代理人员是在审查施工提款、分析贷款协议、验证保险覆盖范围、总结要约备忘录，还是在投资组合中识别异常情况，都需要相同的核心能力：能够以上下文关联、准确性和可追溯性理解文档。

为了构建这一基础，Built 与 AWS 生成式 AI 创新中心（GenAIIC）、AWS 合作伙伴 AND Digital 以及 AWS 账户团队合作，创建了一个可扩展的 AI 驱动文档处理引擎。

其成果是一个可复用的文档智能解决方案，能够对复杂的房地产金融文档进行分类、拆分、提取、评估和推理。该方案将原本需要数天完成的工作流程缩短至几分钟，支持数百种文档类型，并为技术团队和行业专家提供了一个共同构建和改进文档处理器的环境。

为什么房地产金融需要 AI 驱动的文档智能

房地产金融以文档密集、碎片化和高度上下文相关为特点。单笔交易或资产可能涉及不同方在资产生命周期不同阶段生成的数百甚至数千页文档，格式各异。

一些文档是标准化的，例如 ACORD 25 证明或政府表格。而另一些文档则高度可变，例如要约备忘录、贷款协议、评估报告、基于 Excel 的财务模型以及图纸和规格说明。许多文档包含嵌套表格、扫描页面、嵌入图像、不一致标签、法律术语、手写注释以及借款人或放款人特定的术语。

Built 现有的文档处理能力帮助公司从人工操作转向多种文档类型的自动化提取。团队已使用光学字符识别（OCR）和传统机器学习（ML）建立了 26 个处理器，用于提取、拆分和分类。这种方法在字段明确、布局可预测的狭窄用例中有效。

但随着Built Technologies将其AI路线图扩展到房地产生命周期的各个环节，团队需要更灵活和更智能的解决方案。他们需要一个能够支持250多种文档类型、处理数百万份文档，并运行能够对文档进行推理而非仅仅提取文本的代理系统的解决方案。

Built面临以下挑战：

• 文档数量和种类：Built在建筑贷款、房地产金融、资产管理、合规和投资组合工作流程等多个领域处理超过250种文档类型。单个文档可能超过500页。

• 复杂且不一致的文档结构：许多文档包含嵌套表格、嵌入图像、扫描页面、自定义布局和非标准术语。

• 依赖上下文的提取：重要信息通常隐含在文本中、分散在多个章节中，或以领域特定语言表达，而非以明确标注的字段形式呈现。

• 高置信度要求：Built需要分类和提取工作流程的置信度超过95%，以支持财务和合规敏感流程的生产使用。

• 可扩展性和扩展性：Built需要一个解决方案，不仅支持单一产品工作流程，还要支持全年推出的多个基于代理的AI产品。

目标是使文档理解成为贯穿Built产品生态系统可重复使用的AI能力。

从基于OCR的提取到基于代理的文档理解

传统的基于OCR和机器学习的文档提取通常通过识别文本并将其与预期字段、标签、布局或先前模板进行匹配来工作。这在结构化文档中可能有效，但在需要判断、上下文或领域推理的任务中存在局限性。例如，查找贷款金额、发票编号或保单到期日期可能是相对直接的提取任务。字段通常明确标注，并位于可预测的文本附近。然而，查找贷款协议中的契约则有所不同。

契约通常不会以明确标注为“契约”的表格形式呈现。它们可能出现在长期协议的多个章节中。它们可能嵌入在法律语言中，通过引用其他章节来定义，或以借款人义务、限制、报告要求、财务阈值、违约触发条件或补救措施的形式表达。对“契约”一词的关键词搜索可能会遗漏实质内容。传统的提取模型可能找到这个词，但无法理解其背后的义务。

基于代理的文档工作流程可以以不同的方式处理这个问题。除了从文本中提取字段外，系统还可以在上下文中解释文档。它能够识别相关章节，对定义和义务进行推理，区分要求与例外情况，提取结构化输出，并为人工审核提供支持证据。

对于贷款协议，基于代理的工作流程可以：

• 识别文档类型和相关协议结构。

• 定位与借款人义务、财务报告、限制、违约和补救措施相关的章节。

• 推断哪些条款代表契约，即使它们没有明确标注。

• 提取契约名称、要求、阈值、频率、有效期限、责任方和违约后果。

• 为人工审核提供回溯到原始文档的参考信息。

• 将模糊或置信度低的结果转介给领域专家。

• 记录纠正信息并将其反馈至模式定义、提示工程和评估工作流。

这正是 Built 需要实现的转变：从文档提取转向文档理解。这种模式同样适用于整个房地产金融领域。代理人员需要判断保险覆盖是否满足要求、提款包是否包含必要文件、评估报告是否支持承销假设、投资说明书是否包含关键风险指标，或投资组合文件是否包含需要关注的例外情况。在每种情况下，文档不仅是文本来源，更是业务上下文的来源。

适用于 Built Technologies 智能体AI路线图的横向解决方案

Built 将新的文档智能解决方案设计为横向能力而非单一用途工具。首个生产用例聚焦于商业地产贷款提款包，借款人在施工项目期间提交文件集合以申请资金拨付。提款包是理想的验证场景，因为它们规模大、内容多变、时间敏感且运营关键。

然而，该解决方案有意设计为支持整个房地产金融领域。相同的分类、拆分、提取、评估和人工复核能力可跨多个智能体和工作流复用，包括：

• 提款审核智能体：分类包内容、识别缺失文件、提取发票和权益放弃数据、标记异常项。

• 贷款协议智能体：识别契约条款、报告义务、财务阈值、借款人限制和违约条款。

• 保险智能体：验证保险证明、保单声明、承保限额、附加条款、除外责任和有效期。

• 承销智能体：总结投资说明书、评估报告、租金清单、预算和财务模型。

• 资产管理智能体：监控持续报告包、识别变更、揭示投资组合级风险。

• 合规智能体：检查必要表格、许可文件、检验报告和监管文件。

这些智能体均依赖于相同的基础能力：将非结构化、不一致、高体量文档转化为结构化、验证过且可解释的智能信息。

通过将文档处理作为共享解决方案能力，Built 可加速AI路线图推进而无需为每个产品重建提取流水线。新智能体可复用相同基础设施进行数据摄入、分类、模式管理、提取、评估和人工复核。

架构深度解析：智能文档处理加速器与Amazon Bedrock

Built 与AWS GenAIIC及AND Digital合作，采用AWS智能文档处理（IDP）加速器作为基础构建解决方案。该方案使用Amazon Bedrock实现基于生成式AI的分类、拆分、模式生成、提取、评估和文档推理。

该解决方案通过 AWS Step Functions 协调的多阶段流水线进行处理。每个文档都会经过定义好的阶段序列：OCR、分类与拆分、提取、评估以及可选的规则验证。每个阶段均由独立的 AWS Lambda 函数驱动。本节将通过一个代表性示例说明该流水线：一个包含发票、留置权放弃书、保险证明和封面信的 150 页商业建筑付款包，这些内容以无特定顺序的单个 PDF 文件形式到达。

从高层次来看，流水线的工作流程如下。上传到 Amazon Simple Storage Service（Amazon S3）输入存储桶的文档会触发 Amazon EventBridge 事件。一个名为 Queue Sender 的 Lambda 函数会将事件记录到 Amazon DynamoDB 跟踪表中，并在 Amazon Simple Queue Service（Amazon SQS）队列中放置一条消息。Queue Processor Lambda 函数通过 DynamoDB 原子计数器管理并发性，当有可用容量时，会为文档启动 AWS Step Functions 执行。状态机随后按顺序运行处理阶段：首先执行 OCR，然后进行分类与拆分，接着是提取，再是评估，最后是处理结果的步骤。

提取过程在 Step Functions 的 Map 状态中运行，这是使解决方案能够并行处理分类部分的机制。当 150 页的付款包被拆分为组成文档后，每个部分都会获得独立的提取调用，并与其他部分并行执行。总处理时间由最长单个部分决定，而非所有部分时间总和。这也是为什么之前需要数天完成的工作流程现在能在几分钟内完成的原因。处理结果写入 S3 输出存储桶，AWS AppSync 通过 GraphQL 订阅向用户界面实时推送状态更新。

文档摄入与审核体验

AND Digital 构建了一个基于 React 的自定义用户界面，通过 Amazon Cognito 进行身份验证。该界面为用户提供了一个集中位置，用于上传文档、管理处理器、定义模式、审核提取结果、比较版本以及查看置信度评分。

自定义用户界面至关重要，因为 Built 需要该解决方案同时支持技术人员和业务领域专家。文档智能处理不能仅由工程团队管理。最了解文档的人往往是放款专家、运营团队、合规专员、产品经理和面向客户的团队。

当用户上传付款包时，文档会通过预签名 URL 存储到 Amazon S3，Amazon EventBridge 的上传事件会启动流水线。并发控制层（DynamoDB 原子计数器与 SQS 队列的组合）将 Step Functions 执行速率控制在 Amazon Bedrock 和 Amazon Textract 服务限制范围内。这使得同一流水线路径既能处理单个临时上传，也能处理 50,000 份文档的批量运行，无需任何修改。

OCR 与结构提取

当文档进入流水线时，AWS Lambda 会触发 Amazon Textract 提取文本、表格、表单、签名和结构层次。Textract 提供的文档结构是下游生成式 AI 工作流进行分类和提取所依赖的基础。对于大型文档，系统会逐页处理，这允许并行化，但在大规模处理时需要仔细管理并发性和限流。

OCR 阶段会将其输出标准化为后续阶段可使用的统一结构，为 Amazon S3 中每一页记录原始文本、解析后文本和页面图像的位置：

{
  "metadata": {
    "input_bucket": "<BUCKET>",
    "object_key": "<KEY>",
    "num_pages": "<NUMBER>"
  },
  "pages": {
    "1": {
      "rawTextUri": "<S3_URI>",
      "parsedTextUri": "<S3_URI>",
      "imageUri": "<S3_URI>"
    }
  }
}

该解决方案还可以使用 Amazon Bedrock 作为替代的 OCR 后端，处理传统 OCR 难以可靠识别的文档，例如低质量扫描件或密集的手写注释。OCR 后端是配置选择而非代码修改，因此团队可根据处理器需求选择 Textract 或 Bedrock。

智能分类和拆分

OCR 处理完成后，分类流程使用 Amazon Bedrock 确定文档类型并识别组合 PDF 中的边界。这在房地产金融领域尤为重要，因为单个文件包可能包含许多以不可预测顺序排列的文档。解决方案无需依赖具有严格页数限制的独立文档拆分器，而是能识别大型文件包内的组成文档，并保留其与整体交易的关系。

分类由可配置的提示驱动，该提示列出可用文档类型和示例集。提示缓存分隔符将静态指令与文档文本分离，使静态部分可在不同请求中重复使用：

classification:
  task_prompt: |
    将此文档分类到以下类别：
    {CLASS_NAMES_AND_DESCRIPTIONS}
    <few_shot_examples>
    {FEW_SHOT_EXAMPLES}
    </few_shot_examples>
    <<CACHEPOINT>>
    <document_content>
    {DOCUMENT_TEXT}
    </document_content>

<<CACHEPOINT>> 标记使 Built 在大规模处理时效率提升。缓存分隔符前的所有内容（如类别定义和示例）对处理器处理的每个文档都相同，因此 Amazon Bedrock 会缓存并跨请求复用这部分内容。只有标记后的文档文本在每次调用时会变化。对于定义十几个文档类别的 draw-package 处理器，这避免了对每个包每页重复处理相同指令。

文档拆分阶段生成的结构化结果将页码范围映射到文档类型。以示例 draw 包为例，输出将页面分组为带标签的章节：

{
  "sections": [
    { "id": "group-001", "class": "CoverLetter", "pages": [1] },
    { "id": "group-002", "class": "Invoice", "pages": [2, 3, 4, 5, 6] },
    { "id": "group-003", "class": "LienWaiver", "pages": [7, 8] },
    { "id": "group-004", "class": "InsuranceCertificate", "pages": [9, 10] }
  ]
}

每个章节组都会成为 Step Functions Map 状态中的独立任务，提取操作会针对该文档类型特定的模式执行。

动态模式生成和提取

该解决方案的一项关键能力是动态模式生成。用户可上传新文档类型的示例，Amazon Bedrock 会生成建议的提取模式：应从该文档中捕获的字段、结构和输出。然后领域专家可以优化模式，将其与示例进行测试，比较不同模型版本的输出，并创建新的处理器版本。

在内部，每种文档类型都通过 JSON Schema 进行定义，每个字段的描述会成为提取提示的一部分。解决方案的准确性很大程度上来源于此：包含值通常出现位置和名称的字段描述，比单独的字段名称更能有效引导模型。例如，留置权放弃声明的 Schema 会捕获放弃类型、承包商、项目、适用期间、金额以及任何例外情况：

classes:
  - $id: LienWaiver
    x-aws-idp-document-type: LienWaiver
    type: object
    description: >
      一份留置权放弃声明，其中承包商或供应商放弃针对已收到付款的财产提出机械留置权的权利。
    properties:
      WaiverType:
        type: string
        description: >
          放弃类型：有条件、无条件、部分或最终。请在顶部标题中查找这些术语。
      ContractorName:
        type: string
        description: >
          签署放弃声明的承包商或分包商。通常在“来自”或“申请人”字段中，或签名行上方。
      ProjectName:
        type: string
        description: >
          项目名称或地址。查找“项目”、“作业名称”或“财产”标签。
      ThroughDate:
        type: string
        description: >
          放弃适用的截止日期。可能标记为“截止日期”、“期间结束”或“工作截止”。
      AmountWaived:
        type: string
        description: >
          被放弃的金额，通常在放弃声明附近。
      ExceptionItems:
        type: array
        description: 放弃声明中列出的任何例外或排除项。
        items:
          type: object
          properties:
            Description: { type: string }
            Amount: { type: string }

x-aws-idp-document-type 注解将 Schema 与分类输出关联。当分类将第 7 和第 8 页标记为 LienWaiver 时，提取阶段会加载此 Schema，并根据这些页面的字段描述和 OCR 文本构建提示。在需要额外上下文的情况下，团队可以将少量示例附加到类别中（一个示例文档及其预期属性的配对），以演示对非常规布局的期望输出。

这种基于 Schema 的方法也使得支持超过 250 种文档类型成为可能。团队无需手动编写每个 Schema，而是使用 Accelerator 的发现功能从示例文档生成初稿：上传一个或多个示例，Amazon Bedrock 会提出一个包含字段名称、类型和描述的 Schema，供专家进一步完善。对于批量导入，解决方案可以通过相似性对大量示例文档进行聚类，并为每个聚类提出一个 Schema。

因为模式、提示和模型都是配置中的参数，Built 可以应用灵活的模型策略。对于标准发票或保险证明等简单文档，团队可以选择较小且更快的模型，例如 Amazon Nova Lite。对于需要更深入推理或更复杂布局解析的文档，如贷款协议或备忘录，他们可以选择通过 Amazon Bedrock 提供的较大模型，例如 Anthropic Claude。该解决方案针对不同文档和工作流程使用合适的模型，而不是强制所有用例通过单一提取方法处理。

置信度评分、人工审核与反馈循环

每个提取结果都包含字段级别的置信度评分。Built 在关键生产工作流程中要求置信度超过 95%，低于阈值的结果将被路由至人工审核员。

置信度评分来自专门的评估阶段，而非提取调用本身。提取完成后，Amazon Bedrock 的另一次调用会将提取的值与源文档和 OCR 文本进行比对，并为每个字段生成 0 到 1 之间的置信度评分、简短解释以及页面上支持证据的位置。以示例包中的留置权放弃书为例，评估结果可能如下：

{
  "WaiverType": {
    "confidence": 0.95,
    "confidence_reason": "标题显示 'CONDITIONAL WAIVER AND RELEASE ON PROGRESS PAYMENT'",
    "geometry": [{ "boundingBox": { "top": 0.05, "left": 0.2, "width": 0.6, "height": 0.04 }, "page": 7 }]
  },
  "AmountWaived": {
    "confidence": 0.72,
    "confidence_reason": "页面上有多个金额；在放弃声明附近选择了数值，但手写注释部分难以辨认",
    "geometry": [{ "boundingBox": { "top": 0.45, "left": 0.3, "width": 0.2, "height": 0.03 }, "page": 7 }]
  }
}

在此示例中，放弃类型达到了阈值，但放弃金额未达到，因此文档将被发送审核。审核员在分屏界面中工作：左侧窗格显示原始页面图像，并通过评估几何信息绘制边界框叠加图，突出显示每个值的来源位置；右侧窗格显示提取字段，通过颜色编码使低于置信度阈值的值更加醒目。审核员可以更正分类、更新提取值并标记部分完成。基于角色的访问控制在大规模操作中保持秩序。审核员处理其队列中的文档，而管理员则管理配置和用户。

重要的是，这些更正不仅限于单个文档。它们会反馈到解决方案的评估基准数据集中，因此修复一个文档包的审核工作也会改进用于下一个文档的模式、提示和示例。这种人机协作流程使 Built 能够扩大自动化规模，同时在最关键的地方保留专家监督。

文档推理

提取回答的是文档包含什么的问题。许多房地产金融工作流程还需要回答文档是否满足某项要求的问题。这之间的区别在于，从保险证明中提取保障限额，与判断该保障是否符合贷款协议条款。该解决方案通过两步规则验证流程，将文档与业务规则进行比对，支持这种需求。

首先，一个事实提取步骤会将相关文档部分发送到 Amazon Bedrock，并收集与特定政策领域相关的事实，同时附上每个事实的来源引用。其次，一个协调步骤会基于这些整理后的证据进行推理，并返回一个判断结果（合规、不合规或证据不足），并引用支持该判断的文档部分。规则本身以普通问题的形式表达，并按政策类别进行分组，这使它们保持在领域专家能够理解和掌控的语言层面：

policy_classes:
  - policy_type: "loan_covenants"
    questions:
      - "文档是否指定了债务服务覆盖率要求？"
      - "是否存在最低净资产维护条款？"
      - "是否有对新增债务的限制？"
  - policy_type: "insurance_requirements"
    questions:
      - "保险范围是否满足贷款协议中的最低限额？"
      - "贷款人是否被列为附加被保险人或损失赔付人？"

将事实发现与判断分离，使得在处理长而复杂的文档时更加可靠。事实提取步骤会集中模型的注意力，用于在数百页的协议中定位相关条款。协调步骤随后可以在不被文档其他部分干扰的情况下权衡证据。这与之前描述的代理模式相同，即识别相关部分、推理义务并提供证据供审查。

为什么协作模式和评估至关重要

要使代理式文档处理在生产环境中有效运行，团队需要的不仅仅是提示语。他们需要共享的定义，包括应提取的内容、正确答案的定义、如何衡量准确性，以及在部署前如何测试更改。

这在房地产金融领域尤为重要，因为许多提取任务是领域特定的。通用模型可能理解贷款协议、评估报告或保险证书中的词语，但 Built 的团队需要与这些文件的业务含义一致的输出。

该解决方案为技术团队和非技术团队提供了一个共享的工作空间：

• 模式设计：定义代理所需的字段、嵌套结构和输出。
• 提取测试：通过处理器运行文档并比较输出结果。
• 评估流程：通过标记示例和预期答案衡量准确性。
• 版本管理：跟踪模式、提示和模型配置的更改。
• 人工反馈：捕获审阅者的更正，并利用它们改进未来的性能。

这种协作使系统具备可扩展性。行业专家可以在不将每次更改都变成工程项目的前提下，塑造文档理解层。工程团队则可以通过版本化模式、评估、模型协调和部署流程来实现这些定义。

最终结果是一个随时间改进的文档智能解决方案，能够支持广泛的 AI 代理组合。

结果和影响

Built 的 AI 驱动的文档智能解决方案为更快速、更准确和可扩展的房地产金融工作流程奠定了基础。

关键成果包括：

• 从天到分钟：以前需要 3-9 天完成的分类和提取工作流程，现在每包文件可在几分钟内完成。

• 对复杂文档的支持：该解决方案能够处理数百页的文件包、嵌套表格、嵌入图像、扫描内容以及基于OCR的系统难以处理的非标准布局。

• 跨文档类型的扩展能力：该架构设计支持房地产金融工作流程中的250多种文档类型。生产工作负载已扩展至每月2000万份文档、每周30万份文档，以及超过5万次批量处理运行。

• 跨代理的横向复用：相同的文档智能能力可驱动多个代理AI产品，覆盖建筑贷款、保险、承保、资产管理、合规和投资组合智能等多个领域。

• 生产规模的吞吐能力：团队通过大规模批量处理运行和生产规模测试验证了该流程，包括在处理大型文档时解决Amazon Textract的限流问题。

• 以评估驱动质量：Built与评估工作流程的集成使团队能够测试模式变更、比较模型行为，并在将变更部署到生产环境之前维护置信度阈值。

• 人机协作的信任机制：低置信度或模糊的输出将被路由到审核人员，在保持专家监督的同时减少人工工作量。

结论

Built Technologies、AWS GenAIIC 和 AND Digital 的合作展示了生成式AI如何变革房地产金融领域的文档密集型工作流程。

通过使用 AWS Intelligent Document Processing Accelerator 和 Amazon Bedrock，Built 开发了一种可复用的文档智能解决方案，展示了房地产金融公司如何现代化文档处理流程。对 Built 来说，这一能力是其AI战略的基础。文档智能是横向层，使代理能够理解房地产金融工作流程，发现异常，加速决策，并将非结构化文档转化为可信的商业行动。

要了解如何使用 Amazon Bedrock 进行文档处理，请参阅 AWS 上的生成式AI文档处理。

要了解 GenAIIC 计划的更多信息，请参阅 AWS 生成式AI创新中心。

要探索 AND Digital 的 AWS 合作能力，请参阅 AND Digital 的 AWS 联盟。

Built 是一家面向房地产和建筑行业的AI驱动型财务运营平台。通过连接资本提供者、业主与开发商以及建筑商，Built 自动化工作流程，加速资金和信息流动，并解锁洞察力以做出更明智的决策。全球300多家顶级金融机构以及数千家业主和建筑商信任 Built 来管理数万亿美元的房地产和建筑活动，因此您可以减少流程时间，专注于取得进展。了解更多请访问 getbuilt.com。

作者简介

'\"`