実ユーザーに触れても壊れないプロンプトの型

回答より先に、拒否を書く

最初に定めるべきは、答えられないときにモデルが何をするかです。どの文言で、どの言語で、次の一手を提示すべきかどうか。多くのチームはこれを最後に書きます。だから本番での最初の幻覚はいつも不意打ちになります。

指示とデータを分ける

ユーザーの文章を、あたかも指示の一部であるかのように連結してはいけません。指示はシステムロールに置き、ユーザーの内容は明確に区切ること。さもなければ「上記を無視して」と書いた客が、あなたのプロンプトを操作していることになります。

後段が解析するなら構造を要求する

出力を下流のシステムが読むなら、厳密な形を要求し、使用前に検証すること。不正な場合の処理は明示的に書くこと。検証エラーを添えて再試行すれば、たいてい回復します。形式が崩れないことを願うのは、量が増えた時点で戦略ではありません。

簡単な例ではなく、難しい例を与える

プロンプト内の例は高価な文脈です。モデルが間違える場面にこそ使ってください。曖昧な依頼、範囲外の質問、言語を取り違えた入力。簡単な例は、すでにできていることしか教えません。

プロンプトをバージョン管理に置く

プロンプトはプログラムのロジックです。レビューし、版を付け、その変更を正当化した評価実行と紐づけるべきものです。管理画面で直に編集されるプロンプトは、機能が静かに劣化し、何が変わったのか誰も言えなくなる原因です。