DeepMind: ビッグモデルのもう一つの大きな欠陥は、正しい答えが事前にわかっていなければ推論を自己修正できないことだ。

大規模言語モデルのもう一つの重大な欠陥が DeepMind によって明らかにされました。

LLM は自身の推論における誤りを修正することはできません。

「自己修正」とは、モデルが自らの回答を修正できるようにする技術です。多くの種類のタスクにおいて、モデルの出力品質を大幅に向上させることができます。

しかし最近、Google DeepMindとUIUCの研究者らは、推論タスクにおいてはLLMの「自己修正メカニズム」が突然役に立たなくなることを発見した。

写真

さらに、LLM は推論タスクに対する回答を自己修正できないだけでなく、頻繁に自己修正すると回答の質も大幅に低下します。

マーカス氏は、大規模言語モデルのこの欠点にもっと多くの研究者の注意を引くことを期待して、この論文を転送しました。

写真

「自己修正」テクノロジーは、LLM が特定の基準に従って生成したコンテンツを修正および改善できるようにするという単純なアイデアに基づいています。この方法により、数学の問題などのタスクにおけるモデルの出力品質が大幅に向上します。

しかし研究者たちは、推論課題においては、自己修正後のフィードバックが非常に良い場合もあれば、効果が非常に悪い場合もあり、パフォーマンスが低下する可能性さえあることを発見した。

写真

研究者らは、「自己修正」によって推論出力が向上すると信じる文献も研究した。綿密な調査の結果、「自己修正」の向上は、モデルが自己修正するように導く外部情報の導入によるものであることがわかった。外部情報が導入されない場合、これらの改善は消えてしまいます。

写真

具体的には、モデルがベンチマーク データセットに含まれる真実のラベルにアクセスできる場合に、自己修正が効果的に機能します。

これは、アルゴリズムが推論プロセスをいつ停止するかを正確に判断し、答えがすでに正しい場合はその答えを変更することを回避できるためです。

研究者らは、これまでの研究では、モデルが正解を間違った答えに変えてしまうのを防ぐために、真のラベルがよく使われてきたと考えている。しかし、このような「間違ったことを修正する」という事態をいかに防ぐかが、実は自己修正を成功させる鍵なのです。

研究者が自己修正プロセスから真のラベルを削除したところ、モデルのパフォーマンスが大幅に低下したためです。

研究者らは、推論タスクにおける LLM の自己修正方法を改善する試みとして、推論を改善する手段としての「マルチエージェント討論」の可能性も調査しました。しかし、彼らの結果は、同じ数の回答を考慮した場合、このアプローチは自己一貫性よりも優れたパフォーマンスを発揮しないことを示唆しています。

写真

研究者らはさらに、「事前プロンプト」と「事後プロンプト」という概念を提唱した。

彼らは、自己修正を事後プロンプトの一形態とみなし、修正プロンプトは LLM の応答後に入力されると考えました。

研究者の分析によると、一部のタスクにおける自己修正能力の向上は、粗雑な最初の手がかりを隠すように注意深く作成されたフィードバック手がかりによってもたらされる可能性があるという。

この場合、最初の指示に優れたフィードバックを統合したり、最初のプロンプトをより適切に設計したりすると、より良い結果が得られ、推論コストが削減される可能性があります。

研究者らは、LLM の自己修正機能の微妙な差異に関する洞察を提供する研究結果に基づき、研究コミュニティに対し、自己修正の研究にさらに厳密なアプローチを取るよう促している。

大規模言語モデルは推論を自己修正できますか?

研究者らは、既存の自己修正方法を適応させ、その設定（ラベルを使用して自己修正プロセスをガイドする）を採用して、LLM推論タスクのパフォーマンスを向上させる効果を調べようとしました。

実験のセットアップ

プロンプトワード

研究者たちは、自己修正のために3段階の促し戦略を使用しました。

1) モデルに初期生成を実行するように指示します (これも標準プロンプトの結果です)。

2) モデルに前の世代を振り返ってフィードバックを生成するように促す。

3) フィードバックを通じて、モデルに元の質問に再度答えるように促します。

モデル

研究者の主なテストは GPT-3.5-Turbo で実施されました。

研究者らはまた、2023年8月29日にアクセスされたGPT-4のテストも実行し、OpenAIモデルの最新かつ最も強力な反復の自己修正機能をテストするように設計されました。

GPT-3.5 の場合、研究者は前述の完全な評価セットを使用しました。 GPT-4 の場合、コストを削減するために、研究者は各データセットに対して 200 の質問 (HotpotQA の場合は 100 の質問) をランダムに選択してテストを行いました。

結果と考察

写真

研究者らは実験で外部のリソースやツールを一切利用しなかったが、グラウンドトゥルースラベルを使用して自己修正ループをいつ停止するかを決定するという過去の研究に従っている。

しかし、現実の世界では、特に研究者が LLM を使用して数学の問題を解決しようとする場合、ほとんどの場合、正しい答えがわかりません。

したがって、パフォーマンスの向上にはより慎重な検討が必要です。

この考えを確認するために、研究者たちはランダムな推測に基づいたベースラインを設計しました。このベースラインでは、研究者はグラウンドトゥルースラベルを使用して停止時期を決定し続けました。ただし、LLM によって修正アクションが実行されず、残りのオプションのランダムな推測に基づいて修正アクションが実行されました。

CommonSenseQA は、各質問に対して 5 つの候補オプションを提供する複数選択質問データセットです。

ラウンドk（初期世代はラウンド0）の生成精度をxとすると、後続の世代の期待精度はx + (1 − x)/(5 − k)となる。

写真

上記の表 2 に、このランダム ベースラインの結果を示します。

2 ラウンド後には、そのパフォーマンスは自己修正と同等かそれ以上になり、4 ラウンド後には精度が 100% に達します。

しかし、このようなランダムなベースラインは有効な補正方法とはみなされないことは明らかです。それでも、ラベルを使用して得られた結果は、答えの正しさを判断できる完璧な検証者が存在することを示す神託として機能する可能性があります。

これは、コード生成などのタスクでは実現可能であり、研究者はエグゼキュータと単体テストを活用して、生成されたコードが正常に実行されるかどうかを判断できます (Chen et al.、2023b)。

しかし、数学の問題を解くなどの推論タスクの場合、この設定は直感に反しているように思われます。研究者がすでに真実を知っているのであれば、問題を解決するために LLM を使用する理由はないと思われます。

内部の自己修正

GSM8K の場合、同様のランダム ベースラインは存在しない可能性がありますが、基本原理は同じです。

あるいは、研究者は、毎回乱数を生成するなどのベースラインを設計することもできます。かなりの回数の試行錯誤を経て、正しい答えが得られるかもしれませんが、そのような改善は明らかに無意味です。もっと直接的な理由は、研究者がすでに答えを知っているのなら、なぜこれをやるのでしょうか?

実験の設定は上記で定義したとおりです。これを達成するために、研究者は、いつ停止するかを決定するためのラベルの使用を単純に削除し、2 回の自己修正を通じてパフォーマンスを評価しました。

写真

上記の表 3 は、モデル呼び出しの精度と回数を示しています。研究者らは、自己修正後、すべてのベンチマークでモデルのパフォーマンスが低下したことを観察した。

なぜパフォーマンスが低下したのでしょうか?

写真

上の図 1 は、GPT-3.5 を使用して 2 ラウンドの自己修正を行った後の回答変更の結果をまとめたものであり、下の図 2 に 2 つの例を示します。

写真

GSM8K の場合、モデルは 74.7% の確率で初期の回答を保持します。残りの例では、モデルは、誤った回答を正しい回答に修正するよりも、正しい回答を誤った回答に修正する可能性が高くなりました。

CommonSenseQA の場合、GPT-3.5 は回答を変更する可能性が高くなります。その主な理由は、CommonSenseQA の誤った回答オプションは質問に多少関連しているように見えることが多く、自己修正ヒントを使用するとモデルが別のオプションを選択するようにバイアスがかかり、「正解⇒誤答」の比率が高くなる可能性があるためです。

研究者たちは、上の表 1 に示されている結果をもう一度見てみましょう。これらの結果では、モデルが正解を不正解に変更するのを防ぐために、グラウンド トゥルース ラベルが使用されています。

しかし、このような「修正エラー」の発生をいかに防ぐかが、実は自己修正を成功させる鍵なのです。

直感的な説明としては、モデルが慎重に設計された初期キューに一致している場合、そのキューと特定のデコード アルゴリズムが与えられれば、初期応答はすでに最適であるはずだということです。

フィードバックを導入することは、その組み合わせた入力に適した応答を生成するようにモデルを偏らせる可能性のある追加の手がかりを追加することと見なすことができます。

本質的な自己修正の設定では、このような補足的な手がかりは推論タスクにおける質問に答える際に追加の利点をもたらさない可能性があります。

実際、モデルが最初のプロンプトに対して最適な応答を生成できなくなり、パフォーマンスが低下する可能性もあります。

研究者がテストした自己修正の手がかりは最適ではないのだろうかと疑問に思う人もいるかもしれない。

パフォーマンスを向上させるための他のヒントはありますか?答えは、研究者が特定のベンチマークでモデルのパフォーマンスを向上させるヒントを見つけることは完全に可能だということです。しかし、これは、この論文で議論されている本質的な自己補正設定とは一致しなくなり、真の少数ショット設定の議論に似ています。

この検索で​​は、基本的に人間からのフィードバックやトレーニング例を活用します。さらに、同じ戦略を効果的に適用して初期プロンプトを最適化することもでき、自己修正のための追加のモデル呼び出しを必要とせずに、より優れたパフォーマンスを実現できる可能性があります。

付録 B では、研究者はさまざまなプロンプトをテストしましたが、パフォーマンスは依然として向上しないことが分かりました。

写真

さらに、自己修正が必ずしも LLM 推論能力を向上させるわけではないことを観察したのは研究者が初めてではない。要約すると、研究者の焦点は、「特定のベンチマークでパフォーマンスを向上させることができる自己修正の手がかりはあるか？」などの質問に答えることではありませんでした。このようなクエリは特に意味がない可能性があります。

代わりに、研究者たちはより根本的な疑問、「大規模言語モデルは、その固有の能力のみに基づいて推論を本当に自己修正できるのか？」に取り組むことを目指しました。

イベント後のリマインダーとしての自己修正

これまで研究者らは、LLM が推論を自己修正する際に課題に直面していることを観察してきました。

しかし、これまでの研究が実証しているように、自己修正は特定の状況下では目覚ましい成果を生み出してきました。

したがって、違いを特定し、根本的な原因を正確に特定することが重要です。

この問題に対処するには、自己修正の基本的な性質を把握することが重要です。自己修正は、その形式に応じて、事後プロンプトと見なすことができます。

これは、プロンプトが LLM の回答の上に提示されるという点で、標準プロンプト (ここでは事前プロンプトと呼びます) とは異なります。

研究者たちは、このような手がかりを改善するプロセスをポスト手がかりエンジニアリングと呼んでいます。

したがって、自己修正がモデル応答を強化する状況は、事前のプロンプトでは提供できなかった貴重なガイダンスやフィードバックを自己修正が提供できる場合に発生します。

たとえば、応答をより安全にすることが目標である場合、事前の手がかりのみを使用して最初の試行で完全にリスクのない応答を生成するようにモデルに指示するのは難しい場合があります。この文脈では、自己修正は、きめ細かい事後検証を通じて対応の安全性を高める手段として機能します。

ただし、推論タスクの場合はそうではない可能性があります。

「あなたの以前の回答を確認しましたが、回答に問題が見つかりました。」などのフィードバックプロンプト。必ずしも推論に具体的な利益をもたらすわけではありません。

さらに、自己修正後に大幅なパフォーマンスの改善が見られる場合でも、プロンプト設計を慎重に検討する必要があります。

たとえば、応答が最初の指示で簡単に指定できる基準を満たす必要がある場合 (たとえば、出力に特定の単語が含まれている必要がある、生成されたコードは効率的である必要がある、感情は強く否定的である必要がある)、これらの要件を事後プロンプトでフィードバックとして提供するのではなく、これらの要件を事前プロンプトに直接 (明示的に) 埋め込む方がコスト効率の高い代替戦略になります。

写真

上記の表 5 の結果は、研究者が慎重に設計したプロンプト「標準プロンプト (研究者用)」が、以前の研究の自己修正結果よりも優れていることを示しています。

さらに、研究者がヒントを活用して研究者の成果を向上させた場合でも、パフォーマンスは低下しました。

繰り返しますが、ここでの研究者の目的は、研究者が適当に書いたプロンプトよりも優れた事後プロンプトが存在するかどうかを議論することではありません。研究者の主な目標は、自己修正実験のより厳密な検討を促すことです。

質の悪い事前キューによって生成された応答をモデルが「自己修正」するように導くために、慎重に作成された事後キューを使用するのは意味がありません。

公平な比較を行うには、事前キューと事後キューの両方に同等の労力を費やす必要があります。

参考文献:

https://arxiv.org/abs/2310.01798