機械学習（ML）は、現代のビジネスが成長し、競争力を維持するための最も重要な機能の1つになっています。内部プロセスの自動化から、消費されるほぼすべての製品の背後にある設計、作成、マーケティングプロセスの最適化まで、MLモデルは、私たちの仕事や個人的な生活のほぼすべての側面に浸透してきました。 MLをコアコンピテンシーとして採用しないと、次の市場リーダーを定義する大きな競争上の不利益が生じます。
このため、ビジネスおよびテクノロジーのリーダーは、組織全体にMLモデルを実装し、幅広いユースケースにまたがる必要があります。ただし、この緊急性の感覚は、規制の精査の高まりと相まって、現在管理が困難な新しい独自のガバナンスの課題を生み出しています。例：私のモデルは、エンドカスタマーに提供されるサービスにどのように影響しますか？私はまだ政府と内部の両方の規制に準拠していますか？セキュリティルールは本番環境のモデルにどのように変換されますか？
規制や法的な懸念以外にも、機械学習のガバナンスプロセスと手順を採用する理由はいくつかあります。例としては、生産性を向上させる方法（モデルや機能などの資産を再利用するなど）、さまざまなビジネスラインにわたってモデルを制御および維持して、ビジネスクリティカルなアプリケーションが意図したとおりに動作するようにする（またはそうでないものを見つける）方法があります。 、および廃止された資産を含むモデルと予測の履歴を確認します。
これらの課題に取り組む際には、どのモデルと機能が概念的にあるかを定義する価値があります（図1を参照）。多くの異なる定義が存在しますが、一般に、モデルは、入力データから計算された特徴を取り、予測（またはスコア）とメタデータを生成する自己完結型のパッケージです。このパッケージにはさまざまな形式がありますが、常に数学的な表現、コード、ビジネスロジック、トレーニングデータが含まれています。モデルの予測は、システムまたはユーザーによってダウンストリームで消費されます。
多くの企業は、さまざまなサイズと成熟度でMLモデルインフラストラクチャを運用しているため、モデルの管理に役立つツールが必要です。最終的に、MLガバナンスのニーズは、次の主要な領域に抽出できます。モデルの説明可能性、解釈可能性、および再現性。
図1
チーム内および組織全体でのモデルと機能の可視性
モデルガバナンスの基本的な要件は、チームが組織で機械学習がどのように適用されているかを理解できるようにすることです。これには、モデルと機能の正規のカタログが必要です。このようなカタログがない場合、多くの組織は、モデルと機能、展開場所、実行内容などを認識していません。これにより、やり直し、モデルの不整合、機能の再計算、およびその他の非効率性が発生します。
モデルの説明可能性、解釈可能性、および再現性
モデルはブラックボックスと見なされることがよくあります。データが入り、何かが起こり、予測が出てきます。この非透明性は多くのレベルで挑戦的であり、多くの場合、次のような大まかに関連する用語で表されます。
- 説明性 ：人間の言葉でのMLモデルの内部力学の説明
- 解釈可能性 ：a）モデルの入力、機能、出力の関係を理解し、b）入力の変化に対する応答を予測する機能。
- 再現性 ：同じ入力に対して一貫した方法でモデルの出力を再現する機能。
これらはすべて、ソースデータへの関連付け、コードやトレーニングデータなどのモデルの内部の明確な理解、モデル自体を調査および分析するための他の方法など、共通の機能を必要とします。
例を含むモデルメタデータ
上で定義したガバナンスの問題に対処するために、例について考えることから始めましょう。フードデリバリーのウェブサイトを考えてみましょう。同社は、機械学習を活用して納期を見積もることを望んでいます。
トレーニングデータセットは、過去に行われた各配信の配信時間を含む、以前の配信からのイベントログで構成されます。このデータは、将来の納期を推定するためのモデルのトレーニングに使用されます。
イベントログは次のようになります。
午前10時に、loc1から食べ物を受け取り、loc2に配達するように注文しました。宅配便業者は、午前10時15分にレストランから受け取り、午前10時55分に配達しました。注文から配達まで、合計55分かかりました。
loc1とloc2が番地であると想定します。短くて読みやすいように、ここでは省略しています。
イベントログはHBaseに保存されます。モデル開発のエンジニアリングアーキテクチャは次のとおりです。
- データエンジニアは、問題の解決に使用されるイベントログの時間枠を特定します。識別された時間枠で生のイベントログを解析することにより、新しい構造化されたHiveテーブルが作成されます。
- 機能エンジニア（これはデータサイエンティストまたはMLエンジニア内の役割である可能性があります）は、新しい機能を特定して開発します。
- ラッシュアワー機能：場所と時間を指定してラッシュアワーの状態が存在するかどうかを識別する機能。
- レストランの「忙しさ」機能：履歴データに基づいて、特定のレストランで待ち時間が長いかどうかを識別する機能。この履歴データは個別に収集されます。
- 上記で特定された機能は、再利用のためにPythonライブラリとして構築されます。
- このライブラリは、構造化されたHiveテーブルに関数を適用して、最終的なトレーニングデータセットとなる新しいテーブルを作成するために使用されます。新しいテーブルの行は次のようになります：
loc1とloc2が番地であると想定します。短くて読みやすいように、ここでは省略しています。
- データサイエンティストは、トレーニングデータセットに対して線形回帰を実行して、配信時間を予測します。この時点で、トレーニングデータセットの特徴を抽出するために使用されたものと同じ特徴ライブラリを使用する必要があります。
- モデルは、配信時間を予測するためにWebアプリケーションで使用されるFunction-as-a-Service（FaaS）エンドポイントとしてデプロイされます。
モデルは、予測のためにリアルタイムで特徴を計算する必要があることに注意してください。これらの機能は、モデルによって内部的に使用されるライブラリです。この例で実行されたさまざまなアクティビティと生成されたアーティファクトの視覚化は、次のようになります。
青いボックスは、コード、プロジェクト、ビルド、デプロイメントなどのMLエンティティ（名詞）を表します。緑のボックスは、エンティティに作用して他のエンティティを生成するプロセス（動詞）を表します。
データの構造の変換を定義する視覚化と関係は、まとめて系統と呼ばれます。 。データベースの世界では、テーブルに新しい列を追加すると、その系統が変更されます。機械学習の世界では、機能とデータセットを使用してモデルを再トレーニングすると、系統が変更されます。フードデリバリーのウェブサイトでは、「トレーニング中の特徴抽出とスコアリングに違いはありますか」という質問に答えるために、系統情報が必要です。これは、機械学習の世界における系統メタデータの有用性の一例にすぎません。
ガバナンスツールとしてのApacheAtlas
データセットのトレーニングからモデルの展開まで、MLワークフローの完全なエンドツーエンドの系統を構築することが、特定されたガバナンスの問題に対処するための重要な要件になることは明らかです。データ管理と機械学習の統合により、説明可能性、解釈可能性、および再現性が実現する必要があります。
MLメタデータの収集、保存、および視覚化には、標準のバックエンドソフトウェアシステムが必要です。オープンで拡張可能なメタデータ定義により、モデルが開発または提供される場所に関係なく、ガバナンス操作の標準化が可能になります。 Cloudera（および当社の顧客）の明白な候補はApacheAtlasです。
Apache Atlasは、データ管理用に事前定義されたメタデータタイプを備えた、広く使用されているガバナンスツールのセットです。 MLガバナンスのコンテキストでは、機械学習の概念に必要なメタデータを定義およびキャプチャするのに適しています。さらに、Apache Atlasは、分類、Apache Rangerとの統合（承認とタグ付け用）などの高度な機能を提供し、コミュニティが協力してML内の他のさまざまなツールへの統合を段階的に定義できる拡張可能なアドオンシステムを備えています。スペース。読者がApacheAtlasのUIを調べ、これらの機能の使用方法を確認するための演習として残されています。
ApacheAtlasでのMLメタデータ定義
Apache Atlas型システムは、MLメタデータオブジェクトを定義するためのすべてのニーズに適合します。オープンソースで拡張可能であり、事前に構築されたガバナンス機能を備えています。 Atlasのタイプは、特定のタイプのメタデータオブジェクトがどのように保存およびアクセスされるかを定義したものです。また、メタデータオブジェクトのプロパティを定義する1つ以上の属性を表します。 MLガバナンスの場合、Atlas Type Systemを使用して新しいタイプを定義し、MLエンティティとプロセスをAtlasメタデータオブジェクトとしてキャプチャできます。タイプの定義に加えて、エンドツーエンドの系統フローを視覚化するには、エンティティとプロセスの関係も必要です。
これを前述の食品配達ウェブサイトの例に関連付けると、アトラス型システムは機械学習の系統を定義するための優れた基盤を提供します。一般化されたML系統システムは次のように視覚化されます：
上の図から明らかなように、機械学習のメタデータ定義は、実際の機械学習ワークフローに厳密に従っています。トレーニングデータセットは、モデル系統フローの開始点です。これらのデータセットは、データウェアハウスまたは埋め込みcsvファイルのテーブルにすることができます。データセットが特定されると、系統はモデルのトレーニング、構築、展開に続きます。
ML機能開発は、機能エンジニアリング（モデルエンジニアリングとは異なります）と呼ぶことができる並行した特殊なアクティビティです。今日、多くの場合、2つのアクティビティ（モデルエンジニアリングと特徴エンジニアリング）は同じ人またはチームによって実行されます。機能の民主化と工業化により、これは将来、モデル開発と機能開発に特化したチームによって変わる可能性があります。
ML型システムは、次の新しい型を使用して定義できるようになりました。
「機械学習プロジェクトの作成」と「機械学習プロジェクト」
単一の機械学習プロジェクトは、単一のビジネスユースケースを表します。機械学習プロジェクトは、ファイルやその他の埋め込みアセットのコンテナを表します。少なくとも、プロジェクトのメタデータには次のものが含まれます。
- モデルで使用されているファイルのリスト
- すべてのファイルの履歴バージョン
- 最も簡単な実装は、すべてのファイルの履歴を維持するためにGitに依存するgitリポジトリとしてプロジェクトを維持することです。
「トレーニングデータセット」
トレーニングデータセットを表すAtlasのDataSetのサブタイプ。トレーニングデータセットエンティティは、モデルトレーニングプロセスで使用されます。生成されたデータが特徴抽出（または変換）を別のデータセットに適用した結果である場合は、特徴に関連付けることができます。
「トレーニングとビルド」
モデルのトレーニングと構築のアクションを表すプロセス。実験の実行、調整、およびトレーニングアルゴリズムの選択の最終決定が含まれます。トレーニングおよびビルドプロセスは、オプションで機能ビルドの出力を消費する可能性があります。たとえば、モデルによって内部的に使用される特徴抽出を定義するライブラリ関数。
「モデルビルド」
データサイエンティストがモデルの実験とトレーニングを完了すると、モデルは強化され、バージョン管理されます。この処理により、モデルビルドが生成されます。これは、モデルを生成するためのビルディングブロックを形成する不変のアーティファクトです。 Dockerイメージは、モデルビルドエンティティの例です。
「モデルの展開」と「モデルの展開」
モデルビルドは、モデル展開を作成する展開プロセスを通過します。モデル展開は、モデルのアクティブなインスタンス化を表します。 KubernetesベースのRESTサービス（FaaSスタイルのデプロイ）は、モデルデプロイメントエンティティの例です。
「機能機能」
機械学習機能には、1）機能関数と2）変換されたデータセットの2つの解釈があります。
機能関数エンティティは、入力から識別された機能を抽出する方法を定義するカスタム関数（コードで表現）です。これは、MLプロジェクトがMLコードのコンテナを表す方法と同様に、機能のコードを表します。
機能関数は、最初にライブラリとしてパッケージ化されます（バージョン管理および強化）。次に、ライブラリが消費され、特定のDataSetに適用されて、新しいDataSetに変換されます（機能が抽出されます）。変換されたデータセットは、上記で定義されたトレーニングデータセットエンティティによって表されます。
「パッケージ機能」と「機能ビルド」
機能関数のコードは、（他のモデルとの）共有または実行時のスコアリングのためにパッケージ化されています。これらのパッケージは、機能ビルドと呼ばれます。たとえば、機能ビルドには、パッケージ化されたライブラリ（Pythonの場合）またはjarファイル（Javaの場合）が含まれる場合があります。このパッケージは、モデルのトレーニングおよびビルドプロセス中に吸収され、抽出および予測中に同じ機能が使用されるようにすることができます。
MLメタデータ定義の将来の定義を試して参加してください
Cloudera Data Science Workbench（CDSW）をパイロットクライアントとして活用した機械学習型システムの最初の実装であるATLAS-3432の作業を開始しました。 CDSW統合の構築作業を主導してくれたClouderaエンジニアリングチームのNaLiに感謝します。 ATLAS-3432を使用すると、CDSWインスタンスのモデルメタデータをApache Atlasインスタンスにプッシュして、系統を探索できます。 CDSWは現在、機能（または機能ストア）をサポートしていないため、機能に関連する系統は利用できなくなります。
Clouderaでは、お客様のためにこの問題を単純に解決したくはありません。MLメタデータ定義は、テーブルや列などがデータ構造の非常に標準的な方法と同様に、普遍的である必要があると考えています。コミュニティがこの標準の定義に貢献し、企業がMLプラットフォームを最大限に活用できるようになることを願っています。
メタデータモデルに適合しない機械学習ガバナンスのユースケースはありますか？ [email protected]に提案を投稿して、会話に参加してください。