Skip to content
Published on

LLMができないのは証明ではなく前提を立てることです

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

モデルを三度入れ替えたのに結果が同じだったプロジェクト

ログから異常なパターンを見つけて原因の仮説を立てる社内ツールを作ったことがあるとしましょう。モデルを最新に入れ替えるたびに文章はよくなるのに、出てくる仮説の一覧はほとんどそのままです。デプロイの時刻、トラフィックの急増、キャッシュミス、依存サービスの遅延。半年前に出ていた一覧と同じです。

これをプロンプトの問題と見なして数週間を費やす前に、別の可能性を一度検討する価値があります。モデルが怠けているのではなく、一覧になかった項目を新たに作り出すこと自体が、いまの構造からは出てこない種類の作業なのかもしれない、ということです。

帰納、演繹、そして抜けているひとマス

Google DeepMindのTom ZahavyがICML 2026に出した立場論文Position: LLMs can not jumpは、推論を三つに分けます。データから規則を取り出す帰納、前提から結論を導く演繹、そして観察を説明する新しい仮説を立てるアブダクションです。

論文の主張は、前の二つと残りのひとつを明確に切り分けます。生成AIは統計的パターンマッチング、すなわち帰納をすでにマスターしており、形式的証明にあたる演繹も急速に征服しつつあります。ところが新しい説明仮説を作り出すアブダクションについては、そうしたメカニズム自体がないというのが論文の立場です。タイトルにあるジャンプは、経験から公理へ飛び移るこの動作を指します。

この区別が有用なのは、実務では二つの失敗がまったく違って見えるからです。演繹が弱いモデルは間違った答えを出します。アブダクションのないモデルは間違えないのに毎回同じ一覧を出します。後者は性能指標にはほとんど現れません。

アインシュタインの事例が論文で果たしている役割

論文は一般相対性理論の定式化を事例研究に使います。この選択は飾りではなく、論証の核心です。

当時の観測データは希薄でした。水星の近日点の歳差ぐらいがほぼすべてで、そのデータから統計的に取り出せるのはニュートン力学の小さな補正程度でした。等価原理という前提はデータを圧縮して出てきたものではなく、データの外側で立てられたあとにデータで検証されたものです。

論文が指摘するのはここです。その前提がいったん与えられれば、そこから場の方程式へ向かう演繹の区間は現代のLLMがそれらしく実行できます。できないのはその前提を立てる側です。

圧縮としての創造性が崩れる地点

この事例は、広く使われているひとつの見方を直接狙い撃ちにします。創造性とは結局データをより短く説明する能力であり、だからより大きくよりよく圧縮するモデルはいずれ発見もするようになる、という見方です。

論文は、この見方が観測データの希薄な発見では成り立たないと見ます。圧縮は圧縮する対象があってはじめて働きます。データが薄い地点で新しい説明を立てることは圧縮とは別の演算であり、だからモデルを大きくする方向では自動的についてこない、というわけです。

論文がボトルネックとして名指しするのはシミュレーションを形式的な公理へ翻訳する区間であり、提案する方向は、物理的に一貫したマルチモーダルなワールドモデルから感覚的な根拠を供給することです。テキストだけで学習したモデルは、世界がどう動くのかを世界について書かれた文から学びます。まだ誰も書いていない説明を立てなければならないとき、その学習信号には寄りかかる先がない、というのが論旨の核心です。

これは結果の論文ではなく立場の論文です

読み方についてひとつはっきりさせておく必要があります。ICMLのPositionトラックは新しい実験結果を載せる場ではなく、分野がどの方向へ進むべきかについての主張を載せる場です。タイトルの接頭辞がその事実を明示しています。

ですからこの論文は「LLMはアブダクションができない」を実験で証明しません。ひとつの歴史的発見を計算論的な事例研究として取り上げ、いまの学習目標ではその区間に到達する根拠がないと論証します。これは弱点ではなく形式の性格であり、反対の立場も同じトラックから出うるものです。著者個人の立場表明であって、所属機関の公式見解として読む根拠もありません。

実務家にとって有用な読み方はこれです。真か偽かを判定しにかかるより、真だと仮定したときに自分の設計のどこが変わるかを見ることです。

仮説空間をモデルの外から供給する

一つ目の変化は役割の配置です。仮説の一覧をLLMに「思いついてくれ」と頼む代わりに、列挙可能な空間をシステムが作り、LLMにはその空間をなめて、翻訳して、順位を付けさせます。

先ほどのログ分析の例に戻ると、原因の仮説を自由記述で受け取る代わりに、サービスの依存グラフ、最近のデプロイ一覧、設定変更の履歴、インフラのイベントを直積に展開して候補を作ります。候補の数は数百になり、人間が全部は見られません。ここでLLMは提案者ではなくフィルタであり翻訳機として働きます。これはモデルを格下げして使うことではなく、得意な区間に配置することです。

"""仮説は列挙可能な空間から出てきて、モデルはなめて順位を付ける。"""
from dataclasses import dataclass
from itertools import product


@dataclass(frozen=True)
class Hypothesis:
    subject: str      # 何が
    change: str       # どう変わって
    mechanism: str    # どの経路で症状を作るのか

    def as_claim(self) -> str:
        return f"{self.subject}の{self.change}が{self.mechanism}を通じて症状を作る"


def enumerate_space(services, changes, mechanisms):
    """仮説空間の大きさと境界をコードが所有する。"""
    return [Hypothesis(*t) for t in product(services, changes, mechanisms)]


def refutable(h: Hypothesis, evidence: dict) -> bool:
    """反証可能性の検査: 確かめるための観測が実際に存在するか。"""
    return h.subject in evidence and h.mechanism in evidence[h.subject]


space = enumerate_space(
    services=["payment-api", "session-cache", "search-index"],
    changes=["デプロイ", "設定変更", "容量の縮小"],
    mechanisms=["接続プールの枯渇", "キャッシュミスの急増", "タイムアウトの伝播"],
)
evidence = {"payment-api": {"接続プールの枯渇", "タイムアウトの伝播"}}

testable = [h for h in space if refutable(h, evidence)]
print(len(space), "件の候補のうち観測で検証できるもの", len(testable), "件")
for h in testable[:3]:
    print("-", h.as_claim())

ここで重要なのは enumerate_space がコードだという事実です。システムが何を発見できるかの上限がプロンプトではなくこの関数に書かれていて、レビューでき、広げられます。

提案と反証を同じモデルに任せない

二つ目の変化は役割の分離です。仮説を出す側とその仮説を壊す側を同じ呼び出しに置くと、自力で通過できる仮説のほうへ傾きやすくなります。これはモデルの不誠実さではなく目的関数の問題です。一度によい答えを要求すると、反証可能性の低い答えのほうがよい答えのように見えます。

そこでパイプラインをこう切ります。提案の段階は候補を広く出し、点数を付けません。反証の段階は各候補について「これが真なら必ず見えるはずの観測」と「真なら絶対に見えてはいけない観測」をそれぞれ書かせ、その観測を実データに問い合わせます。人間は最後に生き残った少数だけを見ます。

反証の段階を別の呼び出しにすると、副次的な効果がもうひとつ生まれます。「真なら絶対に見えてはいけない観測」を書けない仮説が自動的に弾かれます。そうした仮説はたいてい反証不可能な記述、つまり何を観測しても生き残る文です。人間が読むともっともらしく、何の情報もないその文が、実務でもっとも時間を食います。

この配置のよいところは、論文の主張が間違っていたときにも損がないことです。もし次の世代のモデルが本当にアブダクションをするようになれば、提案段階の候補の質がそのまま上がります。構造はそのままにしておけます。

どこまでが私たちの問題で、どこからが論文の問題か

最後に範囲を整理しておく必要があります。論文が扱っているのは科学的発明、すなわち新しい公理を立てる水準の飛躍です。私たちが毎日作るシステムの大半は、その水準の飛躍を要求しません。

ですからこの論文を「LLMは創造的ではない」と要約するのは行き過ぎです。より正確な要約はこちらです。既知の仮説空間のなかの探索と、その空間自体を広げることは別の作業であり、いまの道具は前者にはるかに強い。 ですから私たちのシステムが後者を必要とするのかをまず問うべきで、必要なら、その部分は人間かシミュレータが担うと設計に明記しなければなりません。

冒頭のログツールに戻ると、半年間ずっと同じ一覧が出ていた理由は、モデルではなく、その一覧を定義した場所がどこにもなかったことにある可能性が高いのです。

参考資料

Discuss on Twitter • View on GitHub