Google: LLM は推論エラーを見つけられないが、修正できる

今年、人工知能の分野では大規模言語モデル (LLM) が大きな注目を集めています。 LLM は、さまざまな自然言語処理 (NLP) タスク、特に推論において大きな進歩を遂げました。ただし、複雑な推論タスクにおける LLM のパフォーマンスはまだ改善の必要があります。

LLM は、自身の推論にエラーがあると判断できますか?ケンブリッジ大学と Google Research が共同で実施した最近の研究では、LLM が独自に推論エラーを検出することはできなかったものの、研究で提案されたバックトラッキング手法を使用してそれらを修正できたことが判明しました。

##論文アドレス: https://arxiv.org/pdf/2311.08516.pdf

• #データセットのアドレス: https://github.com/WHGTyen/BIG-Bench-Mistake
• この論文はいくつかの論争を引き起こしました。これについて何人かの人々がコメントしました。異議を唱えてください。たとえば、Hacker News では、論文のタイトルが誇張されており、少しクリックベイトであると誰かがコメントしました。この論文で提案されている論理エラーを修正する方法は、論理的手法を使用するのではなく、パターン マッチングに基づいていると批判する人もいます。この方法は失敗しやすいです。

Huang et al. in the Paper 「「大規模な言語モデル」は推論をまだ自己修正できません」は次のように指摘しています: 自己修正はモデル出力のスタイルと品質を改善するのに効果的かもしれませんが、LLM が独自の推論と論理を識別して修正する能力があるという証拠はほとんどありません。外部フィードバックなしのエラー。たとえば、Reflexion と RCI はどちらも、自己修正サイクルを停止する信号としてグラウンド トゥルースの修正結果を使用します。

#ケンブリッジ大学と Google Research の研究チームは、自己修正プロセスをエラー発見と出力修正の 2 つの段階に分割するという新しいアイデアを提案しました。

エラー検出は、哲学、心理学、数学の分野で広く研究および応用されている基本的な推論スキルであり、批判的思考、論理的および数学的誤謬などの概念を生み出してきました。エラーを検出する機能も LLM の重要な要件であると考えるのが合理的です。ただし、私たちの結果は、最先端の LLM が現時点でエラーを確実に検出できないことを示しています。

• 出力修正には、以前に生成された出力の部分的または完全な変更が含まれます。自己修正とは、出力を生成したのと同じモデルによって修正が行われることを意味します。 LLM にはエラーを検出する機能はありませんが、この論文では、エラーに関する情報が (小規模な教師あり報酬モデルなどを通じて) 提供される場合、LLM はバックトラッキングを使用して出力を修正できることを示しています。
• この記事の主な貢献内容は次のとおりです。

思考チェーン プロンプト設計手法を使用すると、あらゆるタスクを間違い発見ミッション。この目的のために、研究者らは、PaLM によって生成され、最初の論理エラーの位置をマークした CoT タイプの軌道情報データセット BIG-Bench Mistake を収集し、公開しました。研究者らは、BIG-Bench Mistake は数学的問題に限定されないこの種の最初のデータセットであると述べています。

• 現在の最先端の LLM の推論機能をテストするために、研究者たちは新しいデータセットに基づいて LLM のベンチマークを実施しました。現在の SOTA LLM では、たとえ客観的で明らかなエラーであっても、エラーを検出することが困難であることが判明しました。彼らは、LLM が推論エラーを自己修正できない主な理由は、LLM がエラーを検出できないことであると推測していますが、この点についてはさらなる研究が必要です。
• この記事では、バックトラッキング手法を使用して出力を修正し、間違った位置情報を使用して元のタスクのパフォーマンスを向上させることを提案します。研究によると、この方法では、正しい出力への影響を最小限に抑えながら、正しくない出力を修正できることがわかっています。
• この記事では、重みを更新せずに CoT 出力の反復改善を達成できる「言語強化学習」の形式としてのバックトラッキング手法について説明します。研究者らは、訓練された分類子を報酬モデルとして使用することでバックトラッキングが使用できることを提案し、また、さまざまな報酬モデル精度の下でのバックトラッキングの有効性を実験的に実証しました。
• BIG-Bench 間違いデータセット

BIG-Bench には、CoT スタイルを使用した 2186 個の軌道情報セットが含まれています。各軌道は PaLM 2-L-Unicorn によって生成され、最初の論理エラーの位置に注釈が付けられました。表 1 は、ステップ 4 でエラーが発生する軌跡の例を示しています。

これらの軌跡は、BIG-Bench データセット内の 5 つのタスクからのものです。並べ替え、シャッフルされたオブジェクトの追跡、論理的推論、複数ステップの算術、および Dyck 言語。

各タスクの質問に答えるために、CoT プロンプト設計手法を使用して PaLM 2 を呼び出しました。 CoT の軌跡を明確なステップに分離するために、「React: 言語モデルにおける推論と動作の相乗化」で提案されている方法を使用して、各ステップを個別に生成し、改行を停止マーカーとして使用しました

このデータセットで温度 = 0 のときにすべての軌跡が生成されると、答えの正しさは完全一致によって決まります

ベンチマーク結果

新しいバグ発見データセットで報告されている GPT-4-Turbo、GPT-4、および GPT-3.5-Turbo の精度を表 4

に示します。

各質問には、正解か不正解かの 2 つの答えが考えられます。エラーの場合、値 N は最初のエラーが発生したステップを示します。

すべてのモデルは同じ 3 つのプロンプトで入力されました。彼らは 3 つの異なるプロンプト設計方法を使用しました。

ダイレクト トラック レベル プロンプト デザイン
ダイレクト ステップ レベル プロンプト デザイン プロンプト デザイン
CoT ステップレベル プロンプトの設計

書き直す必要がある内容は次のとおりです: 関連するディスカッション

結果は、3 つのモデルすべてがこの新しいエラー発見データセットに対処するのに苦労していることを示しています。 GPT は最高のパフォーマンスを発揮しますが、直接ステップレベルのプロンプト設計では全体の精度は 52.87 しか達成できません。

これは、現在の最先端の LLM が、たとえ最も単純で明確なケースであっても、エラーを見つけるのが難しいことを示しています。対照的に、人間は特別な専門知識がなくても、高い一貫性を持ってエラーを見つけることができます。

研究者らは、LLM が推論エラーを自己修正できない主な理由は、LLM がエラーを検出できないことであると推測しています。

プロンプト設計手法の比較

研究者らは、直接軌道レベルのアプローチからステップへの移行が重要であることを発見しました。 -レベルのアプローチ CoT メソッドに移行すると、エラーが発生せずに軌道の精度が大幅に低下します。図 1 は、このトレードオフを示しています

#研究者らは、この理由はモデル出力の数にあるのではないかと考えています。 3 つのメソッドはすべて、ますます複雑な出力の生成を必要とします。軌道を直接生成するプロンプト設計メソッドには 1 つのトークンが必要で、ステップを直接生成するプロンプト設計メソッドにはステップごとに 1 つのトークンが必要で、CoT ステップレベルのプロンプト設計メソッドには各ステップに複数の文が必要です。ビルド呼び出しごとのエラー率にある程度の確率がある場合、トレースごとの呼び出しが増えるほど、モデルが少なくとも 1 つのエラーを識別する可能性が高くなります。

少数ショットエラー位置を正確さの代用として使用するプロンプト設計

研究者らは、これらのプロンプト設計方法がエラー位置ではなく軌道の正しさを確実に判断できるかどうかを調査しました。

彼らは平均 F1 スコアを計算しました。これは、モデルが軌道にエラーがあるかどうかを正しく予測できるかどうかに基づいています。エラーがある場合、モデルによって予測された軌道は「誤った答え」とみなされます。それ以外の場合は、モデルによって予測された軌跡が「正しい答え」とみなされます。

correct_ans と unavailable_ans を肯定的なラベルとして使用し、各ラベルの出現数に応じて重み付けを行って、研究者らは計算しました。平均 F1 スコアの結果を表 5 に示します。

この重み付けされた F1 スコアは、プロンプトを通じてエラーを探すことが、最終的な答えの正しさを判断するための戦略として不適切であることを示しています。

バックトラック

Huangらは、LLMは外部フィードバックがなければ論理エラーを自己修正できないと指摘した。ただし、現実世界の多くのアプリケーションでは、外部フィードバックが利用できないことがよくあります。この研究では、研究者らは代替案を採用しました: 少量のデータに外部フィードバックを使用するというものです。トレーニングされた軽量分類器が外部フィードバックを置き換えます。従来の強化学習の報酬モデルと同様に、この分類器は、出力を改善するためにジェネレーター モデルにフィードバックする前に、CoT 軌跡内の論理エラーを検出できます。改善を最大限に高めたい場合は、複数の反復を実行できます。

研究者は、論理エラーの位置をバックトラックすることでモデルの出力を改善する簡単な方法を提案しました。

• モデルはまず初期 CoT 軌道を生成します。実験では、温度 = 0 に設定します。
• 報酬モデルは、軌道内のエラーの位置を決定するために使用されます。
• エラーがない場合は、次のトラックに移動します。エラーがある場合は、同じ手順を実行するようモデルに再度プロンプトを出しますが、今回は温度 = 1 として、8 つの出力を生成します。ここでは、同じプロンプトが、エラーのあるステップの前のすべてのステップの部分的なトレースとともに使用されています。
• これらの 8 つの出力では、前のエラーと同じオプションをフィルターで除外します。次に、残りの出力から対数確率が最も高いものを選択します。
• 最後に、前のステップを新しい再生成されたステップに置き換え、温度 = 0 にリセットし、軌跡の残りのステップの生成を続けます。

以前の自己修正方法と比較して、このバックトラッキング方法には多くの利点があります。

• 新しいバックトラッキング方法には次のものが必要です。答えについての事前知識はありません。代わりに、論理エラーに関する情報 (トレーニングされた報酬モデルからの情報など) に依存します。論理エラーは、報酬モデルを使用して段階的に判断できます。論理エラーは、correct_ans 軌道に現れる場合もあれば、現れない場合もあります。
• バックトラッキング方法は、特定のプロンプト テキストや文言に依存しないため、関連する設定が減少します。
• 軌道全体の再生成を必要とする方法と比較して、バックトラッキング方法は、既知の論理的に正しいステップを再利用することで計算コストを削減できます。
• バックトラッキング手法は、中間ステップの品質を直接向上させることができ、正しいステップが必要なシナリオ (数学的問題の解を生成するなど) で役立つ可能性があると同時に、解釈可能性も向上します。

研究者らは、バックトラッキング手法が LLM の論理エラーの修正に役立つかどうかを調査するために、BIG-Bench Mistake データセットを使用した実験を実施しました。実験結果については表 6 を参照してください。

Δaccuracy✓ は、元の答えが正しい場合に設定された軌道を指します_ans 違い精度_ansの間。

不正解の軌跡の結果については、精度を再計算する必要があります

これらのスコア結果は、不正解の軌跡を修正する利点を示しています。元の正解を変更するよりも、引き起こされる損害に対して大きな影響を及ぼします。さらに、ランダム ベンチマークでも改善は得られますが、その改善は実際のエラー位置を使用した場合よりも大幅に小さくなります。ランダム化されたベンチマークでは、真のエラーの場所を見つける可能性が高いため、ステップ数が少ないタスクでパフォーマンスが向上する可能性が高くなります。

適切なラベルが利用できない場合にどの精度レベルの報酬モデルが必要であるかを調査するために、シミュレートされた報酬モデルによるバックトラッキングの使用を実験しました。このシミュレートされた報酬モデルの設計の目標は、さまざまな精度レベルのラベルを作成します。これらは、accuracy_RM を使用して、指定されたエラー位置におけるシミュレーション報酬モデルの精度を表します。

特定の報酬モデルの precision_RM が X% の場合、X% の確率で BIG-Bench Mistake のエラー位置を使用します。残りの (100 − X)% については、エラー位置がランダムにサンプリングされます。一般的な分類器の動作をシミュレートするために、データ セットの分布と一致する方法でエラー位置がサンプリングされます。研究者らはまた、サンプルの間違った位置が正しい位置と一致しないことを確認する方法も発見した。結果を図 2 に示します。

#損失率が 65% に達すると、Δ 精度が安定し始めることがわかります。実際、ほとんどのタスクでは、accuracy_RM が約 60 ～ 70% のときに、Δaccuracy ✓ がすでに Δaccuracy ✗ を超えています。これは、精度が高いほど結果は良くなりますが、ゴールドスタンダードのエラー位置ラベル がなくてもバックトラッキングは機能することを示しています。

以上がGoogle: LLM は推論エラーを見つけられないが、修正できるの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。