bonotakeの日記

元・ソフトウェア工学系研究者、今・AI系エンジニア

MLSEの来年に向けた取り組み

この記事は、機械学習工学/MLSE Advent Calendar 2019の25日目の記事です。

最終日ということで少し趣向を変えて、技術の話ではなく、MLSE(日本ソフトウェア科学会 機械学習工学研究会)の現在の取組みに関する話を書こうと思います。 なので、書く場所をQiitaでなく自分のブロクにしてしまいました。

僕はMLSEの立ち上げメンバーの1人ではあるんですが、特に夏頃からまたMLSEへの取り組みを本格化しました。 というのは、自分から見てMLSEの色々な課題が見えてきたからです。
特にそれがはっきりしたのが、今年7月に行われたMLSE夏合宿2019でした。

今年の夏合宿に参加して

夏合宿に参加して、参加者といろいろ話して気づいたのですが、1年以上前と変わらない課題意識を抱えてる人が沢山いたのです。
たとえば、

機械学習プロジェクトの標準的なプロセスを定めたいですよね。

といったコメントなど。
私たちは研究会として正式に発足する前、2017年の11月頃からずっと活動しているのですが、このようなコメントは2017年も、2018年の第1回ワークショップでも聞かれたものなのです。
新しい発見が出ないと前に進まない独自研究ならともかく、こういった活動は誰かが着手すれば進むのですが、みんな「欲しい」「やりたい」と言うものの、実際に手をつける人がいなかったわけです。

また、少し関連しますが、MLSEに参加を希望する方はすごく多いのですが、実際に自ら研究して成果を発信する人の数が少ないな、という印象もありました。これは僕だけではなく、数人のMLSE運営委員からも聞かれた話です。
MLSEは、各々が研究した成果を発表し合う場を提供する、というのが本来の趣旨です。もちろん分野の裾野を広げるために、自ら手は動かしていないが興味を持って情報を仕入れに参加する方もwelcomeなのですが、ただ情報をgiveできる人がまだまだ少なく、情報をgiveする人とtakeする人のバランスが現在非常に良くないのです。研究分野が機能するためには、もっと自らの手で研究する人が必要です。
今年の夏合宿は特に論文の査読なども行わなかったこともあり、発表された研究の成熟度・完成度は非常にまばらでした。研究成果を発表してくださる方を増やすには、発表の数を増やして裾野を広げることも重要ですが、質も重要です。これは我々がきちんと担保していく必要があります。

ワーキンググループの設立へ

先ほどのような問題はひとえに、現在の我々MLSE運営の至らなさだと思いました。
昨年、立ち上がったばかりの研究会に非常に多くの方に関心を持ってもらい、たくさんの方に参加してもらったので、どこか慢心というか、勘違いしてしまっていたのだと思います。 まだできて2年目なので、自ら研究してアクティブに参加してくれるプレイヤーが少なくて当たり前だったのですが、そこに気づかず、ただ発表の場だけを用意すれば勝手に色んな人が発表しに来てくれると思いこんでしまっていました。

ですので、単なるイベントの開催だけをやるのではなく、年間を通じて継続的に研究をサポートしていく必要があると考え、WG(ワーキンググループ、作業部会)を設置することにしました。
そして、いくつかのテーマを元に、複数の方に幹事になっていただくべく声をかけさせていただき、結果、3つのWGが発足しました。

  • プロセス・事例収集WG
  • システム基礎WG
  • 本番適用のためのインフラと運用WG
    • 機械学習基盤特有のシステムデザインのパターンを明らかにし、国内企業・組織における継続的で安定した機械学習パイプラインの確立を支援するWG

詳細はこちらに書いてあります。

来年の夏合宿

そして、来年の夏合宿についても、実施内容に色々手を加えました。(あ、僕は実行委員長に立候補しました。)
既にCFPが公開されていますが、こちらでもう少し動機づけのあたりを掘り下げて書いていこうと思います。

最近、特に機械学習関連分野の研究はarXivやストリーミングの普及もあって、新しい研究の情報はオンラインですぐ共有されます。ですので、特に国内学会が研究集会を開催する意義が昔とかなり変化している、あるいは変化させなければならないと僕は思っています。
それは僕が思うに、オフラインで交流するメリットを活かした、まだ活字などの形にならない萌芽的な研究やちょっとしたプラクティスの情報、あるいは課題意識を、参加者の間で共有し、議論することです。

ですので次回の夏合宿は、論文を募って発表してもらういわゆる研究発表会と、皆で議論をするワークショップのハイブリッドを目指すことにしました。
今まではシングルトラックで1泊2日の合宿だったのですが、マルチトラックで2泊3日とし、分厚い内容にしようと思っています。
このうち、セッションの企画を提案してくださる希望者には、(もちろん実行委員の審査の上ですが)好きなテーマ・内容で1セッションの運営をお任せすることにしました。(以下のフォームで募集しています。)

forms.gle

なお先ほどご紹介したWGからはそれぞれセッションの提案が義務となっていますので、これらのテーマのセッションは必ず開催されます。

一方、投稿してくださる論文の質の向上を促すため、今回からPC委員会を設置し、厳正な査読を行うこととしました。 採択本数よりもクオリティを重視し、夏合宿に採択されることがこの分野でのステータスにしてもらえるようになったらいいな、と考えています。

おわりに

ということで、MLSEまだ2年目(最初期の活動からは3年目)ですが、これからも色々活動内容をブラッシュアップして、この新しい分野の発展に寄与していきたいと思っています。
ぜひ、これからも奮ってご参加頂けると嬉しいです。

『Practical Developers』読みました

技術評論社様から献本いただきました。ありがとうございます。

Practical Developers ――機械学習時代のソフトウェア開発[ゲームアプリ/インフラ/エッジ編]

Practical Developers ――機械学習時代のソフトウェア開発[ゲームアプリ/インフラ/エッジ編]

献本されたからとか、筆者に個人的にゆかりのある人が多いからとかではなく、純粋に、読んで面白かったです。
僕は(ご存知の通り)機械学習工学研究会(MLSE)なる、機械学習システムをどう構築するかっていう工学を考える研究会にどっぷりかかずらわっているんですけども。
この本のサブタイトルが「機械学習時代のソフトウェア開発はどう変わったのか」になっていて、まさにこの、機械学習工学的な興味に照らしてどんぴしゃな内容だったわけです。

6章を7人が、それぞれの経験を元に色々書いていて、目次見たときはもっと簡素な事例集かと思ったんですけど、各章非常に中身が濃く、そこいらではなかなか得られないような気づきも多く含まれた、非常に良質なプラクティスの塊だなぁという印象を持ちました。
ということで、本当に純粋に、機械学習工学に興味を持つ人、機械学習を使ったソフトウェアの開発に興味を持つ人にオススメしたい本です。

以降はもう少し詳細に語っていこうかなと思います。

全体的な話

面白いと言うか、よくこんな構成にしたなと思ったのは、6章あるうちの3章がクラウドサービス構築に関する話、でもう3章が、よくエッジAIとか言われる、小さいデバイスディープラーニングを走らせる話に関連した内容になってることです。
両方とも機械学習が関わってるとはいえ、興味を持つ人が分断するんじゃないかなと。前半しか読まない人とか後半しか読まない人とか出そうで、本を企画する側としてはどういう気持ちでこうしたんだろうな、などと思ってしまいました。

あと、各章それぞれの執筆者に自分の開発環境がどうなっているか(使っている計算機、モニタ、エディタの種類、etc.)を書かせてるのが地味に面白かったです。
読者にとって役立つ情報かどうかはわからないですが、みんな他人がどういう環境で開発してるかは気になりますよね。

1章 ゲームアプリ『逆転オセロニア』の開発

個人的には非常に読ませる内容でした。改めて思ったんですけど、ゲームって機械学習のアプリケーションとして向いてますよね。
機械学習って確定的な出力結果を期待できなかったり、リコメンドシステムみたいなものだと返ってくる結果が合ってるのか間違ってるのかも定かでなかったり、という意味で、ロジックをバッチリ組むビジネスアプリケーションと相性が悪いところがあるんです。
そういう点で、ゲームというのはプレイヤーの満足度をいかに上げるかっていう感性が全てなので、開発者もそういうモードで接しやすいと言うか。
そのためか、非常に機械学習を使いこなしてるなぁ、という印象を持ちました。
機械学習モジュールに周辺のシステムをすり合わせていくような開発過程など、一般的なアプリケーションの開発でも参考になる点は多いと思います。

2章 Indeedのインフラ構築

こういうのを、最近国内では MLOps と呼ぶようになりました。
機械学習システムの運用をどう円滑に進めて、そのためにどういうインフラを構築しなければいけないか、など。
この方面は、エンジニアの人達はさかんに勉強会を開いたりしてるんですが、残念ながらアカデミックにちゃんと研究してる人が少なくて、国内ではゼロに等しいのです。
海外ではOpMLなんて国際会議も開かれたりしてるんですけどね。

この章を読んで頂ければわかるんですけど、本当に機械学習関連のインフラ周りは奥が深いようで(僕は普段タッチしないので間接的に聞いてる話でしかないですけど)やはり多くのエンジニアが興味を持つのでは。

3章 フィンテックでの大規模データ処理の自動化

こちらも2章に比較的近い話なのかな。フィンテックと書いていて、具体的なサービス名などは明らかになってないようですが。
いやー、こちらも僕は専門外ではあるんですけど、奥が深そう。すごくマニアックなことを色々書いていて、ちょっと感動しました。ファイル名の名前の付け方で日付が後ろのほうがいいとか、非常に細かい話が書いてあります。
このdockerやAirflowに特化した話を、他社の人がどれだけ参考にできるかわかりませんけども、筆者がどうしてこういうことを考えたのかな、という思いを巡らせると、いろいろ得るものは大きそうな気がします。
タスクを冪等に設計する/しないなんて話は、そういうこと考えるんだ、というちょっとした感動が個人的にはありました。

4章 Ideinの深層学習のエッジ推論高速化

はい、私の勤め先です。
執筆者の大川さんは会社で私の隣りに座っている人なので、なので開発環境が書かれているとおりになっているの、ここだけは自分で確かめられました。

これも身内贔屓じゃないんですけども、非常に内容が濃いですよね。
大川さんとか、その他Ideinエンジニアがよく議論していることが本当にそのまま書かれていて、結構太っ腹だな、とか思ってしまいました。
ぜったい他社の人も参考にしてほしいって思うことも書いてるし、依存型モリモリ使ったHaskellの型検査が遅いとか、他社では絶対参考にならんやろ、とか思う情報もふんだんに載ってますけど。 まぁ、大川さんは普段こんな細かいことを意識しながら開発してるんだ、っていうのをぜひとも汲み取ってほしいです。

あと、2章のIndeedのところで「計算資源のコストより開発コストを下げる方を優先」って書いてあったんですけど、このIdeinの章を読めばそういう富豪的な開発はエッジ向けには採用できないということがわかっていただけると思います。どちらが間違いとかではなく、やはり製品・サービスごとにトレードオフがあるということですね。

5章 TVM

ここだけは、うーん、僕はあまり面白いと思えなかったです。森田さんごめんなさい。
というか、ここだけノリが違いません? 他は製品なのにここだけOSSってのもあるかもしれないですけど、他は製品をどう作るのかって話が主眼なのに、ここはTVMそのものの紹介しかしてないと言うか。
どちらかというと、森田さんにはTVMを開発する上でどういう苦労があるかとかをもっと密に語ってほしかったかな……あるいはTVMの中の人じゃなくて、TVMをサービスに組み込んでる AWS SageMaker Neo の中の人に、TVMをどんな工夫を凝らして組み込んでいるかを語ってもらうとか。中の人英語だろうけど。
国際的なチームによるOSS開発ならではの苦労とか、色々あると思うんですけどねえ。
僕自身がTVMに少なからず関わっていて、この章の内容はほぼ既知の内容だったってので面白さを見いだせなかったのかもしれないですけども。

6章 LeapMindでのFPGAとか量子化とか

はい、私の以前の勤め先です。
だからというのもあってか、ここは多分他の人と僕は読み方が違っていると思います。あー徳永さん育児休暇取ってたんだ、とか。 Blueoilのワークフロー書いてましたけど、あれ、それlmnetじゃない? dlkはどうなってるんだろう?とか。 (僕は在籍時、dlk開発のリードとかしていました)

まぁそんななので、フェアに書けることが割と少ないんですけど、ただエッジAI開発であっても学習環境が重要だっていうのは #02 あたりを読んで頂ければわかるのではないですかね。
僕がいた頃からLeapMindには優秀なインフラエンジニアの方がいまして、彼らがみんなの開発を支えていた面が多分にありました。

おわりに

改めてですけど、これは非常におすすめです。開発で機械学習使ってたり、機械学習プロジェクトに関わってたりする人は読んでみるといいのでは。
続編が読みたいかというとそうでもないんですが(この内容で十分おなかいっぱいになれる)、機械学習工学研究会をやってる人間からすると、これを踏み台にしていろいろ研究する人とか出てきてくれないかな、と思ったりします。

微分可能プログラミングの最近の動向

昨日の微分可能プログラミングに関する記事がやたらはてブつくしTwitterもいいねRTされるし、何でかわからずビビリ散らかしているんですが。

それはともかく、その記事も既に修正したんですが、公開後に David Dalrymple 氏と連絡が取れ、彼が色々教えてくれました。
微分可能プログラミングの起源の話については修正した記事を読んでもらうとして、彼は他にも色々教えてくれたので、2, 3ここに(自分の備忘録も兼ねて)残しておこうと思います。

まず、一番最近彼が見た、微分可能プログラミングに関する論文。

概要を斜め読みしただけですが、Plotkin先生の微分可能プログラミング言語を拡張して、いくつかの微分幾何的/圏論的な検討を加えたものみたいです。ヘビーそうだけど面白そう。

更に、最近 Oxford大学に微分可能プログラミングを研究しているグループがあるそうです。そこのスライド。

人の名前をたどるとEdinburgh大から来てる人もいて、なのでPlotkin先生の流れかもしれないです。

他にも、彼が今書いてる論文のドラフトをチラ見せしてくれたりしたんですけど、流石に公開はしません。でも面白そうな論文でした。

天気の子 忘れないうちにネタバレ感想


映画『天気の子』スペシャル予報

恐らくもう沢山の人が観たであろう『天気の子』、今更なネタバレ感想を書きます。
僕は公開初日最初の全国一斉上映で観て、その後感想ブログ書きたいなと思ってたんですけど、その時は他のことに時間取られてて書く暇なかったのでした。
今はもう押し寄せる感動とかも大分落ち着いてしまったので要点しか書けないし、同じことを誰もがもうたくさん書いているだろうし、ということで今更な感じがするのですが、まぁしゃあなし。

以降、『天気の子』『君の名は。』のネタバレがあります。両方のストーリーを知っている人向けです。

続きを読む

『微分可能プログラミング』はどこから来たのか

はじめに(8/3追記)

この記事を一旦書いたあと、重要な追加証言が得られたため、追記修正しています。結論もやや変わっていますが、現時点のほうがより正確です。

本編:ここから

ディープラーニングが現在これだけ流行っている1つの要因は、TensorFlowやPyTorchなどのフレームワークが非常に便利だからです。ニューラルネットワークの設計、訓練、そして分類などの推論がフレームワークを使えばとても簡単に行なえます。

普通に使っている人達は、これらのフレームワークを『ツール』あるいは『ライブラリ』だとみなしていると思います。でも実際のところ、これらはプログラミング言語です。より正確に言えば、すべてのディープラーニングフレームワークディープラーニング計算用DSL(Domain-Specific Language、ドメイン特化言語)と見なせます。このDSLは大抵、Pythonなど他の汎用言語への埋め込み型で定義されています。

これらDSLに共通して言える特徴が微分可能性です。そのDSLで書かれたプログラムは自動で微分できて、その微分の結果に依って内部のパラメータを自動更新できるのです。

あるとき、僕はネット上のどこかで"differentiable programming language"と書いたwebページを見かけました。それがいつだったか、どのサイトだったかははっきり覚えてないのですが、2017年頃だったと記憶してます。

その後、今年チューリング賞も獲ったディープラーニングの父の1人であるYann LeCunがこんな記事Facebookに投稿しました。2018年1月7日のことです。

OK, Deep Learning has outlived its usefulness as a buzz-phrase.
Deep Learning est mort. Vive Differentiable Programming!
(雑な訳:OK、ディープラーニングはバズフレーズになって、便利なものを遺してくれた。
ディープラーニングはお亡くなりになった。微分可能プログラミング万歳!)

そして、この記事が結構バズりました。

この記事が有名になりすぎたのか、ちょいちょい「LeCunが『微分可能プログラミング』を考えついた」と書いた文章を見かけるようになり、結構戸惑いました。しかもその後、かの Gordon Plotkin(プログラム言語理論研究の大家です)が “Some Principles of Differential Programming Languages”というタイトルの基調講演を、POPL’18という、 プログラム言語理論のトップカンファレンスでしていたのを知りました。この講演が2018年1月初旬。なので、LeCunが起源という噂とは矛盾します。

それで、僕はこのフレーズのオリジナルは何なのかを調べ始めました。折しも今年の3月にPlotkin先生が来日していて、そのおかげで重要なヒントを先生からもらうことができました。

イデアの起源

Plotkin先生がこのアイデアを最初に知ったのは2015年のChris Olahのブログ記事だそうです。ニューラルネットと、関数型言語に登場する型システムって実は似てるんじゃない? といった趣旨の記事なんですけど、そこには"differentiable functional programming language"(微分可能関数型プログラミング言語)というフレーズが登場します。

僕自身が調べて、これ以上前に"differentiable programming"の類の言葉を見つけることはできませんでした。 せっかくなので、Chris Olahにも直接メールを出して、このフレーズは誰かを参考にしたのか聞いてみました。その返事がこちら(もちろん、彼女の掲載許可は取っています)。

I'm not aware of any discussion of "differentiable programming" exactly prior to my post, although it's possible there are things I am unaware of.
I do think there were similar ideas floating around. For example, Leon Bottou has a line in this paper drawing analogies between neural nets and list manipulation in LISP.
(雑な訳:私の記事より本当に前に"differentiable programming"の議論をしたものは知りません。私が気づいてない可能性ももちろんあるけど。
似たようなアイデアはいろいろ漂ってたとは思います。Leon Bottouはこの論文で、ニューラルネットLISPのリスト操作が似てる、と言うようなことを書いています。)

ちなみに、Olahの記事にはYann LeCunもコメントしています。なので、彼は少なくともこの記事は読んでいますね。

その後2016年に、Atılım Güneş Baydinによる"Diffferentiable Programming"と題した講演があったようです。BaydinはOlahの記事を参照しつつ、"differentiable programming"というフレーズを何回も使っています。

さらにこの中ではDavid Dalrympleのエッセイも参照していて、ここでも"differentiable programming"という言葉を使っています。やはり、ニューラルネットと関数型プログラムが似ている、という話を書いています。
彼にもぜひアイデアの起源を聞いてみたいと思ってるんですけど、Twitterのアカウントしか見つからなかった……ので、詳細を聞けるかどうかはまだわかりません。
記事を一旦公開した後、Dalrymple氏と連絡が取れました。色々話を聞くことができたんですが、この件については以下のような証言をしてくれました。

I definitely got the idea from Olah's blog. I also have strong reason to believe LeCun read my essay before popularizing the perspective, and I think it was a substantial influence. But I'd bet LeCun also read Olah's blog already so I don't want to take much credit, except for streamlining the phrase by removing the word "functional".
(雑な訳:私はこのアイデアを間違いなくOlahのブログから得ました。また、LeCunがこれを広める前に私のエッセイを読んだ、と思える強い理由があって、なのでそれなりの影響はあったと思います。でもLeCunはOlahのブログも読んでいただろうし、たくさん手柄を主張したりはしたくありません。ただし、”functional"という単語をそのフレーズから抜いたのは私の影響だと思います。)

その証言をブログで公開していいか、と聞いてみたところ、少しの逡巡があって、以下のコメントも含めてくれ、と頼まれました。

I cited Olah's blog in the manuscript I sent to EDGE.org, but the editors removed the citation with the justification that references to outside works are against the editorial policy of EDGE.org (which prioritizes self-containedness over other intellectual virtues like giving credit where credit is due). Removing the citation then made it seem like I was implicitly claiming novelty in the essay and I regret that.
(雑な訳:私は EDGE.org (注:彼のエッセイが載ったメディア)に送った原稿にはOlahのブログへの参照を入れていましたが、外部の文献を参照するのは EDGE.org の編集方針に反する(必要なクレジットを入れるなど知財面をきれいにするより、自己完結していることに重きを置く)という理由で編集者によって削除されました。削除によって私がエッセイで暗に新規性を主張したかのようになってしまい、後悔しています。)

彼が誠実であろうとすることに、僕は敬意を評します。

ちなみに、Baydinは2018年にサーベイ論文も書いていて、この中で、"differentiable progamming"の提唱者としてChris Olah, David Dalrymple, そして Yann LeCun の3人を挙げています。

と言ったあたりなので、 僕の調べた限りだと、Chris Olahがこのアイデアを思いついた一番最初で、David Dalrympleがそのアイデアから『微分可能プログラミング』("differentiable programming")というフレーズを生み出しました。Yann LeCun は起源ではないですが、このアイデアを大きく普及させたのは間違いなく彼の功績です。

謝辞

記事を書くにあたり、こちらの不躾な質問に快く回答下さった Gordon Plotkin先生とChris Olah、そして David Dalrymple に感謝します。

追記

英語版も書いたよ。 bonotake.github.io

追記2

微分可能プログラミングって昔からある自動微分と何が違うん?」って質問を頂いたのですが、というか割と想定質問だったんですけども、「深層学習の文脈で同じようなものに別の名前をつけた」とか「深層学習を一般化したら昔から自動微分と言われるようなものになった」っていうのが一番近しいのかもしれないです。そんで、深層学習向けに自動微分よりも拡張されたものになっています。
恐らくですが、本文中でも紹介したBaydinらのサーベイ論文を読むのが一番わかり易いかも。

追記3

TensorFlowなどのフレームワークが実際back propagationのときにどういう「微分」をしてるか、は↓の「ゼロディー」にめっちゃくちゃ平易に解説してあるので読んでみてください。

『計算機科学から見たディープラーニング』英語版をアップロードしました

前回の記事でもお伝えした、n月刊ラムダノートに寄稿した記事をGoogle翻訳使ってざっくり翻訳して英語版のブログ記事としてアップロードしました。

bonotake.github.io

ということで、僕の適当な英語を苦にしない方なら記事がタダで読めます
日本語がいいという方はやっぱり↓を買ってください(はあと

www.lambdanote.com

記事『計算機科学から見たディープラーニング』とHagiya triple

本日(というかついさっき)刊行された雑誌『n月刊ラムダノート vol.1, No.2』に記事を寄稿しました。ということで宣伝エントリーです。

www.lambdanote.com

この中で、『計算機科学から見たディープラーニングという記事を書かせていただきました。

この記事を書くことになったきっかけは2つありました。
まず、ラムダノート社長の@golden_luckyさんと雑談している間にこういう話題で盛り上がり、勢いで執筆を依頼された、というのが1つ。
そしてそれと同時期に、ちょうどMLSE夏合宿2019での企画を考えなきゃいけなくて、そのネタ帳代わりに書いたという側面もあります。東大の萩谷昌己先生をお招きすることは先に決まっていて、先生のご専門である理論計算機科学の観点でディープラーニングを捉え直すとどうなるか、みたいなのを、私なりに考えて記事の形式にまとめました。

で、初稿ができたタイミングで、萩谷先生と、あと共同で企画をしたPreferred Networksの丸山宏さんとで原稿を共有したところ、丸山さんが「3人で座談会をしよう」というとんでもない提案をされ、『鼎談:新しいプログラミングパラダイムとしての深層学習』として実現しました。いやぁ、お2人のお相手を務めるのが私でいいのか、とも思いつつ、精一杯やらせていただきました。

で、その鼎談の中で、萩谷先生が発表されたのがこのスライド。私の記事を元に、さらに考察を重ねておられます。

www.slideshare.net

私の記事のキーポイントも、この記事の中で極めて抽象的ですが説明されているので、数学的な抽象論が平気な方はこちらを見ていただければ記事読まなくても大丈夫です。
これじゃわからん、という人は記事買ってください(ニガワラ

まぁこのスライドだけだと当日の参加者以外には不親切すぎるかもしれないので、以降、先生のスライドをかいつまんで、簡単な解説を試みようかと思います。 (繰り返しですが、この説明で難しいと思う人は記事買ってください)
まず、これは一般的なホーアの三つ組(Hoare triple)の説明です。 https://image.slidesharecdn.com/mlse2019hagiya-190709072155/95/-4-638.jpg?cb=1562657137

事前条件P・プログラムc・事後条件Qで構成される三つ組に対し、(i, o) なる二つ組が出てきますが、これはテストケースです。
iが入力、oが対応するテストオラクル。iPを満たし、(i, o)はQを満たします。

これは今までのソフトウェアだったんですが、ディープラーニング、あるいはディープラーニングを元にした新たなプログラミングの世界Software 2.0はこの枠組みを拡張します。それがこれ。

https://image.slidesharecdn.com/mlse2019hagiya-190709072155/95/-5-638.jpg?cb=1562657137

私が記事の中で書いたのがこの構図です。(なので Imai triple なんて名前がついている。恥ずかしい……)
{P}c{Q}ではなく{P}[c]{Q}となっているのがミソで、真ん中にある[c]はプログラムではなく、プログラムスキーマ(≒特定の要件を満たすプログラムの集合)です。ディープラーニングでは、ニューラルネットワークアーキテクチャがこれに相当します。
そして更に学習器tが存在していて、tはテストの集合{(i, o)}を与えると、一番良さそうなプログラムcを自動探索して出力します。

これを更に拡張して、{P}[c]{Q}, {(i, o)}, t の3つを定めるメタ戦略mが存在するよね、というのが萩谷先生の考察。

https://image.slidesharecdn.com/mlse2019hagiya-190709072155/95/-6-638.jpg?cb=1562657137

ちゅーことで、このメタ戦略を規定するのが新たな枠組みである Hagiya triple です。

https://image.slidesharecdn.com/mlse2019hagiya-190709072155/95/-7-638.jpg?cb=1562657137

そして現状、このメタ戦略には機械学習エンジニアEの存在も含まれるのでは、という考察。

https://image.slidesharecdn.com/mlse2019hagiya-190709072155/95/-8-638.jpg?cb=1562657137

本来的には、メタ戦略はm(P, Q, {E})と3つのパラメータを持つ関数になるんですが、現状はメタ戦略m(P, Q)とは腕のいいエンジニアの集合{E}を集めることで、この腕のいいエンジニアE達が良さげなネットワークを設計するという、大変属人的でおおよそ科学とは言えないものになっているのでは?というのが萩谷先生の問いかけです。
ディープラーニングを科学にするには、いかにこの{E}を理論的な枠組みで制御可能にしていくべきかが問われます。

いかがでしょう。小難しい話を駆け足で説明したので、どこまで理解していただけたかわかりませんが。
私が書いた記事は、この Imai triple までをかなり平易に説明したつもりのものです。なので詳細はぜひ記事を読んでください(3回目)。

あと誰か、この続きを研究してみませんか?
(お前がやれ? ごもっとも……)

注:bonotakeは、amazon.co.jpを宣伝しリンクすることによってサイトが紹介料を獲得できる手段を提供することを目的に設定されたアフィリエイト宣伝プログラムである、 Amazonアソシエイト・プログラムの参加者です。