すべてのデータペルソナのためのMLOpsプラットフォーム – イケアから学んだ教訓

皆さん、おはようございます。 IKEAのエンジニアリングマネージャーのカランです。 基調講演をご覧になった方は、イケアが何をしているのかご存じでしょう。 そして、これは基調講演で 10 分間話したことについて、少し深く掘り下げたセッションです。 では、今日はなぜIKEAにMLOpsのプラットフォームが必要なのかについて議論します。 どのようなデータペルソナが存在するか? つまり、誰のためにプラットフォームを構築しているのか、消費者は誰なのかということです。 次に、コンポーネントについてもう少し深く掘り下げてから、デモを開始します。 私の同僚がデモを見せに来てくれるので、Q&Aの時間が残っていることを願っています。

なぜMLOpsが必要なのか?

イケアは、多くの人々により良い毎日を届けるというビジョンを掲げており、ホームファニッシングのニーズをなくすような製品づくりに日々努めています。 そして、なぜMLOPSのプラットフォームが必要なのかというと、ライフサイクルを加速させる必要があるからです。 基調講演でも、アイデアから制作までのスピードが重要だという議論をしました。 そして、それは競争だけでなく、常に出現しているテクノロジーに追いつくために本当に、本当に必要です。 そして、標準化とコラボレーションは、社内の私たちの多くが同じことをしているということですが、異なる方法で行っています。 また、データサイエンスでは、スケーリングを行う場合は、可能な限り標準化する必要があります。

コラボレーションが不可欠になります。 特定のモデル用に構築したコンポーネントを再利用できる必要がありますが、おそらく同じことができる別のモデルですよね? MLのスケーリングとは、基本的に、エッジにデプロイでき、要素をデプロイでき、単純な分類アルゴリズムをデプロイできることを意味します。 ですから、時系列モデルのようなもの、例えばGenie AIのようなものも対象です。

次に、オブザーバビリティと説明可能なAIが、私たちにとって非常に重要になります。 私たちは、お客様のために正しいことをするために常にお客様のデータを使用することをお客様に約束しています。 また、データを販売したり、悪用したりしないこと。 そのため、説明可能なAIを開発し、セキュリティやコンプライアンスなどにも目を向ける必要があります。 欧州ではAI法が制定される予定で、AIの開発と展開の方法に大きな影響を与える可能性があります。 そして、これらのことが一緒になって、なぜプラットフォームが必要なのか、ということになります。

消費者情勢

次に、消費者の状況、つまりプラットフォームを誰に提供しているのかを見ていきます。 そこで、社内で「では、誰がデータやアルゴリズムを扱うのか」という評価を行いました。 そして、リサーチデータサイエンティストのペルソナの人がいて、このペルソナは、大学から出てきた最新のモデルを使っていますよね? 実験的なものから実際の製品に何かをもたらす方法を模索しています。

次に、ビジネスデータサイエンティストです。 基本的には、ビジネス上の問題をデータの問題に変換し、ビジネスで多くの概念実証を実行し、多くのアイデア出しを行うことを検討します。

次に、シチズンデータサイエンティストです。 これは、マーケットマネージャーやストアマネージャーなど、国内でデータにアクセスできるデータアナリストですが、たとえば、マーケティングキャンペーンの効果や客足を増やす方法などのユースケースを持っています。

そして、エンジニアリングデータサイエンティストと呼ばれる人がいて、このペルソナは、コードを扱う人で、DevOpsとデータサイエンティストの両方の経験があり、本番環境で多くのモデルを持っている人です。

ML ライフサイクル

さて、さらに話を進めると、プラットフォームを構築したコンセプトは設計上ヘッドレスであり、MLライフサイクルのどの部分でもオプションのコンポーネントとして使用できます。 ですから、開発環境を求めに来て、それを持ち去ることができます。 あなたはあなたのマシンでそれを開発し、デプロイするためだけに私たちに来ることができます。 または、ソフトウェアに自分でデプロイし、文字通り私たちと一緒に観察することもできますが、これは監視オブザーバビリティが私たちが処理するコンポーネントであることを意味します。

コンストラクト全体を見ると、MLのライフサイクルが基本的にどのように機能するかを見ており、左側には常にデータがありますよね? つまり、データは、たとえば、市場から、私たちはカタログから、ビジネスデータと運用データの両方から取得できます。 次に、基本的にコードリポジトリ、つまりコードをインポートして操作できるアーティファクトツリーがあります。 実験コンポーネントがあり、基本的にさまざまなモデルを試して、ユース ケースに適したモデルを選択できるようにします。 そのためには、もちろんモデルを構築します。モデルには機能が必要であり、機能は機能ストアから取得されます。 そのため、機能ストアを構築する必要があります。

次に、ブルーグリーン、カナリア、およびそれらすべてをデプロイする方法を含むデプロイジャーニー全体と、データがモデルにヒットしている場所の推論を行います。 そして、オブザーバビリティジャーニーでは、モデルのオブザーバビリティ、パフォーマンス精度、ドリフトなど、入力データや出力データに関してモデルがどのように変化しているかを確認します。 そして、このすべてに管理層があり、データサイエンティストとして、モデルを管理、制御、所有することができます。

開発の話に移りますが、ここでは、たとえば社内で提供されているGitHubのアーティファクトツリーを再利用することについて、あまり意味がありません。 ですから、ここでは何かを発明しているわけではありません。 実験プラットフォームは、基本的にインジェストに注目します。 ML アプライアンスは、実験の追跡、実験の登録、GPU などの大容量コンピューティングへの接続を行うことができる統合開発環境を提供します。 次に、機能ストアがありますが、これは基本的に、特定のモデル用に開発されたすべての機能のリポジトリであり、貢献したり、使用したりすることができます (基本的には、さまざまなモデルで構築されています)。

つまり、機能をいつ廃止するか、いつ新しい機能になるか、どのような状態にあるかなど、機能ライフサイクル管理全体があるということですね。 次に、さまざまな機能とそれらが使用された場所を実際に示すカタログ。 そして、パイプラインは、実験プラットフォームへのデータパイプラインを使用して、機能を再利用または提供できることを意味します。

基調講演では、モデルをソフトウェア層から分離し、さまざまなスタイルでデプロイする必要があるため、多くのコンテナ化と分離の手法を示しました。 たとえば、シャドウ、ブルーグリーン、カナリア、そしてもちろん、モデル CI、CD、バージョン管理などを含むデプロイ パイプライン全体です。 また、モデルテストでは、モデルが結果を出しているか、データサイエンティストが望む結果を得ているかを確認しています。

次に、ガバナンスと監査可能性全体です。 これは非常に新しいことであり、倫理と責任の組織があり、モデルがどのように動作しているかを監査したいと考えています。 モデルなどをデプロイしたり、モデルを開発したりする上で与えられた機能の重要性は何ですか?

次に、推論パイプラインについて見ていきますが、これはすべてを記録するという非常に標準的なものです。 つまり、ログ、ログ、ログ、私たちはそれを信じていますし、それは未来のために必要です。 基本的にデータをさまざまなモデルに渡して、もちろん推論をバッチ処理するタスクオーケストレーター。 つまり、たとえば、在庫のフルフィルメント、供給、または予測のモデルです。 バッチで作業し、たとえば IKEA.com 上にあるモデルのようなリアルタイム推論があります。

そして、2つのコンポーネントを持つオブザーバビリティレイヤー全体があります。 1つは運用監視で、基本的にモデルのパフォーマンスとプラットフォームの可用性、モデルの可用性に焦点を当てています。 次に、ドリフト、外れ値の参照、および再トレーニングパイプラインに焦点をあてたオブザーバビリティレイヤー。

これがオブザーバビリティレイヤーであり、次に自分たちで構築したマネージドレイヤーにたどり着きます。 これは内部設計ライブラリであり、そこにはモデルレジストリがあり、社内にあるすべてのモデルとそれらのモデルのバージョンを一元的に管理して、リモートバージョンを昇格させることができます。 メタデータリポジトリは、モデルモデル、メタデータ、そしてモデルのライフサイクル全体の管理とアクセス管理のためのもので、モデルはプライベート、パブリック、共有可能にすることができ、例えば、公開する代わりに実際に個人と共有することができます。

マネージドレイヤー全体の中には、先ほど説明したフロントエンドであるエクスペリエンスレイヤーがあり、ロールベースのアクセススペースもあり、たとえば、モデルのコストやモデルにヒットしているデータの量などを確認できます。 そしてもちろん、デモでもご覧いただけるさまざまな統合開発環境の種類があり、実際に何を開発したいか、開発環境にはどのような要件が必要かについて、ある種のビュッフェのコンセプトを持つことができます。

次に、データマーケットプレイスのインタラクションでは、データカタログのインタラクションも表示されます。 しかし、基本的には、1 か所に座って、アクセスできる社内のさまざまなデータ ソースをすべて確認し、実際にデータを入れることができます。 その後、ワンクリックでデプロイできます。 コーディングする場所でそれができない場合は、フロントエンドでも同じワンクリックのオブザーバビリティジャーニーで行うことができます。

これらは、私たちが持っているプラットフォームコンポーネントです。 インフラストラクチャはKubernetes上にあります。これはプラットフォームの心臓部です。 そして、コードは基本的にPython Reactであり、その後、私たちが使用している多くのクラウドネイティブツールを移行しました。 そのため、コンテナ化にDockerを多用しています。ARGO CD、KNative、Kafka、Prometheus、そしてMLflow、Seldon Core、Alibi、ZenML、Feast機能ストアなどの機械学習に特化した多くのフレームワーク、そしてこれらすべてを結びつけるIKEAのUXとエンジニアリング全体とCSDパイプラインを使用しています。

エンジニアのハリッシュさんとフェルナンドさんを歓迎します。 Harish はこのアーキテクトであるリード エンジニアであり、Fernando はデモを実行する機械学習エンジニアです。 ようこそ。

ありがとう、カラン。 みなさんおはようございます。 Karan は、MLOps プラットフォームとは何かについての背景を説明してくれたと確信しています。 そのさまざまな構造と、プラットフォームが保持するさまざまなコンポーネントは何ですか? ここでは、簡単な UI のデモにすぐに切り替えますが (詳細は省きます)、これがプラットフォーム MLOps.ikea.com です。

プラットフォームのデモ

これがMLOpsプラットフォームであり、プラットフォームの目的は非常にシンプルです。 今日私が歩いたように、データサイエンティストは何も持ち歩く必要はありません。 彼はアルゴリズムでモデルを作成するというアイデアを持って入ってきて、おそらくそれを念頭に置いているのでしょう。 彼はここに来ます。

彼はここに来ます。開発に行き、開発環境、いわゆるトレーニングラボを入手し、モデル開発用の環境、CPU、GPUなど、PyTorch、Python、Anacondaなどを入手します。 モデル開発キットのソフトウェア コンポーネントを開発します。 モデルを開発し、デプロイし、モデルを登録し、デプロイに来ます。 ここでの目的は、アイデアだけを持って手ぶらで入ってきて、環境を整え、アイデアをプレイに落とし込み、より良いモデルを作り、それをデプロイし、帰ることです。 そして、チーム内の他の誰にでも引き継ぎます。

そのため、インフラストラクチャにアフィニティを取り戻すことはできません。 ブレード、ベアメタルのV1、またはVMV1は、このモデルを開発した私のマシンです。 これは私が別のモデルを開発したマシンです。 私たちは、このようなレガシーな考え方から離れ、インフラストラクチャの抽象化をプラットフォームから完全に取り除いて、単なるSaaSソリューションのように使用しています。 もちろん、GPUやCPUの上にコンテナが与えられています。

しかし、開発に何があるかはすぐに説明します。 つまり、開発は開発環境を手に入れる場所です。 独自のクラウドまたはプラットフォームのクラウドにもデプロイできます。 自分が参加しているプロジェクトを選択し、必要な GitHub アクションを選択して、デモを行いましょう。 Docker.com。 お気に入りのゾーンを選択し、ここから直接GPU環境を取得したり、軽量モデルの開発を行ったりすることもできます。 あらゆるタイプのCPU環境とアニメーションを取得します。 そして、ここでは通常、モデル開発に必要なさまざまなIDEを取得します。 PyTorchでも、Pythonでも、その他でもかまいません。

基本的には、他のさまざまなプラットフォームと必要なソフトウェアパッケージを選択し、[展開]をクリックします。 すぐに [デプロイ] をクリックすると、マシンがすぐに起動し、インストールされている Jupyter ノートブックへのアクセスと、ID に接続してリモート開発を行う手段が得られます。 これもまた開発です。 だから、これは似たようなもので、私がそこに持っていくものは何でも、サービスエリアに戻ってリストされます。 これが以前に作成したインスタンスであるとしましょう。 作成中のマシンのさまざまなステップと、この開発環境のメタデータを実際に確認できました。

さらに、基本的には、これはサービススペースと呼ばれるスペースです。 すべてのモデルはコンテナーに格納され、サービスの下に一覧表示されます。 私が 20を開発したとしましょう、そして私は 20を得るつもりです、そしてそれらのすべてがここにリストされます。 ここは、私のモデル、現在のモデルを登録する場所であり、すべてのモデルガバナンスもサービスエリアに登録されます。

そこで、環境を取得する方法と、実際にモデルをリストする方法を示しました。 何が必要ですか? モデル開発に必要なのは、もちろんデータです。 そこで、データカタログの出番です。 これは、モデル開発で常に問題となっている場所です。 モデル開発に適したデータを見つけるために、モデル開発用の高品質データもあります。 例えば、オンライン決済、分析プラットフォーム、人材データなどです。 データサイエンティストとして、データを見つけるために別の場所に行く必要はなく、データを取得し、抽出変換を行い、それをモデルに読み込んでモデル開発を行う必要はありません。 ここからすぐにデータを取り上げることができ、ここにサンプルデータを示しています。 しかし、利用可能なさまざまなデータスキーマを見ることができます。 それらすべてを選択でき、すぐにクエリを実行できます。 これは、インプリントバックされるモデルに直接使用されます。 そして、それがデータカタログの部分です。

ここで、誰かがモデルを開発したとしましょう。 これは、ラマモデル、ダウンロードされるパブリックモデルである可能性があります。 もしかしたら、ちょっとした微調整が行われているのかもしれません。 しかし、プラットフォームを使用していません。 例えば、彼らがここに来て展開したいとしましょう。 そこで、デプロイの部分の出番です。 コードを持参する必要はありません。 遺物は持ってこなくていい。 ファイルを持ってくる必要はありません。 モデルのデプロイを行うために、これらすべてのもの、つまりコードを含む依存関係パッケージを持ち込む必要はありません。 私が持ってくる必要があるのは、事前に構築され、すべての依存関係マトリックスで設定されているDockerだけです。 モデルパッケージ用にすっきり。 Dockerイメージ内にあるすべてのものをプラットフォームに持ち込むことができます。 そして、ここから、それらは公に推論することができます。 そして、Dockerイメージは基本的にデプロイステージに入り、本番環境のエンドポイントを取得します。 ここにDockerイメージを持ってきます。 終点がわかります。 そして、イングレスポリシーとエグレスポリシーに基づいてエンドユーザーにサービスを提供します。

つまり、これはデプロイメント・スペースです。 これは、開発で見ているものとほとんど同じです。 モデル名をつけました。 そして、XTBoostを使用しているとしましょう。 そして、私はカスタムに行きます。 そして、それは私にDockerイメージを要求します。 画像リンクを提供できます。 そして、モデル名と作成者を名乗って、デプロイを進めます。 この最終結果は、公衆の目の前で展開される終点になります。

そして、それがデプロイです。 そして最後に、フィーチャーストアについて触れたいと思います。 その目的は何ですか? 特徴量ストアは基本的に、モデルによって使用される特徴の一元化されたリポジトリです。 つまり、これは、たとえばモデルAを開発したとしましょう。そして、 100GBのデータのうち、おそらく 100MBを使用しています。 たとえば、年齢、場所、興味の種類 (購入したもの) などの入力を必要とするモデルを開発しているとします。 そして、これら3つの機能、標準抽出を使用し、モデルを開発しました。 しかし、モデル開発が完了した後に、これらの機能がすべて消えるべきではありません。 それはちょうど民主的なデータのようなものです。 それは、モデルの機能を他の人にも共有することです。 そうすれば、モデルを開発する必要がある他の誰かがこれを使って、モデルの私の特徴を見て、再開発を行います。

これは、モデルに関連付けられているすべての機能が何であるかを言うことができる一元化されたスペースです。 つまり、データを持ち歩く必要はありません。 つまり、これはデータのメタデータであり、モデルで使用されるABCDであることを示しています。 また、これは監査中に使用できます。 これは、ビジネス上の話し合い中、数か月中、およびモデルがレビュー段階に入るたびに使用できます。 しかし、これらすべては、私の同僚であるフェルナンドによってバックエンドで詳細に示されます。

ハリシュさん、どうもありがとうございました。 ねえ皆さん。 フェルナンド、私はメディアオフィサーのエンジニアで、コードを書く技術担当者です。 そして、Huawei起亜がこのサービスをどのように使用しているかについてのデモを詳細に示します。 まず、私の場合、私がデータサイエンティストで、モデルをトレーニングしたいとします。 当社が提供する本サービスを利用することができます。 では、最初のステップは何でしょうか?

データラングリング

最初のステップは、必要なデータを決定することです。 データを取得する場合は、カタログから、同僚が示したクエリからデータを取得します。 そこで、この問題に必要なデータをインポートします。 そして、データをインポートします。 パンダのデータフレーズを作成します。 ですから、データサイエンティストである私は、データの中身を理解したら、データに何があるのかを理解しています。 魔法とは何か、数値列、カテゴリ列とは何か、そして特徴量を作成する方法。 または、どの特徴量をモデルに当てはめるかをどのように決定できるか。 これは私が使用する列です。 これは、列に関する統計的な分布です。

次に、データに関する相関関係を作成します。 たとえば、これはタイタニック号のデータセットで、あるデータの確率を評価したいとします。 たとえば、クラス、年齢、家族などに基づく人の生存確率。 たとえば、相関関係を見ると、タイタニック号の最初のクラスが生き残る確率が高いことがわかります。 または、性別に基づいて、女性がより多くの確率を持っています。 今では、データがどのように分布しているかを視覚化するために、いくつかのグラフの作成を開始するのが一般的です。 たとえば、年齢に基づいて、あなたが老人である場合、生き残る確率は低くなりますが、これは正常です。 仮定を立て、検証する必要があるいくつかの仮説を作成します。 これは、データ側の一般的な作業です。

仮定に基づいて、特徴量エンジニアリングから始める時が来ました。 特徴量エンジニアリングとは 特徴エンジニアリングとは、優れたモデルをトレーニングするために必要な重要性に基づいて、新しい特徴を作成、結合、または遅延させることです。 それで、例えば、名前に基づいて、ミスター、ミスなどのタイトルを取ることができることを発見しました。 そのため、これはモデルの最終的な品質に影響を与える可能性があります。 たとえば、このタイトルがサバイバルにどのように影響するかを見ることができます。 そして、ご存じのとおり、AIモデルはテキストを処理できないため、テキストまたはカテゴリ列を整数またはコードエンコーダーに変換する必要がありますが、これは非常に通常のプロセスです。

その後、新しい列を作成しました。 したがって、これは、特徴エンジニアリングプロセスで行ったソリューションに基づく最終的なデータセットになります。 現在、私はこの機能の作成と調査に多くの時間を費やしているので、この機能をAIコミュニティと共有したいと思います。 では、どうすればいいのでしょうか? このデータ フレームをプッシュできます。 データは既に機能ストアにあるため、ここでは行いません。 データが特徴量ストアにある場合、特徴量にデータがあることがわかります。 そして、あなたは私がすでに作成した機能の説明を見ることができます。 これはエンリッチメントされたデータセットです。 そして、このデータセットは、データを必要とするデータサイエンティストと共有できます。

データ共有

では、私が別のデータサイエンティストである場合を想像してみてください。 また、乗客 ID にデータしか含まれていないデータのサブセットがあります。 このデータのサブセットに、他のデータサイエンティストが発見した特徴量をどのように埋めることができますか? これはFISを使用しています。 FISは、機能の復元として使用するオープンソースライブラリです。 そこで、FISに接続するためのクレデンシャルを設定しました。 これが必要な機能とバージョンであることを示します。 そして、入力するデータ フレームが、既に作成したデータのサブセットであることを選択します。

そこで、このブロックを実行します。 また、データのサブセットに基づいて、トレーニング データ セットを埋める方法を確認できます。 FIS には、オフライン機能ストアがあります。 これは、モデルのトレーニングと、推論に使用できるオンライン特徴量の復元に役立ちます。 推論では、最新のデータを使用する必要があるためです。 したがって、これにはしばらく時間がかかります。 BigQuery からデータを読み込みました。 ご覧のとおり、詳細、プロジェクトとは何か、前のブロックにロードした元のデータセットは何か、があります。 そして、この情報を一緒に使用できます。 ご覧のとおり、 が実行されました。 時間標準である乗客IDに基づいて、他のデータサイエンティストが発見した他の特徴をデータセットに入力することができます。 これは、モデルが本番を読み取るのにかかる時間を短縮するために大いに役立ちます (数週間から数か月かかることもあります)。

次に、機能ストアからデータを取得します。 模型を作りたいのですが。 この例では、最適なモデルを検索しません。 分類器にランダムを取りたいと思います—私たちは二項分類の問題にあります。 モデルをもらいました。 二項分類で最も一般的な指標である、精度再現率を採点した場合の精度でデータを検証したいと思います。

このモデルに満足していると仮定して、今度はデプロイします。 どうしたらいいでしょう。 次のステップは、成果物を保存することです。 アーティファクトは、モデルファイルなどのようなものです。 現在、IKEAでは、モデルクラスを作成するための標準的な方法を提供しています。 型にはまったテンプレートを何でも使用できますが、結局のところ、モデル クラスは非常に単純です。 init が必要であり、load が必要であり、predict が必要です。 読み込みでは、アーティファクトをロードし、Googleからダウンロードでき、やりたいことは何でもできます。 predict 関数では、この例では、乗客 ID のみを使用して、特徴量ストアから future を使用して予測を生成する方法を示します。 モデルと共有する必要のあるデータを大幅に削減し、特にWebサイトなどで問題となるレイテンシーを削減します。 これは、乗客IDに基づくIのコードです。 特徴ストアから特徴を取得し、いくつかの予測を生成します。

このモデルクラスは、Dockerファイルにカプセル化する必要があります。 Dockerファイルは非常に単純です。 ここでは Seldon Core を使用します。 Seldon Coreは、モデルを成果物から本番環境に対応したマイクロサービスに変換できるツールです。 Dockerにデプロイしたり、Kubernetesにデプロイしたり、好きなようにデプロイしたりできます。 良い点は、設計上、生存性が得られることです。 つまり、Prometheus を使用して、リアルタイムでグラフを視覚化するなど、モデルを使用してメトリックを取得できます。 たとえば、フォルダーに移動できるなど、ローカルでテストできます。 このクラスをロードし、ローカルでテストできます。 ここでは、例えば、乗客IDのみを用いて、乗客IDのみに基づいて生存確率を算出することができた。 モデリング側は、トレーニングに使用する機能を埋めます。

次に、Dockerイメージのビルドを開始し、そのためにDockerを使用します。 この場合、画像はすでに構築されていますが、ここにコメントがあります。 ビルド、プッシュする必要があり、Dockerを使用してローカルでテストするために実行することもできます。 私たちの場合、IKEAでMLOpsの能力を示したいと思います。 そのため、バックエンドAPIを提供することもできますし、技術者であるあなたも、フロントエンドからモデルをデプロイすることもできます。

モデルのデプロイ

この場合、バックエンドを介してモデルをデプロイし、そこからDockerイメージ、ユーザー、デプロイ、プレパッケージサーバー、必要なハードウェア、レプリカの数を示します。 いつでも多数のクエリを受け取ると、自動的にスケーリングし、レイテンシーを安定させることができます。 例えば、入力データは乗客IDですが、入力例を示すこともできます。

今、私はデプロイしたいと思います。 API を照会すると、このモデルがデプロイされます。 したがって、このモデルにこれがデプロイされることを確認できます。 さて、私の同僚であるハリッシュが、私たちにはモデル空間があることを示しました。 モデルサービスでは、モデルをデプロイするときに導入するすべての入力、乗客IDは何か、出力形式は何か、さらにはフロントエンドを介してリアルタイムでモデルを照会でき、すべての予測をリアルタイムで取得できます。 また、イケアではサービスがとても大切です。 したがって、モデルで何が起こっているのか、誰がモデルを使用しているのか、モデルが受け取っている入力は何か、その入力の出力は何かを知る必要があります。 このアルゴリズムを組み込む計画があるため、データドリフト、リアルタイム、コンセプトドリフト、問題の検出を少し行います。

したがって、今回はモデルをクエリすると、誰がモデルを使用しているか、そのユーザーが送信している入力は何か、モデルによる出力は何かについてのエントリがここに表示されます。 そして、このモデルが受信している総数または数、予測の成功率、レイテンシーに関するグラフが表示されます。 これは、私たちが持っているすべてのモデルに当てはまります。 たとえば、このモデルをチームと共有したい場合は、[設定]をクリックしてユーザーを追加し、このユーザーを追加すると、同僚はモデル空間でこのモデルを視覚化できます。 モデルを変更することもできます。

また、このモデルをアプリケーションで使用したいのですが、どうすればよいですか? さて、予測URLをコピーしてから、コードに移動できます。 もちろん、セキュリティについて話す必要があり、電子メール、モデルを使用している人、データのゲストを送信する必要があります。 ご覧のとおり、モデルはリアルタイムで予測を生成でき、前に示した可観測性を自動的に取得できます。 というわけで、私の側からは以上です。 ありがとうございました。 ご不明な点がございましたら、ご相談の時間があります。 ありがとうございます。

質疑応答

つまり、これが合計スタックです。 したがって、Seldonは主にデプロイを行うパッケージですが、デプロイがシームレスであることを確認するために、多くのクラウドネイティブアプリケーションを導入しています。

MLflow は実験プラットフォームであり、独立したクラスターです。 Argo CDは基本的にCIシリーズを横断的にやっています。 ここに欲しいスケジューラはありますか? 実際、はい、それだけではありません。 GPU部分のスケジューラーのためにそこにいるのではありません。 実際、GPU はトレーニング パワー ピース用の GPU を入手したばかりです。 そのスケジューラーは今のところありません。 つまり、これが 100 GB のデータであるとします。 金曜日の一日の終わりにバッチトレーニングを実行してください。 そのスケジューラーの部分は、まだプラットフォーム上では処理されておらず、コーディングレベルで処理されていますが、開発を行うためのバックログにある部分です。

まずはモデルサイズからだと思います。 つまり、LLMOps、つまりオブザーバビリティはもう少し難しいということです。 モデルのサイズは、通常のモデルよりもはるかに大きくなります。 そこから挑戦が始まると思います。 同じ標準化されたプロセスを使用して、モデルを十分に効率的にパッケージ化してデプロイするにはどうすればよいでしょうか。 そして、それは私たちが完全に解決した問題ではないと言えます。 GenAIモデルやLLMを見ると、 15GB、 16GBモデルのように展開したい場合は、標準モデルと比較して、はるかに大きくなります。 そのため、サイズが大きくなると、GPU にデプロイする必要があり、それもコストがかかり、管理も困難になります。

LLMのその他の課題は何でしたか? ええ、LLMが課題です。 という疑問だったと思います。 つまり、私たちが言いたいのは、それは展開に関連しているということです。 それが彼の問いだったのだと思います。 正規モデル分類バイナリ深層学習モデルのデプロイ。 つまり、デプロイを行うためにSeldonを使用していましたが、まったく正常に機能しています。 課題は、それがLLMモデルである場合に発生し、通常の実行でも非常に巨大なサイズであり、Seldonに展開して戻すことさえできます。 これは、LLMモデルで直面する主要な課題の1つです。 繰り返しになりますが、これはあくまでも課題のためのインフラであり、プラットフォームレベルではありません。

さらなる課題は、LLMOpsに関する彼の質問ですよね? 今のところ、カランが言ったように、私たちはLLMOpsの問題を解決していません。 MLOps プラットフォームは現在、運用モデルの LLMOps に準拠し、適応するためにさらに拡張されています。 今のところ、通常のモデルを取引するのと同じように、一度に1つのLLMモデルを展開しています。 しかし、LLMOps間のマルチモーダルオーケストレーションですよね? これはまだ発見されていない、または未解決の問題であり、すべてのMLOpsプラットフォームがLLMOpsをサポートするサブソートを行うことが期待されています。 右。 それが答えです。 はい。

他に質問はありますか? これらの非常に有用な事前トレーニング済みモデルが導入されてから、プロセスはどのように変化しましたか?

ある意味、データサイエンティストを回り道に立たせたようなものです。 これは、私たちの側からの実際の観察です。 すべてのChatGPTが入ってくると、誰もがそこに回り道をして使い始め、それからレイテンシーの問題が発生し始めましたよね? これも最大のハードルの1つになっています。 今では、エンタープライズ向けChatGPTの入手も開始しており、エンタープライズクラウドとしてもOpenAIとなっています。 これで問題の一部は解決しましたが、それでも、モデルから取得したかった遠い結果ではなく、モデルからトップレベルの結果が得られると考えています。 そこで、私たちは寄り道を始めました。 つまり、私たちは「それは非常に良い研究だ」と言いました。 事前にトレーニングされたモデルを使用して実際に回り道をしましたが、1つのサイズでは収まりません。 そこで、私たちは独自のLLMモデルを導入し、消費者向けに合理化された非常にカスタマイズされた回答結果を提供するために、社内でトレーニングを開始しました。 ですから、そのようにして、私たちもブラックボックスの視点に立ち入ることはありません。 ですから、なぜこの答えを消費者に言ったのか、いつでも説明することができますよね? また、監査可能性も重要です。 だから、それが今私たちがとった回り道です。

オープンソースモデル

私たちはオープンソースモデルを選びました。 OpenAIとChatGPTはクローズドモデルだと言った方が適切だと思います。 あなたはそれを使って多くのことができることがわかりますが、それはオープンソースではありません。 オープンソースモデルでは、モデルがどのように開発され、何に基づいてトレーニングされたかについて、より多くの情報を利用できます。 ですから、説明可能性を本質的にどのように全体像に持ち込むかを検討する必要がありますよね? そして、それはAI法で将来的に求められるもので、モデルは非常に高いリスク、高いリスク、中程度のリスク、低いリスクに分類されます。 そして、顧客志向やマーケティング志向のモデルの多くが、高リスクのカテゴリーに分類されることがわかります。 例えば、マルチモデルLLMの設定で買い物支援の旅をしていて、予測に何か問題があり、モデルが幻覚を見始めたとしたら、その時こそコントロールが必要になります。 そんなときこそ、何を使用しているのか、なぜ使っているのかを正当化できる必要があります。 そのため、現在のアプローチは、オープンソースモデルを検討して、お客様に送信する内容をより細かく制御することです。

では、私たちがよく使う特定のモデルは何ですか? 基本的に、マルチモデル設定で見ると、Llama、たとえばBardのようなクローズドソースが1つでも使用されます。 繰り返しになりますが、私たちはプラットフォームなので、さまざまなデータサイエンティストや任意のチームが独自のモデルを使用できるようにしています。 また、ラマやその他のモデルでも機能が見られますが、データサイエンティストによってもすぐに使用されています。 彼らには独自の自律性があります。

まさにその通りで、その理由とは別に、ユーザーが何を使っていても、その目的を実現するプラットフォームが必要です。 それがモットーだと思いますよね。 つまり、ペルソナの作品も最初に見たということですね。 モデルをデプロイできるようにしたいデータアナリストがいるかもしれませんし、調査から最新のモデルを知っている経験豊富なデータサイエンティストがあなたと一緒に仕事をするかもしれません。 それよりも、プラットフォームとして、これらすべてのペルソナに可能な限り最善の方法で提供し、価値を提供できるようにすることが私たちの役目です。

何を使って拡大していますか? つまり、私たちはプラットフォームであり、会社が提供するプラットフォームを使用しているため、マネージドGKクラスターを提供するチームがあり、それらを使用し、スケーリング要件が満たされていることを確認する責任があります。 つまり、私たちはチームとして働くということですね。 つまり、私はスタック全体を所有しているわけではなく、スタックの一部を所有しており、多くの人から提供されたスタックを再利用しています。

さらに付け加えると、このプラットフォームレイヤーからのスケーリングも3つの方法で行われます。 つまり、スケールアウトはGoogleで行われているということです。 マネージドGKもリソースです。 また、消費者に公平な自律性と呼べるものを与えようとしています。 そして、顧客は選択することができますよね? Googleに入れて何かを費やすのではなく、OpenShiftにスケールバックしてクラスタに戻すか、専用のクラスタを取得させてください。 つまり、プラットフォームの消費者は、Googleでさらにスケールバックするか、オンプレミスに戻すかを選択し、モデルのサイズ、多くの影響要因、トラフィック、そしてもちろん最終的にはコストに基づいて判断を下します。 そのため、これらすべての異なるパラメーターに基づいて、スケーリングする場所を決定します。 しかし、繰り返しになりますが、あなたのポイントに対する率直な答えは、Zmanagedを使用してクラスター部分のスケーリングを行うことです。

さて、聞いてくれてありがとう。 ありがとうございます。

さらに詳しく

• IKEA Retailが効率的な機械学習モデルの導入のためにDockerイメージを標準化した方法
• Docker は初めてですか? さっそく始めましょう。
• Docker デスクトップの最新リリースを入手します。
• 質問がありますか? Docker コミュニティがお手伝いします。