算術推論問題のための即座のエンジニアリング
即興エンジニアリングのための算術と推論問題
Vellum.aiを使用して算術的推論問題のさまざまなプロンプトエンジニアリング技術、ベストプラクティス、および製品用の迅速な実験を探求する
イントロダクション
言語モデル(LLM)は、言語の理解と生成能力において優れているため、学術研究者や業界の専門家からますます注目を集めています。彼らのテキスト理解能力の背後には、予測される後続の単語を主な目標とした、膨大なデータにさらされるトレーニングプロセスがあります。これらのモデルを特定のタスクに最適化するためには、 fine-tuning が不可欠です。これは、「プレトレーニングおよびファインチューニング」と「プロンプトファインチューニング」の2つの方法で行うことができます。
従来の「プレトレーニングとファインチューニング」アプローチでは、LLMは後で実行するタスクに関連するデータセットでファインチューニングされ、ファインチューニングフェーズでパラメータが更新されます。一方、「プロンプトファインチューニング」では、モデルを実行するためのテキストセグメントでモデルをガイドします。
プロンプトは、ユーザーがモデルに対して応答するために提供する入力です。プロンプトには指示、文脈、質問、または出力指示が含まれる場合があります。プロンプトエンジニアリングは、言語モデルの効果的な利用のためのプロンプトの開発と改良に専念する新興の分野です。
しかし、算術と常識的推論を必要とする問題に対処できるモデルの確保には、重要な課題があります。この記事では、具体的には算術問題のためのプロンプトエンジニアリングに焦点を当てています。
- 混沌な文脈で、思考の糸口と並行の知識グラフの検索によって、構造化された推論を達成するLLMs
- (ローマ字:Rokkagetsu de detā anarisuto no shigoto o te ni ireta hōhō)
- 物理の知識を持つニューラルネットワークのエキスパートGPTを構築する
前提条件
事前の知識は必要ありません。以下に示すデモンストレーションは、OpenAI PlaygroundまたはOpenAI APIで実行できます。この記事では主にOpenAIモデルを使用していますが、市場で入手可能な任意のLLMを適用することも可能です。
算術問題のためのプロンプトエンジニアリング
以下に挙げるすべての問題は、GSM8Kデータセットから取得され、デフォルトの設定でOpenAIのGPT-3.5 Turbo Instructモデルを使用してテストされます。
以下の算術問題に対して、さまざまなテクニックをテストします:
Jenniferは、教室の友人Markと会う前に、店で40缶のミルクを購入しました。Jenniferは、Markが購入する毎に追加で6缶ずつ購入しました。Markが50缶購入した場合、Jenniferは店から何缶のミルクを持ち帰りましたか?
上記の問題の正しい答えは100リットルです。
ゼロショットプロンプティング
ショットは基本的に例を意味します。ゼロショットは、モデルに対してデモンストレーションを提供せずに質問を提示する基本的なプロンプティング技術です。一般的に、大規模なモデルであり、膨大なデータでトレーニングされている場合に有利な結果を生み出します。
プロンプト:
Q: {{ question }}A:
出力:
ジェニファーは店からミルクの缶を76個持ち帰りました。
前のプロンプトでは、どのようなデモンストレーションも問いの前に付け加えなかったため、モデルが算術の問題に正しい答えを提供できなかったのです。推論や常識の問題は、ゼロショットのプロンプトでは満足のいく結果を得ることが滅多にありません。そのため、このような問題に取り組む際には、例を含めることが重要です。
フューショットプロンプティング
フューショットプロンプティングでは、モデルに少数のデモンストレーション(例示)を提供します。これらの例示はモデルをガイドする役割を果たし、その後の問題を同様に処理するための手助けをします。必要なデモンストレーションの数は、問題の複雑さと使用される具体的なモデルによって異なります。
プロンプト:
Q: ケンは寄宿舎に滞在している弟に送るためにケアパッケージを作りました。ケンはスケールの上に箱を置き、それから箱に十分なだけのゼリービーンズを注ぎ入れて重量が2ポンドになるようにしました。次に、重量を3倍にするために十分なだけのブラウニーを追加しました。その後、さらに2ポンドのゼリービーンズを追加しました。そして最後に、重量を再び2倍にするような十分な量のガミーワームを追加しました。グッズの箱の最終的な重さは何ポンドですか?A: 16Q: マークは花が咲く庭を持っています。彼はそれに3つの異なる色の植物を植えました。そのうち10個は黄色で、その紫色の植物の数はその80%多いです。黄色と紫色の花があるだけの緑色の花は25%しかありません。マークの庭には何個の花がありますか?A: 35 Q: ジェームズは1週間に2つの友達に対して3ページの手紙を2回書いています。1年に何ページの手紙を書くのでしょうか?A: 624 Q: アルバートは1日にどれだけのピザを食べられるか考えています。彼は大きなピザを2枚と小さなピザを2枚買いました。大きなピザは16個のスライス、小さなピザは8個のスライスがあります。全部食べた場合、その日に何個のピースを食べますか?A: 48Q: ベティは新しい財布を買うためにお金を貯めています。財布の値段は100ドルです。ベティは必要なお金の半分しか持っていません。彼女の両親はその目的のために彼女に15ドルを渡すことにしましたし、彼女の祖父母は両親の2倍のお金を渡すことにしました。ベティは財布を買うためにもういくらお金が必要ですか?A: 5Q: {{ question }}A:
出力:
76
この技術は困難な問題に取り組む際にうまく機能しますが、モデルは算術推論の問題で満足のいく結果を見つけることができない場合もあります。これは、モデルが直ちにステップを推論できないためです。
フューショット チェーン オブ ソート(CoT)プロンプティング
フューショット チェーン オブ ソート (CoT)プロンプティングは、解決策に到達する過程でモデルにいくつかの例示を提供します。このガイダンス(中間的な推論ステップとも呼ばれます)は、モデルがステップを進め、論理的な出力を生成するのを手助けするために重要です。
プロンプト:
Q: ジェームズは週に2人の違う友達に対して3ページの手紙を2回書いています。1年に何ページの手紙を書くのでしょうか?A: 彼は1週間に6ページずつの手紙を友達ごとに書いています。つまり、彼は1週間に12ページの手紙を書いています。これは1年で12×52=624ページの手紙を書くことを意味します。答えは624です。Q: {{ question }}A:
出力:
ジェニファーは40+6/5*50=40+12*10=40+120=160個のミルクの缶を買いました。答えは160です。
上記の出力では、モデルが手順を推論しようとしましたが、正しい最終答えには至りませんでした。これによる不一致は、提供された例示が関連性を持たないことに起因すると考えられます。この問題に対処する方法は2つあります。モデルにさらに例を提供するか、与えられた例が関連していることを確認することです。以下では、関連性のある例を用いてこの問題を修正しようとしています。
プロンプト:
Q: マークは花が咲く庭を持っています。彼はそれに3つの異なる色の植物を植えました。そのうち10個は黄色で、その紫色の植物の数はその80%多いです。黄色と紫色の花があるだけの緑色の花は25%しかありません。マークの庭には何個の花がありますか?A: イエローフラワーは10個あります。紫色のフラワーは10の80/100=8個多いです。したがって、マークの庭には10+8=18個の紫色のフラワーがあります。紫色と黄色のフラワーの合計は10+18=28個です。これはマークの庭には紫色と黄色のフラワーの25/100=7個の緑色のフラワーがあることを意味します。したがって、マークの庭には28+7=35個の植物があります。答えは35です。Q: {{ question }}A:
出力:
Markさんが5缶買うごとに、Jenniferさんはさらに6缶買いました。したがって、50缶の場合、Jenniferさんは6/5*50=60缶を追加で購入しました。合計で、Jenniferさんは40+60=100缶のミルクを買いました。したがって、Jenniferさんはお店から100缶のミルクを家に持ち帰りました。
得られた最終答えは正しいです。タスク、モデルの選択、例の関連性を考慮して、正しい解決策にたどり着くためにすべてが貢献しています。
プログラム支援言語モデル(PAL)
プログラム支援言語モデル(PAL)は、プロンプティング手法ではなく、プロンプトエンジニアリングの応用です。CoTと同様に、PALは中間ステップを推論することを目指しています。ただし、一般のテキストではなく、Pythonインタプリタなどのプログラムランタイムを使用して、中間のプログラムステップを使用します。
プロンプト:
Q: Jamesさんは週に2回、異なる2人の友達に3ページの手紙を書きます。1年間で何ページ書かれるでしょうか? A: #Jamesが持つ友達の数は2です。#1回の書簡に各友人に3ページ書きます。#週に2回ずつ友人に書き込むので、1週間に書かれる各友人へのページ数は3*2=6です。#したがって、彼が1週間ごとに書いたページの合計、1週間当たりの合計ページ数は6*2=12です。#1年間の週数は52です。#つまり、彼が書いた合計ページ数、1年間に書かれた合計ページ数は12*52=624ページです。回答は624です。Q: {{ question }}A:
出力:
#Jenniferは最初に40缶のミルクを購入しました。initial_cans_bought=40#Markが5缶買うごとに、Jenniferはさらに6缶を購入しました。additional_cans_bought=6mark_cans_bought=50#したがって、Markが5缶買うごとに、Jenniferはさらに6缶を購入しました。additional_cans_bought=6mark_cans_bought=50#Markが5缶買った回数number_of_times_mark_bought=mark_cans_bought/5=10#Jenniferが合計で購入した追加缶の数total_additional_cans_bought=additional_cans_bought*number_of_times_mark_bought=60#Jenniferが家に持ち帰った総ミルク缶の数total_cans_brought_home=initial_cans_bought+total_additional_cans_bought=40+60=100答えは100缶のミルクです。
例題として関係のない例ですが、few-shot CoT技術を使用して正しい答えを得ることができなかったにも関わらず、PALは正しい最終解を見つけることに成功しました。
ゼロショットチェーンオブソート(CoT)プロンプティング
few-shotチェーンオブソート(CoT)技術のデモが利用できない場合、モデル自体に中間ステップを推論するように尋ねるという、直接的で効果的なアプローチがあります。これはゼロショットチェーンオブソート(CoT)と呼ばれます。「ステップバイステップで考えましょう」といったテキストをプロンプトの質問に追加することで、このシンプルなテクニックは驚くほど優れた結果を示しました。
プロンプト:
Q: {{ question }}A: ステップバイステップで考えましょう...
出力:
1. Jenniferは最初に40缶のミルクを購入しました。2. Markが5缶買うごとに、Jenniferは追加で6缶購入しました。3. Markが50缶購入したため、Jenniferは5缶ごとに6缶追加購入したことになり、これは(6/5) x 50 = 60缶です。4. したがって、Jenniferは合計で40 + 60 = 100缶のミルクをお店から家に持ち帰りました。
上記の例から、モデルはステップを推論し、例やガイダンスなしで正しい解決策に到達することができることがわかります。
Tree-of-Thought (ToT) Prompting
Tree-of-thought (ToT)フレームワークは、人間の問題解決と似たように、思考のツリー構造をナビゲートする方法で潜在的な解決策を探求することを含みます。このアプローチにより、必要な場合にはステップを逆戻りすることが可能になり、問題解決プロセス中に人間が自分の思考を再評価して調整する方法と同じようになります。基本的には、ToTは試行錯誤を通じて人間の推論の適応的かつ反復的な性質を再現することを目指しています。
ToTフレームワークに基づき、Dave Hulbertはtree-of-thoughtプロンプティングを提案しました。この技術は、モデルに中間ステップの評価を依頼するシンプルなシングルプロンプトアプローチを採用しています。
プロンプト:
この質問に適切な3つの異なる専門家として振る舞いなさい。全ての専門家はステップとステップに対する考えを書き留め、それをグループと共有します。その後、全ての専門家は次のステップに進みます。各ステップで、全ての専門家は1から5までの間で他のメンバーの返答にスコアをつけます。1は非常にあり得ないことを意味し、5は非常にあり得ることを意味します。もしもどの専門家がどこかで間違ったと判断された場合、その専門家は退場します。全ての専門家が分析を提供した後、あなたは3つの分析を分析し、合意に基づく解決策またはベストゲスの解決策を提供します。以下は質問です:Q: {{ question }}A:
出力:
専門家 1: 数学の専門家
Step 1: Markが購入したミルクの缶数を計算します。Markはミルクの缶50本を買いました。スコア: 5 (非常にあり得る)
Step 2: Markに会う前にJenniferが購入したミルクの缶数を計算します。Jenniferはミルクの缶40本を買いました。スコア: 5 (非常にあり得る)
Step 3: 5缶の買い物ごとにJenniferが追加で購入したミルクの缶数を計算します。Markが5缶買うごとに、Jenniferは追加で6缶を買います。スコア: 5 (非常にあり得る)
Step 4: Jenniferが購入したミルクの総缶数を計算します。Jenniferは40 + (6/5)*50 = 40 + 60 = 100缶のミルクを買いました。スコア: 5 (非常にあり得る)
Step 5: 結論Jenniferは店から100缶のミルクを家に持ち帰りました。スコア: 5 (非常にあり得る)
専門家 2: 小売業の専門家
Step 1: 店で顧客が購入するミルクの平均缶数を求めます。過去の販売データに基づくと、顧客が購入するミルクの平均は10缶です。スコア: 4 (あり得る)
Step 2: Markが購入したミルクの総缶数を計算します。Markはミルクの缶50本を買いました。スコア: 5 (非常にあり得る)
Step 3: Markに会う前にJenniferが購入したミルクの缶数を計算します。Jenniferはミルクの缶40本を買いました。スコア: 5 (非常にあり得る)
Step 4: Jenniferが購入したミルクの総缶数を計算します。Jenniferは40 + (6/5)*50 = 40 + 60 = 100缶のミルクを買いました。スコア: 5 (非常にあり得る)
Step 5: 結論Jenniferは店から100缶のミルクを家に持ち帰りました。スコア: 5 (非常にあり得る)
専門家 3: 心理学の専門家
Step 1: Jenniferの行動と意思決定プロセスを分析します。Jenniferは彼女自身のニーズと好みに基づいて40缶のミルクを購入した可能性があります。スコア: 4 (あり得る)
Step 2: Markの行動と意思決定プロセスを分析します。Markは彼自身のニーズと好みに基づいて50缶のミルクを購入した可能性があります。スコア: 4 (あり得る)
Step 3: 社会的規範や仲間のプレッシャーの影響を考慮します。Markの購入を見た後、Jenniferはもっと多くのミルクの缶を買う必要を感じた可能性があります。スコア: 3 (ややあり得る)
Step 4: Jenniferが5缶ごとに追加で買うことを決めた影響を分析します。JenniferはMarkに追いつくために、あるいは寛大に見せるためにこの決定をした可能性があります。スコア: 3 (ややあり得る)
Step 5: 結論Jenniferは社会的規範や仲間のプレッシャーの影響を受けて、店から100缶のミルクを家に持ち帰りました。スコア: 3 (ややあり得る)
合意に基づく解決策:3人の専門家の分析を考慮すると、Jenniferは店から100缶のミルクを持ち帰った可能性が非常に高いです。数学の専門家の分析は確かな計算を提供し、小売業の専門家の分析は顧客が購入する平均缶数を考慮しています。心理学の専門家の分析は社会的規範や仲間のプレッシャーの影響を考慮することで異なる視点を加えています。全体的に、合意に基づく解決策はJenniferが店から100缶のミルクを家に持ち帰ったということです。
上記の例で使用されたToTテクニックは、正確な解決策を提供します。ToTプロンプトは、Dave HulbertのToTプロンプトから取得されたものですが、このテクニックの欠点の一つはプロンプトのサイズが大きくなることです。
上記で言及されたエンジニアリングのテクニックに加えて、数学的な論理問題を解決するために追加の方法がいくつか採用されることがあります。ただし、この記事の範囲外であるため、Automatic Chain-of-Thought (Auto-CoT)、Self-Consistency、Automatic Reasoning and Tool-Use (ART)、およびActive Promptなどのテクニックは範囲外です。
ベストプラクティス
モデルは、設計がよく考えられたプロンプトで微調整されると効果的に機能します。Elvis Saraviaは、プロンプトは次の4つの要素で構成される場合がありますが、常に全てが必要なわけではありません:
- 命令:モデルに実行させたい特定のタスクまたはアクションを指定します。
- 文脈:モデルがより正確な応答を生成するために、外部情報や追加の詳細を提供します。
- 入力データ:回答を求めている具体的な入力や質問。
- 出力指示:期待される出力のタイプや形式。
命令は、始めに専用の区切り文字(「#」など)を使用して他のプロンプトから分離すると良いでしょう。
Santu and Feng (2023)は、タスクごとに異なる性能を持つ複数のLLMの比較をより有意義にするために、TELeR(Turn、Expression、Level of Details、Role)という包括的なタクソノミーを導入しました。プロンプトのタクソノミーは、提供される詳細レベルに基づいてプロンプト指示を6つのレベルに分類します。与えられたプロンプトに基づいてモデルのパフォーマンスを最適化するために、6番目のレベルを効果的に利用することができます:
- 高レベルのゴールの簡単な説明を提供する。
- サブタスクの詳細な箇条書きリストを提示する。
- 言語モデル(LLM)の出力を評価するための基準を指定するか、いくつかの例を含める。
- 検索ベースのテクニックによって得られた追加の関連情報を含める。
- LLMから明確なステートメントを要求し、その出力を説明してもらう。
一般的には、具体的で明確な詳細を提供し、反復を通じてプロンプトを継続的に改善し、明確な区切り文字を使用してプロンプトの形式を適切に整え、行うこととしないことを述べることが望ましいです。
上記のプラクティスを考慮し、ゼロショットプロンプティングテクニックを適用した場合のプロンプトを再検討してみましょう。
プロンプト:
### INSTRUCTION ###算数論理の問題に回答する必要があります。以下の手順に従って問題を解決してください。1. 必要なステップ数で問題を解決する。各ステップには番号を付けます。2. 計算は明確で理解しやすいものである必要があります。3. 最後に、答えを以下の形式で正確に示します:「答えは 'Answer is 'です。評価要素:- 計算が理解しやすいか?- 答えが正確か?### INPUT DATA ###Q: {{ question }}A:
Output:
1. Jenniferは店で40缶のミルクを購入しました。2. Markは50缶のミルクを購入しました。3. JenniferはMarkが購入する5缶ごとに6缶の追加を購入しました。4. Markが5缶購入するごとに、Jenniferは6缶の追加を購入しました。5. したがって、Markが購入した50缶のため、Jenniferは(6/5)*50 = 60缶の追加を購入しました。6. Jenniferが購入したミルクの総缶数 = 40 + 60 = 100缶。答えは100缶です。
最初、このモデルはゼロショット・プロンプティング・テクニックを使用して正しい解答を提供できませんでした。しかし、適切な指示とフォーマットの適用により、同じモデルはゼロショット・プロンプティング・テクニックを使用して正しい応答を生成することに成功しました。
免責事項:次のセクションでは、急速なプロンプトの製品化に役立つ開発者プラットフォームであるVellumについての情報を提供します。Vellumの言及は情報提供のためであり、支持や促進を意味するものではありません。私はVellumとは関係がなく、その含蓄に対して報酬を受け取っていません。
Vellum
適切なプロンプトを特定することは難しい課題です。プロセスは基本的なプロンプトから始まり、複数の反復を通じて徐々に改良されるタスクであり、管理が困難なものです。スプレッドシートは少数の実験には適しているかもしれませんが、複雑な問題に直面し、多数の反復を要求する場合には不十分です。では、効率的にプロンプトを監視するにはどうすればよいのでしょうか?チームとプロンプトの実験結果をシームレスに共有することが目標の場合はどうでしょうか?これらの質問に対する答えがVellumです。
Vellumは、プロンプトエンジニアリング、意味的検索、バージョン管理、数量テスト、性能モニタリングのためのツールスイートを提供し、製品レベルのLLMアプリケーションの開発を支援します。プロンプトエンジニアリングのコンテキストでは、市場にある主要なLLMすべてで特定のプロンプトのテストと評価が可能です。また、プロンプトに関する協力を容易にします。
上の画像は、Vellum sandboxの代表的なスクリーンショットです。Vellumではテキストとチャットモデルの切り替えが容易であり、モデルパラメータの簡単な調整が可能です。また、正確な一致、正規表現一致、意味的類似性、ウェブフックの4つの評価指標に沿った遅延追跡と定量的評価の利点も提供しています。
Vellum – LLMアプリケーションの開発プラットフォーム
Vellumは、プロンプトエンジニアリング、意味的検索、バージョン管理などのツールを備えたLLMアプリケーションの開発プラットフォームです。
www.vellum.ai
まとめ
この記事ではまずプロンプトについて紹介し、それから算術の論理問題に対するプロンプトエンジニアリングについて探求しました。ゼロショット、フューショット、フューショットチェーンオブソート、ゼロショットチェーンオブソート、プログラム補助言語モデル、およびツリーオブソートといったさまざまなプロンプトエンジニアリング技術について検討しました。
その後、良いプロンプトを作り上げるための一部のベストプラクティスを学びました。一般的には、具体的で明確な詳細を提供し、反復を通じてプロンプトを継続的に改善し、明確な区切りで適切にフォーマットし、実施事項と非実施事項を明記することが推奨されます。
最後に、プロンプトの追跡と評価、およびチームメンバー間での共有の課題に対処するために、Vellumツールを調査しました。
この記事がお気に入りであれば、こちらでフォローしてください。私にはLinkedInおよびX(以前はTwitter)を通じて連絡することもできます。
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles