Amazon Bedrock、複雑文書向けナレッジベース活用 毎月数千件の請求書対応を想定
- Amazon Bedrockのナレッジベース活用例です。
- Amazon Textractと組み合わせて文書を処理します。
- 公共料金請求書への問い合わせ対応を想定します。
AWS Machine Learning Blogは、Amazon Bedrockのナレッジベースを大規模で複雑な文書向けにカスタマイズする方法を紹介しました。公共料金請求書を扱うカスタマーサービスチームが、複数ページの文書や密な表、異なるレイアウトから必要な情報を取り出す場面を想定しています。
記事では、Amazon Textractによる構造化コンテンツと非構造化コンテンツの抽出を、Amazon Bedrockの生成AI機能と組み合わせます。手作業で文書を検索する運用から、プログラムで文書に問い合わせる運用へ移せると説明しています。
対象文書はPDF、DOCX、TXT、HTML、XLSX、PNGです。公共料金請求書を取り込み、前処理し、内容を分析し、関連する表にタグを付けることで、LLMが有用な情報を抽出しやすくします。
記事では、元の請求書をそのままRAGに読み込ませる方法では、期日、支払額、口座番号などの重要情報を取りこぼす場合や、不正確な情報を生成する場合があるとしています。Amazon Textractで抽出データを整理し、不要な情報を除くことで、より信頼できるRAGベースの対応を目指します。
つまり、請求書の PDF をそのまま AI に読ませても、支払期日や口座番号を見落としたり、あべこべな答えを返したりします。そこで先に「Amazon Textract」という読み取り役が、表や項目を整理してから AI に渡します。人間で言えば、書類の山を新人にいきなり渡すのではなく、担当者が付箋を貼って項目ごとに並べ替えてから渡すようなものです。
性能の話がほとんど出てこない紹介です。中心にあるのは、生の請求書を読ませたら重要な数字を取りこぼした、という失敗談のほうでした。
AI に社内文書を読ませる話になると、どのモデルを使うかに関心が集まりがちです。ただ、実務で詰まるのは手前の工程だと筆者は思います。公共料金の請求書は会社ごとにレイアウトが違い、表も入り組んでいます。そこを整理せずに渡した結果が、期日や口座番号の欠落でした。前処理を挟んで、表にタグを付けてから読ませるという地味な手順が、ここでは答えになっています。
対応形式は PDF、DOCX、TXT、HTML、XLSX、PNG。紙とエクセルが混在する日本の請求業務にはわりと現実的な組み合わせです。
毎月大量の請求書を扱っていて、社内で AI 検索を試して精度が出ずに止まっている担当者なら、モデルを変える前に読み取りと整理の工程を疑ってみる価値がありそうです。AWS はこの構成の実装コードを GitHub で公開しているので、次はこの前処理の型が請求書以外の書類、たとえば契約書や検査報告書にどこまで広がるかを見たいです。
公共料金請求書など複雑な文書を使って顧客対応用RAGを構築する企業に関係します。
