行ってきた。前は FB 社でやっていたのを今回は WWDC と同じ会場。こんなイベントをタダでやられてしまったら O'Reilly とか商売上がったりだね。Facebook の景気の良さを感じる。しかも最近は近隣の会社を巻き込んでいるらしく、他社の人が司会をしているトラックもあった。えらい。

おおむね ML track に張り付いていた。内容は hit and miss. Miss の方からいくと...

まず NVIDIA の talk はおおむね宣伝だった。ただ inference と training では違う GPU を使うといいよ、どうせ inference は batch size が小さいからね。などという話は、気にしたことがなかったけれど言われてみればそうだと思った。あと Volta はなかなか速そうだった。あと話しに来ていた NVIDIA の偉い人 Robert Ober が Volta の実物を片手に「こいつはまじ速いんだぜ」と語る様子は愛が伝わってきてよかった。

Qualcomm の talk は概ねどころか完全に宣伝。しかも hand waving の割合が高く残念だった。Neural Processing Engine というライブラリとツールをつくっていて Qualcomm チップ上で TF や Caffe のモデルを変換の上動かせるよ、というのが主題。でも Qualcomm 自体の宣伝が 8 割くらいで肝心なところがさっと流されておりいまいち。

Google の人による TensorFlow の talk. 知ってる話ばかりでいまいち。だけどまあ、もともとそれなりにフォローしてる話題なのでケチをつけるのはフェアではないと思う。ほんとは違うセッションを見る予定だったんだけど時間割を勘違いしてしまったのだった。

@Scale のようなカンファレンスではベンダーの話はダメという話でありましょう。そういえばそうだった。この文脈では上の TF の Google もライブラリベンダにカウントして良い気がする。

よかったやつら。

Salesforce の AI 部門の人の話。SparkML でクールなライブラリをつくった上に、feature seelction とか evaluation の cycle とかを自動化して datascientist-less な ML プラットホームを作るぜ! それが Einstein だぜ！という話。なんか話してた内容に比べてサイトにある商品はしょぼい気もするが、Salesforce が自社のプラットフォームに ML をつけるのはいい話だしアプローチもまともそうに思えた。Salesforce は PaaS/SaaS として顧客の CRM データなどを握ってしまっているから客が ML したいと思った時に使えるものを用意しておかないと都合が悪いというか、逃げられてしまうのだろうね。一方でデータが手元にある前提で色々なものをデザインできるからある種の serverless みたいのもやりやすいのだろう。いい話じゃん。

Facebook 360 のひと。この話とこの話のまとめ的な内容。ML ではなく Computer Vision が専門の人が DNN をどう捉えているのか垣間見えてよかった。

Facebook の NLP platform のはなし。まえに別の @Scale の talk で facebook.com に post された写真はすべて object recognition などの inference を適用されており production engineer はその結果をメタデータとして好きに使えるという話があった。その NLP 版。投稿テキストは色々解析されてるよ、自分のモデルもたせるよ、という。

Facebook の ML platform は製品にべたっとくっついており、なかの人には使いやすそう。投稿にある画像とかテキストを解析したうえで contextual  に発動する機能やシグナルをちまちま足していくのはまさにスケーラブルな問題だと思うのだよなあ。昨今の FB の異常な売上の伸びと照らしあわせ、ML 絡みでなにか金脈を引き当ててるとしか思えない。完全に conspiracy theory ですが。

微妙だったセッション.

Sandcastle という Facebook 内製 CI の話。その CI が遅かったりスケールしなかったりしたのをなんとかしたよという内容。話がどうこうではなくシステムのデザインが危なっかしい感じでそわそわした。CI なのになぜかクラスタマネージャみたいのを再発明していたり、コンテナとかを使えば良さそうな部分で謎のファイルシステムハックをしていたり。システムもおかしいけれど前提となる要件もおかしい。ビルドをするには 50GB ある monorepo を clone する必要があってそれが遅いだとか、ビルド対象によって必要な依存ツールが違うのでそれを揃えるのが大変とか、なんか前提が色々ヘン。必要なぶんだけ shallow checkout 出来たほうがよくね？ビルド環境もっと統一したほうがよくね?  iOS 向けビルド環境は別でよくね? てか monorepo やめたほうがよくね...? などと思ってしまう。

Google の monorepo も正直そんなによくないと個人的には思っているが、Facebook は使える言語とかの自由度が高いせいでより一層物事を難しくしている感がある。そういう autonomy を許すなら VCS も分けた方がいいのではないかな... 挙句の果てには CI だけでなく CD もしたい (のでクラスタマネージャには geolocational な条件も指定できる)とか CI 環境にログインしてコードをいじれるとか。完全に狂ってる。自分は FB テクノロジに憧れがある方だと自負しているけれども、これは近づきたくないなとおもいました。やはり monorepo 勢はなにかしら狂っているのでコードは git で扱える粒度くらいにしておくのが良いですよ。

Talk 以外に poster session のような展示もあり、そこで Caffe2 がモバイル版 (Caffe2go) のデモをしていた。あれ caffe2go ってオープンソースになってたの？と尋ねると、二週間前に公開したそうな。そして Android 版は OpenGL をバックエンドに使えるという。へー。ただし pixel shader なので matmul はできず  convolution だけのように見える。まあ GPU の conv で小さく畳み込んだ後に CPU で feedforward するのはアリなのかもしれない。とはいえ RNN とか GL じゃ無理そうじゃね？NLP の仲間には GPU は使わない割り切りでいくのだろうか。

あと Snapdragon NPE サポートのコードもあるが、いまいちアーキテクチャ的な整合性がわからん・・・。

そのほか。聴衆に Slack の普及が目についた、近隣の人々が開いている laptop の画面をチラっと見るとだいたい Slack を眺めている。流行ってるなあ。

via Misfit Vapor Smartwatch - Misfit

ロクな時計がなくて絶望していた Android Wear だけれど、これはよさそう。しかも $200. 買う気になる。

Misfit というのはぱっとしない fitbit みたいな会社っぽい。体力ないおかげで独自スマ時計ではなく Android Wear を採用してくれたのはよかったね。Fitbit といえば Fitbit Iconic はバッテリーのもちなど含め悪くはなさそう。しかし自分の欲しいアプリは Android Wear 用なのだった。

追記 10/24

ようやく発売された！が一瞬で売り切れ買いそびれた・・・Sigh.

via GloVe: Global Vectors for Word Representation, paper.

授業にでてきたがよくわからなかったので復習。最終的な式変形の根拠は相変わらずわからないが、モデル自体はわかった。occurrence matrix を計算してから regression を解く。たしかにこの方が効率良さげ。

TensorFlow の実装ないかなーと眺めていたら @stanfordnlp の tweet が参照している github repo があった。コードも単純げ。まあモデルが単純だからね。TF  も自社発の word2vec だけじゃなく glove もサンプルに入れといてほしいもんです。Innovation happens elsewhere の精神が足らなくて心配。

CS224n をやりはじめたのだけれど、最初の宿題から早くも挫折。むずかしす...  「Softmax/Word2vec の微分を求めましょう」や「NumPy で Word2vec のコードを書きましょう(穴埋め)」など。最初にみた授業は講義時間の半分くらいその証明に費やしており、かったりーとハナクソほじりながら見ていた。ごめんなさいとしかいいようがない。最初の方の簡単なやつだけやって、あとは降参。数式系はともかくコード課題が出来ないと自分の無能に打ちひしがれる。

授業はまあまあ面白いし参照されている論文も relevant ぽいので、落第しつつも今のところコンテンツは消化する予定。この授業をやっているだけで今年は終わってしまいそうだ...

宿題を本気で突破したいならビデオもぼんやり見るのではなく授業をうけるかのようにがっちりノートを取る必要があるのだろうなあ。 224n の前身 224d には lecture notes がある。231n にもある。224n にもつくってくれー。数式とかをさっと参照する方法がないと辛い。

次のビデオからはいちおうノート用紙を用意のうえ鑑賞します。はい。

それにしてもコンテンツの題材はともかくシステムとしての出来は Coursera の方が良いよなあ。 cs224n はビデオも一本が 80 分くらいあって集中力が保たないしそもそも一日では見終わらない。そして宿題も複数のビデオを見終えた後にドカっとやってくる。ビデオを小さく、宿題も細かく出してくれる Coursera の素晴らしさを思い知る。Hinton NN だって Coursera じゃないところで授業うけたら間違いなく瞬殺されてしまったよ。きっと。

まあ cs224n も utoronto も高い授業料を払って大学に通っている人々には TA などから手厚いサポートがあるのだろうけれど。

追記

せめて正解は覗いておこうとどこかの誰かが書いた宿題コードを見ていたら, "see note1 p12" とかかいてある。はて、とサイトをよく見ると・・・ノートあるじゃん!!! OMG!!! 今日はこれを読みます。はい。

via Roy sells ThoughtWorks

受託開発Javaっ子だった頃に憧れた素敵コンサルティングファーム ThoughtWorks を、創業者が売っぱらってしまったという話。景気が悪いせいで買収とかではないようだけれども、それでもちょっと寂しいね。最近はすっかり存在感がなくなっていた。かつての有名人も多くは ThoughtWorks を去った。そんなひとびとは今頃なにやってるんだろうな。

AutoFactory という factory コードを自動生成するライブラリがあり、仕事で使っている。

AutoFactory は Dagger や Guice などとセットで使う。DI したいけれど Dagger のコンテクストが必要な依存オブジェクトをすべて揃えられないとき、手元にあるオブジェクトだけを inject した factory をつくっておく。そして後から残りの引数を factory に渡し、最終的に欲しいインスタンスを create() する。

要するに関数としての constructor というか new に partially applied な関数としての factory のコードを生成するのが AutoFactory の役割。コードベースが Dagger heavy になるにつれこういうものが欲しくなるのはわかるしまあ便利なのだが Java のダメさを象徴してもいる。

Java はむかしよく FactoryFactoryFactory と馬鹿にされた。Functional POV だと FactoryFactoryFactory は単なる高階関数である。高階関数にある程度の認知的負荷があるのは仕方ない。FactoryFactoryFactoryを笑うものは関数型の奴らも笑えるのか。

と以前はおもっていたけれど FactoryFactoryFactory のダメさはまさに関数でない点だなあ。関数でないがゆえに、というか Java が関数的な道具立てを欠くがゆえに、コンストラクタに引数を partial application して Factory をつくったり、そこから更に FactoryFactory を作ったりすることが出来ない。逆に FactoryFactoryFactory を uncurry して必要な引数をまとめて渡す、とかもできない。だから仕方なくコード生成に頼る。この functional composability の欠落が Java の残念さだと今はわかる。

一方で今 Java を書くのは 15 年前に C を書くようなもので、そういう残念さは所与のものとしてつきあっていかないと精神衛生を保てない。だから AutoFactory も conceptual backporting だと思って付き合えば良い。

機械学習の仕事ができないかなーとぼんやり思うも、今の知識ではまったく無理、どころか下っ端として使い物になるのにすら 3-4 年かかりそうな感触。ただ情報産業の関心がコードからデータにシフトしていく流れ自体は変わらなそうなので、いますぐに機械学習は無理にしろもうちょっとデータに近い仕事をしたい。しかしデータに近い仕事というのがよくわからない。データエンジニアとかがそうなの？世間の求人などをみながらつらつら考える。

Analytics Stack

データの仕事の一番下にはインフラを作る仕事がある。ログのストレージだったり OLAP のデータベースだったり。OSS なり商用なりのソフトウェアをもってきて運用する仕事かもしれないし、組織の規模によってはそういうインフラ的ソフトウェア自体を開発する仕事もある。世間では「インフラエンジニア」と言われる職種の一部に見える。インフラエンジニアは、データよりはコードの仕事に近い気がする。ふつうはデータの中身を解釈しないだろうから。

次に、そういうインフラにデータを ingest する仕事がある。それは serving のレイヤからログのストレージにデータをつなぎこむ仕事かもしれないし、生のログ(アクセスログとか)をもうちょっとプロダクトドメイン寄りのログに整形、集計しなおす仕事かもしれない。これは世間では「Data engineer」と呼ばれている仕事な気がする。Hadoop とか Spark とか Kafka とかでコードを書く世界。Data engineer は、インフラエンジニアよりはデータの中身を知っている。Schema とかわからないと整形できないから。ただ主要な関心は automation とか scalability とかにありそう。

Data Engineer の用意したデータから UI を作る人がいる。可視化したり, drill down の手段を用意したり、あとは alert の画面を作ったり。世間では Visualization Engineer とか、単により広いくくりで Fronend Engineer などと呼ばれている。Data Engineer よりはニッチで、サードパーティのツールで済まされてしまうことも多そうだけれど、一定規模以上の企業には専業でやってる人もいるし求人もある。このひとたちは Data Engineer 以上にデータの中身を気にしている。一方で何か insight を導いたり意思決定をしたりはあまりしなそう。

Data Engineer と Visualization Engineer は Analytics とかなんとか言われるチームで一緒にはたらいていることが多いように見える。Analytics のチームには、こうした人たちがお膳立てした platform で実際にデータをつついて reporting をする人がいる。いわゆる Data Scientist とか Analyst と呼ばれる人たち。この人達はデータの中身を気にしている。というかそれが主な仕事。色々な調査から insights を導き出して report したり、偉い人や顧客の質問に答えたりする。

Analytics の platform は PM とかエンジニアも必要に応じて使い product decision の材料にしている。Product team だけでなく Sales とか Partnership とかの人も、たぶん使っている。こういう人たち...つまり自分とか...は数字の中身を気にしているが、一方でたいして難しいことはしない。多くは集計して比べるだけ。

この Infrastructure - Ingestion - Visualization - Analytics というスタックはいわゆる Data Warehouse というやつで、基本的には中の人が意思決定をする道具である。意思決定の部分を機械学習とかで自動化しちゃうのがモダン Analytics なのかもしれないが、中の人のための道具であることに代わりはない。

Discovery Stack

Analytics とは別に、 Production でデータを使う人たちがいる。Search, ads, feed, recommendation などの ranking アルゴリズムを書いている人たち。あとは anomaly/fraud/spam detection とかをしている人たち。など。ひとまとめにする良い言葉がないけれど、仮に Discovery Stack とでも読んでおこう。

この人達は Data Warehouse のログだけでなくサービスがもっているデータ(商品情報、 UGC など)も使う。まあ Analytics でもサービスのデータを使うことはあるだろうけれども、重点の置き方が違う。より大きな違いとして discovery stack は製品やサービスの一部として結果をユーザに serve する。なので性能とか自動化とかが不可欠。エンドユーザは SQL を書かないし、結果がでるまで何分も待ちはしないから。あとはサービスの出来に直結するので既存の製品/SaaS とかををそのまま使うより自社開発することが多い、気がする。いろいろ求人がある。

Discovery Stack にも Analytics Stack 同様インフラがある。Analytics stack と共有している部分もある。あとはふつうにデータベースとか。ここでいうインフラエンジニアはざっくり言うとデータベースとかを開発したり運用したりする人、ということになる。ただユーザに serve する必要があるので serving 側のインフラも面倒をみている場合がある。データの中身は、たぶんさほど気にしていない。

純粋なインフラの上は, Analytics ほど分業化されていない印象。どちらかというと偉いプログラマが discovery のコアとなる システムやアルゴリズムを作って、下々がそれをチューニングしたり拡張したりするかんじ。 ingestion も機能毎のチーム単位でなんとかしているように見える。なのでインフラより上の Discovery Stack のプログラマは割とみんなデータの中身を気にしていると言える。なぜ product 側のほうが end-to-end な性質が強いんだろうね。Analytics Stack の Data warehouse よりも製品毎のアーキテクチャのばらつきが大きいからだろうか。

Discovery Stack のコアには ML があることが多いだろうけれども、下々のプログラマはそのモデルを触るのか。よくわからない。どちらかというとシグナルを探し出して新しいパラメタとして既存のモデルににつっこむのがメインなのではないかなあ。そうでないとでかいシステムを安定して動かせなさそうじゃん? ただモデルの中身は理解しているのだろうな。

Prevalence of ML

機械学習の普及に伴い ML Engineer みたいな求人をよく見かけるようになった。上に書いたような文脈でこの職種を解釈すると、 ML Engineer には新しい discovery のジャンルを開拓することが期待されている、ように見える。新しい問題に ML を適用し production で動かす仕事。要するに discovery stack の偉いプログラマ相当。

新しい discovery システムが使う ML モデルの構築は Researcher という専門家がやってくれる場合がある。あるいは逆に researcher のアイデアを production にもっていくために ML Engineer が求められる。そして新しい discovery systems は成熟しておらず platform になっていないため下々の出番はあまりない。人海戦術に値するスケールがあるかもわからないし。

従来の Discovery Stack でも色々なものが ML というか DNN に置き換えられていくにつれ Researcher の存在感が大きくなる。これが一過性のもので DNN が成熟するにつれ ML Engineer だけで足りるようになるのか researcher の強い立場が続くのかはわからない。

伝統的な discovery とは違う局面で nice-to-have 的に ML を使う場合もある。そういうときは product team のエンジニアが researcher からモデルをもらって回しておわり、みたいになりがち。このとき エンジニアは Analytics Stack の Data Engineer に相当する役割を勤めている。つまり、データやモデルの中身はそんなに気にしてない。Researcher の片腕となる ML Engineer とは違う。

でも自分の近所でこの仕事をやっている人をみると、データは気にしている雰囲気があるな。モデルをどのくらい理解しているのかは知らないけれど・・・。

ML As A Product

こうした「とりあえず ML してみようぜ」的な世界の反対に、ガチ AI みたいなジャンルもある。翻訳、音声認識など。こういう機械学習をそのまま製品にしたようなプロジェクトは、意外と求人のスコープがわかりにくい。コアのアルゴリズムやモデルを作る人もいれば、それをチューニングする人もいる。そしてアルゴリズムにデータを流しこんだり UI をつけたりする人もいる。Discovery Stack の求人以上に End-to−End な性質が強いせいで、仕事がどれだけデータに近いのかすぐにはわからない。逆に flexibility があるということかもしれない。そしてこういうアカデミアが state of the art を競い合っているようなジャンルでデータに近い仕事をするのは大変そう。ジャンルの成熟度ゆえ超大規模システムで下々にもやることがある、という可能性もないではないけど、どうなのだろうなあ。

外野たる自分の理解を書き出してみた。どのくらいあってるのかね・・・。それなりに正しいと仮定して話を進めるしかないので話を進めると、ではほぼクライアントサイドの経験しかない、かつ特に活躍もしていないおっさんが紛れ込む余地があるのはどこだろう。そして自分がやりたいと思える仕事はどのへんだろう。

データよりコードに近い方が generalist 枠で紛れ込みやすい。つまり Data engineering とか Infrastructure の方が入り込みやすい、気がする。一方で、できるだけ実際にデータの中身を解釈する仕事をしたい。この二つは相反しているので、データに近づける範囲で近づくしかない。

Analytics, Discovery, Emerging Areas, ML Product という軸はどれがよいか。Analytics はプログラマ自身がデータを扱う余地は少なそうなので、なんとなく違う気がする。Discovery はよさそう。ただ敷居も高そう。Emerging Areas の ML Engineer は更に敷居が高く、即戦力以外はお呼びでない感。ガチ ML Product は、わからん。データからは遠い仕事に回されてしまうようにも思えるが、job description をみて position を選べばそういう心配はないかもしれない。しかしそれは end-to-end な性質が近いという自分の予想と矛盾する話でもある。

未経験おっさんの入り込む余地は・・・基本的にはなさそうなので妥協したり運を頼ったりで無理やり下っ端として入り込むしかなさげ。無茶に失敗し、データに近づききれず残念な仕事をする羽目にあうかもしれない。が、それは自分がとるべきリスクなのだろうなあ。最低限サーバ側でデータのパイプラインの一部に入り込めればよし、くらいが現実的か。謎のプロプリエタリインフラとかあんましさわりたくないがやむなし・・・。

あまりうれしい結論ではない。おとなしく Android  仕事を続けろということだろうか。それで良いといえばいいのだけれど。

まあ目先の仕事はあるので気長に考えます。

via [1708.02637] TensorFlow Estimators: Managing Simplicity vs. Flexibility in High-Level Machine Learning Frameworks

かっこいい TensorFlow の high level API を作ったから使ってくれよな、という話。特に目新しいことを主張しているわけではなく、誰が書いても大差ない割にバグりやすい boilerplate を TF に入れたということらしい。

主要な API は tf.layers と tf.estimators. この2つは直行している。話の中心は tf.estimators だった。train のループなどのかったるさを引き取ってくれるというから、使い方を覚えてやろうか思う程度には説得された。 tf.keras もなかみだいたい tf.layers だった気がするし（とおもって眺めると tf.keras の方がだいぶ充実してる...再利用できる範囲では tf.layers に依存している模様。)

ところで検索すると tf.contrib.layers と tf.contrib.learn.Estimator というよく似た API がある。 tf.contrib には API のうち unstable な部分を入れてるのかなー・・・と思いきやよく似た非互換の実装が入っている。まじか。 tf.contrib. で試作したのち tf. で実装しなおしたのだろうか。そんなら古い方は deprecate してくれ。カオスすぎ・・・。

TF は全体的に荒々しすぎ人々がついてくるのかいつもながら不安。tf.estimators もほんとに依存してだいじょうぶなんですかね。まあ自分のような余暇プログラマが心配しても詮無い話ではある。会社の中で使ってる人たちはおつかれさまです。

via The Complete Software Developer's Career Guide: How to Learn Programming Languages Quickly, Ace Your Programming Interview, and Land Your Software Developer Dream Job: John Sonmez: 9780999081419: Amazon.com: Books

Soft Skills 著者な人気者 John Sonmez さんの新作。

それにしても・・・先月でたばかりなのに 265 reviews で 5 stars とか嘘くせー。ファンベースを使って小細工してるとしか思えん。一方で、そういう self promotion および community building skill の高さに尊敬すべきところがあるのも事実。プログラマーというよりプロブロガーの貫禄。

あるいは収入源としてのソフトウェア開発業に焦点をあわせる forthright なところがウケたのだろうか。たしかにそういう本ってインタビュー攻略本くらいしかないよね。

追記

Amazon Unlimited に入っている本はレビューが沢山つく模様。なるほど。

via Sutton & Barto Book: Reinforcement Learning: An Introduction

Reinforcement Learning どんなもんなのかなーとウェブをぶらぶらしていたら、もうすぐ定番教科書の二版がでるよ、という。ドラフトが公開されていたので一章だけ読んで見る。まるばつゲームの話とか、なかなか楽しげ。勉強してみたら面白いジャンルなのかもねえ。今はあまり寄り道できる資源がないけれど、いつか気が向いたら続きを読んでもいいかもしれない。その頃には二版どころか三版くらいになってるかもしれないが・・・。

自分が抱いている TensorFlow のメンタルモデルを書き下してみる。現時点での自分の理解を整理記録するのが目的なので、正しいことは期待していない。

TF はある種の言語処理系、インタプリタである。専用の文法はなく、プログラムは Python の DSL として与えられる。TF の Model はその TF 言語で書かれたプログラム。プログラムは Session を通じて実行できる。

プログラミング言語としてみた TF 言語の表現能力は高くない。たとえば関数とかは定義できない (ほんとに?)。再帰もない気がする(ほんとに?)。Ops と呼ばれるプリミティブを式として組み合わせて何かを計算するのがもっぱら。Ops はプリミティブなので TF 言語自体では定義できない。ただし C++ や Python で拡張することはできる。SQL の UDF を定義するようなもの。まあ SQL の UDF は SQL で定義できるのかもしれないが。誰得。

TF 言語はプログラム内の式の微分を計算できる。それが典型的なプログラミング言語と大きく異なる。この機能を実現するため、全ての Ops は自分の微分を定義しないといけない。(たぶん全てではない。微分要不要の境目はなに?)

とはいえたとえば BUGS のような特殊なドメイン言語は微分じゃないけど似たような特別な性質を持っているので、すごく珍しい話ではない。

TF 言語はまた、並列化や分散化、永続化などを組み込みでサポートしている。これは Python をネイティブ言語とする PyTorch などとは異なるところ。DSL として自分の言語を持った強みと言える。かわりに分岐とかループとかを書くのがめんどいのが欠点。

DSL として言語/モデルをわけておく別の利点は、Python のレイヤでメタプログラミング的なことがやりやすいこと。たとえば Model/Variable の save とかで保存したいノードを選ぶ、みたいなコードを普通にかける。他の言語だと compiler plugin とか macro とか reflection になりがちな部分が普通に触れる。一方で普段から reflection だけでコードを書かされているだけなのでは、というツッコミはありうる。Lisper と Haskeller だけがこのぎこちなさをディスって良い。

と書き出してみると、主張の正しさも何も肝心なところはまったく理解してないと思い至る。

たとえば TF 言語処理系だというなら、そのインタプリタはどのように実装されているのか。プリミティブのうち、本当にプリミティブなものは何で、どこからが sugar なのか。たとえば Variable というのはどのくらい特別な存在なのか。Optimizer はどのように動くのか。Saver で保存される Variables と GraphDef はどんな関係があるのか。などなど・・・。

そのうちコードでも読んだほうがいいんだろうけど、まあ当面は基礎を地道にやります。はい。

via Deep Frying Without a Deep Fryer: Which Pan Is Best for the Job? « Food Hacks Daily :: WonderHowTo

自分の献立の棚卸しをしたところ、そろそろ揚げ物をしていなのがボトルネックに思えてきた。でも苦手なのだよなー揚げ物。ゆこっぷ（奥さん）は揚げ物が得意で、中華鍋を使って鶏の唐揚げとかを作る。でも中華鍋、ユラユラするので揚げ油が入っていると怖い。

揚鍋を買おうかと Amazon で調べてみるも、どれもデカい。そして basket は無駄に思える。世間の家庭料理人はどうしているのだろうかと調べるうちに上の記事にでくわした。Wok Pan がいいよ・・・ってそれゆこっぷと同じじゃん！

揚鍋は諦め、Wok pan で揚げ物の練習をします。はい。

というわけで Learning TensorFlow 本の写経終了。

後半 high level abstraction や distributed TF などいくつかの章はスキップ。コードも写経といいつつ気に入らないところが多すぎるので適当に加工しながら書いた。読むだけよりは理解が深まったと思う。

理解が深まったところでこの本のサンプルコードの感想: 半分以上オフィシャルサイトやサンプルコードのコピペじゃね？一冊にまとまめる価値はあると思うけれど、コーディングスタイルや品質を揃えるところでがんばってほしかった。著者らはサイエンティストとしてはさておき Python プログラマとしてはだいぶ素人っぽいかんじ。まあ自分が読んでるのは early access 版なので、out of beta するころにはよくなってるのかもしれない。

さて、次はなにするかなあ。６月末の時点では大学の授業動画を眺めるか実際になんか作るか、などと考えている。その他のオプションとしては Keras の親玉の本を読む、NMT のチュートリアルをやる, Udacity でなんかやる、などが考えられる。さて・・・。

Learning TensorFlow, データパイプラインの章は「このへんの API は変わりそうだけど一応紹介しとくね」と書いてあり、案の定 1.2 から新たに Dataset がはいった。これが新しい標準になるということらしいので、 Learning TF のデータ IO の章は飛ばし Dataset API を軽く試してみる。まあまあ良さそう。

どちらかというといまいちなのは推薦ファイルフォーマットとされている TFRecord および tf.train.Example. まあ TFRecord はいい。しかしこの Example, ひどくね？ Proto むきだしで、これを Tensor と相互変換する方法がロクにない。書き込みが多少面倒なのは我慢するけれども、読む方はもっとスカっと読ませてくれよ・・・・。

こうした推薦フォーマット/API にのっとるとマルチスレッディングの恩恵が受けられるというけれど Proto のパースと整形のために tf.py_func を挟まざるを得ず、これほんとに off-loading されるのかね。理論上はたとえばグラフの評価は完全に C++ だからそのあいだ GIL を手放していれば別スレッドで Python コードが動けるわけだけれども、ちゃんとそのへんがんばってるの？なぞ。

適当な Proto  じゃなくふつうに HDF5 とかをサポートして、ファイルから Tensor へ直行できるようにしてほしいなあ。

Wikipedia, Paper.

機械翻訳のスコア付け方法。スコアは 0 から 1 の間になるといっているけれど、 NMT の論文たちはもっと謎の数字 (30 とか) になっている。なんなの... よくベンチマークにでてくる WMT のサイトをみると NIST BLEU Scorer を使えとかいてある。これが謎の数字の source of truth なのだろうか。そして一部の翻訳データは Yandex など企業が提供しているのだね。日本の景気のいい会社も J-E のデータを提供して researcher が日本語でテストできるようにしてほしいもんです. French だの German だの今時どうでもいいじゃん。Japanese もどうでもいいっちゃいいけど自分的には重要。

BLEU 自体は ngram を使うなどよく考えられた指標だなと思いました。

モデル定義 DSL と評価結果が混ざる問題は、今のところモデル定義を適当なクラスに押し込んでお茶を濁している。

class Model(object):
    def __init__(self):
        self.graph = tf.Graph()
        with self.graph.as_default():
            self.x = tf.placeholder(tf.float32, [None, 784], name='x')
            self.W = tf.Variable(tf.zeros([784, 10]), name='W')
            self.y_true = tf.placeholder(tf.float32, [None, 10])
            self.y_pred = tf.matmul(self.x, self.W)
            self.loss = tf.reduce_mean(tf.nn.softmax_cross_entropy_with_logits(logits=self.y_pred, labels=self.y_true))
            self.train = tf.train.GradientDescentOptimizer(tf.constant(dtype=tf.float32, value=0.5, name='weight')).minimize(self.loss)
            self.accuracy = tf.reduce_mean(tf.cast(tf.equal(tf.argmax(self.y_true, 1), tf.argmax(self.y_pred, 1)), tf.float32))

フラットに置いておくよりはマシなのでこうしているけど、もうちょっとマシな方法ないのかなーと思ってしまう。クラスでなく関数にすると self がきえてすっきりする一方、公開したい tensor に名前をつけるのがめんどくさくなる。

今あまり追求しても overkill な気がするし独自の流儀を開発するのもやだから、誰かなんとかしておくれ。それなりにまとまった規模のある TF プロジェクトを覗いてみるべきなのかもなあ。

via Andrew Ng: Announcing My New Deep Learning Specialization on Coursera | Coursera Blog

みんな大好き Ng 先生が Coursera に帰ってきて NN 教えるぞ！！

でも個人的には微妙なスコープ。一年前、半年前に来てくれていたら Hinton / Goodfellow じゃなくてこっちをやった気がするが、このくらいはさすがに勉強してしまったよ... Batch Norm とか Residual Network とか微妙に Goodfellow がカバーしてない話題もあるぽいとはいえ, 結局どちらも資料を読んでしまったし。

そしてシラバスみたかんじ TensorFlow を使うらしい。つまり Matlab ではない。きっと NN 入門の鉄板コースになるね。自分も無駄な苦労をせずこっちで入門したかった。はー・・・。

Via “Rest and vest”: engineers who get paid and barely work | Hacker News

大企業のやつらは出世しなくても給料がいいとか株のせいで億万長者だからとかでろくに仕事もせず９時５時で働いててけしからん、というような話、の HN のスレが予想通り盛り上がっておりうっかりつらつら眺める。ストックで億万長者になってるのに働いてる奴らなんなの？というスレで・・・

There's something corrosive to the soul about having no purpose in life.

I retired once. It lasted about 6 weeks, then I decided to create the D programming language. I plan to work until my mind no longer functions. I'm not interested in retiring.

とまさかの Walter Bright 登場! かっこ良すぎるが HN のスレでそんな息巻いてるのはちょっと微笑ましい。

そのほか昔はやっていた会社で働いてない人たちがいたエピソードが次々と語られており、あいかわらずろくでもない、とおもいつつ読んでしまう悪趣味な自分よ。

Tensorboard, サンプルはみな重みを観測するばかりだけれど、Backprop 理解しろ記事を読んで以来 gradient を監視したほうが良いのではと思っていた。でも gradients って TF の外側から観測できるものなのだろうか。

とおもって調べたら tf.gradients という API を使えばいいらしい。これが TF autograd の入り口なのだね。そしてこの周辺の API を使えば Python だけで optimizer も書けそう（書かないけど）。TF, 案外 extensible につくられていた。見くびっていて悪かった。

Tensorboard で graidient を観測するサンプルもあった。

写経つづき。

RNN/LSTM のサンプルを動かす・・・と、CPU が振りきらない。最大 400% のところ 250% とか。CNN では振り切っていた。いくら toy program で dimention が小さいとはいえ、Laptop の CPU も振りきれないとはだいじょうぶなのか RNN. seq2seq も LSTM を stack してレイヤごとに GPU を割り振る。無理やり並列度を上げてる感じ。GEMM とかはある程度並列化できるのだろうけれど。カーネル単位でじゃんじゃん並列化できる CNN と比べると辛い。

もっとも逆に言うと higepon_bot みたいのをトレーニングするのに速い計算機を借りる必要がない(借りても無駄)ということだから、趣味プログラマ的には良いジャンルなのかもしれないなあ。

去年 deep learning とやらを勉強しようと思いたって最初にたてた目標は "word2vec を理解する" だった。適当な目標にむかって逆算しながら入門する方が効率が良いと思ってたてたマイルストンだけど、いま思うと筋が悪かった。はさておき、そのときは細々した資料を読んだ結果テキストデータを通じ distributed representation を学習できるという A Neural Probabilistic Language Model の主張したいことはわかるようになったものの、アーキテクチャとかはわかららずじまい。挫折して逆算は諦め、普通に入門することにした。

時は流れ Learning TF 本をはじめ各種 TF 入門に word2vec が出てくる昨今。しかし実際にコードを写経してみるといまいちわからない。何がわからないのか、いまいちど word2vec の paper を読みなおしてみる・・・と、やっぱわからん。

さすがに一年前よりは理解が進んでいるけれど、データや語彙のサイズに依存しない probability (loss) の計算方法という肝心な部分がよくわからない。

TF tutorial 群では  tf.nn.nce_loss という関数を使っている。ということで次に Learning word embeddings efficiently with noise-contrastive estimation を読む。が、わかんねー。Linear regression を解いてあげればいいんだよというけれど、肝心なところがめちゃ確率変数の世界。Noise Contrastive Estiamtion の出典はこれだということでチラ見したら理解するのは無理げな雰囲気。撤収。Word2vec のような一見基本的なものがこんなに確率変数ばりばりの方法に依存していたとは・・・。

nce_loss のAPIからリンクされている資料によると、NCE やオリジナルの word2vec がつかっている negative sampling などは candidate sampling とよばれる手法のひとつらしい。割と出番がありそうだけれど理解できてない。つらし。仕組みはともかく意図はわかるので blackbox として使うのだろうな。

via Introducing Vectorflow – Netflix Technology Blog – Medium

NetFlix が D で NN のライブラリを書いてしまったという話。どうしてしまったんだ・・・。Sparsity を扱いやすくする、とかいってるけど書きたいから書いてしまったとしかおもえん。

via Why AI and machine learning researchers are beginning to embrace PyTorch - O'Reilly Media

Facebook, research は PyTorch で production は Caffe2 なのか。そしてむかし TF 登場以前 Torch に入門しようとした時はドキュメントがさっぱりわけわからなかったけれど、PyTorch は充実してるね。ぱっとチュートリアルをながめたかんじ悪くなさそう。TF のグラフ定義言語と実行環境がまざって混乱する感じがない。これが imperative style API の良さというやつか。

Immediate mode の gradient はどう計算するかというと、tape based automatic differentiation というテクニックを使うらしい。具体的には gradient に参加させたい変数をオブジェクトでラップし、関数の側にもそのオブジェクトを識別するラッパーを用意し、オブジェクトに適用された関数というか計算を全部覚えておく("tape")。で、その記録された計算を逆にたどって微分する。計算を記録したあとは TF とかと同じということだろう。

PyTorch が引用しているもとねたの一つは Autograd という Python のライブラリ。これは numpy ベースで書かれた関数を自動微分できるという。これを Twitter が Torch (Lua) に移植し、それを更に PyTorch が取り込んだという紆余曲折。Autograd ライブラリもオリジナルというわけではない。この解説記事からリンクされた autodiff.org の参考文献をみると歴史あるジャンルであることが伺える。科学者えらい。

などと NN  framework の dynamic と static の違いがわかってよかった。ついでに TF が numpy 互換っぽい API になっているのも自動微分の流儀なのだと理解した。

追記。PyTorch 0.2 のリリースノートを見てみる。

二階微分ができる。しかも近似ではないっぽい。つまり ops が自分の二階微分を提供しないといけない。まじか。大変じゃね？しかしおかげでむずかしい GAN が実装できるらしい。

分散トレーニング。どうもスクリプトを書くノードに送りつけて実行するスタイル(MPI 系)ぽい。まじか・・・。

TensorFlow とは違う進化の仕方をしているなあ。遠目に見つつ、そのうち気が向いたら試してみよう。

via Transitioning entirely to neural machine translation | Engineering Blog | Facebook Code | Facebook

Facebook 翻訳が NMT になったぞ！！

ConvS2S なのは English-to-French だけらしい。やや意外。言語との相性みたいのがあるのだろうね。とはいえ RNN ベースと CNN ベースのシステムの両方を同時に作ったというのはガッツがあるなあと思ったのだった。

via Trump Supports Plan to Cut Legal Immigration by Half - The New York Times

コメント欄がすごいことになってる。

成人してない子供と奥さんはOK。成人した子供や親族はだめ。親もだめ、ということらしい。子供や親族はともかく親は来ても働かない気がするが・・・。それにしても sibling も sponsor できるとは知らなかった。

アメリカの移民の国としてのアイデンティティというのを自分はあまりよく理解できていない。移民にけちくさい国から来た身としては、しょうじき親族や親が駄目というのはまあまあ妥当に感じてしまう。でも親を呼びたい気持ちはわかる。たとえば歳を取った親のそばにいてあげたいとおもったら帰国するしかなくなってしまう。Canada と同じという話だけれど、Canada は移民の国みたいな identity をもっているのだろうか。不明。

しかしこのポイント制は厳しい。TOEFL のスコアとか年齢で縛られると辛い。

via My Advice To Anyone Starting A Business Is To Remember That Someday I Will Crush You - The Onion - America's Finest News Source

Bezos 氏愛されてるな。Amazon 最強伝説エピソード収集の一環として記録しておく。それにしても10年前は検索会社についてこういうことが言われていたものですよ。遠い遠い昔にはね...