LLMの生成先としてのMFGの課題と可能性（その1）
先日、社内でLLMにフィルタを生成させてみた人がいた。 詳細は以下のブログを参照。
これに対するMFGという言語作者の視点や受け入れる側の話などを書いてみたい。 以下のpodcastと被る内容でもある。
はじめに
自分はLLMのコード生成にはあまり関心が無く、どちらかといえば近づいかないようにしている。 というのは、今の仕事では特に関係が無く、この仕事はそれなりに続くものなので、この仕事が終わるまでは追っかけても仕方がないな、と思っていたから。
今の仕事が終わって、ある程度色々進んだ後にこの辺の話題は見てみようかな、というくらいの気持ちでいた。
だからこの界隈でどういう議論が行われているかも知らないし、多分自分が考えているような話はすでにされていて、もっと先の話も色々とされているとは思う。
だが一方で、今回の話は自分の作った言語であるMFGに特有の話も含むので、自分たちだけが向き合っている課題もあるように思う。 そして自分はMFGの作者なので、ある側面についてはこの問題について世界一詳しいはずだ。
だから自分の考えには独自のものも含まれるんじゃないか、という気もしているし、少なくとも解決しなくてはいけない課題に独自のものはあるようにも思う。 という事で少しこの問題について、自分がどう感じ考えているかを色々書いてみたい。
上記のブログは、率直に言って使い物になりそうで驚いた。だがそのままではその結果を活かせない、とも思っている。
今回書く記事の要旨としては、大きくは以下のようになる。
- 受け入れをどうしたらいいか分からない（課題）
- けれど高い可能性は感じる
- LLMに向いた問題設定としてのMFGという視点の面白さ
受け入れの課題
LLMのやってみました系に共通する話でもあるが、 「ほら、こんなの出来た、凄いでしょ？」の後をどうするかが難しい。 この話題は作る側は大体一緒だけど受け入れる側は状況によってかなり異なる。 話がぼやけてしまわないように今回のケースに絞って話をしたい。
受け入れを頼む側の意識
当初これをやった人は「こんなの出来ましたが、これは正しいコードになっていますか？」と社内チャットに投稿してきた。 作った側にとっては、そう聞いてくるのはとても自然な事に思える。以下は勝手に推測するが、こんな風に思うんじゃないか。
- 最初は全然だめだったが、やり取りを繰り返したらなんかいけそうになってきた
- 動きを見ると動いてそうなコードまでやってきた！これできたんじゃない？
- でも生成したコードや数学は全然わかってない、ただそれは分かっている人があとは確認すれば出来たと言えるんじゃないか、凄い！
生成している側の視点に立つとこの流れは凄く良く理解できる。 そして作る側の思う「自分は中を理解出来ないがこの人なら理解できるはずで、その人が確認してくれればそれで完成になるだろう」という予想は完全に正しい。
ただこれは、頼む側が思っている以上に反発を招く事でもある。 例えるなら、「冬の深夜にアップルストアに徹夜で並べば新型のiPhoneを買ってこれるはずだから買ってきて！」と頼むのに似ている。 やれば出来るのはお互い分かるが、そんなのやりたくないよ、という内容になっている。
しかもこのLLMの生成したコードは、頼む側は何を頼んでいるのか良く分かっていない一方で頼まれた側は瞬時に凄く深く問題を理解してしまう、という非対称性がある。
受け入れる側がやらなくてはいけない事
このコードをレビューするのはなかなか大変である。
まず、以下の事をやらないといけない。
- まずKuwahara Filterの数学的な定義を理解する必要がある
- 昔CGの教科書で勉強した事はあっても、すぐには思い出せない
- 大体こういうのは順番に複雑になっていく記述になっているので、リニアフィルタから復習しないといけない
- 数学的記述をプログラムに落とすにはどうしたらいいかをある程度考えないといけない
- LLMの生成したコードを読まないといけない
1と2は、CGのプログラムをする時に必要な事の結構な割合を占めてしまう。 CGのプログラムは数学的なものをコードに落としたものになる事が多いので、 普通のコードを理解するよりも、より数学的な理解を要求されて、結構大変である。 コードが短いけれど数学的濃度が濃い、と言おうか。
結果として、通常のプログラムよりも、書いたり読んだりするよりも、その周辺の数学的な文脈を心の中に配置する方がずっと大変になる。 実際に書く手前までいかないと、書かれているものはなかなか理解できない。
さらに、LLMのコードは人間に読むのが辛いコードになっている事がある。 通常の自分で書いたコードを読むよりもだいぶ大変になる事がある。 ただでさえ読むのが大変な分野で、人が書いたよりもさらに大変なコードが来る、これはきつい。
この辺の辛さは頼む側は正しく把握するのが難しく、かなり過小評価して頼んでしまう。 というよりも、この把握が難しければ難しいほど、LLMを使ってコード生成をさせる意義が高いとすら言える。 自分に分からないものほど、生成してもらう意義は高い。 だからこの非対称性は本質的なものに思う。
受け入れる側の意識
さらにこれが「無理！」って思うのは、このタスクが他人から降ってくる所にもある。
例えば、自分が「今日はKuwahara Filterを実装しよう」と思っていたとする。 そして教科書とかを読み直して、さぁ、実装するぞ、という所でこのコードがやってきたら、読むのは大して大変でも無い。 作るよりは楽だろう。
だが、それには心の準備が必要で、心以外にも準備が必要になる。 いくつか作る候補がある中で「次はこれをやってみたい」という気持ちがあって、 だからこそ学ぶ意欲も湧く。
一方で、これが降ってくる場合は、自分はそれに対する関心がそこまで高まっていないものが降ってくる。 これを理解するのはさらに心理的に高いコストが高まる。
今日やる予定でなかった仕事が突然降ってくる、みたいな状況を、数倍酷くしたような何かになってしまう。
さらに受け入れる側はLLMでコードを生成してみよう、と思っていない場合が多く、そして生成している側はLLMでコードを生成してみよう、と思っている場合が多い（だからやっているのだろうし）。 この両者が一致していないと、同じ困難でも乗り越える意欲にはだいぶ差がある。 けれどより高い意欲が必要な側により低いモチベーションしか無い、という困った状態になってしまう。
押し付ける側がタスクの大変さを過小評価してしかも押し付けてしまう、というのは、かなり良く発生する事柄なので、頼む側もある程度この問題は意識していた方が拒否反応を減らしてスムーズに行きやすいのではなかろうか。
受け入れ側をどうにか出来ないか？
受け入れる側のコストが見た目よりずっと高いので、普通にやると、作るのと大して変わらない大変さになってしまう。 そしてその事はプログラマ以外の人には伝わりにくい。
分かる人が読んで理解する、という路線は、非プログラマが思うよりもずっと無理がある路線に思う。
一方で「だからLLMはデモでしか使えなくて実際的には役に立たない事を素人どもは全然分かってない！」とか言って終わりにしてしまう態度もありえるとは思うが、 それにしては生成されるフィルタに可能性を感じて勿体無い。
特にMFGは、フィルタのユーザーは絵を描く人であってプログラマでは無い。 そして「こんなフィルタが欲しい」という事をプログラマよりも絵を描く人の方が深く理解しているので、 プログラマでない人が生成出来るというのは大きな可能性を感じる。
そういう訳で、受け入れ側の体制をLLMの時代に合わせたものにする事でこの可能性を活かせないものか、と思うのだが…これがさっぱり分からない。
以下受け入れ体制について考えてみる。
ちょっと長くなってきたので別のポストに続く。