re:Invent 2024: BloombergがAWS上でLLM開発した経験を共有
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Bloomberg: Lessons learned from building and training LLMs on AWS (FSI320)
この動画では、BloombergがAWS上で独自のLarge Language Modelである「BloombergGPT」を開発した経験について詳しく解説しています。7,000億トークンのデータと130万時間のGPU計算時間を要した開発プロセスで、P4 EC2 UltraClusterやAmazon SageMakerなどのAWSサービスを活用し、わずか9人のチームで開発を成功させました。また、BloombergGPTの開発経験を活かし、BQLクエリの生成や決算説明会の要約など、実際のプロダクトでのGenerative AIの活用事例も紹介。さらに、複数のLLMを統合管理するためにEnvoy AI Gatewayを開発し、オープンソースとして公開した取り組みについても言及しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
BloombergGPTプロジェクトの概要と課題
皆様、こんにちは。本セッションへようこそ。私はAWSのPrincipal Solutions ArchitectのVasu Chariです。本日は大規模言語モデルについてお話しさせていただきます。Large Language Modelを構築している企業は少なく、ChatGPT以前に構築した企業はさらに少ないのが現状です。インフラの高コスト、GPUの入手可能性、モデルのトレーニングに必要な優秀なチーム、そして何より重要な高品質なデータの大規模なコーパスへのアクセスなど、課題は山積みです。グローバルな金融サービス業界における主要なデータプロバイダーの一つであるBloombergは、必要なデータをすべて持ち、データサイエンティストとエンジニアの優れたチームを確立していました。研究プロジェクトとして、BloombergGPTという独自の大規模言語モデルを訓練しました。本日は、彼らが直面した課題、それをどのように克服したのか、そしてAWS上でLLMを訓練した経験が、同社の製品における生成AIの活用アプローチにどのように活かされているかについて学んでいただきます。
本日は、BloombergのCTOオフィスのInfrastructure部門長であるPhil Vachonと、BloombergGPT論文の共著者でもあるBloombergのAI Engineering部門のチームリーダー、Vadim Dabravolskiをお迎えしています。お二人を歓迎したいと思います。 Bloombergでは独自の大規模言語モデルを訓練することを決定し、本日はAWS上でそのモデルを構築・訓練する過程で学んだ教訓をお話ししたいと思います。大規模なGPUノードネットワーク全体で膨大な量のデータを管理することを含め、Bloombergがこれらの課題にどのように対処したかについてお話しします。また、インフラストラクチャの自動化とテンプレート化が私たちにどのように役立ったか、そしてデータストレージとデータ転送の管理についても見ていきます。結局のところ、私たちはそのデータを保護したかったのです - データは私たちの生命線です - そしてこれらすべてを安全に保ちながら、トレーニングプロセスのエラーを減らすことができました。これらすべてが、モデルトレーニングプロジェクトをより迅速に立ち上げることを可能にし、結果として迅速なイノベーションと製品開発を実現することができました。
LLMの進化とBloombergの取り組み
Bloombergについてはほとんどの方がご存じだと思います。しかし、Bloombergが2009年からさまざまな形のAIを活用してお客様にサービスを提供し、市場をリードするインサイトを提供してきたことは、あまりご存じないかもしれません。私たちは常にAIとNLPの分野で非常に強力な研究プレゼンスを維持してきました。実際、私たちのチームは過去3年間で100以上の研究論文を発表しており、常に新しい方法を探求して、お客様に独自のインサイトを提供し、金融という干し草の山の中から探している針を見つけるお手伝いをしています。
皆さんに2020年の記憶を振り返っていただきたいと思います - もちろん2020年の良くない部分は除いてですが - ChatGPTや生成AIについて誰もが語る以前の時代を思い出してください。2020年に時計を巻き戻すと、OpenAIの大規模な研究者グループが大規模言語モデル開発の新しい領域を切り開いていました。実際、彼らはarXivで「Language Models are Few-Shot Learners」という刺激的な論文を発表し、1,750億パラメータのモデルであるGPT-3の開発を告げました。 この技術が登場し、ChatGPTのすべての機能を理解し始めるにつれて、研究サイドでも、パラメータ数がモデルのパフォーマンスの質に比例することを理解し始めていました。このパフォーマンスは、トレーニングデータの量 - モデルに供給する良質なトークンの数と、実際にこれをスケールアップするために費やす意思のあるGPU時間に比例します。私たちが注目し始めていることの1つは、私たちが知っているスケーリング則が実際にはスケーリングしていない可能性があり、パラメータ数が増加するにつれて、より大規模なLLMが実際にはパフォーマンスの面で収穫逓減を示しているということです。ただし、その詳細は全く別の議論になります。この論文が発表され、誰もがGPUを買い求め始め、もちろんGPUの入手はさらに困難になりました。
Bloombergでは、 LLMの可能性を本当に認識し始めていました。2009年からAIをお客様に価値を提供する手段として検討してきており、常にお客様をより良くサポートするために興味を持ってきた課題がありました。例えば、信頼性の高い要約をどのように提供できるか、あるいは大量の情報の中から特定の文書を概念的に検索する速度をどのように向上させるかなどです。
GPT-3の論文の実験結果を評価したとき、その結果は印象的でしたが、1,750億個のパラメータというのは途方もなく、達成不可能とさえ思えました。これは実際、私たちの観点からすると、そこまで大規模なモデルが本当に必要なのかという疑問を投げかけることになりました。利用可能な学習データの量を検討し始め、GPU時間についても考える必要がありました。GPU時間は貴重だったのです。
私たちのチームは、金融の専門家が物事を話す際に独特の専門用語を使用するという事実を踏まえて、興味深い質問を投げかけ始めました。この特徴を活かして、金融サービス向けに特化したモデルを学習させることは可能なのか？そもそもそれには意味があるのか？また、別のリスクも認識していました。後ほど話すように、確率的モデルは間違いを起こす傾向があり、その理解が必要でした。これは、常に正確さを求める私たちの顧客にとっては受け入れがたいものです。エラーが存在することをユーザーに示唆できる限り、そのエラーが許容される状況がどのようなものなのか、その時点では明確なアイデアを持っていませんでした。
当時、Large Language Modelを統合したシステムを設計する際に、このリスクをどのように軽減できるのかさえ分かっていませんでした。そこで、実験用に独自のGPT-3ライクなモデルを構築・学習させるのが最適だと考えました。これにより、Large Language Modelを活用したアプリケーションの構築方法を研究し、当時存在していた他の手法や新しく登場する手法との性能比較のベースラインを得ることができます。当時の明確な疑問点は、そのようなモデルをどのように学習させるのか？学習に必要な計算能力をどこから得るのか？そして、GPUが最適な選択肢である以上、これらのGPUをどのように入手するのか？ということでした。
BloombergGPTの開発：技術的課題と解決策
私たちは世界的な半導体危機の真っただ中にいました。これは事業の他の部分でも経験していましたが、この特別な需要のため、特にGPUの調達が困難でした。GPUへの極端な需要の高まりと、COVID-19によるサプライチェーンのチップ不足が重なり、GPUの入手は非常に困難で、ある意味では事実上不可能でした。納期は6ヶ月、9ヶ月、12ヶ月ではなく、GPUを実際に入手するまでに24ヶ月もかかる可能性があったのです。
データセンターにGPUは確かにありましたが、それらは既存のアプリケーションの運用に使用されていました。現在顧客に提供しているインサイトを維持するための能力と、実験目的の新しいLarge Language Modelの学習プロセスとを、トレードオフにする余地はあるのでしょうか？考えてみれば、これは実際にはトレードオフにはなりません。それでも諦めることなく、私たちは利用可能な学習データの棚卸しを始めました。一般的な混合ドメインのコンテンツと、金融に特化した厳選されたデータセットの組み合わせがありました。
実際に計算してみたところ、約7,000億のトークンが利用可能であることがわかりました。これらのパラメータを最適化する中で、当時最高性能だったNVIDIA A100 GPUで約130万時間のGPU計算時間が必要で、500億パラメータのモデルを生成することが判明しました。この時点で、この実現には何らかの支援が必要だということが明確になりました。AWSが最適かつ最速の選択肢でした。GPUが利用可能で予約も取れること、そして私たちが必要とする機能をAWSが構築中であることも分かっていました。結局のところ、私たちは小規模なチームでしたので、すぐに使える優れたツールでチームを支援したかったのです。
当時、私たちが選んだのはP4 EC2 UltraClusterでした。高性能なA100 GPUを使用し、UltraClusterはノード内およびノード間の高速で低遅延の接続性を提供し、モデルトレーニングに必要な環境を整えてくれました。この重要性については後ほど詳しく説明しますが、HPCの世界に携わっている方々なら、おそらく想像がつくと思います。
モデルトレーニングにAWSを選んだのは、実に自然な判断でした。モデルトレーニングに関連する面倒な作業は、すべてAmazon SageMakerが対応してくれました。SageMakerは完全マネージド型サービスで、SMPと呼ばれるネイティブな並列トレーニングフラメワークを提供してくれました。SMPはPyTorchのFSDPとは異なるアプローチを取っており、これは実は私たちにとって課題でした。というのも、Bloombergの社内Data Scienceプラットフォームではすべてのトレーニングと推論にPyTorchを使用していたため、そのAPIをサポートするようにトレーニングコードを再構築する必要があったからです。とはいえ、GPUすら確保できない状況を考えれば、これは払う価値のある小さな代償でした。
必要なリソースの割り当ても確保できました。p4d.24xlargeインスタンスを必要な時に確保でき、各ノードには8個のNVIDIA A100 GPUが搭載されており、各GPUには540億のトランジスタが搭載されていました。1台のマシンにこれだけ多くのトランジスタが搭載されているのです。 当時は、ソフトウェアドライバーやハードウェアにも信頼性の問題があったことを強調しておく必要があります。チームにはモデルトレーニングに集中してもらいたかったので、細かな問題のデバッグではなく、これらの面倒な作業を任せられるパートナーがいることは非常に重要でした。さらに、知識や経験を共有し、アイデアを検証できる専門家のスタッフがいることも重要なポイントでした。AWSとの緊密な関係があったからこそ、わずか9人のAI研究者でこのトレーニングを成功させることができたのです。
そうです、たった9人です。GPT-3の論文の著者数を見ると、確か100人近く、75人くらいだったと思います。つまり、かなり多かったわけです。もちろん、モデルのサイズ、トレーニングに選択したアルゴリズム、トレーニングのリスクを軽減するための技術など、これらの決定について考える必要がありました。これらすべてが、このインフラストラクチャーの設計方法に影響を与えたのです。
BloombergのGenerative AI製品開発の指針
7,000億トークン、これはおよそ3.5〜4テラバイトのデータを、どこかに安全かつ確実に保存する必要があります。なぜなら、データは私たちの生命線であり、誰かにそれを持ち去られるわけにはいきません。また、NVIDIA A100 GPUは常にデータを欲しがっているので、トレーニングプロセス全体を通して高速でトークンを供給し続ける必要があります。さらに、エラーが発生した場合にトレーニングプロセスを最初からやり直す必要がないようにしたいため、Checkpointingと呼ばれるプロセスを行います。HPCの世界に馴染みのない方のために説明すると、Checkpointingとは長時間実行されるプロセスの状態を定期的に捕捉することで、この場合は最新のモデルと最適化の状態を保存する作業です。
もちろん、このプロセスにはコストがかかります。すべてのデータを収集してI/O作業を行って保存している間、GPUはアイドル状態となり、貴重なGPU時間が無駄になってしまいます。幸いなことに、P4 UltraClusterは、NVIDIAのネイティブな接続技術であるNVSwitchと、ノード間の接続技術であるOS bypassを備えたEFA（Elastic Fabric Adapter）という、まさに適切な接続性を提供してくれました。これにより、I/OとIOPSだけでなく、レイテンシーについても最適な組み合わせを実現できました。
インフラストラクチャは再現可能で再構築可能である必要があります。クリック操作は簡単で、気持ちよく、即座に結果が得られます。しかし、環境を再作成したり、監査したり、より広範な制御を適用したり、環境の多くの側面に影響を与える小さな変更を行ったりする必要が出てきた時、多くの手作業が必要になることに気づきます。また、リソースのWarm Poolや自動ジョブ回復サービスなども、Infrastructure as Codeと自動化優先のアプローチから恩恵を受けました。
そしてもちろん、ハードウェアの故障で真夜中に起きてトレーニングジョブを再起動したい人はいませんから、これらをできるだけ自動化しておくことが賢明です。ここで、この興味深い作業の多くを担当したVadimを紹介したいと思います。
私たちは大まかに何に取り組むべきかは分かっていましたが、これをどのように実現すればよいのでしょうか？実は、標準的なAWSのビルディングブロックを活用することで、比較的簡単に実現できることが分かりました。S3バケット、VPC、IAMポリシーなど、すでによく理解されている多くのイネーブルメントサービスを使用し、基本的なコンポーネントを再構築しました。しかし、私たちにとって不足していた要素の一つがAmazon SageMakerそのものを理解することでした。この点については、AWSのアカウントチームが共通理解を確立する上で大変役立ちました。強調しておきたい重要な点の一つは、トレーニングクラスターのインターネットへのアクセスについてです。トレーニングクラスターにインターネットアクセスは必要かと自問されるかもしれませんが、おそらく答えは「いいえ」です。そのため、私たちのインフラストラクチャをインターネットから完全にネットワーク分離することに相当な時間を費やしました。この点については後ほど詳しく説明します。
まず始めに、データ管理に関する特殊なAWSサービスについても考慮する必要がありました。一般的な3層Webアプリケーションで使用されるデータストアやデータベースでは、十分な対応ができないためです。私たちの学習データセットは約3.5テラバイトで、チェックポイントは1つあたり600ギガバイトでした。チェックポイント作成中はGPUがアイドル状態になるため、できるだけ早くチェックポイントを生成して保存する必要がありました。また、学習の進捗が大幅に失われるのを防ぐため、2時間ごとにチェックポイントを作成する必要がありました。学習データへの高スループット、低レイテンシーでのアクセスが不可欠でした。
データに対して適切な制御を適用する必要がありました。データはバックアップされ、重要なデータは適切なアクセスポリシーやカスタマー管理の暗号化キーで保護され、標準的なツールで簡単にアクセスできる必要があります。そのため、私たちは学習プロセス中のトレーニングデータの管理にAmazon FSxを使用し、オンラインバックアップストレージソリューションとしてS3を使用して、両者を同期させることにしました。これにより、学習データが低レイテンシーと高スループットで容易にアクセス可能であるだけでなく、必要なセキュリティ制御も適用されることが保証されました。
学習データセットは非常に価値の高いリソースです。実際、私たちが学習に使用したデータセットは、お客様に提供する学習データでもあります。このデータを誤ってインターネット上の見知らぬ人に公開し、持ち去られるようなことは避けたいと考えています。適切なリソースポリシーと、転送中および保存時の暗号化を組み合わせることで、学習データの読み書きアクセスを必要なサービスのみに確実に制限することができます。GPUの割り当てなどの計算時間も貴重なリソースです。誰かが私たちのGPUリソースを盗んだり、さらに悪いことに、権限のない従業員が何かをしたりすることは避けなければなりません。誰がいつどのようにアクセスしているかを監視することは、GPUリソースが無駄に使われていないことを確認するために重要でした。結局のところ、最も機密性の高いワークロードをパブリッククラウドでホストする際には、私たち全員が投資してきたエンタープライズのベストプラクティスを適用する必要があります。
BQLクエリ生成とトランスクリプト要約：実用化されたAI
当時も、そして現在もLLMは急速に進化している分野です。研究者が実験を開始し、失敗し、そこから学び、素早く改善できるようにすることが重要です。セキュリティとコンプライアンスに関するベストプラクティスは、研究者の妨げとなるのではなく、むしろ基盤として機能すべきです。大規模な学習ジョブには多くの運用上の課題があります。数ヶ月にわたって、何百ものノードで何百もの複雑な計算を実行する、分散型で状態を持つ非常にコストのかかるワークロードなのです。
事実上避けられない単一ノードの障害は、可能な限り自動的に、そして適切に処理される必要があります。言うまでもなく、学習ジョブは非常にコストのかかるリソースなので、コストとリソースの効率性が最も重要です。そのため、最初の大規模実験を開始する前に、運用スタックの計画に時間をかけました。そのために、回復可能なエラーと回復不可能なエラーという概念を導入しました。エラーの種類に応じて、異なる修復制御を実装しました。Amazon SageMakerのCloudWatch LogとMetric Managementソリューションとのネイティブ統合を広範に活用し、修復手順を自動化するためにAmazon SNSとAWS Lambdaを利用して、下流のアクションを開始しました。
私たちが最初に経験した失敗の一つは、GPUリソースの活用不足でした。当時使用していたNVIDIA A100チップは、312テラフロップスの計算能力を提供していました。これは単純に数値の掛け算だけを行う場合には驚異的な数字です。しかし実際には、ネットワーク同期、ホストとGPUメモリ間の転送、ストレージI/Oなど、さまざまな要因により、この理論上のスループットを達成することは稀です。これらの強力なトレーニングクラスターをどれだけ効率的に使用できているかを理解するため、私たちはトレーニングクラスター内の全ノードにおける実効テラフロップスを測定できるようコードを計装しました。トレーニングジョブ中のクラスター全体でのGPUあたりの実効テラフロップスを監視する改善策を導入し、この値が50%を下回った場合にはジョブを停止するようにしました。
効率を改善する方法を調査したことで、トレーニングスクリプトのデバッグ初期段階で時間とコストを節約することができ、グローバルなトレーニングのボトルネックとその対処方法を理解することができました。参考になるデータをお見せしましょう：最適化を適用した後のトレーニングジョブの期間中、Forward passとBackward pass全体で、GPUあたり約100テラフロップス強の性能を達成しました。これは容量の100%ではありませんが、かなりの割合を達成できたと言えます。
もう一つ言及すべき失敗モードは、トレーニングの収束についてです。BloombergGPTのトレーニングを開始した当時、大規模モデルの事前学習を行い、その結果を公開していたチームは世界でもごくわずかでした。Big Scienceは注目すべき例の一つでした。彼らに敬意を表したいと思います。当時のトレーニングソフトウェアとハードウェアのスタックは非常に脆弱で、モデルアーキテクチャとトレーニング手法は日々進化していました。チームとして、トレーニングジョブの収束に課題が生じることは予想していましたが、どのような課題が発生するかは不明確でした。
そのため、モデルとOptimizerの内部状態を各ステップで取得し、これらのメトリクスをCloudWatchにストリーミングできるような運用機能をトレーニングスクリプトに組み込みました。数ヶ月にわたって毎分メガバイト単位の運用データをストリーミングしていたのです。この計装のおかげで、初期の収束問題を理解することができました。約12,000ステップあたりで、モデルの損失曲線が平坦化し始めました。これは通常、モデルの学習が停止したことを示します。次のステップとして、この時期にモデル内部で何が起きているのかを理解する必要がありました。そのため、内部の活性化値、モデルの重み、勾配、勾配ノルムをCloudWatchにストリーミングしました。その結果、ネットワークの初期層の一つで発生していた勾配爆発問題がRoot Causeであることを特定し、問題を解決することができました。
画面に表示されているように、12,000ステップ以降に上昇しているパスの一つがあります。これが私が説明した勾配爆発問題の現れです。トレーニングインフラストラクチャとトレーニングクラスターの構築方法について説明しましたので、ここからは私たちが学んだことについて話しましょう。
これだけの労力を費やした結果として、私たちは興味深いものを手に入れました - BloombergGPT研究モデルです。実験を通じて、当時利用可能だった、はるかに多くのパラメータを持つ汎用モデルと比較して、私たちのモデルが金融特化型タスクでより優れた性能を発揮することがわかりました。BloombergGPTのトレーニング方法や、うまくいかなかった実験の詳細について深く知りたい方は、arXivにあるBloombergGPTの論文をご覧ください。私たちのチームは多くの厳しい教訓を学びました。業界のパートナーやAWSの素晴らしいチームの助けを借りて、これらの課題を乗り越えるためのブレインストーミングができたことは幸運でした。皆さんが同じ教訓を学ばなくて済むように、ぜひ参考にしてください。
ここで明確にしておきたいのですが、BloombergGPTは実際には本番環境のアプリケーションでの使用を意図したものではありませんでした。このモデルは、LLMを統合したアプリケーションの構築方法を探るための実験でした。 当時、多くの人がLLMとユーザー体験やワークフローとの関係性についてあまり考えていなかったため、この経験は私たちに多くの洞察をもたらしました。ChatGPTが普及させたエージェントベースのモデルが、必ずしもそのモデルの最も効果的な応用とは限りません。私たちは実際にGenerative AIを活用した製品やアプリケーションの構築方法を具体的に理解したかったので、BloombergGPTの存在は、この探求において非常に有益で強力なツールとなりました。
この取り組み全体を通じて、私たちは製品におけるLLMの活用に関する3つの指針を策定しました。これは私たちにとって、顧客向け製品にGenerative AIを採用していく上でのロードマップを確実に導くものとなっています。まず第一に、モデルからの出力は信頼できるソースから導き出されたものでなければならず、現実を反映している必要があります。Googleのモデルがピザにチーズを接着剤で付けるように人々に指示した例を皆さんもご存知でしょう。私たちは、クライアントが本当に価値のある洞察を得られるようにしたいと考えています。彼らの調査や分析をサポートする上で、私たちの正確性への信頼は非常に重要です。そのような誤った情報が紛れ込むことは許容できません。誤った方向に導くようなことは避けたいのです。
次に考慮すべき点は、LLMが単独のシステムではなく、より大きな製品の一部、アプリケーションの一部、ユーザーが価値を見出して相互作用する何かの一部であるということです。そのため、モデル自体を評価する際には、ユーザーがそれとどのように相互作用し、システムやアプリケーションとどのように関わるかという文脈の中で評価する必要があります。ユーザーがそのようなシステムから何を期待しているのかを理解する必要があります。ユーザーが適切にこれらのアプリケーションを使用できるようにガイドするステップを提供する必要があります。つまり、ほとんどのアプリケーションで自由形式のテキストプロンプトを標準的なユーザーケースとしたくないのです。適切なユーザー体験のヒントを提供し、モデルが誤った判断をしたり幻覚を見たりする可能性がある場合にそれを示唆したり、さらには、モデルが特定のデータポイントをどこから導き出したのかを示す手がかりを提供したりする必要があります。また、ユーザーが結果の品質についてフィードバックを提供できるようにする必要があります。ユーザーが簡単に、摩擦の少ない方法でフィードバックを提供できるようにすることで、その情報を製品の進化に活かし、モデルのパフォーマンスを理解し測定することができます。
最も重要な原則として私が強調したいのは、先ほど述べたように、モデルがデータをどこから取得しているのかについて透明性のある帰属を提供する必要があるということです。ユーザーが元のソースを確認でき、なぜその特定の出力が提供されたのかを理解できるようにする必要があります。また、ユーザーがその出力と対話できるようにすることも重要です。ユーザーが手元で回答の正確性を評価するのに十分な情報を持てるようにしたいのです。結局のところ、文脈が全てです。さらに、ユーザーが簡単にフラグを立てフィードバックを提供できるようにする必要があります。この情報は、途中で修正を加えていく上で不可欠なものなのです。
LLMの実践的応用と今後の展望
Bloombergで実際に Large Language Model と Generative AI をどのように活用しているのか、具体的な事例についてお話ししたいと思います。先ほど申し上げたように、LLMには大きな可能性がありますが、Generative AI を活用して効果的なプロダクトを構築するには、多くの事前検討と慎重なプロダクト開発が必要です。テクノロジー業界全体での初期のプロダクト提供は、様々なアプリケーションやアプローチを試行錯誤的に展開するような状況で、その中でもAgent型のアプローチは多くの人々が即座に活用できるユースケースとして注目しました。しかし、これらの品質と信頼性にはばらつきがありました。Bloombergでは、そのような不確実性のあるプロダクトをお客様に提供することは避けたいと考えていました。当社は常にお客様との信頼関係を築き、信頼できるプロダクトを提供することに注力してきたため、その信頼を損なう可能性のあるアプリケーションの開発には慎重で実用的なアプローチを取っています。
特に株式分野のリサーチアナリストは、市場環境について様々な疑問を持つことでしょう。例えば、エンターテインメント関連のポートフォリオについてのトレード判断のためのレポートを作成する場合、Walt Disneyの過去1ヶ月の終値を素早く知りたいと思うかもしれません。Bloombergのお客様であれば、 Bloomberg Query Language（BQL）を使用することができます。これは、膨大な過去および現在の市場データにアクセスするための標準ツールです。 このBQLを使用して、Disney（ティッカーシンボル：DIS）のデータを取得することができます。 そして、特定のシンボルや株式に関する様々な側面の情報と組み合わせることもできます。取引時には、任意の株式やシンボルに関して考慮したい有用なデータポイントが多数存在します。
例えば、株式の取引量は、市場の状況やセンチメントを示す指標として、あるいは特定のアナウンスメント前後での株式の動きの変化を理解するために使用されることがあります。例えば、Teslaの過去5日間の出来高推移を理解したい場合。これも非常にシンプルな質問で、 この場合、データのロールアップを要求する単純なBQLステートメントとして記述することができます。これはBQLクエリ言語の機能をより前面に出す、straightforwardなクエリです。 しかし、質問したいことはどんどん複雑になり、BQLで使用する機能もより高度になっていきます。特定のシンボルやシンボルグループに対して、非常に深い計算を統合することができます。Sharpe比率の計算や、Starbucksの保有銘柄に対するアナリストの買い推奨数と総推奨数の比率を取得するといったことも、BQLですべて実行できます。ただし、そのためにはBQL言語のエキスパートになる必要があり、これは新人アナリストや、BQLでの実行方法をまだ知らない質問に素早く答えを得たい人にとっては、かなり大変な課題となります。ソフトウェア開発の経験がある私たちにとって、BQLの習得は比較的簡単です。
実際、皆さんの多くは、これらのクエリが何を求めているのかを直感的に理解できるでしょう。しかし、要求する内容が複雑になればなるほど、ドキュメントをより深く理解し、BQLの背後にあるデータモデルを理解する必要が出てきます。つまり、BQLを学び、その後でこれらの質問に答え始めることになります。しかし、これは最も効率的な方法とは言えないでしょう。
BQLクエリを実際に書く代わりに、特定の証券について答えを得たい質問を考えるだけでよいとしたらどうでしょうか。自然な英語の内容からクエリを生成し、その質問に答えるBQLクエリを生成することができれば。非常にシンプルな質問から始めてみましょう。「Fordとそのピア企業の来四半期の収益成長率が知りたい」という質問です。そして、すぐに言えることですが、 このクエリは単純なBQLクエリではなく、言語自体の使い方についてある程度の深い知識が必要になります。
そこで、BQLクエリの生成と理解を支援するために特別に訓練された Fine-tuned モデルである Large Language Model を活用できるようになりました。このモデルは BQL クエリを生成でき、Peer が何であるかを理解し、そのクエリに含めることができるさまざまな用語を基本的にすべて理解しています。ユーザーインターフェースでこのクエリを提供するだけでなく、結果の表形式のビューも提供しています。ここでは、ユーザーが自然言語でプロンプトを入力し、自由に編集可能なクエリを提供し、さらに結果を表形式で表示することで、その回答が質問に答えているかどうかを評価したり、求めている情報を確認したりできるようにしています。
ここで明確にしておきたいのは、これはオープンソースの既製モデルを使用しているということです。このモデルの Fine-tuning に投資することで、Excel や Python、あるいは BQ 環境でフォーミュラに変換できる BQL コードを確実に生成でき、ユーザーが私たちのデータにアクセスしやすくなります。もちろん、私たちが非常に興味を持っているもう一つの分野は、インサイトの収集と統合です。これには、 長大な決算説明会の議事録の要約なども含まれます。
上場企業にお勤めの方々は、投資家に対して企業のリスクや基本情報を理解してもらうために、定期的に行わなければならない規制関連の提出書類やさまざまな儀式的な手続きについてよくご存じでしょう。これらの四半期決算報告書、提出書類、説明会は何時間にも及び、議事録は何万語にも及び、何百ページにもなります。人間が全てに目を通すのは大変な作業です。そして、これらはすべて金融特有の専門用語で満ちています。特に決算シーズンには、掘り下げて理解したい興味深い表現方法が出てくることがあります。
アナリストは、できるだけ早く議事録から重要なインサイトを得られるようにする必要があります。画面の左側には、Apple の 2024年第3四半期決算説明会から自動生成された要約として、いくつかの発見事項や重要なガイダンスが表示されています。私たちの目標は、決算説明会の完全な要約を提供することではなく、典型的なアナリストがこの説明会について持つであろう質問に答えることです。このシステムの設計にあたって、私たちは RAG（Retrieval Augmented Generation）パラダイムを採用することにしました。金融サービス業界で何十年もの経験を持ち、金融サービス企業に関するこのような質問に答えてきた社内の Bloomberg Intelligence（BI）アナリストに協力を仰ぎました。彼らは私たちのクライアントが基本的にどのように活動しているかを非常によく理解しています。私たちは、Large Language Model と、アナリストが答える一般的な質問のリストで構成されるシステムの訓練を支援してもらいたいと考えました。そして、モデルがそれらの特定の質問に対する答えの質の高い要約を提供できるようにしたいと考えました。
複数の議事録に対して、正確な回答が提供されることを確認する必要がありました。それをテストしなければなりませんでした。ガイダンスセクションで提供される要約の品質に満足できるレベルに到達できたことがわかりました。 要約を単独の箇条書きとして提供するのではなく、自動要約の中の特定のガイダンスをクリックすると、そのガイダンスが文書のどこで見つかったのかを展開して表示できるようにしました。このように、ユーザーがそのインサイトがどのような文脈から導き出されたのかを実際に理解できるような透明性を提供することができました。
収益に関するトランスクリプトが私たちのシステムに届くと、各シード質問に関連する部分がSparseおよびDenseベクトルインデックスを使用した意味的マッチングによって抽出され、要約された回答が生成されます。これらの要約は、品質を向上させるためにポストプロセスを経ます。重要なのは、これらの要約ポイントの一つ一つをユーザーが評価できるということです。私たちは、ユーザーが判断を下せるように、そのような手がかりやヒントを提供したいと考えています。AI、機械学習、自然言語処理の全体的な利用の一環として、モデルのパフォーマンスを管理・監視するための品質管理メカニズムを数多く導入しています。これらはリリース時に実施し、リリース後も継続的に監視しています。
これは2年前のことですが、当時の実施方法と現在の方法を比較すると、2年間で多くのことが変化しました。Vadimが言及した、テレメトリーの収集、モニタリング、トレーニング中の障害タイプの特定など、私たちが行わなければならなかった多くのことが、現在ではSageMaker HyperPodですぐに利用できるようになっているという点を強調したいと思います。これは、チェックポイントの作成、ハード障害からの回復、手動介入なしで利用率を最大化するための、ターンキー型のトレーニングインフラストラクチャ、ツール、ライブラリです。
現在、NVIDIAの最新かつ最高のハードウェアはH100 GPUで、各GPUが提供できる実効TFLOPSスループットが劇的に向上しています。Blackwellやその他の興味深いイノベーションも間もなく登場します。AWSとの協議を通じて私たちが非常に期待し、強く主張していた機能の1つは、AWSの次世代SMPライブラリであるSMPでFSDPサポートが利用可能になることでした。私たちのData Science Platformは、小規模なモデルのトレーニングと微調整のために社内で運用しているML OPSプラットフォームですが、そのプラットフォーム向けのコードをどの環境でも使用できることを保証しています。Bloomberg Data Science Platformや、KubernetesやKube Flowなどのオープンソースプロジェクトの上に構築したインフラストラクチャについて詳しく知りたい方は、数週間前のQcom Americaでの私たちのチームの講演をぜひチェックしてください。オンプレミスとAWSへのバーストの両方でコードを使用できるようにすることは、私たちにとって非常に重要なイノベーションです。
もう1つ重要なことは、Andyが今朝言っていたことですが、私は自分でよいジョークを思いついたと思っていましたが、これは明らかに誰もが思いつくジョークだったようです：1つのモデルがすべてを支配することはありません。その時点で、そしてアプリケーションの要件に基づいて、適切なモデルを選択できる必要があります。その際、ユースケースに特化したモデルの長所と短所を考慮する必要があります。これには、モデルがダウンストリームタスクにどれだけ適しているかといった明白な要素も含まれます。また、モデルのレイテンシーとスループットも考慮する必要があります。これは事前に計算できる場合、ユーザーエクスペリエンスの観点から実際に重要です。
トランスクリプト要約製品では、ユーザーはモデルの実行とインサイトの提供を待つ必要はありません。しかし、ユーザーが動的に質問をする際に結果を待たされると、良くないユーザーエクスペリエンスになる可能性があります。そのような場合、Large Language Modelが適切な解決策になるかどうかを検討する必要があります。
多くの人々が、人間を介在させるケースを補完するためのAgentやツールの活用を検討しています。これはLLMの応用例の一つですが、そのようなケースに適したモデルと、文字起こしの要約や自動コード生成に適したモデルは、必ずしも同じではありません。また、モデルに知識を追加するアプローチについても考慮する必要があります。RAGや Fine-tuningを行う場合、そのモデルはその特定のアプリケーション用に特化させるか、もしくはターゲットとするアプリケーションにのみ使用されるよう確認する必要があります。モデルが引き続き良好な結果を生成しているか、あるいはFine-tuningを重ねたり、別のモデルを選択したりすることで改善の余地がないかを、継続的に評価する必要があります。
Envoy AI Gatewayとカスタムモデルの必要性
私たちは、単なるモデルのデプロイメント以上の機能をAIプラットフォームに求める必要があります。そこで、LLMワークロードの変化する要件に対応するための重要なインフラ要素についてお話ししたいと思います。Bloombergはオープンソースファーストの企業です。これは、社内で広くオープンソースを活用しているだけでなく、CephやML分野など、特定の領域においてオープンソースにも貢献していることを意味します。実際、いくつかのライブラリはBloombergで生まれました。
LLMワークロードの運用化を進める中で、私たちは、LLMにアクセスするためのゲートウェイ機能を提供する既存のオープンソースソリューションには、堅牢なテナンシー分離、クォータ管理、コスト配分、高度なルーティング機能といった、企業に必要な機能が不足していることに気づきました。これらのギャップを埋めるため、BloombergはEnvoyコミュニティと協力して、Envoy AI Gatewayを構築しました。
このソリューションは、単一のエンドポイントAPIを使用して複数のLLMをスタックに統合しようとしているチームの、様々な企業ユースケースに対応します。Envoy AI Gatewayプロジェクトは現在、BloombergチームとTed Rateのチームによって活発に開発が進められており、3つの主要な機能セットに焦点を当てています。1つ目は、集中型のAPI管理です。複数のチームが複数のLLMを使用しており、これらのLLMは異なるInferenceプロバイダーでホストされています。私たちの場合、内部のData Scienceプラットフォームや、Bedrockモデルなどが該当します。これらのモデルはそれぞれ少しずつ異なるAPIを持っているため、AI Gatewayはこの問題に対処し、すべてのモデルで一貫したAPIを提供します。
もう一つの領域は、数百のテナント間でのアクセスポリシーの分離と適用、そして堅牢なアクセスとコンプライアンス管理機能の提供に関連します。コストと容量の管理も重要な側面です。Envoy AI Gatewayは、集中型のコスト計測とコスト配分機能を提供するとともに、テナント間で利用可能な容量を配分するクォータ管理機能も提供します。また、LLMモデルで確認される遅延や全体的なフリート容量に基づいて、インテリジェントなルーティングソリューションを実装します。より多くの企業が複数のLLMを使用するようになる中で、Envoy AI Gatewayのようなソリューションは、複数のモデルをAIスタックに統合する方法を簡素化します。
これは私たちがKubeConで行ったプレゼンテーションの1つで、この話題についてはこれからも多くの講演を予定しています。私たちはこのオープンソースの機能について非常に期待しています。 本日の質疑応答に入る前に、1つの質問で締めくくりたいと思います：本当にカスタムFoundation Modelは必要なのでしょうか？独自のモデルをトレーニングする必要があるのでしょうか？
このプロセスは複雑で、その質問に対する答えは単純な定型的なプロセスではお答えできないということを私たちは学びました。良いニュースは、もし実際にこれを行う必要があり、独自のモデルの実験やプロダクション用モデルのトレーニングを行いたい場合、AWSは2年前と比べてはるかにターンキーなソリューションを提供しているということです。実際にこれを行っていた時にSageMaker HyperPodがあれば、私たちの作業ははるかに楽になっていたでしょう。
既存のオープンソースのオープンウェイトモデルを自社のデータセットでFine-tuningしたり、私たちが一から訓練していない既存のLarge Language Modelを活用したりすることで、素晴らしい結果を得られないかどうかをよく考えてみてください。モデルのFine-tuningやRAGを使用して追加のコンテキストを提供することは、BloombergのプロダクトにおけるGenerative AIの力を引き出す鍵となりました。BloombergGPTはクライアントアプリケーション向けには決して公開されることを想定していませんでしたが、これが私たちのビジネスの課題を解決する正しい方法かどうかについて学んだこと、そしてモデルの構築とトレーニングを通じて得た知見は、数え切れないほど多くの方法で、私たちのより広範なGenerative AI戦略の形成に役立ちました。そして、これら3つの原則が、現在の私たちのプロダクトイノベーションすべてを推進しているのです。ありがとうございました。ここで、質問のモデレートをお願いするためにVasu Chariに引き継ぎたいと思います。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion