レッスン5: プロンプトのデバッグと改善

学習目標:

• プロンプトの問題を体系的に発見する方法を学ぶ
• プロンプトが失敗する理由を診断する手法を身につける
• プロンプトを改善するための反復可能なループを構築する

前提: << レッスン4: Chain-of-Thought: AIに推論を示させる | 次: レッスン6 >>

プロンプトがうまくいかないときにすべきこと

役割、タスク、形式、例を含む丁寧なプロンプトを書いたのに、AIがまだ間違える。形式がずれていたり、内容がそれていたり、重要な情報が抜けていたりする。どうすればいいのか?

ランダムに数語を変えて、次の実行が幸運であることを願うのか? それとも問題を突き止めて意図的に修正するのか? このレッスンでは2つ目のアプローチを教える。コードをデバッグするようにプロンプトをデバッグする。症状を見つけ、原因を診断し、小さな変更を加え、結果を確認する。¹

3ステップのデバッグループ

プロンプトのデバッグはコードのデバッグと非常に似ている。¹

1. 問題を特定する: 出力の何が具体的に間違っているのか?
2. 原因を診断する: プロンプトのどの部分がその問題を引き起こしたのか?
3. 変更して検証する: 1つのことを変更し、改善されたかどうかをテストする。

最も重要なルール: 一度に1つの変数を変更する。3つのことを一度に変更すると、どの変更が効果をもたらしたのかわからなくなる。

ステップ1: 具体的な問題を特定する

「出力が間違っている」では曖昧すぎる。実際に何が間違っているのかを正確に特定する。¹

よくある問題タイプ:

例: 問題の特定

あなたのプロンプト:

この記事の重要なポイントを要約してください。

AIの出力:

この記事は3つの重要なポイントをカバーしています。第一に... 第二に... 最後に...

特定された問題: あなたが望んでいたリスト形式ではなく、何ポイントにするかも指定していない。

ステップ2: 原因を診断する

プロンプトのどの部分(またはどの欠けている部分)が問題を引き起こしたかを見つける。

診断チェックリスト:

• タスクは明確か? 「重要なポイントを要約する」は曖昧。何ポイントにするか、各ポイントをどのくらいの長さにするかを言っていない。
• 形式の例はあるか? ない。AIはあなたが望む形を推測するしかない。
• 制約は十分か? 「ポイントのみを出力し、導入文は不要」とは言っていない。
• 曖昧な部分はあるか? 「重要なポイント」は「核心的な主張」を意味するかもしれないし、「すべての主張」を意味するかもしれない。

診断: 形式の仕様と数の制約が欠けている。

ステップ3: 小さな変更を加え、検証する

一度に1つの問題を修正し、改善されたかどうかをテストする。

変更1: 数と形式を明示する

この記事を3つの箇条書きで要約してください。各ポイントは1文で。

テスト結果: 形式は正しいが、各ポイントが1文より長くなっている。

変更2: 長さの制約を追加する

この記事を3つの箇条書きで要約してください。
要件:- 各ポイントは15語以内- 箇条書き(- )リストを使用する- ポイントのみを出力し、「重要なポイントは以下の通りです」のような導入文は不要

テスト結果: あなたが望んでいたものと一致する。

次回同じ問題に遭遇したときに再利用できるように、うまくいった変更を記録しておく。

よくある問題の診断と修正

問題1: 不安定な形式

症状: 時々JSON、時々プレーンテキスト。時々コロン、時々イコール記号。

診断: 形式の例がない、または例が互いに一致していない。

修正:

• すべてが全く同じ形式を使用する2〜3の例を提供する
• または制約で明示する: 「このJSON形式に正確に従い、それ以外は何も出力しないでください。」

問題2: 情報の欠落

症状: 出力にデータの一部のみがあり、常に特定のフィールドが抜けている。

診断: 必要な情報をリストアップしていない。

修正:

以下のすべてのフィールドを抽出してください(すべて必須):1. タイトル2. 著者3. 公開日4. 要約
フィールドがソースにない場合は、フィールドを省略するのではなく「提供されていません」と出力してください。

重要なのは、すべての必須フィールドをリストアップし、1つが欠けているときに何をすべきかを言うことです。

問題3: 過剰な説明

症状: コードを要求したのにコードと大量の説明が返ってきた。リストを要求したのに導入文と要約が周りに付いてきた。

診断: 「Xのみを出力する」という制約がない。

修正:

実行可能なコードのみを出力してください。説明、コメント、注記は不要です。

または:

リストのみを出力してください。「これがリストです」のような導入文や要約は不要です。

問題4: 意図の誤読

症状: AIがあなたの意図を誤読し、関連しているが間違った質問に答えた。

診断: 曖昧な表現、または文脈の欠落。

例:

このコードの問題を分析してください。

AIは以下を分析するかもしれない:

• スタイルの問題
• パフォーマンスの問題
• セキュリティの問題
• ロジックエラー

あなたはロジックエラーが欲しかったが、プロンプトはそう言っていなかった。

修正:

このコードのロジックエラーを分析してください。スタイルとパフォーマンスは無視し、間違った出力を生成するロジックバグのみに焦点を当ててください。

欲しい次元を指名し、残りを除外する。

反復のベストプラクティス

プラクティス1: テストケースのセットを構築する

3〜5の代表的な入力を準備し、すべての変更に対してそれらすべてを実行する。¹

例: 製品レビューから感情を抽出するプロンプトを調整している。

テストケース:

1. 明らかにポジティブ: 「とても満足しています。強くお勧めします。」
2. 明らかにネガティブ: 「完全に使用不可能、お金の無駄。」
3. 中立/混合: 「問題なく動作しますが、少し高価です。」
4. エッジケース: 「まあ大丈夫だと思います。」
5. 複雑: 「サポートは素晴らしかったですが、製品品質は平凡です。」

プロンプトを変更するたびに、5つすべてを実行し、すべてが正しく分類されるかどうかを確認する。

プラクティス2: バージョンと結果を追跡する

コードのバージョンを管理するように、プロンプトのバージョンを管理する。¹

シンプルなログ:

v1 (2024-01-15):レビューの感情を抽出してください。
結果:- 明確なケースはOK- エッジケースは不安定
---
v2 (2024-01-15):レビューを「ポジティブ」、「ネガティブ」、または「中立」に分類してください。例: [3つの例]
結果:- エッジケースは改善- しかし出力形式が一貫していない(時々「ポジティブ」、時々「Positive」)
---
v3 (2024-01-15):[v2の内容] + 制約: 小文字のpositive、negative、neutralのいずれか1つを正確に出力してください。
結果: すべてのテストケースをパス

これで、各変更が何をもたらしたかがわかり、新しいバージョンが悪化した場合は最後の良いバージョンにロールバックできる。

プラクティス3: 確信が持てない変更をA/Bテストする

変更が実際に役立つかどうか確信が持てない? 両方のバージョンを保持し、それぞれを10回実行して、成功率を比較する。これがA/Bテスト: 一度に1つの要因を変更し、データに決めさせる。

例: 「段階的に考えましょう」を追加することが本当に役立つかどうか確信が持てない。

• バージョンA(なし): 10回実行、7回正解
• バージョンB(CoTあり): 10回実行、9回正解

データが物語る。Bの方が良い。

プラクティス4: シンプルなバージョンから始める

500語の巨大なプロンプトから始めない。最もシンプルなバージョンから始め、進むにつれて制約を追加する。¹

反復パス:

v1: この記事を要約してください。   -> 曖昧すぎる
v2: この記事の核心的なポイントを3つの箇条書きで要約してください。   -> 箇条書きが長すぎる
v3: 核心的なポイントを3つの箇条書きで要約してください。各15語以内。   -> 形式がまだ一貫していない
v4: [v3] + 箇条書きリストを使用し、導入文なしでポイントのみを出力してください。   -> うまくいく

各ステップは正確に1つの問題を修正し、フィラーのない、ちょうど十分なプロンプトになる。

デバッグループ、最初から最後まで

完全なループはサイクルです: プロンプトを実行し、出力を確認し、一致しない場合は、問題を特定し、原因を診断し、1つのことを変更し、テストケースで検証し、一致するまで繰り返し、次に動作するバージョンを記録します。

以下の図は、そのループの各ステップを示しています:

graph TD    A[プロンプトを実行] --> B{期待通りの出力?}    B -->|はい| C[動作するバージョンを記録]    B -->|いいえ| D[具体的な問題を特定]    D --> E[原因を診断]    E --> F[1つのことを変更]    F --> G[テストケースで検証]    G --> B    C --> H[プロンプトライブラリにアーカイブ]

核心原則:

• 一度に1つのことを変更する
• すべての変更をテストケースで検証する
• バージョンとその結果を追跡する
• シンプルから始め、必要に応じて制約を追加する

チューニングをいつ止めるか

プロンプトのチューニングには自然な終わりはないが、十分な良さのバーがある:

止めても良い兆候:

• テストケースでの成功率が90%以上
• 出力形式が安定している
• プロンプトのすべての部分が何をするか説明できる
• 次の改善にかかる時間がその価値を超える

続けるべき兆候:

• 成功率が70%未満
• 同じ入力が実行ごとに大きく異なる出力を生成する
• プロンプトの一部が何をするかわからない
• エッジケースで失敗し続ける

実用的なルール: 十分良ければ十分、完璧を追求しない。90%の時間でうまくいくなら、残りの10%のエッジケースには人間が介入できる。

まとめ

プロンプトのデバッグループは: 具体的な問題を特定し、原因を診断し、小さな変更を加え、検証する。重要なのは、一度に1つの変数を変更し、すべての変更をテストケースで検証し、バージョンと結果を追跡することです。

よくある問題には、不安定な形式、情報の欠落、過剰な説明、意図の誤読が含まれます。それぞれに対応する修正があります: 例を追加し、フィールドをリストアップし、「のみを出力」制約を追加し、曖昧さを除外します。

シンプルなバージョンから始め、テストケースでの成功率が90%を超えるまで制約を追加します。うまくいくプロンプトのバージョンを記録して、次回再利用できるようにします。

次のレッスンでは、異なるタスクタイプのプロンプト戦略を扱います: コード生成、ドキュメント作成、データ分析に特有なものは何か。

次のレッスン 異なるタスクのプロンプト戦略 >>