Tokopedia は、インドネシアのテクノロジー企業で、最大級の e コマース マーケットプレイスのひとつです。40 を超えるデジタル プロダクトと 1, 400 万人を超える登録販売者をプラットフォームでホストしています。
Mitra Tokopedia は、Tokopedia のビジネス カテゴリの一部であり、小規模ビジネスのオーナーがクレジットやゲームのクーポン、データ パッケージ、電気トークン、国民健康保険料などのデジタル商品を販売するのに役立つウェブ アプリケーションです。このウェブサイトは、700 を超える都市の Mitra Tokopedia 販売者の主要なチャネルの 1 つであるため、スムーズなユーザー エクスペリエンスを確保することが重要です。
オンボーディング プロセスの重要なステップでは、販売者が本人確認を行う必要があります。販売者は、販売者確認を完了するために、身分証明書と身分証明書が写っている自撮り写真をアップロードする必要があります。これは、顧客確認（KYC）プロセスと呼ばれます。
ウェブアプリ内のこの重要な KYC プロセスに機械学習機能を追加することで、Mitra Tokopedia はユーザー エクスペリエンスを向上させ、検証エラーを 20% 以上削減できました。また、手動承認を 70% 近く削減することで、運用コストを削減しました。
課題
KYC データのほとんどが不承認となり、手動検証のために運用チームに毎週数千件のチケットが作成されていました。これにより、運用コストが高くなるだけでなく、販売者の確認プロセスが遅延し、販売者のユーザー エクスペリエンスが低下する結果になりました。不承認の最大の理由は、販売者が身分証明書付きの自撮りを正しくアップロードしなかったことです。Mitra Tokopedia は、最新のウェブ機能を使用したスケーラブルな方法でこの問題を解決したいと考えていました。
解決策
Tokopedia のチームは、KYC プロセスの最初のステップ、つまりユーザーが画像をアップロードする際に、TensorFlow.js で ML を使用してこの問題を解決することにしました。販売者が身分証明書と自撮り写真をアップロードしたときに、販売者の顔を 6 つのキーポイントで検出するために、MediaPipe と TensorFlow の顔検出ライブラリを使用しました。モデルの出力は、承認基準との照合に使用されます。確認が正常に完了すると、情報がバックエンドに送信されます。検証に失敗した場合は、販売者にエラー メッセージと再試行オプションが表示されます。ハイブリッド アプローチが使用され、スマートフォンの仕様に応じて、モデルがオンデバイスまたはサーバーサイドで推論を実行します。低価格のデバイスでは、サーバー上で推論が行われます。
KYC プロセスの早い段階で ML モデルを使用すると、次のことが可能になります。
- KYC プロセスの不承認率を改善します。
- モデルによって評価された品質に基づいて、画像が不承認になる可能性があることをユーザーに警告します。
他のソリューションではなく ML を選択する理由
ML を使用すると、時間がかかる、または手動では実行できない反復的なタスクを自動化できます。Tokopedia の場合、現在の ML 以外のソリューションを最適化しても大きな成果は得られませんでしたが、ML ソリューションを使用することで、毎週数千件の承認を手動で処理していた運用チームの負荷を大幅に軽減できました。ML ソリューションを使用すると、画像チェックをほぼ瞬時に実行できるため、ユーザー エクスペリエンスが向上し、運用効率が向上します。問題のフレーム処理の詳細を確認して、ML が問題の解決に適したソリューションかどうかを判断します。
モデルを選択する際の考慮事項
ML モデルを選択する際には、次の要素が考慮されました。
費用
モデルの使用にかかる全体的な費用を評価しました。TensorFlow.js は Google によって適切にメンテナンスされているオープンソース パッケージであるため、ライセンスとメンテナンスの費用を節約できます。推論のコストも考慮する必要があります。推論をクライアントサイドで実行できると、高価な GPU を使用してサーバーサイドで処理する場合に比べて、特にデータが無効で使用できない場合に、大幅な費用削減につながります。
スケーラビリティ
モデルとテクノロジーのスケーラビリティを考慮しました。プロジェクトの進展に伴うデータとモデルの複雑性の増加に対応できますか？他のプロジェクトやユースケースに対応するように拡張できますか？オンデバイス処理は、モデルを CDN でホストしてクライアントサイドに配信できるため、非常にスケーラブルです。
パフォーマンス
ライブラリのサイズ（KB 単位）とランタイム プロセスのレイテンシを考慮しました。Mitra Tokopedia のユーザーベースの大部分は、中程度のインターネット速度と接続性を備えた中低価格帯のデバイスを使用しています。したがって、ダウンロードとランタイム（モデルが出力を生成できる速度）のパフォーマンスは、特定のニーズに対応し、優れたユーザー エクスペリエンスを実現するために最優先事項です。
その他の考慮事項
規制遵守: 選択した図書館が、関連するデータ保護とプライバシーに関する規制を遵守していることを確認する必要があります。
スキルセット: チームの専門知識とスキルセットを評価しました。一部の ML フレームワークとライブラリでは、特定のプログラミング言語や特定分野の専門知識が必要になる場合があります。これらの要素を考慮して、機械学習プロジェクトに適したモデルを選択する際に、十分な情報に基づいて判断しました。
選択したテクノロジー
これらの要素を考慮した結果、TensorFlow.js がニーズを満たすことになりました。WebGL バックエンドを使用してデバイスの GPU を使用し、完全にオンデバイスで実行できます。モデルをデバイス上で実行すると、サーバー レイテンシが短縮され、サーバーのコンピューティング費用が削減されるため、ユーザーへのフィードバックを迅速に提供できます。オンデバイス ML の詳細については、オンデバイス ML のメリットと制限事項をご覧ください。
「TensorFlow.js は、JavaScript 開発者を対象とした Google のオープンソースの機械学習ライブラリで、ブラウザでクライアント側を実行できます。ブラウザ内で高速なパフォーマンスで使用できる、WebGL、WebAssembly、WebGPU バックエンド演算子の包括的なサポートを備えた、ウェブ AI の最も成熟したオプションです。」 - Adobe が TensorFlow.js でウェブ ML を使用して Photoshop for web を強化した方法
技術的な実装
Mitra Tokopedia は、MediaPipe と TensorFlow のFace Detection ライブラリを使用しました。これは、リアルタイムの顔検出を実行するためのモデルを提供するパッケージです。具体的には、tfjs ランタイムを実装するこのライブラリで提供されている MediaPipeFaceDetector-TFJS モデルがこのソリューションで使用されました。
実装に入る前に、MediaPipe について簡単に説明します。MediaPipe を使用すると、モバイル（Android、iOS）、ウェブ、デスクトップ、エッジデバイス、IoT にオンデバイス ML ソリューションを構築してデプロイできます。
この記事の執筆時点で、MediaPipe では14 種類のソリューションが提供されています。mediapipe ランタイムまたは tfjs ランタイムを使用できます。tfjs ランタイムは JavaScript で構築されており、ウェブ アプリケーションによって外部からダウンロードできる JavaScript パッケージを提供します。これは、C++ でビルドされ、WebAssembly モジュールにコンパイルされる mediapipe ランタイムとは異なります。主な違いは、パフォーマンス、デバッグ性、バンドルです。JavaScript パッケージは、webpack などの従来のバンドラにバンドルできます。一方、Wasm モジュールは、より大きく、個別のバイナリ リソースであり（読み込み時の依存関係がないため軽減されます）、別の Wasm デバッグ ワークフローを必要とします。ただし、技術要件とパフォーマンス要件を満たすために、実行速度は速くなります。
Tokopedia の実装に戻ると、最初のステップとして、次のようにモデルを初期化します。ユーザーが写真をアップロードすると、HTMLImageElement が検出機能に入力として渡されます。
// Create the detector.
const model = faceDetection.SupportedModels.MediaPipeFaceDetector;
const detectorConfig = {
runtime: 'tfjs'
};
const detector = await faceDetection.createDetector(model, detectorConfig);
// Run inference to start detecting faces.
const estimationConfig = {flipHorizontal: false};
const faces = await detector.estimateFaces(image, estimationConfig);
顔リストの結果には、画像内の各顔の検出結果が含まれます。モデルが顔を検出できない場合、リストは空になります。顔ごとに、検出された顔の境界ボックスと、検出された顔の 6 つのキーポイントの配列が含まれます。これには、目、鼻、口などの特徴が含まれます。各キーポイントには、x と y の座標と名前が含まれます。
[
{
box: {
xMin: 304.6476503248806,
xMax: 502.5079975897382,
yMin: 102.16298762367356,
yMax: 349.035215984403,
width: 197.86034726485758,
height: 246.87222836072945
},
keypoints: [
{x: 446.544237446397, y: 256.8054528661723, name: "rightEye"},
{x: 406.53152857172876, y: 255.8, "leftEye },
...
],
}
]
box は、画像ピクセル空間における顔の境界ボックスを表します。xMin、xMax は x 境界、yMin、yMax は y 境界、width、height は境界ボックスのサイズです。keypoints の場合、x と y は画像ピクセル空間内の実際のキーポイント位置を表します。name はキーポイントのラベル（それぞれ 'rightEye'、'leftEye'、'noseTip'、'mouthCenter'、'rightEarTragion'、'leftEarTragion'）を提供します。この投稿の冒頭で説明したように、販売者は販売者の確認を完了するために、身分証明書と身分証明書が写っている自撮り写真をアップロードする必要があります。モデルの出力は、承認基準との照合に使用されます。つまり、前述の 6 つのキーポイントが一致して、有効な身分証明書と自撮り画像と見なされます。
確認が完了すると、関連する販売者情報がバックエンドに渡されます。検証に失敗した場合は、不合格のメッセージと再試行オプションが販売者に表示されます。バックエンドには情報が送信されません。
ローエンド デバイスのパフォーマンスに関する考慮事項
このパッケージは 24.8 KB しかなく（圧縮済み、gzip 圧縮済み）、ダウンロード時間に大きな影響はありません。ただし、非常にローエンドのデバイスでは、ランタイム処理に時間がかかります。2 つの画像を ML 顔検出モデルに渡す前に、デバイスの RAM と CPU を確認するロジックを追加しました。
デバイスに 4 GB を超える RAM、4G を超えるネットワーク接続、6 コア以上の CPU が搭載されている場合、画像はオンデバイス モデルに渡され、顔認証が行われます。これらの要件が満たされていない場合、オンデバイス モデルはスキップされ、古いデバイスに対応するためにハイブリッド アプローチを使用して、画像がサーバーに直接送信され、検証されます。ハードウェアの進化に伴い、時間の経過とともに、より多くのデバイスでサーバーからコンピューティングをオフロードできるようになります。
影響
ML を統合したことで、Tokopedia は不承認率の高さを解決し、次のような結果を得ることができました。
- 不承認率が 20% 以上減少した。
- 手動承認の数は 70% 近く減少しました。
これにより、販売者のユーザー エクスペリエンスが円滑になっただけでなく、Tokopedia チームの運用コストも削減されました。
まとめ
全体として、このケーススタディの結果は、適切なユースケースでは、ウェブ上のオンデバイス ML ソリューションが、ユーザー エクスペリエンスと機能の効果を高め、コスト削減などのビジネス上のメリットをもたらす可能性があることを示しています。
MediaPipe Studio と MediaPipe Face Detector for web のコードサンプルを使用して、MediaPipe の顔検出機能を試すことができます。
オンデバイス ML を使用して独自のウェブアプリの機能を拡張する場合は、次のリソースをご覧ください。