30秒サマリー
- Amazon TextractとAmazon Bedrockを組み合わせ、複雑な帳票類のRAG精度を改善する構成をAWSが公式ブログで解説
- 生のPDF等をそのままRAGに投入すると情報欠落やハルシネーションが頻発する課題に対し、Textractで前処理することで精度を向上
- CloudFormationで一括デプロイできるサンプル構成とGitHubコードも公開されている
何が起きたか
AWSは公式機械学習ブログにて、Amazon TextractとAmazon Bedrock Knowledge Basesを組み合わせ、複雑なPDF・画像などの帳票文書を高精度にRAG（検索拡張生成）処理する実装方法を解説した。
ブログが示す課題は、PDF・DOCX・TXT・HTML・XLSX・PNGなど多様なフォーマットの文書を生のままRAGモデルに投入した場合、LLMが口座番号・支払期日・請求金額といった重要情報を見落としたり、誤った情報を生成するハルシネーションが発生したりするという点だ。ユーティリティ料金明細（電気・水道等の請求書）を扱うカスタマーサービス部門の事例を題材に、この問題が具体的に説明されている。
提案する解決策は、Amazon Textractを前処理パイプラインとして用いることで、複数ページにまたがる複雑なレイアウトや埋め込み表・画像からテキストを高精度に抽出し、不要なノイズを除去してからAmazon Bedrockのナレッジベースに格納するというものだ。インフラはAWS CloudFormationで一括構築でき、Lambda関数・S3バケット・Amazon OpenSearch Serverlessクラスター・Bedrock Knowledge Basesが自動的に作成される。ファイルをS3にアップロードするとLambdaが自動起動し、Textractによる解析・TXT変換・ナレッジベースへの格納が順次実行される。推論モデルにはAmazon Nova Microが使用例として挙げられている。
なお、本記事はこの構成の実装解説を目的としたブログ投稿であり、新サービスや新機能の一般提供開始を告知するものではない。本番環境への導入にあたっては、Amazon Bedrock Guardrailsによる有害コンテンツフィルタリングやグラウンディング検証の活用をAWSは推奨している。
原典ハイライト
「生の文書をそのままRAGに投入するだけでは、重要情報の欠落やハルシネーションが頻発する。Amazon Textractによる前処理——テキスト抽出・クレンジング・タグ付け——を挟むことで、LLMが必要な情報を正確に参照できるようになる」というのが本解説の核心。GitHubにサンプルコードとCloudFormationテンプレートが公開されている。
出典: AWS Machine Learning Blog（公式ブログ）
So What?（なぜ重要か）
社内文書のAI活用において「まずLLMに文書を読ませる」という単純なアプローチは、複雑なレイアウトや表を含む帳票類では精度が安定しない。Textractのような専用OCR・文書解析サービスを前段に置く「前処理ファースト」のアーキテクチャが、信頼性の高い業務用RAGシステム構築の標準的な設計パターンとして浮かび上がっている。
日本企業への示唆
請求書・契約書・申請書など、表や複数レイアウトが混在する社内帳票をRAGで活用しようとしている日本企業にとって、このAWS構成は直接参考になる。既存の社内AI実証でLLMの回答精度が低い場合、文書の前処理が不十分である可能性を疑うべき段階にある。AWS環境を使っているのであれば、CloudFormationテンプレートとGitHubコードを活用することでPoC構築のリードタイムを短縮できる。また、本番展開時にはGuardrailsによるハルシネーション検出と機密情報マスキングの実装を、コンプライアンス対応の観点から検討することが求められる。
背景・経緯
Amazon Bedrock Knowledge BasesはフルマネージドのRAG基盤サービスであり、Amazon TextractはAWS提供の文書テキスト抽出サービス。両者の統合自体は以前から可能だったが、今回のブログは複雑な帳票処理という具体的なユースケースに絞り、前処理パイプラインの実装手順をステップバイステップで解説した点が実務上の参考価値を持つ。
