開発効率とサービス競争力を上げる　機械学習のために整備した「3種類の特徴量」について解説

特徴量の一元化で重視した4つのポイント

Chaerim Yeo 氏：Feature as a Serviceの重要な概念となる特徴量の一元化において、我々が重要視したポイントは4つあります。それぞれ順に説明しますが、まず1つ目は汎用性です。特定の機械学習コンポーネントに特化した特徴量を生成すると一元化する意味がまったくないので、どの機械学習コンポーネントからも汎用的に使えるような特徴量を設計しました。

2点目は柔軟性です。機械学習コンポーネントの用途はさまざまですので、当然必要となる特徴量もそれぞれ異なります。そのため、必要な特徴量をある程度選択可能な設計にしました。

3つ目は再利用性です。サービス横断のデータを機械学習で用いる際、特徴量の生成にはかなりの計算コストが掛かりますので、1回だけ計算をしておいて、あとは再利用できるような仕組みにしました。

最後の4つ目は拡張性です。新たなタイプの特徴量を追加したいとき、例えば新しいサービスが立ち上がってそのサービスのデータから特徴量を生成したいというニーズがあった場合、容易に拡張できるような設計にしています。

この4つのポイントを抑えつつ、現在我々は3種類の特徴量を開発しており、Feature as a Serviceとして社内の機械学習を行う他組織などに提供しています。

さまざまなデータを横串で活用できるZ-Features

では、それぞれの特徴量をご紹介したいと思います。

まずZ-Featuresと呼んでいる、ユーザ単位の特徴量です。この特徴量を作るきっかけになったコンポーネントは2つあります。まずはユーザの性別や年齢グループ、地域といった属性を推定するエンジンの開発。そしてもう一つは、あるユーザ群を入力として与えるとそれに類似したユーザを出力することが推定できるLookalikeエンジンです。

いずれも、LINEのサービスにおけるさまざまな行動ログが、何らかの精度向上に寄与すると期待される性質の問題を扱っています。あるスタンプは女性が使うことが多いとか、この音楽は男性が聞くことが多い、などです。Lookalikeエンジンは主に広告プラットフォームでよく使われていますが、どんなセグメントに似ているかは毎回異なるため、サービス横断のデータを活用する必要があります。

これらのコンポーネントは簡単に言いますと、入力層と出力層の間に2層挟んだシンプルかつオーソドックスなDeep Neural Networkがベースとなっていますが、この場合、各々のユーザに対して有効な特徴量は本当にケースバイケースなので、高次元になりがちですけど、なるべく網羅性が高い特徴量を使う必要がありました。

こういった背景から、サービス横断のユーザの行動ログを一ヶ所にまとめておくことでさまざまなデータを横串に活用できるZ-Featuresを開発しました。

Z-Featuresの生成フローはご覧のように、すごくシンプルで各サービスのログを適切な構造に変換してユーザ単位で集約するだけです。ここで適切な構造に変換する理由としては、すべての情報を保持するのは現実的に不可能なためです。

そのために、まず社内の機械学習コンポーネントのユースケースをある程度網羅して、約8割程度がカバーできるようなコンパクトな構造を定義しました。この構造は、Bit flagなどを用いてユーザの行動を簡潔に表現し、Sparse Vectorなどのデータ構造に素早く変換できる利点があります。

言葉だけではZ-Featuresのイメージが湧かないと思いますので、実際のデータは見せることができませんが、ご覧のような、行がユーザで列がサービスのテーブルを想像するとわかりやすいかなとは思っています。

Z-Featuresは現在10を超えるサービスから、30を超える種類の特徴量を生成しています。特徴量の合計次元数は約5,000万次元で、かなり高次元ですので、これをすべて使うケースは極めて稀で大抵1,000万〜2,000万次元程度のサブセットを取って使うケースが多いです。Z-Featuresが生成されているユーザの数はユニークユーザIDの延べ数になりますが、おおよそ8億9,000万になります。

Z-Featuresが開発されてから、開発のきっかけになったユーザの属性推定のコンポーネントやLookalikeエンジンでもちろん、多くの機械学習コンポーネントから使われるようになりました。とくにレコメンデーションエンジン系から使われるケースが多くて、例えばSmart ChannelのLINEスタンプや、マンガ、ニュースのRecommendation Engineでも、このZ-Featuresが使われています。

Y-Featuresは、Z-Featuresの問題を緩和するために開発

続いて、Y-Featuresと呼んでいる、難読化されたユーザ単位の特徴量について説明します。先ほどZ-Featuresというユーザ単位の特徴量が開発されているのに、なぜわざわざ難読化した特徴量をまた開発する必要があったかというと、長年Z-Featuresを使って運用する過程で、いくつかの問題に直面したからです。

それらの問題は2つに帰結されます。第一に、Z-featuresは極めてスパースであることと。全体で5,000万次元で、サブセットとして使っていても1,000万次元以上の次元を使うケースが多いですが、高次元かつ、極めてスパースなデータを機械学習で処理する際の計算コストが非常に高くなってしまう、ということがありました。

そしてもう一つの問題は、人間が解釈可能なデータ構造である、という点です。Z-Featuresが機械学習向けに使ってよいデータからだとしても、他のデータと組み合わせて利用すれば、その中身を人間が解釈できてしまう、ということです。社内ではZ-Featuresを使いたいという機械学習関連の組織が増えつつありましたが、いくら社内でも容易に提供することはできませんでした。

こういったZ-Featuresの問題を解消するために開発したのが、Y-Featuresです。Y-FeaturesはZ-Featuresを難読化したものとなりますが、ただ単に難読化したものではなくて、機械学習を使いやすくなるように工夫しています。

どういうことかというと、各々のサービスが提供するコンテンツに対して、そのコンテンツの埋め込みベクトル（Content Embedding）を求め、それをユーザの行動ログ、Z-Featuresと組み合わせます。具体的には、ユーザの複数コンテンツへの接触をContent Embeddingの足し合わせという形の中間的な特徴量（Interim Features）を生成し、さらに後段の処理として次元圧縮を行い、Y-Featuresを生成します。

ここでいきなりContent Embeddingが出てきましたが、ユーザの特徴量の計算なのに、なぜContent Embeddingを使うのかと疑問に思う方がいらっしゃると思います。埋め込みベクトルを利用する理由の一つは、コンテンツの埋め込みベクトルの足し合わせによって、ユーザ自身の生の行動データが隠蔽できることです。

もう一つは、もともとは仮説だったのですが、前述の足し合わせという方法で生成したY-Featuresが、ちゃんと機械学習で役に立つデータになる、ということが検証できたためです。

Content Embeddingの求め方ですが、これはコンテンツが明確に存在するサービスの場合はオーソドックスな機械学習の手法によって求めることができます。例えば、ニュースの場合は記事という明確なコンテンツが存在して、その記事の中の文章の分散表現を求めることができます。

サービスの中では、例えばLINEポイントのようにユーザの行動履歴がわかるサービスもありますが、コンテンツ自体が明確に存在しないサービスも少なくはありません。そのために我々が考えた手法としては、まず、すべてのユーザの行動ログを、その並び順が何らかの情報を保持するような疑似的なドキュメントに変換します。このドキュメントはコンテンツのIDを単語として含む文書としての構造をもっているため、すべての単語の分散表現を求めることができます。コンテンツのIDに該当するEmbeddingだけを抽出すると、それがそのIDに対応するコンテンツの埋め込みベクトル（Content Embedding）になります。

中間特徴量の次元圧縮には、現状のところMatrix Sketchingと主成分分析（PCA）の組み合わせを使っています。Matrix Sketchingは、Frequent directionsというアルゴリズムを使っています。

特徴量の処理時間が飛躍的に速くなった

Y-Featuresは10を超えるサービスに対して20強の特徴量を生成しています。特徴量の合計次元数は約6万次元となって、Y-Featuresが生成されているユーザの数は、ユニークユーザIDの延べ数で約4億となります。Z-Featuresに比べてユーザの数が約半分ぐらいになっていますが、これはLINEが最も使われている4つの国、日本と台湾、タイ、そしてインドネシアのユーザを最初のターゲットとしたためです。

Z-Featuresに比べてY-Featuresの合計次元数はわずか0.12パーセント程度となっています。特徴量としての有効性を評価するためにZ-Featuresを直に使った場合とY-Featuresを使った場合で、日本のユーザの属性推定を行って、結果を比較してみました。

ここに載っているすべての値は、Z-Featuresの結果に対する相対値となっていますが、まずは学習のメトリクスの比較です。左から順に性別推定と年齢グループの推定、そして住んでいる地域、日本の場合は都道府県の推定結果となります。性別と地域の場合はほぼ同レベルの精度が得られましたが、年齢グループに関しては10パーセント程度の精度低下がありました。

次は処理時間の比較です。学習時間の場合はZ-Featuresでの学習より約20倍ぐらい速く処理することができて、予測時間の場合も約2倍ぐらい速くなりました。精度に関しては多少落ちた結果となりますが、処理時間は飛躍的に速くなって社内では十分使える特徴量という結論になっています。

Y-Featuresを使っているコンポーネントの例を挙げますと、まず類似ユーザの推薦エンジンがあります。このコンポーネントは機能的にはLookalikeエンジンと似ていますが、実装としてはディープニューラルネットワークを使っているわけではなく、近似最近傍探索を使っています。そのほかにも、Y-Featuresを使うことを検討している部署が増えつつありまして、直近では、広告プラットフォームでCTRやCVRの予測などにY-Featuresを使うことを検討しています。

C-Featuresは、さまざまなサービスのコンテンツに拡張していく

最後に、コンテンツ単位の特徴量であるC-Featuresの紹介をします。C-Featuresは、先ほども言ったように各サービスのコンテンツのEmbeddingを一箇所にまとめたものです。

その開発の背景としては、まずY-Featuresでユーザの特徴量を難読化するときに、現在の疑似的なContent Embeddingではなく、コンテンツそのものの情報を持つ、本来のContent Embeddingを使うように変更する計画のためです。

そして、Content Embeddingを生成している機械学習コンポーネントが、すでにいくつか存在していたため、特徴量の一元化を行う必要があったためです。例えば、スタンプショップの類似スタンプ推薦エンジンでは、スタンプ画像の埋め込みベクトル（Embedding）を生成できる仕組みになっていたので、それをC-Featuresにとして取り入れました。

C-Featuresは、開発に着手したばかりで、現時点ではニュースとスタンプ、2つのサービスのみをサポートしています。ニュースの記事の場合はfastTextとSCDVの組み合わせで、スタンプのイメージはXceptionモデルを用いてEmbeddingを生成しています。

先ほど述べたとおり、C-Featuresは現在2つのサービスのみですが、5つのタイプの特徴量を生成しています。特徴量の合計次元数は約1.5万次元となって、C-Featuresが生成されているコンテンツの数はおよそ300万程度となっています。今後はニュースとスタンプだけでなく、さまざまなサービスのコンテンツに対して拡張していく予定です。

C-Featuresを使っている機械学習コンポーネントは、まずY-Featuresがあります。そして今日、Smart Channelに関する発表がいくつかあったと思いますが、Smart Channelのの推薦エンジンにおけるContextual Banditと呼ばれるアルゴリズムの中に出てくる、Item Embeddingとして、C-Featuresを使っています。

開発効率やサービス競争力を上げることができた

今日の発表をまとめたいと思います。

まず、LINE Data Labsでは機械学習で使う特徴量をFeature as a Serviceという方法で運用をしています。これによってデータの標準化及びデータの民主化が実現されて、開発効率やサービス競争力を上げることができました。

そしてFeature as a Serviceによって運用している特徴量は、ユーザ単位の特徴量（Z-Features）と、それを難読化した特徴量（Y-Features）、そして最後にコンテンツ単位の特徴量（C-Features）の3つがありまして、これらの特徴量はさまざまな背景から誕生して、現在はLINEの社内のいろいろなコンポーネントから使われています。

以上で発表を終わります。ご清聴ありがとうございました。

（会場拍手）