システムプロンプトとユーザープロンプトの最大の違いは、最初に現れる人ではなく、「責任者」です。 システムプロンプトは、同一性、トーン、出力境界、禁止事項、固定プロセスなどの長期的かつ安定したルールの作成により適しています。 ユーザープロンプトは、このラウンドで行う特定のタスクを書くのに適しています。例えば、書き直し、要約、抽出、比較するコンテンツを手伝ってくれます。 多くの人がこの二つを混同し、その結果、ルールが不安定で課題が逸脱しやすくなっています。
| 判決点 | システムのプロンプトの方が適しています | ユーザープロンプトの方が適しています |
|---|---|---|
| アクションサイクル | 複数のラウンドにわたって引き続き有効です | 現在の課題のみが実行されます |
| コンテンツタイプ | 役割、ルール、境界、フォーマット制約 | 質問、教材、目標、補足要件 |
| 頻繁に変わるのですか? | 比較的安定しています | 質問によってよく変わることが多いです |
まずシステムのプロンプトに書くべき内容は何か
- カスタマーサービス、編集者、コードアシスタントなど、モデルが長期間にわたって維持してほしいアイデンティティやレベル。
- 結論を先に出す、表のみを返す、偽造の禁止、見つけられない場合は直接話すなど、守るべき出力ルール。
- このプロセスは問題ごとに変わらず、例えば継続する前に入力を確認するなどです。
ユーザープロンプトに入れるのに適したコンテンツは何でしょうか
- 今回は具体的に何をすべきか、例えば会議議事録の要約、契約リスクの抽出、そしてコピーを口語的なバージョンに変更するなど。
- このラウンドでのみ利用可能となる文脈資料、例えば原記事、スクリーンショットの説明、顧客の要望、テーブルデータなどです。
- 例えば、この時間が短く、上司志向で、数字や日付を保持するための臨時の好みもあります。
最も一般的なミスは、システムプロンプトにタスク要件の大部分を長期間詰め込み、その後の各ラウンドで古い要件に邪魔されることです。 より安定したアプローチとしては、システムプロンプトがルールのみを設定し、ユーザープロンプトが現在のタスクを具体的に言及するというものです。 覚えておくべきは一文だけ、長期的に変わらない解放システム、解放利用者に対して行うべき現在の流れ、労働分業が明確であればあるほど、モデルが矛盾しにくくなるということです。
