ブラックテクノロジー：AoE-モデルをうまく管理するには？

序文

今後ますます多くの企業が AI 関連のテクノロジーを利用するようになるでしょう。ほとんどの AI モデルはクラウドに展開されています。結局のところ、サーバー側の計算の方が高速で、管理も簡単です。端末デバイスのパフォーマンスが向上するにつれて、端末での AI モデルの使用価値が高まり、リアルタイム応答とデータプライバシーに対するビジネスニーズをより適切に満たすことができます。 Didi Chuxing の銀行カード認識機能もクライアントに導入される予定ですが、これも多くの問題に直面しています。

1. モデルアップグレードが困難。端末のモデルは通常、アプリケーションソフトウェアによって実行されます。ユーザーはアプリケーションソフトウェアを更新するかどうかを選択できるため、モデルバージョンの差別化につながります。

2. ハードウェアの適応の問題。メーカーによる高度なカスタマイズにより、端末デバイスによって互換性の問題が発生する可能性があります。

3. モデルごとに実行フレームワークが異なるため、クライアント エンジニアにとって使いやすくありません。

これらの問題に対応するため、Didiの端末インテリジェンスチームはソリューションとしてAoEを立ち上げました。設計当初から、マルチモデル管理のサポート、アップグレードの可能性、マルチフレームワークのサポート、モデルの暗号化などの機能がインフラストラクチャとして定義されていました。

AoE はどのようにモデルを管理しますか?

私たちが遭遇した問題を解決するために、主に次の 3 つの部分を実行しました。

1. モデルを検証するためにマルチモデルカバレッジテストを試みた
2. ランタイム環境設定を使用してモデルをロードする
3. 動的更新によるモデルのアップグレード

以下、これら3つの項目についてそれぞれ紹介します。

設定可能な動作環境

AoE SDK は、推論フレームワークを、初期化、前処理、推論実行、後処理、リソース解放の 5 つのプロセスにまとめています。 AoE 統合オペレーティング環境の場合、最も基本的なのは抽象推論操作です。依存性反転設計により、ビジネスは特定の推論フレームワークのアクセス実装を気にすることなく、AoE の上位レベルの抽象化のみに依存します。この設計の最大の利点は、開発者がフレームワークの実装を変更することなくいつでも新しい推論フレームワークを追加できるため、ビジネス開発と AoE SDK 開発が完全に分離されることです。

ユーザーは、json ファイルを記述するだけで動作環境の構成を完了できるため、ユーザーの使用プロセスが簡素化され、より簡潔で効率的になります。

簡単な構成は次のとおりです。

 {  
 "version" : "1.0.0" , // バージョン番号 
 "tag" : "tag_mnist" , // ビジネスシナリオを区別する 
 "runtime" : "tensorflow" , // ランタイム型 
 "source" : "installed" , // インストールソース 
 "modelDir" : "mnist" , // モデルが配置されているフォルダ 
 "modelName" : "mnist_cnn_keras" , // モデルファイル名 
 "updateURL" : "https://www.didiglobal.com" // 設定リンクの更新 
 }

モデルカバレッジテスト

ハードウェアの違いの問題に対処するために、モデル検証中にマルチモデル カバレッジ テストを実施しました。さまざまなモデルでのモデルのパフォーマンスを記録し、モデル制作チームにフィードバックして、モデルの継続的なアップグレードと修復に役立てました。

いくつかのテスト中に生成された時間のかかる比較データは次のとおりです。

モデルが異なり、使用する手順も異なる場合がありますが、マシンのパフォーマンスについて大まかなアイデアを得ることができます。具体的な値は参考値です。このプロセスでは、複数のモデルの範囲を検証するのに役立つベンチマーク ツールが開発されました。将来的には、このツールもオープン ソースの一部となり、誰もがモデルの使いやすさを検証し、効果的なモデル比較を確立できるようになります。

動的更新

AoE のモデル管理モジュールは、配布方法に応じてモデルを 2 つのタイプに分類します。

1. ローカルモデル（アプリケーションソフトウェアに付属するモデル）
2. リモート モデルは、ポリシー構成を通じてサーバーからローカル マシンにダウンロードされるモデルです。

ローカル モデルとリモート モデルの最大の違いは、ローカル モデルは変更できず、アプリケーション ソフトウェアと一緒にのみ更新できるのに対し、リモート モデルはローカル モデルと比較して更新される新しいモデルであることです。モデルはバージョンを通じて相互に比較されます。ローカルモデルとリモートモデルは共存することも、別々に存在することもできます。Didi Chuxing の最新バージョンでは、パッケージのサイズを縮小するために、ローカルモデルさえ存在しません。すべてのモデルはリモートの場所からダウンロードされます。

モデルを 2 つの部分に分割する理由は、モデルの可用性と信頼性を確保するためです。なぜそう言うのでしょうか。通常、ローカル モデルは、長期間のテストを経て、APP とともに安定バージョンとしてオンラインになります。最新バージョンとしても、その後の安定バージョンとしても使用できます。後でダウンロードしてアップグレードしたリモート モデルが理想的ではないことが判明した場合でも、グレースケール テストを通じてリモート モデルのリモート使用を停止し、モデルの高可用性を確保できます。

リモート モデルの存在により、ビジネス モデルを動的に更新できるようになり、製品の反復が容易になり、クライアントのリリース サイクルに依存しなくなります。動的スイッチの書き込み支援により、正確に指定されたモデル バージョンをロードすることも可能です。

全体的なモデル管理構造は次のとおりです。

モデルの読み込みをどのように使用しますか?

モデル マネージャーは AoE の基本コンポーネントです。iOS を例にとると、このコンポーネントは Loader ディレクトリに実装されています。デフォルトでサポートされているモデル構成ファイルは JSON 形式です。ランタイム環境構成セクションのコードは、mnist デモの構成を記述します。

モデルとモデル構成ファイル名の形式、およびリモートバージョンストレージアドレスは、AoEModelConfigクラスを継承することで変更できます。具体的な使用方法については、squeezenetの例を参照してください。

オープンソース版では、AoE は単機能マルチモデルのサポートも提供しています。銀行カードの認識を例にとると、全体のプロセスは 2 つのステップに分かれています。1 つ目はカードとカード上のデジタル領域を見つけること、2 つ目はデジタル領域の画像に基づいてカード番号を識別することです。そのため、全体のプロセスには 2 つのモデルが必要です。オープンソース プロジェクトで使用されるモデル構成の tag フィールドは、主にモデルの機能を定義するために使用されます。 dir フィールドと組み合わせることで、特定のモデルを見つけることができます。

最後に

リモートロードと多次元グレースケールテスト構成は、モデルの安定的かつ安全な動作を保証するものです。モデルのリモートロード機能はオープンソースバージョンではまだリリースされていませんが、予定されており、9月末にリリースされる予定です。このプロジェクトにご興味をお持ちの方、端末AI動作環境についてアイデアをお持ちの方、ご利用にあたってのご質問などございましたら、ぜひご参加ください。

プロジェクトリンク: https://github.com/didi/AoE