デモを試さないと自分の価値関数は磨けない
布留川英一氏：「デモを試す」。デモを試さないと基本評価できないので、「デモを試しましょうよ」ということで。
「GPT-4を超えた」というのがよくあるんですが、GPT-4を超えたと思ってやってみたら、「確かにこのテストだと超えそうだけど、自分のやりたいことはできない」みたいなものがたくさんあるので。「GPTを超えた」ということは、けっこうニュースにはなるんですが、「このベンチマークだけで」みたいなものが多かったりします。
最近では本当にGPT-4を超えたかのような「Claude 3」が出ました。特定のベンチマークでGPT-4を越えているので嘘は言っていませんが、「こう言ったけど、ただしこんな条件があるよ」ということは、実際の論文の見出しとかだとあまり書いていない。
あと、ニュースサイトとかそういうところもあまり書いていないので、実際に試してみて、「できるんだろうな」と思ってやってみたら、「あっ、こんな条件があったのね」とか「こんな縛りがあった」ということを繰り返す感じになります。
デモを試さないと自分の価値関数を磨けないという感じで、「このニュースは自分にとって価値があるどうか」をけっこう予測したりすると思うんですが、「こういう時にはここをチェックしなくちゃ」ということが、デモを試していくとわかるようになります。
最初に実際に試して、自分の予測と実際の動作の差を確認して、その差を補正することで自分の価値関数を磨くということで、ニュース1つを見たとしても、それを正しく自分が認識できるか、ちゃんと認識しているか（という差）を得るために、実際にデモを試すのは重要かと思います。
デモが動かない場合の確認事項
あと、リポジトリからダウンロードして、デモが動かない場合もたくさんあるんですよ。そういう時にどんな感じにやっているのかを紹介します。
最近圧倒的に多いのは、「ChatGPTに聞く」です。なにかエラーが出たら（そのエラーについて）聞くと、けっこううまくやってくれるので、ほとんど「ChatGPTに聞く」で終わることが多くなっています。
あとはやはり「公式ドキュメントをよく読む」ですが、そんなによく書いてあるものがないので、その次に見るのがrequirements.txtです。中のほうに依存関係が激しいライブラリがないかをチェックします。
特にTorch（PyTorch）関係だと、「Colab」とかでやる時にはTorchがぶつかって壊れちゃったりすることもあるので、そのあたりを調整するために、ちゃんとどんなものがインストールされているかを見ます。
あと、最新の技術だと、特にTwitterとかにもあまり載っていません。そういう時はIssueを覗くと、真っ先に試した人たちが「動かない」とかそういうことを書いたりしているので、そういうものを確認します。
そういうものもなかったら、最終的に「ソースコードを読む」です。ChatGPTがわからなかったらソースコードを読んで、それをChatGPTに聞きながら直すことがけっこう多かったりします。
記事を書く3つのメリット
「記事を書く」。自分はけっこう「note」に記事を書いているんですが、どちらかというと自分のためみたいな。
記事を書くのは同じことは二度としたくないからで、1回セットアップしたら2回目は「どうやってセットアップするんだっけ？」（となったり）とか、ドキュメントをまた読むのはつらいので、そのために毎回記事を書くようにしています。
あと、もう1つ言えることはからあげさん（からあげ氏）が書いていたんですが、（記事を書くことで）欲しい情報が集まってくる。自分の興味がある記事を書くと、それに対してさらに追加情報（をくれたり）とか追加調査してくれる人がいて、「さらにこんなことができるよ」とか「こんな条件だとうまくいかない」という記事を書いてくれる。そういうのを見ると、自分が1やるだけで3と4はほかの人がやってくれるので、追加情報としていい情報が集まってきます。
そして3つ目。そうすることによって推しの技術が発展するということです。自分だけでやっているとそんなに大きくありませんが、それによっていろいろな人がいろいろな視点でいろいろな結果を出してくれると、その技術が発展するので、後からやる人がさらにやりやすくなる。このあたりが利点かなと思っています。
あと、普通に要約なので、要約の過程で内容を理解し、自分なりの言葉で再構成することで理解が深まり、記憶にも残りやすくなるというのはよく言われていることです。普通に理解する時には、要約すると頭に入るということがあるかと思います。
技術記事の書き方は「読み方の逆」
この「技術記事の書き方」ですが、だいたい読み方の逆で書きます。トップダウンで書くということで、はじめに何を書くかを書いて、目次を書く。見出し、小見出しを書いて、各小見出しの最初の1文を書いて、最後まで書くみたいな、そんな感じでやっています。最近はあまり時間がないので省いて、だいたい3まで書いたらOKみたいな感じです。
トップダウンで書くと、情報の粒度的に時間がない時には粗く、時間がある時には細かくと都合良くできるので、読む時だけではなく書く時もトップダウンで書くと、それなりにやりやすいかと思います。
初めて情報に触れようとする人たちのためにも本にまとめる
最後に「本にまとめる」。（スライドを示して）自分の書いた本はこのあたりでまとめています。50冊ほどと言いましたが、ちょうど48冊ぐらいでした。
基本、noteとかで書いているのは、バラバラの情報なんです。ふだんから情報を集めている人だと、バラバラのブログでもぜんぜん情報を取れるんですが、今までそういうのをやったことがない人が初めて入った時に、自分のnoteをいきなり読んだら、「Colabの使い方は」とかから始まって、細かいことを言い始めるといろいろ覚えなくちゃいけないことがたくさんあるので。初めて来た人たちがそういうnoteを読めるように、バラバラの情報を1つのシーケンスにまとめる作業みたいな感じになっています。
「noteがあれば本は要らない」という考え方の人もいますが、本にまとめないと初めて情報に触れようとする人たちは、全体像がわからないので。そういう人たちをレベルアップというか、読めるようにするために書くというのが、だいたいの目的になっています。
あと、自分自身の情報と情報の関係を整理して、自分自身で理解しやすくしたり、調べていない情報を見つけて穴埋めするとか。「部分的な技術を調べているだけで、実はあそこはちゃんと調べていなかった」ということがけっこう見つかるので、そういうのは便利です。
あと、実際に書いてみてほかの人からいろいろ意見をもらうと、自分だけだと見落としていた部分もだいぶわかるようになるので、けっこう自分のためになっています。
趣味でやりたいことは目一杯やって、仕事でやるべきものはなるべく短い時間で
本の作成手順ですが、基本は、興味ある技術情報の記事をあらかじめ書いておいて、最後に「仕事にするぞ」となった時に、記事をつないで原稿作成をします。ざっとだと原稿1ヶ月、編集1ヶ月みたいな感じでやっています。
この時に重要だと思っているのは、興味のある技術の記事を書くのは趣味なので何時間でもやっていられるんですが。記事をつないで原稿作成みたいなことをするのはどちらかというと仕事になってしまって、なかなか集中力を続けるのが難しかったりするので。趣味でやりたいことはもう目一杯やって、なるべく仕事でやるべきことを少なくするという感じでやっています。
同じことをやるんだとしても、締め切りが決まっていたりするとだいぶやる気を失ってしまうので、締め切りができる前になるべく記事を書いて、仕事が来た時にはなるべくその時間は少なくというのがポイントとしてやっていることになります。
「アプリケーション開発」です。アプリケーション開発もけっこう会社でやっていることが多いのであまり言えませんが、言えそうなのはこんな感じです。
最近作ったのは、キャラクターと歩く「Vision Pro」というものです。今これにAIを載せて何ができるかをやっていたりはします。左下のは、お肉屋さんで何を食べたいかの注文を取ったり、そのメニューについて解説したりみたいなAIを作っていました。注文を取ると、その厨房の別のAIに「Slack」経由で通信して、そっちから料理を作ってもらうみたいなものを作っていました。
あと、右下は強化学習でロボットでサッカーするという……。1人だけじゃなくて、複数のAIが協力してやるにはどう学習させればいいかみたいなことをやったりしていました。
こういうものを作る時も、できれば興味ある技術の記事を最初に書いておいて、いざ作るぞという時には、その技術でアプリケーションを開発します。なるべく趣味でやりたいことは目一杯やって、仕事でやるべきものはなるべく短い時間でやるという感じで自分はやっています。
ということで、自分からの発表は終わりになります。じゃあ、このへんで。
