/w=3840,quality=90,fit=scale-down)
※本記事は、AWS re:Invent 2024で発表された「Using open source blueprints for building AI applications (AIM269)」の内容を基に作成されています。この発表はMongoDBがAWSパートナーとして提供したものです。発表の詳細情報はYouTube（https://www.youtube.com/watch?v=hvxCV4PP8KI ）でご覧いただけます。本記事では、セッションの内容を要約しております。なお、本記事の内容は発表者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご覧いただくことをお勧めいたします。AWS re:Inventの詳細については https://go.aws/reinvent 、その他のAWSイベントについては https://go.aws/3kss9CP をご参照ください。
1. イントロダクション
1.1. 発表者の紹介
このセッションには3名の発表者が登壇しています。
- Fred Favelin: 彼はセッションの進行役を務め、ヘルスケアソリューションに関するユースケースを中心に発表しました。特に診察の予防方法に焦点を当てたAIアプリケーションの構築について説明する役割を担当しています。
- Shane McAllister: MongoDBの開発者リレーションチームのリーダーの一人です。彼はパートナー関係を担当しており、このAWSのイベントでMongoDBのパートナーシッププログラムについて解説しました。特にMongoDB AI Applications Program (MAP)の説明を担当しています。
- Rick Houlihan: MongoDBのエンタープライズ向けフィールドCTOを務めています。彼はAWS時代にDynamoDBの最初のエンタープライズSAを務め、約3年前までAWSでは世界的なNOSQLテクニカルリーダーとして活動していました。このセッションでは主にMongoDBの技術的な優位性とAIにおけるベクトル検索の重要性について解説しました。
1.2. セッションの概要
このセッションは以下の4つの主要パートで構成されています：
- ブループリントの重要性: 開発者やビジネスオーナーにとってなぜブループリントが重要なのか、AIの競争優位性や採用における課題を含めて解説しています。
- MongoDBの価値提案: AIの文脈においてMongoDBが提供するユニークな価値、特にシンプルさ、統合API、ドキュメントモデルの優位性、ベクトル検索機能について説明しています。
- オープンソースブループリントと支援プログラム: 適切なブループリントの選択方法とMongoDB AI Application Partners（MAP）プログラムの詳細が紹介されています。
- 実例紹介（乳がん検診アプリケーション）: MongoDBを活用した医療ヘルスケアソリューションの具体的な実装例を通じて、AIがどのように診断プロセスを効率化するかをデモンストレーションしています。
2. ブループリントの重要性
2.1. AIの競争優位性
Rick: まず、開発者やビジネスオーナーにとってなぜブループリントが重要なのかについて少しお話ししましょう。ここで興味深いのは、2019年にMITスローン・ビジネススクールが組織に対して行った調査です。その結果、調査対象の組織の97%がAIによって競争優位性を得られると感じていることがわかりました。これは2019年の調査です。それから5年経った今、AIを使っていなければ、ほぼ置いていかれたと言えるでしょう。つまり、未来は既に来ているのです。しかし現実には、これらのツールを使うのは簡単ではありません。
Rick: AIを活用することで、私たちはいくつかの重要な改善を実現できます。従業員体験の向上、AIツールでソーシャルメディアのイベントを処理することによる顧客エンゲージメントの再構築などです。当社の顧客の中には、これを使ってリアルタイムで顧客の感情を測定し、行動を起こしている企業もあります。さらにビジネスプロセスを再構築することも可能です。他の顧客では、数ヶ月かかっていたビジネスプロセスをAIツールを使って文字通り10分に短縮した例もあり、これについても後ほど詳しくお話しします。本質的に、AIを使って革新のカーブを曲げたり、再形成したりすることができるのです。
Rick: 明らかにAIで競争優位性を得るためにできることはたくさんありますが、これを正しく実行し、実現させることは簡単ではありません。生成AIの採用を業界全体で見ると、進展と停滞を繰り返しています。その理由は、このツールの継続的な進化です。毎日、より多くの機能、より多くのツール、テクノロジーの進化があります。そして、これらのパイプラインを構築し、本質的にこれらのテクノロジーを接続してMLパイプラインを作るための内部専門知識が不足しています。
Rick: これらの異なるシステムを統合することが課題であり、これこそがブループリントが最も意味を持つ理由です。意味のある目的のために接続されたツールを取り、事前構築されたMLパイプラインを作成し、それらを自分たちの用途のために再デプロイすることができるからです。これがブループリントが重要である理由です。
2.2. Gen AIの採用における課題
Rick: 生成AIの採用が業界全体で進展と停滞を繰り返している理由は、このツールの継続的な進化にあります。毎日のように新機能、新ツール、テクノロジーの進化が起こっています。そして大きな問題の一つは、これらのパイプラインを構築し、本質的にこれらのテクノロジーを接続してMLパイプラインを作成するための内部専門知識が多くの組織に不足していることです。
Shane: 確かに、今日の競争環境において革新的なテクノロジーを活用することはますます難しくなっています。生成AIの潜在力が自社のアプリケーションやビジネスを変革できることは理解していても、実際に導入するための具体的な方法がわからない企業が多いのです。
Fred: その通りです。特に医療分野など、厳しく規制された業界では、これらの新しいテクノロジーを採用する際のコンプライアンスや安全性の懸念もあります。単に技術的な課題だけでなく、規制要件にも対応する必要があるのです。
Rick: また、生成AIプロジェクトを実装しようとすると、多くの場合、データサイロの問題に直面します。運用データストア、ベクトルインデックス、分析エンジンなど、複数のシステムを接続する必要があり、それらの間でデータの一貫性を維持するためのETLパイプラインを構築・維持することが大きな負担になります。これは私が「ぐらつく技術の塔」と呼んでいるものです。基本的なオペレーショナルデータストアの上に機能のサイロを接続し、それらのETLパイプラインとすべての配管、すべてのオーバーヘッドの維持があなたの責任になるからです。
Shane: さらに、進化し続けるAI環境に加えて、複雑な統合問題もあります。多くの顧客がレガシーテクノロジーに縛られていると感じており、それが彼らが構築・生成したいアプリケーションの開発を妨げています。変化する市場条件に適応しようとしていますが、レガシーテクノロジーで作業しているため、リアルタイムでそれを管理することができません。Rickが話したマルチモーダルはレガシーテクノロジーでは機能せず、今日のインテリジェントなアプリケーションが要求する期待に応えられません。
2.3. ブループリントによるソリューション
Rick: これがまさにブループリントが本当に意味を持つ理由です。接続されたツールを取り、意味のある目的のために事前構築されたMLパイプラインを作成し、それを自分たちの用途のために再利用できるからです。複雑な技術スタックを一からすべて構築する代わりに、実証済みの設計パターンを活用できるのです。
Fred: そうですね。ブループリントはスタートアップキットのような役割を果たします。適切に文書化され、学習リソースが充実したブループリントがあれば、プロトタイプの作成から本番環境への移行までの時間を大幅に短縮できます。
Shane: そして、MAPプログラムではまさにそれを提供しています。お客様がAIアプリケーションを迅速かつ効果的に構築できるよう、包括的なテクノロジースタックのデモや統合など、様々なサービスを提供しています。これにより、開発者は技術的な複雑さよりも、ビジネス価値の創出に集中できるのです。
Rick: そして重要なのは、これらのブループリントがスケーラブルであるということです。小規模なプロトタイプから始めて、ビジネスの成長に合わせて拡張できる必要があります。Novo Nordiskの例が示すように、適切に設計されたソリューションは、6ヶ月かかっていたプロセスを10分に短縮するような劇的な効率化をもたらすことができます。
Fred: また、ブループリントを選ぶ際には、セキュリティとコンプライアンスも重要な考慮事項です。特に医療分野など規制の厳しい業界では、データセキュリティとコンプライアンスが非常に重要になります。私たちが後ほどデモで示すように、機密データを安全に保護するためのベストプラクティスに準拠することが不可欠です。
Shane: そして、良いブループリントはコミュニティのサポートを受けています。活発なコミュニティとフィードバックのサイクルがあることで、問題が発生した場合にも迅速に解決できます。MAPにおいては、MongoDBとパートナー企業の専門知識を活用できるという大きな利点があります。
Rick: 最終的に、ブループリントはAIの採用を民主化し、あらゆる規模の組織がAIの力を活用できるようにするものです。技術的な複雑さを抽象化することで、ビジネス価値の創出に集中できるようになるのです。
3. MongoDBの価値提案
3.1. シンプルさの重要性
Rick: MongoDBがなぜ重要なのか、なぜ気にすべきなのか、MongoDBはここでどのような役割を果たすのかという点に入りましょう。それは私たちのミッションの核心に関わることです。私たちは常にシンプルさを追求してきました。私たちの製品に関するすべては、開発者の作業を容易にすることに関するものです。アルバート・アインシュタインがかつて言ったように、「すべてはできるだけシンプルに、しかしシンプルすぎないように」。言うのは簡単ですが、実行するのは必ずしも簡単ではありません。
Rick: 私たちが知っているように、組織には多くのレガシーアプリケーションがあり、それらのアプリケーションにデータが閉じ込められています。これらすべてをクラウドに移行したとき、素晴らしい進化と効率性を得られると考えていました。そして実際、いくつかの進化と効率性を得ることができました。もはやデータセンターの構築や運用のビジネスに携わる必要はありません。しかし実際には、そのすべてのテクノロジーのリフト＆シフトは、モダンアプリケーションが必ずしも恩恵を受けない状況を作り出しました。これらのモダンアプリケーションには、そのレガシーテクノロジーが構築された目的を超える要件があります。
Fred: そうですね、特に医療分野では患者データ、診断結果、画像データなど様々なタイプのデータを扱う必要があります。従来のリレーショナルデータベースでこれらを管理しようとすると、複雑なスキーマとクエリが必要になってしまいます。
Rick: AIの分野に入ると、ベクトルのサポート、全文検索、時系列など、データベースから多くの異なる機能が必要になります。レガシーデータベースはこのために構築されていませんでした。現在、クラウドでは多くのオプションがあります。レガシーの運用データストアに接続するための目的別サービスが増殖しています。しかし、これは私たちに恩恵をもたらしているわけではありません。実際には、開発者が何度も何度もシステムを構築することを余儀なくされ、基本的にカスタムアーキテクチャを何度も構築しなければならないため、複雑さが増しているだけです。私はこれを「ぐらつく技術の塔」と呼んでいます。
Shane: その通りです。多くの顧客からは、データの断片化が大きな課題だという声を聞きます。データがさまざまなシステムに分散していると、それらを統合して有意義なインサイトを得ることが難しくなります。特にAIアプリケーションでは、高品質なデータへのシームレスなアクセスが不可欠です。
Rick: MongoDBは常にこれに対抗してきました。私たちはシンプルさを追求しており、顧客が同じことを何度も繰り返していることを見るとき、それを検討して「これは顧客のために実際に取り入れて、この機能をプラットフォームに統合できるものでしょうか？」と考えます。これがAtlasが誕生した経緯です。しかし、AtlasはMongoDBの始まりではありませんでした。MongoDBは実際にはコアデータベースから始まり、創設者たちはリレーショナルデータベースでの作業が不必要に複雑だという事実を認識していました。
3.2. レガシーデータベースの限界
Rick: リレーショナルデータベースは本質的にデータの抽象化です。データをリレーショナルデータベースに保存する方法は、アプリケーション層で使用する方法と同じではありません。実際、データベースから複雑なオブジェクトを取得する必要がある場合、そのデータを取得するために全く異なる言語で複雑なクエリを書く必要があります。これは開発者が苦労する際のインピーダンスミスマッチです。多くの開発者は基本的に諦めて、リレーショナルデータベースに構築するモデルは、あるべき姿ほど効率的ではありません。
Rick: 開発者はコードの書き方をデータの保存方法に変換することを強いられており、それがスピードを低下させます。私たちはこれを何度も何度も実証してきました。リレーショナルデータベースのもう一つの問題は、リレーショナルデータベースの運用化とスケーリングです。繰り返しになりますが、これはリレーショナルデータベースが構築されたものではありませんでした。1970年代に構築され、リージョン間のレプリケーションと地理的な一貫性が問題ではなかった時代のものです。
Fred: そうですね。特に私たちの乳がん検診アプリケーションのようなユースケースでは、複数の放射線センターからデータが集まってきます。従来のデータベースでは、このような分散環境での一貫性の維持が大きな課題になります。
Rick: そこで私たちはこれをデータベース自体のレプリケーションプロトコルに組み込みました。MongoDBに書き込みを行うと、データをデプロイしているすべてのリージョンで望む一貫性の種類を選択できます。これは開発者がデータを扱う際のユニークな体験です。データを使用する方法で保存し、リレーショナルデータベースではできない方法でデータを運用化でき、優雅にスケールします。
Shane: そして顧客からよく聞くことですが、アプリケーションの要件が拡大するにつれて、アプリケーション構築の複雑さが増しました。時系列、全文検索、リアルタイム分析、ストリーム処理、そして現在のAIによるベクトル検索を追加すると、モダンアプリケーションに必要な機能がどんどん増えていきます。開発者はこれらの機能を自分のデータベースに何度も何度も追加する必要がありました。
Rick: クラウドへの移行によって得られる恩恵の一つは、目的特化型サービスへのアクセスでした。しかし、その代償として複雑さが増しました。例えば、全文検索が必要な場合、Elastic Searchを使用することになります。データをElastic SearchインスタンスにETLする必要があります。Elastic Searchデータベースにクエリを実行すると、何が返ってくるでしょうか？それは運用データストア内のデータへのポインタです。その後で戻ってデータを取得する必要があります。
Rick: ベクトルインデックスにElastic Searchを使用している場合、必ずしもElastic Searchから直接データを取得できるわけではありません。そのデータにアクセスするには別の場所に行く必要があります。これはレイテンシであり、追加のオーバーヘッドであり、複雑さです。MongoDBの開発者データプラットフォームは、これらすべてを単一のAPIにまとめています。MongoDBでベクトルクエリを実行すると、結果とともにデータが直接返ってきます。二次クエリを実行する必要も、データを二次データストアに投影する必要も、複数のデータストア間でデータの一貫性とETLパイプラインを維持する必要もありません。
3.3. MongoDBのドキュメントモデルの優位性
Rick: MongoDBのドキュメントモデルの最大の強みは、データを使用する方法と同じ方法で保存できることです。これにより、開発者は年間を通じてMongoDBに殺到してきました。MongoDBは有料顧客が50,000以上利用しています。これにはオープンソース製品は含まれていません。オープンソースプラットフォームには何十万ものデプロイメントがあり、毎月175,000人の開発者が初めてMongoDBを見ています。今日最も人気のある、あるいは最も人気のあるデータベースの一つが私たちのプラットフォーム、MongoDBです。そして私たちは成長を続けています。
Fred: そうですね。特に医療分野のような複雑なドメインでは、ドキュメントモデルの柔軟性が大きな利点になります。例えば、患者の記録、診断結果、画像データなど、様々な種類のデータを自然な形で保存できます。私たちのデモで後ほど示しますが、これによりアプリケーション開発が大幅に加速します。
Rick: AIが現在、私たちが先ほど話したスプロール現象をすべて再点火しています。ベクトルインデクシングについて言及しましたが、ベクトルインデクシングはAIワークロードのごく一部です。私たちが見ているのは、AIワークロードをサポートするために、この追加の複雑さが運用データストアに再び忍び込むリスクです。
Rick: 今では、Pinecone、PG Vector、ベクトルインデックスを作成するための多くの異なるオプションがありますが、運用データはまだ取得する必要があり、保存する必要があり、アクセスする必要があります。Pineconeにクエリすればデータへのポインタが得られますが、データを取得するためには運用データストアにクエリする必要があります。ここには多くの複雑さとレイテンシを導入するシステムがあります。私たちはそれを排除したいのです。
Shane: 確かに、多くの顧客から、複数のシステム間でデータを同期させる複雑さについての懸念を聞いています。特にAIの文脈では、ベクトルインデックスと実際のデータの間で一貫性を維持することが大きな課題です。MongoDBのアプローチでは、これらはすべて同じシステム内で管理されるため、ETLパイプラインや複雑な同期メカニズムは必要ありません。
Rick: AIのワークロードがどのようなものかを理解するために、ベクトルがAIで重要である理由を理解する必要があります。部屋の多くの人がすでにこれを知っていると思いますが、ベクトルはAIにおいて非常に重要な機能です。データの多次元表現を保存し、通常は関連付けられないデータを一緒に照合または関連付けることができます。画像、音声ファイル、豊富なドキュメント構造などです。
Rick: 興味深いことに、AIの機能を利用して構築されている最新のアプリケーションは、リレーショナルデータベースが構築されたのと同じ方法でデータを使用していません。レガシーアプリケーションでは、データをテーブルの行として使用します。OLTPワークロードは、実行されるとき、多くの場合、単なる個々の行だけを扱っています。Amazonにいたとき、10,000のサービスにわたる単一のテーブル上の単一の行のデータへのアクセスパターンは70%でした。さらに20%は単一のテーブル上の一定範囲の行に対するものでした。つまり、それらのレガシーOLTPアプリケーションのアクセスパターンの90%は、単にテーブル上の行を扱っているだけでした。
3.4. 統合APIの提供
Rick: 私たちが実現したのは、すべてが統一されたAPIにまとめられたプラットフォームです。開発者がアクセスする必要がある場所は一つだけで、データにアクセスするために複数のシステムにクエリを実行する必要はありません。今日の多くのデータベースでは、全文検索が必要な場合、Elastic Searchを使用することになります。データをElastic Searchインスタンスにモデルする必要があります。Elastic Searchデータベースにクエリを実行すると何が返ってくるでしょうか？それは運用データストア内のデータへのポインタです。それからそのデータを取得するために戻らなければなりません。
Rick: ベクトルインデックスにElastic Searchを使用している場合、必ずしもElastic Searchから直接データを取得できるわけではありません。このデータにアクセスするには別の場所に行く必要があります。これはレイテンシであり、追加のオーバーヘッドであり、複雑さです。MongoDBの開発者データプラットフォームは、すべてをあなたのために単一のAPIにまとめています。MongoDBでベクトルクエリを実行すると、結果とともにデータが直接返ってきます。二次クエリを実行する必要も、データを二次データストアに投影する必要も、複数のデータストア間でデータの一貫性とETLパイプラインを維持する必要もありません。一つの場所に行き、一つのAPIを使用するだけです。
Shane: そして、これが開発者が長年にわたってMongoDBに殺到してきた理由です。MongoDBには50,000以上の有料顧客がいます。これにはオープンソース製品は含まれていません。私たちのオープンソースプラットフォームには何十万というデプロイメントがあり、毎月175,000人の開発者が初めてMongoDBを見ています。
Fred: このAPIの統合は、特に医療分野のような規制の厳しい業界では非常に重要です。データアクセスを単一のインターフェイスに統合することで、セキュリティポリシーの実装や監査が大幅に簡素化されます。後ほどデモでお見せしますが、これにより患者の機密データへのアクセスを適切に制御することができます。
Rick: また、Atlasで長い間前に学んだことの一つは、全文検索と分析ノードを導入したとき、ユーザーはその機能を互いに独立してスケールする必要があるということでした。最初の実装では、ユーザーがすぐに戻ってきて「全文検索が必要なのでクラスタ内のすべてのノードのサイズを上げているが、ほとんどのデータはセカンダリからヒットしているので、運用データにはそのようなアップサイズされたハードウェアリソースは必要ない」と言いました。
Rick: そこで今、機能をリリースするたびに、その機能をプラットフォーム内で独立してスケール可能な機能としてリリースしています。実際に、ベクトルワークロードを運用データとは別に独立してスケールすることができます。基本的に、異なる構成、異なるインデックス、異なる読み取りパターン、異なる書き込みパターンをサポートする異なるノードを持つことができ、システムの効率性とスケーラビリティを高めることができます。
Shane: そして、これはお客様からの強いフィードバックに基づいています。例えば、Atlas Vector Searchが2023年に発表されてから、史上最も急速に採用された新サービスの一つとなりました。これは主に、運用データの上にベクトルインデックスを優雅に統合し、その機能を独立してスケールできるという理由からです。
Rick: 最近よく耳にする話題の一つは、「トランスリティカルデータベース」という概念です。一つのデータベース、ゼロETL、すべてのワークロード。トランザクション、分析、すべてを一か所で。それは素晴らしいアイデアですね。私たちはその考えを10年前に持っていました。それがAtlasだったのです。トランスリティカルデータベースについて話すとき、非常に重要なのは、ワークロードをサポートするために必要な機能のサイロを独立してスケールできることです。
4. ベクトル検索とAI
4.1. ベクトルの重要性
Rick: AIにおけるベクトルの重要性を理解するために、部屋の多くの人がすでに知っていると思いますが、ベクトルはAIにおいて非常に重要な機能です。ベクトルはデータの多次元表現を保存し、通常は関連付けられないデータを一緒に照合または関連付けることができます。画像、音声ファイル、豊富なドキュメント構造などです。
Rick: 興味深いことに、AIの機能を利用して構築されているモダンアプリケーションは、リレーショナルデータベースが構築された方法とは異なる方法でデータを使用しています。レガシーアプリケーションでは、テーブル上の行にデータを使用していました。少しずつの断片です。OLTPワークロードは、実行されるとき、多くの場合、個々の行だけを扱っています。Amazonにいたとき、10,000のサービスにわたる単一のテーブル上の単一の行のデータへのアクセスパターンは70%でした。さらに20%は単一のテーブル上の一定範囲の行に対するものでした。つまり、それらのレガシーOLTPアプリケーションのアクセスパターンの90%は、単にテーブル上の行を扱っているだけだったのです。
Fred: そして医療分野では、これがさらに複雑になります。例えば、マンモグラフィー画像やその他の診断データは、構造化データと非構造化データの両方を含みます。従来のリレーショナルモデルでは、このようなデータ型を効果的に関連付けることは非常に困難です。
Rick: インフラストラクチャの半分は、残りの10%をサポートするためにデプロイされていました。基本的には結合を行うためのものです。しかし現実には、AIワークロードでは、すべてが結合されています。なぜなら、複雑なデータが必要だからです。もはやテーブル上の行ではなく、豊富なドキュメント構造を扱っています。数キロバイトの小さなものや数百バイトではなく、最低でも4キロバイトのデータを扱っています。メガバイト単位のデータについて話しています。これらはリレーショナルデータベースが構築されたものではなく、パフォーマンスも良くありません。
Shane: 実際、多くのお客様からは、トラディショナルなデータベースでこれらの複雑なデータ型を扱おうとすると、パフォーマンスが大幅に低下するというフィードバックをよく聞きます。特にAIアプリケーションでは、レスポンスタイムが重要ですから、これは大きな課題となります。
Rick: 私のLinkedInをぜひチェックしてみてください。そこには、PostgresのJSONBパフォーマンスとMongoDBのようなツールでのドキュメントパフォーマンスに関する素晴らしいベンチマークを公開しています。そこでは問題が即座に明らかになります。
Rick: ベクトルでの作業において、再び、セマンティック検索のようなワークロードのためにデータを関連付けています。最近人気のあるものの一つは、検索拡張生成（Retrieval Augmented Generation）と呼ばれるものです。関連するデータを取得し、更新された応答を得るためにモデルに戻して供給する能力です。診断や予測AIワークロードにこれを使用しています。しかし現実には、AIの応答を生成するワークロードにフィードバックしているデータを取得するためにベクトルを活用しています。
4.2. スタンドアロンベクトルストアの制限
Rick: 運用データの上にベクトルインデックスを実装するためには、複数の方法があります。最初の方法は、スタンドアロンのベクトルストアを使用することです。スタンドアロンのベクトルデータベースは悪くないオプションですが、問題は、データベースに保存されているのはベクトルだということです。すでに言及しましたが、ベクトルインデックスにクエリすると、ポインタが返ってきます。そのポインタが指すデータを取得する必要があります。つまり、本質的に2つのステップです。ベクトルインデックスにクエリし、次にデータを取得します。これはレイテンシであり、複雑さです。
Shane: 実際、顧客からよく聞く不満の一つは、スタンドアロンのベクトルデータベースを使用すると、システム全体のレイテンシが増加するということです。特に大規模なデータセットを扱う場合、このレイテンシは顕著になり、ユーザーエクスペリエンスに影響を与えることがあります。
Fred: 医療アプリケーションの文脈では、これは特に重要な問題です。医師が患者の診断を行っている際、数秒のレイテンシでも大きな違いを生む可能性があります。緊急の状況では特にそうです。そして、さまざまなデータソースから関連情報を迅速に取得する能力は、効果的な診断と治療につながります。
Rick: 次の選択肢は、PG Vectorのような統合ベクトルソリューションを使用することかもしれません。これはオプションかもしれませんが、シンプルな問題があるため、この方法は崩壊します。ベクトルワークロードが運用データと競合することになるのです。
Rick: Atlasで長い間前に学んだことの一つは、全文検索と分析ノードを導入したとき、ユーザーはその機能を互いに独立してスケールする必要があるということでした。最初の実装では、ユーザーがすぐに戻ってきて「全文検索が必要なのでクラスタ内のすべてのノードのサイズを上げているが、ほとんどのデータはセカンダリからヒットしているので、運用データにはそのようなアップサイズされたハードウェアリソースは必要ない」と言いました。
Shane: この問題は、特に大規模データセットや高トラフィックのアプリケーションで顕著になります。ベクトル検索は計算リソースを大量に消費する可能性があり、同じノードで運用データを処理すると、パフォーマンスに影響が出ることがあります。
Rick: そこで今、機能をリリースするたびに、プラットフォーム内で独立してスケール可能な機能としてリリースしています。実際に、ベクトルワークロードを運用データとは別に独立してスケールすることができます。基本的に、異なる構成、異なるインデックス、異なる読み取りパターン、異なる書き込みパターンをサポートする異なるノードを持つことができ、システムの効率性とスケーラビリティを高めることができます。
Fred: これは実際のアプリケーション開発において重要な利点です。私たちの乳がん検診アプリケーションでは、マンモグラフィー画像のような大きなデータセットを処理しながら、同時に高速なクエリパフォーマンスを維持する必要があります。独立したスケーリング機能がなければ、このようなバランスを取ることは非常に難しいでしょう。
4.3. MongoDBのベクトル検索の利点
Rick: これらの理由から、2023年にベクトル検索を発表しました。これは実際に、私たちが今までにリリースした新サービスの中で最も急速に採用されたものの一つでした。主にこの理由からです。運用データの上にベクトルインデックスを優雅に統合し、その機能を独立してスケールできるということです。そして私たちだけではありません。Retoolの2024年AI状況レポートでは、2年連続で「最も愛されるベクトルデータベース」に選ばれました。何千人もの専門家、AIの専門家、開発者、プロジェクトマネージャー、ビジネスオーナーが意見を寄せ、このツールが彼らのAIワークロードを構築するための最も効果的なツールだと述べています。
Shane: 実際、多くの顧客がMongoDBのベクトル検索機能を採用する主な理由の一つは、運用データとベクトルデータを単一のプラットフォームで管理できることです。これにより、ETLパイプラインの複雑さや、複数のシステム間でデータの一貫性を維持する必要性がなくなります。
Fred: 私たちの医療用アプリケーションでは、これが特に重要です。患者データは高度に規制されており、システム間でデータを移動させるたびに、セキュリティとコンプライアンスのリスクが生じます。単一のプラットフォームですべてを管理することで、データガバナンスが大幅に簡素化されます。
Rick: 正直なところ、この認識は急速に進化する市場における顧客のニーズをサポートするという私たちのコミットメントを裏付けるものです。そして、それこそが私たちの目的です。私たちは常に、開発者が配管に集中することなく、必要なことを行えるようにすることを目指しています。配管はあなたのビジネスにとって価値がありません。ETLの維持、キャッシュの一貫性の理解、サイロ間のデータの一貫性は、コンピュータサイエンティストにとっては興味深い問題かもしれません。しかし、あなたのビジネスにとって必ずしも興味深い問題ではありません。あなたのビジネスにとって重要なことに集中しましょう。
Rick: これがAIを活用したソリューションを構築するためにMongoDBツールを使用した顧客のサンプルです。これらの企業すべてがMongoDBを選んだのは、運用データとベクトルを一つにまとめる能力だけでなく、モダンアプリケーションのすべてのニーズに対応するからです。私たちはベクトルだけに焦点を当てているわけではありません。実際に運用データをサポートし、時系列、ベクトル検索、全文検索などの特殊なワークロードをサポートし、他の多くの機能も一緒にサポートしています。
Shane: そして、MongoDBのベクトル検索の主要な利点の一つは、他のMongoDBの機能との統合です。例えば、変更ストリーム、シャーディング、レプリケーションなどの機能をベクトル検索と組み合わせることができ、これによりリアルタイムの更新や高可用性を備えたロバストなAIアプリケーションを構築できます。
Rick: あなたのアプリケーションには、これらの機能が必要です。これは顧客から何度も何度も見てきたことです。これらの機能をプラットフォームに組み込んだ理由は、顧客が何度も繰り返し行っていることであり、私たちは彼らにとってより簡単にできると感じたからです。そして、実際にそうなっています。MongoDBの統合開発者データプラットフォームだけが、その単一のAPIを提供しています。開発者として、複数の技術のサイロや、複数の異なるシステムとの対話方法、異なるAPIの理解を必要としません。一つだけ理解すればいいのです。その結果、2023年の発表以来、Atlas Vector Searchに対する大きな需要が見られます。スタートアップから企業まで。
4.4. 独立したスケーリング機能
Rick: Atlasで長い間前に学んだことの一つは、全文検索と分析ノードを導入したとき、ユーザーはその機能を互いに独立してスケールする必要があるということでした。最初の実装では、ユーザーがすぐに戻ってきて言いました。「全文検索が必要なのでクラスタ内のすべてのノードのサイズを上げているが、ほとんどのデータはセカンダリからヒットしているので、運用データにはそのようなアップサイズされたハードウェアリソースは必要ない」と。
Rick: そこで今、機能をリリースするたびに、その機能をプラットフォーム内で独立してスケール可能な機能としてリリースしています。実際に、ベクトルワークロードを運用データとは別に独立してスケールすることができます。基本的に、異なる構成、異なるインデックス、異なる読み取りパターン、異なる書き込みパターンをサポートする異なるノードを持つことができ、システムの効率性とスケーラビリティを高めることができます。
Shane: これはお客様にとって大きな価値です。特に大規模なアプリケーションや変動の激しいワークロードを持つお客様にとっては、リソースを効率的に割り当てることができるため、コスト効率が大幅に向上します。
Fred: 医療アプリケーションの場合、これは特に重要です。例えば、乳がん検診のピーク時期には処理能力の需要が急増することがありますが、その他の時期は通常のレベルに戻ります。独立したスケーリング機能により、必要な時に必要なリソースだけを割り当てることができます。
Rick: 最近よく耳にする話題の一つは、研究サークルで聞いているかどうかわかりませんが、「トランスリティカルデータベース」という考え方です。一つのデータベース、ゼロETL、すべてのワークロード。トランザクション、分析、すべてを一か所で。それは素晴らしいアイデアです。私たちはその考えを10年前に持っていました。それがAtlasだったのです。
Rick: トランスリティカルデータベースについて話すとき、非常に重要なのは、ワークロードをサポートするために必要な機能のサイロを独立してスケールできることです。なぜなら、そのワークロードのすべての部分に同じ方法でノードをスケールしなければならない場合、基本的にすべてのアクセスパターンに対してクラスター全体のサイズを大きくする必要があります。そのようなことはしたくありません。
Shane: そして、お客様は実際にこの柔軟性を高く評価しています。一部のお客様では、ベクトル検索用に最適化されたノードと運用データ用に最適化されたノードを組み合わせることで、全体的なパフォーマンスを犠牲にすることなく、コストを最大50%削減できたと報告しています。
Rick: ベクトル、全文、時系列、必要なものすべてに対して独立したスケーリング機能を提供することで、それらのワークロードを優雅にサポートすることができます。これが2023年にベクトル検索を発表した理由の一つであり、これは実際に、私たちが今までにリリースした新サービスの中で最も急速に採用されたものの一つでした。主にこの理由からです。運用データの上にベクトルインデックスを優雅に統合し、その機能を独立してスケールできるということです。
5. オープンソースブループリントの選択方法
5.1. ユースケースの定義
Fred: ではどこから始めればよいでしょうか？それは素晴らしい質問です。まずは適切なオープンソースブループリントを選ぶことから始めましょう。これを行うためには、実際に異なる能力を整理して、アプリケーションや異なるワークロードを構築したり、ジェネレーティブAIで異なるアプリケーションを強化したりする際に本当に役立つものを書き、使用していることを確認する必要があります。
Fred: 最初に行う必要があるのは、ユースケースを定義することです。それは目標を理解することから始まります。ジェネレーティブAIで実際に何を達成したいのでしょうか？テキスト生成、画像生成、音声検出、あるいは他のものの構築に焦点を当てているのか、あるいはこれらすべての組み合わせなのかもしれません。
Shane: そうですね。そして多くの顧客は、始める前に明確なビジョンを持っていないことがよくあります。そのため、MongoDBのようなパートナーと協力して、AIが彼らのビジネスにどのような価値をもたらすかを理解することが重要です。
Rick: 実際、Novo Nordiskの例を思い出してください。彼らの課題は明確でした—規制当局への提出プロセスの効率化です。しかし、AIアプローチを適用する前に、具体的なワークフローとボトルネックを特定する必要がありました。
Fred: その通りです。そして、ジェネレーティブAIは既存のデータからデータを生成することから始まります。そのため、データニーズも特定する必要があります。異なるタイプのデータを考慮する必要があります。どこに解決策を見つける必要があるのか？データを処理するために何をする必要があるのか？そしてこれこそがMongoDBのクラスが実践に移される部分です。Rickが言ったように、MongoDBは非構造化データと半構造化データで本当にうまく機能することが素晴らしいことです。
Shane: 特に医療のような分野では、データの種類が多様です。患者記録、画像、センサーデータなど、これらすべてを一貫した方法で管理する能力が不可欠です。適切なデータモデルを選ぶことがブループリント選択の重要な部分です。
Rick: そして、データをどのように使用するかも考慮する必要があります。Amazonでの経験から、ほとんどのレガシーアプリケーションでは、アクセスパターンの90%が単なるテーブル上の行の操作であることを学びました。しかし現代のAIアプリケーションでは、より複雑なデータ構造が必要であり、これらの異なるデータタイプ間の関係を捉えることが鍵となります。
5.2. データニーズの特定
Fred: ジェネレーティブAIは既存のデータからデータを生成することから始まります。そのため、データニーズも特定する必要があります。異なるタイプのデータを考慮する必要があります。どこに解決策を見つける必要があるのか？データを処理するために何をする必要があるのか？そしてこれこそがMongoDBのクラスが実践に移される部分です。Rickが言ったように、MongoDBは非構造化データと半構造化データで本当にうまく機能することが素晴らしいことです。
Shane: 医療分野に限らず、ほとんどの業界でデータは多様な形式で存在します。構造化データベース、PDFドキュメント、画像、動画など様々です。MAPプログラムでは、これらさまざまなソースからデータを取り込むためのローダーを提供しています。Confluenceページ、Microsoft Wordドキュメント、PDF、PowerPoint、ウェブサイトマップ、静的ウェブサイト、YouTubeチャンネル、さらにはYouTube検索までサポートしています。
Rick: そして重要なのは、これらのデータをどのように関連付けるかです。ベクトルの重要性について説明しましたが、これらの異なるデータ型を意味のある方法で関連付けるためには、適切なデータモデルが必要です。リレーショナルデータベースでは、これは複雑なテーブル結合とパフォーマンスの問題を引き起こします。
Fred: 医療アプリケーションの場合、患者データ、マンモグラフィー画像、診断結果など、さまざまなデータ型をすべて関連付ける必要があります。これを効率的に行うためには、「一緒にアクセスされるデータは一緒に保存する」というMongoDBの原則が非常に役立ちます。
Shane: そしてデータインデックスについても考慮する必要があります。データインデックスは、効率的な検索と検索操作のために生データを準備します。大規模言語モデルは、プライベートな知識を理解し活用するために、データベースやPDFのようなファイルから抽出してフォーマットすることに依存していることがよくあります。これは非常に重要です。
Rick: さらに、データセキュリティの観点も重要です。医療データのような機密情報を扱う場合、適切なアクセス制御と暗号化が不可欠です。MongoDBでは、きめ細かいアクセス制御と暗号化機能を提供しており、規制の厳しい業界でも安心して利用できます。
Fred: また後ほどデモでお見せしますが、ユーザープロファイルに基づいてデータをマスクする機能も重要です。クエリ可能な暗号化により、権限のある人だけがデータにアクセスできるようにすることができます。これは医療業界など、厳格なプライバシー規制のある分野では特に重要です。
5.3. ドキュメントの質とコミュニティサポート
Fred: 次に、既存のブループリントを見てみましょう。GitHubリポジトリやその他のプラットフォームで多くのブループリントを見つけることができます。単にGenerative AIとMongoDBでGoogle検索を行うだけでも、本当に多くの関連リポジトリを見つけることができます。しかし、これらのリポジトリは十分にドキュメント化されているでしょうか？スタートアップキットとして実際に役立つ例はありますか？また、それに関する学習リソースはありますか？提供されているドキュメントの質はどうでしょうか？
Fred: これは、多くのものがリリースされ、1回、2回プッシュされただけで、ドキュメントの質が原因で、実際にはあまり役に立たない場合があります。コードはあるかもしれませんが、ドキュメント化されておらず、それがなければ何もできないかもしれません。そのため、チュートリアル、例、包括的なガイドが必要な部分があります。また、学ぶ必要もあります。チュートリアルとその質についても確認して、それを使用する方法、それから何かを構築する方法を本当に助けてくれるかどうかを確認する必要があります。
Shane: そうですね。ドキュメントの質は、良いブループリントを選ぶ上で最も重要な要素の一つです。チュートリアルは明確で、ステップバイステップのアプローチを提供し、初心者でも簡単に理解できるものであるべきです。MAPプログラムでは、このようなドキュメントの質を特に重視しています。
Rick: また、そのチュートリアルがどのようにライセンスされているかも重要です。オープンソースライセンスなのか、それとも何らかの制限があるのか？それを使用して何かを構築することができるのか、それともただ試すだけで、本番環境に移行すると悪夢が始まるのか？その場合、GitHubリポジトリやドキュメントなどのプロセス全体に戻って時間を無駄にしてしまうかもしれません。
Fred: そうですね。その後、良いブループリントを見つけても、それがどのように機能するかを確認するために、少し検証する必要があります。また、何かを構築するときにサポートがあるかどうかもチェックする必要があります。そのため、アクティビティレベルも確認する必要があります。また、コミュニティの中でチャンネルに問題や議論があるかどうかも見つける必要があります。コミュニティが強ければ強いほど、より良いです。
Shane: 実際、活発なコミュニティがあることは非常に重要です。問題に遭遇した場合、助けを求めることができ、他の開発者の経験から学ぶことができます。MAPでは、MongoDBの専門家チームとパートナー企業の専門家が緊密に連携しており、顧客が直面するあらゆる課題に対応できる体制を整えています。
Fred: また、レビューも適切なものを選ぶ上で非常に重要です。フィードバックが必要だからです。そして、悪いフィードバックがあれば、それを廃止することになるかもしれません。そのため、良いサポートと高いアクティビティレベルのあるものを見つける必要があります。そうすれば、ブループリントから何かを作るとき、問題があっても何らかのサポートを得ることができ、バグが修正され、何かを得ることができるでしょう。
Rick: 最終的には、これらのオープンソースブループリントの価値は、それらを採用し改善するコミュニティの活気によって決まります。GitHubの星の数、フォークの数、アクティブなコントリビューターの数など、これらはすべてプロジェクトの健全性を示す指標です。そして、MongoDBとのパートナーシップを通じて、これらのブループリントがプロフェッショナルのチームによってサポートされていることを確認できます。
5.4. セキュリティとコンプライアンス
Fred: ブループリントを選んで、それがうまく機能することを確認したら、それをフルエコシステムに統合する必要もあります。MongoDBやAWSとうまく統合されるでしょうか？使用している生成モデルとスケールする方法はどうでしょうか？初日のアプリケーションは小さいかもしれませんが、1ヶ月後、2ヶ月後、6ヶ月後、1年後はどうなるでしょうか？進化できるものが必要です。
Fred: そして確かに非常に重要なことはセキュリティです。私のデータは本当によく保護される必要があります。これは、機密データを保護するためのベストプラクティスにも準拠する必要がある点です。これは、デモの中で後ほど少し示すことになるでしょう。データセキュリティは本当に複雑で重要だからです。
Shane: セキュリティは特に医療分野では最重要課題です。患者データは高度に機密性が高く、HIPAA（米国健康保険の携行性と責任に関する法律）やGDPR（EU一般データ保護規則）などの規制に準拠する必要があります。MongoDBはクエリ可能な暗号化、フィールドレベルの暗号化、きめ細かいアクセス制御など、これらの要件を満たすための強力なセキュリティ機能を提供しています。
Rick: また、セキュリティはデータベースレベルだけでなく、AIモデルとの統合にも関わってきます。特に機密データで訓練されたモデルは、データ漏洩のリスクがあります。MAPエコシステムのパートナーは、セキュアなモデル統合のための最先端の手法を提供しています。
Fred: さらに、働いている業界によっては、すべてのコンプライアンスを確保する必要もあります。これは、デプロイするときにデータとアプリケーションの両方のコンプライアンスを確保できることを確認するために、非常に重要であるべきです。なぜなら、これはデータベースだけでなく、アプリケーションにも関わることだからです。
Shane: そうですね。多くの規制では、監査証跡や暗号化などの技術的要件だけでなく、プロセスとポリシーも定義しています。MAPプログラムでは、技術的な実装だけでなく、これらのプロセス要件に対応するための専門家のアドバイスも提供しています。
Rick: また、Novo Nordiskの例で見たように、製薬業界では非常に厳格な規制があります。彼らが新しい医薬品に関する臨床試験レポートを実行するたびに、世界中の110の機関にわたって結果を提出するために約6ヶ月のプロセスを経ています。このようなコンプライアンス要件を満たしながら、AIの力を活用して、このプロセスを10分に短縮することができた例は、セキュリティとコンプライアンスを妥協することなく、効率性を大幅に向上させることができることを示しています。
Fred: そして、適切なブループリントを選んだら、それでプロトタイプを作ることから始めます。約束のあるブループリントをいくつか分岐して、どのようなものになるかを確認することをためらわないでください。また、そこでパフォーマンスも重要です。パフォーマンスはアプリケーションにとって非常に重要です。エンドユーザーエクスペリエンスにも影響するからです。また、ほとんどのブループリントはサンプルデータセットと一緒に提供されるかもしれませんが、あなた自身のデータセットも使用して、ユースケースと環境内で期待通りに機能することを確認してください。
6. MongoDB AI Applications Program (MAP)
6.1. プログラムの概要と目的
Shane: ありがとう、Fred。ベクトル検索の成功と、Rickが最初に説明したことを踏まえて、2023年以降、すべての顧客とクライアントから、彼らのジェネレーティブAIアプリケーション構築の支援を求める質問を受けました。そこで6月にニューヨークでのMongoDB.localで、MongoDB AI Applications Program、略してMAPと呼ぶものを発表し、立ち上げました。
Shane: これは何で、何のためのものなのでしょうか？今日の競争の激しい環境では、革新的な技術を活用することがますます難しくなっています。しかし、すべての人がジェネレーティブAIとその可能性を活用して、アプリケーション、ビジネス、そして必要なことを変革したいと考えています。MAPは、MongoDBと後ほど見ていただけるいくつかのパートナーによって提供される包括的なソリューションで、これを簡単に、スケーラブルに、そして高度なAI機能を備えたパフォーマンスの高い方法で実現することを可能にします。
Shane: MAPの成功は、今日の最先端のAIパートナーとの強力なパートナーシップにかかっています。これらのパートナーと協力することで、MAPプログラムを通じて、今日利用可能な最も先進的な技術にアクセスできることを保証します。また、MAPは基本的にサービス提供でもあります。顧客がより速く、より迅速に構築できるよう支援するために、戦略的アドバイスや包括的な技術スタックのデモと統合などのプロフェッショナルサービスを提供しています。
Rick: このプログラムは、私たちが長年にわたって観察してきた問題に対応しています。多くの企業がAIの可能性を理解していますが、実際に統合するためのリソースや専門知識を持っていません。MAPは、この技術的なギャップを埋め、企業がAIのメリットをすぐに活用できるようにします。
Fred: そして医療分野のようなドメイン固有の用途では、これは特に重要です。例えば、放射線科医は画像分析のAIツールの価値を理解していますが、それを既存のシステムに統合するためのテクニカルスキルを持っていないかもしれません。MAPプログラムは、このギャップを埋めるのに役立ちます。
Shane: Rickが最初に触れたスプロール、開発のスプロールについてさらに詳しく説明します。「組織の65%がAIを定期的に使用していると主張している」という統計は素晴らしいです。私たちの分野では、AIとジェネレーティブAIは2年間存在しています。機械学習とAIはずっと長く存在しています。しかし、私たちが今日知っているジェネレーティブAIは、本当に公の議論の中で2年間だけです。私たちはこのシフトを活用しようとしており、すべての企業がこのシフトを活用しようとしています。
Shane: しかし、AIアプリケーションを作成する意欲にもかかわらず、多くの企業はすぐに課題や困難を経験しています。これらは多岐にわたりますが、特にAIモデルへのデータ統合に関するものです。これがどのように支援するかをお見せします。つまり、彼らのアプリケーションはうまく機能していますが、十分にうまく機能していないのです。
6.2. パートナーシップとエコシステム
Shane: 私たちが発展するAI環境の課題に加えて、複雑な統合問題、つまり私たちの顧客のほとんどが直面している問題があります。他にも2つのことがあります。レガシーテクノロジーに縛られていると感じており、それが彼らが構築し、生成したいアプリケーションを構築する能力を妨げています。変化する市場条件に適応しようとしていますが、レガシーテクノロジーで作業しているため、それをリアルタイムで管理することができません。Rickが話したマルチモーダルはレガシーテクノロジーでは機能せず、今日のインテリジェントなアプリケーションが要求する期待に応えられません。
Shane: 第二に、そして全体を通して普及しているのは、専門知識の不足に苦しんでいることです。これはほとんどの開発者にとって、ほとんどの企業にとって新しい分野です。彼らは社内にAI開発の専門知識を持っていません。そしてその不足により、統一されたサポートシステムなしにこれらの種類のプロジェクトを引き受けるリスクの認識が高まります。彼らはこの課題と今日のジェネレーティブAI開発の複雑さを解決するための信頼できるアドバイザーを求めています。
Shane: MongoDBの技術に加えて、私たちはあらゆる段階でAIアプリケーション開発を促進するために、ツールとサービスの両方を組み合わせたMAPを作成しました。さらに、このプログラムは、企業の特定の技術ニーズ、特定の予算、特定の開発者の経験とタイムラインに合わせて調整されています。
Fred: これは特に重要です。なぜなら、すべての組織が同じスタート地点にいるわけではないからです。一部の企業は既にAIの実験を行っているかもしれませんが、他の企業はまだ初期段階かもしれません。MAPプログラムは、現在の能力レベルに関係なく、各組織が次のステップへ進むために必要なものを提供します。
Shane: 私たちのMAPエコシステムでは、統合とパートナーを慎重に選択し、整理しました。私たちはコンポーザビリティを中心にMAPエコシステムを構築しました。異なるパートナー、異なる技術をリフトアンドシフトする能力です。これらすべてを専門家のサービスとサポートで包んでいます。したがって、開発を加速し、AIアプリケーションの構築に関連するリスクを最小限に抑えるための支援を提供することができます。それがプロトタイプであれ、技術統合であれ、本番デプロイメントであれ、どの段階でもです。
Shane: 最後に、MAPプログラムの一部として、自分のチームが独自のアプリケーションを開発するために高度なスキルを身につけることができるよう、統合と開発のベストプラクティスへのアクセスを含むリソースを提供しています。MAPは全体として、市場投入までの時間を短縮し、リスクを最小限に抑え、AIへの投資価値を最大化します。
Rick: このパートナーシップモデルは、Novo Nordiskとの作業で効果を発揮しました。AWSとLangChainと共同で、彼らの問題に対するソリューションを構築したとき、一緒に働くことで、6ヶ月のウィンドウを10分に削減しました。これは各組織が自分の強みを持ち寄って、ユーザーにとって非常に価値のあるものを作り出した例です。
Shane: エコシステムについて話しましたが、これはどのようなものでしょうか？私たちはAI分野の主要な企業のほとんどと連携しています。MongoDBとそのオープンアーキテクチャにより、基本的には誰とでも協力することができますが、私たちの顧客のために、MAPにおいて私たちのスタックを完成させるために、世界の主要なAIおよび技術組織のセットをまとめました。
Shane: これらを選ぶことで、私たちと共に主要な組織自体が、AIスペースにタップする能力の柔軟性とデモンストレーションを作ることにコミットしています。始めるのがとても簡単で、これらが私たちがパートナーシップを結んでいる企業であると知ることは非常に心強いです。これらのパートナーを選び、MAPの中で行ったアーキテクチャ設計により、本質的にこのエコシステムを作りました。まだ始まったばかりで、常に新しいパートナーを追加しています。先週だけでも数社発表しました。
6.3. 主要な価値提案
Shane: 私たちは開発者が差別化された本番環境対応のAIアプリケーションを作成できるようにすると同時に、投資に対する実質的なリターンを提供することを目指しています。コンポーザブルな性質を考えると、「どんなベクトルストアでも選べる」と言う人がいるかもしれませんが、それは問題ありません。しかし、Rickが最初に説明したように、MongoDBが一般的にこれらのアーキテクチャ内で提供する主要な中核的価値を見失ってはなりません。
Shane: これらの中核的価値は、運用データとベクトルデータの両方のためのユニークなデータストアであるということです。Rickが指摘したように、ETLを回避しています。構築する必要も、維持する必要も、追加のオーバーヘッドを維持する必要もありません。そしてその観点から、全体的により良いユーザーエクスペリエンスになります。
Shane: それは統一された開発者エクスペリエンス、私たちの開発者データプラットフォーム、Rickが詳細に説明したすべてです。MongoDBクエリAPIはそのすべてにアクセスできます。また、MongoDBにアプリケーションを作成する開発者が、基本的にMongoDBのベストプラクティスに基づいた情報を持つツールを持っていることを確認するためにさらに一歩進んでいます。
Shane: 現在のすべての開発者はコードアシスタンスを使用しています。いくつかあります。特にAmazon Q developerを微調整し、トレーニングしました。1年以上前に、QとCode Whispersが当時どのように開発者と連携するかを理解し、コマンドや何らかのMongoDBへの接続を呼び出す開発者が、プロンプトに基づいてベストプラクティスコードを返されることを確認するように招待されました。つまり、そのコードを最初に書く際の開発者の生産性を向上させています。
Rick: これは非常に重要なポイントです。MongoDBは単にデータベースを提供するだけでなく、開発者が最初からベストプラクティスに従うことができるようサポートしています。私たちのアプローチは常に、開発者がデータモデリングやクエリパターンについて考える時間を減らし、ビジネスロジックに集中できるようにすることでした。
Shane: もちろん、MongoDBはこれらのAIアプリケーションが多くの企業にもたらす指数関数的な成長に対応します。Atlasのオートスケールのおかげで、ハードストップはありません。そして議論したように、ベクトル最適化検索ノードによるネイティブベクトル検索機能とボトルネックを回避する能力があります。
Fred: 医療アプリケーションにおいて、これは特に重要です。例えば、乳がん検診のピーク時期には処理量が急増することがありますが、その他の時期は需要が低いかもしれません。自動スケーリング機能により、常に最適なパフォーマンスとコスト効率を維持できます。
Shane: したがって、開発者データプラットフォームの観点から、これらのアーキテクチャ内でコンポーザブルではありますが、MongoDBは依然として最適な選択肢です。私たちが初期のスペースで行ったことは、多くの顧客と企業が最も頻繁に使用するジェネレーティブAIのアプリケーションの一つであるRAG（検索拡張生成）を見ることでした。どのように支援できるでしょうか？パートナー全体のスイートとベクトル検索、Atlas検索、ストリーム処理などを活用してアーキテクチャを構築し、素早く自信を持って始められるものを提供します。
Rick: 最終的に私たちが創造しようとしているものは、AIアプリケーション開発を民主化し、専門家チームでなくてもAIの力を活用できるようにすることです。MongoDBとMAPは、その複雑さを抽象化し、開発者がAIソリューションを実装するための統合、テスト済みのブループリントを提供します。
7. 乳がん検診アプリケーションの事例
7.1. アーキテクチャと実装
Shane: 理論、規模、そしてMongoDBがどこに適合するかについて議論してきましたが、今からは具体的な例に入りたいと思います。Rickが言ったように、私たちはチャットボットを作りたくありません。そこで、本当に効果的な例を示したいと思います。昨年10月は乳がん啓発月間でした。これは世界中の人々に直接的または間接的に影響を与える問題です。少なくとも10%の女性がいずれかの段階でこれに遭遇するでしょう。スクリーニングと事前スクリーニング、検査の努力によって、何十万もの命を救いながら、これが最小限に抑えられてきたのです。
Shane: 私たちが検討したのは、より大きなケーススタディで、このデモのより大きな例を持っています。今日はすべてを紹介する時間はありませんが、ジェネレーティブAIで構築されたアプリケーションが、医師、臨床スタッフ、患者に最新の情報を提供できるとしたらどのようなものかを想像してみました。それが今日お見せしたいものです。
Fred: ありがとう、Shane。さあ、始めましょう。乳がんだけでなく、あらゆる種類のがんで本当に重要なのは予防についてです。私たちにとって予防は、どのように始めるかということです。ピンク・オクトーバーでは、すべての人、すべての女性が検査を受けるよう促されています。それはマンモグラフィーから始まります。このサンプル企業には、女性が行ってマンモグラフを受けることができる専用のセンターがあります。また、マンモグラフを処理し、フォローアップを行うためのプログラムもあります。
Fred: では、これがどのように機能するのか、少し実践的に見てみましょう。それを構築するために必要な異なるコンポーネントと少しのアーキテクチャについてです。まず、もう一度ドキュメントモデルから始めます。これは非常に重要なことです。このデータでは、本当に構造化されたものだけでなく、データの観点から非構造化されたものも必要であることがわかるでしょう。
Shane: しかし、これらのすべての異なるセンターと臨床サポートからデータを取得しているのですね？すべてがデータを送っているのですね？
Fred: そうです。そして、これは本当にずっと複雑です。なぜなら、これだけでなく、おそらく私のさまざまな患者に応じて、さまざまな検査なども行うでしょう。
Shane: そうですね。
Fred: そのため、異なる種類のデータモデリングも取得することになります。つまり、すべての患者が異なるのです。
Shane: でも、あなたのデータは医療シナリオなので、構造化、非構造化、半構造化されていますよね？
Fred: その通りです。すべてであり、これもMongoDBの美しさです。私はスキーマ強制も少し確保できるので、私の患者があなたの患者であり、予約が予約であることを確認できます。そして、マンモグラフについても同様です。マンモグラフに私の犬の写真を取得したくありません。それは意味がありません。
Shane: では、それは実際にどのように見えるのですか、Fred？
Fred: 実際には、どのように見えるかというと、先ほど言ったように、実際に私にはさまざまな放射線センターがあり、すべての患者がそこにいます。見てのとおり、私のさまざまな放射線センターから来るさまざまなタイプのデータがあり、これらのデータはすべて中央に集められています。これも私のグローバルエージェンシー内にあります。では、私たちのドキュメントモデルを少し見てみましょう。
Shane: それがどのように見えるか見てみましょう。
Fred: はい。ご覧のように、私の予防に本当に重要になるさまざまなテーブルがあります。患者、予約、研究、場所などを取得します。実際に私が持っているもの、そして構築したものは、MongoDBにおいて非常に重要なものに基づいた何かです。つまり、一緒にアクセスされるデータは一緒に保存されます。そうすることで、アプリケーションも加速し、開発者である私とあなたが皆開発を加速し、ビジネスに本当に集中できるようになります。
Rick: これは実際、データベース設計の基本的な原則です。一緒にアクセスされるデータは一緒に保存すべきですが、リレーショナルデータベースではこれが難しくなります。正規化の原則が、自然な形でデータを保存したいという欲求と対立するからです。MongoDBのドキュメントモデルでは、データを使用する方法と同じ方法で保存できるため、この問題が解消されます。
7.2. ドキュメントモデルの活用
Shane: スライドだけではありませんよね、Fred。実際にどのように見えるか、ビデオで見せてください。
Fred: はい、それでは私たちの側からどのように見えるか見てみましょう。これが私たちが持っているデータベースです。私たちのアプリケーションにはいくつかの異なるデータベースがありますが、バーチャル病院という一つに本当に焦点を当てます。
Fred: 患者を見ると、実際にすべての患者のデータがあり、それらはすべてよく構造化されています。PIIデータを含むすべての情報を持っています。これだけでなく、私は予約に関するコレクションも持っています。予約に関連するすべての関連データがあります。なぜなら、私が行うとき、予約をするだけだからです。
Fred: そのため、私の予約に関連するすべてのデータがそこにあります。そして私はフォローアップをすべて行うことができます。そして予約がどのように進むかによって、必要なすべての機能を追加することができますし、アプリケーションを必要に応じて進化させることもできます。
Shane: それでは、これがAtlasとMongoDBのドキュメントとコレクションにバックアップされている構造と保存方法です。私たちが言ったように、構造化、半構造化、非構造化、すべてを収容できます。これが医師が見るものに向かってどのように展開するのでしょうか？プロセスは何ですか？これは実際に動作しているアプリです。勇気がなかっただけで、ビデオだけを示しています。問題が発生しないようにしていますが、これを後でチェックアウトすることもできます。これは適切に実行されているアプリですが、診断についてはどうでしょうか？患者が来たときに何が起こるのでしょうか？
Fred: 実際に、私の患者が来たとき、最初に行うのはテストです。私たちは患者を取得します。患者が来て、異なるマンモグラムを撮ります。そして本当に重要なことの一つは、マンモグラフィーを取得したら、そこから関連するすべての情報を抽出する必要もあります。何か問題があるかどうか、また医師がレポートを生成するのを助けることで、すべてを持っていることを確認し、それが治療とこのようなプロセスすべてを加速することになります。
Fred: そして、Rickが話したNovo Nordiskの事例を覚えておいてください。私たちはすべてを加速しました。マンモグラフィーに基づいてレポートを生成するために生成AIを使用することで、すべてを実際にどれだけ加速できるかをライブで見ることができます。
Shane: わかりました。それでは生成AIの段階に入りますね。それはどのように見えるのでしょうか？
Fred: もう一度アーキテクチャ自体について少し見てみましょう。ご覧のように、同期と統合も少し使用します。なぜなら、診断を行うときに本当に重要なことは、新しい追加の検査が来るかもしれないということだからです。そのため、最新の情報と持っている最新のものに基づいて、すべてのレポートを更新することができる必要があります。
Shane: それならば変更ストリームが関係してきますね。
Fred: そしてここで変更ストリームが関係してきます。しかしこれだけではありません。なぜなら、実際に私が取得したいのは、異なるマンモグラフィーの履歴も保持することだからです。ここで実際には、私のマンモグラフィーをS3バケットに保存し、すべてのメタデータと私のベクトルデータを本当に私のドキュメント内に保存します。
Shane: わかりました。リファレンスアーキテクチャを示すと、このフローがすべてです。ここには多くのステップがありますが、MongoDBはそれをとても簡単にします。少し説明してからデータを見せてください。
Fred: このようにして動作します。実際には、4つのマンモグラムを撮り、それらを画像として処理します。これらの画像を取得し、この点ではチェーンAIではなく、少しマシンラーニングを行って、スコアリングを行います。このスコアリングは、物事を検出できるかどうかを判断するのに本当に役立ちます。これは医師だけでなく、RAGロジックにも役立ち、どのように振る舞うかを確実にします。そして画像を修正し、それはアップロードされてS3バケットに保存され、スコアを計算し、そのスコアの結果がドキュメント内に作成されます。
7.3. AIを活用した診断レポート生成
Shane: わかりました。私は医師で、技術的なことは気にしません。リファレンスアーキテクチャは気にしません。そこで何が起こるのですか？
Fred: ああ、そうですね、あなたは医師ですね。それは良いですね。
Shane: 昇進ですね。
Fred: はい、素晴らしい昇進ですね、Shane。実際、あなたがオフィスに着いたときに最初にすることは、まずその日の予約をすべて見ることです。そしてこれがあなたが持っているものです。すべての医師がそこにいるのが見えます。また、今日の準備ができているさまざまな患者がいることがわかります。
Fred: 最初の患者、Ameliaが到着し、マンモグラフィーの準備ができています。異なるマンモグラフィーを撮りますが、ご覧のように、それがあります。そして私たちはライブでBI-RADSスコアを計算しています。これは...
Shane: デモの目的のために非常にスピードアップされていますが。
Fred: はい、実際にはほんの数秒です。少しスピードアップされていますが、重要なことの一つは、すべてのマンモグラフィーが撮影されると、私のクリニックノートを生成することができます。そのため、行ったすべての観察に基づいて、すぐに手に入ります。しかしクリニックノートだけではなく、私の結論も生成することができます。そのため、私のすべての情報が本当に保存されています。
Fred: そして私が持っているのは、ただ報告書を保存し、私のデータがMongoDBに保存されるだけです。素晴らしいことは、では背景でどのような異なるステージが行われたかを見てみましょう。最初に行ったことの一つは、報告書を生成しました。そして私たちが見ることができるのはデータです。私のすべてのデータが行われていますが、同時に報告書を生成し、それからベクトルを生成したことも見ることができます。これは素晴らしいことです。しかし、MongoDBにはどのように保存されていて、私が行った2番目のAPI呼び出しは何だったのでしょうか？そして私のドキュメントを見ると、長いドキュメントですが、私の報告書についてのすべての情報、クリニックノート、そしてそこからのベクトルも持っています。そのため、後で検索するとき、ハイブリッド検索、セマンティック検索、またはただの検索を行うことができます。
Shane: 素晴らしいですね。そしてRickが先ほど言ったように、Novo Nordiskのケーススタディでは数ヶ月から数分へ、これは現実です。
Fred: これは現実です。まさにそれを言おうとしていました。
Rick: これは全く同じワークロードではありませんが、非常に似たような演習です。臨床試験の結果を処理して報告書を生成し、再び6ヶ月のサイクルを10分のプロセスに短縮します。これをリアルタイムで見ているのです。医師がそれらの画像をすべて分析し、そのデータをすべて確認して結論を導き出すのにどれくらい時間がかかるでしょうか？そして彼はAI生成の応答を確認し、比較するのにどれくらい時間がかかるでしょうか？
Rick: 私はこれを見ていて、これはCopilotのようだと思います。コードを書くときのCopilotのようです。コードを生成し、開発者として私はそれを検証します。これは医師に同じ機会を与えます。応答を生成し、彼の専門知識を使ってそれを検証します。これは本質的に彼の情報処理能力を拡大しています。置き換えるのではなく、単に拡大しているのです。これがこのツールで私が好きなところです。
Shane: そしてスピードと、すべてを最新に保つ能力。しかし、報告書を生成した後に、医師であろうと、看護師であろうと、関与する臨床医であろうと、その報告書内の情報を活用する能力です。それはどのように機能するのですか、Fred？
7.4. 自然言語検索機能
Fred: これは本当に重要なことであり、ここで医師や誰か、あるいは助手、さらには患者が行っていることは、実際にデータを見ることです。彼らは自然言語処理クエリを行います。なぜなら、SQLやMQLクエリタイプのような形式のクエリに慣れていないからです。それは本当に難しいでしょう。そこで私たちが行うのは、ユーザープロンプトを生成することです。それが処理され、ベクトル化されます。そして、結果を提供するAPI呼び出しを取得します。
Shane: わかりました。先ほどマンモグラムの分析を見ましたが、今度は生成AIをさらに活用しています。プロンプトを入力するだけでどのように操作できるか見せてください。
Fred: 現在行っていることは、会社内の誰もが使えるものを作ることです。そして良いことは、ご覧のように、プロファイルに応じて、異なるデータをマスクすることもできることです。これはクエリ可能な暗号化のおかげで、データにアクセスできる人だけがデータにアクセスできるようになっています。そして、ご質問いただいたように、医師は単一の場所ですべてのデータを見ることができます。もう少し深く掘り下げたい場合、実際にAtlasチャートを使用して分析を行うこともできます。そうすれば、私のすべてのデータを見ることができます。
Shane: わかりました。それでは、操作したり、チャートで見たりできますが、学ぶこともできます。そして患者自身が帰宅した後に少し情報を調べることもできると言われていました。RAGシステムがここでどのように構築されているかについても少し示したいと思います。これは実際に、その後の治療についてのフォローアップ部分です。
Fred: はい。
Shane: そして、今月、今週、今年どれだけの患者が来たか、どの年齢層の間でなどのレポートを実行する方法についてもです。クエリ機能の点で非常に強力です。
Fred: はい。そしてこれは本当に重要なことです。なぜなら、患者を助けるために次に得たいものは、治療のフォローアップができることであり、新しいことや新しい治療法が出てきた場合、それが患者の健康にどのような影響を与えるかを確認することができます。そこで、緊急の注意が必要な患者がいる場合、それをどのように得ることができるかについても少しフォローアップがあります。少し音楽と共にそれがどのようになるか見てみましょう。
Shane: わかりました。このスレッドでは、今何を見ているのですか？何を見ているのですか？
Fred: ここで見ているのは、まだ患者がいますが、結果について少し知りたいと思っており、結果から何が得られるのかを検索できるようにしたいと思っています。そして重要なことは、私は医師ですが、新しい患者が来て、推奨される治療や取引が必要かもしれないということです。これがセマンティック検索の美しさです。「現在推奨されるアクションが必要なすべての患者を表示して」と入力します。
Rick: はい。これは単純な英語のプロンプトを入力して取得したものです。システムの使い方を学ぶ必要はありません。追加の治療が必要なすべての患者を表示するように言えばいいのです。
Fred: そうです。しかし実際にはもう一歩進むことができます。緊急のアクションが必要なすべての患者を表示するよう頼むこともできますし、おそらく年齢の範囲内でも可能です。例えば、45歳から65歳の間で、がんの疑いのあるすべての患者を表示してくださいと言えば、そのようなすべてのデータとそれに該当するすべての患者が表示されます。
Shane: ここではハイブリッド検索を行っていますね、年齢のプリクオリファイヤーを使って。
Fred: そうです。
Shane: 素晴らしいですね。
Fred: そうです。そして、がんの疑いの結果も含めており、すべて自然言語で行っています。
Shane: わかりました。それでは、RAGについて多く話しましたが、RAGを使用してアプリケーションに簡単に研究を追加する能力が根底にあります。どのような形式であれ、ドキュメントをS3などにアップロードして、このアプリケーションに追加した別の機能を作成することができます。そうですよね、Fred？
8. まとめと次のステップ
8.1. 主要な学びと提案
Rick: それでは、このセッションの主なハイライトとMAPプログラムについてまとめましょう。もし組織内でAIワークロードに取り組んでいるのであれば、ぜひMAPがどのように組織がモダンアプリケーションの構築とデプロイを支援するかを検討してください。今日お示ししたのは、MongoDBとAIの有用なユースケース、そしてこのようなパイプラインワークロードを構築する方法の例です。
Rick: MongoDBがどのようにAIワークロードの構築を支援できるかについてもっと知りたい場合は、スライドに表示されているリンクを参照してください。QRコードをスキャンしてください。そして、時間を割いていただきありがとうございます。
Shane: Fredから今日ここにいる皆さんへもう一つのプラグがあります。
Fred: まだここにいる皆さんのために、無料の新しいトレーニングも開始しました。MongoDBとAWSでこのタイプの生成AIアプリケーションを構築する方法についてです。QRコードをスキャンすれば、トレーニングに登録することができます。
Fred: re:Inventに参加している方々のために、学習バッジを取得すれば、ご覧のようなバックパックを手に入れることができます。
Rick: 素晴らしい。
Shane: ありがとうございました。
8.2. 無料トレーニングの案内
Fred: まだここにいる皆さんのために、私たちは新しいトレーニングを無料で開始しました。このタイプの生成AIアプリケーション、つまりMongoDBを使ったAWS上のジェネレーティブAIアプリケーションの構築方法についてのトレーニングです。QRコードをスキャンすれば、このトレーニングに自分自身を登録することができます。
Fred: また、re:Inventに参加している皆さんへの特典として、学習バッジを取得すれば、ご覧のような素敵なバックパックを手に入れることができます。
Rick: 素晴らしいですね。
Shane: 皆さん、どうもありがとうございました。
このセッションの最後に、発表者たちは参加者にMongoDBとAWSを使用した生成AIアプリケーション構築に関する無料のトレーニングプログラムを紹介しました。このトレーニングはQRコードをスキャンすることで登録でき、特にAWS re:Inventの参加者にとっては、学習バッジを取得することで特別なバックパックを獲得できる機会も提供されています。このトレーニングは、セッションで示された乳がん検診アプリケーションのような実用的なAI統合ソリューションの構築方法を学ぶための貴重なリソースとなっています。