プロンプト最適化とは、定めた目標に照らしてプロンプトを改善するプロセスです。目標は、より良い回答、少ないトークン、低い遅延、より一貫した形式などです。いじり回すことと違うのは、測定があることです。「より良い」とは何かを決め、1 つだけ変えて、確認します。
何のために最適化するかを決める
プロンプトはいくつもの軸で最適化でき、それらは互いに引っ張り合います。
| 目標 | 測定方法 | 犠牲になりがちなもの |
|---|---|---|
| 品質 | テストセットでの合格率 | トークン |
| 一貫性 | 同じ入力に同じ形の出力 | 柔軟性 |
| コスト | 呼び出しごとの入出力トークン | 文脈、例 |
| 遅延 | 最初と最後のトークンまでの時間 | 推論の深さ |
| 安全性 | インジェクションや漏えいへの耐性 | 有用性の一部 |
主な目標を 1 つ選び、他には上限を設けます。たとえば「入力 800 トークンを超えずに、合格率を上げる」のように。
最適化ループ
1. まず静的な問題を直す
モデルがなくても見つかる欠陥があります。目的がない、あいまいな言葉、数値のないサイズ、矛盾する指示、出力形式がない、繰り返される文、区切りのない変数などです。モデルの呼び出しにお金をかける前に、これらを片づけましょう。PromptFlowEngine のプロンプトアナライザーが、修正案とともに一覧にします。
2. テストセットを作る
実際の使い方を代表する入力を 20〜50 件集めます。含めるもの：
- 典型的なケース。
- エッジケース：空、非常に長い、言語が混在、不正な形式。
- 敵対的なケース：指示を変えようとするテキスト。
- 過去の失敗。すべてのバグがテストになります。
各入力について、正しい出力が含むべきことや満たすべきことを書き出します。
3. ベースラインを確立する
現在のプロンプトをすべての入力で実行し、結果を記録します。この数字が、あらゆる変更の比較対象です。これがなければ、改善とノイズを区別できません。
4. 失敗を読む
グループ分けします。10 件の失敗には、たいてい 2〜3 個の原因があります。パターンを探しましょう。いつも長い入力か、いつも特定のカテゴリか、いつも同じ欠けたフィールドか。
5. 仮説を 1 つ立て、変更を 1 つ行う
「プロンプトに JSON のみを返すよう書いていないので、モデルがコメントを付けている。」その変更だけを行います。
6. セット全体を再実行する
失敗が直ったこと、そして同じくらい重要な、以前は通っていたものが失敗していないことを確認します。1 つのケースを直して 2 つを壊したなら、それは回帰です。
7. 残すか戻すかを決め、繰り返す
何をなぜ変えたかを記録します。バージョン管理はプロンプトの管理を参照してください。
たいてい効く推敲
| 症状 | 推敲 |
|---|---|
| 出力の長さがばらつく | サイズを表す語を数値に置き換える |
| 出力の形がばらつく | 明示的な形式またはスキーマを追加する |
| ルールが無視される | 段落からリストに移す。矛盾を取り除く |
| 一般的すぎる | 対象読者と分野の文脈を追加する |
| エッジケースで間違う | そのケース用のルールまたは例を追加する |
| 事実を捏造する | 出典を渡し、ない場合は「記載なし」を求める |
| 冗長 | 語数の上限を示し、省くものを伝える |
たいてい効かない推敲
- すべての行に強調（大文字、「非常に重要」）を加える。
- 同じ指示を複数の場所で繰り返す。
- 矛盾を確認せずに、失敗のたびに特殊ケースのルールを足す。
- 原因でなかったものの言い回しを変える。
トークンの最適化
品質が許容できるようになったら、振る舞いを変えずにコストを下げます。
- 挨拶、丁寧表現、つなぎの言葉を取り除く。
- 繰り返しの文やほぼ同じ文を削除する。
- テストセットのどの答えも変えない文脈を削る。
- 例の数を減らして再テストする。
- 提供元のキャッシュが効くよう、プロンプトの変わらない部分を先頭に置く。
ステップ 1 と 2 は機械的で、安全に自動化できます。PromptFlowEngine のプロンプトオプティマイザーはそれらを実行したうえで、元のすべての文、要件、保護された範囲がまだ残っていることを検証するので、短いプロンプトは長いプロンプトとまったく同じことを求めます。詳細はトークン最適化を参照してください。
自動最適化
モデルに変種を提案させ、テストセットで採点することで、より良いプロンプトを自動的に探すツールがあります。人が見落とす改善を見つけることがあります。機能するには 3 つが必要です。良いテストセット、信頼できる採点関数、そして勝ったプロンプトのレビューです。最適化は指標の弱点を突くからです。
チャットモデルに「このプロンプトを改善して」と頼む場合にも、似た注意が必要です。読みやすいものは出てきます。ただし、制約を落としたり、前提を追加したりすることがあります。結果を元のものと差分で比較し、すべての要件が残っていることを確認してください。
やめどき
テストセットで目標を満たし、さらなる変更が結果をノイズの範囲内でしか動かさなくなったら、やめます。そこから先の改善は、より良い文脈、プロンプトチェーンのような別の手法、あるいは別のモデルから生まれます。
ルールベースのスコアで分かることと分からないこと
プロンプト評価のような静的な品質スコアは、書かれたとおりのプロンプトを測ります。明確さ、網羅性、一貫性、安全性です。速く再現できるため、あらゆる編集とコミットに向いています。モデルがそのプロンプトで何をするかは測りません。プロンプトを健全に保つのにはスコアを、出力の確認にはテストセットを使いましょう。両方をプロンプトのテストと評価で扱っています。