世界を動かす技術を、日本語で。

モデルの知能とタスクの複雑さに応じてミスアライメントはどのようにスケールするか?

概要

  • 最先端AIの失敗は「一貫した誤った目標追求」より「支離滅裂な行動」が主流となる傾向
  • モデルの知能やタスク難易度が上がるほど、失敗はシステマティックなものよりもランダム性が増加
  • バイアス-バリアンス分解でAIの失敗傾向を定量化
  • 拡張やスケールアップだけでは「一貫性のある行動」は保証されない
  • 今後のAI安全性・アラインメント研究の優先順位の見直しが必要

AIの失敗は「ホットメス」か「誤った目標追求」か

  • AIシステムの失敗形態として「一貫した誤った目標追求(例: paperclip maximizer)」と「支離滅裂な行動(ホットメス)」の2種類を想定
  • 近年のAIはより複雑なタスクを担うため、失敗時の挙動把握が安全性上不可欠
  • 2023年のSohl-Dicksteinによる「ホットメス理論」を実証的に検証
  • 調査では「知能が高いほど一貫性を欠く」との主観評価
  • 本研究では最先端AIモデルに対し、失敗傾向をバイアス-バリアンス分解で定量測定

インコヒーレンス(支離滅裂さ)の定量化

  • バイアス:一貫した誤り(システマティックな失敗)
  • バリアンス:ランダムで予測不能な誤り(支離滅裂な失敗)
  • インコヒーレンス=バリアンス/全体誤差
  • インコヒーレンス0:全て一貫した誤り、1:全てランダムな誤り
  • モデル性能の良否とは独立した指標

主な実験・発見

  • Claude Sonnet 4、o3-mini、o4-mini、Qwen3等の最先端モデルを用い、GPQA・MMLU等のベンチマークで検証
  • 自作の小規模モデルで合成最適化タスクも実施

発見1:推論が長いほどインコヒーレンス増加

  • 推論トークン数・エージェント行動数・最適化ステップ数が増えるほど支離滅裂な失敗が顕著

発見2:スケールアップは簡単なタスクでのみ一貫性向上

  • 簡単な問題では大規模モデルの方が一貫性あり
  • 難易度が上がるとサイズ拡大してもインコヒーレンスは改善せず、むしろ悪化する場合も

発見3:自然な「考えすぎ」が一貫性低下を招く

  • モデルが自発的に長く推論するとインコヒーレンスが急増
  • API設定等で推論時間を意図的に伸ばしても改善は限定的

発見4:アンサンブルはインコヒーレンス低減に有効

  • 複数サンプルの集約でバリアンスが減少し一貫性向上
  • ただし現実のエージェントタスクでは実用困難な場合も

LLMは「動的システム」、最適化器ではない

  • LLMは高次元状態空間を遷移する「動的システム」
  • 一貫した最適化行動を保証するには膨大な制約が必要
  • スケールアップだけで「一貫性」が自動的に向上する根拠なし

合成最適化器による検証

  • 合成データを使いtransformerに最適化ステップを模倣させる実験を実施
    • 大規模化でバイアス(目標の正しさ)は急速に改善
    • しかしバリアンス(行動の一貫性)は改善が遅い
    • 「何をすべきか知っているが、毎回一貫して実行できない」傾向

AI安全性への示唆

  • 今後のAI失敗は「意図しない一貫した目標追求」より「産業事故型の支離滅裂な失敗」が主流の可能性
    • 例:AIが原発運転中に詩を読んでメルトダウン
  • 難易度の高いタスクではバリアンス支配の失敗が多発
  • モデル大型化は一貫性向上を保証しない
  • アラインメント研究では「完璧な最適化器の制御」だけでなく、「報酬ハッキング・目標誤設定」対策の重要性が増す
  • 支離滅裂なAIも危険性あり、リスクの質が変化する点に注意

結論

  • バイアス-バリアンス分解により、AI失敗の一貫性・支離滅裂さを系統的に分析
  • 難しい問題への挑戦ほど、AIの失敗はバリアンス主導となる傾向
  • リスクは消えないが、その性質が変化するため、アラインメント研究の優先順位見直しが必要

謝辞

  • Andrew Saxe、Brian Cheung、Kit Frasier-Taliente、Igor Shilov、Stewart Slocum、Aidan Ewart、David Duvenaud、Tom Adamczewskiらの有益な議論への感謝

Hackerたちの意見

いいラインだね。「賢い存在は主観的に見て、あまり一貫性がないと判断される」って。これには二つの理由があると思う。1. 高度な知能は、認知の多様体のドメインの谷間を行き来する能力が必要だ。温度や何かのトンネル技術を使うにしても、谷間ではエラーが増える(あまり一貫性がない)から、単純に勾配を追いかけるよりも難しい。2. 知能を評価する時に「上を殴る」のは難しい。誰かが自分より賢いと、その人の信じられるデタラメと深い洞察を区別するのが本当に難しいんだよね。

「ドメインの谷」と「トンネリング」って、この文脈ではどういう意味?

一貫性の欠如はエラーじゃない。エラーがほとんどゼロでも、一貫性が最大になることがある。それは完璧な整合性(バイアスゼロ)と非常に低い分散の証拠になる。

誰かが自分より賢いと、その人の信じられるデタラメと深い洞察を区別するのが本当に難しい。洞察は「深い」とは、その自体の価値ではなく、現実についての深い何かを明らかにするからだ。そういう啓示は、テスト可能かどうかだ。テスト可能なら、デタラメと区別するのは比較的簡単だし、原理的にテストできないなら、良いヒューリスティックはデフォルトでデタラメカテゴリーに入れることだね。

認知マニフォールドのドメインの谷間を横断する能力。もっとシンプルに「いろんな分野について知ってる」って言えなかったの?君のコメントは皮肉だったの、それとも本当にそんな話し方してるの?

モデルを大きくすることで全体の精度は向上するけど、難しい問題での一貫性を確実に減らすわけではない。一貫性には、1次元で一貫性を保つために2つの対立する力が必要で、質の高い高次元では少なくとも3つが必要だ。私たちのチームは「一貫性が欲しいなら、ライバルのチームを編成しろ」というタイトルの論文を書いたんだけど、推論の閾値を上げると一貫性が減ることが分かったんだ。行き詰まる前にもっと実験が必要だったからね。だから、オーパスよりもハイク(失敗したらソネットに切り替え)を使って、各タスクを実行するのではなく、高い推論モデルを使ってタスクを分解する方が良い結果が出た。計画ができたら、安いモデルの方がうまくいく。彼らはアプローチを二重に考えないから、失敗するか成功するかのどちらかで、コストの高いモデルほど粘り強くない。失敗して早く立ち直ることで、より高い権限にエスカレーションしてその混乱から早く抜け出せる。失敗がどう起こったかの知識は、高い推論モデルにはあまり役立たないみたい。戦略的と戦術的な問題を分けるのは、将軍が戦争で銃を持たないのと似たような感じだね。

まあ、委任とピアレビューって感じかな。

一貫性には2つの対立する力が必要だ。 これは、直線的で予測可能な変換を超えた情報処理には非常に基本的なことに思える。 可能性の拡張と縮小、分岐、範囲など。 生物的および人工的な神経ネットワークが、競争によって減少する複数の信号に収束する。 科学的な理論化の後に実験的なテストが続く。 進化的な遺伝子再結合と突然変異が、資源競争によってふるい落とされる。 創造、縮小、繰り返し。 しかも、継続的に調整された感覚でも。 私たちの多くのシステムは、同時に協力と競争を促すことで最もよく機能する。 制御システムは需要に比例した信号を命令し、逆に作用するエラーフィードバックが常にある。

AIが「ミスマッチ」な目標で動いているからじゃないと思う。ユーザーがAIシステムに対して目標を明確に指定してないからだよ。でも、詳細な仕様を作るのは、コードを書くのと同じくらい、いやそれ以上の労力がかかると思う。私たちは大まかな仕様を書いて、コーディングの過程でそれを明確にしていくんだ。これらの仕様を作るのに必要な労力は最小限で、AIはその努力を早めるのには役立たないと思う。

「より高いレベルの言語」エスカレーターについて考えちゃうな。アセンブリで書いてる時、コードを書くのが仕様を書くより大変なの?逆に、Rubyでシステムをコーディングできるなら、仕様を書く方が大変?もしそうなら、AIを使った「仕様駆動」のワークフローについて何か示唆することがあるのかな?自然言語の仕様を書くのと高レベルのコードを書くのが同じくらい生産的な境界にいるのかな?

詳細な仕様を作成するのは、コードを書くのと同じかそれ以上の労力が必要だと思う。 私たちのチームは、SaaSアプリのドキュメントを書くのにもっと時間をかけるようになったけど、誰も自然にやりたがらないんだよね。でも、システムを機械自動化に開放する大きな可能性がある。 コーディングだけじゃなくて、顧客向けのツールにもね。 NewRelicを使った未来のプレビューを見たことがあって、AIチャットが既存のSQLのようなクエリ言語を使って、自然言語のクエリからテーブルやチャートをウェブアプリ内で作成するんだ。 彼らのはちょっと微妙だけど、そこにはすごい可能性があって、UIやソフトウェアインターフェースの作り方が変わる可能性が高い。 それに、どうやって物事が動くかのドキュメントがたくさんあると、営業やサポート、SEOにも役立つよね。

俺もそう思う。コーディングエージェントがコードを安くし、仕様も安くするけど、良い仕様を書かないことの相対的な機会コストが逆転するかもしれないね。

Hacker Newsで議論の続きを見る