行ってきました。というか、まだ最中ですが、ブログ書いてます。ちなみに画像のお弁当、めっちゃ美味しかったです。

場所

ホテルの地下が会場なんだけど、ホテルの入り口がめっちゃ分かりにくい。たぶんゆりかもめから行くのが最適解。バスとか使うと迷う。

深層学習と脳科学

なんというかエンジニア系イベントでは異質だけど、めちゃくちゃ考えさせられる面白いセッションでした。

機械学習について大雑把に話を理解するのにもちょうど良い説明だったのと、機械学習がもたらす影響は産業革命と同様に大きく、変革を妨げる方法もないんだから、今後の文明社会について、みんな考えていこうぜ、っていう内容でした。

LINEが開発した時系列データベース'Flash'の紹介

Line社では日々ものすごい大量の計測データを取ってるんだけど、そういったデータを、最初はMySQLを使って、シャーディングその他頑張ったけど、無理ゲー過ぎたので、他社のもっと大規模なヤツも試したり検討したけど、ダメだったので、プロトタイプを2ヶ月くらいで作って、運用したらいい感じってセッションでした。

ミソとして計測データは、計測データを出す方のID（サーバー名やプロパティ名）は静的な文字列で、データ自体は数字。なので、まずID（ラベル）と、メトリクスの数値自体（Data Point）を別々に持ち、それぞれのデータ構造に応じた最適化をするという判断。

Label文字列はElastic Searchを活用、ついでに、これをハッシュかして、IDとして所持。（IDとLabel文字列の紐付けや検索でElastic Searchを活用）。

Data Pointは二段階に分けて保持。メトリクスは大体28時間くらいしか積極的には使わないから、まず In-memory DBで 28時間分を保持して、随時永続ストレージ（これは既存のソフト）に入れるという構成。

In-memory ではデータを圧縮するために、Delta-Delta-XORアルゴリズムで小さくしている。これは、メトリクスはデータの変化なので、デルタを二段階で取れば、変化が小さくなるので扱いやすくなるというもの。

やってるかどうかはしらないけど、高段でさらに圧縮をかけようと思えば欠けやすいデータ分布になるから、そういう意味でも有利そう。

これらは、Golang使って、二ヶ月程度でプロトタイピング。さらに、既存のプロダクトなんかも併用しながら、目的に応じたちょうど良いものを作り上げるという素晴らしいプロダクトだった。

ほんとは、Labelなんかももっと最適化したりとかの課題はあるらしいけど、素晴らしい。

個人的には、FM-Index系のアルゴリズムが活用できそうかなーとは思う

LINT (Line Improvement for Next Ten years)

Lineのサービス当初は1つのメッセージングアプリケーションに過ぎなかったけど、利用者も爆発的に増えて、かつ接続サービスが大量になって、技術的負債の塊となったメッセージング基盤を改善するために、LINTチームという、横断的なチームを立ち上げて改善していくという、闇と戦う闇成分の強いセッションでした。

もともと、Line は、Operation というデータ単位を積み重ねる state machine 型のアーキテクチャなんだけど、サーバーとクライアントで同期が崩れる、久々にアクセスすると情報が大量にやりとりされて非効率でつらたんとか、けっこう色々問題を抱えている。

もう一つ、プロキシ・フロントエンド部分と、バックエンドで効率が悪いとか、自前のSPDYを使ったりとかも辛すぎて、HTTP/2へ移行するとか大変そうな闇を抱えてるとのことでした。

次、Operation自体が持つ問題があるので、snapshot を作る改善をしているらしい。ただ、問題は元から別の目的で作られたサーバーを流用してるため、snapshot がそれぞれいくつかのサーバーごとに作られるらしい。

個人的にはそういうのって、Operation のログから単一のsnapshotを作っていく方がバグが少なくてハッピーだと思うんだけど、歴史的経緯でそういうわけにはいかないらしい。

あとは、ローカルのOperationの数と、サーバー側の数を比較することで、ローカルデータが欠損してるかどうかを確認するってやり方で、リカバリもしてるらしい。

なんというか涙ぐましいが億単位のユーザーがいて、大量のサービスと結合してるので、簡単な解決方法はないってことなんだなぁということと、そういうサービスは最初からちゃんと設計しとかないとヤバいんだなーということですかね。

グロースの途中でなんとか出来ていれば…とは思うものの、まぁ得てしてそういうのは後の祭りというヤツですね。

まぁ、初期想定の200倍とかいうグロースしてたら、しゃーない

なんとも難しい。

LINEにおける深層学習を用いた音源分離技術の研究

複数人が喋ってる音源から、一人一人のデータを分離する研究。

例えば会議を録音しても、後で資産として使いづらい。せめて誰が喋ってるのがわかったり、そこからさらに文字興し出来ればいいんだけど、ということで、音源分離は研究テーマとしてはすごく応用しがいのあるやつ。

まず、マイクを複数用意すると、それぞれの話者の空間的な位置によって、個々のマイクへの音声の届く時間差および、音の減衰があるので、何かしらうまくやれば音源分離が可能になる。

ところが、どうやれば、正しい分離したデータであると判断できるのかが分からない。これに対しては統計的分離手法がいくつかあるんだけど、そのままだとまだ不自然なまま。

そこで深層学習を使って音源分離を行う。

シングルな音源データを学習したネットワークを使った音源分離だと、今回のような複数マイクを使ってるような空間的な情報を活用できないので、精度を上げるのに難があるので、空間的な情報もネットワークに組み込みたい。

BLSTMを複数の層を重ねてるんだけど、単純に、一番最初の段階で空間的情報をぶち込んでも、空間的情報が反映されづらいので、BLSTM層の間で毎回空間情報を入れるようにすると、反映されてくれる。

で、これはこれでいいんだけど、論文提出して査読途中だけどいい手法があるので本邦初公開！（意訳）

ここまでは教師有り学習だったが、どうせなら教師無し学習したい。

で、統計的手法により抽出したデータを教師として使うらしい。

ん？統計的手法自体が精度低いんだから、それを教師として使っても仕方ないのでは？と思ったら、どうもそうではないらしい。

既存の統計的手法だと、実は特徴的な部分は本来の音声に近いところがあって、それ以外の精度の悪い部分は割とランダムに出る傾向があるので、そこはいい感じに機械学習が、スルー気味にしてくれるらしい。

わざとノイズ加えて学習させるのと同じような感じかな。

さらに、損失関数も、通常考えるものではなくて、KLD（カルバック・ライブラー情報量）を使うとさらに効果的らしい。

面白いのは、これまでの人間が考えてきた統計的手法、実は無駄じゃなかったんだ！という点。感動的ですよね。人間の知恵と機械学習が手を結んだ感じ。

今日一番面白いセッションだった。