説明不能な失敗の常態化

2026年9月27日 日曜日 説明不能な失敗の常態化 最近の「プレジデント・カーティス」という番組のエピソードで、大統領が二度にわたってドアを開けるのに苦労する場面がありました。これらのドアが機能しないのは、障害物が邪魔をしているからです。最初は人、次に約10億ドル相当の金塊です。どちらの場面でも、キャラクターはフラストレーションのあまり「このクソッタラが！」と呟きます。これはドアの合理的なモデルではありません！ドアは説明不能に「クソッタラ」であってはなりません！私はこれらの場面を法外に面白く感じましたが¹、もしかしたら私の愚かな脳みそがクソッタラなのかもしれません。 Jev: クソッタラなドアをさらに作る TypeSafe AIが開発したAIモデルJevが、確率推定値付きの型付き値を返すということで、インターネットは賑わっています。私が理解する限り、Jevの重要な点は以下の通りです。 * 高速で安価である * 迅速に構築できる * 高速である * 安価である 私は、どのテクノロジーが採用されるかを理解するのが得意ではありません。いまだにSlackも理解していません²。しかし、この製品は私にとってさらに混乱を招くものです。これは「FTPアカウントを取得し、curlftpfsでローカルにマウントし、マウントされたファイルシステム上でSVNやCVSを使用する」というようなものではありません。依然として難しい部分を自分でやる必要があります。Jevが機能していることを知るためには、評価（evals）と正解パイプラインを構築する必要があります。評価と正解パイプラインがあれば、独自のソリューションのファインチューニングの大部分はすでに完了しています。 待てよ。 まだ難しい部分を自分でやる必要があるのでしょうか？ おそらく私の問題は、製品が機能することを期待していることです。 これを購入する人は誰も評価を実行していません。彼らは単に不透明な質問をJevに投げかけ、不透明な応答を得ています。好意的に解釈すれば、これにより「AI搭載」というチェックボックスにチェックを入れ、金曜日までにリリースできます。そして、これが下流のロジックを壊した場合、彼らはいつでも肩をすくめて「まあ、AIは間違いを犯すものだ」と言うことができます。 エラーバジェット？障害モード？テストセット？それらはすべて後で処理できます。ユーザーは障害率を発見できます！すでにリリース済みです！ 誤った自信 「ああ」と、私の投稿に応答するストローマンは言います。「Jevが信頼度スコアを提供してくれるという事実を考慮に入れていないな！」 それらをどうするつもりですか？ 信頼度スコアを合理的に扱うためには、その信頼度スコアのキャリブレーション（校正）についての理解と、不確実性のコストのモデルの両方が必要です。 キャリブレーションの側面では、Jevのトップライン広告コピーは、主に様々なベンチマークでのスコアについてのものであり、信頼度スコアのキャリブレーションの良さについては触れていません。分類ツリーを上がるために信頼度スコアを使用する方法についてのクックブックはありますが、それは根本的に信頼度スコアの良さについての話ではありません。 モデリングの側面では、誰もこれについて考えたくありません。それは常に「えーと、しきい値を超える応答はすべて受け入れよう。0.9でいいかな？昼食は何？」となります。彼らのドキュメント自体は、「何もしない」ための0.5のしきい値と、「高リスクなアクションを実行する」ための0.9のしきい値³を設けており、注釈ボックスには「正しいしきい値は、ドメインとユースケースにおけるモデルのパフォーマンスによって異なります」と記載されています。 最良の場合、人々は信頼度スコアをカーゴカルト的に使用します。最悪の場合、人々はAPI呼び出しが失敗した理由としてそれを使用します。モデルは73%しか自信がなかった！それは私のエラーバジェットが27%であることを意味します！ 説明責任 ウェブサイトのボタンが壊れたとき、私は何が起こるべきだったかについてのモデルを持っています。どこかで契約が破られたのです。私のDNSが壊れています。誰かがJavaScript構文エラーを含むスロップを特定のパスに沿ってリリースしました。予期せぬハンドラーがスローされました。HTTPステータス500のエラーデバッグにアクセスできないかもしれませんが、エンドポイントが500エラーになる理由を理解する責任を持つ誰かがいることを期待しています。所有権は明確に定義されています（たとえ不透明であっても）³。 しかし、多くのユーザーにとって、実際の経験はほぼ「このクソッタラが」というだけです。ソフトウェアはすでに気まぐれに感じられます。失敗が増えれば、フラストレーションの度合いが変わるだけです。失敗の原因を具体的な原因にたどる可能性を排除することは、それほど大きな損失ではないようです。時には物事はただクソッタラなのです。 これが説明不能の常態化につながります。 私の恐れは、LLM駆動開発によって物事が加速されたときに、より多くのものが失敗することではありません。それは起こるでしょう。それは起こりました。新しい方法で物事を構築する代償の一部です。 私の恐れは、「時にはただクソッタラ」が、調査の受け入れられる終着点になるということです。これは悲しいことです。なぜなら、LLMで加速された開発は、これらの問題の一部を解決するのに実際に役立つからです。エンジニアリング時間の不足のために書かれていない自動QAワークフローはたくさんあります。Jevの使用を正当化することさえ、あるいは置き換えることさえ、ほとんどの道を進むことができる評価は、数回のプロンプトで実現可能です。 今日のソフトウェアエンジニアリングの悲劇は、ユーザーも開発者も、ドアの後ろに人（body）がいるかどうかを確認するのに興味がないシステムを、意図的にエンジニアリングしていることです。 私たちはただ肩をすくめ、「クソッタラだ」と結論づけるだけです。 ¹ これは、私が同様に面白いと思うことわざを思い出させます：「時にはエレベーターに乗り、時にはシャフトに落ちる」。これもエレベーターの合理的なモデルではありません!! ² ロックインネットワーク効果は私には理解できますが、メッセージを確実に配信しない製品に人々がどのように標準化したのか、いまだに当惑しています。無料版、有料版、エンタープライズ版で、数週間後にようやく表示されるメッセージが失われるのを目にしました。 ³ まあ、「明確に定義されている」というのは楽観的かもしれません。ビル・ゲイツがムービーメーカーのダウンロードに失敗したという有名な話の後、それが誰かの問題であることは誰もが同意しましたが、必ずしも彼らの問題であるとは限りませんでした。理想的には、顧客がビル・ゲイツでなくても、このレベルの説明責任を得られるようにしたいものです。 投稿者 patrickxia 午前8時24分 メールで送信 このブログを共有する Xに共有Facebookに共有Pinterestに共有 コメントなし: コメントを投稿 古い投稿 ホーム購読: コメントを投稿 (Atom)