FactSetがDatabricks AI Runtimeでモデルのトレーニングとデプロイを数日から数時間に短縮した方法

FactSetのText-to-Formula（TTF）システムは一見シンプルに見えて非常に難度の高い役割を担っています。それは、投資の専門家からの自然言語リクエストを受け取り、正確なFactSet Query Language（FQL）数式に変換することです。

FactSetは当初、検索拡張生成（RAG）を中心にTTFを構築し、検索によって指定されたリクエストに関連する例や情報を特定していました。しかし、利用の増加に伴い、クエリはより専門化し、数式も高度化していったため、このアプローチは品質の限界に直面しました。そこでFactSetは、ファインチューニングされたオープンモデルをCompound AIアーキテクチャに取り入れ始めました。これにより、推論時の検索に主に依存するのではなく、FQLの構造やパターンに基づいてモデルをトレーニングできるようになりました。TTFに関する初期の取り組みにおいて、FactSetはファインチューニングされたモデルの導入により、エンドツーエンドのレイテンシーが約60%削減されることを確認しました。

システムの進化に伴い、ファインチューニングの役割も変化しました。FactSetはより多くのトレーニングデータを蓄積し、モデルを定期的に更新するようになりました。これにより、以前は実験的だったワークフローが、TTF開発の継続的なプロセスへと移行しました。現在、チームは概ね2〜3週間ごとにモデルのファインチューニングを行っています。

ファインチューニングがリリースサイクルの一部となるとき

数週間ごとのトレーニングは、インフラへの要件を変えます。たまに行う実験であれば、環境の準備やGPUコンピューティングの設定も対応可能かもしれません。しかし、新しいデータや新しいモデルのテスト準備ができるたびにその作業を繰り返すことは、開発サイクルに直接的なオーバーヘッドをもたらします。

モデルに対する要件も、実験ごとに変わる可能性があります。FactSetはLlamaベースのモデルを使用してきましたが、新しいオープンモデルの評価も継続しています。モデル、プロンプトの長さ、出力の特性が異なれば、必要なコンピューティング構成も異なるため、トレーニング環境を固定のGPU設定に紐付けると、チームの実験に伴う柔軟な適応が難しくなります。

FactSetは、 Databricks AI Runtimeを使用して、これらのファインチューニングワークロードをサーバーレスGPUインフラ上で実行しています。エンジニアは、基盤となるGPU環境を事前にプロビジョニングおよび構成することなく、特定のトレーニング実行の要件に基づいてコンピューティングを選択できます。

開発ループ内にトレーニングを維持

TTFのトレーニングワークフローは、Databricks上ですでに稼働しているデータ、実験、モデル管理、ガバナンスと並行して機能します。FactSetはMLflowを使用してモデル開発と実験を追跡し、基盤となるデータは既存のLakehouse環境内でガバナンスが維持されます。

AI Runtimeでファインチューニングを実行することで、GPUトレーニングをそのワークフロー内に収めることができます。エンジニアはガバナンスの効いたデータを扱い、新しいモデルをトレーニングし、生成されたアーティファクトを追跡し、ファインチューニング用の別個のGPUスタックを維持することなくデプロイへと進めることができます。FactSetでは、これによりカスタムTTFモデルのセットアップ、トレーニング、デプロイに必要な時間を数日から数時間に短縮できました。

DatabricksのAI Runtimeは、カスタムのText To Formula（TTF）モデルをトレーニングするプロセスを大幅に効率化しました。インフラのセットアップや遅延がないため、プロンプトのサイズや出力トークン生成に基づいて適切なコンピューティングを簡単に選択できました。これにより、迅速に行動し、Lakehouseのワークフローを維持しながら、完全なガバナンスを備えた高品質なモデルを提供することができ、モデルのセットアップ、トレーニング、デプロイにかかる時間を数日から数時間に削減できました。- Nikhil Sunderraj氏（FactSet Research Systems, Inc. プリンシパル マシーンラーニング エンジニア）

進化し続けるモデルに対応する構築

モデルを変更できる柔軟性は、当初からTTFの進化の一部でした。高度なRAG、特に外部でホストされたモデルのみへの依存は、利用が増加し数式が複雑化するにつれて、一貫した精度とレイテンシーのボトルネックになります。RAGはシステムがより複雑な数式に直面するまでは機能していました。ファインチューニングされたオープンモデルは、FactSetに品質とレイテンシーを改善するもう1つのアプローチを提供しました。現在、新しいモデルが利用可能になると、チームは現在のモデル選択を永久的なものとして扱うのではなく、ワークロードに対してそれらを評価できるようになりました。

TTF自体もより専門化しています。FactSetはデータが蓄積されるにつれて、クエリの分解、コンポーネントの抽出、ライブラリの識別などのタスク向けに、追加のファインチューニングモデルを検討しています。これにより、ワークフローの各パートに最も適したモデルを使用する機会が増える一方で、迅速で再現可能なトレーニングがより重要になります。

トレーニング環境を再構築する必要がなければ、モデルの変更のテストは大幅に容易になります。AI Runtimeを通じてGPUコンピューティングをオンデマンドで利用できるため、エンジニアリングの作業は、どのモデルを使用するか、どのようにトレーニングするか、結果として得られたバージョンがアプリケーションを改善するかといった、実際にTTFに影響を与える課題に注力できるようになります。

さらに、ファインチューニングパイプラインはDatabricks Lakeflow JobsおよびPipelines上で、 プラグアンドプレイで再利用可能なフレームワークとして構築されました。これは、最小限のセットアップ作業で異なるTTFタスクや他のチーム間でも容易に導入できるように設計されており、オンボーディングの摩擦を軽減し、統合を加速する標準化された基盤を提供します。

モデルの選択を実用的なものに

オープンモデルの進化は急速です。今日、品質、レイテンシー、コストのバランスが最適なモデルが、6か月後もチームが望むモデルであるとは限りません。したがって、モデルの選択肢を確保するには、単に新しい重みセットをダウンロードできる以上のことが求められます。それを支えるトレーニングやデプロイのワークフローも、そのスピードに追従できなければなりません。

FactSetのTTFでの経験は、それが本番環境でどのように機能するかを示しています。データとアプリケーションが進歩する中で、チームは新しいオープンモデルのテストを継続でき、AI Runtimeは既存のDatabricksワークフロー内でサーバーレスGPUインフラを提供します。各イテレーションのセットアップ、トレーニング、デプロイに数日費やす代わりに、FactSetはそのサイクルを数時間で完了できます。

数週間ごとに再トレーニングされるシステムにおいて、この違いは大きな効果を生みます。新しいデータはより早く新しいモデルに反映され、エンジニアは各イテレーションでトレーニングに必要なインフラの準備ではなく、TTFの改善により多くの時間を費やすことができます。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事