re:Invent 2024: Allianz Germany レガシー移行を AI で加速
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Allianz Germany: Accelerating legacy migration with generative AI (FSI323)
この動画では、Allianz GermanyのSenior Data ScientistとSolution Architectが、レガシーシステムからの大規模なデータ移行をGenerative AIとServerlessアーキテクチャで実現した事例を紹介しています。従来の手作業による2万件の契約書移行を見直し、残り1万件の契約をAIで自動化。Amazon S3、AWS Step Functions、AWS Lambda、Amazon Bedrock（Claude 3.5 Sonnet）を組み合わせたパイプラインを構築し、最大150の属性を84%の精度で抽出することに成功しました。Human-in-the-loopの原則を取り入れ、ビジネスユーザーが抽出結果を承認・却下できるフロントエンドも実装。従来型の移行と比べて高い精度とユーザー受容性を実現した革新的なアプローチを詳しく解説しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Allianz GermanyのServerless AIを活用したレガシーシステム移行プロジェクト
みなさん、こんにちは。私はAllianz GermanyのSenior Data ScientistのAlexander Höwelerです。ドイツの損害保険市場向けにServerlessな大規模AIサービスを構築するData Scienceチームの一員として働いています。そしてこちらがPhilippです。ありがとうございます。私はPhilipp Kloseと申します。AllianzでSolution Architectとして働いており、特にAlexanderとData ScienceやMachine Learningの分野で協力させていただいています。
会場の中で、レガシーシステムやコアシステムの移行を経験された方なら、これが通常、非常にリスクが高く、コストがかかり、多大な時間を要する作業であることをご存知でしょう。これは多くの場合、レガシーシステムが古いプログラミング言語を使用していることが原因です。プロセスやシステム、さらにはデータを本当に理解している人材がいません。データを移行する際には、古いデータを理解できない新しいデータにマッピングする必要があるため、新しいシステムについても理解が必要になります。しかし朗報があります。Generative AIの能力と、Financial Services Industry企業の大半において、コアシステム内のデータの大部分が契約や顧客とのやり取りに基づいているという事実を活用することで、レガシーシステムを排除し、文書、契約書、顧客とのコミュニケーションをGround Truthとして使用することで、移行を効率化し、データを直接新しいシステムに移行することができます。これがAlexanderが今から紹介するプロジェクトを生み出したアイデアです。
ありがとう、Philipp。このプロジェクトの範囲についてもう少し詳しくお話ししたいと思います。Philippが説明したように、私たちはレガシーシステムから新しいシステムへのデータ移行について話しています。私たちのケースでは、このデータは契約書、つまりPDF文書に含まれています。 このアイデアは、お客様の20,000件の契約を従来の方法で手作業により移行することから始まりました。これは非常に時間のかかるアプローチで、予定していたスケジュールに間に合わないことが分かったため、私たちは従来のアプローチを完全に見直す必要がありました。そして、その結果が今日ご紹介する私たちが構築したものです。
現在、このプロジェクトの範囲は、 Generative AIとServerlessのアイデアを活用して、自動または半自動で移行する残りの10,000件の契約です。 私たちのアイデアの最も重要な点は、レガシーシステム内のデータではなく、文書がGround Truthを構成するということです。これは重要なポイントで、Philippが示したように、レガシーシステムのデータを経由する中間部分を通ることなく、AからDへ直接移行できるようになりました。
現在、私たちは契約から最大150の属性を抽出しようとしています。これは属性によって抽出の精度が異なります。Allianz Germanyの契約書の場合、データの品質は比較的良好です。しかし、サードパーティの契約書のデータ品質は課題となることもあり、これが属性抽出の品質にばらつきが生じる理由です。私たちの目標は、もちろんこれらのデータを正確に抽出して表示することです。しかし、これらのデータ属性を構造化された形でビジネスユーザーに表示するだけでも、すでに大幅な時間削減効果が見られています。
フロントエンドで抽出したデータ属性をビジネスユーザーが承認または却下できる仕組みを導入しています。この詳細については後ほどご説明いたします。基本的に、私たちはHuman-in-the-loopの原則に従っています。データ属性の抽出は自動または半自動で行われますが、同時にHuman-in-the-loopの原則も維持しています。
ビジネスユーザーはこれらのデータ属性を承認または却下することができ、これにより最も重要な要素である高品質なデータを確保することができます。そして最後に、 パイプラインはバッチ処理で実行されます。ビジネスユーザーは毎日、各契約に関連する顧客データをアップロードすることができ、夜間にそれらのデータ属性が抽出され、翌日にはビジネスユーザーがフロントエンドでその結果を確認して操作することができます。
Serverlessパイプラインの仕組みと実装のポイント
ここで、実際のパイプラインの仕組みについてご説明したいと思います。基本的に、私たちのアイデアをスケールさせ、データサイエンティストの作業をできるだけ効率的にするため、可能な限りサーバーレスにすることを心がけています。すべては関連文書をAmazon S3バケットにアップロードすることから始まります。 その後、AWS Step Functionsワークフローが続きます。このAWS Step Functionsワークフローは、S3にアップロードされた全バッチに対して実行されます。 次に、AWS Lambda関数が2つのことを行います。まず、 パイプラインで失敗した以前のアップロード文書をチェックし、新しい文書が入ってきているかどうかを確認します。これらをPythonのドキュメントIDリストにまとめ、そのリストを使って下流のパイプラインを処理します。
次に分散マップ関数があり、 入力された全文書を並列処理します。分散マップ関数は各文書に対して実行され、AWS Step Functionsワークフローは全バッチに対して実行されます。この分散マップ関数内では、OCRや、データクリーニングなどを行い、最も重要な処理として、Amazon Bedrockを通じてClaude 3.5 Sonnetを使用してデータ属性を抽出します。 その後、データを集約します。これは私たちのプロセスのもう一つの重要な側面です。 古い文書から得られたデータと、より新しい文書から得られた同じデータがあるとします。私たちは、これらのデータ属性にランク付けを行います。より新しい文書からのデータ属性があれば、そちらを高くランク付けします。これにより、新しいシステムで正確なデータを持つだけでなく、常に最新のデータを維持することができ、これはデータ品質とその向上に向けた大きな一歩となります。
そして当然ながら、 結果をAmazon S3から読み取り、書き戻しも行います。最後に、もう一つのAWS Lambda関数があり、これはAmazon Auroraデータベースに接続されており、 各文書のステップと各文書IDの状態を更新して、関連文書を見逃さないようにしています。では、テストデータを使用した例を お見せして、フロントエンドの実際の動作をご説明したいと思います。これは小さなデモです。右側に、当社が保険を提供しているお客様の文書が表示されています。表を見ていただくと分かるように、このお客様は様々なリスクに対して保険をかけています。例えば、強盗や窃盗のリスクに対する保険があり、右から2列目を見ると、補償限度額はゼロ（制限なし）で、免責金額は1,000ユーロとなっています。
このデータ属性は私たちのモデルによって抽出されたものです。左側をご覧いただくと、ソースがAIであることが分かります。これは私たちのクラウドモデルから得られたものだからです。控除額の値は1,000ユーロで、この場合は正しい値です。また、この情報がどのページで見つかったのか、そして業務ユーザーが理解できるように、なぜこの属性が抽出されたのかという理由も表示しています。下部には代替案も表示されています。可能な限り、業務ユーザーに代替案も提示するようにしています。この同じデータ属性に対する代替案は、Firmwareという名前の従来システムから得られたものです。
今回の値は25,000ユーロで、ユーザーはこのデータ属性を承認するか却下するかの判断を下すことができます。このデータ属性は誤りで、この特殊なケースでは、従来システムから得られた古いデータであり、最新の文書で更新されていないことが原因です。ここでもお分かりいただけるように、私たちのアイデアの重要な点は、新システムに正確なデータを持つだけでなく、最新のデータを持つことなのです。
では、データ移行を実施中または検討中の方々と共有したいアイデアについて、いくつかポイントをお伝えしましょう。外部の専門家によって従来型のデータ移行が行われていた昔を思い出してください。データを渡して戻ってくるのを待ち、そして多くの場合、戻ってきた低品質なデータに苦しむことになりました。私たちの場合は、ユーザーとより密接に連携しています。ユーザーは私たちのServerlessパイプラインとプロセスに積極的に関与することができます。そのため、従来型の移行と比べて、はるかに高いビジネスユーザーの受け入れを得ることができています。
また、私たちが特に誇りに思っているのは、すべてではありませんが、特定のデータ属性については、パイプラインの精度が84%に達していることです。これは重要なポイントです。100%の精度は決して得られません。AIは決定論的ではありません。そのため、可能な限り最高の結果を得るために、AIによる自動抽出という従来のアイデアとHuman-in-the-loopの原則を組み合わせることで、データ属性の精度を可能な限り高めているのです。
私たちが非常に早く進展できた理由は、今年初めに、AWSの専門家とAllianz Germanyのデータサイエンティストと共に、今年2月のGen AI Labsでキックオフを行ったことです。そこで、このアイデアをServerlessで、かつスケーラブルな方法で実装する方法について、すでに検討を始めていました。そのおかげで、最初から非常に速いペースで進めることができました。
また、最初の段階で評価フレームワークについて考えることが重要だということもわかりました。LLMやプロンプトを扱う場合、プロンプトを素早く調整して、その結果を確認し、Ground Truthと照らし合わせてテストする必要があります。プロンプトを変更・改善した際の結果をすぐに確認し、より良い品質を得るために、このプロセスをできるだけ迅速に行うことが重要です。
そして、これは強調しすぎることはないのですが、必ずビジネスユーザーをアイデアに巻き込むようにしてください。これは単に結果の評価をしてもらうだけでなく、旧システムのデータ構造、データ品質、データフォーマットについて、同僚のノウハウを得ることも含みます。旧システムは新システムとは大きく異なっている可能性が非常に高いのです。
そして最後に、誰もが直面している大きな課題として、データ品質の問題があります。私たちのケースで言えば、文書の分類について考えてみましょう。システム内で契約書として分類されているすべての文書が、必ずしも契約書であるとは限りません。この問題にも対処する必要があります。では、どのように取り組んでいるのでしょうか？冒頭で申し上げたように、パイプラインを肥大化させないよう、関連する文書を選別する必要があります。そこでも、ビジネスユーザーの知見と関与を活用しています。
以上で終わりです。私たちがどのように移行を行い、Allianz Germanyのような大規模企業で、Gen AIとServerlessのアイデアを活用して、いかに革新的な方法で移行を実現しているかについて、簡単な洞察をお伝えできたと思います。ご清聴ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion