re:Invent 2024: 3社のデータ活用事例 - Gen AI、不正検知、Composite AI
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Innovate with analytics and governance: Customer Panel (ANT203)
この動画では、AWSのData and AI Governanceのプロダクトヘッドを務めるShikha Vermaをモデレーターに、Natera、NatWest、Amazon Transportationの3社のデータ活用事例が紹介されています。Nateraでは臨床検査データと患者データをGen AIで統合し、NatWestでは不正検知のためのグラフ埋め込みモデルを構築し、Amazon Transportationでは配送ステーションの問題分析にComposite AIを活用しています。また、Data Meshやガバナンスの実装方法、DataZoneの活用事例など、大規模組織でのデータ活用の実践的な知見が共有されています。特にGenerative AIの導入においては、現時点では実現不可能と思えるような課題にも挑戦することの重要性が強調されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
パネリストの自己紹介：データとAIの最前線
このような素晴らしいパネリストの皆様とご一緒できることを嬉しく思います。これから、パネリストの方々が各社で実現してきたAnalyticsとガバナンスに関するイノベーションについてお話しいただきます。私はAWSのData and AI Governanceのプロダクトヘッドを務めるShikha Vermaです。それでは、パネリストの皆様に自己紹介をお願いしたいと思います。
私はVP of EngineeringのMirko Buhholzerです。AWSとは長いお付き合いがあります。re:inventがVenetianだけで開催されていた頃を今でも覚えています。私の趣味についてですが、アクションスポーツが大好きで、雪上や空中で私を見かけることがあるかもしれませんね。
こんにちは、Zachery Andersonです。NatWestのChief Data and Analytics Officerを務めています。私も様々な企業でAWSを長年活用してきました。面白い経歴としては、銀行に来る前はゲーム会社に勤めていました。Electronic Artsで働いていた時、Redditの歴史上最も多くのダウンボートを記録した投稿の一つ（約1000万のダウンボート）に関わっていました。当時は大変でしたが、今となっては興味深い経験だったと思います。
皆さん、こんにちは。私はSiva Vaidyanathaと申します。Amazonに所属しており、荷物を時間通りにお届けするためのシステムを裏方で構築している一人です。AWSとは長いお付き合いがあり、最初はCTOとして、その後は病院で、そしてスタートアップを経て、現在はAmazonで働いています。私たちはSageMakerを広範に活用してきました。以前は配送ルートの最適化に革新的なディープラーニングを実装し、現在はSageMakerプラットフォーム全体を活用しています。私の趣味についてですが、ロック音楽の大ファンで、特にLed Zeppelinが大好きなんです。驚くべきことに、去年Robert Plantと偶然出会い、写真も撮らせていただきました。
Generative AIがもたらすデータ活用の変革
皆様にここでご自身の経験を共有していただけることを大変嬉しく思います。それでは始めましょう。ここにいらっしゃる方で、Generative AIについて聞いたことがない方はいらっしゃいますか？Generative AIについて聞いたことがない方、あるいは現在その影響を受けていない方はいらっしゃいますか？いないようですね。これは時代のテーマであり、世界中のビジネスを変革するイノベーションを推進しているのです。
皆さんはAnalyticsとガバナンスのセッションに参加されているということは、データに関わる方々だと思います。データの専門家だと自認される方はいらっしゃいますか？はい、何人かいらっしゃいますね。私も間違いなくデータの専門家です。Generative AIアプリケーションにおいて、皆さんのデータは差別化要因となります。なぜなら、モデルをカスタマイズせずに一般的に得られる結果は、ごく表面的なものに過ぎないからです。Generative AIシステムの真の価値は、ビジネスに合わせた結果を生み出すために使用する、皆さん独自のデータにあるのです。
企業はますますデータドリブンになることに投資を増やしています。ここにいらっしゃるCDO、VP、Directorの方々の会社も、かなりの投資をされています。CDOを任命する企業が増えていますね。Zackさん、仲間が増えていますよ。私がChief Data Officerを始めた頃は、世界中でもそれほど多くはありませんでしたが、今では随分増えています。私たちの調査によると、82%の組織がCDOを任命しており、94%が2023年と2024年により多くの投資を行っています。20%が収益の成長を実感していますが、それでも74%の企業がデータドリブン化に失敗しているのです。
これらのリーダーたちは、そして皆さんもきっと、データについてよくご存知でしょう。だからこそ、今日ここにいらっしゃるわけです。彼らの学びと、それをどのように実現したかについてお話ししましょう。自社が完全にデータドリブンだと言える方はいらっしゃいますか？まだそう言える企業は少ないですね。あ、そちらのグループはデータドリブンなんですね。素晴らしい。Q&Aセッションでぜひお話を伺いたいと思います。興味深いことに、これらの事実に関連して、CDOとCDAOの平均在任期間はわずか2年程度なんです。CEOやCMOよりも短いというのは、考えてみると驚きですよね。
その理由の一つは、74%が任された仕事を達成できていないからです。私たちが直面している問題、つまり、膨大なデータの拡散とツールの拡散は、2年程度では解決できないのです。これは長期的な取り組みが必要です。複数年にわたるイニシアチブに着手する必要があります。ありがたいことに、今では少し速く進められるGenerative AIという切り札を手にしています。
ヘルスケア業界におけるGenerative AIの活用事例
パネリストの方々が共有してくださるユースケースについて、とても楽しみにしています。これらの課題は皆さんにとって身近なものですか？挙手してください - 見覚えがありますか？大量のデータ、様々な種類のデータ、多くのツールに対処していますか？そうですよね。では、最初の質問に入りましょう。ここには3人の業界のエキスパートがいらっしゃいます：Nateraのヘルスケアライフサイエンスを代表するMirkoさん、金融サービスを代表するZacheryさん、そして大規模な物流、Amazon Transportationを代表するSivaさんです - そのスケールは途方もないものです。皆さんの会社や業界で、データアナリティクスとMLの世界がGenerative AIによってどのように変化しているのか、ぜひお聞かせください。
Nateraは基本的に臨床検査ラボです。私たちは多くの検査を行っており、米国では最近1,000万件の検査を突破しました。検体の取得、DNAシーケンシング、解釈、そして患者への報告を行っています。ここで重要なのは、遺伝子データと結果だけでなく、臨床データを実際に活用できることです。この2つを組み合わせることは、多くのヘルスケア企業にとって夢のような目標ですが、それを一貫性のある迅速な方法で実現することが重要です。過去にも実施してきましたが、手作業での実行は本当に困難でした。非構造化データを確認し、EMRレコードやプログレスノートから意味を見出し、組み合わせたい情報を抽出しようとする人々がいました。
Gen AIの分野では、ここ2年ほど、はるかに大規模にそれを実行する機会を得ています。これまでは先ほど述べたように、チームが手作業でこれを行っていました。しかし今ではGen AIを活用することで、LLMを使用して、これらの異なる非構造化データソースで利用可能な膨大な資料やテキストを分析できるようになりました。これらのデータソースを見ると、病理レポートやプログレスノートを評価を通じて取得しています。医師が私たちに検査を依頼する際には、患者の臨床情報が送られてきますし、EMRや他のデジタルチャネルにアクセスして追加の臨床情報を取得することもできます。
これらの文書をアーカイブしてテキストを抽出する機能は以前からありました - これは新しいことではありません。実際の文書をOCRで処理したり、情報を直接抽出したりすることはできましたが、現在では、その情報を取得してLLMと一緒に使用しているVector Storeに保存できるようになりました。Vector Storeにより、臨床患者情報の中から、意味的に抽出したい情報を見つけることができるようになりました。私たちは、投薬、患者の治療、手術、対応する日付などを調べ、患者の完全な履歴を作成し、実際の検査結果とともにその経過を示すことができます。これが、その上で実行できるワークロードの種類であり、シンプルなプロンプトを使用して、それらの臨床属性を正確に抽出し、検証することができます。もちろん、その大部分はLLMを通じて実行できます。例えば、LLMを判定者として使用し、抽出されたデータを確認してデータが有効かどうかを確認することが重要です。
ただし、一部のプロセスではHuman-in-the-loopの検証が必要になる場合があります。データをData Meshにプッシュする前に、データが正しいことを確認するため、そのようなケースをエスカレーションします。そこから、私たちの検査を利用している患者のデジタルヘルスレコードを持つことができます。
この応用の特に良い例は、特定の患者のがん治療をモニタリングする検査の一つです。ここで見ているのは、臨床データと検査データの両方から抽出した、ステージIIの膀胱がん患者の完全ながん治療の経過です。患者は最初に非侵襲的な処置とNeoadjuvant Chemotherapyを受けており、これがラインの最初のデータポイントとして表示されています。181日目に、医師は手術を行ってTumorを除去することを決定し、そのTumorサンプルから指紋を作成しました。現在、継続的な治療中に、その患者の体内でまだ何個の細胞が見つかるかを経時的に追跡することができます。
ご覧のように、最初の3つのデータポイントでは検査結果が陰性を示しており、治療が効果を上げていたことがわかります。しかし、456日目のポイントで検査結果が陽性に転じ、その患者さんに何かが起きていることを示していました。この情報により、医師は遠隔転移（Distant recurrence）の可能性を認識し、それは573日目に確認されました。その後、医師は放射線治療（Radiotherapy）と免疫療法（Immunotherapy）を実施し、ご覧のように最後には検査結果が再び陰性域に戻りました。このような患者さんの経過を、検査データと臨床データを組み合わせて作成することが、Gen AIとLLMsによって、当社の検査室を利用するすべての患者さんに対して可能になりました。以前は少数の患者群に対してしかできなかったことが、今では全員に対して実施できるようになったのです。
このコレクションは、ビジネスの観点だけでなく、医療や治療の観点からもいかに有用であるかを示しています。今では、これらすべての患者さんの経過を組み合わせて分析することができます。画面に表示されているのは、それぞれの横線が1人の患者さんの経過を表している複数の経過図です。実際の検査結果、実施された処置、治療法、そして結果を確認することができます。これにより、医師は現在治療している患者さんと似たケースを比較し、治療のタイムラインを計画することができます。また、異なる患者さんを比較することで、新しい治療戦略を検討することもできます。
金融サービスにおけるGenerative AIの革新的応用
これは、当社の検査室に届く臨床記録から非構造化データを抽出し、すべての患者さんに対して一貫した形で適用している明確な例です。とても興味深い例だと思います。医療関係の方はいらっしゃいますか？このような例は共感していただけますでしょうか？Q&Aセッションでさらにお話できれば幸いです。 では、金融サービスが直面している課題と、Zachがデータとのチャットで取り組んでいることを見てみましょう。Generative AIの分野で最も興味深い点の1つは、関与する人々の変化です。私のキャリアの大半において、データサイエンティストは、機械学習モデルや技術の可能性についてビジネス部門の人々に関心を持ってもらうよう働きかける必要がありました。しかし、Generative AIの登場により、現在では全ビジネスユニットにカウンシルが設置され、それぞれの事業でAIをどのように活用できるかについて、何百ものアイデアが寄せられるようになりました。
リーダーとして、現在はかなり難しい状況です。以前は簡単にリソース管理ができていましたが、今では各事業部門からの要望に追いつくことが課題となっています。この変化は、銀行内でGenerative AIを展開する方法を考える上で、私たちにとって大きな影響を与えています。
私たちは、SageMakerを使用して展開できるツールを構築し、銀行の多くの技術チームが展開できるアプリケーションを作ることを考えています。そして次に、長期的な視点で何が可能になるかを考え、コアサイエンスチームとともにそれらのユースケースの構築を始めています。 啓発と刺激の分野では、当社が所有するプライベートバンクであるCouttsの顧客向けに、リレーションシップマネージャー用の通話要約を実施しています。顧客との通話内容は非常にセンシティブなデータであるため、すべて社内で保持する必要があります。
私たちは長年、通常のNLPやBERTモデルを使用してきましたが、その精度は徐々に向上していました。それは優れたツールセットでしたが、ビジネス部門にその価値を理解してもらうのに苦労していました。しかし今では彼らは完全にこれを受け入れ、それらのユースケースにLLMsを実装することで、さらに優れた強力なものになりました。現在、彼らが私たちに求めているのは、ミーティング前の支援です。顧客が銀行内で保有している複数の口座に関する情報を収集する必要があるのです。また、私たちは大手企業向け銀行でもあるため、Couttsの顧客の多くは、私たちが取引している企業の投資家や幹部でもあります。
私たちは、あなたのユースケースと同様に、銀行全体の様々なシステムからデータを抽出し、その抽出した重要な事実を要約して、リレーションシップマネージャーがミーティングに必要なすべての情報を得られるようにすることができました。以前は通話の要約機能さえほとんど使ってもらえなかったのに、今ではこのツールの機能追加要望が膨大になっています。この変化は非常に興味深いものでした。
同様に、不正対策チームからも別のユースケースの要望がありました。私たちは長年、不正分類や支払い停止のための機械学習による不正検出モデルを構築してきました。最近私たちのところに来たのは不正調査チームです。複雑な不正事例、特に当行や他行に複数の口座を持つ人々が関与する第一当事者不正と呼ばれるケースでは、人身売買を含むことの多いマネーロンダリングのために資金を移動させるネットワークが存在します。
私たちは、当行のすべての口座と、当行外の送金先口座（サードパーティと呼んでいます）にわたるグラフ埋め込みモデルを構築することができました。これにより、不正調査官は驚くべき調査を行うことができ、IPアドレス、自宅住所、類似した名前など、口座に関する様々な周辺情報を含めて、口座間の資金移動のネットワークを把握することができます。LLMsの追加は、既存システムからグラフにフィードするエンティティや要素の抽出と、そのグラフの探索の両面で素晴らしい効果を発揮し、不正調査官に新しい調査手法を提供しています。
私たちは素晴らしい成果を上げています。不正ネットワークとその深さの発見が約10倍速くなり、調査官が数週間かかっていた作業が数日で完了するようになりました。最近の重要な事例では、当行内の不正ネットワークを発見し、その中に東ヨーロッパからアイルランドに人身売買された被害者である当行の顧客が含まれていることが判明しました。私たちは警察に完全な調査ファイルを提供することができ、その結果、この不正が摘発され、その人物は性産業から解放されることができました。
警察はその事件で逮捕を行いましたが、他のどの銀行もこれほどの情報を提供したことがないため、これほど多くの捜査情報が入手できた事例は初めてだと述べていました。私たちは、犯人を起訴することを可能にした他の銀行の口座情報を警察に提示することができ、これは驚くべき成果でした。これらは実に興味深いケースで、正直なところ、これまでなら実現不可能だったでしょう。私たちは不正検知の分野で多くのカテゴリー分類モデルやMachine Learningモデルを実装してきましたが、Generative AIの可能性について考えた調査員たちが私たちのところに来てくれたおかげで、彼らと共にそれを構築し、人々の生活に実際の影響を与える新しいソリューションを生み出すことができたのです。
Amazonの物流最適化：AIによる大規模データ分析
Amazonでは、何百万もあるロングテール商品の中から実際に商品を選択してから、約束した日時（私たちが「promise」と呼んでいる期日）に実際に配送されるまでの間、大規模な緻密な連携が必要です。私のチームは、非常にCustomer-obsessedな企業である私たちにとって極めて重要な、この約束を確実に守るために、すべての情報を整理してインサイトを生成する裏方の仕事を担当しています。
毎年、構造化・非構造化を問わず、ペタバイト規模のデータが毎日生成されています。50,000人以上のアクティブな管理者やパワーユーザーがこれらの情報を分析しています。100以上の異なるシステム、40,000以上のメトリクスを追跡しており、それぞれが信頼できるソースとなる異なるシステムが存在する非常に複雑な問題です。どのMetadataマネジメントやMaster Dataマネジメントシステムでも予想されるように、サイロ化や重複があり、この膨大なデータの中から問題を防ぐのに役立つインサイトの核心を見出さなければなりません。私たちは荷物を時間通りに顧客に届けたいのです。
これが、この問題の範囲と規模であり、これはグローバルな課題です。今日は、その中から特定の問題を選んでお話ししたいと思います。それは配送ステーション、つまりラストマイルの部分です。荷物がファーストマイルを通過し、幹線輸送を経て、配送ステーションに到着すると、皆さんがよく目にする配送バンに積み込まれて各家庭に配送されます。私たちは計画を重視する企業です。毎日、荷物、ルート、バンなどすべての計画を立てています。
毎日、計画があり、実際の結果があります。計画したことの中には上手くいかないこともあります。現場では、スタッフが計画を評価し、すべての情報を確認して何が間違っていたのかを特定し、Root Cause Analysisを行っています。これは各ステーションで行われ、地域レベルでまとめられ、ディレクターレベル、そして最終的にVPレベルまで集約されます。彼らはネットワーク全体を総合的に見て、何が起きているのか、システム全体の健全性を改善するためにリソースをどこに投入すべきかを判断しています。この分析作業には毎日15,000から20,000時間もの人的労力が費やされています。そこで、まずこの問題に取り組むことにしました。この問題に取り組むにあたり、まず直面したのはRoot Cause Analysisがない状態からのコールドスタート問題でした。膨大なデータがあり、原因の関係グラフはN層に深くなる可能性があり、非常に広範になる可能性があります。そのため、まずKnowledge Graphから始める必要がありました。
私たちは、Expert Systemベースのナレッジグラフから始めました。実際にこの作業を行ってきた人々の知見を活用し、Machine Learningを使ってコールドスタート問題を解決しました。人間は自分の知っていることしか見ることができず、通常は過去のパターンに頼ってその上に構築していくものですが、そこからモデルが学習して拡張していくようにしました。
次に、様々な種類のMachine Learningアルゴリズムを導入し、広範なパターンを探索して相関関係を見つけ、それらがナレッジグラフの一部となり得るかを検討しました。密接なフィードバックループを持ち、実験を行って、それらが根本原因分析の一部となるべきかを判断しました。これを完了した後、パイロットを実施し、人々が理解できるインサイトを生成しました。
私たちが実際に行ったのは、Composite AIと呼ばれるものです。根本原因分析にMachine Learningを使用し、それを現場レベルで表現するためにGenerative AIを使用しました。これを北米とヨーロッパ全域で展開し、91%の受け入れ率を達成しました。ユーザーからは「これは素晴らしい、まさに自分がやりたかったことだ」という評価を得ています。場合によっては「これは自分が考えていた以上のものだ - 知らなかった相関関係まで見つけてくれた」という声も聞かれます。
次のステップとして、推論自体にLarge Language Modelsを活用する予定です。技術が整っていなかったため、最初は推論から始めませんでしたが、これからはLLMベースの推論を使用し、もちろんGenerative AIを使って推論の正確性を確認していきます。これが来年に向けて取り組み始めた一つの側面です。もう一つの取り組みは、Agentic AIに焦点を当てることです。現場のスタッフが気に入っているアクショナブルなインサイトがあり、それが実際に機能することを示す密接なフィードバックループもあります。
アクションを実行すれば実際にネットワークの改善につながり、逆に実行しなければネットワークに悪影響を及ぼすことが分かっています。今後は、幸いにも技術が整ってきたので、Agenticフレームワークを使用してシステムが実際のアクションを実行できるようにしていきます。つまり、大規模なコールドスタート問題があったため、Composite AIから始め、従来のMachine Learningで根本原因分析を行い、Generative AIで情報を表現しました。現在は、推論の一部にGenerative AI自体を組み込んで、システムのアンサンブルがより正確になるようにしており、来年はAgenticフレームワークを通じてインサイトをアクションに変換していく予定です。
データガバナンスとメッシュアーキテクチャの重要性
これはAmazonのスケールでは驚くべきことで、私たち一人一人のAmazon.comユーザーにとって、商品を時間通りに受け取ることは非常に重要です。Shiva、技術面ではなく、ビジネスや人的プロセスの面についてもう少し詳しく教えていただけますか？Amazonのスケールでは、ビジネス上の課題に対して何に取り組むかについて合意を得ることも、かなり難しいと思います。どのように進めて、どうやって合意を得たのでしょうか？
技術とプロセスの組み合わせによって、従来からある典型的なサイロの問題に対処しました。多くのチームが、最善の意図を持って次のData Lakeを構築したり、次世代の最高のメタデータカタログ、すべてを解決する統一カタログを構築したりしていました。しかし幸運なことに、私たちはSageMaker Lake Houseの主要顧客の一つとなることができました。このプラットフォームでは、ETLが不要になり、1つのメタデータカタログで2つの重要な機能を実現できます：発見可能性とデータの系統です。データアセット、メトリクスアセット、特徴量エンジニアリングアセットなど、あらゆる種類のアセットをセマンティック検索できます。これらのMachine Learning特徴量を検索したり、使用されていないダッシュボードや重複したものを特定して削除したり、Amazon全体の単一の情報源を作成することができます。Amazonのようなシステムでは、ネットワーク全体に複数のホップがあるため、系統を理解し、どこで問題が発生するかを把握することも重要です。幸いなことに、Amazon SageMaker Lake House技術により、さらなる移行やData Lakeを作る必要なく、すべてを統合することができました。
もう一つ実装したのは、純粋なプロセスとガバナンスのアプローチで、これはネットワークレベルのメトリクスを管理するチームの検証を含みます。Network Hubのようなクロスネットワークチームが、ネットワークレベルでのアクションを管理し、責任を持ちます。
Domain Hubは、それぞれの特定のドメインに責任を持ち、Last MileやFulfillment Center operationsなど、問題に対する詳細な分析を行います。Amazonではすべてがメカニズムに基づいており、どのチームが特定の領域に責任を持つかを定義するメカニズムを確立しています。これらのチームは、それぞれの領域における単一の情報源を所有しています。そのサンドボックスで操作する場合、従うべき特定のルールと設定すべき権限があるガードレールのシステムを実装しています。
もう一つの利点は、これらの異なるシステム間でのシングルサインオン機能により、権限を効果的に管理できることです。これにより、意図を追跡するだけでなく、技術を通じてこれらのガイドラインを強制することができます。プロセスと技術を適切に組み合わせることで、これらの変更を実装しましたが、まだ進行中です。これは一度解決して終わりという問題ではなく、良い筋肉のように継続的に鍛え続ける必要があるものです。
HCLSでは素晴らしい取り組みをされていると伺っています。特に上手くいっている点や、共有したい内容について教えていただけますか？最近導入した重要なコンポーネントの1つが、Data Meshに関するものでした。当社は2004年に設立されましたが、当初は小規模なシステムインフラストラクチャーで、分析のために直接データベースにアクセスしていました。しかし、ある時点で、これを効果的に管理するためのAnalytics Platformが必要になりました。
私たちは、すべての情報をAnalytics Platformに集約し、中央のチームがダッシュボード、クエリ、レポートを作成して各事業運営チームに配布する、集中型のアプローチを導入しました。これはある程度まではうまく機能しましたが、やがてビジネス全体からの様々な要求に応えようとする中で組織的なボトルネックが発生しました。さらに、システムからのデータアクセスにもボトルネックが生じました。というのも、一部のシステムがレポート用に適切に構造化されていなかったり、クエリやETLを実行しにくいソースであったりしたためです。
そこで私たちは、Analytics Infrastructureを変更し、データ側で完全に分散型のアプローチを実装することにしました。各システム、組織、ユニットが、自身のデータ管理、定義、組織への公開に責任を持つことになりました。彼らが自身のシステムを最もよく理解し、分析のためにデータをどのように構造化すべきかを把握しているデータのオーナーであり管理者となります。このアプローチは、特にセキュリティ、アクセス、データディスカバリーの面で新たな課題をもたらしました。
そこでAWSと協力し、DataZoneを活用してソリューションを作り上げました。DataZoneを活用することで、カタログ内のすべてのData Productsを作成できる集中型のガバナンスを実現しました。ユーザーは利用可能なデータを探索し、データへのアクセスを要求し、さらに属性レベルの細かいアクセス制御も可能になりました。特に私たちのヘルスケア分野では、情報が非常に制限されているため、データの特定の側面にはアクセスできても、機密情報は見えないようにブラインド処理されます。これらの機能により、すべてのシステムが組織にData Productsを公開する責任を持つ、一貫性のあるデータ戦略を構築することができました。
このアプローチは非常に分散的でありながら、集中型のカタログとアクセスモデル、それに対応するセキュリティを維持しています。データがカタログに集中化されているため、誰が何にアクセスできるかを把握でき、データの移動を追跡できない多くの異なる場所にデータがコピーされることを防ぐことができます。これは、ZackとSivaが行っていることと非常によく似た、一貫性のあるアプローチの実現に大いに役立ちました。興味深いことに、皆が同じことの少しずつ異なる側面について言及していますね。
ガバナンスをワークフローに組み込む：効率的なデータ管理の実現
データに対する集中管理から、より分散化されたメッシュシステムへの移行を進めています。これは発見を妨げるボトルネックとなっていた従来の方式からの転換です。私たちはテクノロジーの観点からメッシュについて考えがちですが、実際には使用する技術に関係なく、適切な場所でのData Productのオーナーシップに関する話なのです。従来は、人々がETLジョブを作成し、コンシューマーが契約もないままソースから最終地点までのパイプライン全体を所有していたため、変更や管理が非常に困難でした。Data Productとその外部でのオーナーシップへのシフトは非常に重要です。この分散型対集中型という考え方は、皆さんの経験と共鳴しますか？
私たちの銀行も皆様と同様に厳しい規制下にあります。データの使用目的は限定されており、プライバシー影響評価やGDPRコンプライアンス管理、そしてModelとModel Riskに関する規制遵守が必要です。従来、ガバナンスのステップはほとんどが会議を通じて行われていました。新しいModelを構築したい場合、12人の前でModelを構築する理由と方法を説明し、構築後に承認を得るために再度戻ってくる必要があり、これは非常に時間がかかりました。
NatWestに来た当時、アイデアから本番環境へのModel導入まで2年かかっていました。テクノロジーの進歩の速さを考えると、完成する頃には全く新しいテックスタックが利用可能になっているような状況でした。私たちは、すべてのガバナンスとコントロールをModelの構築やデータアクセス、プロジェクト実行のパイプラインに直接組み込む戦略を採用しました。DatazoneとMarketplaceと呼んでいるシステムがこれに不可欠でした。プロジェクトの属性がガバナンスを決定し、それが実際のデプロイメントとパイプラインに組み込まれています。Model構築においては、すべてのModelガバナンスコントロールがそのパイプラインに組み込まれており、リスク評価を動的に行います - リスクが低ければ進行し、高ければ追加承認が必要かもしれません。この方法は、作業をより速く完了できるため、人々に優れたパターンの使用を自然に促します。エンジニアやData Scientistにとって、作業の高速化ほど強い動機付けはありません。
分析プロジェクトでは、Data Marketplaceを通じて適切かつ倫理的にデータにアクセスできることを確認するためのAPIを申請する必要があります。先ほど発見可能性が一つの障壁だとおっしゃいましたが、アクセスコントロールは私たちにとって極めて重要です。例えば、フロントオフィスとバックオフィスの分離は規制上のコントロールの一部です。
さらに、データの使用目的、その正当性、GDPRコンプライアンスやポリシーへの適合性も考慮します。これらすべての要素をパイプライン内に組み込もうとしています。まだ完全ではなく開発中の部分もありますが、このアプローチによってアイデアから価値創造までの道のりが加速することがわかってきました。実際にガバナンスが改善され、コンプライアンスが強化され、ガバナンスに必要な人員や会議も減少します。すべてをパイプラインに統合することで、好循環が生まれているのです。
Datazoneを活用することで、プロジェクトのアイデアを具現化し、その周辺にガバナンスを構築することができました。これは、開発者やアナリスト、データサイエンティストがデータを使用し、モデルを構築し、あらゆる種類のプロジェクトを扱う際の方法論の一部となっています。皆さんが実現したことで特に評価したいのは、ガバナンスをワークフローに組み込んだことです。考慮すべき外部の負担ではなくなったのです。三人とも異なる方法でそのことについて言及されました。実際のところ、これは私が出席する会議が減ることを意味します。これこそが私の目標なのです。開発者がより速く物事を進めたいのなら、私はただ会議に出る機会を減らしたいだけです。
Generative AI導入のアドバイス：大胆な目標設定と文化の変革
皆さんにお聞きしたいことが一つあります。皆さんは素晴らしい成果を上げられ、とても興味深いGenerative AIの取り組みを始められています。これから始める人、あるいはすでに取り組んでいて皆さんが直面したような課題に対処している人に、一つアドバイスをするとすれば何でしょうか？ Sivaさん、まずあなたからお願いできますか？
適切な問題から始めることです。私はAWS Finance Summitに John Feltonに招待されて参加しました。彼は以前Operationsにいて、その後Financeに戻りましたが、それは私たちのチームが実際にプロダクションまで到達した数少ないチームの一つだったからです。スタートアップでは、これをProduct Market Fitと呼びます。誰かにとって本当に問題となっていることから始めるのです。たまたまその解決手段がAIであったり、何らかのMachine Learningであったりするわけですが、まずは問題から始めることです。
Amazonには2つの大きなメカニズムがあります - 私たちはすべてをメカニズムを通して見ています。1つ目はインキュベーションのメカニズム、2つ目はオペレーショナライゼーションのメカニズムです。インキュベーションでは、アイデアを持ち、現場の人々と話し、実現可能性を確認します。構築する場合は、簡単な実験を行い、機能することを確認し、小規模な展開でコンセプトを証明してから、ソリューションの運用化に焦点を当てます。ソリューションを運用化する時点で、5つの要素を整備する必要があります：データプラットフォーム、Feature Engineering、モデルパイプライン、モデル構築パイプライン、そしてモデル提供パイプラインです。また、モデル管理とモデルを監査する何かが必要です。なぜなら、これらのモデルはデータが変化するにつれて劣化するからです。つまり、適切な問題から始め、インキュベーションと運用化・スケーリングの能力の両方が成功に必要だということを認識しておく必要があります。
そして確かMarcoさん、このトピックについて言及されていましたよね。
文化の変革は大きな課題です。特に、組織全体のデータを準備する1つのチームによる集中型モデルから、各コンポーネント、アプリケーション、またはチームがデータに責任を持つ完全分散型モデルへの移行においては、文化の変革が確実に起こるようにする必要があります。Chief Data Officer（CDO）の在任期間が2年程度というお話がありましたが、これはおそらく、CDOが任命された時点で文化が変わらず、組織全体がCDOの行動を待っているだけだったことを示す良い指標だと思います。もちろんCDOがこれを推進しますが、組織全体がデータの使用方法と管理方法を変えていく旅に一緒に参加する必要があるのです。
私たちの場合、チームは自分たちのシステムに対してビジネスが実際に何を求めているのか、何が関連しているのか、何を公開したいのか、それらのData Productをどのように管理すべきか、新しい機能を追加する場合にデータへの影響は何か、公開する必要のある新しいモデルはあるのか、それらのモデルの関係性で変更が必要なものはあるのか、といった問題に取り組まなければなりませんでした。また現在では、自分たちが公開するData Productが、他のチームが公開している製品とうまく連携できることを確認するため、様々な組織やチームと話し合う必要があります。
これらは、組織全体で新しい機能やコンポーネントを実装する際に、データを最優先事項として考える文化を確立する必要がある部分です。これを行わなければ、結果として素晴らしいカタログを持っていても、それが全く活用されないか、1つか2つの製品しか含まれていない状態になり、価値が失われてしまいます。そのため、分散型であれ集中型であれ、実装においては特に、組織の文化を変革し、優先順位リストの上位にデータを位置づけることができるかどうかが重要なコンポーネントとなります。
ありがとうございます、Marco。私たちがより多くのGenerative AIモデルを本番環境に導入してきた中で気づいたことの1つは、プロジェクトの終了時に、ほぼすべてのチームから「今なら違うやり方をするだろう」という声が聞かれることです。なぜなら、テクノロジーが進化し、学びが深まっているからです。そしてこれらはたった5ヶ月のプロジェクトなのです。私たちは今、特に中心となる最高のData Scienceチームのために、魔法のように思えるプロジェクト、現時点では実現不可能だと思えるようなプロジェクトを選ぶようになってきています。
その理由は、プロジェクトが完了する頃には新しい機能が登場しているだろうという現実があるからです。私たちは、現在のLLMではできない音声から音声への変換や画像処理などについて考えていますが、6ヶ月後にはおそらく可能になり、8ヶ月後には確実に可能になるでしょう。もし万が一、プロジェクトが完了した時点でまだ実現できずに失敗したとしても、また後で取り組めばいいのです。私たちは通常、アプリケーション、データ、RAGインフラストラクチャ、使用するデータセットなどをすべて構築していますので、新しい機能を持つ新しいモデルセットが登場したら、それらを組み込んで動作を確認すればいいのです。
銀行では通常、革新的でありながら実現可能なことを考えたがるものですが、そのような考え方に何度か取り組んでみて、私には本当に衝撃的でした。プロジェクトを始める時、失敗が目に見えているような道には進みたくないものです。しかし、私たちは本当に考え方を変えて、大胆になり、魔法のように感じることについて考える必要があります。なぜなら、実際にそこに到達する頃には、それらは可能になっているからです。現時点で可能なことだけを考えてプロジェクトを始めると、実際には目標を低く設定しすぎて、期待外れな結果になり、結局また最初からやり直すことになってしまいます。そのため、最初は魔法のようなことを目標にして、必要であれば少し現実的な方向に調整するか、別のイテレーションで再検討する方が良いのです。
私たちのチームには、ビジネスソリューションを設計・販売する際にこのアプローチを適用することを推奨しています。企業に対して、現時点では実現可能とは思えないような難しい課題を私たちに提示するよう促しています。そしてそれらをプロジェクトに組み込んでいます。このアプローチが、私たちが達成できることとその影響の大きさの面で、驚くほど効果的であることが分かってきました。
私は皆さんに、可能性を大胆に探求することを推奨します。なぜなら、私たちの成果を見てみると、Graph Embeddingsモデルを稼働させたばかりで、今朝Swamiが発表したように、BedrockでのGraph RAGを使って、これを再構築することになります。今それを行えば、すでにすべてのデータがあるため、それらの機能を活用して再度作り直すだけで、このモデルをより良いものにできます。これらは私たちのビジネスにとって本当に素晴らしい学びと機能だと思います。
このセッションを締めくくるには素晴らしいアドバイスですね。現在私たちが目にしているイノベーションのペースを考えると、魔法のようなことが可能になっている、というのは本当に素晴らしいことです。では、お時間となりましたので、ここで終わりにしたいと思います。パネリストの皆様には、学びを共有していただき、ありがとうございました。また、ご来場いただき、この対話に参加してくださった皆様にも感謝申し上げます。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion