Builtが不動産金融文書のレビューをAmazon Bedrockで短縮

AWSは、不動産金融向けのBuilt TechnologiesがAmazon BedrockとIntelligent Document Processing Acceleratorを使い、多様な文書をエージェントが利用できる構造化データへ変換した事例を紹介しました。

要点

• 250種類以上、最大500ページの文書を対象に、分類、分割、抽出、評価、推論を再利用可能な流れにしました。
• 単純なOCRでは扱いにくい契約条項や文脈を読み取り、数日かかる処理を分単位へ縮めたとしています。
• 業務投入には95%を超える信頼度を求め、低信頼の結果を人へ回します。
• 抽出値だけでなく、参照元と判断理由を残して人が確認できるようにします。

今回のブログ記事で語られていること

Builtは、5000億ドルを超える不動産プロジェクトを扱う基盤で、融資申請、工事進捗、請求、検査、契約など多数の文書を処理します。対象は250種類以上で、単一文書が500ページに達する場合もあります。従来のOCRで文字を取り出すだけでは、複数ページにまたがる契約条件、例外、金額の関係、表の意味を業務判断へ使える形にできません。事例ではAWSのIntelligent Document Processing AcceleratorとAmazon Bedrockを組み合わせ、文書を分類し、適切な単位へ分割し、必要項目を抽出し、結果を評価して推論へ渡す共通基盤を作りました。

共通基盤にした理由は、案件ごとに個別の抽出処理を作ると、モデル変更、監視、評価、人手確認がばらばらになるためです。処理段階を分ければ、分類を誤ったのか、ページ分割で文脈を失ったのか、抽出した値が違うのかを追跡できます。Builtは数日かかっていた流れを分単位へ縮めたとしていますが、不動産金融では速さだけでなく誤りの影響が大きいため、95%を超える信頼度を業務投入の目安としました。閾値を下回る結果は人のレビューへ送り、エージェントが不確かな値を確定情報として使わないようにします。

信頼度はモデルが返す自己評価だけでは不十分です。文書種別と項目ごとに正解データを用意し、金額、日付、当事者、契約条項など重要度に応じて基準を変える必要があります。抽出値には元ページ、該当箇所、使用したモデルと版、処理時刻を結び付け、人が原文へ戻れるようにします。文書内に悪意ある指示が含まれる可能性もあるため、文書本文をエージェント命令として扱わず、許可した抽出・検索だけを行う境界も必要です。

今回のブログ記事が関係する人

契約・融資・請求文書を扱う業務部門、文書AIを構築する開発者、精度基準と人手レビューを管理するリスク・コンプライアンス担当に関係します。

結局、今回のブログ記事をどう読むべきか

大量文書をモデルへ入れる事例ではなく、分類から人手確認までを測定可能な工程へ分解した事例です。自社では重要項目別の合格率、低信頼時の振り分け、原文への参照を先に設計するとよいでしょう。