私は未来が嫌いだ：理由もなく失敗することが常態化する

『President Curtis』の最近のエピソードで、大統領は2回、ドアに阻まれた。

ドアが開かなかったのは、何かが邪魔をしていたからだ。最初は人、次はおよそ10億ドル相当の金塊だった。

どちらの場面でも、彼は堪えきれずに「stupid thing sucks」と吐き捨てる。ドアにそんな期待をするのは筋が通らない！　ドアがわけもなく「sucks」であっていいはずがない！　この2箇所で私は大笑いした¹。ただ、私の頭がひどく出来が悪いだけかもしれない。

Jev：ろくでもないドアをもっと作る

最近ネットで話題なのが Jev だ。TypeSafe AI が開発した AI モデルで、確率推定付きの型付き数値を返す。私が把握している限り、Jev の要点はこうだ。

速い、安い、
すぐ上に何かを作れる、
速い、
安い。

どの技術が普及するかについて、私はこれまでろくな見立てを持ったことがない。

今に至るまで²、Slack が理解できない。

だが、この製品は私をさらに混乱させる。「FTP アカウントを取って curlftpfs でローカルにマウントし、そのマウントしたファイルシステム上で SVN か CVS を走らせる」という類のものではない。難しい部分は依然として自分でやる必要がある。Jev がまともに動いているかを知るには、eval と ground-truth の仕組みを組まなければならない。そして eval と ground-truth の仕組みをすでに持っているなら、自分でファインチューニングしたソリューションを作るまであと数歩だ。

待てよ。

難しい部分は、本当に自分でやるしかないのか？

おそらく私の問題は、製品がまともに動くことをいつも当てにしてしまうことにある。

これを買う人間は誰も eval を走らせたりしない。彼らは言葉にできない問題を Jev に投げ、言葉にできない答えを受け取るだけだ。最良の場合、それで「AI 駆動」の欄にチェックを入れ、金曜日までにリリースできる。下流のロジックが壊れたときは、こう言って肩をすくめればいい。「AI だから、間違うこともあるさ」。

エラーバジェット？　故障モード？　テストセット？　それは後回しだ。失敗率はユーザーに自分で見つけてもらえばいい！　とにかくもうリリースしたんだから！

偽りの自信

「おや」と、私の投稿に返信してきた藁人形が言う。「Jev が信頼度スコアを返すことを考慮に入れていないね！」

それをどう使うつもりだ？

信頼度スコアを使ってまともな意思決定をするには、スコアの較正がどうなっているかを理解し、不確実性のコストに対するモデルも必要だ。

較正の側。Jev のトップページの広告コピーは主に、各種ベンチマークでどれだけ高得点を取ったかを語っていて、信頼度スコアがどれだけうまく較正されているかではない。信頼度スコアを使って分類木を上に登る方法を説明した cookbookはあるが、それは本質的に、信頼度スコアが正確かどうかとは関係がない。

モデリングの側。誰も考えたがらない。結局は「えー、閾値を超えたら受け入れよう。0.9 でいい感じ？　昼飯どうする？」になる。彼らのドキュメント自体が、0.5 の閾値を「何もしない」、0.9 の閾値を「高リスク操作の実行」としてでっち上げている [アーカイブ]。その横には「正しい閾値はあなたの領域と、そのユースケースにおけるモデルの性能に依存する」と書いた情報ボックスが添えられている。

良くて cargo cult 的に信頼度スコアを使う。悪ければ、API 呼び出しが失敗したときの言い訳に使う。モデルの信頼度は 73% しかなかった！　なら私のエラーバジェットは 27% だ！

説明責任

ウェブサイトのボタンが壊れたとき、私の頭の中には、本来どうなるべきかについてのモデルがある。どこかで契約が破られている。私の DNS が壊れている。誰かがゴミコードをリリースし、特定のパスでしか通らない JavaScript の構文エラーが混ざっている。投げるべきでない例外を handler が投げている。HTTP 500 を前にしても、私にはデバッグする権限がないかもしれない。それでも、このエンドポイントがなぜ 500 を返すのかを突き止めるのが仕事である誰かの存在を、私は前提にしている。責任の所在は、不透明であれ³、明確だ。

だが多くのユーザーにとって、実際の体験はおおよそ「このクソは本当にクソだ」というものだ。ソフトウェアはもともと気まぐれに見える。失敗が増えても、いらだちの頻度が変わるだけだ。「一度の失敗から具体的な原因までたどる」可能性を奪っても、失うものはほとんどないように思える。ときには物事はただクソなのだ。

こうして「説明不能」が当たり前になっていく。

私が心配しているのは、LLM 駆動の開発があらゆるものを加速した結果、壊れるものが増えることではない。壊れるだろう。すでに壊れている。新しいやり方で物を作るためのコストの一つだ。

私が心配しているのは、「ときにはただクソなだけ」が、調査の公認された終着点になりつつあることだ。これは悲しい。LLM で加速した開発は、その一部を 実際に 解決する助けになりうるからだ。自動化された QA プロセスのうち、書かれなかったのはエンジニアリングの時間が足りなかったからにすぎないものが山ほどある。Jev を置き換えるところまで、あるいは Jev を使う正当な理由を提供するところまで、ほぼ連れて行ってくれる eval は、あと数個の prompt で済むかもしれない。

今日のソフトウェアエンジニアリングの悲劇は、ユーザーも作り手も、ドアの向こうに死体があるかどうかを確かめる気が どちらにも なさそうなシステムを、私たちが自ら進んで構築していることだ。

私たちはただ肩をすくめ、こう結論する。バカなものはクソだ、と。

¹これは、同じくらい面白いと思う言い回しを思い出させる。「エレベーターに乗ることもあれば、エレベーターにやられることもある」。これもまた、筋の通ったエレベーターのモデルではない！！

²ネットワーク効果が強力なのはわかる。それでも、メッセージすら確実に届かない製品に人々が標準化する理由が、私にはまだ理解できない。無料・有料・企業インスタンスのいずれでも、メッセージが捨てられ、数週間後にようやく現れるのを目にしてきた。

³まあ、「明確に定義されている」と言うのは楽観的すぎたかもしれない。Bill Gates が Movie Maker のダウンロードに失敗したことで有名になったあの件以来、これはおそらく誰かの問題であって、必ずしも自分の問題とは限らない、という点では全員の意見が一致している。理想的には、顧客が Bill Gates でない場合でも、このレベルの説明責任に到達したいものだ。

Posted by

patrickxia