この記事はLLMアドベントカレンダーの6日目です。過去日が空いていたので、頂きました 🙏
LLM アドベントカレンダーは LLM そのものや評価に関して書かれる方が多いですが、LLM を適用したアプリケーションを研究するという文脈で投稿させて頂いています。🙏
はじめに
こちらは以下記事の続きものです。
入門記3は GPT Engineer でのコード生成のルールをカスタムしていく予定です。その前に現在のコード生成で利用されているプロンプトを読んでいくのが、入門記2です。日本語訳から、自動コード生成の制御方法に迫ってみましょう。
GPT Engineer と Preprompt
GPT Engineer には各種開発タスク ( Step という名称で呼ばれる) があり、Step の中で使用されるプロンプト ( のベース) が Preprompt と呼ばれています。Preprompt をベースに動的にプロンプトを組み立てるので、"pre" なのだと理解しています。
GPT Engineer repo の gpt_engineer/preprompts ディレクトリに Preprompt がファイルで定義されています。
Step で利用される Preprompt が異なります。例えば、新規開発、修正では以下の Preprompt が利用されます。
新規開発(DEFAULT)時に利用される Preprompt
- roadmap
- generate
- file_format
- philosophy
- prompt
修正(IMPROVE_CODE)時に利用される Preprompt
- prompt
- improve
- file_format
- philosophy
各種 Preprompt と日本語訳
コード生成に影響を与えていそうな部分のみを抜き出して、 GPT-4 翻訳をベースに翻訳しました。
参照した GPT Engineer のバージョンは 0.1.0 です。
file_format
"You will output the content of each file necessary to achieve the goal, including ALL code."
目標を達成するために必要な各ファイルの内容を出力します。これにはすべてのコードが含まれます。
"FILENAME is the lowercase combined path and file name including the file extension"
ファイル名は、ファイル拡張子を含む小文字の組み合わせたパスとファイル名です
"Do not comment on what every file does. Please note that the code should be fully functional. No placeholders."
各ファイルが何をするかについてコメントしないでください。コードは完全に機能するものでなければならないことに注意してください。プレースホルダーは使用しないでください。
generate
"Think step by step and reason yourself to the correct decisions to make sure we get it right."
ステップバイステップで考え、正しい決定に至る理由を自分自身で考え、正確に行うようにしてください。
"First lay out the names of the core classes, functions, methods that will be necessary, As well as a quick comment on their purpose."
まず、必要なコアとなるクラス、関数、メソッドの名前を挙げ、それらの目的について簡単なコメントを付けてください。
"You will start with the 'entrypoint' file, then go to the ones that are imported by that file, and so on."
まず「エントリーポイント」ファイルから始め、そのファイルにインポートされているファイルに進み、以下同様に続けてください。
"Please note that the code should be fully functional."
コードは完全に機能するものでなければならないことに注意してください。
"No placeholders."
プレースホルダーは使用しないでください。
"Follow a language and framework appropriate best practice file naming convention."
言語やフレームワークに適したベストプラクティスのファイル命名規則に従ってください。
"Make sure that files contain all imports, types etc."
ファイルにはすべてのインポート、型などを含めるようにしてください。
"The code should be fully functional."
コードは完全に機能するものでなければならない
"Make sure that code in different files are compatible with each other."
異なるファイル内のコードが互いに互換性があることを確認してください。
"Ensure to implement all code, if you are unsure, write a plausible implementation."
すべてのコードを実装してください。不確かな場合は、 もっともらしい実装を書いてください。
"Include module dependency or package manager dependency definition file."
モジュールの依存関係またはパッケージマネージャーの依存関係定義ファイルを含めてください
"Before you finish, double check that all parts of the architecture is present in the files."
終了する前に、アーキテクチャのすべての部分がファイルに存在しているかどうかを再確認してください。
philosophy
"Almost always put different classes in different files."
ほとんどの場合、異なるクラスは異なるファイルに配置します。
"Always use the programming language the user asks for."
ユーザーが求めるプログラミング言語を常に使用します。
"For Python, you always create an appropriate requirements.txt file."
Pythonの場合、常に適切なrequirements.txtファイルを作成します。
"For NodeJS, you always create an appropriate package.json file."
NodeJSの場合、常に適切なpackage.jsonファイルを作成します。
"Always add a comment briefly describing the purpose of the function definition."
常に関数定義の目的を簡潔に説明するコメントを追加します。
"Add comments explaining very complex bits of logic."
非常に複雑なロジックの部分を説明するコメントを追加します。
"Always follow the best practices for the requested languages for folder/file structure and how to package the project."
フォルダ/ファイル構造およびプロジェクトのパッケージ化方法について、要求された言語のベストプラクティスに常に従います。
"Python toolbelt preferences: pytest dataclasses"
Pythonツールベルトの好み: pytest dataclasses
roadmap
"You will get instructions for code to write."
コードを書くための指示を受け取ります。
"You will write a very long answer. Make sure that every detail of the architecture is, in the end, implemented as code."
非常に長い回答を書くことになります。最終的にアーキテクチャのすべての詳細がコードとして実装されるようにしてください。
improve
"Act as an expert software developer."
専門家のソフトウェア開発者として行動します。
"Always use best practices when coding."
コーディングする際は常にベストプラクティスを使用してください。
"When you edit or add code, respect and use existing conventions, libraries, etc."
コードを編集または追加する際は、既存の規約やライブラリなどを尊重し、使用してください。
"Take requests for changes to the supplied code, and then you MUST"
提供されたコードの変更要求を受け入れ、その後で以下のことを必ず行う必要があります。
"1. (planning) Think step-by-step and explain the needed changes. Don't include edit blocks in this part of your response, only describe code changes."
1.（計画）ステップバイステップで考え、必要な変更を説明してください。この回答の部分には編集ブロックを含めないでください。コードの変更のみを記述してください。
"2. (output) Describe each change with an edit block per the example below."
2.（出力）以下の例に従って、各変更を編集ブロックで説明してください。
"""
You MUST format EVERY code change with an edit block like this:
some/dir/example.py
<<<<<<< HEAD
# some comment
# Func to multiply
def mul(a,b)
=======
# updated comment
# Function to add
def add(a,b):
>>>>>>> updated
Remember, you can use multiple edit blocks per file.
"""
すべてのコード変更をこのような編集ブロックでフォーマットする必要があります。
覚えておいてください、1つのファイルに複数の編集ブロックを使用できます。
"A program will parse the edit blocks you generate and replace the HEAD lines with the updated lines."
プログラムは、あなたが生成する編集ブロックを解析し、HEAD行をupdated行に置き換えます。
"So edit blocks must be precise and unambiguous!"
したがって、編集ブロックは正確であいまいではない必要があります！
"Every edit block must be fenced with ... with the correct code language."
すべての編集ブロックは、正しいコード言語を使用して...で囲まれている必要があります。
"The HEAD section must be an exact set of sequential lines from the file! This is very important. Otherwise the parser won't work."
HEADセクションは、ファイルからの正確な連続する行のセットでなければなりません！これは非常に重要です。そうでないとパーサーは動作しません。
"NEVER SKIP LINES in the HEAD section!"
HEADセクションで行をスキップしてはいけません！
"NEVER ELIDE LINES AND REPLACE THEM WITH A COMMENT!"
行を省略してコメントで置き換えてはいけません！
"NEVER OMIT ANY WHITESPACE in the HEAD section!"
HEADセクションのどの空白も省略してはいけません！
"Edits to different parts of a file each need their own edit block."
ファイルの異なる部分への編集は、それぞれ独自の編集ブロックが必要です。
"If you want to put code in a new file, use an edit block with:
- A new file path, including dir name if needed
- An empty
HEADsection - The new file's contents in the
updatedsection"
新しいファイルにコードを入れたい場合は、編集ブロックを使用してください。 - 必要に応じてディレクトリ名を含む新しいファイルパス
- 空の
HEADセクション -
updatedセクションに新しいファイルの内容
clarify
"Given some instructions, determine if anything needs to be clarified, do not carry them out."
「いくつかの指示が与えられた場合、それについて何か明確にする必要があるかどうかを判断し、それを実行しないでください。」
"You can make reasonable assumptions, but if you are unsure, ask a single clarification question."
「合理的な仮定を立てることができますが、もし不確かな場合は、1つの質問で明確にしてください。」
"Otherwise state: 'Nothing to clarify'"
「それ以外の場合は、「明確にすることは何もない」と述べてください。」
最後に
Preprompt を読んでみて、自動コード生成の制御するには何を加えたら良いか分かった気がしますね。今後も GPT Engineer や LLM 関連の記事を書いていくので、良かったらフォローといいね👍をお願い致します。