プロンプトテンプレートの最適化と調整
プロンプトテンプレートを反復的に改善して、一貫性のある高品質な結果を実現します。優れたプロンプトテンプレートは、1 回目で完全に記述されることはほとんどありません。
必要なエディション
| 使用可能なインターフェース: Lightning Experience |
| 使用可能なエディション: Einstein for Platform、Einstein または Agentforce for Sales/Service アドオン、または Agentforce Foundation が付属する Enterprise Edition、Performance Edition、および Unlimited Edition |
最適化は、プロンプトが必要な出力を一貫して生成するまでテスト、評価、調整を繰り返すプロセスです。AI モデルは、表現、構造、指示の微妙な変化に敏感であり、エッジケースは実際のデータでのみ出現します。反復は失敗の兆候ではありません。優れたプロンプトが優れたプロンプトになるプロセスです。
7 ステップの反復サイクル
ステップ 1: 書き込み。最初のプロンプトテンプレートのドラフトを作成します。完璧を目指すのではなく 、 「 テストするのに十分なレベル」を目指します。まず、明確な ToDo 定義、基本的な手順 (5 ～ 7 の重要ポイント)、基本的な差し込み項目、シンプルな書式要件、1 ～ 2 つの主要な制約事項を確認します。
ステップ 2: テスト。5 ～ 10 個の多様な実際の Salesforce レコードを使用してプロンプトテンプレートを実行します。典型的なケース、エッジケース (異常値、最小データ、最大データ)、過去に問題があったレコードを含めます。すべての回答を評価用に保存し、エラーや失敗があれば文書化します。
ステップ 3: 評価する。評価ルーブリックを使用して、結果を成功条件と比較します。各回答にスコアを付けます。各条件を満たしているかどうか、合格率はどのくらいか、失敗は一貫しているか、ランダムか?
ステップ 4: 問題を特定します。失敗とパターンを分析します。一般的な問題のカテゴリは次のとおりです。
- 欠落情報: 命令で必須要素が明示的に必要でなかったため、応答に必須要素が含まれていません。
- 間違ったトーン: トーンの指示があいまいであるか欠落しているため、応答が形式的すぎる、カジュアルすぎる、またはロボットすぎる。
- 不正な長さ: 長さ制約がないか無視されているため、応答が長すぎるか短すぎます。
- 構造が悪い: 形式の仕様が明確ではないため、応答が期待された形式に従っていません。
- コンテンツが不正確: 差し込み項目が正しくないか、コンテキストが不十分であるため、応答に誤った情報が含まれています。
- 一貫性のない結果:命令ではエッジ ケースが処理されないため、テスト ケース間で品質が大幅に異なります。
ステップ 5: 調整する。学習した内容に基づいてプロンプトテンプレートを更新します。
- 情報が不足している場合は、必須要素をリストする明示的な指示を追加します。
- 口調が間違っている場合は、例を使用して特定の口調ガイダンスを追加します。
- 長さが間違っている場合は、単語数または文字数で明示的な長さ制約を追加します。
- 構造が間違っている場合は、詳細な形式仕様を追加します。
- コンテンツが不正確である場合は、コンテキストを追加するか、差し込み項目を修正します。
- 結果に一貫性がない場合は、空の項目などのエッジケースの明示的な処理を追加します。
ステップ 6: 再テストします。以前に使用したテストデータに対して絞り込まれたプロンプトを実行します。合格率が向上したか、以前の失敗が現在は合格しているか、1 つの問題を修正して新しい問題を作成したかを測定します。目標合格率 (本番使用では通常 85 ～ 95%) に達するまで反復します。
| バージョン | 合格率 | 備考 |
|---|---|---|
| バージョン 1 | 60% (6/10) | 件名が欠落している、口調が堅すぎる |
| バージョン 2 | 80% (8/10) | 件名は固定され、口調は改善されたが、2 行が長すぎる |
| バージョン 3 | 90% (9/10) | 固定長、残り 1 個のエッジケースのみ |
ステップ 7: リリースします。プロンプトで一貫して品質応答が生成されたら、本番にリリースします。
Iteration Best Practices (反復のベストプラクティス)
- バージョン履歴を保持します。プロンプトの各バージョンを、そのバージョンの合格率と共に、何が変更されたか、その理由に関するメモと共に保存します。
- 複数のバージョンで同じテストデータを使用します。これにより、改善を直接比較できます。
- 可能な場合は、一度に 1 つずつ変更します。3 つの点を変更して品質が向上すると、どの変更が役立ったかわかりません。初期の反復では複数の修正を一括処理できますが、後の反復では対象を絞った変更を行う必要があります。
- うまくいかなかったことを文書化します。あなたが試みたメモのアプローチは、事態をさらに悪化させました。これにより、後で時間を節約できます。
- 学習内容をチームと共有します。あるプロンプトの最適化について学習した内容は、多くの場合、他のプロンプトにも適用されます。
よくある反復の間違い
- あきらめが早すぎます。生産品質に達する前に 3 ～ 5 回の反復を予想します。このプロセスの予算時間。
- 実際のデータを使用してテストしていない。本番データが乱雑である。テストケースの作成ではなく、実際の Salesforce レコードを常に使用してください。
- 一度に多くのものを変更します。後の反復で、何が機能するかを特定できるように対象を絞った変更を行います。
- エッジケースを無視します。テストデータにエッジケースを含めて、指示で明示的に処理します。
- 成功条件がありません。反復を開始する前に、2 ～ 3 個の具体的で測定可能な成功条件を定義します。明確な目標がなければ、反復は目的がありません。
最適化チェックリスト
プロンプトテンプレートを本番用に準備できたとみなす前に、次の項目を確認してください。
- 15 ～ 20 件以上の実際の Salesforce レコードでテスト済み
- この使用事例の目標 (通常は 85 ～ 95%) を満たす合格率
- エッジケースが適切に処理される
- すべての成功条件が一貫して満たされている
- バージョン履歴は合格率と変更メモと共に文書化されます。
- 調整により、初期バージョンよりも明らかに改善
- 残りの問題はまれで影響が少ない
- チームがレビューして承認した
