どんなオンラインプロジェクトでもより良くすることができます。 新しい機能の実装、サーバーの追加、インターフェースのやり直し、またはAPIの新しいバージョンのリリース。 あなたのユーザーはそれを好きになるでしょう。 かどうか？ そして一般的に、彼らはどのような人々ですか？ 若いですか、それとも高齢ですか？ 安全か、それとも反対ですか？ モスクワから？ ピーター？ カリフォルニア州サンフランシスコ？ 最後に、5月に購入した暖かい毛布100枚が倉庫に散らばり、オクトコットの付いたTシャツがホットケーキのように散らばっているのはなぜですか？ 回答を得ると、プロジェクトの評価Mail.Ruに役立ちます。 この記事では、データマイニングを使用して最も難しい質問に答える方法について説明します。



もちろん、1つの投稿ですべてのことを話すことは不可能なので、特定の問題を解決する例でユーザーの収入のカテゴリを決定することで、アプローチを説明します。 車に関するブログがあり、その中に高価な自動車販売店のオファーの広告を表示するとします。 あなたのブログがあまり裕福でないユーザーによって主に読まれることを学んだので、あなたはあなたの戦略をレビューして、パーツ広告を表示します。 岡用。



評価はどこから来ますか？ ユーザーの性別を調べる必要がある場合は、Mail.Ru Mailの登録データ（登録時に不正行為を行うユーザーは非常に少ない）とソーシャルネットワークのプロファイルが使用されます。 都市を知る必要があります-助けになるIP。 特定のユーザーの収入が高いかどうかを判断することは、はるかに困難です。



開始するには、トレーニングセットが必要です。 このようなサンプルを取得するのは非常に現実的です-世論調査の結果、パネル調査、または友好的なプロジェクトのデータを使用できます。 収入カテゴリを決定するタスクのトレーニングサンプルは、HeadHunterサービスのユーザーの給与希望に関するデータに基づいてコンパイルされます。 サンプルから、性別、年齢、居住都市、収入カテゴリ、雇用地域など、ユーザーの多くの特性を把握しています。 そして、評価識別子はMail.Ruです。 評価データを使用してサンプルからユーザーの行動をモデル化するため、後者は特に重要です。 これにより、解決する問題を定式化できます。



目的：既知のカテゴリの個人所得を持つ約100万人のユーザーを含むトレーニングサンプルを使用して、評価に従って、新しい未割り当てユーザーが5つのカテゴリーのどれに属するかを予測できるモデルを開発します：1-低収入、2-平均以下の収入、3-平均収入、4-平均収入より上、5-高収入。

入力-ページビューログ

サイトの統計を取得するには、ページに評価カウンターコードを追加する必要があります。 各訪問のデータはカウンターによって収集され、サーバーに送信され、そこでログとして保存されます。 ログの各訪問（同義語：hit）は1行に対応します。 たとえば、次の図では、1行目は4月9日正午頃のA21CEによるhi-tech.mail.ruへの訪問に対応し、2行目はhoro.mail.ruへの訪問に対応しています。







ユーザーが訪問したページに関するこのデータが十分にあれば、このユーザーの収入カテゴリを非常にうまく予測できることがわかります。 アイデアを説明するために、写真はいくつかのサイトのユーザーの収入カテゴリ別の分布を示しています。





^{（クリック可能）}



先験的分布は青色の領域でマークされています。たとえば、平均未満の収入を持つユーザーのシェアは0.39で、高収入のユーザーのシェアは0.08です。 左のグラフは、hi-tech.mail.ruの訪問者にとってこの比率が異なることを示しています。このサイトのユーザーのほぼ12％が金持ちで、貧しい人の割合は一般人口よりも少ないです。 rabota.mail.ruの場合、状況は逆です。仕事を探している人々の中で、貧困層の割合は「通常」を上回っています。 他の多くのサイトでも、状況は似ています。たとえば、裕福なユーザーは航空会社のサイトに行くのが多く、ユーザーは通常ローンをよりよく探します。 したがって、ユーザーがどのサイトにアクセスしているかを知ることにより、収入カテゴリについて合理的な仮定を立てることができます。 ログで利用できる他のユーザー情報は、たとえば、性別（平均グラフ-男性の収入が高い）や使用されているブラウザ（右グラフ-サファリ愛好家はIEを好む人よりも突然豊かになります）に役立ちます。



小計を合計します。 これがアクションプランです。ユーザーがアクセスしたサイトやその他の利用可能な情報を分析し、収入カテゴリについて合理的な仮定を立てます。 簡単ですね。 しかし、問題があります。多くのユーザーがいるため、手動分析は不可能です。 数千万。 また、圧縮ログのサイズは1分あたり500MBに達します。 データマイニングは不可欠です。

訪問ログを特徴ベクトルに変換する

KDDプロセス（およびその類似物： one 、 two ）によると、データマイニングの問題の解決は機能エンジニアリングから始まります。 この段階は最も重要であると同時に最も骨の折れる作業です。 半構造化されたページ訪問ログから機能を強調表示します。 この図は、3人の実際のユーザーの日次ログを示しています。 1日の分（0-1439）は水平軸にプロットされ、対応する分（0-59）の秒は垂直軸にプロットされます。 各ポイントはサイト訪問です。 明確にするために、サイトは異なる色で表示されます。 上のグラフのユーザーは、主にデート（赤いヒットが一般的なデートサービスに対応）とコンピューターハードウェア（青と緑のヒット）に関心があります。 さらに、主な活動は夜に発生します（誰かが自分自身を認識しましたか？）。 2番目のユーザーも会議（緑のヒット）に対してではなく、勤務時間中です。 3番目は、この非作業時間に費やします-夕方とおそらく昼休み。





^{（クリック可能）}



表されたユーザーはデートに似た関心を持っていますが、行動パターンは異なります。活動の期間、ヒットの数と頻度は異なります。 この違いを滑らかにするために、Webマイニングでは、セッションでのユーザーヒットのストリーム、つまりインターネットでの継続的なアクティビティの間隔を分割することが慣習となっています。 セッションの選択には多くのアプローチがありますが、次の単純なルールに決めました。



（1）2つのヒットの間隔が20分を超えない場合、2つのヒットは同じセッションに属します

（2）セッションは最後のヒットから20分間続きます。



グラフ上のユーザーのセッションは灰色で強調表示されます。 受信したセッションに基づいて、ユーザーのアクセス履歴を機械学習アルゴリズムに入力できるマトリックスに変換します。 このマトリックスの各行はユーザーに対応し、各列は属性に対応します。 Habrはゴムではないため、ここでは、使用する最も単純なオプションに焦点を当てます。各属性は、訪問したページのURLから抽出された単語です。 たとえば、すでにおなじみのログの一部：







そのような行列に変換されます：

	ハイテク	メール	ホロ	例
A21ce	1	2	2	0
B0BB1	0	1	0	1

この場合の特定のユーザーの特性値は、この属性が発生したユーザーセッションの数です。 原則として、しきい値を使用して特性の値を2値化することができます。または、たとえばidfによって、多くの計量オプションの1つを適用できます。 実験により、これらの正規化はいずれもモデル品質の向上につながることが示されています。 二値化に決めました。

機能の選択

すべての症状が同じように役立つわけではありません。 ページ属性のゼロ以外の値の存在は、ユーザーの収入については何も言っていません。これは、ページはページ番号を示す単なる技術用語であるためです。 対照的に、宝飾品属性の値が0以外のユーザーは宝飾品を探している可能性があり、これは宝石を「リッチ」として分類するのに役立ちます。 症状を分析するとき、次の考慮事項を使用します。



（1）症状は統計的に信頼できる推定値を与える必要があります。 たとえば、 テストには多項テストが使用されます。

（2）症状は有益であるべきです。 冗長性などの情報基準が検証に使用されます。



この図は、各カテゴリーを最もよく反映する標識を示しています。 たとえば、リッチユーザーの大部分は、IT-news属性に対応するマトリックス列の重みがゼロではありません。 どうやら、ITスペシャリストであることは非常に有益です。 貧しい人々のカテゴリーは、スキルの低い仕事に関連する兆候により適しています（「営業アシスタント」、「経験なし」）。





^{（クリック可能）}



有益で統計的に信頼できる特徴のみを選択すると、より小さなサイズの行列が得られ、これが機械学習アルゴリズムへの入力になります。 この行列x [i、j]の要素は、 i番目のユーザーのj番目の属性の重みです。 公平を期すために、ユーザーが訪問したページを反映するトレーニングサンプルに加えて、たとえば人口統計データやページコンテンツに基づいて、さらにいくつかのサンプルを作成します。 トレーニングサンプルごとに個別のモデルが構築され、その後、すべてのモデルが結合されます。

モデリングと結果

分類問題の特異性は、データ行列が大きな次元（数百万行と数万列）を持ち、同時に非常にまばらであることです。 したがって、スパース行列で機能する学習アルゴリズムの実装が使用されます。 ここでは自転車を発明しません-クロスエントロピー損失関数を持つロジスティック回帰と最大値の線形モデルの集合を使用します。 このようなモデルは、いくつかの理由で優れています。 まず、特に分布p（x | class）が指数関数的な分布族に属する場合、クロスエントロピーはかなり一般的な仮定の下で自然に発生します（詳細については、パターン認識と機械学習を参照してください// C. Bishop and Machine Learning：A Probabilistic視点// K.マーフィー）。 第二に、SGDアルゴリズムを使用すると、スパースデータを含むそのようなモデルを効果的にトレーニングできます。 第三に、モデルのシリアル化は重みのベクトルの単純なストレージに削減されるため、保存されたモデルはO（属性の数）のみのメモリを使用します。 第4に、モデルの適用には、決定関数の迅速な計算のみが必要です。 トレーニングマトリックスでは、バギングを使用して線形モデルのアンサンブルを作成します。 最終的な予測は、アンサンブルの投票に基づいて行われます。



問題の分類の品質を評価するための主要な指標はアフィニティです（より一般的な名前はLiftです）。 このメトリックは、モデルがランダムより優れていることを示しています。 たとえば、リッチユーザーのカテゴリを考えます。 一般ユーザーにおけるこのようなユーザーの割合は7％です。 許容範囲（リコール）のモデルの精度（精度）が21％である場合、アフィニティはアフィニティ= 0.21 / 0.07 = 3.0と見なされます。 この場合、ユーザーのカテゴリーへの出力分布が入力とほぼ一致するように、再呼び出しが構成されます。 表は、構築されたモデルの相互検証メトリックを示しています。 モデルが非常に良い結果を与えることがわかります。

クラス	ソース配布	得られた分布	精度	リコール	親和性
1	69720（0.125）	18609（0.033）	0.281	0.075	2.245
2	223358（0.400）	274519（0.492）	0.492	0.605	1.229
3	134024（0.240）	93075（0.167）	0.316	0.220	1.317
4	91448（0.164）	118506（0.212）	0.246	0.319	1.502
5	39353（0.071）	53194（0.095）	0.233	0.315	3.301

分類結果を詳しく見てみましょう。 私たちの場合、カテゴリの順序により、すべてのエラーが同様に深刻なわけではないことは明らかです。 「平均以上」のカテゴリを「リッチ」なユーザーに割り当てるのは怖くありません。「貧しい」と呼ぶのはまったく別の問題です。 この図は、ユーザーの予測カテゴリと実際のカテゴリを比較するためのアフィニティマップを示しています。 各セルの値は次のように計算されます：







言い換えれば、 jとして予測した人々の中でのiカテゴリーのユーザーの割合を、一般集団のiカテゴリーのユーザーの割合で割ったものです。 したがって、対角線では、Precision / TrueFraction = Affinityになります。 理想的な分類器は、そのような行列の要素の非ゼロ値を対角線上にのみ与えます。 図から、隣接するカテゴリを混在させることができます（3つの「正方形」：金持ちは平均を上回り、中央は平均を上回り、貧しい人は平均を下回る）が、総誤差の割合はかなり小さい。 収入カテゴリへの分割はかなりarbitrary意的であることを考慮して（正直に自分のカテゴリを定義してみてください）、隣接するカテゴリ間のあいまいさは理解できます。 また、両極端が最もよく定義されていることに注意してください-金持ちと貧乏人、そしてすべての最悪-中間のカテゴリ。 これが成功するのは、それが通常ビジネスに関心を寄せるのが極端であるためです（私の視聴者、経済、プレミアム）。







プロセスの最後のステップは、割り当てられていないユーザーにモデルを適用することです。 このようなユーザーは何千万人もいます。それぞれのユーザーに対して、選択された特徴のベクトルが計算され、トレーニングされたモデルが適用されます。 モデルの最終的な品質管理は、パネル調査に参加しているユーザーのデータに基づいて実行されます。 予測収入カテゴリは、評価Cookieに記録されます。 カウンターはこれらのCookieを読み取り、サービスの統計をカウントします。 インターフェイスに表示されるのはこれらの統計であり、ビジネス上の意思決定に使用できます。 タスクは閉じられています。

最終的な考慮事項

収入のカテゴリを決定するタスクの例に関する記事では、プロジェクトRating Mail.Ruのユーザーを分類する問題を解決するために使用されるアプローチについて説明しました。 この記事のレビュー形式では、たとえばプロセスのさまざまな段階（主にHadoopで）の実装の微妙さなど、技術的な詳細を掘り下げることはできませんでした。 また、簡潔にするために、ボットと1日のユーザーのフィルタリング、セマンティック属性の構築、異なるトレーニングサンプル用に構築されたモデルのアンサンブルのコンパイル、構築されたモデルの検証アプローチなど、いくつかの重要なサブタスクを省略しなければなりませんでした。 これらはすでに少し異なる物語です。今後の出版物のためにそれらを残しましょう。