多くの企業は、未活用のビジネスインテリジェンスを含む大量の紙または電子文書を保有しています。生成AIの進歩により、様々な大規模言語モデルを使用してこれらの文書から関連データを正確に抽出できます。この投稿では、Amazon Bedrock上でオンデマンド推論とバッチ推論の両方のオプションを備えたインテリジェントな文書処理パイプラインを紹介し、文書処理の時間とコストを柔軟に制御できるようにします。時間に敏感なリクエストにはオンデマンド推論オプションを使用でき、バッチ推論オプションは最もコスト最適化されています。また、文書レベルで大規模言語モデルとプロンプトを動的に指定する方法についても説明し、同じパイプラインで複数種類の文書からデータを抽出できるようにします。
ソリューション概要
もしあなたが、私たちの顧客の一人のように、何億もの土地リース文書をスキャンPDF形式（画像のみで編集可能なテキストがないPDF、例えばスキャンされた土地リースがPDFとして保存されている）でバックログに抱えており、新しい文書が毎日積み重なっている場合、これはこれらの文書から効果的にデータを抽出するために使用できるソリューションです。次の図に示すように、このソリューションはオンデマンドとバッチの2つの推論パイプラインを構築し、それらを動的に呼び出すメカニズムを備えています。Amazon Bedrock Prompt Managementで管理される効果的に設計されたプロンプトを使用することで、フォーマットや慣例が異なることが多いスキャンPDFやテキストファイルからデータを抽出し、標準化できます。
左側のパイプラインはオンデマンドパイプラインで、文書を1つずつ処理し、数秒以内に結果を返します。そのため、時間に敏感なリクエストに適しています。右側のパイプラインはバッチ推論パイプラインで、単一のAmazon Bedrockバッチ推論ジョブで複数の文書リクエストを処理し、モデル呼び出しは非同期で行われます。ユーザーは両方のパイプラインのリクエストでプロンプトIDとバージョンを指定でき、対応するプロンプトテキストがAmazon Bedrock Prompt Managementから取得されます。
1. オンデマンド推論パイプライン
オンデマンド推論パイプラインでは、Amazon SQS FIFOキューが作成されます。文書ID、LLMモデルID、プロンプトID/バージョン、システムプロンプトID/バージョンを含むキュー・メッセージが到着すると、AWS Lambda関数がトリガーされます。この関数は、指定されたAmazon S3バケットからPDF文書を取得し、PDFページをPNG画像に変換し、Amazon Bedrock Prompt Managementから関連プロンプトを取得し、LLMを呼び出すメッセージを構成し、結果をAmazon DynamoDBテーブルに保存します。
1.1 AWS SQS FIFOキュー
FIFOキューを使用する主な理由は次のとおりです。信頼性の高いメッセージ配信（各メッセージが正確に1回配信される）、厳密な順序処理、メッセージグループ化機能。キュー・メッセージは外部でAWS CLIまたはAWS SDK APIを使用して作成できます。例：aws sqs send-message --queue-url ... --message-group-id "1" --message-body "msg 1" --message-attributes file://message_txt.txt。Lambda関数はAmazon Bedrockが抽出データを返した後、キュー・メッセージを削除します。
1.2 Lambda関数によるメッセージ処理と推論
Lambda関数はキュー・メッセージのs3_location属性を使用してS3から文書をダウンロードします。スキャンPDFの場合は画像に変換します。Claude 4 Sonnetモデルはマルチモーダル呼び出しごとに最大20枚の画像しか許可しないため、20ページを超える文書は20ページずつのチャンクに分割する必要があります。文書ID、チャンク数、チャンクIDは、抽出結果やモデルパフォーマンスメトリクスとともにDynamoDBテーブルに保存されます。
次に、Amazon Bedrock Prompt Managementからプロンプトを取得します。土地リース文書の形式は様々であり、カスタマイズされたプロンプトを使用することで抽出精度が向上します。プロンプトには一意のIDとバージョンがあり、SQSメッセージでこれらを指定する必要があります。なお、リージョンあたり最大50のプロンプト、プロンプトあたり最大10のバージョンというサービス制限があります。
Lambda関数は、プロンプト本文と画像を連結してLLM用のメッセージを構成し、Converse APIを使用してAmazon Bedrockにリクエストを送信します。LLMはJSON文字列で抽出データを返し、最終的に解析してDynamoDBテーブルに保存し、SQSメッセージを削除します。
2. バッチ推論パイプライン
バッチ推論パイプラインでは、高スループットのために標準のAmazon SQSキューが使用されます。主要コンポーネントは次のとおりです。Amazon EventBridgeスケジューラー、バッチ推論Lambda関数（スキャンPDFを前処理し、JSONLファイルを作成してバッチ推論ジョブを投入）、Amazon EventBridgeルール、後処理Lambda関数。
2.1 Amazon EventBridgeスケジューラー
バッチ推論Lambda関数をスケジュールに従って起動します。
2.2 バッチ推論Lambda関数
関数はまずキューに十分なメッセージがあるか確認します（執筆時点では、Amazon Bedrockバッチ推論ジョブには最低100レコードが必要）。次に、キュー内のメッセージをループ処理し、文書ID、LLMモデルID、プロンプトID/バージョンを抽出します。オンデマンドパイプラインと同様に、文書を取得し、スキャンPDFの場合は画像に変換し、大きなファイルは分割します。標準キューは正確に1回の配信を保証しないため、重複メッセージは無視されます。
異なる文書形式には異なるユーザープロンプトが必要であり、SQSメッセージでプロンプトIDとバージョンが指定されます。Lambda関数はAmazon Bedrock Prompt Managementからプロンプト本文を取得します。次に、メタデータファイルとJSONLファイルを作成し、バッチ推論データS3バケットにアップロードし、SQSメッセージを削除します。最後に、JSONLファイルを使用してAmazon Bedrockバッチ推論ジョブを作成します。1つのバッチジョブは1つのモデルしか処理できないため、関数は最も頻繁に指定されたモデルIDを選択します。
2.3 Amazon Bedrockバッチ推論ジョブ
ジョブが開始されると、JSONLファイルを取得し、推論完了後に出力を指定のS3バケットに保存し、Amazon EventBridgeにジョブステータス変更イベントを送信します。
2.4 Amazon EventBridgeルールが後処理Lambda関数をトリガー
後処理Lambda関数はバッチ推論データS3バケットから出力JSONLを取得し、解析して抽出された土地リース属性をDynamoDBテーブルに保存します。
前提条件
この例を試すには、AWSアカウントとCloudFormationスタックを作成・管理する適切なIAM権限が必要です。
CloudFormationスタックのデプロイ
オンデマンドパイプラインをデプロイ：起動スタックリンクをクリックしてAWS CloudFormationに移動し、手順に従ってスタックを作成します。IAMリソース作成を承認して送信します。同様の手順でバッチパイプラインもデプロイします。
パイプラインのテスト
オンデマンドパイプラインのテスト：サンプルデータ（3つの土地文書）をダウンロードし、S3にアップロードした文書を使用してSQSメッセージを作成します。数秒後、DynamoDBで抽出結果を確認できます。バッチパイプラインは少なくとも100の文書がある場合にテストできます。