プレビュー

こんにちは、Habr！ 2016年4月25日、3か月間の激しい競争であったHome Depot Product Search Relevanceが終了し、チューリングテストチーム（ Igor Buinyi 、 Kostiantyn Omelianchuk 、 Chenglong Chen ）が自然言語処理とMLをうまく処理できただけでなく、3 2125チーム中7位。 ソリューションとコードの詳細な説明はこちら 、短いインタビューはこちら 、この出版物の目的は、そのような結果をもたらしたソリューションだけでなく、競技中に経験しなければならない困難や経験についても話すことです。

Kaggleについて一言

ほとんどの読者はおそらくKaggleに精通しているでしょう。 残りについては、現時点では、これがデータサイエンストピックに関するかなりの数のコンテストが常に開催されている世界最大のプラットフォームであり、数千人の参加者の集合的な精神が実際の応用問題に対する多数のソリューションを生成することに注意してください。 その結果、競合他社は知識と経験を受け取り（受賞者も賞品を受け取ります）、オーガナイザーは実践に役立つアイデアを受け取ります。

問題の声明

-修理ツールと建築材料を販売するウェブサイトがあり、より多くの特定の商品を見つけることができます

-検索機能を使用して、興味のある製品を見つけようとしているユーザーがいます

-数十万の「検索クエリ」/「表示された製品」の一致があります。 製品情報は、名前、説明、多くの属性（ブランドや色など）などの複数のテキストフィールドで構成されます。

-そのような通信の一部について、評価者からの関連性の平均評価がある

-タスクは、評価者が残りの要求/製品のペアに対して行う関連性の推定値を適切に予測するアルゴリズムを構築することです



なぜこれが必要ですか？



「要求」/「製品」の一致を選択する検索アルゴリズムを最適化する場合、関連性の評価が必要です。

評価者はそのような評価を行うことができますが、動作は遅く、時間は高価または自動です。評価者を節約し、フィードバックの速度を大幅に上げることができます。 ただし、評価の品質は同じレベルに維持する必要があります。



評価者は間違っている可能性のある人々です



私たちはモデルに、評点を付けた人の行動を模倣するように教えました（それ以上のものはありません）。 彼らの評価が「真の関連性」にどのように対応するかという質問への答えは、常に特定の仕事から哲学の起源へと導きます。



モデルの品質はどのように評価されましたか？



メトリックとして、RMSEが使用されました。これは、他の2次メトリックと同様に、ほとんどすべての大きなエラーに対処します。





ソースデータは何でしたか？



データは、「検索語」/「製品」のペア（製品タイトル、製品の説明、属性の3つの部分で構成される）と平均関連スコア（一部の小数を含む1〜3の値をとる）で構成されました。

列車/テストの内訳は、74 067/166 693の割合で行われ、ランダムではありませんでした（テストのみまたは列車のみに存在するリクエストが多く、それらの分布は正規とは言えません）。

データがかなり汚れていた（クエリの文法エラーが多数）

私たちについて少し

5/6コンテスト中の私たちのチームは、2人（Igor BuinyiとKonstantin Omelyanchuk）で構成されていました。 私たちは両方ともウクライナのブラウザゲーム会社で働いている分析の同僚です。 このコンペティションの開始前、私たちの背後には多くのコースがあり、kaggle.comにはたった1つのコンペティションがありました。 イゴールは、NLPを使用したプロジェクトを1つ終えたばかりで、このコンテストに参加するように私を招待しました。



私たちの目標



最初の目標は次のとおりです。

-実際のデータを操作する実践的なスキルを身に付ける

-NLPをより深く扱う

-プログラミングスキルを強化する

-上位10％に入る

しかし、ご存知のとおり、食欲は食事に伴うものであり、競争の終わりに近づくにつれて、私たちの目標はより野心的な目標に向かって修正されます。

最初のステップ

前述のように、決定の詳細な説明は他の場所で公開されています 。この記事では、行動の年表についてお話ししたいと思います。したがって、主な結果と発見をそれらが達成された順に示します。



ステージ1



最も簡単な開始方法から始めました-フォーラムで常に見つかる既製のスクリプトを見つけました。 「計算された変数」がないため、生成する必要がありました。 最初の変数（他の多くの参加者と同様）は、クエリとドキュメント間の単語の一致数などの数値変数でした。 最初のワードプロセッシングは、各単語からそのルートを残したステマーの使用でした。 これらの機能のxgboostモデルは、ステマーでテキストを処理した後、約0.49のRMSEを与えました。



ステージ2



次に、3つの方向に移動し始めました。

-新しい単純変数の生成

-モデルパラメーターの近似

-テキスト内の最も一般的なエラーの修正と、同じ意味の単語の単一フォーマットへの縮小。

これら3つの方向に徐々に移動して、 RMSEを0.48に近づけ 、3番目の方向が他の方向と比較して最大の改善をもたらしたという結論に達しました。 この段階で、2つの重要な発見がなされました。

1.エラー修正プロセスを何らかの方法で自動化するというアイデアが生まれました。Damerau-Levenshtein距離を使用して、マッチングだけでなく類似の単語を考慮する解決策が見つかりました。 この距離は、ある行を別の行に変換するために必要な文字の挿入/置換/削除/転置操作の数を示しました。 この距離がmin（3、max（len（word1）-3,1））より小さい場合、2つの単語（word1、word2）は同じであると考えました。 この基準を使用して計算された新しい変数は、 RMSEを0.478に改善し、ワードプロセッシングがこの競争で非常に重要であるという考えをさらに確認しました。

2.単純変数のリストに、一致する単語の文字数を考慮した変数を追加しました。 奇妙なことに、これらは非常に強力な変数であることが判明したため、 RMSEを0.474に改善しました 。



ステージ3



いくつかの単純な（キーワードマッチ）変数と、より複雑な変数を使用する必要があることはできないことが明らかになりました。 この問題の古典的な変数はtf / idf変数で、特定のドキュメントおよびドキュメントのコレクション全体での頻度に応じて、一致する各単語の重みを考慮します。 これらの変数を追加する最初の試みは、RMSEで.468をもたらしました。

これと並行して、ドキュメントの属性の中から有用な情報を探し始めました。 ブランド変数と材料変数を含めると、 RMSEが0.464に増加しました 。



ステージ4



次のステップは、単語間のセマンティックなつながりを何らかの形で考慮する変数の生成でした。 NLTKライブラリのWordNetパッケージは、このタスクに役立ちました。 単語間の類似性を異なる方法で考慮する組み込み関数を使用して、以前は使用されていなかった根本的に新しい情報を持つ変数の別のカテゴリを取得しました。

単語がどのスピーチの一部に属するかを考慮した変数も計算されました（NLTK POSタガーが使用されました）。 これに伴い、ワードプロセッシングとエラー修正が大幅に進歩しました。 これらすべてにより、 RMSEを0.454に改善し、上位10チームに入ることができました。 （進行状況グラフの注1）



ステージ5



進むにつれて、RMSEを改善することがますます困難になり、望ましい結果をもたらさない試みに対する成功したアクションの比率が、私たちの方向に傾かなくなりました。 これは、アンサンブルの構築を開始する時期であることを示唆しています。 アンサンブルを構築する最初の試みは成功しませんでしたが、私たちはこの方向で働き続けました

次の飛躍を可能にした主なアクションは次のとおりです。

-テキスト処理とエラー修正。

-ローカルtf / idf変数。特定の各検索クエリに関連するドキュメントのレベルで考慮されました。

-word2vec変数。予測の品質を大幅に向上させました。

したがって、別のモデル（単一モデル）でRMSEを0.445にし、競技開始から1か月半後に現在の評価でトップになりました。 （進行状況グラフの注2）





描画。 結果進捗グラフ

潜在的な勝者のその他の問題

最初の場所に到達する前に、私たちはこの競争をトレーニングのプラットフォームと考えましたが、現時点では、少なくともtop10に侵入する可能性があることに気付きました（top10％の元の目標の代わりに）。 3つの場所）。 しかし、賞品を獲得するには、さらに2つの問題を解決する必要がありました。



再現可能なソリューション



コンテストの受賞者は、最終決定を再現できる適切な文書とコードを提供する必要があります。 多少の変更はコードに対して常に行われ、古いバージョンのコードは保存されず、中間計算結果が多数のファイルに書き込まれたため、控えめに言っても、ソリューションはこの要件を満たしませんでした。 コードのバージョンと変数を含む特定のファイルとの正確な対応を確立することが不可能であるという事実に加えて、手動モードでの完全な再計算には、マシンで1週間以上の計算時間が必要でした。



すべてのサードパーティの外部データを共有する



2番目の重要なポイントは、どのワードプロセッシングが受け入れられ、どのワードプロセッシングが受け入れられないかに関するフォーラムでの議論でした。 この議論により、ユーザースクリプトsteubkが発生しました 。これは 、Googleを介してすべての検索クエリを巧妙に実行し、Googleによって修正されたテキストを取得しました。 コンテスト管理者は、最初にこのアルゴリズムの使用に反対し、テキストのエラーの「手動修正」（手でのラベリング）に反対しました。 しかし、「手動修正」と私たちの判断に基づく一般化されたルール（機能エンジニアリング）との間に明確な区別がなかったため、結果として修正辞書の使用が許可されました。 唯一の条件は、この辞書をコンテスト終了の1週間前にフォーラムに投稿することでした（合併の締め切り）。 ワードプロセッシングの重要性を理解し、非常に優れた辞書を作成したと信じて、私たちはそれをフォーラムに公開したくなく、ほとんどのワードプロセッシングを自動化する方法を探しました。 このような自動化は結果の悪化を招き、テキストを処理しないとすべての変数の再集計を開始できなかったため、さらなる作業を停止しました。



難しいですか？



合計で、約1か月を費やしてコード全体を単一の形式で書き直し、変数を再カウントしました（これは、競争の自由時間の不足と一致しました。 進行状況グラフの注3を参照 ）。 アンサンブルの構築からいくつかの進歩がありました。 アンサンブルの一般的な考え方は、データの一部について、さまざまなパラメーターとさまざまな変数のセットを使用して、レベル1モデルを構築し、これらのモデルの予測に基づいてレベル2モデルを構築することです。 このアプローチは、トレーニングとモデル検証のためにデータを正しく分割した場合にうまく機能します。 私たちの場合、これはtrainとtestのデータの構造が異なるという事実によって複雑になりました。 StratifiedKFoldを使用すると（データのモデルK-1の部分をK回訓練し、残りの部分の予測を収集する）、交差検証（交差検証）の結果と現在の評価（公開リーダーボード）のギャップが大きくなりました。 それにもかかわらず、アンサンブルを構築するためのこのようなスキームに同意しました。第1レベルの新しいモデルを追加したため、現在のレーティングの結果が改善され続けたためです。



このように、コンペティション終了の3週間前に、 RMSEを0.44に引き上げましたが、私たちの困難のほとんどが背後にあり、最終的なブレークスルーに向けてほんの少しのプッシュが残っていると信じていました。 そして、チームの統合が始まりました。

マージするかしないか

関連付けが必要な理由



最初にチームを結合すると、アンサンブルに新しいレベルを追加するのと同様の効果が得られます。 結合前のチーム決定の特定の線形結合は、これらの決定が互いに非常に異なるという事実のために、単一の決定よりも優れています（それらは相関係数が低く、たとえば0.9）。 私たちの競争では、この違いは、ワードプロセッシングと変数生成へのアプローチの違いによって大きく保証されました。

組合の2番目のプラスは、お互いから学び、いくつかのアイデアを借り、経験を共有する機会です（原則としてKaggleが存在します）。



どうした



合併の締め切りに近づくと、合併プロセスがより集中的に進むことを理解しましたが、発生した規模を明らかに過小評価しました。 競技終了の3週間前に、トップ10に少数のチームが2人以上しかいなかった場合、すべてが終わった後、トップ10に3人未満のチームはありませんでした（トップ10チームの平均参加者数は4.6人でした） 。

当初は、賞品を獲得するチャンスが十分にあるにもかかわらず、誰とでも団結するつもりはありませんでした。欲望からではなく、レベルを明確に理解したいという願望から。 しかし、アソシエーションの締め切りの約1週間前に、私たちは4〜5位に戻され、トップ10の2人の参加者からなるほぼ唯一のチームのままでした（その時点で1人しかいなかった）。 私たちは再び現在の状況について話し合い、彼を団結させようとすることにしました。 私たちは彼の同意を期待していませんでした：この男Chenglong Chenは以前の同様のCrowdFlower Search Relevanceコンテストで単独で勝ちました。チームの誰かと）。 彼はそれまで一人で競い続けているので、誰とも団結したくないと考えました。 2時間後、私たちの申し出に応えて、フレンドリーで簡潔な答えを見つけたとき、私たちは非常に驚き、喜んでいました。

「確かに！ チームマージリクエストを送ってください:)詳細については後で説明します。

皮肉なことに、私たちが利用できる唯一の通信チャネルは、評価が500を超える参加者が利用できるKaggleの内部メッセージングシステムでした。それまでは1つのコンテストにのみ真剣に参加していたため、メッセージを送信できません。 私たちの他の人が数ヶ月前に別のコンテストに数時間を費やしたことは幸いな偶然でした。彼はトップ90％で、この素晴らしい結果はメッセージを送信する機会を得るのに十分でした。 この事実がなかったら、この記事が存在しなかったように、私たちの城龍との連合は存在しなかったでしょう。



それは私たちに何を与えましたか？



まず、合併後、私たちは最良のソリューションの相関を評価しました。Kaggleの基準では、0.87と非常に低いことがわかりました。 2つのソリューションの単純な平均によりRMSE 0.435が得 られ、LBで2位に戻りました。 （進行状況グラフの注4）

第二に、私たちは信じられないほど才能があり、気持が良く、謙虚な男に出会いました。

仕上げ

2週間しか残っておらず、互いに5つのタイムゾーンの距離にありました。 したがって、彼らは私たちにとって最適な戦略はアイデア、変数、コードを交換することであると判断しましたが、独自の決定を完了することに焦点を合わせ、単純な計量（ブレンド）で結合します。 その結果、Chenglongは変数の一部を使用してより良いソリューションを得ましたが、ソリューション間の相関は0.94に増加しました。 したがって、全体的な結果の改善は、私たちが望むほど大きくありませんでした。



適切な相互検証の重要性



上記のように、アンサンブルを構築するときの相互検証のために、最初にデータの2/3でモデルを調べ、データの残りの1/3でチェックしました。 この競争のためのこのアプローチは、CVとLBの間の拡大するギャップにつながったため、成功とは言えません。

コンテストの終了の約1か月前に、トレーニングに1/3のデータを使用し、検証に2/3のデータを使用するコードを作成しました（つまり、トレーニングとテストの内訳に類似した内訳を使用しました）。 CVとLB間のギャップは大幅に減少しましたが、結果は悪化しました。 したがって、私たちは最初の故障を守り続けました。

今後は、その瞬間に間違いを犯したと言います。 古いクロス検証戦略で良い結果が得られたのは、この戦略が優れていた（悪化した）ためではなく、ワードプロセッシングと変数計算のアプローチが異なるさまざまな時期に構築された数百のモデルでアンサンブルが構築されたためです。 この競争でこのような異なるアプローチを使用することで、ソリューションが改善されました。 終了の約1週間前に、単一のアルゴリズムを使用してすべての変数を再計算し（賞品の資格を得るために再現可能なソリューションを作成する必要がありました）、より悪い結果が得られることを恐れました。 ここで、以前に破棄したコードが役に立ちました。 数百のモデルを数える時間はありませんが、8つのモデルのうちでも、古いアプローチよりも良い結果が得られました。

Chenglongはもともと、より効率的な内訳を使用していました。 実際には、検索クエリの一部は電車内のみで、一部はテストのみで、一部はあちこちにありました。 製品についても同じです。 Chenglongはこれに注意を喚起し、トレーニングと検証のために部品で同様の分布を作成しました（下図）。 その結果、彼は我々よりも現実にはるかに近い交差検証の結果を得ました。

ソリューションに同じ相互検証を実装する時間はありませんでしたが、アプローチよりも優れていることがわかりました。 したがって、Chenglongの変数は次の目的には使用しませんでした。

a）意思決定間の相関をできる限り少なくする

b）正しい交差検証アルゴリズムを使用して最強の解が計算される状況を取得します（最後の不意打ちを避けるため）





描画。 城龍交差検証の内訳



それはとてもランダムなプライベートですか？



文字通り、競争の最後の日に、ソースデータにレコードIDとその関連性の評価との間に関係があることに気付きました。 ほとんどすべての競争を通じて、私たちは、他の多くの人と同様に、データ内のこのレコードのシーケンスはランダムであると信じていました。 IDに応じて、平均関連性の値が非常に異なる3つの異なる領域を明確に区別できることがわかり、非常に驚​​きました。 さらに驚くべきことは、2つの最適なソリューションがいずれかの領域でまったく異なる動作をしたことです（図のパート3）。 これに先立ち、LBで見た結果は公開データ（テストの30％）に対応していましたが、最終結果は残りの70％テスト（プライベート）で計算されていたはずです。 データが明らかに非ランダムに順序付けられていることを考えると、問題は、パブリックとプライベートの内訳も非ランダムですか？ そして、私たちのソリューションのどれが物議をかもしている分野（パート3）で最もよく機能しますか？











最後の質問を解決するために、2つの最良のソリューションを組み合わせました（最初の2つの部分をあるソリューションから、最後の部分を別のソリューションから取得しました）。 LBの結果は同じでした！ これは、膨大な量のデータが完全にプライベートであることを意味し、2つのソリューションのどちらがこのデータに最適かわからない。 Kaggleでは最終的なソリューションとして2つのソリューションを選択できるため、決定を巡る論争の的となる部分については、マークを逃さないように、単に直径的に異なるウェイトを選択することにしました。

率直に言って、パブリック/プライベートへの非ランダムな内訳による格付けの大きなショックを予想していましたが、テスト中のすべてのデータの3分の1が参加者の関与を阻止するために特別に「感染」したことが判明したため、テキストの手動処理」 。 このデータはまったく評価されていません。 主催者側の非常に残酷な動き。



結果の不利益に対する誠実さ



コンペティション全体を通して、コンピューターを夜間に放置することは犯罪であり、夜間にはアンサンブルの新しいモデルが検討されることがほとんどでした。 再現可能なソリューションを得るためにコード全体を書き直さなければならなかった後、私たちは正確に再現できず、これに十分な時間がなく、フォーラムに古い辞書を1週間公開しなかった第1レベルの約300の異なるモデルがありましたルールの要求に応じて、競技の終了まで。 それでも、これらのモデルをアンサンブルに追加すると、LBがわずかに改善されました（これらのモデルが異なるバージョンのワードプロセッシングに属しているためと思われます）。 私たちの理解では、これは競合の条件に反するため、これらのモデルを最終的なソリューションとして使用しないことにしました。 また、データのランダムな分布による不快な驚きを排除せず、古い古い相互検証戦略の信頼性が低いと考えました。

これを決定した場合、これらのモデルを使用した最終的なソリューション（これは公開されている最高のソリューションでした）は、RMSEで0.43188をもたらします。

真実の瞬間、結論、そして勝利後の人生

それで、私たちの最終決定の両方が準備ができた瞬間が来ました、そして、私たちはプライベートで最終結果の公表を待つだけでした。この時点で、状況は3位でした。チームは1位で良いマージンを取り、9位以下のチームは大幅に遅れ、2位から8位のチームの結果は非常に近かったため、最終順位で場所を変える可能性があります。予想されるショックを考えると、結果はトップ8内の私たちにとって何でもあり得ることに気づきました。朝の3時に大事に、ページの更新を繰り返した後、最終的に結果を確認しました。4位...



勝利とは？



衝撃は大きかった。 2番目の打撃は、古い再現不可能なモデルを使用した決定が2位になることを確認したときに発生しました。その夜眠りにつくことは容易ではありませんでしたが、実際にはトップチーム間の最終的なギャップは重要ではなく、プロセスで習得された膨大な経験とスキルは言うまでもなく、同様のレベルの高さに達するという事実は重要であるという朝の考えに近づきました。 3位の報酬はそれほど悲しくはないほど大きくなかったので、しばらくすると悲しみはよくできた仕事からの楽しい気持ちに置き換えられました。そして翌日、メンバーの1人が複数のアカウントの使用で有罪判決を受けたため、そもそも最初にいたチームが失格となったことを知りました。主催者によるこの厳格な決定により、最終的な3位になりました。 競技後の



生活



競技後、私たちは道徳的および肉体的疲労に追い抜かれましたが、多くの時間と労力を費やしました。しかし、その完成後にリラックスしたいという素朴な欲求は、実現する運命にありませんでした。コンテストの2か月後、さらに次のことを行いました。- 決定に関する完全な文書

化- インタビューの準備-HomeDepot とのプレゼンテーションの準備と電話会議の開催-キエフのKaggleコミュニティのプレゼンテーションの準備と講演-この記事の執筆









一般に、これらはすでに楽しい瞬間でしたが、すべて同じでしたが、予想以上に時間がかかりました。



結論とアドバイス



このコンテストの結果は、2つのグループに分けることができます。 1つ目は、このコンペティションから学んだことです

。1。コンペティションの結果は、主にどれだけの時間とエネルギーを投資するかによって決まります。知識とスキルも解決しますが、ほとんどの場合、知識とスキルの不足は、忍耐力の過剰によって補うことができます。

2.競技会への参加自体も有益で興味深い経験です。もちろん、視野が大きく広がり、世界中の有能な競合他社を背景にあなたの個人レベルを客観的に評価できるという事実は言うまでもありません。

3.試すことを恐れないでください！あなたが好きなことを始めたら、すぐにそれとインスピレーションの時間を見つけます。データサイエンスに興味がある場合は、ぜひ試してみてください。後悔することはありません。

第二-これらは、私たちが同様の結果を達成することができた理由

です：1.多大な投資時間。

2.完全なテキスト処理。

3.以前の受賞者の経験と、自然言語処理で使用されるほとんどの古典的なアプローチを使用します。

4.努力の正しい配分。

5. Chenglongとの統合。

これはKaggleでの最後の競争ではないと確信しており、将来の成果を共有できることを願っています。