GPT-4 だけが自己改善可能、GPT-3.5 はできない、MIT と Microsoft のコード生成実験で新たな発見

大規模言語モデル (LLM) は、自然言語からコード スニペットを生成できることが示されていますが、専門的なコンテストやソフトウェア エンジニアリングの専門家の面接などの複雑なコーディングの課題を処理するには、依然として大きな課題があります。最近の研究では、自己修復を活用してモデルのエンコード性能を向上させる試みがなされています。自己修復とは、モデルが自身のコード内のエラーを反映して修正できるようにすることです。

下の図 1 は、自己修復アプローチに基づく一般的なワークフローを示しています。まず、仕様が与えられると、コード生成モデルからプログラムがサンプリングされます。次に、仕様の一部として提供される一連の単体テストでプログラムが実行されます。プログラムがいずれかの単体テストで失敗した場合、エラー メッセージと問題のあるプログラムがフィードバック生成モデルに送られ、コードが失敗した理由の簡単な説明が出力されます。最後に、フィードバックが修復モデルに渡され、プログラムの最終的な修正バージョンが生成されます。

表面的には、これは非常に魅力的なアイデアです。この設計により、システムはデコード プロセス中に外れ値のサンプルによって発生するエラーを克服できます。修復フェーズでは、コンパイラ、静的解析ツール、実行エンジンなどのシンボリック システムからのフィードバックを簡単に統合し、人間のソフトウェア エンジニアがコードを記述する際の試行錯誤の方法を模倣できます。

写真

ただし、自己修復にはより多くのモデル呼び出しが必要となり、計算コストが高くなります。自己修復が機能するかどうかは、最終的には、同じ計算パフォーマンス バジェット内でモデルからより多くのコード サンプルを抽出し、それらをタスクの一部として提供される単体テスト スイートと比較できるかどうかにかかっていることに注意することが重要です。

重要なのは、自己修復の有効性は、モデルのコード生成能力（文献で広範に研究されている）だけでなく、（モデル自体によって生成された）コードがタスク仕様に対してどのように間違っているかを識別する能力にも依存するということです。これまで、これらの能力の影響を詳細に調査しようとした研究はありませんでした。

この論文では、MIT と Microsoft Research の研究者が GPT-3.5 と GPT-4 を使用して、競技レベルのコード生成タスクを解決する際の自己修復の有効性を研究しています。まず、 pass@t と呼ばれる新しい評価戦略を提案します。この戦略では、(特定のユニットテストに対して) 正しいプログラムを取得する確率が、モデルからサンプリングされたトークンの総数に応じて重み付けされます。

従来の pass@k メトリック (試行回数に基づいて合格率を測定する) の代わりに新しい評価戦略を使用することで、研究者は、自己修復によって得られたパフォーマンスと、モデルがフィードバックを生成して修復を行う際に行った追加作業とを正確に比較することができます。研究者たちは、さまざまなハイパーパラメータの下での動的な自己修復プロセスを注意深く調査しました。

最後に、私たちの研究の主な目的は、最先端のコード生成モデルが独自のコードをイントロスペクトしてデバッグする能力についての洞察を得ることであるため、フィードバック フェーズを単独で改善した場合の影響を調査するための一連の実験を実施します。研究者らは、コード生成モデルよりも強力なフィードバック生成モデル（GPT-4を使用してGPT-3.5コードモデルのフィードバックを生成する）を使用することの影響を分析し、モデルによって生成された自己フィードバックと人間が提供する自己フィードバックを比較するために、人間が誤ったプログラムにフィードバックを提供する研究を実施しました。

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

この記事の実験から、研究者たちは次のことを発見しました。

1. 検査と修復を実行するコストを考慮すると、自己修復のパフォーマンス向上は GPT-4 でのみ測定可能です。GPT-3.5 の場合、修復の合格率は、すべての構成でベースライン モデル/修復なしの方法の合格率以下になります。

2. GPT-4の場合でも、パフォーマンスの向上はわずかであり（7000トークンの予算と約45の独立した同一に分布した（iid）GPT-4サンプルで66％→71％の合格率）、初期プログラムに十分な多様性があるかどうかに依存します。

3. GPT-3.5 のエラーの説明を GPT-4 によって生成されたフィードバックに置き換えると、自己修復パフォーマンスが向上し、ベースラインの修復されていない GPT-3.5 アプローチを上回ります (7000 トークンで 50% → 54%)。

4. GPT-4 自身の説明を人間の説明に置き換えると、修復結果が大幅に改善され、テストに合格する修復プログラムの数が 57% 増加します。

エディンバラ大学の博士課程の学生である Fu Yao 氏は、次のように述べています。「GPT-4 だけが自己改善でき、より弱いモデルは自己改善できないという発見は非常に興味深く、新しいタイプの出現能力 (つまり、自然言語フィードバックの改善) は、モデルが十分に成熟している (大規模で整然としている) 場合にのみ存在する可能性があることを示唆しています。大規模モデルのこの能力は、「AI フィードバックからのセルフプレイとコンテキスト内学習による言語モデル交渉の改善」という論文でも確認されています。」

十分に成熟したモデルだけが自然言語のフィードバックを聞いて改善することができますが、成熟度の低いモデルはフィードバックを理解できないか、フィードバックを改善することができません。

この新たな能力（言語的フィードバックによる自己改善）は、AI が人間の監督をほとんど受けずに自律的に改善し続けることができることを意味するため、LLM 研究にとって非常に重要な意味を持つと私は考えています。 「

写真

方法

自己修復の概要

上の図 1 に示すように、自己修復方式には、コード生成、コード実行、フィードバック生成、コード修復の 4 つの段階が含まれます。次に、これら 4 つの段階を正式に定義します。

コード生成

仕様ψが与えられると、プログラムモデルM_Pはまずn_p個の独立かつ同一分布のサンプルを生成する。研究者はこれを次のように表現する。

写真

コード実行

これらの n_p コード サンプルはテストベンチで実行されます。研究者たちは、実行可能な形式でテストの完全なセットにアクセスできるため、いずれかのサンプルがすべてのテストに合格すると、満足のいくプログラムが見つかったため、システムが停止すると想定しました。それ以外の場合、システムは実行環境から返されたエラー メッセージを収集します。これらのエラー メッセージには、コンパイル/ランタイム エラー メッセージ、またはプログラム出力が予想される出力と異なるサンプル入力が含まれます。例を図 1 (コンポーネント 3) に示します。

フィードバック生成

実行環境からのエラー メッセージは通常非常に高レベルであるため、修復のためのシグナルはほとんど提供されません。中間ステップとして、研究者はフィードバック モデルを使用して、何が間違っていたのかをより詳しく説明しました。例を図 1 (コンポーネント 4) に示します。正式には、この段階で、次のように、障害のあるプログラム p_i ごとに n_f 個のフィードバック文字列が生成されます。

明示的なフィードバック生成ステップを使用すると、このコンポーネントを分解して、その重要性を個別に調査することが可能になります。

コード修正

最後のステップでは、各初期プログラム p_i とフィードバック f_ij に対して、次から n_r 個の候補修復プログラムをサンプリングできます。

木を修復します。研究者たちは、このプロセスによって生成されたテキストとプログラムを含むツリーを ψ と呼んでいます。このツリーは仕様をルートとして初期プログラム p_i に分岐し、各初期プログラム p_i はフィードバック f_ij に分岐し、次に修復ツリー r_ijk を修復します (下の図を参照)。

注: サンプリング フィードバックと修正を組み合わせました。上記の一般的なフレームワークでは、プログラミング モデルとフィードバック モデルが同じである必要はないため、2 つのモデルはそれぞれ独自のモデルを使用できます。ただし、M_P = M_F の場合、GPT-3.5 と GPT-4 はどちらも応答にテキストとコードを織り交ぜる自然な傾向があるため、1 回の API 呼び出しでフィードバックと修復プログラムを共同で生成します。研究者らは正式には次のように表現した。

写真

pass@t: 合格率とトークン量の関係

自己修復には、コストが均一でない複数の依存モデル呼び出しが必要であるため、k 個の独立した同一に分布したサンプルの中から正しいプログラムを取得する確率である pass@k は、自己修復のためのさまざまなハイパーパラメータの選択を比較および評価するための適切なメトリックではありません。代わりに、モデルからサンプリングされたトークンの総数の関数として合格率を提示し、これを pass@t と呼びます。

正式には、データセット D = {ψ_d}_d とハイパーパラメータ (M_P、M_F、n_p、n_f、n_r) に選択された値のセットを想定します。前述のように、サンプリングタスク ψ_d の修復ツリーを表します。size(T^i_d) は修復ツリー内のプログラムとフィードバックトークンの合計数を表します。また、T^i_d 内の少なくとも 1 つのリーフプログラムが仕様内の単体テスト ψ_d を満たす場合にのみ、T^i_d |=ψ_d が真となります。このハイパーパラメータ選択の pass@t メトリックは、このハイパーパラメータ選択で生成されると予想されるトークンの数を与えられたときの予想合格率として定義されます。

実験では、これら 2 つの量のブートストラップ推定値 (パラメータ推定値の不確実性を評価するためによく使用される統計的推定方法) をプロットします。これらの値を取得するには、まず各タスク仕様に対して非常に大きな修復ツリーを生成します。ここで、N_p ≥ n_p の初期プログラム サンプルがあり、各障害プログラムには N_f ≥ n_f のフィードバック文字列があり、各フィードバック文字列には N_r ≥ n_r の修復候補があります。 (n_p、n_f、n_r) のセットが与えられた場合、この凍結されたデータセットから N_t 個の異なる修復ツリーを (置換により) サブサンプリングします。最後に、この論文では、これらの N_t ツリーの合格率とツリー サイズのサンプル平均と標準偏差を計算します。このように pass@t を推定すると、同じ初期データセットを再利用して n_p、n_f、n_r のさまざまな選択肢に対する推定値を計算できるため、実験の計算コストが大幅に削減されます。

この論文のすべての実験では、自己修復法では N_p=50、n_p≤25、ベースラインの非修復法では n_p≤50 でした。同様に、フィードバックについては、N_f=25、N_f≤10 に設定します。候補修復については、ほとんどの実験でフィードバックと修復を共同でサンプリングするため、N_r=n_r=1 に設定します。最後に、すべての設定に N_t=1000 を使用します。

実験

研究者たちは以下の質問について実験を行った。

(a) 困難なプログラミング問題の文脈において、提案されたモデルの場合、自己修復は修復なしの独立した同一分布のサンプリングよりも優れているか?もしそうなら、どのようなハイパーパラメータで自己修復が最も効果的でしょうか?

(b) フィードバックモデルを強化すると、モデルの修復パフォーマンスは向上しますか?

(c) 最も強力なモデルの場合でも、フィードバックの提供に人間が関与すると修復のパフォーマンスが向上するのでしょうか?

この論文では、APPS データセットを使用して、Python プログラミングの課題に関するこれらの疑問を評価します。

自己修復には強力なモデルと多様な初期サンプルが必要

M_P = M_F∈{GPT-3.5, GPT-4}とします。ここで、コード/修復生成とフィードバック生成に同じモデルが使用されます。 GPT-3.5 の結果を図 3 に、GPT-4 の結果を図 4 に示します。

図からわかるように、GPT-3.5 モデルの場合、選択されたすべての n_p および n_fr の値に対して、pass@t は対応するベースライン (黒線) 以下であり、自己修復は GPT-3.5 にとって効果的な戦略ではないことが明確に示されています。一方、GPT-4では、自己修復の合格率がベースラインよりも大幅に優れているn_p、n_frの値がいくつかあります。たとえば、n_p=10、n_fr=3 の場合、合格率は 65% から 70% に増加し、n_p=25、n_fr=1 の場合、合格率は 65% から 71% に増加します。

GPT-4からのフィードバックによりGPT-3.5の自己修復機能が向上

次に、フィードバックを生成するために別の強力なモデルを使用することの影響を評価する実験を行います。これは、モデルが独自のコードをイントロスペクトしてデバッグできないことが自己修復を妨げるという仮説をテストするためでした (特に GPT-3.5)。

この実験の結果は図 5 (明るい青線) に示されています。研究者らは、絶対的なパフォーマンスの点では、M_P=GPT-3.5、M_F=GPT-4 がパフォーマンスの壁を突破し、GPT-3.5 の独立した同一に分散されたサンプリングよりもわずかに効率的になったことを観察しました。これは、フィードバック段階が重要であり、これを改善することで GPT-3.5 自己修復のボトルネックを軽減できることを示唆しています。

人間のフィードバックによりGPT-4の自己修復の成功率が大幅に向上

論文の最後の実験では、研究者らは、GPT-4などのより強力なモデルを使用して修復を実行する際に、熟練した人間のプログラマーからのフィードバックを使用することの効果を考慮しました。この研究は、ヒューマン・イン・ザ・ループ・アプローチと自己修復アプローチを直接比較することを目的としたものではありません。ヒューマン・イン・ザ・ループ・アプローチでは認知負荷が大きくなりますが、この論文ではその点については調査していません。代わりに、この論文の目的は、コード内のバグを識別するモデルの能力が人間とどのように比較されるか、そしてこれが自己修復の下流のパフォーマンスにどのように影響するかを理解することです。そこで本研究では、人間からのフィードバックが自己修復に与える影響について定性的および定量的な分析を行った。

結果は表1にまとめられています。まず、GPT-4 自身のデバッグを人間の参加者によるデバッグに置き換えると、全体的な成功率が 1.57 倍以上向上することに気づきました。おそらく驚くことではないが、問題が難しくなるにつれて相対的な差は大きくなり、タスク（およびコード）が複雑になるにつれて、正確で有用なフィードバックを生成する GPT-4 の能力は人間の参加者よりはるかに遅れていることを示唆しています。

さらに、この研究では、人間の参加者が提供するフィードバックと GPT-4 が提供するフィードバックの違いを定性的に分析しました。

• 80 人中 2 人だけが、疑似コードまたは明示的な Python を含むフィードバック文字列を提供しました。つまり、得られた人間のフィードバックのほぼすべてが自然言語であり、時折単一ステートメントの数式/コード式が散在していました。
• GPT-4 のフィードバックは、大幅に不正確になる可能性が高かった (人間のフィードバックでは 32/80 に対して 7/80)。
• GPT-4 は小さな変更を明示的に提案する傾向が強かった (正しく見えた場合、54/80 対 42/80、28/48 対 38/73) 一方、人間の参加者は高レベルの変更を提案する傾向が強かった (正しく見えた場合、23/80 対 18/80、GPT-4、21/73 対 13/48)。
• 人間の参加者は時々不確実性を表明しましたが (7/80)、GPT-4 はそうではありませんでした (0/80)。

さらに分析を進めると、表 1 の結果は、参加者がモデルから単純にコピーした明示的なコード ブロックを提供するなどのアーティファクトによるものではないことが示されました。むしろ、パフォーマンスの違いは、より正確なフィードバック、必要に応じてコードに高レベルで大規模な変更を提案する能力の高さ、参加者が不確実性を表現する能力（不正確な可能性のあるフィードバックを自信を持って与えるのではなく）の組み合わせによって生じたものと思われます。