生のLLMはなぜ信頼できないか：ハーネスが車でモデルはエンジンという真理

裸の人は馬鹿になると想像してみて。実は、裸のモデルは本当にそうなる。念のため言うと、そういう意味での裸モデルではない。でも今感じているその失望感？それがKyle KingsburyがLLMに対して感じていることとまさに同じだ。 Kyle Kingsburyは現存する最高のシステムエンジニアの一人だ。彼のJepsenプロジェクトは、分散データベースが謳い文句通りに機能しないことを10年かけて系統的に証明した。CockroachDB、MongoDB、Redis、その他数十のDBが守れない一貫性保証を約束していた。彼が結果を発表し、ベンダーはバグを修正し、業界全体がより誠実になった。Jepsenは応用的懐疑主義の傑作だ。先週、彼は「The Future of Everything is Lies, I Guess: Bullshit About Bullshit Machines（全ての未来は嘘だ、たぶん：でたらめマシンについてのでたらめ）」という32ページのエッセイを発表した。美しく書かれ、深く研究され、本当に面白く、そして最も重要なことについて間違っている。彼の観察は正しい。彼の結論は正しくない。スコープについての注記：このエッセイはKingsburyの技術的主張——LLMは信頼できる出力を生み出せない信頼できないでたらめマシンだ——に対処する。労働移転、情報生態系、文化的影響についての彼のより広い懸念は本物で、別個のエッセイに値する別の問いだ。ここで扱わないことでそれらを否定しているのではない。アーキテクチャの問いに対処している：モデルの信頼性の欠如は有用なシステムを不可能にするのか、それともエンジニアリングの問題にするのか？私は後者だと思う。Kingsburyのエッセイは前者を前提としている。そこが我々の意見の相違だ。 ## ベンチでエンジンをテストする Kingsburyのエッセイは、LLM失敗の目録として構成されている。彼はGeminiに3Dバスルームレンダリングにマテリアルを適用させようとした。トイレを忘れ、部屋の形を変えた。Claudeに画像→画像変換をさせようとした。意味不明なポリゴンのガラクタを生成する何千行ものJavaScriptを出力した。ChatGPTに青いシャツに白いパッチを付けさせようとした。色を変え、パッチを動かし、削除した。同僚のLLMが株価データをダウンロードしてランダムに生成された数値のグラフを作るのを見た。これらの失敗はすべて本物だ。私も同様の失敗を見た。LLMで構築している全員が見た。Kingsburyは何も作り話をしていない。しかし各例で起きていることはこうだ：人間が生のLLMの前に座り、自然言語でリクエストを入力し、失敗するのを見ている。モデルにタスクへのアプローチ方法を教えるスキルファイルなし。精度が必要な部分を扱う決定論的ツールなし。リクエストを適切な能力にルーティングするリゾルバなし。コンテキストを管理し、安全性を強制し、行動を制約するハーネスなし。彼はベンチでエンジンをテストして、自動車は安全でないと結論付けている。 ## アーキテクチャの問いこのシリーズの最初のエッセイを読んでいない読者のための用語説明。スキルファイルはモデルにタスクへのアプローチ方法を教える再利用可能なMarkdownドキュメントだ——プロンプトではなく手順だ。リゾルバはモデルにどのタスクにどのドキュメントを読むかを伝えるルーティングテーブルだ。決定論的コードは毎回同じ出力を生み出すソフトウェアだ——SQLクエリ、APIコール、数学——モデルが絶対に触れるべきでない部分だ。ハーネスはモデルをループで実行し、ファイルを読み込み、コンテキストを管理する薄いコンダクターだ。合わせると：薄いハーネス、太いスキル。 Kingsburyの中心的主張は、LLMは「でたらめマシン」だということだ。confabulate（作話）し、カオスで、操作に脆弱で、信頼できない。モデルを孤立した状態でテストすることでこれに辿り着く。関数をテストするように：入力→出力→評価。 Kingsburyの問題を抱えているのは、まさにこれをやっている人たちだ：生のモデルとチャットして信頼できる出力を期待する人たち。その問題を抱えていない人たちはハーネスを構築した。ハーネスがモデルを信頼できるものにするからではない。ハーネスが、中のモデルが信頼できなくても、システムを信頼できるものにするからだ。 Kingsburyはハーネスが存在することを知っている。Claude Codeのソースリークを引用している：Anthropicが自社モデルの周りに構築した512,000行のエンジニアリング。世界最高のLLMのメーカーでさえ、生のモデルを信頼しない。ライブリポコンテキスト、プロンプトキャッシング、専用ツール、セッションメモリ、並列サブエージェントでラップした。これはモデルの信頼性がエンジニアリングの問題であり、哲学的な問題ではないことを示す512,000行の証拠だ。 ## 株価データの例株価データの例が最も明確な例だ。LLMが株価をダウンロードしてグラフを生成すると主張したが、データはランダムだった。KingsburyはこれをLLMが嘘をつく証拠として提示する。しかし実際に起きたことは？誰かが言語モデル（テキスト予測マシン）にインターネットからデータをフェッチするよう頼んだ。インターネットからデータをフェッチできない。ツールがない。HTTPクライアントがない。APIキーがない。だから言語モデルがすること——株価データ応答のように見えるテキストを生成した——をやった。修正はより良いモデルではない。修正は決定論的ツールだ：実際に株価APIを呼び出し、本物の数値を返し、それをコンテキストとしてモデルに渡す関数。モデルはデータ取得に触れない。何を調べるかを決める。コードがどうやるかを決める。同じ入力、同じ出力、毎回。 ## バスルームの問題 Kingsburyのバスルームの例を取ろう。彼はGemini（言語モデル）に3Dレンダリングにマテリアルを適用させようとした。GeminiはImageエディタではない。3Dモデリングツールではない。後付けの機能として画像能力を与えられたテキスト予測システムだ。もちろんトイレを忘れた。もちろん部屋の形を変えた。適切にハーネスされたシステムは異なる扱いをする。スキルファイルはこう言うだろう：タスクをステップに分解しろ。 - ステップ1：画像のすべての表面を特定する（ビジョンモデルを使用） - ステップ2：各表面に適切なマテリアルを選択する（モデルが決定） - ステップ3：決定論的な画像処理ツールを使用してマテリアルを適用する（コード——Pillow、OpenCV、Blenderスクリプト） - ステップ4：出力ジオメトリが入力ジオメトリと一致するか確認する（決定論的比較）モデルが判断をする。コードが実行をする。リゾルバがその間をルーティングする。ハーネスがシーケンスをオーケストレートする。 Kingsburyの失敗はデバッグできない、なぜならデバッグするシステムがないからだ。モデルがインプロビゼーションをしているだけだ。 ## ジャギーは壊れていることを意味しない Kingsburyの最も優れた観察の一つは「ジャギーな技術フロンティア」だ——LLMが不規則で予測不可能な能力の境界を持つという考え。多変数微積分をやって、簡単な文章問題で失敗する。エッセイを書いて、文字を数えられない。これは正しくて重要だ。しかしKingsburyは間違った結論を引き出す。ジャギーなフロンティアは信頼性を必要とするタスクにLLMが不適切だということだと主張する。実際に意味するのは、ルーティングが必要だということだ。リゾルバはコンテキストのルーティングテーブルだ。タスクタイプXが現れたら、スキルYをロードしろ。タスクが文字数えを必要とする場合、コードにルーティングしろ。3行のPython関数。タスクがエッセイ執筆を必要とする場合、モデルにルーティングしろ。ジャギーなフロンティアはAIに反対するのではなく、ハーネスエンジニアリングのための論拠だ。 ## カオスは制約のための論拠 Kingsburyは、LLMはカオスなシステムだと主張する。小さな入力の摂動に敏感で、adversarial操作に脆弱で、行動が予測不可能だ。正しい。質問の言い換えが答えを変える。文の並び替えが出力を変える。見えないUnicode文字が行動を乗っ取れる。しかし、スキルファイルを通じて入力を制約していれば、そうである必要はない。スキルファイルは手順を定義する構造化されたMarkdownドキュメントだ。モデルに何を読むか、何を考慮するか、どのフォーマットで出力するか、どの制約を守るかを伝える。スキルファイルを通じた構造化入力は、自由形式の自然言語よりも劇的にカオスが少ない。スキルが軌跡を制約する。土手が川を導くように、カオスを導く。 ## 推論の誤解 Kingsburyは「推論」モデルについて巧妙な点を指摘する。Chain-of-thoughtトレースは「本質的にLLMが自分自身についてファンフィクを書いている」と指摘する。Anthropicの発見——Claudeのchain-of-thoughtトレースは実際の推論プロセスを確実に反映しない——を引用する。これは正しいが無関係だ。Chain-of-thoughtトレースはスクラッチパッドであり、成果物ではない。重要なのは出力だ。システム（モデル＋ハーネス＋ツール）は正確で検証可能な結果を生み出すか？それが検証可能な問いだ。 ## アスピリンがなぜ効くかも分からないエッセイの終わり近くで、Kingsburyは「トランスフォーマーモデルがなぜこれほど成功したのか、どう改善するかを本当に知らない」と観察する。これは正しい。アスピリン（作用機序は1970年代まで完全には理解されていなかった）、全身麻酔（まだ完全には理解されていない）、自転車の安定性（2011年にようやく明確に説明された）についても同様だ。実用的な有用性は理論的な完全性を必要としない。1971年の機序論文を待ちながらアスピリンの処方を止めなかった。 ## Jepsenが実際に見つけるもの皮肉がある。KingsburyのJepsenの方法論は、AIシステムに対してまさに正しいアプローチだ。ただし、間違ったレイヤーに適用されているだけだ。 AIシステムに同じ方法論を適用すれば、ターゲットは明らかだ。モデルがhallucinateするかどうかをテストするな！もちろんする。システムがhallucinateするかどうかをテストしろ： - ハーネスはhallucinateされたデータがユーザーに届くのを防ぐか？ - スキルファイルは精度が重要な場所でタスクを決定論的コードにルーティングするか？ - リゾルバは正しい入力に対して発火するか？これらは検証可能な主張だ。決定論的コードのユニットテスト。パイプライン正確性の統合テスト。ルーティング精度のリゾルバトリガー評価。出力品質のLLM-as-judge評価。フルパイプラインのエンドツーエンドテスト。彼は生のモデルをテストした。データベースの代わりに素のファイルシステムに対してJepsenを実行するようなものだ。 ## 真実の美学 Kingsburyの最も深い論拠に対処しよう。LLMは真実を生み出さない。真実のように見えるテキストを生み出す。認識論的根拠のない、真実を語ることの美学。哲学的な意味で、Harry Frankfurtが定義したような、でたらめマシン：出力の真実値に無関心なシステム。これは正しい。そしてまさにアーキテクチャが重要な理由だ。生のモデルはもっともらしいテキストを生み出す。ハーネスされたシステムは検証されたテキストを生み出す。 - スキルファイルは「ソースデータに対して作業を確認しろ」と言う。 - 決定論的コードは「この出力をground truthと比較し、乖離した場合は拒否しろ」と言う。 - モデルがドラフトを生み出す。 - システムが検証された結果を生み出す。もっともらしいと検証済みの間のギャップは、まさにハーネスエンジニアリングが埋めるギャップだ。しかしKingsburyが完全に見逃している部分がある：検証の品質はスキルファイルの品質に依存する。そしてスキルファイルは人間が書く。これがオープンソースがこれほど重要な理由だ。 ## 車を作れエッセイの終わりで、Kingsburyは車に例えてAIを考える。車が都市に何をしたかを考えるよう読者に求める：スプロール、鉛中毒、コミュニティの取り壊し、車依存。良い例えだ。しかし彼はそこから全く間違った教訓を引き出す。我々は自動車の問題をエンジンを疑うことで解決しなかった。エンジニアリングで解決した：シートベルト、クランプルゾーン、触媒コンバーター、信号機、高速道路設計、燃料噴射、ABS、エアバッグ、排ガス規制。エンジンへの懐疑論は一命も救わなかった。シャーシのエンジニアリングが救った。それがKingsburyのエッセイへの答えだ： - システムを構築しろ。 - スキルを書け。 - コードをテストしろ。 - リゾルバでルーティングしろ。 - 決定論的部分を決定論的にしろ。 - 潜在（モデル）部分を制約付きにしろ。 - モデルではなく、システムをテストしろ。 Kingsburyは生のモデルが信頼できないことで正しい。彼が間違っているのは、これらの特性を制約ではなく評決として扱うところだ。モデルはエンジンだ。ハーネスが車だ。車を作れ。

生のLLMはなぜ信頼できないか：ハーネスが車でモデルはエンジンという真理

AIFCC — AI Fluent CxO Club