※本記事は、ACM（Association for Computing Machinery）が主催するKDD 2024（Knowledge Discovery and Data Mining Conference 2024）における招待講演者Alex Jaimes氏（Dataminr社 Chief AI Officer）による講演「実践的AIスケーリングの現在～緊急対応システムにおける実装と知見～」の内容を基に作成されています。本記事は、講演内容を要約・構造化したものです。なお、本記事の内容は講演者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性があります。正確な情報や詳細な文脈については、オリジナルの講演映像をご覧いただくことをお勧めいたします。
Alex Jaimes氏は、Dataminrのエンジニアリング、データ、AI部門を統括するChief AI Officerとして、リアルタイムイベント検知/緊急対応、ヘルスケア、自動運転車、メディア、通信など、多様な産業におけるAI製品の開発をリードしてきました。また、Columbia大学、KAIST、Yahoo、Telefónica、IBM、AT&T Bell Labs等での20年以上にわたる国際的な研究・開発経験を持ち、100以上の特許と論文（h-index 43）を発表し、約9,000回の引用を受けています。
1. 緊急対応システムの背景と課題
1.1 Kings Cross駅火災事例(1987年)の教訓
数十年前、ロンドンのKings Cross駅で発生した悲劇的な事例から、緊急対応システムの重要な教訓を説明したいと思います。この事例は、点対点のコミュニケーションの致命的な欠陥を明確に示しています。
事の始まりは、一人の通勤客がエスカレーター下部から出ている煙を発見したことでした。その通勤客は駅員に報告しましたが、その駅員は煙を確認したものの、適切な対応を取らずに通常業務に戻ってしまいました。その後、別の通勤客が別の駅員に同様の報告をしましたが、やはり効果的な対応は取られませんでした。
状況が深刻化する中、駅の検査官が通報を受け、現場を確認しに行きました。しかし、検査官は消火スプリンクラーシステムを操作する権限を持っておらず、システムは施錠されていたため使用できませんでした。
最終的に、誰かが警察官に煙の存在を報告しましたが、当時の地下では無線通信が機能しなかったため、警察官は地上に上がって消防署に通報する必要がありました。最初の煙の発見から約30分後にようやく消防隊が到着しましたが、この遅延の結果、31人の尊い命が失われることとなりました。
この事例で明らかになった主な問題点は以下の通りです：
- 様々な関係者間での点対点のコミュニケーションの非効率性
- 部門間の連携不足
- 緊急時の対応権限の不明確さ
- 消防署への通報の遅延
この事例は、緊急時における効果的なコミュニケーションシステムの重要性と、部門間の適切な連携の必要性を痛感させる歴史的な教訓となっています。残念ながら、これらの課題の多くは現代においても完全には解決されていません。
1.2 現代の緊急対応における課題
残念ながら、Kings Cross駅の事例から数十年が経過した現代でも、同様の問題が続いています。最近の具体例として、私の友人が体験したニューヨークの駅での出来事を共有したいと思います。
この友人はFacebookに、駅のホームに不審な放置バッグを発見したことを投稿しました。彼女は適切な対応として911（緊急通報）に連絡しましたが、911のオペレーターは、これは彼らの管轄ではないとして、代わりに交通局に連絡するよう指示しました。
彼女は指示に従って交通局に連絡しましたが、交通局は「調査します」と言っただけでした。その後、10分から15分が経過しましたが、何の対応も見られませんでした。結局、彼女は電車の到着時刻となり、不審物が気になりながらも電車に乗って現場を離れざるを得ませんでした。
幸いなことに、この事例では実際の危険な状況には発展しませんでしたが、もし本当に危険物であった場合、深刻な結果につながった可能性があります。この事例は、現代においても以下のような重要な課題が継続していることを示しています：
- 緊急対応機関間での管轄の縦割り
- 責任の所在が不明確なことによる対応の遅延
- 市民からの通報に対する適切な初動対応の欠如
- 組織間での情報共有と連携の不足
これらの課題は、Kings Cross駅の事例で見られた問題と本質的に同じものです。テクノロジーが進歩した現代においても、組織的な課題は依然として解決されていないのです。
1.3 中央集権型vs放送型の情報伝達モデル
従来の中央集権型緊急対応モデルでは、市民が911（欧州では112）に電話をかけ、ディスパッチャーがその通報内容を判断して、適切な対応部門（救急車、消防、警察など）に振り分けるという流れになっています。このモデルには本質的な遅延が内在しています。誤解のないように申し上げますが、私は911への通報を否定しているわけではありません。しかし、このような中央集権型モデルと、現代のソーシャルメディアに代表される放送型モデルには、大きな違いがあります。
放送型の情報伝達モデルの特徴は、以下の3点に集約されます：
- 速度：ソーシャルメディアや公共データプラットフォームに投稿された情報は、瞬時に利用可能になります。
- 規模：情報は同時に世界中の人々にアクセス可能となります。
- 範囲：世界のどこで地震が発生しても、即座にアラートを受け取ることができます。
このような情報拡散の方法は、緊急対応機関の活動を根本的に変革しました。例えば、サンディ・ハリケーンの際には、2000万件以上のツイートが発信されました。救急対応チームはこれらのソーシャルメディア情報を活用して、大規模な緊急事態の全体像を把握し、どこで支援が必要とされているのかを理解しました。
さらに興味深いのは、停電時でも携帯電話のシステムが機能している場合、このような情報伝達は継続可能です。実際の現場の状況がリアルタイムで共有されることで、緊急対応の効率と効果が大きく向上しています。このように、ソーシャルメディアは単なるコミュニケーションツールを超えて、緊急対応における重要な情報源となっているのです。
2. DataMinerのイベント検知システム
2.1 システムの概要と規模
DataMinerは、緊急対応を必要とするイベントやコーポレートセキュリティ対応、そしてニュース性の高い速報イベントを検知するプラットフォームです。我々のシステムは、パブリックデータから関連イベントを検知し、それらのイベントに関するアラートを発信しています。
システムの規模と対応範囲は以下の通りです：
我々は100万以上のパブリックデータソースから情報を収集しています。これには画像、動画、音声、センサーデータ、そしてテキストデータが含まれます。データソースは、ウェブ、ダークウェブ、ソーシャルメディア、ブログなど、多岐にわたります。また、世界150以上の言語に対応しており、真にグローバルな監視と分析が可能となっています。
このシステムの信頼性と有効性は、その採用実績からも明らかです。Fortune 50企業の3分の2、Fortune 100企業の50%が我々のプラットフォームを利用しています。また、国連とその関連機関を含む多くのNGO、さらに世界中の公共セクターや政府機関にもご利用いただいています。
メディア業界においては、1500以上のニュースルームが我々のシステムを活用しています。私がDataMinerからアラートを受け取ってから30分後には、そのイベントがニューヨークタイムズやBBC、その他の主要メディアで速報として報じられるというのは珍しいことではありません。
このような広範な採用は、我々のシステムが提供する主要な価値、つまり重要なイベントをいち早く検知し通知する能力への信頼を示しています。ビジネスや緊急対応、そしてニュース価値のあるイベントについて、最初の通知者となることを目指しています。
2.2 対応イベントの種類と特徴
私たちが検知・対応する緊急事態は、一般的に想像されるよりもはるかに多岐にわたります。赤十字の緊急事態リストを見ると、多くの人々が普段考えもしないような事態が含まれていることに驚かれるでしょう。
例えば、多くの人々は新型インフルエンザやCOVID-19のようなパンデミックを緊急事態として考えていませんでしたが、実際にはこれらも重大な緊急事態となりました。その他にも、化学物質による事故、干ばつ、地震、食品安全問題、中毒事案、テロ行為、竜巻、雷雨、山火事など、実に様々な種類の緊急事態が存在します。さらに、即座の緊急対応を必要とする犯罪なども我々の監視対象に含まれています。
興味深いのは、即座の緊急対応を必要としないものの、対応が遅れれば緊急事態に発展する可能性のある事案も存在することです。例えば、数年前に我々のプラットフォームは、ニューヨークの地下鉄で誰かが線路に100ドル紙幣を投げ入れているという警告を発しました。これは、おそらく誰かが危険を冒して現金を拾いに行くことを誘発する意図があったと考えられます。
ニューヨークでは週単位で地下鉄での人身事故が発生しており、被害者本人の被害だけでなく、交通システム全体に深刻な影響を及ぼします。このような事例は、直接的な緊急事態ではありませんが、早期に対処しなければ重大な事態に発展する可能性のある予防的な監視の重要性を示しています。
このように、我々のシステムは従来型の緊急事態から新しいタイプの脅威まで、幅広い事象を監視し、適切な対応を可能にしています。
2.3 複雑な緊急事態の特性
大規模な緊急事態は、その性質上、極めて複雑な特性を持っています。私の経験から、主な特性について説明させていただきます。
まず、緊急事態の中で予期せぬサブイベントが次々と発生し、状況が極めて迅速に変化していきます。典型的な例として、地震発生時の情報の流れを考えてみましょう。最初の通知は通常、センサーからの単純な情報で、「この場所でこの規模の地震が発生した」という程度です。しかし、その後わずか数分のうちに、死者数の報告が始まります。最初は10人、次に20人、30人と増えていき、24時間後には数千人、さらには1万人規模という具合に、状況は劇的に変化していきます。
地理的な広がりも、緊急事態の種類によって大きく異なります。例えば、政治家の暗殺は1秒間の出来事で、特定の場所で発生しますが、その影響は戦争や革命にまで発展する可能性があります。一方、ハリケーンは広大な地域に影響を及ぼし、数日間にわたって継続します。
また、緊急事態への対応には重要なロジスティクスの課題が伴います。私は数年前、ニューヨーク市での緊急避難に関するハッカソンの審査員を務めました。その際、最も驚いた発見の一つは、市内には十分なバスがあるにもかかわらず、大規模避難時の最大の課題は、それらのバスを運転する資格を持つドライバーを確保することだということでした。なぜなら、ドライバーたちにも家族がおり、彼ら自身も避難する必要があるためです。
さらに、計画通りに物事が進まないことも大きな課題です。例えば、ニューヨーク市の避難計画を実行しようとしている最中に、橋で事故が発生して通行止めになれば、すべての計画を即座に変更する必要が生じます。
このように、緊急事態は予測不可能なサブイベント、急速な状況変化、複雑な地理的影響、そして困難なロジスティクスの課題を含む、極めて複雑な性質を持っているのです。これらの特性を理解し、適切に対応できるシステムを構築することが、効果的な緊急対応には不可欠です。
2.4 再生成AIによるリアルタイムサマリー機能
我々は最近、リジェネレーティブAIと呼ぶ新機能を導入しました。この機能の基本的な考え方は、イベントの展開に伴って発生する多数のサブイベントを自動的に検知し、それらを統合してリアルタイムで更新される要約を生成することです。
この機能の実力を示す良い例として、最近のボルティモア橋崩落事故での活用事例があります。この事故では、最初のアラートは単なる道路閉鎖に関する情報でした。その後、コンテナ船が橋に衝突したという情報が入ってきました。我々のシステムは、これらのサブイベントを自動的に検知し、イベント全体の状況を示すサマリーを生成しました。新しい情報が入るたびに、このサマリーはリアルタイムで更新されていきました。
この機能は、企業のリスク管理チーム、報道機関のジャーナリスト、そして緊急対応チームにとって非常に価値のあるものとなっています。なぜなら、最新の情報を即座に把握し、最も重要な情報にすぐにアクセスできるためです。
このようなリアルタイムサマリーの生成には、もちろんLLMを活用していますが、これには様々な技術的課題が伴います。時系列は数百のサブイベントを含む場合もあれば、わずか数個のサブイベントで構成される場合もありますが、基本的なアイデアは同じです。つまり、検知されたイベントの本質を捉え、それを簡潔に要約することです。
このサマリー機能により、ユーザーは複雑な緊急事態の全体像を即座に把握し、適切な対応を迅速に取ることが可能になりました。これは特に、複数のサブイベントが同時進行する大規模な緊急事態において、その真価を発揮しています。
3. AIモデルの実装と選択
3.1 予測AIと生成AI
私たちのプラットフォームでは、AIを大きく2つのカテゴリーに分けて考えています：予測AIと生成AIです。技術コミュニティ以外で講演する際、多くの人々がAIをChatGPTと同一視し、すべてが生成AIだと考えている傾向があることに驚かされます。そのたびに、予測AIという数十年にわたって研究開発されてきた重要な分野が存在することを説明する必要があります。
私たちのシステムでは、これら2つのAIタイプを効果的に組み合わせて活用しています。予測AIは、様々なソースから入ってくる信号からイベントを検知し、そのイベントのラベル付けを行います。具体的には、5W1H（いつ、どこで、誰が、何を、なぜ、どのように）の特定、トピックの分類、場所の特定、関連エンティティの検出などを担当します。
一方、生成AIモデルは、検知されたイベントの説明文を生成する役割を担っています。ソーシャルメディアなどに投稿される情報は、しばしばスラングを含み、不完全で一貫性がなく、正確な位置情報も含まれていないことが多いです。そこで、私たちのモデルは予測AIから得られたメタデータを活用し、イベントの内容を簡潔な一文で説明する文章を生成します。
私たちは2019年からLLMを本番環境で活用してきました。つまり、幻覚（ハルシネーション）の問題には2019年から取り組んできたことになります。当時使用していたLLMは、今日のモデルと比べるとはるかに小規模でした。また、最初は人間によるレビューを多く取り入れ、モデルが生成した複数のイベント説明の中から、人間のラベラーが最適なものを選択するというプロセスを採用していました。このフィードバックデータを使って、モデルの訓練と改善を重ねてきました。
このように、予測AIと生成AIの組み合わせは、私たちのシステムの中核を成しています。予測AIによる正確なイベント検知と、生成AIによる分かりやすい説明文の生成という、それぞれの長所を活かすことで、効果的なイベント検知・通知システムを実現しています。
3.2 LLMの進化と選択肢
LLMは、ここ数年で驚異的な進化を遂げています。2017年以降、モデルのサイズは急速に拡大し、この成長は現在も続いています。しかし、このグラフはすでに古くなっているほど、技術の進歩は急速です。私たちは2019年からLLMを本番環境で活用してきましたが、当時使用していたモデルは今日のモデルと比較すると非常に小規模なものでした。
現在のLLMの状況を見ると、まさに驚くべき状況です。毎週のように新しいLLMが登場し、より大規模なモデル、より小規模なモデル、より優れたモデルが次々と発表されています。そして、これらのモデルは一部の企業や国からだけでなく、中東、中国、アメリカ、ヨーロッパなど、世界中から登場しています。モデルの多様性も顕著で、それぞれが異なる特性や能力を持っています。
このような状況で、大規模な本番環境で高い精度が要求される我々のようなプラットフォームでは、どのLLMを選択すべきかという重要な判断に直面します。消防車を間違った場所に派遣するわけにはいきませんから、可能な限り高い精度が必要です。
注目すべき重要な点は、GPT-4やGPT-3.5以前にも多くのモデルが存在し、それらは本質的に同じ技術に基づいているということです。タスクによって異なるモデルが異なるパフォーマンスを示すため、モデルの選択には慎重な検討が必要です。感情分析を行うのか、質問応答なのか、固有表現抽出なのか、関係抽出なのか、具体的なタスクに応じて最適なモデルを選択する必要があります。必ずしも最新の大規模モデルが最適な選択とは限らないのです。
この考え方は、情報抽出、テキスト分類、会話、要約、翻訳、コンテンツ生成など、あらゆるタスクカテゴリーに当てはまります。特に興味深いのは翻訳分野です。一般的に翻訳は「解決済みの問題」と考えられがちですが、我々のような実システムでは、入力データが完璧ではないため、非常に困難な課題となっています。Google翻訳などのサービスで完璧な文章を翻訳する場合は問題ありませんが、ノイズの多いデータを様々なソースから多言語で受け取る場合、言語の曖昧さが大きな課題となります。
3.3 コスト分析とスケール時の考慮点
大規模なAI実装を検討する際、コストは極めて重要な考慮点となります。Chip Huyen氏が2023年に公開したブログ記事のデータは、我々の実際の経験とも一致する興味深い分析を提示しています。
例えば、2023年4月時点でのある分析では、公開APIを使用した場合、1日あたり約4000万ドルのコストがかかる計算になりました。一方、DoorDashのような企業がカスタマイズモデルを使用した場合、同じワークロードで1日あたり約2000ドル程度に抑えられるという試算が示されています。この劇的なコスト差は、スケールの重要性を如実に示しています。
しかし、朗報として、Peter Gao氏が今月発表した分析によると、モデルプロバイダーやクラウドプロバイダー間の激しい競争により、価格は急速に下落しています。市場シェア獲得のための競争が「底辺への競争」を引き起こし、可能な限り価格を引き下げる動きが加速しています。一部のモデルでは、価格が99%も下落するという驚異的な例も見られます。
ただし、注意すべき点として、同じモデルでもプロバイダーによって価格が大きく異なる場合があります。これは一部のプロバイダーがモデルを量子化している可能性があるためです。つまり、コストは削減できても、パフォーマンスが低下している可能性があることに注意が必要です。実際のところ、何を得て何を失っているのか、完全には把握できない状況もあります。
このように、大規模な実装におけるコスト考慮は非常に複雑で、単純な価格比較だけでなく、パフォーマンスとの兼ね合いを慎重に検討する必要があります。特に、急速に変化する価格状況においては、定期的な再評価と柔軟な対応が求められます。
3.4 実験結果：小規模カスタマイズモデルの優位性
私たちの経験と最近の研究結果は、小規模なカスタマイズモデルの優位性を明確に示しています。昨年、私たちは「小規模なカスタマイズモデルに注力する」という戦略を公表しましたが、この判断は現在の市場動向からも正しかったことが証明されています。
興味深いことに、特定のタスクに対してカスタマイズされた小規模モデルは、汎用の大規模モデルをそのまま使用するよりも優れたパフォーマンスを示すことが分かってきました。これは直感的に理解できることです。なぜなら、大規模モデルはSAT試験や司法試験の合格、その他様々なタスクをこなすように訓練されていますが、それらの多くは特定のタスク遂行には不要なものだからです。
評価指標に関して重要な点は、これらの指標は参考程度に捉える必要があるということです。なぜなら、これらの指標は特定のドメインでモデルがどれだけ良いパフォーマンスを発揮するかを正確に示すものではないからです。例えば、MOE（Mixture of Experts）7Bが GPT-3.5 Turboより優れているかどうかを一概に判断することはできませんが、ある程度の傾向を把握することはできます。
私たちの実験では、モデルを特定のタスクに特化させることで、以下の利点が確認されています：
- より正確なイベント検知と分類
- 低いコストでの運用
- より速い推論速度
- 特定ドメインでの高い精度
これらの結果は、大規模言語モデルを使用する際の「より小さく、より賢く」というアプローチの有効性を裏付けています。ただし、これはモデルの評価とベンチマークを継続的に行い、特定のユースケースに対して最適なモデルを選択し続ける必要があることを意味します。
4. 大規模プロダクション環境での課題
4.1 推論コストの重要性
大規模なプロダクション環境でAIを運用する際、最も重要な考慮点の一つは推論コストです。多くの人々は訓練コストを気にしますが、実際には推論コストの方がはるかに重要です。1つのモデルの訓練に1000万ドルかかるというニュースを目にして驚かれる方も多いでしょうが、実際の運用においては、その訓練コストは推論コストと比較すると取るに足らない金額なのです。
なぜなら、スケールが大きくなればなるほど、モデルの使用頻度が飛躍的に増加するためです。このため、大規模言語モデルを構築している企業は、数千万ドルの訓練コストをかけることを厭いません。彼らはそのモデルを何度も販売することで、最終的に利益を得ることができるからです。ただし、現在は多くの企業が同様のことを行っているため、モデル自体が一種のコモディティ化しつつあります。
企業の立場からすると、ある程度の精度が確保できれば、推論時の最適化に注力すべきです。これは単なるコスト削減の問題ではありません。我々のような緊急対応システムでは、1ミリ秒でも早く情報を届けることが人命を救う可能性があります。アクティブシューターの存在や地震、洪水の警報を送る際、その速度は文字通り生死を分けることになります。
そのため、推論の最適化はパイプライン全体で行う必要があります。学術界ではしばしば一つの要素の最適化に焦点を当てがちですが、実際のシステムでは、目標は明確です。可能な限り低コストで、可能な限り高い精度を実現し、可能な限り速く処理を行うことです。そのためには、あらゆる最適化の機会を活用する必要があります。
4.2 データ分布の変化への対応
私たちのような緊急対応システムでは、入力データと出力データの分布が時間とともに変化することが、システムに大きな負荷をかけています。例えば、地下鉄の線路に100ドル紙幣を投げ入れるような、これまで見たことのない新しいタイプのイベントが発生することがあります。
このような未知のイベントに対応するため、私たちは継続的な学習とラベリングのプロセスを確立しています。サンプリング手法は、新しい種類のイベントを効率的に検出し、モデルの更新に活用するために重要です。また、モデルのパフォーマンスを継続的にモニタリングし、必要に応じて新しいデータでモデルを更新する必要があります。
特に重要なのは、高速で効率的なラベリングプロセスです。緊急事態の性質上、新しいタイプのイベントが発生した場合、できるだけ早くそれを認識し、適切に分類できるようにする必要があります。このため、私たちは人間のエキスパートとAIシステムを組み合わせたハイブリッドなアプローチを採用しています。
また、データの分布変化に対応するためには、モデルの性能を継続的に監視し、必要に応じて更新や切り替えを行うための仕組みも重要です。これは単なるモデルの精度だけでなく、実際の運用環境での有効性を考慮に入れた評価が必要となります。
このような継続的な学習とアダプテーションのプロセスは、システムの信頼性と効果を維持するために不可欠です。新しいタイプの脅威や緊急事態が次々と発生する現代において、静的なシステムではなく、常に進化し続けるシステムを維持することが重要なのです。
4.3 最適化の必要性
システムの最適化は、パイプライン全体で行う必要があります。私たちのデータマイニング社では、この取り組みを数年前からAWSと協力して進めており、特にInferentiaチップを使用した推論の最適化に注力しています。しかし、これはハードウェアの最適化だけにとどまりません。
私たちのAIエンジニアリングチームには、モデルの最適化に特化したメンバーがいます。彼らの唯一の仕事は、大規模な運用のためのモデル最適化です。研究科学者がモデルを構築してテストすると、AIエンジニアリングチームがそれらのモデルを最適化します。これには、モデル圧縮やプルーニングなどの技術が含まれます。
パイプラインの処理順序の最適化も重要です。私たちは、より安価なモデルを最初に実行し、より高価なモデルは最後にのみ実行するようにしています。これは、ChatGPTのような応用例で見られる手法に似ています。例えば、「爆弾の作り方を教えて」というような有害なリクエストがあった場合、大規模言語モデルを呼び出す前に、ルールベースのシステムがそれをブロックするでしょう。ナイトクラブの用心棒のように、ドレスコードに合わない人を入場させないのと同じです。
このように、複雑なモデルと単純なモデルを大規模システムで組み合わせることで、効率性と安全性の両方を確保しています。場合によっては安全性のため、また別の場合では最適化のためにこのアプローチを採用しています。私たちのような緊急対応システムでは、1ミリ秒の違いが人命を左右する可能性があるため、このような総合的な最適化アプローチは極めて重要なのです。
4.4 LLM Opsの重要性
おそらく、これは私の講演の中で最も重要なスライドです。新しいLLMの波を効果的に活用する上で、私たちが成功を収めている基盤となっているのが、LLM Opsと呼ぶインフラストラクチャへの強い注力です。これは単なるLLMだけでなく、より広範なインフラストラクチャの管理を含んでいます。
我々のAIエンジニアリングチームは、モデルの最適化に加えて、プロビジョニングの責任も担っています。新しいオープンソースモデルがリリースされた際、可能な限り早く本番環境で利用できるようにすることが重要です。我々は、Databricksや Snowflakeなどの外部プラットフォームを通じたアクセスだけでなく、内部での展開も行います。これは、より多くの制御が可能になるためです。
また、これらのモデルの迅速な評価プロセスと、私が「スワップサイクル」と呼ぶものが必要です。つまり、緊急対応、企業リスク、世界に影響を与え得るニュースを扱っているため、慎重かつ責任を持ってモデルをロールアウトする必要がありますが、同時に素早く切り替えられる能力も必要です。さらに、問題が発生した場合は即座に元のモデルに戻せる必要もあります。
このためには、明確な評価指標とベンチマークが必要です。分類タスクについては、ラベル付きデータセットを使用して繰り返し評価を行うことが比較的簡単です。ただし、主観性の問題は依然として存在します。要約や説明文の生成については、さらに複雑です。しばしばラベリングをやり直す必要があり、比較もより困難です。
特に重要なのは、人間によるレビューの要素です。これは多くの人が語りたがらない部分ですが、非常に重要です。例えば、再生成要約や説明文を生成する2つのモデルを比較する場合、どのように評価すればよいでしょうか？要約の研究はNLPコミュニティで数十年にわたって行われてきましたが、まだ完全な解決策は見つかっていません。モデルは非常に高性能になり、異なるスタイルや順序で、いずれも合理的な要約を生成できるようになったため、評価はさらに難しくなっています。
最後に、おそらく最も重要なのは、特定のタスクに対する最適化です。標準的な外部ベンチマークでのパフォーマンスは参考になりますが、自社の内部データで特定のタスクに対して実行した評価に勝るものはありません。これが究極的に、どのモデルを使用するか、カスタマイズや微調整がどの程度うまくいっているかを判断する基準となります。
このようなLLM Opsプロセスを迅速に実行できれば、それだけ早くイノベーションを実現でき、プラットフォームの品質を向上させることができます。これにより、イベントの検知能力が向上し、より効果的な緊急対応が可能になるのです。
5. 知識グラフの活用
5.1 イベントの因果関係ネットワーク
私たちのプラットフォームにおいて、イベントの因果関係を理解することは非常に重要です。世界には物理的な性質があり、イベントは他のイベントを引き起こします。最も基本的な例を挙げると、火災が発生すれば、必ず煙が発生します。私の昨日のワークショップでの講演を聞いた方はご存知かもしれませんが、これは明白な例です。
しかし、大規模なスケールで考えると、この因果関係はより複雑になります。例えば、私は数年前のアイスランドでの火山噴火を覚えています。その噴火による煙は、ヨーロッパ全域の航空便に深刻な混乱をもたらしました。同様に、数年前のカナダでの山火事は、アメリカの広範な地域で航空便の混乱と大気質の悪化を引き起こしました。
このように、多くのイベントは他のイベントやサブイベントを生み出し、カスケーディングネットワークを形成します。2019年に私たちはこの仮説を検証するための探索的研究を実施し、ワークショップで発表しました。我々の会社は12年以上にわたって世界中のイベントデータを収集してきており、そのデータを分析することで、これらのパターンを発見し、活用することが可能になっています。
この研究により、イベント間の因果関係パターンを特定し、それらを予測や早期警告に活用できることが明らかになりました。例えば、あるタイプのイベントが発生した場合、それに続いて発生する可能性が高いイベントを予測し、関係者に事前に警告を発することができます。これは特に大規模な緊急事態における対応計画の立案と実行に非常に有用です。
このように、イベントの因果関係ネットワークの理解と活用は、私たちのプラットフォームにおける重要な研究方向の一つとなっています。これは、物理的な因果関係からより複雑な社会的影響まで、様々なレベルでの関係性を包含する豊かな研究分野だと考えています。
5.2 知識グラフの構造と応用
私たちのプラットフォームにおいて、知識グラフは以下のような形で活用されています。あるイベントが発生し、そのイベントに特定のエンティティが関連している場合、それを知識グラフと照合することで、影響を受ける可能性のある他のエンティティを特定できます。
例えば、スライドに示すように、あるソフトウェア製品（緑色のE1）に関連するイベントが発生した場合、知識グラフを通じて、そのソフトウェアが他のソフトウェア製品とどのような関係を持っているかを把握できます。これにより、グレー、ブラウン、パープルで示されたエンティティも影響を受ける可能性があることが分かります。逆に、グレーのエンティティに影響するイベントが発生した場合、緑色のエンティティにも「サプライチェーンのどこかで何かが起きている」という警告を発することができます。
このような知識グラフの活用は、サプライチェーンやサイバーセキュリティの分野で特に重要です。私たちは、予想もしなかったような接続性が世界中に存在することをCOVID-19のパンデミックで痛感しました。誰が、インフルエンザのようなウイルスがトイレットペーパーの不足を引き起こすと予想したでしょうか？しかし、実際にそれは起こりました。
サプライチェーンは現代では非常に重要なトピックとなっています。なぜなら、世界が私たちが想像していた以上に密接に繋がっていることが明らかになったからです。サイバーセキュリティの分野でも同様です。最近のCrowdStrikeの事例を見ても、たった一つの出来事が、いかに大きなネットワーク効果を生み出すかが分かります。
このように、知識グラフを通じてエンティティ間の関係性を理解することで、イベントの潜在的な影響範囲を予測し、適切な警告を発することが可能になります。これは、直接的な影響だけでなく、二次的、三次的な影響まで予測するための強力なツールとなっています。
5.3 実例：COVID-19とCrowdStrikeの早期検知
私たちのシステムの効果を示す具体的な事例として、COVID-19とCrowdstrikeの二つの重要な検知事例を紹介したいと思います。
まず、2019年12月、私たちのプラットフォームは中国の武漢で「インフルエンザのような病気が発生している」という初期アラートを発信しました。当時、これが後にCOVID-19として世界的なパンデミックを引き起こすウイルスだとは誰も知りませんでした。しかし、このような早期の兆候を検知し、警告を発することができたのは、私たちのシステムの強みを示しています。
同様に、Crowdstrike事案についても、他のどのプラットフォームよりも早く最初のアラートを発信することができました。この事例は特に興味深いものでした。なぜなら、最初の兆候が現れた時点では、その影響の大きさを完全に予測することは困難でしたが、私たちのシステムは早期に重要な警告を発することができたからです。
これらの事例は、私たちの早期警告システムとしての効果を示しています。初期の段階では影響の全容は明らかではありませんが、そのような早期の兆候を検知し、関係者に警告を発することで、より効果的な対応準備が可能になります。
このような早期検知能力は、知識グラフとイベント検知システムの組み合わせによって実現されています。特に、複雑な関係性を持つイベントの連鎖を理解し、潜在的な影響を予測する能力が、これらの成功事例の鍵となっています。
6. 研究課題と今後の方向性
6.1 知識グラフの自動構築と更新
これらの領域における主要な研究課題の一つは、複数のソースから知識グラフを自動的かつ半自動的に構築、拡張、更新する方法の開発です。私たちのようなプラットフォームで必要とされる世界の完全な知識グラフを構築することは、少なくとも私の生涯の中では実現不可能でしょう。そのため、より効率的な構築・更新手法の開発が急務となっています。
特に重要なのは、人間の専門知識を効果的に活用するためのツール開発です。今朝のTanyaの講演で印象的だったのは、私たちのケースにも当てはまる多くの指摘があったことです。私たちも同様にドメインエキスパートを抱えており、その専門知識の活用が重要な課題となっています。LLMの性能が向上しているとはいえ、世界の複雑さについて、ドメインエキスパートの方が遥かに深い知識を持っている領域が数多く存在します。
最近では、LLMベースのアプローチを用いて、非構造化データからグラフを発見し、エンティティや関係性を見出す研究が増えています。これは非常に興味深い方向性です。なぜなら、LLMは学習データから多くの知識を獲得していますが、現在のLLMは構造化データを十分に活用できておらず、またそのデータを構造化することも本来の目的とはしていないからです。
LLMの主な目的は次の文や単語を予測することですが、これを既存データから構造を抽出するために活用したり、イベントの説明や要約を生成するために使用したりすることができます。このように、知識グラフの構築と更新において、人間の専門知識とLLMの能力を効果的に組み合わせることが、今後の重要な研究方向の一つとなっています。
6.2 予測と生成に関する課題
予測と生成に関する分野では、まだ多くの重要な課題が残されています。特に、私たちのプラットフォームのような実用システムにおいては、以下のような課題が顕著です。
まず、マルチモーダルデータの統合における課題があります。私たちは音声、画像、動画、センサーデータなど、様々な形式のデータを扱っています。これらのデータが完璧に書かれていない、あるいは理解が困難な場合、基本的な意味情報の抽出でさえ非常に難しい作業となります。
次に、曖昧性の解消も依然として大きな課題です。実際の運用では、完璧に書かれていないテキストや、理解が困難な音声・画像データを扱うことが多く、コンテキストの理解が極めて重要になります。例えば、翻訳の分野では、これまでの経験から、言語の曖昧さが予想以上に大きな問題となることがわかっています。
さらに、情報の価値評価という重要な課題があります。COVID-19のような事例のイベントサマリーを作成する際、何千、何百万ものイベントの中から、どの情報を重視するべきかの判断が必要です。私にとって最も興味深い点は、情報の価値が時間とともに劇的に変化することです。ある情報を伝えた瞬間に、その価値は大きく低下します。
このため、情報の価値を最大限に保つためには、個々のユーザーのコンテキストを理解し、パーソナライズされた形で情報を提供する必要があります。これは広告業界で求められているものと似ていますが、私たちの場合は実世界のインパクトを目的としている点が異なります。
これらの課題に対して、因果関係の理解やクラスタリング、情報の粒度の適切な設定など、様々なアプローチを試みていますが、完全な解決にはまだ時間がかかるでしょう。情報の価値を最大化しながら、適切なタイミングで適切な情報を提供することは、継続的な研究課題となっています。
6.3 技術トレンドの予測
私が予測する技術トレンドについて、主要な方向性をお話ししたいと思います。
まず、大規模LLMへの投資は継続され、汎用モデルや汎用チャットボットの開発が続くでしょう。AGIを目指し、企業が数十億ドルを投資する動きは続くと思われます。ただし、これらのビジネスモデルはまだ明確ではありません。OpenAIのように、モデル開発だけでなく、新しい検索アプリケーションやChatGPTのようなチャットボットなど、アプリケーション領域への展開が進むと考えられます。
同時に、オープンソースモデルの開発も継続するでしょう。一部の大手企業にとって、これはPyTorchなどのフレームワークで見られたような競争戦略となっています。オープンソースでモデルを公開することで市場をリードし、コミュニティからの貢献を得られるためです。これは研究コミュニティとビジネスコミュニティの双方にとって素晴らしい展開です。
そして必然的に、このオープンソースの流れは何十万ものモデルのカスタマイズを生み出すでしょう。その結果、どのモデルが何をするのか把握が難しいジャングルのような状況が生まれるかもしれません。しかし、これはイノベーションにとっては良いことだと考えています。
特に注目すべきは産業特化型モデルの台頭です。これまでのGPT-4やGeminiなどの大規模モデルは非常に汎用的でしたが、今後は業界特化型のモデルが増えていくでしょう。すでにBloombergが独自モデルを構築し、ヘルスケア分野でもいくつかのモデルが登場しています。大手クラウドプロバイダーも、この産業特化型モデルの開発に参入すると予想され、そこでの競争も活発化するでしょう。これは非常にエキサイティングな展開です。教育、金融、ヘルスケアなど、各産業に特化した本当に優れたモデルが登場することが期待できます。
さらに、小規模言語モデルやエッジでの実行を目指したモデルも増加するでしょう。パーソナルモデルやパーソナルチャットボットの方向性も見えてきています。私のTwitterハンドルは何年も前から「tiny big data」でしたが、これはAIの次のフロンティアがパーソナルデータにあると信じていたからです。この進展は遅かったものの、徐々に実現に向かっています。Appleなどの企業の戦略を見ても、パーソナライズされたソリューションへの投資が進んでいることが分かります。
このエコシステムの進化は、アプリケーションから特定のタスクに特化したアシスタントへ、そしてさらにエージェントへと発展していくでしょう。ただし、汎用的な文脈では機能しなくても、特定のドメインでは非常に効果を発揮する可能性があります。例えば、ホテル予約に特化したエージェントは、過去15年分の予約履歴を分析し、会議の場所や予算に基づいて最適なホテルを提案できるかもしれません。このように、非常に特化した用途で効果的なソリューションが登場することが期待されます。
7. AI実装の実践的考察
7.1 必要なリソースと専門知識
これらすべてを実際に構築し、競争力を維持しながら成功を収めるために必要な要素について、私の経験から3つの重要な柱があります。
第一に、データの存在は不可欠です。これは訓練のためだけでなく、たとえ訓練に必要でない場合でも評価のために必要です。実際のシステムを構築する場合、何らかの形でデータは必要になります。また、そのデータはワークフローやアプリケーションに統合できる形式でなければなりません。
第二に、技術的な専門知識は極めて重要です。エンジニアリングスキルは、単にモデルを構築するためだけでなく、それをワークフローやアプリケーションに統合するために不可欠です。私たちは常に明確な問題定義とその成果を測定できる指標を持つ必要があります。
第三に、計算インフラストラクチャとそれを支えるプロセスが必要です。これらは小規模な実験から始めることができますが、実際の本番環境での運用を考えると、適切なインフラストラクチャの整備は避けて通れません。
重要なのは、これら3つの要素が相互に関連し、補完し合っているということです。どれか一つが欠けても、効果的なAIシステムの実装は困難になります。また、これらすべての要素は、責任あるAIの適用という文脈の中で考慮される必要があります。つまり、システムが倫理的で、社会的に有益な形で運用されることを保証する必要があります。
このように、AI実装の成功には、単なる技術的な要素だけでなく、組織的な準備とプロセスの確立が不可欠なのです。
7.2 実世界での課題
実世界でAIシステムを運用する際、私たちは数多くの実践的な課題に直面しています。特に重要なのは以下の点です。
まず、データに関する課題があります。サンプリングの問題、データのバイアス、そして教師なしデータの扱いなど、様々な課題が存在します。完全なデータセットを得ることは不可能であり、常に何らかのバイアスと不完全性が存在することを前提に、システムを設計し運用する必要があります。
次に、パフォーマンスと速度のトレードオフの問題があります。緊急対応システムでは、ミリ秒単位の速度が人命を左右する可能性があります。そのため、高い精度を維持しながら、可能な限り高速な処理を実現する必要があります。
また、異なるステークホルダーの存在も重要な課題です。同じイベントであっても、コーポレートリスクアナリスト、緊急対応チーム、ジャーナリストなど、それぞれが求める情報の粒度や優先順位が異なります。私たちのシステムは、これらの異なるニーズに対して適切に対応できなければなりません。
状況認識の問題も重要です。アプリケーションがどこで使用されるのか、それはどのような意味を持つのかを理解する必要があります。例えば、航空会社のカスタマーサービスチャットボットが、全く関係のない質問に対して不適切な応答をしてしまうような事例が最近LinkedInで話題になりましたが、このような状況を避けるためにも、コンテキストの理解は極めて重要です。
最後に、人間の行動パターンへの適応も大きな課題です。「AIへの投資が成果を上げていない」という指摘がありますが、実際には人間の側がAIツールの活用に適応するのに時間がかかっているのです。新しいツールの導入時には、必ず人間の側の学習と適応のプロセスが必要になります。
7.3 構造化された知識とLLMの組み合わせの重要性
私は、将来的には構造化された知識とLLMの組み合わせが非常に重要になると考えています。この組み合わせにより、より多くの推論が可能になり、システムの能力が大きく向上するでしょう。
特に注目すべきは、知識の自己更新メカニズムの必要性です。現状では、知識グラフやナレッジベースを常に人間が介在して更新する必要があります。これは効率的ではありません。システムが自律的に知識を更新していく仕組みの構築が必要不可欠です。
また、検索エンジンの役割も大きく変化していくと考えています。世界が変化している中で、一つの興味深い考察があります。大規模なモデルを持っていれば、多くの「エバーグリーン」（不変の）情報は、検索せずともモデル内に存在することになります。例えば、自由の女神がフランスからの贈り物であることは変わりません。このような不変の情報に関して、わざわざウェブをインデックス化する必要はないかもしれません。
つまり、将来的には大規模なLLMに接続するだけで、不変の情報に関する検索エンジンを構築できる可能性があります。その場合、検索エンジンは常に変化する情報のインデックス化に特化すればよいことになります。これは検索エンジンの参入障壁を下げ、より小規模な企業でも特定の分野で競争力を持つことができるようになることを意味します。
しかし、実際には検索には様々なユースケースが存在し、多くの種類の検索が必要とされます。重要なのは、誰かが私たちのために作業をしてくれる、つまりエージェントやシステムが関連情報を探してアラートを送ってくれるような世界への移行です。この変化は、私たちの情報アクセスの方法を根本的に変えていく可能性を秘めています。