以前大変失礼にもこまっちの人の立場を「理屈云々じゃなくて単に嫌い」と切って捨てた私が通りますよ。いや、こまっちの人が嫌いなんじゃなくて、学会系のコミュニティが本質的に嫌い。こまっちの人はがんばってると思います。
んで、この下りだ。
今年このプログラムについて2つのハイレベルな「不満」があると思う。1つ目は、学会で以前よりますます「自分はほげほげのデータをダウンロードし、なにかを予測するためのモデルを全く普通の素性で訓練し、なんとなく動いた」という論文を目にするようになってきた気がする。あなたの論文について言っちゃってたらごめんなさい。でも、こういう論文は本当に癇に障る。そんな論文からはなにも学ぶことがないように感じる。機械学習が信じがたいくらいうまくいくことはみんな知っているし、それに対するこれ以上の証拠は必要ないのだ。で、もしさっきの文があなたの論文のことを言っていたとしても、それが言語についてなにか理解するための手助けになる興味深い分析もしているのであれば、それはいいのだ！
これは拙い3年程度の間、主に電力消費系アルゴリズムを調べていたときに私が思った、学会系論文のやってる不快な慣習と異常なほど似てる。
どういうことかというと、「電力減らすための複雑なすーしきを駆使したアルゴリズム考えたぜー。シミュレータで動かしてみたら減った気がするぜー。以上だ！」っていうもの。
実際の世界では複雑なアルゴリズムを電力を制御するKernelの最もコアなプロセススイッチャーあたりに実装するのははなはだアホだ。だってそのために電力を消費することになるし、ましてやKernelが扱うのは消費電力だけではなくリスポンス要求水準の違う複数のプロセスをタイムスライシングで割と平等にうまくやってるからだ。実際のシステムに落として評価しなければ有効性は評価出来ず、要するにこういう論文を読んでも複雑な数式で頭を痛める以上に学べることがない。
私が修士のときにやったことは実装系の人からすると涙目なほど単純だった。単に「実際にLinux Kernelを弄って」プロセススイッチのタイミングでcpufreqという電源管理モジュールに処理を移譲して、プロセス毎に取得したプロファイリングデータを元に電力を上げ下げできないか、という話だった。すんごく単純で今でも反吐がでる。このアイディアの肝はプロセス切り替えの度にCPUの周波数を変更することがオーバーヘッドにならないかという話だが、当時のPenMは周波数変更のラグタイムが10ns以内に収まることを保証していて、それが故にこのアイディアは大筋割とうまく行った。
実際には当時の能力不足からコミュニティにパッチを送りつけると言うことはしなかったし、すべきでもなかった。実際、(現在に到るまで)Kernelコミュニティではプロセスごとに詳細にプロファイリングしなくてもondemandという、システム全体のCPU利用状況とかを見てなんとなく周波数を変えるアルゴリズムが優秀で、私が作った「プロセス毎の消費電力制御」は極めて限定的な状況でしかondemandに対してトータルでの電力消費性能(と、各プロセスの応答性能)で勝てなかったから。
まじめにやれば勝つのも出来ると思ったけど、当時の私はそれをやるほどinsightfulじゃなかったし、実装能力もたいしたことがなかったので頓挫した。また、Kernelの最もコアな部分であるプロセススケジューラと、オプションで取り外せる上CPU毎の癖をマジで真面目に考えなきゃいけないcpufreqモジュールをつなげるってアイディアがパッチとして取り込まれるfeasibilityをほとんど信じされなかった。というわけでアボートした。
この点に関してもうすこし掘り下げてみる。聞いたところでは、実際の電力消費業界では、OSから見られるCPUの周波数だけで消費電力を制御しているわけじゃない。CPU内部(やメモリ)の使っていないと思われるちっちゃいモジュールレベルで電源のオンオフをしていて、例えばメモリの特定のバンクが今使われてないのでこいつのスイッチは切っちゃいましょうなんてことをやるのが常態化しているらしい。もしそうだとすれば、仮にCPUの周波数を上記のように制御したとして、それで十分と言えるかといえばそんなことはない。OSから見えないレイヤのかなり細かい電力調節機構に任せている部分が結局全体の消費電力を制御する上で一番重要なんだという結論に至れば、わざわざプロセススケジューラとcpufreqモジュールをつなげてKernelの中に気持ちの悪い密結合を導入するメリットがほとんどなくなる。
なお、私の直観ではコンパイルをするマシンではondemandはコンパイル時間を若干伸ばす可能性があると思ってる。理由はコンパイル時のIO待の時間をondemandアルゴリズムが「CPUを使ってないので消費電力落としてもよさげ」だと認識する可能性があるという話で、つまりIOセンシティブなプロセスに対してondemandはオンデマンドすぎる、ってこった。でもこれは実際に調べてみないとだめ。私は単に、コンパイルするマシンではondemandを切ってる。
あ、話が長くなりました。で、何が言いたいかと言うと
実際のニーズや、社会で要求されている具体的な前提と要求なしに「へい、つくってみたぜ」って論文を出しても「すてきすてき！」ってことにはなかなかならず、そういう論文を引用して「へい、改善してみたぜ」っていう論文を出されてもさらにぽかーんで、これは象牙の塔が自己消費的なループに陥る典型的なパターンだと思う。
ここまでのネジがぶっ飛んだ話を上の記事と結びつけてみよう。「全く普通の素性で訓練」された実験結果は実際の環境のありとあらゆるちっこい実際的な問題でしばしば「理論的にはうまくいくんだけど、実際にはダメっぽいね」という結論に飛ぶことが多く、論文としては面白いけど使う気にならねーな、という結論に行き着きやすいということ。
今はコンセプトワークとしてはどの業界も多分かなり成熟していて、具体的な現実の問題に沿った問題設定をしない限り実業の人たちを「あ、これいい！」と思わせることは出来ない。それを知らずに修士くらいの人が「あうあう、ボクは新しいモデルを考えたのですよ！」とか言い出しても、多分それは使えない。
例外はあり、例えば実装界隈ではXenが研究畑からCPUの新フィーチャになるほど仮想化を推し進めた原動力だった(と、理解してる)。悲しいことに最近はあんまりXenに対する風当たりはよくない(らしい)けど、私が修士にいたころは「あ、これすごい」と思ったもんだ。象牙の塔の提案がIntelに「いいね！つくったげる」と思わしめるってのは、学会としては再考の栄誉なんじゃまいか。
自然言語の業界は私の範囲外なので、私の問題意識とこまっちの人の言いたいことが一致しているかどうかについてはあんまり自身はない。でも、実業界の涙目な現状を踏まえずに「へい、なんとなくモデルを思いついたよ」とか学生がやって、それでうまくいくほど自然言語業界がうまくいくとは私は思ってない。
今象牙の塔に欠けているのは現実の実装が何に行き詰まっていて、結果としてなんで学会からするとゴミに見えてしまうのかのroot causeを共有することなんだと思う。
話はぶっとんで、現在の日本銀行の総裁が経済学と実務の金融政策の関係についてこういったことを述べている。中央銀行が現実に出会った経済の異常事態に、そのときの私たちがどう対処したのかについて経済学の学会にそれを公表し、学者の今後の経済学の研究に役立ててもらい、その成果をまた金融政策の実務に携わる者が利用する。それが健全な経済学の姿勢なんじゃねーの、と。
前もいったけど私は日本のコンピュータ科学の象牙の塔は理屈抜きで嫌いだ。日本銀行は理論と実務の両方を駆使しなければ本当に有効な知見を得られないことをよく分かっていて、んじゃ、IT系の学会はそれを理解して、そういう行動を起こせているのか？
アルファネットの時代は象牙の塔の人たちが同時に実務をやらざるを得なかったので、こういうことは考えなくてよかったんだけど、いまや社会的なインフラになりかねない「くらうど」とかいうのが浸透し始めている時に、学部生が「くらうどにつかえるおーばーれいねっとわーくを考えてみました」とかやって、それが大企業で採用出来る水準であると期待出来る理由はどこにもない
