抽象化のもれる穴が小さくなる
AIにプログラミングをさせることに関する議論が盛り上がっている2025年
抽象度の高い高級言語的な表現によって具体的で低級言語的な表現が生成されるシステムは今回が初めてではない
- コンパイラがC言語の記述から機械語の記述を生成する
- LLMが自然言語の記述からプログラミング言語の記述を生成する
- A:
- 最初は「生成できた、しかし役に立たない」の状態からはじまる
- B:
- その次に「生成したそのままでは役に立たない」「しかし手直しすれば使える」
- 手直しコストがゼロからの作成コストより安くなれば経済的合理性が生まれる
- ここまでは低級言語の知識が必要である
- C:
- 「生成したそのままでは役に立つ」がくるかどうかに意見が分かれている
- リーキーアブストラクションの法則
- 「抽象化には漏れがあるから完全に低レイヤーの知識が不要になることはない」という主張
- 2025年現在「Cが実現される」という意見に反対の立場のソフトウェアエンジニアはこれを根拠にすることが多い
- 一方で、2025年現在C言語のコンパイラが生成する機械語の品質に満足できてない人はどの程度いるのか？
- ゼロでないのはわかっている、同僚の光成さんがXbyakを使って世界最速の暗号ライブラリを作ったりしているので
- 世界最速のものを作りたいケースでは必要だろう
- いまソフトウェアエンジニアを名乗ってる人の一体何パーセントが世界最速の実装を作る仕事をしてるの？
この議論が平行線なのはバイアスとバリアンスのバイアスにのみ注目しているところにある
- 横方向のずれがバイアス、分布の広がりがバリアンス
- バリアンスが大きいAと小さいBでは期待している出力のレンジRに入る確率が違う
- 技術の進歩によってバリアンスが小さくなっていって、レンジRに入る確率が高まっていく
- どんなに高まってもはみ出すEの確率がゼロにはならない
- 十分高まってくると適切に期待出力範囲の出力が出るような高級言語的表現をすることの重要さが相対的に高まっていく
- 「コンパイラが間違う確率」より「人間がC言語の記述にバグを入れる確率」の方が高くなる
- 「コンパイラが間違ってることを疑ってコンパイラの出力した機械語をチェックすること」と「人間が間違ってることを疑ってC言語の記述をチェックすること」の期待リターンが後者の方が高くなる
- 「LLMが間違ってることを疑ってLLMの出力したソースコードをチェックすること」と「人間が間違ってることを疑ってLLMに与えた自然言語の記述をチェックすること」だと2025年3月現在はまだ前者の方がリターンが大きそう
- しかしclinerulesやDevinのknowledgeの仕組みによって高速に「自然言語の記述」の改善やライブラリ化が進んでいるので分水嶺は今年中だと思う
- 活動全体として見ると、そもそも「期待出力範囲」の設定の正しさの重要性が高まると思う
- 誰も使わないものを作っても無益ということ
- 世の中のユーザのニーズを理解して適切な「期待出力範囲」を設定する力が、価値を創造するプロセス全体の中で占める割合が高くなっていく
- ボトルネックは解消すると別の場所に移動する
関連