Tree of Thoughtsの次に来るものについて考えてきました — 推論ステップを探索できるなら、アクションも探索できるのでは？ それがまさにLATS（言語エージェント木探索）が行うことであり、今私がこれを読んでいる理由です。Andy Zhou、Kai Yan、Michal Shlapentokh-Rothman、Haohan Wang、Yu-Xiong Wangによる論文（ICML 2024、arXiv:2310.04406）は、推論・行動・計画を単一のエージェントフレームワークに統合した最も明確な総合であり、その結果は本当に無視できないものです。
論文について
LATSが取り組む中心的な問題は、従来のエージェント研究における構造的なギャップです。ReActは推論と行動を交互に行いますが、軌道が失敗したときに逆戻りして別の経路を試す仕組みがありません。Tree of Thoughtsは推論ステップの分岐を可能にしますが、内部のLM知識に基づいて動作し、探索中にツールを呼び出したり外部フィードバックを受け取ったりすることはできません。Reflexionは言語による自己修正を追加しますが、その線形的な再試行ループは代替案を探索せずに新しい軌道にコミットします。LATSはこれら3つのアイデアを適切なモンテカルロ木探索（MCTS）バックボーンで融合し、LLMエージェントが複数の分岐を探索し、実際の環境フィードバックを受け取り、経路が失敗したときにバックトラックできるようにします。
技術的な仕組みは6ステップのMCTSループです：選択（UCT式で次に探索するノードを選ぶ）、展開（LMからn個の候補アクションをサンプリングする）、評価（ハイブリッド価値関数で各ノードをスコアリング）、シミュレーション（終端状態までロールアウト）、バックプロパゲーション（祖先の値を更新）、リフレクション（失敗時、何が悪かったかの言語サマリーを生成しコンテキストとして保存）。価値関数は注目に値します：V(s) = λ·LM(s) + (1−λ)·SC(s)。ここでLM(s)は環境フィードバックを受け取った後の軌道品質に関するLM自身の推定値、SC(s)はそのアクションが兄弟ノード間でサンプリングされる頻度に基づく自己整合性スコアです。これは訓練された報酬モデルではなく、価値関数は完全にプロンプト駆動です。
主要なアイデア
- HumanEvalで、GPT-4 + LATSはpass@1 92.7%を達成。GPT-4 + Reflexionは91.0%、GPT-3.5 + ReAct単独では56.9%。GPT-3.5 + LATSは83.8%に跳ね上がります。
- HotPotQAで、LATS（CoT + ReAct）はExact Match 0.71を達成。ReActベースラインの0.32に対し、マルチホップ精度が2倍以上に向上。
- WebShop（ウェブナビゲーション+購入）で、LATSは75.9（成功率38.0%）を記録。Reflexionの64.2（35.0%）に対して、多くのページにまたがる状態管理が必要なタスクで有意な差。
- Game of 24（純粋な推論パズル）で、LATSは成功率0.44を達成。同じGPT-4バックボーンを使用しているにもかかわらず、ToTの0.20を上回ります。
- 驚くべきことに、LATSはToTよりも少ないノード展開で解を見つけます（HotPotQAでk=50のとき平均66.65ノード vs 84.05ノード）、トークン使用量も少なく（173,290 vs 210,215）、理論上はより高コストに見えるにもかかわらずです。
有効な点 — そして有効でない点
ベンチマーク数値は現実的で、フレームワークは概念的にもクリーンです。UCT定式化は、ToTの場当たり的なBFS/DFSに欠けている原理的な探索・活用トレードオフを提供します。純粋なLM内省ではなく、外部環境フィードバックを価値関数に統合するのは正しい方向であり、結果がそれを示しています。
しかし、この論文には著者が完全にはストレステストしていない重大な前提があります：LATSは環境を以前の状態に戻す能力を必要とします。 チェックポイントがなければ、木を分岐できません — 一度アクションを取れば、コミットされます。著者らはLMタスクでは「過去のテキスト入力をコピーペーストする」ことで対応可能なことが多いと指摘していますが、実際のアクション環境（データベース、ファイルシステム、副作用のあるAPI）では、多くの本番システムが満たせない厳しい要件です。WebShopの結果はベースラインより優れていますが、複雑な環境では自己リフレクションが具体的ではなく一般的になりがちであることを示しています — エージェントは表面的には異なるが構造的に同一の間違いを繰り返して停滞することがあります。論文はこれを指摘していますが、対策は示していません。
また、MCTS構造の貢献と価値関数設計の貢献を分離するアブレーションもありません。同じハイブリッド価値関数を使ったより単純な分岐アプローチでギャップの多くを埋められる可能性は十分にあり、著者らはこれを直接テストしていません。
金融AIにとっての重要性
Beancount台帳は、LATSスタイルの木探索にとってほぼ理想的な環境です。主な理由はひとつ：すべての台帳がgitリポジトリでバックアップされていること。 状態復元要件 — LATSを多くの実環境で非現実的にする厳しい制約 — はgit checkoutやgit stashで簡単に満たせます。ライトバックエージェントは、複数のブランチにわたって候補の仕訳エントリを提案し、貸借対照表の制約（価値関数）に対してスコアリングし、最高スコアの経路のみをコミットできます。失敗したブランチには言語によるリフレクションが残ります：「転記されたエントリは、勘定科目タイプの分類ミスのため、資産 = 負債 + 純資産に違反しました。」
ハイブリッド価値関数の設計も直接適用可能です。台帳エージェントの場合、LM(s)は提案されたエントリの意味的適合性（正しいカテゴリに見えるか？）をスコアリングし、SC(s)はエージェントが類似の過去取引をどの程度一貫して分類するかを追跡します — 台帳自身の履歴に根ざした自然な自己整合性チェックです。
状態復元は、金融アナロジーで私が異議を唱えたい唯一の点です。実際の台帳には下流効果があることがよくあります：転記されたエントリが請求書をトリガーし、それが支払いワークフローをトリガーします。そのような場合、LATSの前提は崩れます。具体的にBeancountでは、台帳がgit管理下のプレーンテキストファイルであり、下流トリガーが発火する前にローカルで変更が行われるため、前提は成立します — ただし、これは明示的に維持すべき設計上の制約です。
次に読むべきもの
- 環境モデルなしのMCTSベース計画：「推論と計画の統合：言語モデルによる計画は世界モデルによる計画」（Haoら、2023年、arXiv:2305.14992）— LATSが基盤とし改善したRAP。
- LM価値関数はどの程度汎化するか？「ステップバイステップで検証しよう」（Lightmanら、2023年、arXiv:2305.20050）— プロンプトベース価値関数の代替としてのプロセス報酬モデル。
- 不可逆性下での安全なマルチステップ計画：「逐次プロンプティングによる言語モデルを用いた意思決定」（Creswellら、2023年）— 状態復元要件を回避するより単純な計画アプローチ。
