実際のアプリケーションのプロンプトを作成する際には、簡潔さと効果のバランスという重要なトレードオフが生じます。すべての要因が同じ場合、簡潔なプロンプトは長いプロンプトよりも高速で、費用対効果が高く、保守が容易です。これは、レイテンシとトークン上限が重要なウェブ環境で特に重要です。ただし、プロンプトが最小限すぎると、モデルが高品質の結果を生成するためのコンテキスト、指示、例が不足する可能性があります。
評価主導開発（EDD）を使用すると、このトレードオフを体系的にモニタリングして最適化できます。EDD は、出力を小規模で確実なステップで改善し、回帰を検出し、モデルの動作をユーザーとプロダクトの期待に沿って調整するための、再現可能でテスト可能なプロセスを提供します。
これは、AI の不確実性に対応したテスト駆動開発（TDD）と考えることができます。決定論的な単体テストとは異なり、AI 評価はハードコードできません。出力（整形式のものと失敗したもの）は予期しない形式になる可能性があるためです。
EDD は、ディスカバリの取り組みもサポートします。テストを作成することで機能の動作が明確になるのと同様に、評価基準を定義してモデルの出力を確認することで、不明確な点に直面し、オープンエンドのタスクや不明なタスクに徐々に詳細と構造を追加していくことができます。
問題を定義する
入力タイプ、出力形式、追加の制約など、API 契約のように問題をフレーム化できます。次に例を示します。
- 入力タイプ: ブログ投稿の下書き
- 出力形式: 3 つの投稿タイトルを含む JSON 配列
- 制約: 128 文字未満、親しみやすいトーンを使用
次に、入力例を収集します。データの多様性を確保するため、理想的な例と実際の複雑な入力の両方を含めます。絵文字を含む投稿、ネストされた構造、多くのコード スニペットなど、バリエーションやエッジケースについて考えてみましょう。
ベースラインを初期化する
最初のプロンプトを入力します。ゼロショットから始めて、次のものを含めることができます。
- 明確な指示
- 出力形式
- 入力変数のプレースホルダ
評価と最適化を行う際は、複雑さを増し、他のコンポーネントや高度なプロンプト技術を使用します。まず、最適化の取り組みを正しい方向に導くための評価システムをセットアップする必要があります。
評価システムを作成する
TDD では、要件がわかったらテストの作成を開始します。生成 AI にはテスト対象となる明確な出力がないため、評価ループの作成にさらに力を入れる必要があります。
効果的に評価するには、複数の測定ツールが必要になる可能性があります。
評価指標を定義する
評価指標は決定的です。たとえば、モデルが有効な JSON を返すかどうか、または正しい数のアイテムを出力するかどうかを確認できます。
ただし、明確さ、有用性、トーン、創造性などの主観的または定性的な指標を特定して改善することに、多くの時間を費やす必要があります。広範な目標から始めるかもしれませんが、すぐに複雑な問題に直面する可能性があります。
たとえば、タイトル生成ツールが特定のフレーズやパターンを過度に使用し、結果が繰り返しで機械的なものになることがあります。その場合は、バリエーションを促し、過度に使用されている構造やキーワードを抑制する新しい指標を定義します。時間の経過とともに、コア指標が安定し、改善を追跡できるようになります。
このプロセスでは、アプリケーションのドメインで「良い」状態がどのようなものかを理解し、微妙な障害モードを特定できる専門家のサポートが役立ちます。たとえば、ライティング アシスタントを開発している場合は、コンテンツ プロデューサーや編集者と協力して、評価がその世界観と一致するようにします。
審査員を選択する
評価基準が異なると、評価者も異なります。
- コードベースのチェックは、確定的またはルールベースの出力に適しています。たとえば、タイトルをスキャンして回避したい単語を探したり、文字数を確認したり、JSON 構造を検証したりできます。これらは高速で繰り返し可能であり、ボタンやフォーム フィールドなどの固定出力 UI 要素に最適です。
- トーン、明瞭さ、有用性など、より主観的な品質を評価するには、人間のフィードバックが不可欠です。特に初期段階では、モデルの出力を自分で（またはドメイン エキスパートと一緒に）確認することで、迅速な反復が可能になります。ただし、このアプローチはスケーリングが容易ではありません。アプリをリリースすると、星評価などのアプリ内シグナルも収集できますが、ノイズが多く、正確な最適化に必要なニュアンスが欠けている傾向があります。
- LLM-as-judge は、別の AI モデルを使用して出力をスコアリングまたは批評することで、主観的な基準をスケーラブルに評価する方法を提供します。人間によるレビューよりも高速ですが、落とし穴もあります。ナイーブな実装では、モデルのバイアスや知識のギャップが永続化し、強化される可能性もあります。
量より質を優先します。従来の ML と予測 AI では、データ アノテーションをクラウドソーシングするのが一般的です。生成 AI の場合、クラウドソーシングのアノテーターはドメイン コンテキストを理解していないことがよくあります。規模よりも、質の高いコンテキスト豊富な評価が重要です。
評価と最適化
プロンプトをテストして調整する速度が速いほど、ユーザーの期待に沿った結果を早く得ることができます。継続的な最適化を習慣にする必要があります。改善を試して評価し、別のことを試します。
本番環境に移行したら、ユーザーと AI システムの動作を継続的にモニタリングして評価します。次に、このデータを分析して最適化ステップに変換します。
評価パイプラインを自動化する
最適化の取り組みにおける摩擦を軽減するには、評価を自動化し、変更を追跡し、開発と本番環境を接続する運用インフラストラクチャが必要です。これは一般に LLMOps と呼ばれます。自動化に役立つプラットフォームはありますが、サードパーティ ソリューションを導入する前に、理想的なワークフローを設計する必要があります。
考慮すべき主なコンポーネントは次のとおりです。
- バージョニング: プロンプト、評価指標、テスト入力をバージョン管理に保存します。コードとして扱うことで、再現性と明確な変更履歴を確保します。
- バッチ評価の自動化: ワークフロー（GitHub Actions など）を使用して、各プロンプトの更新で評価を実行し、比較レポートを生成します。
- プロンプトの CI/CD: 決定論的テスト、LLM-as-judge スコア、ガードレールなどの自動チェックでデプロイをゲートし、品質が低下したときにマージをブロックします。
- 本番環境のロギングとオブザーバビリティ: 入力、出力、エラー、レイテンシ、トークンの使用状況をキャプチャします。ドリフト、予期しないパターン、障害の急増をモニタリングします。
- フィードバックの取り込み: ユーザー シグナル（高評価、書き換え、放棄）を収集し、繰り返し発生する問題を新しいテストケースに変換します。
- テスト追跡: プロンプト バージョン、モデル構成、評価結果を追跡します。
小規模で的を絞った変更を繰り返す
通常、プロンプトの改善は、プロンプトの言語を改善することから始まります。たとえば、指示をより具体的にしたり、意図を明確にしたり、曖昧さを解消したりします。
過適合に注意してください。よくある間違いは、モデルの問題を修正するために狭すぎるルールを追加することです。たとえば、タイトル生成ツールが「The Definitive Guide」で始まるタイトルを生成し続ける場合、このフレーズを明示的に禁止したくなるかもしれません。代わりに、問題を抽象化して、上位レベルの命令を調整します。たとえば、独創性、多様性、特定の編集スタイルを重視することで、モデルは単一の例外ではなく、根底にある好みを学習します。
もう 1 つの方法は、より多くのプロンプト技術を試し、これらの取り組みを組み合わせることです。手法を選択する際は、このタスクはアナロジー（フューショット）、ステップバイステップの推論（チェーン オブ ソート）、反復的な改善（自己反省）のいずれで最適に解決できるかを自問します。
システムが本番環境に移行しても、EDD フライホイールの速度が低下することはありません。むしろ、加速させるべきです。システムがユーザー入力を処理してログに記録している場合は、これが最も貴重な分析情報源となります。評価スイートに繰り返しパターンを追加し、次の最適な最適化手順を継続的に特定して実装します。
要点
評価主導のプロンプト開発により、AI の不確実性を構造的に解消できます。問題を明確に定義し、カスタマイズされた評価システムを構築し、小規模で的を絞った改善を繰り返すことで、モデル出力を着実に改善するフィードバック ループを作成できます。
リソース
LLM を審査員として実装する場合は、次のドキュメントを読むことをおすすめします。
- LLM の機能と要約を比較する。
- Hamel Husain の LLM-as-a-Judge の使用に関するガイドを読む。
- 論文「A Survey on LLM-as-a-Judge」をお読みください。
プロンプトの改善に関心がある場合は、コンテキスト認識開発の詳細をご覧ください。これは、機械学習エンジニアが最適に行うことができます。
理解度を確認する
評価主導開発の主な目標は何ですか？
クライアントサイド システムの評価に大規模なモデルを使用する理由
評価に LLM を判定モデルとして使用する場合の潜在的な落とし穴は何ですか？
推奨される自動評価パイプラインの一部であるコンポーネントはどれですか？
評価システムの審査員を選ぶ際に、人間のフィードバックを使用する主な制限事項は何ですか？