ABテストの準備方法。 ヤンデックス講義

YandexサービスのABテストが進行中です。 「そのような、そしてほんの一部の聴衆にロールアウトして」人々の反応を見ることは、チームの誰もがなぜこれが必要なのかという疑問を提起するような標準的な慣行です。 また、テスト自体に問題がないように、実験用の特別なインフラストラクチャがあります。 開発者のSergey MytsとDanil Valgushevが詳細を語っています。





セルゲイ：

-ABテストのタスクの説明を簡略化しようとします。 ユーザーとの抽象的なシステムがありますが、私たちはそれにいくつかの変更を加えており、その利点を測定できる必要があります。 これまでのところ、すべてはシンプルですが、あまりにも抽象的です。 例。 猫の写真をいくつか比較するためのWebサービスがあります。 ユーザーは、自分が一番気に入っている写真を選択する必要があります。 さらに、彼は左または右のショットだけでなく、「すべてに対して」選択することもできます。 そのため、私たちは写真をあまりうまく撮れませんでした。 私たちのタスクは、サービスを合理的に改善し、これを数字で証明することです。



どのように実験しますか？ まず、何が良いかを理解する必要があります。 システムを改善したい。 努力するものを選択する必要があります。必ずしも数ではなく、理想に向けた方向性を選択する必要があります。 ユーザーに、私たちが何も良いことを見つけられなかったということをできるだけ少なく言ってほしいと思うかもしれません。 障害をできるだけ少なくする。 また、ユーザーの選択を正しく予測できる場合にもおそらく良いでしょう。 次に、左の写真のように彼をもっと頻繁に作ってみましょう。 ユーザーが当社のサービスをより長く使用することもできます。 突然、私たちは広告をハングアップしたいと思うでしょう、そして、彼がサービスを使うほど、彼はより多くの広告を見ます。 そして、彼はサービスが好きだから、そして私たちにとっては、広告が好きだからです。 冗談。



この概念は、何らかの方法で測定するために数字で表示する必要があります。 良さの指標-指標を入力できます。 指標として-比較からの拒否の数、正しく推測された左の結果の数、彼の行動の数のためのサービスの加重平均ユーザー、個々の写真の時間など。私たちの意見では、私たちの理想を反映する個々のもの。



ここで、すべてを計算するためのデータが必要です。 ユーザーアクションを強調表示します。 おそらくボタンのクリック、マウスの切り替え。 同時に、どの写真が表示されたのか、特定のページにどれだけの時間を費やしたかを記録したいと思います。 メトリックの計算に役立つすべてのものをまとめましょう。



クライアント側でそれらを覚えることを学びます。 これがWebサービスである場合、いくつかのアクションをマークしてローカルに保存するのはおそらくJavaScriptです。 次に、それらをサーバーに伝達して各マシンに保存する方法を学習します。 そして、後でそれらを処理できるように、それらを集約してストレージに入れる方法を学びます。



私たちは何を望み、どのデータを探すべきかを知っています。 カウントすることを学びましょう。 メトリックの計算の実装が必要です-私たちの実験によれば、ユーザーが平均してそのようなメトリック指標を持っていると言う、ある種のプロセスです。 結果は簡単にアクセスできる状態で保存する必要があります。 計算するのは1回だけではなく、たとえば、マネージャーが分析に表示されるため、マネージャー自身がこのリポジトリに簡単にアクセスして結果を確認できます。



結果の検索があまり長くないようにしたい。 したがって、リポジトリは、結果の迅速な検索と表示を提供する必要があります-そのため、より速く移動できます。 内部用語を理解するためのいくつかの用語を紹介します。 実験サンプルは、次の2つのことを組み合わせたものです。実験機能を備えたフラグまたはパラメーターのセットと、これらの変更に含まれる人々のサブセット全体です。



実験は、いくつかのサンプルのコレクションです。 原則として、そのうちの1つはコントロールコントロールであり、ユーザーは実験せずにそこにサービスを表示します。 他のすべてには実験的なアクティビティが含まれます。 データスライスは、補助的な分析ツールです。 ほとんどの場合、おそらく限られたユーザーのグループでメトリックスを確認したいと考えています。 特定の国でのユーザーの行動に興味がある場合があります。 お金が彼らから来るので、私たちが商業的なリクエストの発行をどのように変更するか興味深いことがあります。 データストリーム全体ではなく、個々のスライスを見るのは興味深いことです。



実験を作成して実施することを学ぶ必要があります。 実験サンプルの説明では、この実験に含まれるパラメーターの説明を何らかの方法で決定する必要があります。 実験で2つの画像選択アルゴリズムを比較するとします。 最初は口ひげの観点から猫を好み、2番目はふわふわの観点からです。 その後、最初の実験サンプルには、Mustache = trueのフラグがあり、2番目のサンプルにはIs fluffy = trueがあります。



別の実験サンプルには、実験の実行を希望するユーザーの割合と、場合によっては制限（たとえば、どの国）が含まれます。 これは、実験サンプルの説明と変更に関するものです。 そして、実験を停止して実験を開始できるといいと思います。 健康を監視します。 大規模なシステムがある場合、すべてがいつ故障するか、または変更の結果として計画どおりに何かがうまくいかないときを理解することは有益です。



1つではなく、多くの実験を行いたい場合は、それぞれで何が起こるかを見ると非常に便利です。 たとえば、口ひげの分類器がもう少し機能し、応答時間を浪費する場合があります。 そして、これは時々非常に望ましい状況ではないかもしれません。



結論を導き、実験の指標を表示し、重要な変化があるかどうかを知る必要があります。 これらのメトリクスは、統計的基準によって大きな変化があることを示す何らかの種類のインターフェイスが必要です-いくつかの結論を見て、描きます。 すべてがすべてのメトリックで問題ないと主張される場合は、ロールバックする必要があります。 ひどくて理由がわからない場合は、理解する必要があります。 理解がなければ、次回はもっと仕事をすることができます。



また、モバイルの応答時間が無駄にならないようにするためなど、個別の重要なセクションの機能を検討することも役立つ場合があります。 そして、起こりうる問題や異常を検索するツールがあると便利です。 すべてのスライスを見るのはあなた次第ではありませんが、このスライスには誰もが傷つくほどひどいものがあることを伝えるツールがあります。 すべてが比較的単純なようです。



ダニル：

「そうでもない。」 私の名前はダニル・ヴァルグシェフです。 すべては簡単ではありません。 これは、Yandexが大企業であり、特定の例を使用してお話ししたい多くの興味深いニュアンスがあるためです。



基本的な検索だけではありません。 写真やビデオ、メール、地図、その他の多くのサービスで検索が行われます。



また、多くのユーザー、多くの実験者、実験があります。 各サービス内でも、改善したい多くの異なる領域があります。 検索では、ランキングアルゴリズムを改善したり、インターフェイスを設定したり、新しい機能を作成したりできます。



ユーザーは実験インフラストラクチャとどのように対話しますか？ 簡略図は次のようになります。 ユーザーがいます。Yandexには、実験のインフラストラクチャが構築されています。 ユーザーは結果を尋ねて受け取ります。結果は何らかの方法で実験によって変更されます。 Yandexには、実験用のアプリケーションを作成する開発者、マネージャー、アナリストがまだいます。 その後、それらを実施し、結果を分析するためのツールを提供します。



典型的な実験は3つのステップで構成されます。 マネージャーまたはアナリストは、最初に実際のユーザーで実験を行い、完了時に結果を分析して決定します。



たとえば、実験を行い、検索結果のレイアウトを改善することにしました。 アプリケーションを作成し、すべてのフィールドに入力する必要があります。 ロールアウト基準は、基本的なフロントエンドメトリックの改善であると書いています。 アプリケーションのタイプ-インターフェース。 次に、2つのサンプルを作成します。 1つは空、A、クリーンな生産です。 また、サンプルBには、goodInterface = trueなどのフラグがあります。 このフラグは、インフラストラクチャ全体をスキャンして、宛先、インターフェイスを生成するコードまでスキャンし、コードはこのフラグによってトリガーされます。 また、アプリケーションでは、メトリックで計算するターゲットスライスについて説明し、どの地域、ブラウザー、プラットフォーム、および実験を開始する割合について注意します。



アプリケーションに記入したとしましょう。 実稼働環境に展開することはできません。 最初にテストする必要があります。 テストには2つの目標があります。 手動テストと自動テストがあります。 手動-これは、実験の作成者が興味のあるすべて、必要なすべてのインターフェイスをクリックして、すべてが正しく機能するようにするときです。 自動化されたテストは、実験が実稼働に移行する際の問題を回避するように設計されています。



2つの例があります。特定のサービスモジュールの落下を確認するか、実験から評価評価を収集します。実稼働環境での非常に悪い実験を防ぐために、展開する前にテストします。 おそらく私たちが初めて実験を行っており、何も壊さないことを完全に確信していないという問題があります。 その後、当社の専門家が支援を求めます。



各サービスおよびサービス品質のあらゆる側面について、専門家が各アプリケーションごとにサービスを提供しています。 彼らは説明の明快さとフラグの正確さをチェックし、アドバイスを与え、追加のテストが必要かどうかを確認し、原則として実験に同行し、十分に得意でない人々を助けます。



申請が承認されたら、生産に入る必要があります。 これも問題を引き起こします。ユーザーは限られていますが、多くのアプリケーションがあります。 キューが形成されます。



1つの解決策は多次元スキームです。 1次元のスキームは、各ユーザーが1回の実験に参加することです。 そして、多次元-各ユーザーが複数の実験に入るとき。 当然のことながら、交差する実験は互いに競合するべきではありません。 通常、それらは異なるサービス、または1つのサービスの品質の異なる側面に関連しています。



生産を開始したとしましょう。 ユーザーはどのように実験に分割されますか？ 実際にルールを記述するいくつかの構成があります。 そして、この構成は決定グラフの形式で簡単に記述されるという結論に達しました。 グラフのリーフには実験があり、ノードにはリクエストパラメータの決定があります。リクエストパラメータには、たとえば、ユーザーID、リクエストテキスト、ページアドレス、地域、ユーザーエージェント、時間などが含まれます。



アプリケーションは、構成がロールアウトの準備をしている瞬間に構成に入ります。 構成は、古いチケットを削除して新しいチケットを追加することにより収集されます。 通常、ロールアウトは1日に数回行われます。



これも問題を引き起こします。 私たちはすべての実験をテストしたようですが、新しい構成を展開しても何も壊れないという保証はありません。 そのため、構成をロールアウトするときは、重要な検索インジケータを常に監視します-何かが発生した場合に正常にロールバックするため 通常、これは起こりませんが、私たちはまだ保証しています。



1つの実験が故障しても、故障の規模は小さくなります。 ここではより複雑で、すぐに表示されるわけではありません。クリック数、リクエスト数などの主要な指標について、各実験のグラフを作成する必要があります。 また、異常を自動的に検出するシステムがあり、スケジュールが不適切に動作し始めたときに通知します。 何かが間違っている場合は、緊急シャットダウンシステムもあります。



分割はどのように機能しますか？ ユーザーを分割して混同するようにし、同時に各ユーザーが同じ実験に入るようにする方法は？



簡単な解決策は、その識別子からハッシュを取得し、モジュロNを取得することです。N個の可能なディセントを取得し、それらをスロットと呼びます。 通常、このパーティション測定と呼ばれます。



その後、実験とアルゴリズムをスロットに掛けることができます。 しかし、問題がありました。 目の前で実験を行ったとします。この実験では、1つのサンプルのユーザーは良好で、もう1つのサンプルのユーザーは少し悪くなりました。 実験を無効にした後、ユーザーはそれに慣れ、異なる動作を開始しました。 そして、私たちが自分自身をオンにするとき、私たちはバイアスを持っています、AとBは等しくない状態にあります。



私たちのアルゴリズムはグラフであるという事実のため、私たちは耳でそのような気味を悪くすることができます：ユーザーが再びサンプルAとBに落ちる前に再びユーザーを取り混ぜてください。したがって、同じ条件を提供します。



多次元スキームも非常にシンプルに見えます。 グラフの横断を並列化する特別なノードがあります。 バイパスは各ブランチで独立して発生し、結果が追加されます。



異なるブランチで測定が行われる場合、通常、Salt1とSalt2-saltが使用されるため、それらは独立して戦い、互いに相関しません。



最後の問題は、構成の組み立て方法です。 それにもかかわらず、各実験には、パーセンテージ、地域、ブラウザ、プラットフォームなどの一連の制限があることに留意することが重要です。ここに例を示します-異なる地域に行く4つの実験。 たとえば、10個のスロットに配置する方法は？



このように配置すると、各スロットから各実験がわずかに食べられ、最後の実験は3つすべてと交差するため機能しなかったことがわかります。



ここでは、単純なヒューリスティックが非常にうまく機能します。 構成に新しいツールを配置するとき、通常、既にいくつかの実験があるスロットを選択しようとします。 そして、大胆な実験が広い限界に達したとき、私たちはそのための場所を残す必要があります。



そこで、私たちは実験を行い、うまくいったので、メトリックを調べました。 収集されたデータの量を理解するために、通常のメトリック、ユーザーリクエスト数、クリック数を必ず確認してください。 別の標準的な指標は、クリックされていないページの割合、CTRです。 さまざまな指標がありますが、クリックやクエリではなく、合成指標で受け入れられます。 これは別のトピックであり、レポート用ではありません。



そのような統計的検定があります。 実験を行ったときに、決定を下します。 まず、指標、製品の考慮事項によって展開基準を確認し、必ず専門家に相談してください。



完了後、実験はデータセットに進みます。 ストーリー全体を収集します。 まず、実験の方法に関するさまざまな研究を行うことができ、また新しい測定基準の検証にも必要です。





セルゲイ：

-これは、ツールのインフラストラクチャの一般的な概要です。 最初の2つのトピックについて話しました：対話インターフェイスで何ができるかと、パーティションの発生方法。 そして、実世界でのロギングでどのような問題が発生しますか？



多くのサービスと多くのデータソースがあるため、データ動物園があります。 サイズが異なり、速度も異なります。 すぐに準備ができるものもあれば、1日でできるもの、1週間でできるものもあります。 大きな問題は、このソースデータに従って責任が分散されることです。 各チームが独自のログを作成し、それらを収集します。 したがって、それぞれ個別に作業する必要があります。



動物園のデータにより、配信と集約の問題が発生します。 つまり、すべてのチームからログを収集する複雑なインフラストラクチャと適切に機能するプロセスを開始する必要があります。 同時に、社内全体でデータを処理し、独自のパーサーを使用して各チームに行かないようにするために、互換性のあるデータ形式があればいいと思います。 ここでは、ログを操作するための一般的なライブラリが役立ちます。



最後に、データを1か所に集約して保存する必要があります。この場所でさらに処理するのが便利です。 ライブラリを作成する個別の特別チームがあり、個々の低レベルおよび高レベルのログ収集プロセスのデータ配信の時間を担当します。 したがって、実験チームはタスクを簡素化し、すでに準備が整っています。 ログを操作するための共通ライブラリがあります。適切なアクセス権を持っている場合、アナリストはその助けを借りて、会社のすべての主要なログを解析できます。 すべてのデータは、システム内のMapReduceの下のストレージに保存され、MapReduce計算で処理されます。 独自のYTシステムがあり 、検索することができ、それに関する報告があります。



配信されたデータは、カウントする必要があります。 分散データ処理では、計算は数百テラバイトとペタバイトになります。 インターフェイスの観点から見ると、必要な数値を取得するために、実験とデータスライスの任意の日が必要です。 そのため、何らかの方法でデータを準備する必要があります。 データを特別な方法でスタックするスクイーズを作成して管理します。これにより、バイナリ検索やその他の特別な前処理されたインデックスによって、ファイルシステム内でデータをすばやく見つけることができます。



その結果、非常に複雑な実験と大量のデータがある場合、個々のツールは数秒または数分で社内で実施された実験の数値をアップロードできます。



多くの実験-多くの潜在的な問題。 サービスは非常に異なり、個別に開発され、独自の機能があり、それぞれが実験を行い、誰でも独自の方法で何かを壊すことができる共通のポイントでそれらを収集します。 したがって、監視は非常に必要かつ重要です。 最初の提案は、収集されたログの集計に時間がかかることです。そのため、カウンターを壊すために監視することをお勧めします。 少なくとも、リクエスト、クリック、または単純なアクションの数をカウントする必要があります。 このデータは非常に迅速に準備され、そこから何かが完全に間違っていることがわかります。



一方、問題は複雑になる可能性があり、個々の数値だけでなく特定のメトリックで何かがうまくいかないことがあります。 たとえば、ユーザーはインターフェイスでの時間を短縮したり、逆にユーザーのタスクをより長く解決したりできます。 , , . , , - . , . .



, , : , . . , , . . , , . , -, - . .



: - . . , , , , , - - . , , , .



— , , . , , . , , .



, . , , . , . , , .



, , . , n , , . . , .



— . . - , , , , . , .



, . ありがとう