リアルワールドのMLOpsの例：Brainlyでのビジュアル検索のためのエンドツーエンドのMLOpsパイプライン
'Brainlyにおけるビジュアル検索のためのMLOpsパイプラインの例'
Brainlyのビジュアルサーチチームにおけるエンドツーエンドの機械学習オペレーション（MLOps）プロセスをご紹介します。テクノロジーやプロセスだけではMLOpsの成功には足りないため、以下の詳細も共有します：
-
1
Brainlyの機械学習のユースケース、 -
2
MLOpsの文化、 -
3
チーム構成、 -
4
およびBrainlyがAIサービスを提供するために使用する技術、
記事をお楽しみください！
免責事項：この記事は主にBrainlyの本番の機械学習チームの設定に焦点を当てています。
会社概要
Brainlyは、全ての学校の科目と学年に対する最も広範な知識ベースを持つ、世界中で最も多く利用されている学習プラットフォームです。何億人もの生徒、保護者、教師が毎月Brainlyを利用しており、それは彼らが理解し、より速く学ぶための証明された方法です。Brainlyの学習者は35以上の国から来ています。
BrainlyにおけるMLOpsの動機
BrainlyがMLOpsに向けての道のりを理解するには、BrainlyがAIと機械学習技術を採用する動機を知る必要があります。この執筆時点で、Brainlyは世界中で数億人の月間利用者を抱えています。その規模の活発な月間利用者とそのユースケースの数から、MLアプリケーションはBrainlyの教育リソースを活用し、学習スキルと経路を向上させるためにユーザーに大きな利益をもたらすことができます。
Brainlyの主力製品は、ユーザーが以下の方法で任意の学校の科目に関する質問をすることができるコミュニティのQ&Aプラットフォームです：
- タイピング
- 質問の写真を撮影
- 音声で質問
ユーザーが入力すると、製品はステップバイステップの説明付きで回答を提供します。もし回答がすでに知識ベースにない場合、Brainlyはコミュニティメンバーの一人に回答を依頼します。
「Brainlyでは、教育機能を向上させ、次のレベルに引き上げるためにAIベースのサービスを構築しています。これがAI関連の研究の驚異的な成長を活用する背後にある主な理由です。」
— Paweł Pęczek, Brainlyの機械学習エンジニア
BrainlyのAIおよびテクノロジーチームは、機械学習を使用して学習者に対してパーソナライズされたリアルタイムの学習支援と世界最高の教育製品へのアクセスを提供しています。BrainlyのAI/MLチームの目標は以下の通りです：
- ユーザーの体験をパーソナライズする反応型から予測型の介入システムへの移行
- 将来の教育の困難を事前に解決
- 学生の学習パスをより成功させる
BrainlyのMLストーリーについては、この記事をご覧ください。
Brainlyにおける機械学習のユースケース
BrainlyのAI部門は、ユーザー向けの予測型介入システムの構築を目指しています。そのようなシステムに向けて、以下のドメインに関する複数のユースケースに取り組んでいます：
- コンテンツ：コンテンツの属性（品質属性など）の抽出やメタデータの充実（カリキュラムリソースのマッチングなど）
- ユーザー：ユーザーの学習プロファイルの向上
- ビジュアルサーチ：画像の解析およびカメラの写真を質問に変換
- カリキュラム：ユーザーセッションと学習パターンの分析による推薦システムの構築
これらのドメインで作業する各チームのMLOpsの実践について詳細を説明することは困難ですので、本記事ではビジュアルサーチAIチームが実際のMLOpsをどのように行っているかについて学びます。
コンテンツAIチームがMLOpsを行う方法については、このビデオをご覧ください。
「Brainlyのサービスの利用者が検索クエリをどのように作成するかを考えると、利用しやすい入力方法に偏っていることがわかるでしょう。これにはビジュアルサーチだけでなく、AIで探索可能な特別な種類の信号を持つ音声やテキスト検索も含まれます。」
— Paweł Pęczek, Brainlyの機械学習エンジニア
MLOpsチームの構造
Brainlyのテクノロジーチームは、プロダクトチームとインフラストラクチャチームに分かれています。インフラストラクチャチームはテクノロジーに焦点を当て、他のチームが主要な成果物に取り組むために適応して使用するツールを提供します。
チームの上には部門もあります。DevOpsとAutomation Opsの部門はインフラストラクチャチームの下にあります。AI/MLチームはインフラストラクチャチームの下のサービス部門にありますが、AIに関連しており、一部のAIチームはクライアントが利用できるMLベースのソリューションに取り組んでいます。
AI部門の基盤として、MLインフラストラクチャチームがあります。このチームはAIチームが適応できるように、標準化されたソリューションを提供します。MLインフラストラクチャチームは、各チームが独自の環境に自律的に展開できるように、インフラストラクチャとしてのコード形式のテンプレートソリューションを提供することで、AIチームがトレーニングパイプラインを簡単に作成できるようにします。
複数のAIチームもMLインフラストラクチャの取り組みに貢献しています。これは、メンテナンスしているツールに取り組むすべての人が関与する内部オープンソースシステムに似ています。
「プロダクトチーム、インフラストラクチャチームがさまざまな部門に分かれ、製品に公開される特定の技術要素に取り組む内部チームがあるというこのチームのセットアップは、大手テック企業ではかなり一般的です。」
— Paweł Pęczek、Brainlyの機械学習エンジニア
BrainlyのMLOps文化
BrainlyのMLOps文化の背後にある2つの主要な哲学は次のとおりです：
-
1
速度を優先する -
2
協業、コミュニケーション、信頼の育成
速度を優先する
「私たちの究極の目標は、チームにとって再利用可能なすべての基盤関連コンポーネントを可能にすることです。私たちの究極の目標は、チームが探求し実験する方法を提供し、何か興味深いものを見つけたらそれをできるだけ早くクライアントのユースケースに展開することです。」
— Paweł Pęczek、Brainlyの機械学習エンジニア
MLOpsエコシステムの目標は、できるだけ迅速に移動し、時間の経過とともに自動化されたコンポーネントの構築方法を学ぶことです。Brainlyは、AI部門の下にあるインフラストラクチャチームの傘下で共通の取り組みを持っています。これらの取り組みにより、チームは主要な成果物に集中することでより速く成長することができます。
「一般的には、モデルを実世界のトラフィックに公開するために可能な限り速くなるようにしています。それがなければ、フィードバックループは長すぎてワークフローに悪影響を与えます。チームの視点からも、フィードバックはできるだけ即座にほしいのが普通です。できれば、早ければ早いほど良いです。さもないと、モデルの改善プロセスが時間がかかりすぎます。」
— Paweł Pęczek、Brainlyの機械学習エンジニア
速度を優先することによる効果：チームが1つのモデルを本番環境に展開するのにどれくらい時間がかかりますか？
初期の段階では、標準化の取り組みを始めたばかりで、各チームがさまざまな内部基準とワークフローを持っていたため、1つのモデルを本番環境に展開するのに数ヶ月かかりました。チーム間でワークフローが標準化され、データが適切な形式に整えられると、ほとんどのチームは通常、数週間以内にモデルを展開し、サービスとして組み込む準備が整っています（もちろん、研究がうまくいく場合です）。
「最初の段階で最も時間がかかるのは、意味のあるデータの収集とデータのラベリングです。もし研究が完全に新しいもので、他のプロジェクトから結論を導き出すか、理解を基にするための他のプロジェクトがない場合、実現可能性の検討と研究には少し時間がかかるかもしれません。
チームがデータを持っており、すぐにラベリングを開始できる場合、実験プロセスの設定やMLパイプラインの構築はスムーズで効率的に行われます。ほぼ瞬時にこれらのプロジェクトに似たコード構造を作成することができます。メンテナンスも非常に簡単です。」
— Paweł Pęczek、Brainlyの機械学習エンジニア
チームが直面した別の課題は、クライアントがソリューションを迅速に採用できるようにエンドポイントインターフェースを構築することでした。最適なインターフェースについて話し合い、合意するには時間がかかります。これは機械学習に限らず、すべての分野で共通の課題です。彼らは効果的な協力とコミュニケーションの文化を育成する必要がありました。
協力、コミュニケーション、信頼の築き方
AI関連のサービスを公開した後、クライアントはそれらを適切に使用し統合する方法を理解する必要があります。これには人間関係の課題があり、AI/MLチームは、単にエンドポイントを提供するだけでなく、ドキュメントや指示なしにソリューションの使用方法を人々に伝えることで、クライアントとの良好な関係を築くよう奨励されています。
BrainlyのMLOpsへの道のり
BrainlyのMLの初期の日々から、インフラストラクチャとエンジニアリングチームは、プロジェクトとコードベースの構造化について最善の方法を使用するようデータサイエンティストと機械学習エンジニアに奨励してきました。
これにより、彼らはすばやく始めることができ、将来的に大きな技術的負債を支払う必要はありません。これらのプラクティスは、「成熟度レベル」の設計図に従ったより成熟したMLOpsワークフローの構築に伴い進化してきました。
「私たちはプロジェクト開発のさまざまな段階間にかなり整理された移行を持っています。私たちはこれらの段階を『成熟度レベル』と呼んでいます。」
— Paweł Pęczek, Brainlyの機械学習エンジニア
彼らが最初に導入したもう一つのプラクティスは、AI/MLチームが純粋な実験から始めることを容易にすることでした。このレベルでは、インフラストラクチャチームは研究者に対してあまり干渉せず、彼らが研究を行いモデルを開発し提供することに集中できるようにしました。
実験の追跡の早期設定はベストプラクティスです
「私たちは研究の将来的な再現性を大幅に助ける重要な要素として、実験の追跡を実験プロセスの初めから有効にしました。」
— Paweł Pęczek, Brainlyの機械学習エンジニア
チームはデータサイエンティストが特別なユースケースのためにコードベースを立ち上げるための研究テンプレートを用意しました。大抵の場合、これらのテンプレートには実験追跡ツールであるneptune.aiと統合するモジュールがすべて含まれています。
彼らはneptune.aiとシームレスに統合し、送信するレポートの観点ですべてがきちんと構造化されており、チームはトレーニング前とトレーニング後の実験を見直し比較することができます。
BrainlyのMLOpsの成熟度レベル
MLOpsレベル0：デモアプリ
実験が有望な結果を生み出した場合、モデルを内部クライアントにすぐに展開します。これは、実験を実行するための自動化と構造化エンジニアリングコードをMVPに公開するフェーズです。
「私たちは既に持っている内部の自動化ツールを使用してモデルのエンドポイントを簡単に表示できるようにしています。これにより、クライアントはサービスを試すことができ、モデルが彼らのニーズに合うかどうかを決定できます。内部的には、このサービスを『デモアプリ』と呼んでいます。」
— Paweł Pęczek, Brainlyの機械学習エンジニア
ワークフローの最初のイテレーションでは、クライアントがモデルの使用によってどのような結果が期待できるかを確認するために、クライアントがコードまたはWeb UI（ユーザーインターフェース）を介して接続できる内部デモアプリケーションを作成しました。これは本番環境での完全な展開ではありませんでした。
「デモアプリの結果に基づいて、クライアントと利害関係者は特定のユースケースを進んだ成熟度レベルに推進するかどうかを決定します。決定が下されると、チームはソリューションの最初の成熟または広範なバージョンである『リリース1』を展開することになります。
私たちが既に持っているものに加えて、自動化されたトレーニングパイプラインを組み立てて、モデルを繰り返しトレーニングしタスクをシームレスに実行します。」
— Paweł Pęczek, Brainlyの機械学習エンジニア
MLOpsレベル1：トレーニングパイプラインを備えた本番展開
実験と展開のためのワークフローが改善され、各チームにとって標準となったことで、新しいデータが到着した際にモデルを再トレーニングする良い手法を確保することに焦点を当てるようになりました。
ユースケースは徐々に進化し、新しいデータの量が急増するにつれて、チームはモデルを完璧にすることや過度な研究をする代わりに、データ中心のAIアプローチに切り替え、データセットの収集とパイプラインへの継続的なプッシュに重点を置くようになりました。
スピードが重要な文化であるため、彼らは自動化ツールを使用して完全な展開を本番環境に送信することを期待されていました。これらのツールを使用することで、次のようなことができます:
- モデルをサービスとして埋め込んでパイプラインをトリガーする
- トレーニング中に見たものと比較してモデルの品質が低下していないことを検証する
「私たちはサービスを本番環境に公開し、監視を可能にして、時間の経過とともに何が起こるかを観察できるようにしています。これを私たちはMLOpsの成熟度レベル1と呼んでいます。」
— ブレインリーの機械学習エンジニア、パヴェウ・ペチェク
このレベルでの作業の目標は、モデルが最高品質であり、開発初期に起こりうる問題を排除することです。また、サービスが実行されている間にデータの分布の変化（データドリフト、コンセプトドリフトなど）を監視し、変化を確認する必要もあります。
MLOpsレベル2：アクティブラーニングループを閉じる
次の成熟度レベルであるMLOpsレベル2に到達する必要がありました。このレベルでは、良好な投資収益率（ROI）を示すか、ステークホルダーのKPIやビジョンに関連する他の理由でアクティブラーニングループを閉じることができるように、モデルをより成熟したレベルに移動します。
彼らは、本番環境からデータを自動的に抽出し、クリーニングし、必要に応じてラベリングサービスに送信することで、より大きくてより良いデータセットを継続的に作成します。これらのデータセットは、既に設定したトレーニングパイプラインに入ります。また、より包括的なモニタリングを実施し、毎日送られるより良いレポートを実装して、すべてが順調であることを確認します。
Visual Searchチームの機械学習ワークフロー
以下は、チームの典型的なMLワークフローの概要です：
- まず、プロデューサーから生データ（イベント、アプリ内のユーザーアクションなど）を開発環境に取り込みます
- 次に、データを操作し、例えば、フィルターを調整して必要な形式にデータを前処理します
- ソリューションの開発度合いに応じて、データセットにラベルを付けたり、トレーニングパイプラインを使用してモデルをトレーニングしたり、研究モデルのままにしたりします
「モデルが完成したら、通常評価します。承認されたら、自動展開パイプラインを開始し、モデルの品質が良好であり、トレーニング中に測定したモデルの品質と同じであることを再確認します。それが事実であれば、単純にサービスを展開し、期待通りに動作していないかを監視します。問題を検証し、改善策を講じます。」
「できるだけ多くのユースケースをこの最終成熟度レベルに持ち込みたいと考えており、アクティブラーニングサイクルを閉じ、すべてが正常かどうかを観察しています。」
— ブレインリーの機械学習エンジニア、パヴェウ・ペチェク
もちろん、ワークフローを完全に閉じるには努力と時間が必要です。また、すべてのアイデアがその成熟度レベルに達するわけではないため、一部のユースケースはその成熟度レベルには達しません。
BrainlyのVisual SearchチームのMLOpsインフラストラクチャとツールスタック
チームのMLOpsインフラストラクチャとツールスタックは、新しいサービスを迅速に提供するのに貢献するさまざまなコンポーネントに分かれています：
-
1
データ -
2
実験とモデルの開発 -
3
モデルのテストと検証 -
4
モデルの展開 -
5
継続的インテグレーションとデリバリー -
6
モニタリング
以下の画像は、チームが使用しているさまざまなコンポーネントとツールの概要を示しています：
各コンポーネントを詳しく見てみましょう。
Brainlyのビジュアルサーチチームのデータインフラストラクチャとツールスタック
「私たちのデータスタックはプロジェクトによって異なります。コンピュータビジョンチームでは、可能な限りシンプルなソリューションを使用しようとしています。データをS3に保存するだけで十分であり、作成されたデータセットを変更できないように権限を設定しています。」
— ブレインリーの機械学習エンジニア、パヴェウ・ペチェク
チームは、生データを抽出し、トレーニングに適した形式で処理するための自動化されたパイプラインを持っています。彼らは、洗練されたツールを使用せずにデータ処理を一般化するように努めています。彼らは、AWSテックスタックと統合するために、Automation Opsチームが既に開発していたものを基盤に構築しました。
チームは、AWS BatchとStep Functionsを使用してバッチ処理とオーケストレーションを実行します。これらのシンプルなソリューションは、Brainlyで最もよく知っている機能に焦点を当てており、サービスの動作方法よりも重視しています。
「現在のアプローチでは目的を達成できますが、非常に詳細または洗練されたとは言えません。他のチームは私たちよりもデータエンジニアリングやETL処理ツールをより多く使用していることを知っていますが、それに比べて私たちはデータセットをキュレーションし処理するためにより直接的なソリューションを使用しています。」
— Paweł Pęczek, Brainlyの機械学習エンジニア
Brainlyのビジュアル検索チームの実験基盤とツールスタック
「実験では可能な限りシンプルな状態を保つようにしています。EC2インスタンスとAWS SageMakerで基本的な設定でトレーニングを実行します。本番パイプラインでは、ステップを追加しますが、SageMakerの使用量が過剰にならないように注意しています。」
— Paweł Pęczek, Brainlyの機械学習エンジニア
目標は、データサイエンティストがEC2マシンやSageMakerで実験を実行し、効率的なワークフローを作成するために、複雑さをできるだけ減らすことです。インフラストラクチャの上には、実験を追跡するneptune.ai以外にはほとんどツールはありません。
チームは、トレーニングモデルのためのライブラリやデータセットの高速かつ効果的な処理のための単純でよく知られた方法など、標準的な技術スタックを使用しています。彼らはこれらのライブラリを組み合わせ、EC2マシンやSageMakerで実行し、実験のメトリクスをneptune.aiに報告します。
「私たちは、科学的なプロセスの見た目に重点を置いています。将来的には、実験プロセスを改善し、よりスムーズでかさばらないものにすることを検討するかもしれません。現時点では問題はありませんし、SageMakerでトレーニングジョブを実行するためのいくつかのソリューションを構築しています。」
— Paweł Pęczek, Brainlyの機械学習エンジニア
彼らは実験のワークフローをシンプルに保つことで、データサイエンティストや研究者が多くのエンジニアリング作業に対処する必要がないようにしています。複雑さが低いことを考えると、彼らにとって驚くほどうまく機能しています。
「また、内部モデルアーキテクチャの研究を行いたくありません。特別な場合を除いては、それを行わないという厳格な要件はありません。一般的に、私たちは私たちが取り組んでいるさまざまな分野（音声、テキスト、ビジョン）から標準的なアーキテクチャー（ConvNetやトランスフォーマベースのアーキテクチャー）を使用します。
私たちは特定のアーキテクチャーにこだわりません。特定の文脈で最も効果的なものを実験し使用します。」
— Paweł Pęczek, Brainlyの機械学習エンジニア
モデル開発フレームワークとライブラリ
コンピュータビジョンチームは主にモデル開発にPyTorchを使用していますが、必ずしも固定されているわけではありません。モデル開発ライブラリが優れており、チームがそれを使用してモデルをトレーニングおよび展開できる場合、それを使用することができます。
「チームごとに実験フレームワークを強制することはありません。誰かがTensorFlowを使用したい場合、使用することができますし、誰かがPyTorchを利用したい場合も可能です。もちろん、特定のチーム内では内部での合意があります。そうでないと、毎日の協力が混乱します。」
— Paweł Pęczek, Brainlyの機械学習エンジニア
ビジュアル検索チームのデプロイメントインフラストラクチャーとツールスタック
チームは、Flaskなどの標準的なデプロイメントツールやTorchServeなどの推論サーバーを使用しています。
「私たちはAutomation Opsが提供するものを使用しています。モデルを取り、EKSでの標準的なサービス提供ソリューションを実装します。私たちの視点からは、既存の自動化ツールを考慮すると、単純に簡単でした。」
— Paweł Pęczek, Brainlyの機械学習エンジニア
彼らはAmazon EKS上で異なる戦略を使用してサービスをデプロイしています。特に、テスト、準備、およびリブネスプローブが正しく設定されている場合、問題が発生した場合にデプロイを回避することができます。彼らはシンプルなデプロイ戦略を使用していますが、必要に応じて将来的に他のより複雑な戦略を検討しています。
ビジュアル検索チームの継続的インテグレーションとデリバリーツールスタック
「私たちは、自動化とパイプラインの構築のためにCI/CDを広範に活用しています。AWSのCI/CDパイプラインツールスタックを広範に活用している領域もあります。」
— Paweł Pęczek、Brainlyの機械学習エンジニア
チームは、CI/CDのためにAutomation Opsチームがすでに提供しているソリューションを使用しています。彼らは数行のTerraformコードで実験コードにCIとCDを追加することができます。トレーニング用のパイプラインに関しては、Terraformモジュールを使用して、パイプラインを初期化し、テストし、テストが合格した場合にSageMaker（パイプライン）にデプロイするCI/CDを作成します。
彼らはGitHubリポジトリに本番とトレーニングのコードベースを持っています。コードを変更するたびに、パイプラインの定義が変更されます。それにより、パイプラインの下にあるDockerイメージが再構築され、定義された順序でパイプラインのステップが実行されます。すべてが更新され、誰でも新しいデータセットに対してトレーニングを実行できます。
モデルが承認されると、モデルレジストリからのシグナルがCI/CDパイプラインによって取り扱われ、モデルの展開プロセスが開始されます。統合テストでは、ホールドアウトデータセットを予測サービスに通してメトリクスが評価段階で計測されたものと一致するかどうかを確認します。
テストが合格した場合、誤った入力標準化や類似のバグによって何も壊れていないことがわかります。すべてが問題なければ、サービスを本番環境にデプロイします。
「AWSが合理的なものを提供している場合、私たちは通常、広範なサードパーティのソリューションを使用しようとはしません。特にAutomation Opsチームが使用できるモジュールを提供している場合です。」
— Paweł Pęczek、Brainlyの機械学習エンジニア
CI/CDパイプラインのモデルテストと承認
「モデルのトレーニング後にモデルをテストし、メトリクスを検証します。純粋なエンジニアリングに関しては、すべてがエンドツーエンドで正常に動作することを確認します。テストセットまたはホールドアウトデータセットをサービスに送り込み、結果が以前と同じであるかどうかを確認します。」
— Paweł Pęczek、Brainlyの機械学習エンジニア
AI/MLチームは、解決策が正常に機能することを確認するために、健全なテストセットを維持する責任を持っています。他のチームについては、特に表形式のMLユースケースでは、データのサブポピュレーションでテストを行うことがあります。
「データサイエンティストや特にMLエンジニアが、彼らのプロジェクトの機能に対するテストを提供する責任を持つ状況は、健全な状況です。彼らは何かに頼る必要はなく、誰かに頼る必要もなく、指をさすことも意見の不一致もありません。彼らはただ仕事を適切に行い、他の人々にそれが正常に機能することを示す必要があります。
私たちにとっては、すべてのパイプラインで完全なテストの標準化を達成することは困難ですが、類似のパイプラインには類似のテストケースがあります。」
— Paweł Pęczek、Brainlyの機械学習エンジニア
彼らのコードのテストには、PyTestを使用して単体テストや統合テストなど、シンプルなツールが使用されています。
「モデルの承認方法は、ユースケースによって異なります。特定のパフォーマンスのしきい値に達した後に自動的に承認することに合意することができるほど、いくつかのユースケースは非常に成熟していると私は考えています。」
— Paweł Pęczek、Brainlyの機械学習エンジニア
ほとんどの場合、ユーザー（機械学習エンジニアまたはデータサイエンティスト）はモデルの検証プロセスに注意を払わなければなりません。プロセスをより一貫性のあるものにするために、特定の品質基準を満たすためにチェックおよび実行する必要がある作業の明確な手順を含んだメンテナンス手引書を作成しました。
メトリクスの検証だけでは十分ではありません。モデルの他の質的な特徴もチェックする必要があります。それが完了し、モデルが比較的問題なければ、承認ボタンを押し、その瞬間から自動化されたCI/CDパイプラインがトリガーされます。
本番環境でのモデルとパイプラインの管理
モデルの管理は、異なるAI/MLチームにとってかなりコンテキスト依存です。たとえば、コンピュータビジョンチームがラベリングが必要な画像データで作業する場合、本番環境でのモデルの管理は別の方法で行われます。
「私たちは、サービスの動作方法、モデルの予測の正確さ、および本番環境で記録されるデータの統計情報の変化について常に注意を払っています。劣化を検出した場合、データをもう少し調査し、問題がある場合は新しいデータセットを収集してラベル付けします。
将来的には、データと監視に関連するさまざまなことが自動的に行われるMLOpsの成熟度レベル2に、より多くのユースケースを推進したいと考えています。」
— Paweł Pęczek、Brainlyの機械学習エンジニア
クライアントは自分たちのKPIを測定することもあり、何か問題があればチームに通知されます。
モデルの監視とガバナンスツール
サービスのパフォーマンスメトリックスを取得するために、チームはGrafanaを使用してモデルの統計情報を観察し、Amazon Elastic Kubernetes Service (Amazon EKS) 上の標準のログとモニタリングソリューションを使用しています。サービスの動作に関する統計情報を追加し、時間系列として利用できるようにするために、Prometheusを使用しています。これにより、新しいダッシュボードの追加、モニタリング、アラートの取得が容易になります。
Automation Opsチームは、モニタリングサービス向けのバンドルを提供しており、既存のエンジニアリングエコシステムに適合するようにスタックをできるだけシンプルにするというチームの決定を正当化しています。
「既に優れたツールを持っている場合、異なるツールへの過度な投資は合理的ではありません。」
— ブレインリーの機械学習エンジニア、Paweł Pęczek氏
モデルのガバナンスの場合、チームは主にGDPRに関心を持ち、データがある程度検閲されることを確認しています。例えば、個人情報がラベラーに漏れたり、不適切なコンテンツがユーザーに提供されたりすることは避けたいと考えています。彼らは自分たちのユースケースの一環としてコンテンツをフィルタリングし、モデレートします。
以上です！Brainlyのテクノロジーエコシステムについて詳しく知りたい場合は、彼らのテクノロジーブログをチェックしてください。
この記事の作成に協力してくれたBrainlyのPaweł Pęczek氏とチームに感謝します！
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
