9月の先週末、私たちのチームはM.Videoデータ分析ハッカソンに参加しました。 次の2つのタスクから選択できます。1つ目は製品レビューに基づいて製品説明を生成すること、2つ目はディレクトリ、共同ビューのデータ、バスケットに追加することに基づいて商品の最も重要な特性を強調することです。 両方のタスクを解決しました。 カットの下には、このハッカソンに失敗した理由と学んだことの物語があります。
問題の声明
私たちのチームがハッカソンの開始前に会ったとき、私たちは問題や希望の明確な声明の欠如に困惑していました。 最高のものがない場合、私たちは自分でアイデアを生み出し始めました：
- 顧客の苦情処理システム。
- 推薦システム;
- さまざまな製品をナビゲートするためのアルゴリズム。
- 他のサイトの製品に関するデータを収集するシステム。
ビュー、コンバージョン、平均請求額、ロイヤルティなどのビジネス指標の測定可能な増加を夢見ました。 数日間、私たちはインサイダーから情報を引き出しようとしましたが、その結果、より混乱しました。 土曜日にM.Videoのオフィスに到着したとき、何ができるかについていくつかの選択肢がありましたが、実際に尋ねられたものと一致するものはありませんでした。
商品の説明を作成するか、商品の最も重要な特性を特定する必要があることが判明しました。 そして、測定基準はありませんが、審査員の目はあります。
私たちのチームの3人のエンジニア全員が、私たちにとって正しいと思われるタスクを解決するために座っていました。 データの新規性と多数の実験を考えると、一晩かかった。 夜遅くまでに、私たちは午前中終わろうとしていた中間的な解決策がありました。 期限までに、互いにほとんど関係のない3つのアルゴリズムがありました。 疲れたクリエーター以外は誰もアルゴリズムのレビューをしませんでした。 私たちが上位3位に入らなかったのは驚くことではないようです。 しかし、アルゴリズム自体は注目に値するようです。
レビューから圧縮された製品説明を抽出する
2つのハッカソンの割り当ての最初は、 自動テキスト要約のタスクとして定式化されました。 製品の一連の顧客レビューに従って、製品に関する最も重要な情報を含む1つの総合レビューを生成するアルゴリズムを作成する必要がありました。 総合レビューの正式な要件はなかったため、独自のウィッシュリストを作成しました。
- 合成リコールは、製品に関する個別のステートメントで構成されています（何らかの構造が必要です！）。
- 各ステートメントから、それが作成された根拠に基づいてそれらのレビューに移動できます（信じやすくするため）。
- 各ステートメントは、可能であれば、複数の実際のレビューに基づいている必要があります（信頼できる情報が大好きです）。
- ステートメントは、製品が対応する製品とどのように異なるかを示さなければなりません（そうでなければ、役に立たない）。
これらの要件から、アルゴリズムの一般的なスキームに進むことがすでに可能です。
- テキストレビューの前処理。 各単語は単語に分解され、各単語はpymorphy2によって標準形（不定詞の動詞、単数の主格の名詞など）につながりました 。 これは、単語をより正確に数えるために必要です。 さらに、いくつかの特別な単語を導入しました。数字のシーケンスは<NUMBER>に置き換えられ、正と負の色の絵文字は<SMILE_POS>および<SMILE_NEG>に置き換えられました。
- 言葉を量る。 各製品のレビューで正規化された各単語が何回出現するかを計算しました。 レビュー内の単語の出現ごとに、このカテゴリのすべての商品の中で、その単語が使用されているレビューのシェアの逆数である重みが割り当てられました。 したがって、情報量の少ない単語の影響を軽減しようとしました。 たとえば、ヘッドフォンへの応答にある「HEADPHONES」という単語は、情報の負荷を運びません。 しかし、この製品のリコールでのみ見つかった単語には、重み0も割り当てました。 これらは通常、比較が難しい非常に具体的な概念です。 たとえば、同じヘッドフォンへの応答にある「JBLAWAREBLKI」という言葉も意味がありません。名前だけです。 したがって、ウィッシュリストを実行しました（4）。
- 承認のために各レビューをスライスします。 これを行うために、私たちはそれを文に分割しました（句読点のみ）。 文は、2語と3語のさまざまな部分（nグラム）に分割されました。 文はすべての文とすべてのn-gramと見なされました。
- ステートメントの数値形式への変換。 各ステートメントについて、段落3 の重みで重み付けされた、それに含まれる単語の平均埋め込みを見つけました。 埋め込みは、 誰かが訓練したword2vecモデルからアンロードされた100個の数字のベクトルです。 添付ファイルの主な特性は、同様の意味の単語の場合、添付ファイルも通常同様であり、その逆も同様です。 そして、それが何らかの意味を伝えることを期待して、各ステートメントの「加重平均語」を計算しました。
- グループ化。 各製品について、この製品に関するすべてのベクトル化されたステートメントでDBSCANクラスタリングアルゴリズムを開始しました。 言い換えれば、互いに類似したステートメントからグループ（クラスター）を見つけました（つまり、類似の埋め込みベクトルによって記述されています）。 検出された各クラスターには、原則として製品に関する重要な事実が含まれている必要があります。 どのクラスターにも含まれていないステートメントを除外しました（DBSCANは、これを実行できる数少ないアルゴリズムの1つです）。
- クラスターランキング。 各クラスターについて、その評価（クラスターに含まれるすべてのステートメントの単語の重みの合計）を計算しました。 1つのレビューのみからのステートメントを含むクラスターの評価に、ウィッシュリスト（3）を満たすために削減係数を適用しました。 製品ごとに、最大評価の5つのクラスターを使用しました。
- クラスター内のクレームのランキング。 選択された各クラスターで、最適な方法でそれを説明する唯一のステートメントを見つけることが残ります。 これを行うために、クラスター内の各ステートメントの評価を、このステートメント内の単語の平均重みを、そのステートメントからクラスター内の他のステートメントの投資までの平均距離で割って計算しました。 1.分子は、ステートメントが有益であり、分母-意味がクラスター全体と十分に一致することを保証する責任があります。 そして、選択されたクラスターのそれぞれについて、ウィッシュリスト（1）および（2）を満足する総合評価で最大評価のステートメントを作成しました。
その結果、次のような総合的なレビューが得られました（テレビで）。
- 水平視野角は壮大です
- 良い画質
- 素晴らしい写真
- キッチンで買った
- 音がいい
最初の例では、アプローチの長所と短所が見えます。 さらに、レビューが読みやすいこと。 マイナス-たとえば、2つと3つのステートメントを組み合わせることができますが、クラスタリングが詳細すぎることが判明しました。 残念ながら、注視法を除いて、合成レビューの生成の品質を確認する方法を思いつきませんでした。 また、綿密な（しかし大雑把な）外観の方法は、レビューに構造が欠けていることを示しましたが、一般的には適切に見えました。
レビューから重要な製品特性を抽出する
作業の別のブランチは、レビューの感情的な色付け（ 調性 ）に関連していました。 ほとんどのレビューで、1から5の製品評価が付けられましたが、予選でも、調性を決定する問題を解決しました -レビューのテキストに従ってそれを予測しました。 これを行うために、正規化された各単語がバイナリ変数に変換され、線形回帰が学習されました。 このようなモデルで単語の前に大きな正の係数があるということは、肯定的なレビューで通常見られ、否定的なレビューで見られることを意味します。 係数（モジュロ）が大きいほど、単語は商品の評価に強く影響します。
製品ごとに、すべてのレビューにそのような回帰を構築しました（多くのレビューがある場合。係数を並べ替えると、この製品について最も「ポジティブ」および「ネガティブ」な単語を見つけることができます。それらを除外するために、特別なブラックリストを作成する必要がありました。これを行うには、絶対にすべての製品の調性モデルを構築し、そこから最も重要な係数を引き出しただけでした。 IPA "良い/悪いです"。
ブラックリストによるフィルタリング後に残った単語は、非常に有益なものであることが判明しました。 たとえば、iPhone 6の場合、「静かな」という言葉は負の係数が最大であることが判明しました。実際、これは所有者が不満を抱いている主な問題の1つです。
おそらく、合成レビューに商品の特性の感情的な評価を埋め込むと、勝利を保証するのに十分魅力的なものになります。 しかし、私たちは最後の瞬間まで自分のモデルをデバッグし、通常の統合の代わりに、あるアルゴリズムの出力を別のアルゴリズムの下に単純に書き留めました。
ユーザーの行動の重要な兆候を検索する
レビューに加えて、製品の表示とバスケットへの追加に関する情報がありました。 ビューの購入への変換を決定するのは、製品のどのプロパティであるかを調べることにしました。 すべての製品について、ディレクトリからの特性、寸法、画面解像度、プロセッサブランドなどがありました。 それらをバイナリタグに変換しました。 商品のカテゴリごとに、製品をバスケットに追加する確率を予測するロジスティック回帰を構築しました。 商品の特性について得られた係数は、購買決定を行う際にこれらの特性の重要性として解釈することもできます。 さらに、レビュー内の単語とほぼ同じ方法でそれらに対応しました。頻度の重要性を再重み付けし、各セマンティックグループから最も重要な記号を選択しました。 その結果、製品ごとに消費者の行動の観点から最も重要な特性を受け取りましたが、それらをレビュー分析の結果と組み合わせることはできませんでした。
思慮深い結論
ハッカソンの主催者に、おもしろい仕事、質の高いデータ、おいしい食べ物をありがとう。 一般的な印象では、これらの1日半は非常に良かったです。
ハッカソンの組織の観点から見ると、最初から発表された品質基準だけでは十分ではなく、どのソリューションを比較するかによって異なります。 未知の関数を最大化することは、最も生産的な活動ではありません。 ハッカソンの前には、問題に関する明確な声明がまだ十分ではありませんでした。「サイトでのレビューの集計」および「ストアで商品を選択するためのアシスタントセラー」というフレーズは、お望みどおりに解釈できます。
後から考えてみると、このような状況でも、私たちのチームは白鳥、ガン、カワカマスのような異なる方向に急いで行くべきではないことはすでに明らかです。 出力で取得したい製品の理想的な説明がどのように見えるかをすぐに判断する価値がありました。 ハッカソンの最初の数時間から、私たちはどの方向にも集中することができ（どちらが重要であるかはそれほど重要ではありません）、夕方には実用的なプロトタイプができます。 次に、共同デバッグの2日目に、既に動作する製品にそれをもたらします。
いずれにせよ、再利用可能なコード 、大量の商品、そして最も重要なことには、経験を得ました。 店舗の単純なタスクを解決するために、機械学習の入門コースのほぼ半分を取りました。 しかし、いつものように、すべてはプログラミングと数学の知識ではなく、組織の能力によって決定されました。