あなたは、LLM搭載のエージェントに、ぐらつく（フレークな）テストを直すよう依頼します。エージェントはスタックトレースを読み取り、データベース呼び出しの直後に失敗が起きていることに気づき、リトライでパッチを当てます。しかしテストはまだ失敗します。モデルは相関 — データベース呼び出しの近くで失敗する — を見たものの、その呼び出しが原因であるかどうかは確認していません。この見落としには、正確な名前があります。確率的・因果的推論を形式化することで2011年のチューリング賞を受賞したジュデア・パールなら、エージェントは因果の階段（Ladder of Causation）の一番下の段から決して降りていない、と言うでしょう。
これは、プロンプトエンジニアリングの問題ではありません。修正でどうにかできる類のものではないのです。データ駆動型システムが計算できること、できないことについての主張であり、LLMツールで見かける不具合の多くを説明してくれます。
因果の階段の3つの段
パールの因果階層 — 彼の2018年の著書『The Book of Why』で一般向けに整理されたもの — は、あなたが尋ねることのできるあらゆる問いを3つの段に分類し、各段には、その下の段からは供給できない情報が必要になります。
第1段は関連（アソシエーション）です。 「Xを見たとき、Yについて何が分かるのか？」を問います。形式的に書くと、条件付き確率P(Y | X)です。相関、パターン認識、曲線当てはめ、通常の教師あり学習、そして次トークン予測はすべてここに属します。例：請求（ビリング）ページを開くユーザーは、解約率がより高い。
第2段は介入です。 「私がXを行うとしたら、Yには何が起きるのか？」パールはこれに独自の表記を与えます。P(Y | do(X)) — do-operator（do演算子） — です。行為は観察と同じではないからです。例：請求ページを再設計したら、解約は下がる？第1段の相関では分かりません。請求ページを訪れることと解約の両方が、混乱したユーザーによって起きているだけかもしれませんし、ページ自体は何も変えていないのかもしれません。
第3段は反実仮想です。 「この特定のユーザーは、壊れたページを踏まなかったなら解約しただろうか — そのユーザーは実際にはページを踏み、そして解約したのだが？」これは、すでに起きた出来事に対する「別の可能性（代替案）」について考える推論です。あなたが「そのバグはテストがあればリリースされなかったはずだ」と言うたびに行っているのがこれです。
段には順序があります。その理由があります。因果階層定理（Causal Hierarchy Theorem）— パールの研究を土台にし、Elias Bareinboimらが形式化した — により、その分離は厳密になります。一般に、下の段からのデータでは、上の段の問いには答えられません。第1段の観察だけで、第2段の問いが解決されることはありません。
なぜデータを増やしても階段は登れないのか
開発者が見落としがちなポイントは、これはサンプル数の限界ではなく、構造的な限界だということです。行数を増やしても役には立ちません。
直感としてはこうです。まったく異なる2つの因果世界が、まったく同じ観測分布を生み出すことがあります。パールの定番の例：オンドリは毎朝、日の出の前に鳴く。データ — 毎日、何年もの間ずっと「鳴く→太陽が昇る」 — は、「オンドリが日の出を引き起こす」ことにも「日の出がオンドリの鳴き声を引き起こす」ことにも、同じくらい整合的です。正しい方を選ぶには、データからは得られない仮定が必要です。つまり、世界が実際にどう配線（つながり）されているかについての知識です。それを取り除くと、データセットは黙り込むのです。大きくなっても関係ありません。
これが、あなたのスタックにとって重要な部分です。検索拡張生成（RAG）は、より多くの第1段の証拠を追加します。事実が欠けていて起きる幻覚を本当に減らせることはあります。モデルが、負荷時にあなたのAPIが429を返すことを見たことがないなら、それを文脈に入れることで直せます。ただし、検索ができないことは、モデルにdo-operator（介入）を渡すことです。会社がこれまで書いたあらゆるインシデント事後分析（postmortem）をインデックス化しても、リトライ方針を変えたらどうなるかは、テキストのどこかにすでにその因果構造が書かれていない限り、モデルは計算できません。
検索を推論の穴を埋めるための解決策として扱うのは、よくあるものの、コストがかかって危険な間違いです。RAGは、根拠付け（grounding）を改善します — モデルが知っていることを増やすのです。モデルがどの段で動いているかは変わりません。失敗のモードが「モデルが自信満々に因果関係を断言してしまう」ことであるなら、コンテキストウィンドウにドキュメントを追加しても直りません。あなたは第1段のシステムに、より多くの第1段データを与えているだけです。
これがあなたのLLMツールやエージェントに意味すること
次トークンを予測するように訓練された言語モデルは、P(text)をモデリングしており — 第1段です — パールの世代の統計学者が想像した以上に巨大な規模でスケールしています。モデルは第1段の作業を、確かにうまくやります。問題は、プロンプトが因果（または反実仮想）の問いのように見えたときに始まります。モデルは因果計算を実行しません。その代わり、その形に関連づけているテキストパターンを取得します。
うまくいくこともあります。訓練コーパスに、その話題について十分に丁寧に扱われた因果推論が含まれていれば（そしてよく踏まれている話題であれば、それは多くの場合そうです）、パターン一致は正しい答えに着地し、「推論をしている」ように見えます。しかし、状況に近いテキストの前例がないときに崩れます。新規のシステム、あなたの特定のコードベース、そして互いに重ねて積み重なった2つか3つの介入の連鎖です。これは本番での幻覚の大きな割合の特徴です。モデルは嘘をついているわけではありません。第2段の問いに対して第1段の作業をしており、どちらの場合でも同じような流暢さで結果を提示しているだけです。
エージェントはこのギャップをより鋭くします。世界で行動するエージェントは、毎ステップで第2段の問いを投げかけます — 「このコマンドを実行したら、どんな状態になる？」という具合にです。過去の実行ログしかシグナルがないエージェントには、その実行ログについての第1段データがあります。新しい状況が、モデルが見てきた分布と一致するときはうまくいきますが、一致しないときは、たいていは静かに劣化します。「デモでは動くが、本番では失敗する」は、しばしばこのまさにその不一致です。
実務上の打ち手は、これらのツールに、登れない段を登らせようとするのをやめることです。そして、第1段のところでこそ必要となる用途に、強く（しっかり）使うことです。つまり、自動補完、定型文の生成、フォーマット変換、差分（diff）の要約、ファイル間でのパターン抽出などです。次に、因果モデルはあなた自身で用意します。プロンプト内で明示的な制約を置き、因果関係に対する期待をエンコードしたテストを用意し、出力だけでなく推論をチェックするレビューを行ってください。
これらはAIツールに反対する議論ではありません。ツールを、どの段に対応させるかを合わせろ、という議論です。パールの階層は、委任する前に素早く確認するためのチェックを与えてくれます。私はこのモデルに「パターンを認識させたい」のか、それとも「変更が何を引き起こすかを推論させたい」のか？前者は、モデルが作られた用途です。後者は、まだあなた次第です。
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
