ハッシングは次元を減らしますが、ワンホット エンコーディングは基本的に、マルチカテゴリ変数を多くのバイナリ変数に変換することによって特徴空間を爆破します。なので、逆効果のようです。私の質問は次のとおりです。
同じデータセットで両方を行う利点は何ですか? インタラクションのキャプチャについて何か読みましたが、詳細ではありません - 誰かがこれについて詳しく説明できますか?
どちらが最初に来ますか、そしてその理由は何ですか?
4986 次
1 に答える
11
標準カーネルを使用して線形モデルと SVM にカテゴリ データを供給するには、バイナリ ワンホット エンコーディングが必要です。
たとえば、曜日の機能があるとします。次に、それぞれのワンホット エンコーディングを作成します。
1000000 Sunday
0100000 Monday
0010000 Tuesday
...
0000001 Saturday
特徴ハッシュは主に、パラメーター ベクトルの大幅なストレージ圧縮を可能にするために使用されます。1 つは、高次元の入力ベクトルを低次元の特徴空間にハッシュします。したがって、結果として得られる分類器のパラメーター ベクトルは、元の入力空間ではなく、低次元空間に存在することができます。これは次元削減の方法として使用できるため、通常、パフォーマンスが少し低下する代わりに、ストレージの大幅なメリットが期待できます。
ウィキペディアの例は良い例です。次の 3 つのドキュメントがあるとします。
- ジョンは映画を見るのが好きです。
- メアリーも映画が好きです。
- ジョンはサッカーも好きです。
bag-of-words モデルを使用して、最初に以下のドキュメントから単語へのモデルを作成します。(各行はドキュメントであり、マトリックスの各エントリは単語がドキュメントに表示されるかどうかを示します)。
このプロセスの問題は、そのような辞書が大量のストレージ スペースを占有し、トレーニング セットが大きくなるにつれてサイズが大きくなることです。
辞書を維持する代わりに、ハッシュ トリックを使用する特徴ベクトライザーは、検討中のアイテムの特徴 (単語など) にハッシュ関数 h を適用し、ハッシュ値を直接使用することによって、事前定義された長さのベクトルを構築できます。機能インデックスとして、それらのインデックスで結果のベクトルを更新します。
以下のハッシュ化された特徴を 3 つのバケットで生成するとします。(k元の機能にさまざまなハッシュ関数を適用し、ハッシュ値がバケットにヒットした回数を数えます)。
bucket1 bucket2 bucket3
doc1: 3 2 0
doc2: 2 2 0
doc3: 1 0 2
これで、9 次元のフィーチャを 3 次元に正常に変換できました。
特徴ハッシュのさらに興味深いアプリケーションは、パーソナライズを行うことです。特徴ハッシュの元の論文には、良い例が含まれています。
スパム フィルターを設計し、各ユーザーに合わせてカスタマイズしたいとします。これを行う単純な方法は、ユーザーごとに個別の分類器をトレーニングすることです。これは、トレーニング (パーソナライズされたモデルをトレーニングおよび更新するため) またはサービング (すべての分類器をメモリに保持するため) に関して実行不可能です。スマートな方法を以下に示します。
- 各トークンは複製され、各単語を一意のユーザー ID と連結することによって 1 つのコピーが個別化されます。( USER123_NEUおよびUSER123_Votreを参照)。
- バッグ オブ ワード モデルは、一般的なキーワードと使用固有のキーワードを保持するようになりました。
- 次に、すべての単語が低次元の特徴空間にハッシュされ、そこでドキュメントがトレーニングおよび分類されます。
あなたの質問に答えるために：
はい。one-hot-encoding は、カテゴリ特徴をバイナリ特徴に変換して線形モデルで使用できるようにするため、最初に来る必要があります。圧縮された特徴空間を使用する利点がある限り、同じデータセットに両方を確実に適用できます。元の特徴の次元を許容できる場合は、特徴のハッシュは必要ありません。たとえば、MINSTなどの一般的な数字認識問題では、イメージは 28x28 のバイナリ ピクセルで表されます。入力次元はわずか 784 です。確かに、この場合、機能ハッシュは何のメリットもありません。
于 2014-10-21T05:20:25.020 に答える