DatabricksとMLflowを活用して、FactSetが企業向け生成AIプラットフォームを実現した方法

「FactSetの使命は、クライアントがデータに基づいた意思決定を行い、ワークフローと生産性を向上させることです。私たちは、プラットフォーム全体でAI駆動のソリューションを提供するために、自社の開発者およびクライアントの企業の開発者が効率的かつ効果的に革新を進めることを支援しています。Databricksはこの革新の重要な要素であり、データとAIを中心としたソリューションを構築するための柔軟なプラットフォームを提供することで、価値を創出しています。」 - Kate Stepp, CTO, FactSet

私たちの企業と主要な取り組み

2024年には、特にAIの応用を通じてクライアントのワークフローを改善し、検索やさまざまなクライアントチャットボット体験における提供内容を強化することに焦点を当てています。AIをさまざまなサービスに統合することで、より個別化された効率的なクライアント体験を提供し、成長を促進することを目指しています。これらのAI駆動の強化は、ファクトセット投資家向けの財務提案の生成からポートフォリオのパフォーマンスの要約に至るまで、金融ワークフローのさまざまな側面を自動化し最適化することを目的としています。

ソリューションおよびデータプロバイダーとしてのリーダーであり、テクノロジーの早期導入者として、FactSetは生成AI（GenAI）を使用して顧客体験および内部アプリケーションを強化するいくつかの機会を特定しました。FactSet Mercuryイニシアチブは、新規および既存のユーザー向けにAI駆動の体験を提供することで、FactSetワークステーション内のユーザー体験を向上させます。このイニシアチブは、コード生成やFactSet提供データの要約などの特定のタスクに合わせてカスタマイズされた大規模言語モデル（LLM）によってサポートされています。しかし、FactSetのエンドユーザー体験のビジョンは明確であったものの、このビジョンを実現するためにはさまざまなアプローチが考えられました。

インテリジェントでAI駆動の体験を提供するために、FactSetは開発者が迅速に革新できるようにさまざまなツールやフレームワークを探索し始めました。この記事では、商用モデルに焦点を当てた初期のアプローチから、Databricksによって強化された柔軟性のあるAIフレームワークに至るまでの進化について説明します。

開発者の自由がもたらす機会費用:GenAIツールの過負荷への対処

標準化されたLLM開発プラットフォームの欠如

GenAI導入の初期段階では、標準化されたLLM開発プラットフォームの欠如が大きな課題でした。異なるチームのエンジニアは、さまざまなツールや環境を使用したり、特定のユースケースに合わせたカスタムソリューションを利用したりしていました。この多様性には、クラウドネイティブの商用オファリング、モデルのファインチューニング用の専門サービス、オンプレミスのモデルトレーニングおよび推論ソリューションが含まれていました。標準化されたプラットフォームがないため、以下の問題が発生しました：

• コラボレーションの障壁: 異なるツールやフレームワークのため、チーム間の協力が難しい
• 重複作業: 似たようなモデルが孤立して再開発されることが多く、非効率を招く
• 品質の一貫性の欠如: 異なる環境のため、アプリケーション全体でモデルの性能が一貫しない

共通のLLMOpsフレームワークの欠如

もう一つの課題は、組織内のLLMOpsの断片化されたアプローチでした。一部のチームはMLflowのようなオープンソースソリューションを試していたり、ネイティブクラウド機能を利用していましたが、一貫したフレームワークは存在しませんでした。この断片化は、以下のライフサイクルの課題を引き起こしました：

• 孤立したワークフロー: チーム間でのコラボレーションが困難で、プロンプト、実験、モデルの共有ができない
• 増大する需要: 標準化の欠如がスケーラビリティと効率を妨げ、MLおよびLLMソリューションの需要が増加
• 再利用性の制限: 共通フレームワークがないため、プロジェクト間でのモデルや資産の再利用が難しく、繰り返し作業が発生

データガバナンスと系統の問題

生成AIのために複数の開発環境を使用することは、データガバナンスの課題を引き起こしました：

• データサイロ: 異なるチームがさまざまな場所にデータを保存し、複数のデータコピーとストレージコストが増加
• 系統追跡: データ変換を追跡することが難しく、パイプライン全体でのデータ使用の理解が影響
• 詳細なガバナンス: 分散したデータではコンプライアンスとデータの整合性を確保することが難しく、ガバナンスが複雑化

モデルガバナンス + サービング

最後に、モデルを効果的に管理および提供することにはいくつかの障害がありました：

• 複数のサービングレイヤー: モデルの維持とガバナンスが煩雑で時間がかかる
• エンドポイント管理: さまざまなモデルサービングエンドポイントの管理が複雑さを増し、監視に影響
• 集中管理の欠如: オーバーサイトの欠如が一貫したパフォーマンストラッキングと最適なモデルメンテナンスを妨げる

開発者を断片化された環境ではなくフレームワークで支援する

AIプロジェクトが進展し、プロダクションに移行するにつれて、プラットフォームの柔軟性を無制限に提供することが、特に多数のアプリケーションに対するLLMライフサイクルの管理に課題をもたらすことを認識しました。FactSetでのGenAI実装の第2フェーズでは、中央集権的なエンドツーエンドのフレームワークのガードレールを備えた最適なモデルを選択する力を開発者に与えます。

特定のビジネス要件に基づく徹底的な評価の結果、FactSetは2023年後半にDatabricksをエンタープライズML/AIプラットフォームとして選定しました。初期の導入およびさまざまなAIプラットフォームとサービスの開発で直面した課題を踏まえ、FactSetはLLM/AIアプリケーションの新しい開発をDatabricks Mosaic AIおよびDatabricks管理のMLflowで標準化することを決定しました。以下の理由からです：

モデリングとAI/ML開発のためのデータ準備

Databricks Mosaic AIツールおよび管理されたMLflowは、効率を向上させ、実務者のために基盤となるクラウドインフラの維持の複雑さを軽減しました。多くのクラウドインフラタスクの複雑さを抽象化することで、開発者はAWSで動作する管理されたコンピュートおよびDatabricksのサーバーレスおよび非サーバーレスのコンピュートを使用して、新しいユースケースを革新するための時間をより多く費やすことができました。深いクラウドの専門知識や特化したAIおよびMLの経験がなくても、製品エンジニアはDatabricks環境から直接ライブラリや依存関係をインストールすることができました。

例えば、私たちのエンタープライズ展開を活用するアプリケーション開発者は、収益報告要約のためのRAGアプリケーションのエンドツーエンドパイプラインを簡単に作成することができました。彼らは、XML形式でニュースデータを取り込んで解析し、テキストを長さとスピーカーごとに分割し、エンベディングを作成し、ベクター検索インデックスを更新し、選択したオープンソースモデルを使用してRAGを実行しました。最後に、モデルサービングエンドポイントがフロントエンドアプリケーションに応答を提供しました。 

このフレームワークは、実務者がDatabricksデータインテリジェンスプラットフォームを使用して再利用可能な取り込みおよび変換パイプラインを作成するための使いやすい協調的な開発環境を提供します。データはFactSetが管理するS3バケットに統合されます。

ガバナンス、系統、トレーサビリティ

Unity Catalogは、データサイロ、複数のガバナンスモデル、データとモデルの系統の欠如、および監査性の欠如などの以前の課題を解決しました。階層構造と細かいガバナンス機能を備えたカタログ機能を提供します。また、Unity Catalogは、異なるチームの複数のユーザーが共有環境でメタデータおよび物理ストレージレベルの分離を可能にし、個々のユーザーIAMベースのガバナンスの必要性を減らします。

例えば、FactSetには、特定のユースケースやアプリケーションに取り組む複数のチームがある複数の事業部門があります。ユーザーがSSO認証情報を使用してDatabricksにサインインすると、そのユーザーは管理されたデータ資産の分離されたカスタマイズされたアクセスビューを確認します。基礎となるデータは、そのユーザーのチーム固有のFactSetのS3バケットに存在し、Unity Catalogに外部の場所として登録され、ストレージ認証情報が割り当てられています。Unity Catalogは、ユーザーが特定のIAM権限を持つ必要なしに、分離とガバナンスを強制します。

取り込みおよび変換を統合し、Unity Catalogを一貫性のある標準化されたガバナンスフレームワークとして活用することで、Databricksコンピュートを使用したすべての操作のテーブル/カラムレベルの系統をキャプチャできました。系統をキャプチャする能力は、基礎となるデータの監視にとって重要であり、下流のGenAIアプリケーションの説明可能性を実現します。Unity Catalogの系統と基礎となるデータの監査性を組み合わせることで、FactSetアプリケーション所有者はデータライフサイクルおよび下流のクエリパターンをよりよく理解できるようになります。

LLMOps + FactSetセルフサービス機能

ビジネスユニット間のエンタープライズ展開を構築するだけでなく、Databricksを内部のGenAI Hubと統合し、プロジェクトごとのすべてのMLおよびLLMリソースを管理しました。この統合により、Databricksのワークスペース、モデルカタログ、およびMLプロデューサーとMLコンシューマーの協力とモデルの再利用を促進するための重要なメタ共有が中央集権化されました。MLflowとDatabricksのコスト配分の重要な統合が含まれており、Databricksのコストビューを活用してプロジェクトごとのビジネスの透明性を向上させることで、プロジェクトハブおよびコスト配分ワークフローを合理化しました。

FactSetのプラットフォーム評価において最も重要な推進要因は、包括的で標準化されたLLMOpsフレームワークとモデルデプロイメント環境を作成することでした。

モデル開発中に、MLflowを使用して異なるバージョンのモデル性能を簡単に比較できます。Databricks UIに統合されたMLflowを活用することで、実務者はポイント＆クリック操作でMLflowの機能を簡単に利用できると同時に、プログラムでMLflowの機能を活用する柔軟性も得られます。MLflowは、モデルバージョンの反復作業をチームで協力して行うための協調的な経験を提供し、孤立した作業を減らし、効率を向上させます。

FactSetの評価中の重要な考慮事項は、Databricksが幅広いオープンソースおよび商用モデルをサポートしていることでした。私たちの目標は、クライアントに最高の精度、パフォーマンス、およびコストを提供する商用およびオープンソースモデルを活用することです。Mosaic AIは、単一のサービングレイヤーから複数のモデルタイプ（カスタムモデル（例：Langchain、HuggingFace）、オープンソースファウンデーションモデル（例：Llama 3、DBRX、Mistral）、外部モデル（例：OpenAI、Anthropic））を提供できます。MLflow Deployments Serverは、さまざまなモデルタイプのモデルサービングを簡素化します。

LLMOps + FactSetセルフサービス機能

ビジネスユニット間のエンタープライズ展開を構築するだけでなく、Databricksを内部のGenAI Hubと統合し、プロジェクトごとのすべてのMLおよびLLMリソースを管理しました。この統合により、Databricksのワークスペース、モデルカタログ、およびMLプロデューサーとMLコンシューマーの協力とモデルの再利用を促進するための重要なメタ共有が中央集権化されました。MLflowとDatabricksのコスト配分の重要な統合が含まれており、Databricksのコストビューを活用してプロジェクトごとのビジネスの透明性を向上させることで、プロジェクトハブおよびコスト配分ワークフローを合理化しました。

私たちの製品成果

Mercuryでのプロプライエタリフレームワークに対するオープンソースの代替手段のファインチューニング

プラットフォームの初期採用者は、クライアントのプロンプトに基づいて既存のデータインターフェースからデータをリクエストするための定型データフレームを生成できるコード生成コンポーネントでした。

このアプリケーションは大規模な商用モデルを大いに活用しており、最も一貫性のある高品質な結果を提供しました。しかし、パイプライン内の既存の商用モデルでは、初期のテスターは1分以上の応答時間に直面しました。Mosaic AIを使用して、meta-llama-3-70bおよび最近のDatabricks DBRXをファインチューニングすることで、ユーザーリクエストの平均遅延を70％以上削減できました。

このコード生成プロジェクトは、Databricks Mosaic AIの柔軟性を示し、オープンソースモデルのテストと評価により、パフォーマンスの大幅な向上とFactSetワークステーションでのユーザー体験の向上をもたらしました。

オープンソースファインチューニングワークフローを使用したテキストからフォーミュラへの高度なRAG

私たちのDatabricksツールを活用したもう一つのプロジェクトは、テキストからフォーミュラへのイニシアチブです。このプロジェクトの目標は、自然言語クエリを使用してカスタムFactSetフォーミュラを正確に生成することです。以下はクエリと対応するフォーミュラの例です。

プロジェクトは単純な検索補完生成（RAG）ワークフローから始まりましたが、すぐに「品質の壁」にぶつかり、より複雑なフォーミュラでのスケールアップができませんでした。広範な実験の結果、以下のアーキテクチャを開発し、精度の著しい向上を達成しましたが、エンドツーエンド（e2e）の遅延が高くなりました。以下の画像は、Mosaic AIを使用する前のアーキテクチャを反映しています。

Databricks Mosaic AIプラットフォームは、トレーニングの進捗を厳密に監視するための詳細なファインチューニングメトリクスを含むさまざまな機能を提供します。さらに、モデルバージョン管理をサポートし、特定のモデルバージョンをネイティブのサーバーレス環境にデプロイおよび管理することができます。

このような一貫性のあるシームレスなワークフローを実現することは極めて重要です。これはエンジニアリング、ML DevOps、およびクラウドチームのエンドツーエンドの経験を向上させるだけでなく、これらのドメイン全体で効率的な同期とコラボレーションを確保します。この合理化されたアプローチは、開発およびデプロイメントパイプラインを大幅に加速し、生産性を最適化し、モデルが最高のパフォーマンスとコンプライアンス基準に準拠することを保証します。今こそ、初期の要件を超えて「機能的」な主要指標を強化する戦略を策定し、製品をセルフサービス可能にする時です。このビジョンを実現するには、エンタープライズレベルのLLMOpsプラットフォームが必要です。

以下のワークフローダイアグラムは、FactSetのガバナンスおよびコンプライアンスポリシーに準拠するための追加の例を生成するためにデータを体系的に収集し、主題専門家（SME）の評価を組み込んだRAGプロセスの統合を説明しています。このキュレートされたデータセットは、Unity Catalogのプロジェクトスキーマ内に保存され、DatabricksファウンデーションモデルAPIまたはHugging-Face Models Hubのモデルを活用してファインチューニングされたモデルを開発することができます。

私たちにとって重要な「機能的」な主要指標には「精度」と「遅延」が含まれ、どちらもプロプライエタリシステムおよびオープンソースソリューションの両方を活用することで最適化できます。ファインチューニングの取り組みにより、エンドツーエンドの遅延を約60％削減することができました。これらのファインチューニングされたモデルの多くは、上記の図に示されているようにオープンソースのLLMモデルです。

この戦略が当社のGenAI戦略にとって重要な理由

DatabricksがFactSetのワークフローに統合されていることで、LLMプロジェクトライフサイクル全体にわたる中央集権化された統一されたツールセットが提供されます。これにより、異なるチームやビジネスユニット間でモデルやデータを共有し、孤立を減らし、LLM関連のコラボレーションを増やすことができます。最終的に、これにより、複雑さのために従来のAIエンジニアの背後に隠れていた多くの高度なAIワークフローが民主化されました。

多くのテクノロジー企業と同様に、FactSetの初期のGenAI実験は、使いやすさと市場投入の速さのために商用LLMを大いに活用していました。当社のMLプラットフォームが進化するにつれ、GenAI戦略を構築する際にガバナンスとモデル管理の重要性を認識しました。Databricks MLflowを使用することで、LLMOpsのベストプラクティスを強制し、オープンモデルを試験し、すべてのモデルタイプを評価することができ、多くの柔軟性を提供しました。

製品チームが引き続き革新し、LLMやMLを採用する新しい方法を見つけるにつれ、私たちの技術目標は、モデルの選択を可能にし、チームが仕事に最適なモデルを使用する文化を採用することです。これは、クライアント体験を強化するために新しいテクノロジーの採用を支援するリーダーシップ原則と一致しています。管理されたMLflowおよびDatabricksの採用により、GenAI戦略は、製品に既に組み込まれている商用LLMとともに、よりファインチューニングされたオープンソースモデルの範囲を含む統一された体験をサポートします。