一昔前までは、データの取得には大変コストがかかり、貴重でした。しかし現在では様々なデバイスからデータが取得できるようになり、ビッグデータと呼ばれる巨大なレコード数を持つデータセットが手に入るようになりました。これだけデータがあれば、結構自由に分析できる・・・と思うのは少し早いかも。データが増えたのは増えたのですが、実は各データ変数を見るとスカスカ、という問題が各所で発生しているのです。
例えば巨大な音楽配信サービスがあって（何百万人という単位の人のデータ）、その中でコアなパンクバンドの楽曲aがあるとします。コアなバンドですから、ほとんどの人はそんな楽曲は聞きません。数百人といったところでしょうか。そうすると、個人iが楽曲aを聴いたか聴かなかったかを表す変数
X[i,a] = 1 (聴いた), 0 (聴かなかった）
は、ほとんどの場合ゼロで、たまーに1になるといったデータになります。だって、ほとんどの人はパンクロック聴かないですもん。この変数は、ほとんどゼロのスカスカ変数なんです。同様に、個人iの聴く楽曲に調べていくと、ほとんどがゼロ。一部の好きなミュージシャンに1が付く感じになります。（自分が聴く楽曲の数と世の中の楽曲の数を比べてみるとすぐイメージできます。）さらに、これを個人を束ねてデータ化すると、巨大なデータ行列ができます。しかし、そのデータ行列は要素がほとんどゼロになり、スッカスカです。こういったスカスカ行列を疎行列（スパース行列）と呼びます。
さて、どうしてこのようなスパース性が生まれるのでしょうか？データの種類によってその原因はまちまちだと思いますが、一つイメージを持ってもらうためにアンケート調査について考えてみます。アンケート調査のデータは、とても密です。どういうことかというと、アンケートの各項目については全員がこたえられるように設計され、「アンケート回答者」という限られた集団の「全員」が回答します。なので、アンケートデータはすべて何かしら回答が記されているわけです。一方、ウェブの回遊データやPOSデータは、回答者に相当するユーザーが不特定だったり、今度は商品側が次々と更新されたりと、どんどん増殖していく性質を持ちます。そうすると、回答者と回答項目の組み合わせはどんどんと増えてしまい、結果的にほとんどのデータがゼロになる、ということになります。
データがスパースになると、いろいろと困ったことが生じます。先ほどのコアなパンクロック好きのデータの話ですが、スカスカのデータなので、たまに「１」があったとしても、果たして今人はパンクロックが好きだから「１」になっているのか、気まぐれでたまたま楽曲に接触してしまったかがよくわかりません。このような時の対処法は大きく二つあります。
一つは、パンク楽曲を他にも特定して、たとえば楽曲a～zがパンクだったとして、その中でゼロでない変数が例えば５個以上あればパンク好き、という具合に判定する方法。もしくは、数多あるパンクロックの楽曲でも有名なものを特定して、その曲を聴いていればパンク好きとみなす方法。
これ、前者は変数を合成してまとめて一つの変数にしてしまうという方法。後者は、影響力のある変数を特定して、ほかは無視する方法となります。変数の選択です。かなり乱暴な議論をしてしまいましたが、データエンジニアリングで多く用いられるのもこの二つの方法なのです。スパースエンジニアリング(sparse engineering)とかフィーチャーエンジニアリング／特徴量エンジニアリング(feature engineering)と呼ばれる分野の手法は、およそこの二つの方針のいずれかを採用しています。人工知能などにも使われる重要な手法です。専門書や論文では何をやっているか理解するのは難しいですが、平たくこんな具合に考えると、ちょっと身近な感じがしますかね？
No responses yet