プログラムトレースプロンプティングで機械学習の説明を強化する

最近の研究で、Chain of Thought（CoT）と呼ばれる機械学習モデルのための新しいプロンプト手法が注目を集めている。この方法は、モデルが自分の推論を明確なステップに分解することで、より良い説明を提供するのを助ける。私たちは、この方法の新しいバージョンを提案しており、CoTの利点を保ちながら、これらのステップをさらに明確にすることを目指している。Pythonプログラミングに基づく半形式的アプローチを用いて、各推論ステップを特定し、名前を付け、各ステップがどのような入力と出力を持つべきかを定義し、従来のCoTの説明をこれらの構造化されたステップに置き換える方法を提示する。

この新しい方法はさまざまなタスクで効果的であり、23の異なる課題で印象的な結果を達成している。このように説明を整理することで、新たな分析の扉が開かれる。私たちの重要な発見の一つは「非局所的エラー」の特定である。これらのエラーは、モデルが学習した例に示された推論アプローチを誤解したときに発生する。また、CoT説明における各ステップがどれだけモジュール（または独立）であるかを確認する方法も提供する。

CoTプロンプトは効果的であることが示されているが、その出力は時々誤解を招くことがある。たとえば、モデルが見かけ上もっともらしい説明を生成することがあるが、それが誤った結論やバイアスのかかった出力につながることがある。これらの信頼性のない説明は、ユーザーが期待するステップバイステップの推論プロセスと一致しないかもしれない。信頼性のない説明はモデルの基本的な機能には影響しないが、ユーザーへの正当化を提供するためのCoTの有用性を制限する。信頼性のなさを検出することは難しく、CoT説明は多くの形式を取ることができる。

この論文の目的は、CoT説明をその強みを失うことなく分析しやすくすることである。これを実現するために、私たちはCoTデモを構造的に整理するCoTプロンプティングの変種を導入している。各デモはステップを特定し、その動作を定義し、説明を明確な形式化されたアクションの連鎖に置き換える。

私たちは、BIG-Bench Hardベンチマークからの簡略化されたタスクを使用してこの方法の例を提供する。このプロセスは、問題解決戦略を表すPythonに似たプログラムのトレースから始まる。そのトレースは、サブルーチンの概要を示すテンプレートのセットに配置され、プログラムがどのように機能するかを示すフレームワークを作成する。テスト入力が提供され、モデルにこの構造化された形式に基づいて出力を予測するように求められる。

このアプローチでは、ステップを明示的に表現するためにPython構文を使用し、この方法をプログラムトレースプロンプティング（PTP）と呼ぶ。この方法では、CoTデモはプログラムのドキュメントと、例の入力でプログラムがどのように動作するかを示すトレースに置き換えられる。各ステップはPythonのサブルーチンにリンクされ、コメントや型シグネチャで文書化される。モデルはこの情報をコンテキストとして促され、予測出力が得られる。

重要なのは、トレースが示すプログラムは、純粋なPython形式では存在しないことが多い。より複雑な例では、さまざまなエンティティやフレーズに関する背景知識が必要である。これらの要素はPythonで直接実行できないが、能力のある言語モデルは依然としてタスクを処理し、トレースを生成することができる。したがって、PTPによって生成されたトレースはPythonに似た擬似コードのトレースとして見るべきである。

私たちはPTPの具体的な実装を説明し、いくつかの重要なハイライトを通じてその効果を示す。

#タスクへの広範な適用性

まず、PTPメソッドはさまざまなタスクで使用可能である。私たちはBIG-Bench Hardベンチマークの23のタスクそれぞれでPTPをテストし、その精度が元のCoTプロンプトと同程度であることを確認した。

第二に、PTPの出力は、定義されたステップを表す合法的なシーケンスにほぼ常に解析できる。未知のテストケースから生成されたトレースには、作成されたサブルーチン名はなく、99%以上のステップが正しい形式に従っていた。整然とした関数呼び出しのうち、95%以上が期待される型の有効なPythonオブジェクトであった。

第三に、PTPプロンプトは個々のステップや完全なタスクインスタンスに対して実行できる。たとえば、入力を変更してトレースの最初のステップのみを生成することができ、さまざまなタスクにおける異なるステップで90%以上の精度を達成した。

第四に、PTPトレースは従来のCoT説明よりも多くの分析の機会を提供する。たとえば、私たちは手動でエラーの性質を評価し、PTPトレース内のステップのモジュラリティを評価することができる。ステップは、その出力がそのステップに指定された入力のみに依存する場合にモジュールと見なされる。私たちのタスクコレクションを確認したところ、ほとんどのステップがこのモジュラリティ分類に該当した。

ステップを明示的に表現することで、特定のステップに局所的な推論エラーがあることを突き止めることができる。しかし、正しい局所ステップがあっても、最終的な答えは間違っている可能性がある。これを非局所的エラー、または「プログラム誘導エラー」と呼ぶ。これは、モデルがこれまでに見た限られた例に基づいて間違った方法を推測するときに発生する。私たちの分析によると、最も間違った最終答えのほとんどは局所エラーに関連している、特に簡単なタスクでは。

#BIG-Bench Hardベンチマーク内のタスクの調査

BIG-Bench Hardベンチマークは、言語モデルにとって挑戦的な23のタスクで構成されている。各タスクには3ショットのCoTプロンプトとテスト例のセットがある。私たちはPTPアプローチを評価するためにこれらのタスクを利用しており、NLPタスクとアルゴリズムタスクの2つのカテゴリーに分けられている。

NLPタスクは通常、低レベルのルーチンを含む高レベルの推論戦略に従う。対照的に、アルゴリズムタスクはしばしば単純な抽出ルールを使用して解決できる。たとえば、一つのアルゴリズムタスクはブール式を評価することを含み、別のタスクは論理的制約を使って推論を要求する。

#プロンプトの構築方法

私たちの方法を評価するために、各タスクに対する既存のCoTプロンプトに近いPTPプロンプトを作成した。モデルが例に厳密に従い、解析しやすい形式で出力を生成するようにするために、変更を行った。私たちは、CoTプロンプトによって示唆されたアルゴリズムを実装するために、各タスクに対して手動でPythonプログラムを書いた。これらのプログラムは、プロンプトをテストするために使用される「モック」として機能する。

モックを実行すると、自動的に関数呼び出しを記録するトレースが生成され、出力が印刷される場合もある。私たちはこれらのトレースを広く受け入れられているドキュメンテーションの規則に従って構造的に配置した。

#プロンプトのための特別な戦略

PTPの一つの興味深い特徴は、同じプロンプトが全体のCoT推論プロセスと個々のステップに対してそれぞれ出力を生成できることである。プロンプトテキストを変更することで、任意のステップのトレースをモデルに予測させることができ、インタラクティブなデバッグの形式を可能にする。

一方で、単一ステッププロンプトはフル例と比較して出力に変動があることがあるが、サブルーチンのドキュメントに単一ステップのトレースを追加することで、生成過多を解決できる。また、単一ステップ生成から出力を抽出するためのより堅牢な方法を開発している。

#トレース内のエラーの特定

生成されたトレース内で発生するエラーの種類を特定できる。これらのエラーは局所的または非局所的に分類できる。局所エラーは特定のステップによって生成された誤った出力を指し、非局所エラーは誤ったステップのシーケンスによって発生する。最も一般的な非局所エラーは、ステップ間で正確に転送されなかった値をコピーすることに関係している。

非局所エラーの存在を評価するために、異なるタスクにわたって詳細な分析を行った。生成されたトレース内で局所エラーと非局所エラーの発生をマークした。分析の結果、非局所エラーはあまり一般的ではなく、少数のタスクでのみ発生することが明らかになった。

#モジュールステップの理解

私たちのアプローチは、PTP構造内の各ステップの信頼性を評価することを可能にする。単一ステッププロンプトを実装することで、言語モデルがステップを独立して実行できるかどうかを判断できる。

実際には、個々のステップの精度をオラクル-比較のために正しい出力を提供できる関数-に対してテストする。私たちの発見は、全体的なパフォーマンスが90%以上を超え、モデルが独立して扱われるときにステップを正確に実行できることを示している。

しかし、単一ステップを評価することは一般的に課題が存在し、それぞれのステップには明確なラベルがない。観察したとおり、ステップは完全な問題解決コンテキスト内でプロンプトに応じて異なる振る舞いをすることがある。私たちは、追加の情報に依存するステップを非モジュールと呼び、そのパフォーマンスは周囲のコンテキストに基づいて不安定であることを意味する。

#モジュラリティと分析に関する結論

私たちの分析では、モジュラリティを定義し、それを測定する方法を示した。ステップは、その動作が指定された入力変数に基づいて完全に決まる場合にモジュールと見なされる。ステップが独立して実行されるかどうかを確認するために介入を行い、変更があるかどうかを検査することができる。

統計テストを使用して、介入前後のステップのパフォーマンスを比較した。私たちの結果は、非モジュラリティが存在することを示唆しているが、NLPタスクの文脈では相対的に稀であることがわかった。私たちが調べたタスクのほとんどのステップは一貫して振る舞い、多くのステップ実行がモジュールであるという考えを支持している。

この研究では、プログラムトレースプロンプティングを用いてCoT説明を整理することで、より明確な推論とより良い分析につながることを示した。これらの洞察をもとに、言語モデルがいかに推論するか、そして実際のアプリケーションにおける説明能力を向上させる方法を深く理解できればと思っている。