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

[[324462]]

アリ姉の紹介：近年、データコンピューティング能力と機械知能アルゴリズムの台頭により、ビッグデータAIアルゴリズムの応用がますます普及し、さまざまな業界でビッグデータアプリケーションが継続的に登場しています。エンジニアリング技術の一部として、テスト技術も時代の変化に合わせて進化しています。現在の DT 時代では、ビッグデータ ベースのアプリケーションのソフトウェア品質をどのようにテストし、保証するかが、テスト業界における難しい問題となっています。

この記事では、アリババ 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 つの場所にあります。

a. サンプル特徴品質の評価

b. モデル品質の評価

c. オンラインモデル推定サービスの品質保証

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アプリケーションのエンジニアリング効率

主に、この方向でテストとR＆D段階の効率を改善する問題を解決します。DevOpsツールチェーンの構築と、開発、テスト、エンジニアリング、モデルのリリース、モデルデバッグポジショニング）、顧客フィードバック（物理的評価、群衆のテスト、顧客の問題のデバッグ）など、R＆D閉鎖全体で使用されるツールの構築に焦点を当てています。 DevOpsシナリオでは、開発者はこれらのツールを使用して、要件の開発、テスト、リリースを独立して完了し、顧客フィードバックを処理できます。この方向はテスト自体とはほとんど関係がないため、スペースの制約によりここでは省略されます。

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

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

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

これには、サーバー側でのテスト変換の問題が含まれます。将来的には、フロントエンドとユーザーの相互作用の側面の製品の品質を制御することに焦点を当てます。ほとんどのサーバー側のテストタスクは自動化でき、多くのサービスレベルの検証は自動化を通じてのみ検証できます。テスターと比較して、開発者はAPIレベルでの自動コード開発においてより能力があります。さらに、最初の部分で述べたように、アルゴリズムエンジニアはビジネスロジックをより明確に理解しています。

したがって、バックエンドテスト作業は、エンジニアリングまたはアルゴリズムエンジニアによって独立して完了することを好みます。テスターは、自動化されたテストフレームワーク、テスト環境展開ツール、煙検査ツールの解放、継続的な統合、展開など、テストツールの研究開発により焦点を当てています。このモデルは、Googleが今年この方向に変換しようとしているテストモデルでもあります。テストの変革をリードしている国内のインターネット企業として、私たちの仲間に何らかの参照を提供できると思います。ここで強調する必要があるのは、テストチームがこの方向に変換したが、唯一の違いは、この記事で導入された多数のバックエンドテスト技術と方向性が存在することです。パフォーマンスツールに加えて、バックエンドサービステストチームの変換のために、5番目の部分でのオンライン安定性の構築は非常に良い方向です。

2。オンラインテスト、すなわちチップ（生産のテスト）

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

1）一方で、オフラインテスト環境と実際のオンライン環境の間には常にいくつかの違いがあります。または、そのような違いを排除するには、テストの結論が信頼できなくなるため、大きな継続コストが必要です。最も一般的に使用されるのは、バックエンドサービスのトポロジーが非常に複雑であり、テスト環境の違いに大きな影響を与えます。さらに、現在の生産クラスターは、夜間またはトラフィックが低い場合、すべてのトラフィックリクエストを処理でき、残りのクラスターはストレステストに便利に使用できます。最も典型的な例は、アリババのダブルイレブンフルリンクストレステストです。これは、今年は基本的に昼夜のモードで完了しました。

2）さらに、多くの実際のドリルテストは、オフラインテスト環境では実行できないセキュリティ攻撃や防御、障害の注入、ドリルなどのオンラインシステムでのみ実行できます。

3）最終的な品質の結果の観点から、リリース前のオフラインテストであろうと、リリース後のオンライン安定性の構築であろうと、これらの2つの部分を組み合わせて、最終的なオンライン障害を減らすことを目的としたターゲットの最適化作業を削減することが目的です。オフラインテストとオンラインの安定性の統合は必然的に歴史的傾向になると考えており、この分野は集合的に技術的リスクの予防と制御と呼ばれています。

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

図3を参照してください。自律運転の分類と同様に、インテリジェントテストには、手動テスト、自動化、インテリジェントテストの支援、非常にインテリジェントなテストまで、異なる成熟モデルもあります。マシンインテリジェンスは、テストデータとユースケースデザイン段階、テスト結果の実行段階、オンラインインジケーターの異常検出など、さまざまなアルゴリズムとモデルのアプリケーションシナリオを使用できます。インテリジェントテストは、特定の段階の開発の積です。デジタル化や自動化がなければ、実際にはインテリジェントな分析と最適化に対する需要はありません。

さらに、アルゴリズムの使用には、より複雑な深い学習または補強学習アルゴリズムの効果があるのは、2つの場所であることです。しかし、いずれにせよ、最新のアルゴリズムテクノロジーを使用して、さまざまなテスト段階の効率を最適化することは将来の方向です。しかし、自律運転のような完全にインテリジェントなテストは、主にアルゴリズムやモデルの欠如ではなく、テストデータの不足のためではなく、まだ未熟であると考えています。

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

Alibabaの推奨事項と広告システムの品質改善の旅は、多くの前任者のハードワークのおかげで、非常に多くのニッチな分野で実を結びました。スペースが限られており、さまざまなコンテンツがあるため、多くの技術的な詳細をここで詳しく説明することはできません。詳細を知りたい場合は、Alibaba Economic Technology Quality Groupが公開するテストブック「Alibaba Testing」（電子産業プレス、暫定タイトル）に注意を払うことができます。さらに詳細な理解が必要な場合は、上記の方向でより詳細な研究と構造を行うために、チームまたはオープンソースコミュニティに参加できます。