AIは計算である

私たちがChatGPTという製品を通じて大規模言語モデル（LLM）の形でAIに初めて出会ったとき、それはまるで神託のようでした。質問をすると神託が答え、それが取引のすべてです。しかし、エージェンティックAIの輝かしい未来に向かって進むにつれて、この話は当てはまらなくなってきました。エージェンティックAIは、何らかの方法で物事を実行し、おそらく計算さえも行います。

機械学習の元々の枠組みは関数近似でした。この枠組みは正確でしたが、現在の局面で起きていることを捉えきれていません。機械学習は、より正当に「人工知能」と呼べるものに変わりました。私が機械学習に興味を持つ同僚から、特定のモデルで汎用計算ができないと不満を言ったとき、彼らが怪訝な顔をしたのを覚えています。当時はワード埋め込みの話をしていたと思います。Word2Vecが登場したばかりで、連続意味空間で単語を操作する可能性はすぐに明らかでした。しかし、単純な概念算術を超える構成性がなければ、意味空間は興味深いだけで、検索には役立つかもしれませんが、意味のある計算にはほど遠いものでした。非常によく整理された辞書は、やはりただの辞書です。

かつて私がよく面接で聞いていた質問（誰も満足に答えられず、私自身も悩んだもの）は、可変サイズの入力を固定サイズのベクトルに実用的に詰め込み、勾配消失に悩まされることなくニューラルネットワークで処理する方法というものでした。（リカレントニューラルネットワークは有名な非解決策でした。）Transformerはこの質問に決定的に答えました。単純にそれをしない（つまり固定サイズベクトルに詰め込まない）のです。入力とともに成長する表現を維持し、その代償として計算量が二次関数的に増加します。これにより、ニューラルネットワークは理論上は普遍関数近似器でありながら、元の形式では可変サイズデータや可変計算量を扱うように設計されていなかったという制約から解放されました。

素朴な関数近似は写像を与えますが、代数構成性の本質的なスケールを無視します。非公式には、計算は代数構成性の具現化です。その違いは、後者が必要になるまでは衒学的に見えるかもしれません。

ループと構成性

LLMは明らかに計算できます。「適切に」理解された計算は、形式言語の規則に従うことでモデル化されます。LLMはこの概念を拡張して、非形式言語の非形式規則に従うようにしています。これは論理学者が約100年前に作り出した厳格な定義要件を満たさないかもしれませんが、彼らが定義しようとした精神を、私たちが通常認めるよりもはるかに良く捉えている可能性があります。

私たちが慣れ親しんでいる物理コンピュータと同様に、言語モデルは有限のコンテキストとメモリに制限されています。それらは不完全なモデルです（興味深い余談として、不完全性が理論にあるのか実装にあるのかという問題があります）。

計算の歴史において覚えておくべき事実があります。私たちがこれまでに行った最も強力なこと（実際、過度に強力だったと以前主張したこと）は、任意のループを導入したことです。原始再帰関数はすでに注目に値します。有界再帰内で多くの計算を実行でき、すべての呼び出しで終了が保証されます。しかし、決定的な飛躍、計算可能な全体像を切り開いたのは、非有界反復でした。μ演算子、WHILEループ、「条件が満たされるまで続け、それがいつになるかは約束しない」という能力です。

コンテキスト圧縮、サブエージェント、発見可能コンテキストに関する私たちの取り組みは、実質的に有限なコンピュータを理論的には無限の機械のモデルとして扱えるという元の議論と同じ方向を指しています。すなわち、非指数関数的アルゴリズムがあれば、特定のワークロードに対して元の設定の限界に達したときに、より多くのメモリ、処理能力、機械を追加できるのです。

では、言語モデルを通じた単一のフォワードパスが計算上実際に何なのか考えてみましょう。固定コンテキストウィンドウと有限精度演算を備えたTransformerは、入力シーケンスから出力分布への有界関数を計算します。アーキテクチャは固定深度の回路であり、無制限のワーキングメモリを備えた機械ではありません。各トークンは以前のトークンに注意を向けますが、計算はレイヤー数、コンテキストウィンドウ、実装制約によって決定される有界な操作回数で終了します。

これは批判ではありません。この制約はトレーニングを実用的にする一部です。しかし、これらのシステムが構造的に何ができ、何ができないかを経験的ではなく問うとき、この事実を明確に保持する価値があります。単一のフォワードパスは任意の深さの計算ではありません。それは非常に洗練された有界関数適用です。

ここでエージェンティックAIが製品カテゴリーではなく技術的問題として興味深くなります。計算を強力にするループが導入されつつありますが、それはハーネスレベルで導入されています。モデルが呼び出され、出力を生成し、その出力が何らかの状態（ファイル、ツール呼び出し結果、メモリストア、計画、テストログ）を変更し、モデルは更新されたコンテキストで再度呼び出されますが、モデル自体は固定されたままです。計算はラッパー内で発生します。ハーネスはモデル自体にはないWHILEループを提供します。

これにより、エージェンティックハーネスがなぜ疑わしいほど古典的に見えるかも説明できます。コンテキスト圧縮、サブエージェント、発見可能コンテキストは、実質的に有限なコンピュータを理論的には無限の機械のモデルとして扱えるという元の議論と同じ方向を指しています。すなわち、非指数関数的アルゴリズムがあれば、特定のワークロードに対して元の設定の限界に達したときに、より多くのメモリ、処理能力、機械を追加できるのです。

つまり、今のところ、私たちが使用しているのはアクターモデル、ツリー、UnixファイルシステムとOS状態、シェル、任意のコードを実行する能力だけです。追加の機械学習の高度な処理はほとんどありません。

これは、現在のAIの基本的な計算特性を浮き彫りにします。LLMは、人々が歴史的にAIと関連付けてきたもう一つのこと、つまり人間のように振る舞い、模倣し、おそらくは人間であることよりも、計算（非公式に定義されたものではありますが）を実行することの方がはるかに優れていると言えるでしょう。記憶、継続的学習、何かを気にかけること、持続可能な意図性を持つことなどは、短い局所的なコンテキストではシミュレートできるかもしれませんが、中程度のスケールではその欠如がより顕著です。そしてこれは、私のようなプログラマーが、実際の人間である私が定義し、熟考し、設定したタスクに対してこれらのシステムが達成できることに今でも心から驚かされている時代です。

私たちが今日持っているAIは、人工的な人格というよりも、非公式計算です。そして非公式計算をインスタンス化できるようになったことで、GOFAI時代のチェスコンピュータが形式的推論と実際の知能の微妙な違いを示したのと同様に、この区別が浮き彫りになっています。

エントロピーは摩擦である

確率的システムのループ化に対する標準的な反対意見は、エラーが蓄積するというものです。そして時にはそれがまさに得られる結果です。決定論的プログラムでは、ループは書かれたとおりに実行されます。確率的デコーダが何百ものステップを実行する場合、意味空間を通る軌跡は、古典的なソフトウェアにはきれいな対応物がない方法で、ドリフトし、カールし、発散する可能性があります。ステップ3での幻覚が後続のすべてに影響を与える可能性があります。単純に考えれば、長いエージェンティック実行では壊滅的な劣化が予想されます。

しかし、経験的な記録は加法的エラーモデルが予測するよりも興味深いものです。外部フィードバックに基づくと、長いエージェンティック実行は時々自己修正します。モデルはコードを書き、テストを実行し、失敗を確認し、タスクの表現を更新してエラーを修正します。検索し、矛盾する証拠を見つけ、計画を修正します。失敗したツール呼び出しはエラーメッセージを生成し、それがコンテキストに戻り、モデルは調整します。エントロピーは現実ですが、常に単調に増加するわけではありません。

テスト、ツール、検索結果、実行トレース、永続状態が軌跡を制約します。これらはシステムが世界と衝突することを強制することで、任意にドリフトするのを防ぎます。

したがって、エントロピーの問題は現実ですが、壁ではありません。それは摩擦のようなものです。パフォーマンスを低下させ、実用的な限界を設定し、エンジニアリングの注意を要求しますが、有用な長期的計算が行われるのを妨げるわけではありません。

ループのトレーニング

より難しい問題は、計算構造をハーネスレベルではなく最適化レベルに統合することが何を意味するかです。現在、ループは勾配の外側に存在します。モデルは主に次のトークン予測や指示追従でトレーニングされますが、ループと状態管理は推論時に行われ、トレーニングプロセスが一度も見たことのない足場の中で行われます。モデルはトレーニング分布から、アーキテクチャ的に自分が明示的に最適化されたものとは異なる実行コンテキストに一般化する必要があります。そして、それは期待以上にうまく機能します。

しかし、明らかなミスマッチがあります。勾配降下の強力な点は、トレーニングした分布の構造を正確に見つけることです。関心のある分布がマルチステップのエージェンティック実行（状態を伴う手続き、ループ、エラー復旧、バックトラッキング、ツール使用）である場合、計算構造が後付けではなく組み込まれたその分布でトレーニングすれば、質的に優れた結果が得られるはずです。最適化の圧力が正しい場所に適用されるでしょう。

これが大規模に実現されていない明白な実用的理由があります。ループを持つステートフル実行のトレーニングインフラは、固定コンテキストの次のトークン予測よりもはるかに複雑です。計算は孤立したフォワードパスではなく長いロールアウトにわたって悪いスケーリングを示し、数十から数百のステップにわたるクレジット割り当ては本当に困難です。どの初期の決定が後になって成功や失敗を引き起こしたかを知る必要があり、そのシグナルは急速に希釈されます。

これらは言い訳ではなく、実際の障害です。

そのため、私たちはよりクリーンな分解をデフォルトとしました。モデルを次のトークン予測でトレーニングし、後でループを追加して、能力が一般化することを期待します。この期待は部分的に裏付けられました。「部分的」が鍵となる言葉です。

私たちがまだ持っていないのは、反復、失敗、自己修正、成功の経験によって内部表現が長い計算軌跡にわたって深く形成されたモデルです。ループは依然として主にPythonファイル、シェルツール、オーケストレーションコード、プロンプト規則の中にあります。トランスデューサをトレーニングし、それをプログラムでラップしたのです。

Verplankalkül

これにより、プログラミング言語の話題に入ります。計算と深く絡み合い、私にとって非常に身近なトピックです。Andrej Karpathyは、英語が今や最大のプログラミング言語であると指摘することで知られています。多くの点で私は同意します。少なくとも、計算可能で計算に焦点を当てた英語のサブセットについてはそうです。しかし、これを詳しく見てみましょう。

英語は形式言語ではありません。厳格な構文も、形式的に定義された計算意味論もありません。プログラミング言語に相当するものを捉えるには、用語を再構築する必要があります。

そのために、新しい種類のプログラミング言語を紹介したいと思います。Verplankalkülと呼ぶことにします——かばん語です。最初のプログラム可能なコンピュータを製作したKonrad Zuseは、最初のプログラミング言語をPlankalkül（文字通り「計画計算」）と名付けました。ドイツ語の口語表現「verplant」は、混乱した、散らかったという意味で、文字通り「計画ミス」です。したがってVerplankalkülは、混乱した計画計算です。

非公式プログラミング言語。