詳細 | ビッグデータアルゴリズムアプリケーションのテストの開発

[[389157]]

この記事では、アリババ AI ミドルプラットフォームの技術品質システム、つまり検索推奨広告アプリケーションの品質がどのようにテストされるかを体系的に紹介することで、この疑問に答えようとしています。皆様の参考になれば幸いです。改善のためのご意見をお待ちしています。

1. はじめに

過去 10 年間、モバイル インターネットとスマート デバイスの台頭により、大手企業のアプリケーション プラットフォームにはますます多くのデータが蓄積されるようになりました。大量のユーザー特性と行動ログを含むこれらのデータは、大量に保存されています。統計分析と特徴サンプルの抽出の後、トレーニングされて、対応するビジネス アルゴリズム モデルが生成されます。これらのモデルは、ユーザーの行動と意図を正確に識別して予測できるインテリジェント ロボットのようなものです。

データをリソースと見なすと、インターネット企業は従来の企業とは根本的に異なります。彼らはリソースの消費者ではなく、リソースの生産者です。プラットフォームの運用中に新しいデータリソースを継続的に作成し、これらのリソースもプラットフォームの使用期間と頻度の増加に応じて指数関数的に増加します。これらのデータとモデルを使用することで、プラットフォームはより優れたユーザー エクスペリエンスとビジネス価値をもたらします。 2016年、ディープニューラルネットワークに基づく囲碁人工知能プログラム「AlphaGo」が、囲碁の世界チャンピオンであるイ・セドル氏を初めて破った。 Google の子会社である DeepMind によって開発されたこのアルゴリズム モデルは、人間のチェス プレイヤーの過去のチェス ゲーム データをすべて使用します。

Alibaba の検索、推奨、広告も、典型的なビッグデータ応用シナリオ (高次元スパースビジネスシナリオ) です。テスト方法について話す前に、まずプラットフォームのデータ処理のエンジニアリングと技術的背景を理解する必要があります。検索、推奨、広告システムは、エンジニアリング アーキテクチャとデータ処理フローが比較的類似しており、一般的にはオフライン システムとオンライン システムの 2 つの部分に分けられます (下の図 1 を参照) (オンライン広告システムの一般的なアーキテクチャ、Liu Peng の「Computational Advertising」)。オフライン システムはデータ処理とアルゴリズム モデルのモデリングおよびトレーニングを担当し、オンライン システムは主にユーザーのリアルタイム要求を処理するために使用されます。オンライン システムは、クリックスルー率の推定などのリアルタイムのオンライン予測に、オフライン システムによってトレーニングされたモデルを使用します。

ユーザーが携帯電話でタオバオなどのアプリにアクセスすると、ユーザーの閲覧、検索、クリック、購入、評価、滞在時間など、大量の行動データが生成されます。さらに、販売者の製品ディメンションに関するさまざまなデータ（広告には広告主ディメンションのデータも必要）も生成されます。これらのデータを収集、フィルタリング、処理し、特徴を抽出した後、モデルに必要なサンプルデータが生成されます。機械学習トレーニングプラットフォームでオフライントレーニングした後、サンプルデータからオンラインサービスのさまざまなアルゴリズムモデル（深層関心進化ネットワークDIEN、ツリーベースのディープモデル、大規模グラフ表現学習、分類された関心に基づく動的類似ユーザーベクトルリコールモデルなど）を生成できます。オンライン システムの最も重要な機能は、データ検索とオンライン予測サービスであり、通常、データの順方向および逆方向インデックス、時系列ストレージなどの情報検索関連テクノロジが使用されます。

検索推奨広告システムは、上記次元のビッグデータを活用し、ディープラーニングを経て、各個人に合わせたパーソナライズされたシステムになります。ユーザーのリクエストが異なれば、表示される商品や推奨事項の自然な結果とビジネス上の結果は毎回異なります。同じユーザーでも、異なる時間に得られた結果がユーザーのリアルタイムの行動によって変化します。これらすべての背後には、データとアルゴリズム モデルの魔法があります。

図1 オンライン広告システムの一般的なアーキテクチャ

データアプリケーションテスト品質の分野における6つの課題

検索推奨広告システムのテスト方法を考える前に、まず問題領域、つまり解決すべきテスト問題を定義する必要があります。私たちのアイデアは、次の方向から発展していきます。

1 機能テストと検証

通常のリクエストとレスポンスのチェックに加えて、ビッグデータの「ビッグ」は主にデータの整合性と豊富さに反映されます。検索推奨エンジンの品質は、そのコンテンツが十分に豊富で、そのリコールが十分に多様であるかどうかに大きく依存します。さらに、このアルゴリズムは検索推奨結果に不確実性をもたらすだけでなく、テストや検証作業にも支障をきたします。したがって、データの整合性と不確実性の検証も機能テストの重要なポイントとなります。

2 データ更新のリアルタイムパフォーマンスをテストする方法

ご存知のとおり、検索や広告用のオンライン コンピューティング エンジンでは、販売業者による商品情報の変更、広告主の創造性や配信計画の変更などにより、内部データが常に更新されます。これらの更新は、配信エンジンにリアルタイムでフィードバックされる必要があります。そうしないと、情報の不一致やエラーが発生することがあります。これらの変更の適時性をどのようにテストおよび検証するか、つまり、一定の同時帯域幅と更新リンクの応答時間を確保するかは、テストで重点的に考慮する必要がある問題です。

3 データ要求応答の適時性をテストする方法

オンライン サービスでは、低レイテンシが求められます。各クエリ サーバーは数十ミリ秒以内に応答する必要があり、サーバー トポロジ全体は 30 を超えるさまざまなモジュールで構成されます。バックエンド サービスのパフォーマンスと容量をどのようにテストするかが重要になります。

4 アルゴリズムの有効性を検証する方法

クリック率やトランザクションコンバージョン率を高めるには、検索の推奨や広告結果がユーザーのニーズや興味に合致している必要があります。しかし、そのようなニーズと結果の相関関係を検証する方法や、アルゴリズムの有効性をテストする方法は、非常に興味深く、挑戦的なトピックです。

5 AIアルゴリズムシステムのオンライン安定性を確保する方法

オフラインリリース前のテストはコードのテスト受け入れであり、欠陥が発見され修正されるにつれてコードの品質が向上します。オンライン安定性操作の目的は、システム動作の安定性を向上させることです。解決すべき問題は、平均的なコード品質のシステムであっても、技術的な運用と保守方法を通じてシステムの高可用性と堅牢性を向上させ、オンライン障害の頻度と影響を減らすことです。この部分は、オンライン技術リスク領域とも呼ばれます。

6 エンジニアリング効率の方向性

これは上記の部分を補完するものであり、エンジニアリング R&D システム全体の効率を補完するものでもあります。品質と効率は双子の兄弟であり、同じコインの裏表です。 両者の関係をどのようにバランスさせるかは難しい問題です。 品質と効率のどちらを優先すべきでしょうか? 製品開発の段階によって、重点が異なります。当社のエンジニアリング効率は、DevOps R&D ツール チェーンの解決に重点を置き、R&D エンジニアリングの生産性を向上させます。

それ以来、私たちは基本的にビッグデータ アプリケーションのテスト問題の 6 つの主要な領域を定義してきました。一部の領域は従来のテストと品質の範囲を超えていますが、これはビッグデータ アプリケーションがもたらす独自の品質課題でもあります。これら 6 つの問題について詳しく説明しましょう。

3つの主要なデータアプリケーションテストにおける6つの問題の解答

1 AIアプリケーションの機能テスト検証

機能テストは、主にエンドツーエンドのユーザーインタラクションテスト、オンラインエンジニアリング機能テスト、オフラインアルゴリズムシステム機能テストの 3 つの部分に分かれています。

1) エンドツーエンドのユーザーインタラクションテスト

これは、検索推奨広告システムのユーザーインタラクション部分のテストと検証であり、購入者側（Taobaoモバイル、Tmallアプリ、Youkuアプリなど）のユーザーエクスペリエンスとロジック機能の検証、および広告主とマーチャント向けの顧客管理プラットフォーム（ビジネスプラットフォーム）でのビジネスプロセスロジックの検証が含まれます。広告主の広告クリエイティブ作成、配信プラン設定、請求決済などのテストが含まれます。エンドツーエンドのテストにより、最終的にユーザーや顧客に提供する製品の品質が保証されます。エンド側のテスト技術とツールは、主にエンドツーエンド（ネイティブ/h5）アプリ/ウェブ上でのUI自動化、セキュリティ、パフォーマンス安定性（モンキーテスト/クラッシュ率）、トラフィック（弱いネットワーク）、電力消費、互換性と適応性に関係しています。グループ内の他のチームのテスト技術とオープンソース技術システムに基づいて、いくつかの改善と革新を行いました。たとえば、リッチメディアインテリジェント検証をクライアント側の自動テストに導入し、画像比較、テキストOCR、ローカル機能マッチング、エッジ検出、キーフレームベースのビデオ検証（コンポーネントアニメーション、パッチビデオ）などを完了し、クライアント上の広告推奨のあらゆる表示形式の検証問題を解決しました。さらに、Java インターフェースとクライアント SDK のテストでは、通常の API サービス レベルのテストに加えて、データ トラフィックの再生に基づく比較テスト方法が使用され、インターフェース比較、DB 比較、ファイル比較、トラフィック比較の使用で良好な品質の結果が得られています。エンドツーエンドのテスト検証。UI の改訂速度が非常に速いため、テスト戦略の観点から、インターフェイス レベルでの自動化に重点を置いています。UI の自動化は単純なロジック検証にすぎず、完全な UI 検証回帰 (機能ロジックとスタイル エクスペリエンス) は、依然として手動テストを通じて行われます。ここでは、補助として多くのアウトソーシング テスト サービスを使用します。

2) オンラインエンジニアリングシステムのテスト

この部分は、システム全体の機能テストの焦点となります。検索推奨広告システムは本質的にデータ管理システムであり、データには製品ディメンション、ユーザー ディメンション、マーチャント ディメンション、広告主ディメンションが含まれます。大量のデータを特定のデータ構造に従ってマシンメモリに保存し、リコール、推定、融合などのサービスを提供することは、すべてオンラインエンジニアリングが解決する必要がある問題です。機能テストのこの部分の基本原則は、リクエスト/クエリ文字列を送信し、応答結果を検証することです。これに基づいて、テスト ケースの生成と実行の効率を向上させるために、多くのテクノロジが使用されます。可視化、インテリジェント、その他のテクノロジー (インテリジェントなユースケース生成、インテリジェントな回帰、障害のインテリジェントな帰属、正確なテスト範囲、機能的な A/B テスト) に基づいて、テスト方法論が統合され、大規模な異種オンライン エンジニアリング機能テスト ケースの作成にかかるコストの高さ、デバッグの難しさ、回帰効率の低さなどの問題が解決されます。検索推奨広告のオンライン サービス プロジェクトは、基本的に 20 ～ 30 種類のオンライン モジュールで構成されています。これらのオンライン サービス モジュールのテストには非常に時間がかかります。ユース ケースの作成と回帰操作の効率化が、主な最適化目標です。この方向では、ユース ケースの生成にユース ケース拡張および推奨テクノロジを使用し、遺伝的アルゴリズムに基づいて効果的なテスト ケースを動的に生成し、ユース ケースの実行フェーズで動的にオーケストレーションされた回帰テクノロジを使用します。これらのテクノロジにより、オンライン モジュールの機能テストの範囲が大幅に向上しました。

また、機能変更の違いを確認するために、オンラインクエリを比較テストに使用することもよくあります。リリースするシステムと実際のオンラインシステム間の結果とデータ分布の一貫性を分析すると、システムの機能上の問題を見つけるのに役立ちます。オンラインテストの分野では、比較テストに加えて、最近のトップNクエリのオンライン検査を定期的に実施しています。これは、一方では機能監視の目的を果たします。他方では、クエリ量が一定のレベルに達すると（たとえば、過去1週間のロングテールクエリの80％）、エンジンデータの整合性と多様性を検証しやすくなります。最後に、この部分のテスト戦略も強調する必要があります。アルゴリズムのロジック（リコールやソートのビジネス ロジックなど）は非常に複雑で、さまざまなビジネスや階層モデルが関係するため、これらのロジックはアルゴリズム エンジニアによって直接設計および実装されます。したがって、アルゴリズム ロジックのテスト ケースの設計と実行もアルゴリズム エンジニアによって行われます。モデルの機能ロジックとその変化を知っているのは、彼らだけです。オンライン デバッグ システムの使用と組み合わせることで、アルゴリズム エンジニアは、現在オンラインで実行されているアルゴリズムとオフラインで起動しようとしているアルゴリズムの論理的な違いを明確に理解できるため、テスト ケースの作成が容易になります。テスト エンジニアは、テスト フレームワークとツール環境全体のセットアップ、および基本的なテスト ケースの作成と実行を主に担当します。このテスト戦略の調整については、この記事の最後にある将来のテストの予測でも紹介されています。

3) オフラインシステムテストまたはアルゴリズムエンジニアリングテスト

データフローの観点から見ると、アルゴリズムエンジニアリングには、アルゴリズムモデルのモデリングプロセスとオンラインモデルトレーニングの2つの部分が含まれます。特徴抽出、サンプル生成、モデルトレーニング、オンライン予測、パイプラインのオフラインプロセスからオンラインプロセスまで、特徴サンプルの品質とモデルの品質を検証する方法が重要です。したがって、アルゴリズム テストの鍵は次の 3 つの場所にあります。

1. サンプル特徴品質の評価
2. モデル品質の評価
3. オンラインモデル推定サービスの品質保証

a) と b) はデータ品質と機能の有効性に関係しており、これらはセクション 4 で一緒に紹介され、主にデータ品質のさまざまな指標を使用して品質を評価します。

ここでは、アルゴリズムのオンライン推定サービスが開始される前のテストである c に焦点を当てます。これは、モデルの最終的なサービスの品質に関連し、比較的重要であるためです。ここでは、小規模なサンプルのオフラインおよびオンラインのスコアリング比較方法を使用します。これにより、最終的にはモデルの品質の問題をオンラインで比較的包括的に検証できます。詳細なプロセスは次のとおりです。モデルを正式にサービスに投入する前に、テストと検証を行う必要があります。通常のテストデータセットを準備するだけでなく、サンプルセットの一部を分離して、小サンプルデータセットと呼びます。オンラインシステムスコアと小サンプルデータセットのオフラインスコアの差を比較することで、モデルのオンラインサービス品質を検証します。この小サンプルスコアリングは、実際にはグレースケール検証に似た機能を提供します。このプロセスを以下の図 2 に示します。

図2 小規模サンプルテスト

オフライン システム テストに関しては、ディープラーニング トレーニング プラットフォームの品質保証についても検討しました。現在、ディープラーニング プラットフォームの品質は、次の 3 つの大きな問題に直面しています。

• さまざまな複雑な条件により、クラスターでトレーニングされたモデルのトレーニングが失敗するリスクがあります。ディープラーニング プラットフォームに現在存在する潜在的なリスクを早期に警告するにはどうすればよいでしょうか。
• ニューラル ネットワークの自然な局所最適解遺伝子と Tensorflow Batch の設計コンセプトにより、トレーニングされた各モデルがオンライン ローンチの品質要件を満たしていることをどのように保証するか。
• 大規模データセットや分散システムにおいて、ディープラーニングプラットフォームが提供するさまざまなディープラーニング機能の精度を検証する方法。

私たちはこれら 3 つの問題に対して 3 つの解決策を試しました。

• 実験的な事前実行方法、特別なモデルとトレーニングデータを設計し、15 分以内にトレーニングを完了できます。トレーニング プラットフォームの問題を迅速に発見して特定することができ、大規模な生産モデルが正式にトレーニングされる前に問題を検出できます。
• モデルオンモデル検証法は、モデル生成の中間データ指標（AUCのほか、ニューロン活性化率、各層に伝達された勾配の平均二乗誤差などを含む）を処理モデリングを通じて伝達し、生成モデルの品質を監視します。
• モデルベースの機能検証方法では、モデル変数の理論値を正確に計算できるようにサンプル形式とテストモデルネットワークを具体的に設計し、トレーニングモデルの結果に応じてプラットフォームの品質を検証します。

2 データ更新のリアルタイムパフォーマンスをテストする方法

この部分には主に 2 つのサブ質問が含まれます。

1) エンジンデータのリアルタイム更新リンクのテスト

リアルタイム更新リンクの場合、上流データソース/データテーブル（TT/MetaQ/ODPS、Alibabaのメッセージミドルウェア、オフラインデータテーブル）からデータが読み取られ、ストリーミングコンピューティングプラットフォーム（Bayesエンジン、Blinkなど、Alibabaのリアルタイムコンピューティングプラットフォーム）のリアルタイムコンピューティングタスク処理によって、エンジンが受け入れ可能な更新メッセージが生成されます。エンジンは、このようなメッセージを受信した後、データ更新操作を実行します。このリンクの主な検証ポイントは次のとおりです。

• データの正確性を検証する
• データの一貫性検証
• データの適時性の検証
• データの同時実行パフォーマンステスト

これらの問題を解決するために、ストリーミング データのリアルタイム比較と完全比較を使用して、データの正確性と一貫性の検証の問題を解決しました。データの適時性は、コンピューティング プラットフォームの基盤となるリソースに大きく依存し、ミリ秒レベルでの更新速度を保証します。ここでは、更新のタイムスタンプを記録することで、更新の適時性を検証します。パフォーマンス テストでは、アップストリーム データとトラフィックのレプリケーションを偽造することで、リンク全体の応答時間と同時処理機能を検証します。

2) モデルのリアルタイム更新（オンラインディープラーニング）リンクをテストする方法

リアルタイムの行動がもたらすアルゴリズムの利点を得るために、過去2年間でオンラインディープラーニング（ODL）が登場しました。ユーザーのリアルタイムの行動特徴データも、リアルタイムでモデルにトレーニングする必要があります。10〜15分の間隔で、オンラインサービスのモデルは更新および置き換えられ、モデルの検証に最大10分しか残っていません。これが、ODLがもたらす品質の課題です。この問題を解決するために、2 つの方法を同時に実行します。

（１）最も重要な方法は、ODLフルリンク品質指標監視システムを確立することです。ここでのリンクとは、サンプルドメインでの指標検証とトレーニングドメインでの指標検証を含む、サンプル構築からオンライン予測までのリンク全体を指します。

指標の選択は、主に効果に関係するかどうかによって決まります。たとえば、ctr 推定方向の場合、テスト セットで auc、gauc (グループ auc、グループ化後の auc)、score_avg (モデル スコア平均) などの指標を計算したり、train_auc と test_auc、pctr と actual_ctr (前者はオーバーフィットしているかどうかを確認し、後者はスコアリング精度を確認します) の差が妥当な範囲内にあるかどうかを計算したりすることもできます。ここで重要な点は、テスト セットの選択です。テスト セットには、次の時間ウィンドウのデータ (モデルの一般化パフォーマンスをテストするために、目に見えないデータを使用する) だけでなく、過去の期間 (1 週間など) のデータからランダムにサンプリングされたデータの一部 (モデルに偏りがあるかどうかをテストするために、目に見えて包括的なデータを使用する) も含めることをお勧めします。同時に、局所的な異常な検査サンプルが評価指標に及ぼす妨害効果も軽減されます。

（２）指標システムに加えて、モデルが正式にリリースされる前に、シミュレーション環境でスコアリングと検証をシミュレートするためのオフラインシミュレーションシステムを設計しました。

簡単に言うと、オンラインにする必要のあるモデルは、オンライン サービスのコンポーネント スコアリング モジュールを通じて、オンライン トラフィックを使用してオフライン テスト環境で事前にスコアリングされます。このスコアリング プロセスでエラーが発生すると、検証失敗とみなされます。その後、正常なスコアを持つモデルの平均と分布のスコアが検証されます。スコアリング検証に失敗した場合、オンラインへの参加は直ちに拒否されます。上記の 2 つのソリューションを、サンプルとモデルの監視と傍受と組み合わせることで、ODL の品質リスクを高い確率で低減できます。

3 パフォーマンスストレステスト

オフライン部分とオンライン部分で構成される AI システムの場合、オンライン部分はユーザーのリアルタイムのアクセス要求に応答し、応答時間に対する要件がより高くなります。オンライン システムのパフォーマンスは、この部分の焦点となります。オフライン パフォーマンスは、トレーニング プラットフォームによるコンピューティング リソースのスケジュールと使用に大きく依存します。通常は、単純なソース データのレプリケーションを通じて検証します。オンライン システムの場合、パフォーマンス テストは読み取りシナリオと書き込みシナリオに分かれています。書き込みシナリオのパフォーマンスについては、第 2 部「リアルタイム更新リンクの適時性」で紹介しました。ここでは、主にオンライン シナリオの読み取りシナリオのパフォーマンス容量テストについて説明します。

オンライン システムは、通常、20 または 30 の異なるエンジン モジュールで構成されています。エンジン内のデータとテスト クエリの違いは、パフォーマンス テストの結果に大きく影響します。同時に、オフライン パフォーマンス テスト環境とオンライン環境間のデータ同期を維持するには多大なコストがかかるため、現在の戦略では、オンライン プロダクション クラスターでパフォーマンス容量テストを実行することを選択します。数十万の QPS (Query Per Second) を処理できるオンライン システムの場合、大量の同時クエリの発生をいかに正確に制御するかが課題となります。単純なマルチスレッドやマルチプロセス制御では、この問題を解決できません。ここでは、ヒル クライミング アルゴリズム (勾配多重反復ヒル クライミング法) を使用してフローを正確に制御し、数百台のストレス テスト マシンでシステムのパフォーマンス レベルを段階的に検出します。

もう一つの開発方向は、ストレステストプロセス全体の自動化と無人実行です。シナリオベースのオンラインクエリの自動選択からストレス生成、そして平均シフトアルゴリズムのシステム自動検証まで、ストレステストプロセス全体が事前設定された条件に従って自動的に完了します。クラスター間のトラフィック切り替えと組み合わせることで、毎日のストレス テストを昼夜を問わず実行できるため、オンライン水位とパフォーマンスのボトルネックの分析が大幅に容易になります。

4. 効果のテストと評価

これはビッグデータ応用アルゴリズムのハイライトです。アルゴリズムの効果は検索広告事業（収益とGMV）の直接的な利益に関係するため、当社はこの方向にも比較的大きな投資を行っており、以下のサブ方向に分かれています。

1) 機能とサンプルの品質と有効性の評価

特徴品質（データと分布の問題があるかどうか）と特徴有用性（アルゴリズムにとって価値があるかどうか）を考慮することで、欠損率比、高頻度値、分布の変化、値の相関など、特徴指標の計算におけるいくつかの重要な指標が見つかります。同時に、トレーニングと評価のプロセス中に、多数の中間指標がモデル効果との因果関係を生み出すことができます。モデリングのテンソル、勾配、重み、更新量を体系的に分析することで、アルゴリズムの調整と問題の特定に関する意思決定を支援できます。

さらに、AUC アルゴリズムを改良し、ROC、PR、推定分布などのより多くの評価指標を分析することで、モデル効果をより包括的に評価できるようになります。データ量の増加に伴い、過去 2 年間でモデリングとトレーニングのプロセスでは数千億のパラメータと数兆のサンプルが使用されました。グラフ ディープラーニングも数百億のポイントと数千億のエッジの段階に入りました。このような膨大なデータの海の中で、特徴サンプルや前述のさまざまな指標をどのように視覚化するかが難しい点になっています。Google のオープンソース Tensorboard に基づいて多くの最適化と改善を行い、アルゴリズム エンジニアがデータ指標の視覚化、トレーニング プロセスのデバッグ、ディープ モデルの解釈可能性においてより良いサポートを提供できるようにしました。

2) オンライントラフィック実験

アルゴリズム プロジェクトが正式に開始される前に、モデルは実際のオンライン トラフィックを実験環境に導入して、効果のテストと調整を行う必要があります。Google の階層化実験アーキテクチャに基づく第 1 世代のオンライン階層化実験 (その原理は Google の論文「Overlapping Experiment Infrastructure More, Better, Faster Experimentation」に記載されています) に基づいて、同時実験、パラメーター管理、パラメーター間の相互カバレッジ、実験の品質保証の欠如、実験のデバッグ機能の欠如、実験の拡張機能の不足など、多くの改善を行いました。これらの改善により、トラフィックの同時再利用とセキュリティ メカニズムが大幅に改善され、真の実稼働実験の目的が達成されました。有効性の面では、オンライン実験プラットフォームを通じて導入された実際のトラフィックの検証により、モデルの有効性の品質が大幅に保証されます。

3) データ効果評価

これは関連性評価と効果評価の2つの部分に分かれています。関連性は、関連性モデルの非常に重要な評価指標です。私たちは主にデータ評価を通じてこの問題を解決します。検索結果の表示指標を評価することで、各検索結果の関連性スコアを取得できます。サブ指標には、古典的な測定指標 CSAT (顧客満足度、非常に満足、満足、普通、不満、非常に不満を含む)、ネット プロモーター スコア NPS (ネット プロモーター スコア、2003 年に Bain Consulting の顧客ロイヤルティ事業の創設者 Fred Reichheld によって提案された、ユーザーの推奨意欲を測定し、ユーザーのロイヤルティを理解する)、CES (顧客努力スコア、「顧客努力」は、ユーザーが製品/サービスを使用して問題を解決する難しさを評価できるようにする)、HEART フレームワーク (Google から派生、幸福、エンゲージメント、採用、維持、タスクの成功) などがあります。

効果評価に関しては、データ統計と分析手法を使用しました。アルゴリズム モデルを完全にサービスに導入する前に、このモデルのサービス効果を正確に検証する必要があります。最初の部分で紹介したオフラインとオンラインの比較に加えて、結論を裏付けるために、より客観的なデータ指標が必要です。ここでは、実際のトラフィックのA/B実験テスト方法を使用し、オンライントラフィックの5％をリリースするモデルにインポートし、この5％のトラフィックの影響をベンチマークバケットと比較して評価し、ユーザーエクスペリエンス（関連性）、プラットフォーム収益、顧客価値の3つの側面から実際の指標を分析します。ユーザーの関連性評価結果、プラットフォームの収益またはGMV、顧客のROIなどに基づいて、新しいモデルが買い手、プラットフォーム、売り手に与える潜在的な影響を観察し、最終的なビジネス決定に必要なデータサポートを提供します。トラフィック量は5%から10%、20%、50%へと増加します。グレースケールを徐々に最大量まで増加させる過程で、機能上の問題、パフォーマンス上の問題、さらには効果上の問題も検出されます。この方法により、重大なリスクの発生がさらに軽減されます。これは、データの統計分析とテクノロジーを統合したソリューションです。この記事で紹介した他の技術的方法とは異なります。ユニークですが、効果は非常に優れています。

5 オンライン安定性

他の事業の安定性構築と同様に、当社はリリースの3つの軸（グレースケール、監視、ロールバック）でリリースプロセスの品質を解決し、オンライン災害復旧訓練、フォールトインジェクションと訓練（当社はグループのオープンソースカオスエンジニアリングMonkey KingのC++バージョンの提供者でもあります）、セキュリティ赤青対決攻撃と防御を通じて、システムのオンライン安定性と可用性を向上させます。また、AI OpsとService Meshをベースとした運用保守制御では、インテリジェントな運用保守、データ視点の分析、自動フロー切り替え、自動拡張・自動縮小などに取り組んでいます。サービス メッシュ テクノロジーの概念と C++ オンライン サービスの進化を組み合わせることで、システムはビジネス アプリケーションのトラフィックを非侵入的に調整および変更できるようになり、トラフィックのスケジュール設定と分離機能を実現できるようになると予測しています。さらに、レッドとブルーの攻撃と防御もさらに発展し、自動化とプロセスベースの管理が徐々にカオスエンジニアリング実装の標準的な形式になるでしょう。この部分はまだ初期段階なので、まだ実装されていない内容についてはあまり紹介しませんが、この方向には大きな可能性があると考えています。従来の運用保守作業とは異なり、Google の SRE (Site Reliability Engineering) のコンセプトに近いものです。

6 AIアプリケーションのエンジニアリング効率

主にテストと研究開発段階の効率向上の問題を解決します。この方向では、DevOpsツールチェーンの構築と、開発、テスト、エンジニアリングリリース、モデルリリース（モデルデバッグポジショニング）、顧客フィードバック（物理評価、クラウドテスト、顧客の問題デバッグ）を含むR＆Dクローズドループ全体で使用されるツールの構築に重点を置いています。私たちが想定している DevOps シナリオでは、開発者はこれらのツールを使用して、要件の開発、テスト、リリースを独自に完了し、顧客からのフィードバックを処理できます。この指示はテスト自体とはほとんど関係がないため、スペースの制約によりここでは省略します。

4つのデータアプリケーションテストの将来

これまで、ビッグデータ アプリケーションのテストにおけるいくつかの主要な問題に対する解決策が紹介されました。ビッグデータ アプリケーションのテストの将来についても、いくつかの予備的な判断があります。

1 バックエンドサービスのテスト用ツール

これには、サーバー側でのテスト変換の問題が関係します。バックエンド サービス タイプのテストでは、フルタイムのテスターは必要なくなると考えています。開発エンジニアは、適切なテスト ツールを使用して、テスト タスクをより効率的に完了できます。今後、フルタイムのテスト チームは、フロントエンドとユーザー インタラクションの側面における製品品質の管理に重点を置くようになります。製品マネージャーと同様に、ユーザーの観点から製品品質の問題について考える必要があります。製品の配信とインタラクションの検証がこの方向性の焦点となります。サーバー側のテスト タスクのほとんどは自動化できますが、サービス レベルの検証の多くは自動化を通じてのみ検証できます。テスターと比較すると、開発者は API レベルでの自動コード開発においてより能力があります。さらに重要なのは、開発者が独自にテストを行うことで、リリース プロセス全体の大部分を占めるテスターと開発者間の往復通信のコストを削減できることです。さらに、最初の部分で述べたように、アルゴリズム エンジニアはビジネス ロジックをより明確に理解しています。

したがって、バックエンドのテスト作業は、エンジニアリング エンジニアまたはアルゴリズム エンジニアが独立して完了することを推奨します。この新しいプロダクション関係モデルでは、テスターは、自動テスト フレームワーク、テスト環境展開ツール、テスト データの構築と生成、スモーク テスト ツールのリリース、継続的な統合と展開など、テスト ツールの研究開発に重点を置くようになります。このモデルは、Google が使用しているテスト モデルでもあります。今年、この方向への変革に取り組みましたが、品質の変化と効率性の向上という点では、結果は非常に良好です。テスト改革をリードしてきた国内インターネット企業として、同業他社の参考になるのではないかと考えています。ここで強調しておきたいのは、テスト チームがこの方向に変革を遂げたにもかかわらず、バックエンド テストは引き続き継続する必要があるということです。唯一の違いは、テスト タスクの実行者が開発エンジニアになったことです。この記事で紹介した多数のバックエンド テスト技術と方向性は、今後も存在し続けるでしょう。バックエンド サービス テスト チームの変革にとって、パフォーマンス ツールに加えて、第 5 部でのオンライン安定性の構築は非常に良い方向です。

2. オンラインテスト、つまりTIP（Test In Production）

このコンセプトは約 10 年前に Microsoft のエンジニアによって提案されました。 TIP は将来のテスト方法の方向性を示すものであり、その主な考慮事項は次の 3 点です。

1) 一方で、オフライン テスト環境と実際のオンライン環境の間には常に何らかの違いがあり、そのような違いを解消するには大きな継続的なコストが必要であり、テストの結論が信頼できないものになります。最も一般的に使用されるのは、パフォーマンス テストまたは容量テストです。バックエンド サービスのトポロジは非常に複雑で、多くのモジュールがスケーラブルです。データの違いもパフォーマンス テストの結果に大きな影響を与えます。テスト環境と本番環境の違いにより、テスト結果に大きな違いが生じます。さらに、現在の本番環境のクラスターは、さまざまな場所でマルチアクティブになっています。夜間やトラフィックが少ないときは、1 つのクラスターですべてのトラフィック リクエストを処理し、残りのクラスターをストレス テストに便利に使用できるため、オンラインでパフォーマンス テストを行うこともできます。最も典型的な例は、アリババの「ダブルイレブン」フルリンクストレステストで、今年は基本的に昼夜を問わず完了しました。

2) さらに、セキュリティ攻撃と防御、フォールトインジェクションとドリルなど、実際のドリルテストの多くはオンラインシステムでのみ実行でき、オフラインテスト環境では実行できません。

3) 最後に、最終的な品質結果の観点から、リリース前のオフラインテストであれ、リリース後のオンライン安定性構築であれ、目的はシステム障害の発生を減らすことです。この2つの部分を組み合わせて、最終的なオンライン障害を減らすことを目的としたターゲットを絞った最適化作業を実行することで、人的資源を最大限に節約し、活用することができます。オフラインテストとオンライン安定性の統合は必然的に歴史的な傾向になると考えており、この領域は総称して技術的リスクの予防と制御と呼ばれています。

3 インテリジェントテスト技術

図3を参照してください。自動運転の分類と同様に、インテリジェント テストにも、手動テスト、自動化、支援型インテリジェント テスト、高度インテリジェント テストまで、さまざまな成熟モデルがあります。機械知能は、テストのさまざまな段階で適用シナリオを持つツールです。テストデータとユースケースの設計段階、テストケースの回帰実行段階、テスト結果の検証段階、オンラインインジケーターの異常検出など、多くの技術的リスク領域でさまざまなアルゴリズムとモデルを使用できます。インテリジェント テストは、ある段階までの開発の成果です。前提条件はデジタル化です。自動テストは、比較的単純な形式のデジタル化です。デジタル化や自動化がなければ、インテリジェントな分析や最適化の需要は実際には存在しません。

また、アルゴリズムの使用においては、いくつかの単純なアルゴリズムの使用は良い結果をもたらすかもしれませんが、より複雑なディープラーニングや強化学習アルゴリズムの効果は平均的です。その理由や難しさは2つあります。1つは特徴抽出とモデリングがより難しいことであり、2つ目はテスト実行のサンプルとフィードバックが不足していることです。しかし、いずれにせよ、最新のアルゴリズム技術を使用してさまざまなテスト段階の効率を最適化することが将来の方向性です。しかし、私たちは、自動運転のような高度にインテリジェントなテストはまだ未熟であると考えています。その主な原因は、アルゴリズムやモデルの不足ではなく、テストデータの不足です。

図3 インテリジェントテスト技術

Alibabaの検索推奨と広告システムの品質向上の旅は、ほぼ10年間の継続的な発展を経てきました。多くの先人たちの努力のおかげで、非常に多くのニッチな分野で成果を上げてきました。この記事で紹介した方法も、内部のツールと武器に凝縮されています。今後は、徐々にオープンソース化し、コミュニティに還元していく予定です。スペースが限られており、内容が多岐にわたるため、多くの技術的な詳細をここで詳しく説明することはできません。さらに詳しく知りたい方は、アリババ経済技術品質グループが出版するテスト本『アリババテスト』（電子工業出版社、仮題）に注目してください。本記事で紹介したビッグデータAIアルゴリズム応用テストは、第6章に収録されています。さらに詳細な理解が必要な場合は、当社のチームまたはオープンソース コミュニティに参加して、上記の方向でさらに詳細な調査と構築を行うことができます。