※本稿は、ICML 2024チュートリアルでの「On the Role of LLMs in Planning」というサブバラオ・カンブハンパティ教授による講演の内容を要約したものです。
1. はじめに
1.1 チュートリアルの目的と背景
このICML 2024チュートリアル「On the Role of LLMs in Planning」は、大規模言語モデル（LLMs）のプランニングにおける役割を批判的に検討することを目的としています。近年、LLMsを用いたプランニングタスクへの関心が急速に高まっており、特にエージェント型LLMsの概念や、LLMsが推論やプランニングを行えるかどうかという議論が注目を集めています。
過去3年間、「LLMsはゼロショットでXXXができる」というXXXにプランニングや推論などが入る論文が多数発表されてきました。これらの研究は、空のTransformerモデルと、ウェブスケールのコーパスで事前学習されたLLMsの両方を対象としていますが、本チュートリアルでは主に後者、つまり最先端のLLMsに焦点を当てます。
しかし、LLMsのプランニング能力に関する文献の多くはNLPや機械学習の会議で発表される一方で、プランニングの専門家は主にICMLを含むIAPS（国際自動プランニングとスケジューリング会議）や制約プログラミングなどの別の会議に参加する傾向があります。この状況は、両分野間で双方向の無知を生み出しています。機械学習研究者はプランニングを新たに発見しつつあり、一方でプランニングの専門家は機械学習研究者の取り組みに疑問を投げかけています。
このチュートリアルは、この知識のギャップを埋め、LLMsのプランニングにおける役割を批判的に検討することを目指しています。講演者は、これが単なる技術の宣伝ではなく、バランスの取れた議論になることを強調しています。LLMsができないことを指摘すると同時に、他の特定のタスクに非常に有用であることも示します。
カンブハンパティ教授は、LLMsに関して過度に否定的な見解を示すことは「かわいい子犬を蹴るようなもの」だと述べています。つまり、LLMsを非難することが目的ではなく、むしろそれらを適切に活用することが重要だと強調しています。技術の強みと限界を明確に理解することが、その技術を前進させる鍵となります。一方で、盲目的な称賛や偏った懐疑主義は、単に自身のインフルエンサーとしてのキャリアを前進させるだけだと警告しています。
1.2 講演者の背景
チュートリアルの講演者はサブバラオ・カンブハンパティ教授です。カンブハンパティ教授は、AIの分野で長年にわたり活躍してきました。彼は「AIを学校が流行る前からやっていた」と述べており、1956年のダートマス会議ほど古くはありませんが、自動プランニングの分野で幅広い業績を残しています。
カンブハンパティ教授の研究は、様々なプランニングシナリオを網羅しています。これには、異なるタイプのシステムダイナミクス、様々な最適化メトリクス、そしてプランナーが利用可能なモデルの完全性の異なるレベルが含まれます。彼は、強化学習とプランニングの関連性にも言及しており、強化学習を本質的に「プランニングと学習の組み合わせ」と捉えています。つまり、エージェントが使用するモデルも学習しようとしているのです。
過去10年間、カンブハンパティ教授は説明可能なAIと人間-AI相互作用の分野でも多くの研究を行っています。このチュートリアルに直接関連するものではありませんが、彼の幅広い専門知識を示しています。
LLMsのプランニング能力に関する研究において、カンブハンパティ教授は重要な役割を果たしています。彼は、自身の学生たちと共に、LLMsのプランニングにおける限界と可能性を理解するための重要な研究を行ってきました。特筆すべきは、このチュートリアルの内容が、翌日のICMLでスポットライトポジションペーパーとして発表される予定であることです。これは、このトピックに関するより詳細な議論と文献レビューを提供する機会となります。
カンブハンパティ教授は、LLMsとプランニングの関係について、赤と緑の2つの側面があると述べています。赤の部分は、LLMsが自律的にプランニングを行えないという主張です。これは、プランニングが必要とする推論や組み合わせ的推論をLLMsが本質的に行えないためです。Chain-of-Thought、ReAct、ファインチューニングなどの手法も、この問題を大きく改善することはできません。また、LLMsの自己検証も性能を向上させるわけではなく、人間が反復的にプロンプトを与えることは「賢い馬」効果を招く可能性があります。
一方、緑の部分は、LLMsがプランニングタスクにおいて非常に有用であるという主張です。LLMsは素晴らしいアイデア生成器であり、プランの構成要素、問題の仕様の改善、さらにはドメインモデル自体についてのアイデアを生成できます。ただし、LLMsは生成したプランの堅牢性を保証することはできないため、人間や自動検証器とループ内で使用する必要があります。これらの自動検証器は、LLMsから半自動的に抽出されたモデルを使用している可能性があります。
このように、カンブハンパティ教授のアプローチは、LLMsの限界を認識しつつも、その潜在的な有用性を最大限に活用することを目指しています。彼の経験と洞察は、このチュートリアルを通じて、LLMsとプランニングの関係についての深い理解を提供することが期待されます。
2. プランニングの基礎
2.1 プランニング、スケジューリング、強化学習の関係
プランニング、スケジューリング、強化学習の関係は全て連続的な決定問題です。プランニングの場合、与えられた目標に対して、それを達成するための一連の行動やポリシー（計画）を作成することが目的です。できれば最適性などの保証を伴うことが望ましいです。
標準的なプランニング問題や強化学習問題では、エージェントが取りうる可能な行動は予め与えられています。プランニングの本質は、これらの行動をどのように順序付けるか、あるいはMDPの場合はどのようにポリシーに組み込むかを決定することです。
一方で、「メア・プランニング」と呼ばれる別のタイプのプランニングも存在します。これは、問題を解決するための行動自体を考え出すプロセスです。インドでは「ジャガド・プランニング」とも呼ばれています。メア・プランニングは、完全な形では通常のプランニングよりも難しい問題です。
LLMsによるプランニングについて人々が印象的に感じる理由の一つは、LLMsがどこにも明示的に書かれていない行動を提案できることです。しかし、重要なのは単に行動を思いつくことではなく、それらの行動の順序が実際に問題を解決するかどうかです。
スケジューリングは、プランニングの特殊なケースです。実際、ICMLやNeurIPSなどの会議でLLMsとプランニングに関する論文を書いている多くの人々は、スケジューリング問題を扱っているにもかかわらず、それを認識していないことがあります。スケジューリングとは、一連のタスクや仕事、そしてそれらを遂行するための行動の選択肢が与えられた時に、望ましくない相互作用が発生しないように行動をタスクに割り当てることです。
例えば、ジョブショップ・スケジューリングでは、複数の仕事を複数の機械で処理する際に、機械間の競合が発生しないようにスケジュールを組みます。
強化学習、特にモデルベースの強化学習は、プランニング問題と密接に関連しています。プランニングでは、行動とそのモデル（前提条件と効果）が与えられますが、強化学習ではエージェントが行動のモデル（遷移関数）を学習しながら、同時にポリシーを作成します。
2.2 プランニングの複雑性と課題
最も単純なシナリオであるSTRIPSプランニング問題でさえ、計算複雑性はPSPACE完全です。一方、スケジューリングはNP困難です。
プランニングを難しくしている主な要因の一つに、「カスケード型の前提条件」があります。例えば、「正しいことをする」という単一の目標があったとしても、その行動を実行するには多くの前提条件が必要になり、それらの前提条件を満たすためにさらに他の条件が必要になり、それがカスケード的に続いていきます。スケジューリングでは通常、このような無限に続く前提条件のカスケードは発生しません。
2.3 エルゴード性、ロバスト性、品質、最適性の概念
プランニングにおいて重要な概念について説明します。まず、エルゴード性です。環境がエルゴード的であるとは、エージェントが正の確率で環境の任意の状態から他の任意の状態に到達できることを意味します。非エルゴード的環境では、エージェントが特定の状態や状態群に閉じ込められ、目標に到達できなくなる可能性があります。
プランニングは特に非エルゴード的環境で重要です。エルゴード的環境では、多少の失敗をしても、最終的に目標を達成できる可能性が高いですが、非エルゴード的環境では一度失敗すると致命的な結果につながる可能性があります。
次に、ロバスト性について説明します。計画のロバスト性とは、その計画が失敗したり行き詰まったりすることなく目的を達成する確率を非公式に表したものです。決定論的な環境では、正確性がロバスト性と同義です。非エルゴード的環境では、高度なロバスト性が求められます。
LLMsに関連して、「トップkの正確性」という概念がよく議論されます。これは、LLMがk個の異なる計画を提案し、そのうちの1つが正しい計画である可能性を指します。しかし、非エルゴード的環境では、この概念はあまり役に立ちません。
計画の品質は、ロバスト性とは別の概念です。品質は目標がどのように達成されたかに関する指標です。これは多くの場合、良い計画に対する暗黙の常識的な期待を反映しています。
品質の考慮事項を正確性の問題に変換することは可能です。例えば、「計画にかかる時間は特定の制限を超えてはならない」という制約を追加することで、品質の問題を正確性の問題に変換できます。しかし、多くの場合、品質の考慮事項は明示的に規定されていません。
興味深いことに、LLMsはスタイルの達人であり、「雰囲気」を生み出すのが得意です。LLMsは人々が好むような計画を提案することはできますが、その計画が実際に機能するかどうかは別問題です。
最後に、世界モデル、検証器、シミュレータについて説明します。プランニングエージェントが立てた行動計画がロバストであるかどうかを近似的に検証する方法は、その計画が何らかのモデルに対して正確であるかどうかをチェックすることです。このモデルは、PDDLモデルやSAT modulo理論モデルのように外部から与えられる場合もあれば、ドメインシミュレータとして与えられる場合もあります。
多くの人はドメインシミュレータがモデルとは異なると考えていますが、実際にはドメインシミュレータも誰かがドメインに関する知識を持ってプログラムしたものです。また、エージェントが実世界での試行錯誤を通じて直接学習する場合もあります。
LLMsに関連して最も興味深い点の1つは、LLMsが世界モデルを正確に学習する能力を持っているかどうかということです。この点についてはまだ明確な結論は出ていませんが、多くの研究は、LLMsが適切な世界モデルを持っていないことを示唆しています。これが、LLMsが正確なプランニングを行えない主な理由の1つとなっています。
3. LLMsの概要と特性
3.1 LLMsの基本的な仕組み
LLMsは本質的に、非常に大規模なn-gramモデルと考えることができます。我々は小規模なn-gramモデルについてはよく知っていますが、GPT-3.5のような3,000語のコンテキストウィンドウを持つモデル、さらには100万トークンのコンテキストウィンドウを持つモデルは、実質的に100万グラムモデルと言えます。
小規模なn-gramモデルに対する我々の直感は、これほど大規模なn-gramモデルには必ずしも当てはまりません。しかし、結局のところ、それらは依然としてn-gramモデルなのです。LLMsが何か根本的に異なることをするのではないかという期待は、単なる希望的観測に過ぎません。
LLMsの驚くべき点は、パラメータの数が多いことではなく、むしろ少ないことです。例えば、3,000語のウィンドウと50,000語の語彙を持つモデルを考えてみましょう。条件付き確率テーブルを完全に記憶しようとすると、50,000の3,000乗という途方もない数の予測を行う必要があります。この数は実質的に無限大です。それに比べると、1,760億のパラメータは極めて小さな数字なのです。
つまり、トレーニング中に大規模な圧縮が行われているということです。そして、任意の圧縮は何らかの一般化に対応します。しかし、その圧縮が正しい一般化につながっているかどうかは別問題です。実際、私が機械学習の分野を観察してきた中で、「一般化」という言葉が最も過剰に使用され、ほとんど意味を失っているように感じます。
n-gramモデルは本質的に常にプロンプトを補完しています。そして、その補完結果は訓練データに直接保存されているものではありません。つまり、LLMsは常に「幻覚」を起こしているのです。生成された内容が正確であるという保証はありません。私はよく、LLMsの幻覚問題を次のように表現します：「LLMsは常に幻覚を起こしており、時々その幻覚が現実と一致することがある」。これがLLMsの動作を理解する上でより適切な見方だと考えています。
プロンプトエンジニアリングによってこの状況が根本的に変わるわけではありません。プロンプトを変更することで事実に基づく補完や正確な計画が得られるかどうかは、プロンプトを作成する人が与えられた回答の正確性を判断できるかどうかに依存します。時にはそれが可能な場合もありますが、そうでない場合もあります。
例えば、検索の場合を考えてみましょう。答えを知らない場合、なぜLLMを使用するのでしょうか？LLMの回答をチェックし、その後でGoogleで正確性を確認するのであれば、時間の無駄です。常に近似的な検索は幻覚につながるということを覚えておく必要があります。幻覚は「時々」ではなく、「常に」発生しているのです。
3.2 LLMsの強みと制限
LLMsの近似検索は、様々な問題の計算難易度に関する我々の直感を覆します。特に、LLMsがどのように問題を解決するかについて、根本的な問題の計算複雑性は影響を与えません。
例えば、半決定可能または決定不可能な計算を必要とする問題と、多項式時間または亜線形時間の計算で解ける問題をLLMに与えた場合、LLMは決定不可能な問題に対してより長く考えるわけではありません。どちらの場合も、LLMは定数時間で次のトークンを生成するだけです。
これは覚えておく価値があります。問題の根本的な複雑性は、LLMが回答を推測する能力に影響を与えないのです。しかし、コンピュータサイエンスにおける我々の直感のほとんどは、問題を解くことの容易さがその計算複雑性に依存するという考えに基づいています。この直感はLLMsの現実と衝突します。
例えば、LLMsが自己検証を行えると主張する人々の直感的な動機の一つは、多くの問題において検証が生成よりも計算コストが低いという事実です。これは多くの問題に対して確かに言えることですが、誰もLLMsが実際に問題を解いていると言ったわけではありません。LLMsは訓練データから近似的に回答を検索または生成しているだけなのです。
したがって、計算複雑性は差を生みません。これは、確率的な要素や部分観測可能性など、通常は機械学習やプランニングアルゴリズムを困難にする問題の特性が、LLMsには影響を与えないことを意味します。LLMsはプロンプトにエンコードされた根本的な問題の計算複雑性を気にしません。
これは驚くべきことではありません。一方で、AIシステムにとって常に問題となってきた背景知識は、LLMsにとってはある程度容易です。なぜなら、サム・アルトマンや他の人々が、我々の集合的な知識の全てをウェブ上で訓練したからです。
その結果、LLMsは多くのことについて近似的な推測を行うことができます。常識、ドメイン知識、心の理論、類推など、全てを近似的に提供できます。
さらに、多くの人々にとって最も印象的なのは、LLMsの言語能力です。要約、詳細化、特にフォーマット変更などの能力は驚異的です。ただし、要約は実際には推論問題であることを忘れてはいけません。多くの場合、誰かが要約を提供すると、私たちはそれが良いように見えます。なぜなら、本全体を読む必要がなく、1ページで済むからです。しかし、提供された要約が実際に本の内容を正確に反映しているかを確認する唯一の方法は、本を読むことです。しかし、誰が本を読む時間を持っているでしょうか？
このように、LLMsは近似的な回答を生成するのに優れていますが、その回答の正確性を保証することはできません。これがLLMsの強みであり、同時に限界でもあるのです。
4. LLMsによるプランニングの限界
4.1 ブロックワールド問題での失敗事例
約1年半から2年前、私たちはGPT-3とGPT-3.5をブロックワールド問題で評価しました。その結果は非常に悪いものでした。そこで私たちは「LLMsはプランニングができない」という論文を書きました。これは多くの人々にとって驚きでした。なぜなら、ほとんどの人がLLMsはプランニングができると考えていたからです。
その後、GPT-4が登場し、それは「知性の火花」を持っていると言われました。そこで私たちは、この知性の火花がプランニング問題を解決できるかどうかを調べることにしました。2023年12月、私たちはLLMsにプランニング問題を提示する様々な方法を体系的に評価し、外部の検証器を使用して計画が正しいかどうかを確認する新しい論文を発表しました。
その結果、計画生成の結果は若干改善されました。GPT-3.5の5-6%から、GPT-4では34%の正確性に向上しました。一見すると、GPT-3.5からGPT-4への進歩が続けば、GPT-10では170%の正確性に達するのではないかと期待してしまいそうです。しかし、これは誤った期待です。
私が疑問に思ったのは、LLMsがブロックワールドの事実を名前に基づいて検索しているのか、それとも実際に推論を行っているのかということでした。記憶と推論の違いをどのように判断できるでしょうか？
4.2 Mystery Domains実験
この疑問に答えるため、私たちは「ミステリードメイン」と呼ばれる手法を用いました。この手法は、1998年にDrew McDermottが考案したものです。McDermottは、人々がドメイン固有のプランナーを作成するのではなく、あらゆるドメインを扱える一般的なプランナーを作成しているかどうかを心配していました。そこで彼は、単に名前を見るだけでプランニングできないように、単語を他のランダムな単語に置き換えるというアイデアを思いつきました。
私たちはLLMsに対して同じことを行いました。例えば、ブロックワールドの場合、「ブロックを拾う」の代わりに「オブジェクトを攻撃する」、「別のブロックの上からブロックを取り除く」の代わりに「別のオブジェクトからオブジェクトを饗宴する」といった具合です。
これによってプランニングが非常に難しくなると思うかもしれませんが、重要なのは、述語の名前を変更しても、プランニング問題のダイナミクス自体は変わらないということです。これは論理学の基本です。もし本当に推論を行っているのであれば、名前の変更は問題にならないはずです。
実際、古典的なプランナー、つまり人々が批判するような単純なプランナーでさえ、これらのドメインを同じように解くことができます。彼らには何の問題もありません。
一方、LLMsの性能は劇的に低下しました。34%から0.16%程度まで落ち込んだのです。この結果を見て、私は冗談で「GPT-4が人類を滅ぼすのではないかと心配している人がいるなら、ブロックワールド問題を与えれば大丈夫だ。GPT-4は立ち往生して、私たちは別の日を生き延びることができる」と言いました。
もしこの結果に驚いたのであれば、他の研究者たちも同様の結論に達していることをお伝えしたいと思います。例えば、Tom Griffithsのグループは、推論だと思われていたものが実際には近似的な検索であることを指摘しています。名前を変更しただけでパフォーマンスが大幅に低下したという私たちの実験結果は、LLMsが実際には推論ではなく検索を行っていたことを示しています。
Griffithsらの「Embers of Autoregression」という論文では、GPT-4がシーザー暗号の解読を得意とすることに疑問を投げかけています。これはSebastian Bubeckが「知性の火花」の一例として挙げたものです。しかし、彼らはシーザー暗号が基本的に文字をオフセットでシフトすることであることに着目し、可能な全てのオフセットについてGPT-4の性能をチェックしました。
結果は驚くべきものでした。GPT-4はオフセット13で非常に優れた性能を示しましたが、他のオフセットではほとんど機能しませんでした。Unix経験者なら、「rot13」というコマンドを覚えているでしょう。これは平文ファイルを「暗号化」する一般的な方法でした。ウェブスケールのコーパスにはrot13に関する十分なトレーニングデータがありますが、他の数字についてはそうではありません。つまり、GPT-4は手順を学習したのではなく、本質的に推論問題を検索問題に変換したのです。これは驚くべきことではありません。
興味深いことに、LLMsにミステリーブロックワールドのドメインを与え、「これはどのドメインを連想させますか？何に最も類似していますか？」と尋ねると、驚くほど正確に「ブロックワールド」と答えることができます。つまり、LLMsの一部は類推ができることを知っていますが、別の部分はそれを使用する方法を知りません。
実際、私たちはLLMが提供したマッピングをLLMに直接与えてみましたが、それでも問題を解決する性能は低いままでした。
最後に、ICMLの皆さんに向けて、そしてLLMsに対して意地悪だと感じている人たちに向けて、一言付け加えたいと思います。「なぜ名前を変更したブロックワールドを解かせるのか、人間だってそれは難しいのではないか」という反論があるかもしれません。まず、この指摘自体が理解できません。私たちは機械が人間以上のことができることを望んでいるはずです。人間ができることを機械ができるだけでなく、それ以上のことができることを期待しているのです。
第二に、人間は確かにミステリーブロックワールドの問題をブロックワールドよりも難しく感じますが、報酬を与えれば解決できます。実際、私たちは大学院生を対象に実験を行いました。大学院生は何でも解決してくれます。彼らにドメインとルールを与え、問題を解決するためにアクションを組み立てるよう依頼すると、正しく問題を解決することができました。100%正解です。一方、LLMsにお金を与えようとしましたが（サム・アルトマンはより裕福ですが）、LLMsの性能は向上しませんでした。
一般的に、私たちはシステム1で何とかやり過ごしていますが、システム2も持っており、生命が危険にさらされたり、無料でお金がもらえたりする場合にはそれを使用します。一方、LLMsには特にシステム2がありません。これが重要なポイントです。
4.3 Chain-of-Thoughtプロンプティングの限界
Chain-of-Thought（CoT）プロンプティングについて説明します。CoTは、ある種の宗教のようなものです。人々は、例題の解き方を示せばLLMがそこから学習できると考えています。しかし、私は古いAI研究者として、アドバイスを取り入れることが難しい問題であることを知っています。
実際、AIの創始者の一人であるジョン・マッカーシーは、彼の聖杯の一つが「アドバイス・テイカー・プログラム」であると述べています。なぜなら、アドバイスを取り入れるには、高レベルのアドバイスを特定の状況に適用できるように操作化する必要があるからです。これは、アドバイスがその特定の問題に非常に特化していない限り、決して容易なことではありません。
私たちの実験では、CoTプロンプティングが一般化しないことを示しました。ブロックワールド問題に対して4つの異なるセットアップを用意しました：
- ドメイン非依存のCoT：どのドメインでも、計画が与えられれば、モデルを見てプログレッションまたはリグレッションを行うことで計画が正しいかどうかをチェックできることを示しました。
- ブロックワールド特有のCoT：目標が常に単一のスタックであり、初期状態が複数のブロックのスタックを持つことを想定しました。ブロックワールドでは、初期状態からすべてのブロックをテーブルに置き、目標状態に現れる順序でそれらを構築すれば、常に最適な方法で問題を解決できます。この方法では、最適解の最大2倍の長さになりますが、少なくとも正しい解が得られます。
- セットアップ2を特化させ、最初からすべてのブロックをテーブルに置いた状態にしました。
- 上記のすべてを行い、さらに最終スタックが常に辞書順になるようにしました。つまり、A1からA100までのブロックがあれば、A1からA100の順に積み上げるようにしました。
私たちは3〜4ブロックの問題についてこれらのCoTの例を与えましたが、一般化に失敗しました。3〜4ブロックの問題では性能が向上しましたが、グラフに示されているように、ブロック数が増えるにつれて正確性は急激に低下しました。
人間なら、私が説明した「初期状態からすべてのブロックをテーブルに置き、正しい順序で積み上げる」という一般的な手順を理解できるはずです。しかし、CoTプロンプティングではLLMがこの一般的な手順を学習することができませんでした。
この失敗はブロックワールドに限ったことではありません。例えば、元のCoT論文で取り上げられている「最後の文字の連結」というタスクでも同様の問題が見られます。単語数を増やして最後の文字の連結を行わせると、同じCoTのアドバイスを与えても、単語数が増えるにつれて正確性が低下します。
人間なら「最後の文字の連結」という概念を一度理解すれば、4語、5語、10語、15語のケースについて別々に説明する必要はありません。そんなことをしたら、私は大学院生として君をクビにするでしょう。しかし、LLMsにはそれが必要なのです。
これは私の独断ではありません。CoT論文の共著者の一人であるDale Shansは、今年のIAPS（国際自動プランニングとスケジューリング会議）での基調講演で、私たちの主張が正しいことを認めました。実際、誰かがツイートで「Ravはもう正しかった」と言及していましたが、私の返答は「Ravは今でも正しい」でした。なぜなら、状況は変わっていないからです。CoTは現在でも一般化しないようです。
ReActスタイルのプロンプティングも別のバリエーションですが、私たちの論文では、これも機能しないことを示しています。特に、彼らは「think」タグについて大きく取り上げていますが、「think」タグをどこに置くかは重要ではありません。すべてを前に置いても、特定の場所に置いても、性能に違いはありません。
さらに、性能を向上させるためには、非常にタスク固有のCoT例が必要です。論文の詳細はありますが、基本的に推論をパターンマッチングに変換できる場合にのみ機能し、非常に特定の種類の知識を与える必要があります。一般的な手順ではダメなのです。
4.4 自己批評の問題点
LLMsの自己批評、つまり自己検証の能力についても触れたいと思います。多くの人々は、LLMsが即座に正しい計画を立てられなくても、自己検証によって性能を向上させられるのではないかと考えています。しかし、私たちの研究結果は異なる結論を示しています。
実際、LLMsに自己検証させると、その性能は低下することがわかりました。私の提案は、理解していない問題を解こうとする人に対して、直感に従い、自己修正しようとしないことです。なぜなら、自分が何を話しているのかわからない状態で自己修正しようとすると、より多くの間違いを犯す可能性が高いからです。
私たちの論文では、LLMsが自己検証を試みると、実際にはパフォーマンスが低下することを示しています。具体的には、ゲーム・オブ・24、グラフ彩色、そしてプランニングという3つの異なる推論ドメインで実験を行いました。
LLMが解決策を推測し、その解決策が正しいかどうかをループで確認し、正しくない場合は自己にプロンプトを送り返して修正するという方法を検討しました。また、外部の検証器（正しい彩色や正しい解決策を知っているもの）と比較しました。
結果は驚くべきものでした。LLMの自己批評は実際には幻想であることがわかりました。自分の解決策を修正しようとすると、多くの場合、最初の推測よりも性能が低下しました。これは、私が先ほど言及したことを裏付けています。つまり、何をしているのかわからない場合は、自分の推測を疑わない方が良いのです。
なぜこのようなことが起こるのでしょうか？それは、解決策を修正する際に、LLMsが幻覚を起こすからです。実際には存在しないエラーを想定したり、実際に存在するエラーを見逃したりします。そして、特定の背景が機能するように解決策を変更し続けるため、結果的に性能が低下してしまうのです。
つまり、正確性の批評における偽陽性と偽陰性が、LLMsの性能を低下させているのです。
ファインチューニングによって改善する一つの方法は、検証だけを行うLLMを別途訓練することです。私たちはこれを試み、いくつかの有望な結果を得ました。しかし、そのままの事前学習済みLLMは、生成と同じくらい検証も得意ではありません。実際、検証を行わせると性能が低下する可能性があります。
では、なぜ多くの人々がLLMの自己反省や自己検証について論文を書いているのでしょうか？それは、問題の異なる側面を見ているからです。特に、エッセイの改善など、暗黙知を必要とするタスクでは、解決策の正しさを形式的に検証する方法がありません。そのような場合、LLMが何をしても、人間がそれを良いと感じることを期待しているのです。
これに対し、ゲーム・オブ・24、ブロックワールド、制約充足問題など、形式的な検証が可能なタスクでは、LLMsの性能は非常に低いのです。実際、他の研究者も同様の結論に達しています。
自己検証が機能する場合もあります。それは、訓練データに正しいデータだけでなく、修正データも含まれている場合です。GitHubの差分を利用した興味深い研究があります。ファイルが一つのバージョンから別のバージョンに変更される際、後のバージョンの方が良いという前提で、その差分を利用しています。このようなアプローチでは、生成よりも検証の方が若干有利になる可能性があります。
一般的に、これはスタイルと内容の問題に帰着します。LLMsはスタイルに優れていますが、内容や正確性には弱いのです。スタイルを活用したい場合、私たちはLLMsを得意なことに使うべきだと考えています。
実際、私たちのグループからCOLing（計算言語学会議）に発表される論文があり、LLMの行動のスタイルを観察し、批評する方法を示しています。例えば、行動が目標を達成しているにもかかわらず、暗黙の制約に違反している可能性があります。例えば、はさみを渡す際に、鋭い先端を相手に向けて渡すのは、目標は達成していますが、安全性という暗黙の制約に違反しています。特にロボットの場合、このような行動は危険です。
これらのようなスタイルの考慮事項は、明示的な制約として正確性の問題に変換しない限り、LLMsは比較的うまく扱うことができます。
5. LLMsのプランニングにおける有用な役割
前のセクションでLLMsのプランニングにおける限界について説明しましたが、ここではLLMsがプランニングにおいて果たすことのできる有用な役割について説明します。LLMsは自律的にプランニングを行うことはできませんが、プランニングのプロセスを支援する上で非常に有益な役割を果たすことができます。
5.1 アイデア生成器としてのLLMs
LLMsは優れたアイデア生成器として機能します。これは、私がこれまでの説明で強調してきた点です。LLMsは、与えられた問題に対して様々な解決策や行動のアイデアを生成することができます。これは、人間のプランナーが考えつかなかった新しい視点や可能性を提供する上で非常に有用です。
アイデアはどこからでも来る可能性があります。行き詰まってアイデアが出ない状態はありますが、誰かからアイデアを与えられることもあります。しかし、与えられたアイデアが正しいアイデアであるかどうかは別問題です。LLMsは最初の部分、つまりアイデアの生成に優れています。しかし、そのアイデアが正しいかどうかを検証するには、別の誰か、あるいは何かが必要です。
古典的なAIアプローチでは、エキスパートシステムを構築する際、人間のエキスパートにインタビューを行い、その知識を論理的な形式で記述し、推論エンジンに与えるというプロセスを踏んでいました。これは「知識エンジニアリングのボトルネック」と呼ばれ、エキスパートから知識を引き出す過程が非常に困難でした。
LLMsは、この知識エンジニアリングのプロセスを大幅に自動化します。LLMsはドメインモデル、ルール、その他の知識を近似的に生成することができます。ただし、これらの生成された知識が実際に意味をなすかどうかを確認するために、人間や自動化された検証器が必要です。
5.2 ドメインモデル生成におけるLLMsの活用
LLMsの時代におけるプランニングでは、ドメインモデルをLLMsが推測できることを考慮に入れる必要があります。実際、深層強化学習の分野では、基本的なアプローチが非常に非効率であるため、ほぼどんな改善でも性能向上を示すことができます。これは、最も低レベルの形式的なドメインモデル、つまりほぼ原子レベルのドメインモデルを使用する傾向があるためです。
LLMsは、近似的なドメインモデルを推測することができ、これらのモデルは強化学習のコンテキストで使用して、性能を大幅に向上させることができます。ICML 2022で発表された論文では、手書きの近似的なドメインモデルを使用して、ランドマークなどの高レベル分析を行い、深層強化学習システムがこれらのランドマークを通過して目標に到達するようにしています。これにより、性能が大幅に向上しました。
LLMsを使用すれば、このプロセスをさらに自動化することができます。LLMsは、完全に正確ではないが、十分に有用な近似的なドメインモデルを生成することができます。これらのモデルは、強化学習エージェントのガイドとして使用することができ、探索空間を大幅に削減することができます。
5.3 スタイル批評におけるLLMsの強み
LLMsは、プランやポリシーのスタイル面での批評に特に優れています。我々は、人間とAIのインタラクションに関する論文で、LLMsを「常駐人間」として使用し、人間がある行動やプランを見たときにどのように感じるかを推測する方法を示しました。
これは必ずしも常に正確ではありませんが、単に計画を立てるだけでは人間を驚かせる可能性のある状況を予測するのに役立ちます。つまり、LLMsは人間の代理として使用でき、人間にとってより良いと思われる計画を生成するためのスタイル基準として機能します。これは正確性の基準ではなく、スタイルの基準です。
例えば、ロボットがはさみを渡す際の行動を考えてみましょう。目標を達成するという意味では、はさみを渡せばそれで十分かもしれません。しかし、鋭い先端を相手に向けて渡すのは、特にロボットの場合、人間にとって不安を感じさせる行動です。このような暗黙の制約や期待を捉えることは、LLMsが得意とする領域です。
我々のグループがCOLing（計算言語学会議）で発表する論文では、LLMの行動のスタイルを観察し、批評する方法を示しています。この研究では、行動が目標を達成しているにもかかわらず、暗黙の制約に違反している可能性がある状況を特定し、改善することができます。
このようなスタイルの考慮事項は、明示的な制約として正確性の問題に変換しない限り、LLMsは比較的うまく扱うことができます。つまり、LLMsは人間の期待や社会的規範を理解し、それに基づいて行動を評価する能力があるのです。
結論として、LLMsはプランニングにおいて自律的に機能することはできませんが、アイデア生成、ドメインモデルの作成、スタイル批評など、プランニングプロセスの重要な側面で非常に有用な役割を果たすことができます。次のセクションでは、これらの役割をより効果的に活用するためのフレームワークである「LLM Modulo」について詳しく説明します。このフレームワークは、LLMsの強みを最大限に活用しながら、その限界を補完する方法を提供します。
6. LLM Modulo フレームワーク
6.1 フレームワークの概要
LLM Moduloフレームワークについて説明します。このフレームワークでは、LLMがプランニングにおいて複数の役割を果たします。最上位レベルでは、LLMが推測を生成し、それに対して批評バンクが存在します。この批評バンクには、スタイル批評と正確性批評の両方が含まれます。これらの批評は、修正案を提案したり、計画が正しいかどうかを判断したりします。そして、これらの批評はLLMへのバックプロンプトとして送られ、LLMは新しい解決策を生成します。
このフレームワークは、多くの既存の研究を統一的に捉えることができる枠組みだと考えています。
6.2 生成-テストアプローチ
LLM Moduloは本質的に生成-テストフレームワークです。LLMsが候補となる計画を生成し、批評がそれらの計画をテストします。この中で、LLMsは様々な建設的な役割を果たします。
LLMsは候補となる計画を生成し、正確性批評を駆動するモデルの近似的な源として機能します。正確性批評にはドメインモデルが必要ですが、このドメインモデルをLLMから抽出することができます。これは、知識エンジニアリングタスクを自動化する一種のコパイロットのようなものです。
また、LLMsはスタイル批評者としても機能し、すべての批評者からの批評を整理するメタコントローラーの役割も果たします。このメタコントローラーは、すべての批評を統合し、LLMへの組み合わされたバックプロンプトを送ります。さらに、LLMsはフォーマット変更にも役立ちます。異なる批評が異なる形式表現を使用する場合、LLMsは自動的に表現の変換を支援します。
ここで重要なのは、これらの機能はどれも保証されたものではないということです。しかし、これは生成-テストフレームワークであり、最終的に出力されるのは正確性批評が正しいと判断したものだけです。これが、機能しない計画を出力しないという保証になります。
LLM Moduloでは、LLMsとインターフェースする完全なソルバーではなく、批評を使用することを推奨します。批評は建設的な批評にもなり得ます。例えば、緩和された計画を解くソルバーを使用し、その計画をバックプロンプトとして使用することもできます。
しかし、一般的にソルバーを使用し、LLMからソルバーへの単一方向のインターフェースにすると、ソルバーの表現力の制約に縛られてしまいます。また、一般的にソルバーはそれほど効率的ではありません。そのため、LLMsが解決策を生成し、この生成-テストフレームワークの中で動作させる方が効果的です。
生成-テストは、生成器が正解である可能性が高い解決策をより高密度で生成できる場合に有効です。経験的な観察によると、LLMsは少なくともスタイル的にブロックワールドの計画や結婚式の計画のように見える解決策を生成する傾向があります。つまり、正解である可能性が高い解決策をより高密度で生成できるのです。これが、LLM Moduloが機能する理由の一つです。
実際、我々はLLM Moduloの最も基本的なバージョンを、たった一つの批評でブロックワールド問題に適用しました。この批評は、PDDLドメインモデルを使用し、VALシステムを用いて計画がモデルに対して正しいかどうかを健全にチェックします。このようなシステムは、どのドメインでも存在します。
この単一の批評とLLMとの間で15回の反復を行うだけで、正確性は82%まで向上しました。さらに印象的なのは、82%の場合に正しい計画を提供し、残りの場合には計画を提供しないということです。つまり、批評が不正確な計画を通すことはありません。これは、堅牢なプランニングがどのように機能するかを示しています。
6.3 批評バンクの構成
批評バンクには、正確性批評者とスタイル批評者があります。前に言及した行動批評は、スタイル批評の一例です。正確性批評は、計画が実際に目標を達成しているか、すべてのアクションが正しく機能しているか、相互作用がないかなどをチェックします。これは、私たちの研究が示しているように、LLMsが自力で行うことができない部分です。
一方、スタイル批評については、LLMsに勝るものはありません。基本的に、LLMsが行うことが最善です。なぜなら、エッセイがどれだけ良いかを形式的にチェックする方法を誰も知らないからです。これは暗黙知のタスクです。
したがって、LLMsはスタイルの批評に直接使用できますが、正確性については、LLMsから抽出されたモデルを使用する可能性のある外部検証器を使用します。
批評はバイナリ（「もう一度試してください」）の場合もあれば、建設的な場合もあります。例えば、「候補の中にこのようなエラーがあります。この部分についてはこのバリエーションを試してみてはどうでしょうか」というような形です。
また、批評者は緩和された解決を行い、緩和された計画をバックプロンプティングに組み込むこともできます。さらに、部分的な批評も可能です。計画が機能することを保証するのではなく、少なくとも明らかなエラーがないことを確認するだけです。
これは、ソフトウェアのユニットテストと同様です。ユニットテストに失敗すれば、それは明らかに悪いプログラムです。しかし、すべてのユニットテストに合格したからといって、必ずしも完璧なプログラムであるとは限りません。例えば、Crowdstrikeの事例では、おそらくすべてのユニットテストに合格したにもかかわらず、世界中のシステムをダウンさせてしまいました。
ユニットテストを行うためには、Pythonインタプリタのような重要なものがあります。任意のプログラムをPythonインタプリタに与えると、そのプログラムの出力を教えてくれます。これは人類文明の驚くべき成果です。LLMsはPythonインタプリタを書いたわけではありません。しかし、これは特定の言語の意味論を取得するためのモデルなのです。
自然言語にはこのようなものは存在しません。プログラミング言語は形式的ですが、自然言語ははるかに一般的で、単一のインタプリタは存在しません。一般的に、任意の世界に対してインタプリタを振る（シェイク）ことはできません。シミュレータがその世界にない限り。つまり、Pythonインタプリタは、Pythonプログラムのシミュレータなのです。
6.4 メタコントローラーの役割
メタコントローラーは、様々な批評者からの批評を組み合わせ、それをプロンプトとしてLLMに送り返す役割を果たします。この過程で、メタコントローラーは「プロンプト多様化」と呼ばれる重要なタスクを実行します。
LLMsは、すべての関連する候補を生成できるわけではありません。実際、Vaishnavh NagarajanのICMLでの研究があります。彼は、教師強制訓練によって訓練されたTransformerモデルが、訓練されたデータさえも取り出すことができない場合があることを指摘しています。
つまり、生成に不完全性があるのです。しかし、プロンプト多様化戦略を送ることで、より完全にすることができます。一つのアイデアは、「このブランチでは行動A1で始まる計画を与えてください。このブランチでは行動A2で、このブランチでは行動A3で」というようにすることです。
これは基本的に、プロンプトを多様化することで探索をシミュレートしようとする「思考の木」（Tree of Thoughts）のアイデアです。一般的に、LLM Moduloの健全性と完全性を考えることが重要です。
健全性は、正確性批評が正しいことから来ます。一方、完全性については、前述のように、関連するすべての可能な解決策を生成して、そのうちの1つが正しくなるということは保証されていません。ここで、プロンプト多様化戦略が役立ちます。
プロンプト多様化戦略は、探索技術から借用することができます。なぜなら、これは実際に世界のモデルだからです。すべての計画がこれらのアクションの1つで始まらなければならないことを知っているので、それで始める必要のあるアクションを伝えているのです。
このように「思考の木」を見ると、彼らが書いたのとは異なる見方ができます。実際、私はこれについて長いTwitterスレッドを書きましたが、基本的に「思考の木」が行っているのは、LLMがより多くの候補を生成し、そのうちの少なくとも1つが正しくなるようにするためのプロンプト多様化だということがわかります。
これを示すために、我々は次のような実験を行いました。「思考の木」の操作全体を無視し、単にLLMに24パズルに対して150の解決策を生成させ、それらのうちの1つが正しいかどうかを外部の検証器でチェックしました。その結果、「思考の木」の性能に非常に近い結果が得られました。
つまり、実際に機能しているのはプロンプト多様化なのです。異なる空間の部分から候補を生成するためです。そして、正しく多様化するためには、LLM自体が直接使用していないドメインについて何かを知る必要があります。これが覚えておくべき重要な点です。
LLM Moduloフレームワークは、LLMsの強みを最大限に活用しながら、その限界を克服するための統合的なアプローチを提供します。
7. 具体的なユースケースとアプリケーション
7.1 旅行プランニングベンチマーク
私たちの研究成果を検証するために、旅行プランニングベンチマークを用いた実験を行いました。このベンチマークは、オハイオ州立大学のグループが開発したもので、私たちの論文が発表された後に登場しました。
旅行プランニングは、本質的にはスケジューリング問題の一種です。一連のアクティビティを選択し、制約が違反されないようにスケジュールを組む必要があります。このベンチマークでは、GPT-4を使用して旅行計画を生成し、その正確性を評価しました。
結果は驚くべきものでした。GPT-4は、ハードな制約に関して、わずか6%の正確性しか達成できませんでした。これは、私が以前にブロックワールドの問題でLLMsを批判したときに、「なぜそんな人工的な問題を使うのか」と言われたことを思い出させます。しかし、旅行プランニングは、実際に人々が行いたいと思う現実的なタスクです。
例えば、存在しない飛行機を予約したり、ウィーンに奇跡的に到着することを期待したりするなど、実際の制約を考慮しない計画は役に立ちません。LLMsは、ハードな制約に関して正しい計画を生成できるのはわずか6%だったのです。
この問題に対して、私たちはLLM Moduloのアイデアを適用しました。各種の制約に対して異なる批評者を設定し、LLMに推測を生成させ、それを改善していくアプローチを取りました。そして、わずかな作業で、元の性能を6倍以上向上させることができました。
現在、私たちが直面している課題は、旅行計画の多様化です。LLMsは生成の際にループに陥る傾向があり、非常に似たような候補を生成してしまいます。これは、「思考の木」（Tree of Thoughts）アプローチが古典的な探索を使用することで解決しようとしていた問題です。しかし、古典的な探索を行うためには、ドメインのモデルが必要です。LLMsはこのドメインモデルを提供してくれません。これは重要な点です。
7.2 コード生成におけるLLMsの活用
次に、コード生成におけるLLMsの活用について説明します。多くの人が、GitHub Copilotのようなコード補完ツールの成功を見て、「コードはプランよりも一般的で、プログラムを生成しているのだから、LLMsはプランニングもできるはずだ」と考えるかもしれません。しかし、この考えは誤りです。
まず、Copilotが機能するのは、多くの場合、人間が監督しているからです。Copilotが生成するコードの断片は、非常に一般的なものがほとんどです。以前はStack Overflowで探さなければならなかったようなコードを、LLMsが生成できるようになったのです。これは確かに便利ですが、LLMsが自動プログラミングを行っているわけではありません。
自動プログラミングはAGI（人工汎用知能）と同義です。もしそれが実現したら、私も非常に感銘を受けるでしょう。LLMsを自動プログラミングに使用している唯一の真面目な人々は、LLMsを使ってコードを生成し、それをユニットテストでチェックしています。これは、先ほど説明したLLM Moduloアプローチそのものです。
そうでない場合、あなたが検証者となり、LLMsの推測をチェックし、そのコードが正しいかどうかを確認することになります。これが、Twitterで時々見かける「Copilotが生成した15行のコードに、4時間もバグ修正に費やしてしまった」という投稿の理由です。Copilotは一見合理的に見えるコードを生成しますが、それが実際に正しいかどうかは別問題なのです。
このことは、エージェント型LLMsについても考えさせられます。特に、LLMsがいつ、どのように使用できないかについて注意が必要です。行動を取ることと、計画を立てることは全く別のことです。関数を呼び出すだけでは、プランニングとは言えません。
最も恐ろしい例を挙げるなら、家に幼児がいて、銃が置いてあるような状況です。幼児は銃を使うかもしれませんが、必ずしも正しい理由で使うとは限りません。行動を取ることと、その行動が望ましい結果をもたらすことを確認することは、全く別の問題です。後者がプランニングなのです。単に行動を取るだけなら、それは単なる行動主義（エフェクチュアリズム）に過ぎません。
特に、呼び出す関数に相互作用がある場合、問題はさらに複雑になります。ブロックワールドの問題を一連の関数呼び出しとして書くこともできますが、LLMsはそれでも失敗するでしょう。
したがって、LLMs自体にプランニングを期待することはできません。外部の検証者がいるか、あるいは計画が世界を破壊しないことを確認する必要があります。最近のCrowdstrikeの事例のように、小さなソフトウェアの呼び出しが世界を混乱させる可能性があります。これは、LLMsが生成する計画の正確性を保証できないために起こり得ることなのです。
7.3 強化学習におけるLLMsの利用
最後に、強化学習におけるLLMsの利用について簡単に触れます。LLMsは、深層強化学習システムにおいて特に有用な役割を果たす可能性があります。
深層強化学習の分野では、基本的なアプローチが非常に非効率であるため、ほぼどんな改善でも性能向上を示すことができます。これは、最も低レベルの形式的なドメインモデル、つまりほぼ原子レベルのドメインモデルを使用する傾向があるためです。
LLMsは、近似的なドメインモデルを推測することができ、これらのモデルは強化学習のコンテキストで使用して、性能を大幅に向上させることができます。ICML 2022で発表された論文では、手書きの近似的なドメインモデルを使用して、ランドマークなどの高レベル分析を行い、深層強化学習システムがこれらのランドマークを通過して目標に到達するようにしています。これにより、性能が大幅に向上しました。
LLMsを使用すれば、このプロセスをさらに自動化することができます。LLMsは、完全に正確ではないが、十分に有用な近似的なドメインモデルを生成することができます。これらのモデルは、強化学習エージェントのガイドとして使用することができ、探索空間を大幅に削減することができます。
これらの具体的なユースケースとアプリケーションは、LLMsがプランニングや関連タスクにおいて、適切に使用すれば非常に強力なツールになり得ることを示しています。しかし同時に、LLMsの限界を理解し、適切な検証メカニズムを組み合わせることの重要性も強調しています。
8. Q&Aセッション
8.1 人間のデータを用いたLLMの改善について
質問者1: 私たちはTouring.comで、主要なLLM企業（OpenAI、Anthropic、Google、Metaなど）と協力して、コーディング、デバッグ、その他のエージェント型ワークフローのための人間のデータを扱っています。例えば、50人のソフトウェア開発者と50人の他の知識労働者のチームがあり、一般的なプランニングのためにLLMsをより良くするために人間のデータを生成できるとします。タスクをどのように設計しますか？
カンブハンパティ教授: 基本的に、あなたが尋ねているのは、推論を検索に変換する方法についてだと思います。これは、来る質問の非常に特定の分布を知り、それに対して正しいデータを提供することに大きく依存します。一般的に、これは合理的なアプローチです。例えば、ウェブスケールのデータで十分に表現されていないドメインがある場合、ファインチューニングでその情報を追加提供することで、少なくともLLMの性能は向上するでしょう。しかし、これは一般化しません。一般化の概念さえも、我々が考えているような手順を学習するというものではありません。
8.2 LLMsと論理モデルの関係
質問者2: 100年以上前に、ヒルベルトとアルフレッド・タルスキが真理の概念について問いかけ、タルスキがモデル理論を提案しました。今日起こっているのは、LLMsが第一階論理のモデル、つまり「これは真である」「これらの文は真である」「これらの文は真でない」と言えるモデルを欠いているということでしょうか？
また、抽象解釈の古典的理論では、述語抽象化によって抽象ドメインでモデルを生成します。LLMsでも同様の技術を使用できないでしょうか？抽象ドメインは具体的なドメインよりも詳細が少ないため、より効果的かもしれません。
カンブハンパティ教授: 最初の質問に関しては、論理の観点から言えば、一連の基本的な事実が与えられた場合、「AとA→Bが真ならば、Bも真である」というような推論をシステムが行えるかどうかが一つのポイントです。興味深いことに、LLMsは単一のステップさえも行うことができません。これは私が言及した「grocking」論文が示していることです。
しかし、人々が感銘を受ける理由は、LLMsが基本的な事実だけでなく、演繹的閉包の一部でも訓練されているからです。興味深いことに、私が言及した別の論文では、推移的閉包からの情報を投げ込んだ場合にのみ、推論をパターン発見の問題に変換できると述べています。
結局のところ、私は必ずしも「真理とは何か」という哲学的な問題に立ち返っているわけではありません。主に、避けられる明らかな問題を止めることが重要です。人類文明は常にそうしてきました。実世界で我々が立てる計画は、どれも100%正しいことが保証されているわけではありません。しかし、世界の部分的なモデルを持ち、その計画がそのモデルに関して機能するかどうかをチェックすることは、ユニットテストのようなものです。
二つ目の質問については、完全には聞き取れませんでしたが、オフラインで話し合いましょう。一般的に、LLMsを人類全体の外部の非真実的な記憶として考えてください。それは単なるあなたのためのシステム1ではなく、人類全体のためのシステム1です。LLMsは、ウェブスケールのコーパスで表現されている、潜在的に関連性の高いアイデアをより高密度で生成するのに優れています。しかし、生成したアイデアが正しいという保証はありません。
8.3 LLMの確率モデルとしての解釈と回答の評価
質問者3: LLMを確率モデルと考えた場合、複数の多様な回答を生成しています。形式的な検証アプローチがない場合、生成されたサンプルの分布統計を見て、例えば意味的類似性などを調べることで、どの回答がより正しい可能性が高いかを判断することはできないでしょうか？
カンブハンパティ教授: はい、その通りです。私はスタイルと正確性を二分法的に区別しましたが、時にはスタイルを正確性の要件に変換することができます。あるいは、正確性をスタイルの要件に変換することもできます。なぜなら、LLMsはスタイルが得意だからです。
これは基本的に、LLMsの制約付きデコーディングアプローチと呼ばれる一連のアイデアに関連しています。実際、Marvin Minskyは基本的に、知能とは生成-テストの「テスト」の部分を「生成」に組み込むことだと言いました。
より良い解決策の密度を高めれば、より良い結果が得られます。その方法の一つがファインチューニングであり、もう一つが制約付きデコーディングですが、これらはすべて密度を高めるだけです。それでも保証はありません。
9. まとめ
カンブハンパティ教授のチュートリアルは、LLMsのプランニングにおける役割と限界について包括的な洞察を提供しました。
教授は、LLMsが自律的にプランニングを行うことができないという重要な点を強調しました。ブロックワールド問題やミステリードメイン実験の結果が示すように、LLMsは推論や組み合わせ的思考を必要とするタスクで失敗します。Chain-of-Thoughtプロンプティングや自己批評などの手法も、この根本的な限界を克服することはできないことが明らかになりました。
しかし、教授はLLMsがプランニングに全く役立たないわけではないと指摘しました。LLMsはアイデア生成器として非常に優れた能力を持っており、ドメインモデルの生成やスタイル批評においても強みを発揮します。これらの能力は、プランニングプロセスを支援し、より効果的なプランニングを可能にする上で非常に有用であると教授は主張しました。
教授が提案したLLM Moduloフレームワークは、LLMsのこれらの強みを活用しつつ、その限界を補完するアプローチを提供します。このフレームワークでは、LLMsを生成-テストサイクルの一部として位置づけ、外部の検証器や批評者と組み合わせて使用します。旅行プランニングベンチマークの実験結果が示すように、このアプローチは従来のLLMsの性能を大幅に向上させることができることが示されました。
チュートリアルでは、コード生成や強化学習など、他の分野でのLLMsの応用についても検討されました。これらの分野でも、LLMsの強みを活用しつつ、その限界を認識することの重要性が強調されました。
カンブハンパティ教授は、LLMsのプランニングにおける役割は、自律的なプランナーではなく、人間やより厳密なシステムとの協調的なパートナーとしてのものだと結論付けました。LLMsは、アイデアの生成、ドメインモデルの提案、スタイルの批評など、プランニングプロセスの重要な側面で貢献することができます。しかし、最終的な計画の正確性や実行可能性の保証は、他のシステムや人間の監督に依存する必要があることが強調されました。
教授は、今後の研究方向として、LLMsの限界を克服するための新しいアプローチの開発や、LLMsとプランニングの他のコンポーネントとのより効果的な統合方法の探求が重要になると指摘しました。また、実世界の複雑な問題に対するLLMsの適用可能性をさらに調査することの必要性も述べられました。
最後に、カンブハンパティ教授は、LLMsのプランニングにおける役割に関する研究がまだ初期段階にあることを指摘し、この分野に多くの挑戦と機会が存在することを強調しました。教授は、批判的思考と創造的なアプローチを組み合わせることで、LLMsの真の価値を引き出し、プランニングの分野に革新をもたらすことができると締めくくりました。
このチュートリアルは、LLMsとプランニングの関係についての理解を深め、今後の研究や実践の方向性を示す重要な貢献となりました。