TrueML #22 - 機械学習プラットフォームとLLM @ Voiceflow

True ML Talksの新しいエピソードをお届けします。今回は、 VoiceflowのMLプラットフォームとLLMについて深く掘り下げ、今回は Denys Linkov氏

DenysはVoiceflowの機械学習チームを率いています。彼は創業時のMLエンジニアとして入社しました。それ以前は、グローバル銀行でシニアクラウドアーキテクトとして、データシステム、MLOps、コアインフラストラクチャを担当していました。 

📌

Adhitihya氏との対談では、以下の点について取り上げます。
- Voiceflowにおける機械学習
- VoiceflowのMLOpsジャーニー
- モデルのデプロイと可観測性を自動化し、コンテキストスイッチングを減らして効率を向上させる
- リアルタイム推論パイプライン：利点と課題
- Voiceflowの生成AIへのアプローチ

エピソード全編はこちらからご覧ください：

Voiceflowにおける機械学習

Voiceflowは、企業が会話型AIアプリケーションを構築・デプロイできるノーコードプラットフォームです。チャットボット、バーチャルアシスタント、その他の会話型インターフェースを、以下のような幅広い業界向けに作成するために利用できます。

1. Eコマース
2. 不動産
3. 銀行
4. 自動車
5. 公共事業
6. 政府

VoiceflowのNLUモデルは、さまざまなソースからの膨大なテキストとコードのデータセットでトレーニングされているため、幅広い業界に対応できます。これにより、Voiceflowは業界に関わらず、幅広い自然言語クエリを理解し、応答することができます。

例えば： Voiceflowのチャットボットは、eコマース企業が顧客の商品探し、商品に関する質問への回答、注文を支援するために利用できます。また、不動産会社が潜在的な購入者の家探し、エージェントとの面談予約、住宅購入プロセスに関する情報提供を支援するために利用することもできます。

これらすべての業界に対応できるNLUモデルを構築する上での課題の1つは、各業界には独自の言語と専門用語があることです。しかし、VoiceflowのNLUモデルは、さまざまな業界からのより多くのデータに触れることで、時間の経過とともにこれらの違いを学習することができます。

VoiceflowのMLOpsの道のり：会話型AIのための機械学習モデルの構築とデプロイ

Voiceflowが直面した最初の課題の1つは、自社でモデルを構築するか、外部のモデルを使用するかを決定することでした。Voiceflowは両方の選択肢を検討し、いくつかの概念実証を構築しました。Voiceflowが最初に構築した機能は発話生成機能で、これは機械学習を使用して、ユーザーが自身のデータモデルを強化するために追加する必要がある例を生成します。

発話生成モデルを本番環境にデプロイするために、VoiceflowはMLOpsプラットフォームを構築しました。このプラットフォームの目標は、複数の実験を非常に迅速に本番環境にデプロイできること、そして環境を管理できることでした。

発話生成モデルは、より高度な生成モデルであるChatGPTのリリースによって、最初に廃止されたものでした。この経験は、顧客体験にとって最善なものに集中するために、必要であれば自社の開発を中止することもいとわない柔軟性の重要性をVoiceflowに教えました。

Voiceflowはまた、命令チューニングされたGPTベースモデルの登場以来、会話型AI分野で起こった大きな変化についても議論しています。Voiceflowは、当時GPT-3の利用を検討しなかったことは戦略的な誤りだったと認めていますが、この分野が進化するにつれて、適応し、アプローチを変える意欲を持つことが重要であることも学びました。

に関するブログはこちらです。 Voiceflow NLUの作成：

‍

Inside Voiceflow | Voiceflow

Allow us to regale you with product announcements, an exclusive peek behind the Voiceflow curtain, and product tips and tricks from our communit.

Voiceflow

‍

モデルのデプロイと可観測性を自動化して、コンテキストスイッチングを減らし、効率を向上させる

従来の機械学習開発プロセスでは、データサイエンティストはJupyter Notebookでモデルをトレーニングし、それを機械学習エンジニアまたはバックエンドエンジニアに引き渡して本番環境にデプロイします。これは、エンジニアがモデルとデータを理解して正常にデプロイする必要があるため、コンテキストスイッチングや遅延につながる可能性があります。

モデルのデプロイと可観測性を自動化する

この課題に対処する一つの方法は、モデルのデプロイとオブザーバビリティを自動化することです。これは、データサイエンティストが他のエンジニアを関与させることなく、本番環境でモデルをデプロイし監視できるようにする一連のツールとプロセスを作成することで実現できます。

その一例として、モデルのデプロイとオブザーバビリティのためのマネージドサービスを提供するクラウドベースのプラットフォームを利用することが挙げられます。これらのプラットフォームは、以下のような様々な機能を提供できます。

1. モデルの自動デプロイとスケーリング
2. リアルタイムのモデル監視
3. ドリフト検出とアラート
4. モデルのバージョン管理とロールバック

独自のカスタムツールとプロセスを開発する

モデルのデプロイとオブザーバビリティを自動化するもう一つのアプローチは、独自のカスタムツールとプロセスを開発することです。これにより、より高い柔軟性と制御が可能になりますが、その分、より多くの投資も必要となります。

ある企業がこのアプローチを用いてモデルのデプロイとオブザーバビリティを自動化した具体的な例を挙げます。

1. モデルのデプロイと監視に必要なすべてのサービスを備えたクラウド環境を立ち上げる一連の自動化スクリプトを作成しました。
2. 新しいモデルをクラウド環境に簡単にデプロイできるCLIツールを開発しました。
3. そのCLIツールは、モデルをデプロイするために必要なすべてのフォルダとTerraformファイルを自動的に作成します。
4. そのCLIツールは、モデルをデプロイする環境も指定します。

この自動化により、その企業のデータサイエンティストは、他のエンジニアを一切関与させることなく、本番環境でモデルをデプロイし監視できるようになりました。

独自のカスタムツールとプロセスを開発する際の課題

モデルのデプロイとオブザーバビリティのための独自のカスタムツールとプロセスを開発する際には、考慮すべきいくつかの課題もあります。

1. 複雑性： 独自のカスタムツールとプロセスを開発することは、複雑で時間のかかる場合があります。
2. デバッグ： 問題が発生した際にデバッグするのは難しい場合があります。特に、データサイエンティストが構築されたパイプラインの全体像を把握していない場合はなおさらです。
3. メンテナンス： カスタムツールとプロセスには、継続的なメンテナンスとサポートが必要です。

課題を軽減する方法

モデルのデプロイとオブザーバビリティのための独自のカスタムツールやプロセスを開発する際の課題を軽減するために、いくつかの対策が考えられます。

1. スモールスタート： まずは、差し迫ったニーズを満たす基本的なツールとプロセスを開発することから始めましょう。その後、時間をかけて機能を追加していくことができます。
2. オープンソースツールとライブラリを活用する： 独自のカスタムツールやプロセスを開発するのに役立つオープンソースツールやライブラリが多数利用可能です。これらのツールやライブラリを活用することで、必要な開発作業量を削減できます。
3. ツールとプロセスを文書化する： データサイエンティストや他のエンジニアが容易に理解し、使用できるように、ツールとプロセスを徹底的に文書化しましょう。
4. トレーニングとサポートを提供する： データサイエンティストや他のエンジニアに対し、カスタムツールやプロセスの使用方法に関するトレーニングとサポートを提供しましょう。

リアルタイム推論パイプライン：メリットと課題

リアルタイム推論パイプラインには、以下のような多くのメリットがあります。

1. 低レイテンシー： リアルタイム推論パイプラインは、最小限の遅延でユーザーに予測を提供できます。
2. スケーラビリティの向上： リアルタイム推論パイプラインは、需要に応じてスケールアップまたはスケールダウンできるため、大量の処理を必要とするアプリケーションに最適です。
3. 柔軟性の向上： リアルタイム推論パイプラインは、分類、回帰、物体検出など、さまざまな機械学習モデルの実装に利用できます。

しかしながら、リアルタイム推論パイプラインには、以下のような課題もあります。

1. 複雑性の増大： リアルタイム推論パイプラインは、機械学習、分散システム、インフラストラクチャに関する専門知識を要するため、設計と実装が複雑になる可能性があります。
2. コストの増大： リアルタイム推論パイプラインは、より強力なハードウェアとインフラストラクチャが必要となるため、バッチ推論パイプラインよりも運用コストが高くなる可能性があります。
3. エラーリスクの増大： リアルタイム推論パイプラインは、データをリアルタイムで処理し予測を生成する必要があるため、バッチ推論パイプラインよりもエラーが発生しやすくなります。

リアルタイム機械学習パイプラインにおけるオートスケーリング

リアルタイム機械学習パイプラインを構築・デプロイする上での課題の一つは、トラフィックの変化に対応するためにシステムを自動スケーリングする方法です。トラフィックパターンの予測可能性、モデルのレイテンシー要件、オートスケーリングアルゴリズムの複雑さなど、考慮すべき要素がいくつかあります。

リアルタイム機械学習パイプラインを自動スケーリングするアプローチの一つは、キューイングシステムを使用することです。これにより、プロデューサー（推論リクエストを生成する側）とコンシューマー（推論リクエストを処理する側）を分離できます。この分離によって、システムのスケーリング方法においてより柔軟性が得られます。

キューイングベースのシステムを自動スケーリングするには、キュー内のメッセージ数、リクエストの平均レイテンシー、ワーカーのCPU使用率など、さまざまなメトリクスを使用できます。これらのメトリクスを組み合わせて使用することも可能です。

システムの過剰スケーリングや過少スケーリングを避けるために、オートスケーリングアルゴリズムを慎重に調整することが重要です。過剰スケーリングはリソースの無駄につながる可能性があり、一方、過少スケーリングはパフォーマンスの問題を引き起こす可能性があります。

リアルタイム推論のためのキューイングベースシステムの自動スケーリングに関する追加の考察を以下に示します。

1. クラウドベースのプラットフォームを使用する： クラウドベースのプラットフォームは、トラフィックパターンの変化に応じてシステムを自動スケーリングしやすくします。例えば、クラウドベースのロードバランサーを使用して、トラフィックをポッド全体に分散させ、必要に応じてポッドの数を増減させることができます。
2. オートスケーリングをサポートするキューイングシステムを使用する： 一部のキューイングシステムはオートスケーリングをサポートしており、キュー内のメッセージ数に基づいてワーカーの数を自動的に増減できます。これにより、手動での介入なしに、システムがトラフィックの急増に対応できるようになります。
3. システムを監視する： オートスケーリングに関する問題を特定するために、システムを綿密に監視することが重要です。例えば、スケーリングの増減をトリガーするしきい値を調整する必要があるかもしれませんし、システム内の特定のボトルネックを特定して対処する必要があるかもしれません。

レイテンシーに敏感なリアルタイムシステム向けのモデルサーバー

レイテンシに敏感なアプリケーション向けにモデルサーバーを選ぶことは、いくつかの理由から困難を伴います。まず、多くの異なるモデルサーバーが存在し、それぞれに長所と短所があります。次に、レイテンシに敏感なアプリケーションの要件は、特定のアプリケーションや使用されるモデルの種類によって大きく異なります。最後に、本番環境でモデルサーバーがどのように機能するかを予測することは、しばしば困難です。

考慮すべき要素

レイテンシに敏感なアプリケーション向けにモデルサーバーを選ぶ際には、以下の要素を考慮することが重要です。

1. モデルレイテンシ: モデルサーバーのレイテンシは、アプリケーションの要件を満たすのに十分低い必要があります。
2. スケーラビリティ: モデルサーバーは、アプリケーションのトラフィック需要に対応できるようスケールできる必要があります。
3. 柔軟性: モデルサーバーは、さまざまなフレームワークやハードウェアプラットフォームなど、アプリケーションの特定のニーズをサポートできる十分な柔軟性がある必要があります。
4. 使いやすさ: モデルサーバーは、使いやすく管理しやすいものである必要があります。
5. ベンチマーク: 特定のニーズに対してどのモデルサーバーが最も優れたパフォーマンスを発揮するかを確認するために、異なるモデルサーバーのベンチマークを行うことが重要です。
6. サポート: モデルサーバーで利用可能なサポートレベルを考慮してください。
7. コミュニティ: モデルサーバーを取り巻くコミュニティの規模と活動状況を考慮してください。

💡

VoiceflowのMLプラットフォームに関するその他の洞察:
Voiceflowは、企業顧客ごとに要件が異なるため、AWSとGCPを組み合わせて使用しています。KarpenterやAutopilotについては、これらの機能がリリースされた時点ですでにインフラを構築していたため、まだ利用を検討していません。また、多くのワークロードでT4 GPUを使用する必要があり、これはAutopilotには最適ではありません。全体として、現時点ではエンジニアリング時間を優先しており、スケールアップするにつれて、最終的にはより高度なインフラソリューションに移行する予定です。

Voiceflowの生成AIへのアプローチ

Voiceflowは、オープンソースの生成AIに対して慎重なアプローチをとっています。これらのモデルが持つ潜在的な利点を認識している一方で、関連する課題も認識しています。ユーザーに最高の体験を提供することに尽力しており、ビジネスにとって適切な時期が来たらオープンソースモデルに切り替える予定です。

オープンソース生成AIの課題

オープンソースの生成AIには、いくつかの課題があります。

1. 急速な進化： オープンソースの生成AIモデルは急速に進化しており、最新の最適化に追いつくのが難しい場合があります。
2. コスト： オープンソースの生成AIモデルは、学習とデプロイに計算コストがかかる場合があります。
3. サポート： オープンソースの生成AIモデルは、プロプライエタリモデルと同じレベルのサポートがない場合があります。

オープンソース生成AIの利点

課題があるにもかかわらず、オープンソースの生成AIモデルには多くの利点もあります。

1. 透明性： オープンソースの生成AIモデルはプロプライエタリモデルよりも透明性が高く、ユーザーはモデルの仕組みをよりよく理解し、結果を信頼できます。
2. 再現性： オープンソースの生成AIモデルはプロプライエタリモデルよりも再現性が高く、ユーザーは実験結果を再現し、その成果を他者と共有できます。
3. カスタマイズ性： オープンソースの生成AIモデルは、特定のニーズに合わせてカスタマイズおよび拡張できます。

レイテンシーへの対応

レイテンシーは、検索拡張生成システム用のモデルを選択する際に考慮すべき重要な要素です。最善のアプローチは、ユーザーに利用するモデルの選択肢を提供し、異なるタスクに何を使用すべきかについて教育することです。

例えば、レイテンシーが最も重要な要素である場合、複雑な発話と静的応答を伴うNLUベースのアプローチを使用することが推奨されます。NLUモデルは通常、生成モデルよりもはるかに高速であり、静的応答は非常に低いレイテンシーで提供できます。

ユーザーがより高い精度や優れたフォーマットを必要とする場合、GPT-4のような生成モデルを使用することが推奨されます。生成モデルはNLUモデルよりも強力であり、より自然で魅力的なテキストを生成できます。ただし、生成モデルはNLUモデルよりもはるかに低速であることに注意することが重要です。

レイテンシーを削減するもう1つの方法は、分散アーキテクチャを使用することです。分散アーキテクチャでは、検索タスクと生成タスクが別々のサーバーで実行されます。これにより、システムは最も要求の厳しいアプリケーションのニーズにも対応できるよう拡張できます。

高性能な検索拡張生成システムを構築する

検索拡張生成（RAG）システムは、検索モデルと生成モデルの強みを組み合わせた、テキスト生成への強力な新しいアプローチです。RAGシステムは、まず知識ベースから関連するパッセージを検索し、次に生成モデルを使用して検索されたパッセージに基づいてテキストを生成することで機能します。

RAGシステムは、質問応答、要約、クリエイティブライティングなど、さまざまなタスクに使用できます。しかし、高性能なRAGシステムを構築することは困難な場合があります。

このブログ記事では、RAGシステムを構築する際に考慮すべきいくつかの主要な要素について説明します。

1. モデルの選択： さまざまな検索モデルと生成モデルが利用可能です。特定のニーズに適したモデルを選択することが重要です。例えば、特定の言語でテキストを生成する必要がある場合は、その言語のテキストでトレーニングされたモデルを選択する必要があります。
2. データの選択： システムのトレーニングに使用するデータの品質は、そのパフォーマンスに大きな影響を与えます。ターゲットタスクに関連し、エラーのないデータを選択することが重要です。
3. ハードウェアの選択： 使用するハードウェアも、システムのパフォーマンスに大きな影響を与えます。例えば、GPUを使用すると、検索タスクと生成タスクを大幅に高速化できます。
4. システムアーキテクチャ： RAGシステムはさまざまな方法で実装できます。特定のニーズに適したシステムアーキテクチャを選択することが重要です。例えば、システムを本番環境にデプロイする必要がある場合は、スケーラブルで信頼性の高いアーキテクチャを選択する必要があります。

上記の要素に加えて、RAGシステムは複雑であり、一般化が難しいことにも留意することが重要です。各ユーザーのドメインとユースケースは異なるため、ユーザーが独自のプロンプト、処理、チャンキング戦略をテストできる機能を提供することが重要です。これにより、ユーザーは特定のニーズに合わせてシステムをカスタマイズできます。

TrueFoundryでRAGアーキテクチャをデプロイする方法については、こちらをご覧ください。

‍

LLM-powered QA Chatbot on your data in your Cloud

Productionize a question-answering bot on your data in your cloud environment using open source LLMs using RAG (Retrieval-Augmented Generation).

TrueFoundry Blog TrueFoundry

‍

生成AIへの移行：課題と機会

従来の方式でNLPベースのソリューションを構築してきた企業は、現在、生成AIへの移行という課題に直面しています。GPT-4やLaMDAのような生成AIモデルは、テキスト生成、言語翻訳、包括的かつ情報量の多い方法での質問応答など、従来の方式に比べて多くの利点を提供します。しかし、生成AIへの移行にはいくつかの課題も伴います。

課題の一つは、生成AIモデルがまだ開発途上であり、利用コストが高いことです。さらに、プロンプトの概念はまだかなり曖昧で、難しいものです。企業は、生成AIモデルを最大限に活用するために、効果的なプロンプト技術を開発できる必要があります。

もう一つの課題は、生成AIモデルを既存のインフラに統合することです。企業は、自社のシステムが生成AIモデルの負荷増大と複雑さに対応できることを確認する必要があります。

課題がある一方で、生成AIへの移行には多くの機会も伴います。生成AIモデルは、企業が製品やサービスの品質を向上させ、タスクを自動化し、新しい製品やサービスを生み出すのに役立ちます。

生成AIへの移行を検討している企業向けのヒントをいくつかご紹介します。

1. まず、自社のニーズを評価することから始めましょう。 生成AIモデルに実行させたい具体的なタスクは何ですか？予算の制約はありますか？ニーズをしっかり把握できれば、自社のユースケースに合った生成AIモデルを特定し始めることができます。
2. さまざまなモデルや技術を試しましょう。 生成AIへの移行に万能なアプローチはありません。企業は、自社に最適なものを見つけるために、さまざまなモデルや技術を試す必要があります。
3. 生成AIモデルを既存のインフラに統合しましょう。 企業は、自社のシステムが生成AIモデルの負荷増大と複雑さに対応できることを確認する必要があります。これには、インフラの拡張やソフトウェアの変更が必要になる場合があります。
4. スタッフをトレーニングしましょう。 生成AIモデルは強力なツールですが、使いこなすには複雑な面もあります。企業は、生成AIモデルを効果的に使用する方法についてスタッフをトレーニングする必要があります。

生成AIへの移行は課題となり得ますが、企業が製品やサービスを改善し、新しい製品やサービスを生み出す機会でもあります。上記のヒントに従うことで、企業は生成AIへの移行を可能な限りスムーズかつ成功裏に進めることができます。

TrueMLシリーズの過去のブログを読む

‍

True ML Talks #20 - Transformers, Embedding, LLMS @ Turnitin

Deep dive into a new way of thinking about Transformers and LLMs, via Embeddings . We talk with Sumeet, Distinguished ML Scientist @ Turnitin.

TrueFoundry Blog TrueFoundry

‍

TrueMLを引き続きご覧ください YouTubeシリーズ そして、すべてのTrueMLを読んでください ブログシリーズ.

TrueFoundry は、Kubernetes上で動作するMLデプロイメントPaaSであり、開発者のワークフローを加速させるとともに、モデルのテストとデプロイにおいて完全な柔軟性を提供し、インフラチームには完全なセキュリティと制御を保証します。当社のプラットフォームを通じて、機械学習チームが デプロイおよび監視する モデルを15分で、100%の信頼性、スケーラビリティ、そして数秒でのロールバック機能を備えて行えるようにします。これにより、コストを削減し、モデルをより迅速に本番環境にリリースできるようになり、真のビジネス価値の実現を可能にします。