🐕
[つぶやき]プロンプトにおいてどれくらい評価設定は大事なんだ？
概要
想定読者：
-
プロンプトエンジニアリングを学び始めて、評価とかの話を考え始めてなんだ？ってなった方
経緯
- ネットで得た内容をもとに、強くは意識せずに生成aiを利用していた昨今でしたが、一度プロンプトエンジニアリングは体系的に学ぶべきだなと言う気持ちが強くなっていた
- 手始めとして、以下の書籍を学び始めたらいきなり「限定的な評価」の文言が他の「例を示す」等より解像度が浅く整理したいと感じた
そもそも
-
上記書籍で、記載されている「プロンプトの5つの原則」
- 方向性を示す
- 出力形式を指定する
- 例を示す
- 品質を評価する
- タスクを分割する
-
5つとも確かにな〜と思いつつ、こと「品質を評価する」だけはあまり普段やっとらんぞ...と感じた
-
と言うのも、以下のように口語で雑にやりとりする時でも他の4つは自然と記載しているなと感じたからだ
- 方向性を示す：xxxxの方針のもと、で文字として出力して。
- 出力形式を指定する：yyyyを真似てmermaidで作成して
- 例を示す：例)..... ※あくまで例示であり内容は参考にしないで
- タスクを分割する：ステップバイステップで進める前提のもと、zzzzについての議論を私に問いを投げかける方針で出力して
-
ただ、品質を評価するに関しては、以下のような簡単な評価？しかしたことがなくて心掛けている間が少なかったと認識した(これくらいはしたことあるかな？というのを記載してみた)
- XXXX点以上：A, YYYY点以上：B, ZZZZ点以上：Cのもと各種要素を箇条書きで出力して
- gptsにて、XXXX性, YYYY性, ZZZZ性を3点満点で私の連絡内容をレビューして8~ならば晴れ、5~ならば曇り、~4ならば雨という3種類の天気で出力して
-
※後、生成AIに役割を与えて出力させる「ロールプロンプティング」も自然とやってると感じた
なので方法を整理させた上で、表にする
- 参考図書の該当箇所を整理してもらった
- 「限定的な評価」に関しては、つまるところ再現性の高いプロンプト結果にするには、意図的に設定された評価軸が必要であると認識できた
- ただ、どの時点でどのように評価を設定すべきなのかを自分は考えるべきだと思った
- というのもプロンプトを丁寧に書けば丁寧に書くほど、業務生産性が上がるかと言われたら一概には言えないと思っていて、時と場合においては下記のブラインドプロンプティングの方が適している場面は往々にしてあると感じているからだ
- 自分は評価に向けてどのように向き合うのか、と思って表を作成してみた
- 様々な箇所でお話しされている内容ではあるが、一定評価以上を叩き出してくるaiモデルが乱立している中で、正しくaiモデルを搭載していると判断できる評価軸を設定できる能力は必ず求められてくるのではないか
| プロンプト具体例 | 主な 評価アプローチ |
備考 |
|---|---|---|
| 雑談で気になったことなど、スポットで今後使わないであろう内容のプロンプト | ブラインドプロンプティング | 一時的な問いへの応答をざっくり確認したい場面。再現性や評価精度は重視しない。 |
| スポットではあるが、定量的に判別したい等の出力を希望するプロンプト | LLMを活用した評価 | コスト効率の高い自動判定。分類やスコアリング、計算の妥当性確認などに適している。 |
| プログラムによる評価 | 正解が明確な分類・数値・ルール判定ができるケースでは、最も迅速かつ確実な評価が可能。 | |
| 検証環境で実施した集計負荷試験の結果分析のプロンプト | 多段階評価 | レポートの品質・表現の明瞭さなど、主観と精度を両立して判断したい場面。 |
| LLMを活用した評価 | 要約や分析コメントの妥当性を迅速かつ多角的に評価できる。人手評価の補助にも有効。 | |
| gpts, ないしワークフロー等の汎用的に利用するものを作成するためのプロンプト | 性能評価ベンチマーク | 汎用性や再現性を重視。標準化されたタスクで比較することで安定性を確認できる。 |
| プログラムによる評価 | 出力構造の一貫性・ルール準拠・分類の正確性などを自動検証可能。 | |
| 安全性評価（ハルシネーション検出含む） | 長期運用を前提に、誤情報生成や不適切出力を防止。RAGやフィルターとの連携も有効。 | |
| 並列比較 | 複数の案を比較して最適な出力を選びたい場合に有効。相対的に優れたプロンプトを選定可能。 | |
| 公開前のgptsの対話文がユーザーにとって自然か・好ましいかを確認したいプロンプト | 人間による評価 | トーン・流れ・共感性など、主観的な視点が必要な場面で活躍。公開品質を担保したいとき。 |
| 初期段階のプロンプト実験に対してチームで素早くフィードバックを回したいプロンプト | 簡易評価システム（👍👎など） | JupyterやSlack上でのライトなレビュー。プロンプト改善の初期サイクルを回したいとき。 |
以下、1章 プロンプトの5つの原則-1.5第4の原則「品質を評価する」の内容を整理させていただきました🙇
• 評価方法とアプローチ
◦ ブラインドプロンプティング: これは、プロンプトを実行して応答を確認するという単純な試行錯誤の方法です。一時的で単一のタスクには問題ありませんが、本番環境での利用には不十分です。
◦ 性能評価ベンチマーク: 特定のタスクに対して標準化された質問集と事前定義された回答や評価基準を用いて、モデルの性能をテストし、複数のモデル間で比較するものです。OpenAIは、LLMの性能評価ベンチマークのフレームワークである「OpenAI Evals」をオープンソース化しています。
◦ 人間による評価: 最も正確なフィードバック形式とされていますが、多くのサンプルを手動で評価するのは退屈で費用がかかる可能性があります。
▪ 簡易評価システム: Jupyter Notebookのような環境で「高評価（👍）」と「低評価（👎）」のボタンを実装し、応答を迅速にラベル付けすることで、プロンプトの最適化に一定の厳密さを加えることができます。
▪ 多段階評価: 3段階、5段階、または10段階の評価システムを導入することで、プロンプトの品質に対してより詳細なフィードバックを得ることが可能です。
▪ 並列比較: 複数の応答を並べて比較することで、相対的な性能を判断できます。チェスのランキングシステムであるEloレーティングが例として挙げられています。
◦ LLMを活用した評価: 高度なモデルを使用して、あまり洗練されていないモデルの応答を評価する方法が一般的になりつつあります。
▪ これにより、人間によるレビューよりも桁違いに安価で、数分で評価が完了するというメリットがあります。
▪ ただし、複雑な評価の場合は、評価者であるLLM自体の評価に時間をかけることが重要です。偽陽性（ハルシネーション）や偽陰性（見逃し）の数を数えることで、評価者自身の精度を確認できます。
◦ プログラムによる評価: 数学や分類など、真の正解（Ground Truth）が確立可能なタスクでは、プログラムによって結果を評価することで、テストと監視の規模を大幅に拡大できます。具体的には、以下の観点で評価が可能です。
▪ 費用の削減: トークン使用量が多いプロンプトや高価なモデルの費用対効果を検証。
▪ 遅延の対策: 遅延がユーザー体験に与える影響を検証。
▪ 呼び出し回数の削減: ループ処理の削減を検証。
▪ 性能の改善: 物理演算エンジンなどの外部フィードバックシステムの実装。
▪ 分類の精度向上: LLMやルールベースのラベル付けによるテキスト分類の頻度を測定。
▪ 推論の精度向上: 論理的推論や数学的誤りの発生箇所を分析。
▪ ハルシネーションの回避: プロンプトのコンテキストにない新しい言葉の組み合わせが生成される頻度を確認。
▪ 安全性の確保: 安全フィルターや検出システムによる不適切な内容の検出。
▪ 誤検知の削減: 正当なユーザー要求が誤って拒否される頻度を調査。
▪ サイバー攻撃への対策: プロンプトインジェクションへの対策を施す。
▪ 類似性の評価: 生成されたテキストと参照テキストの類似性をBLEUやROGUE、ベクトル距離（コサイン類似度）などで測定
これから
- プロンプト作成時に「品質を評価する」を意識し、画一というより場面に応じて適した評価方法・評価軸を設定することが、普段の生成aiの利用~プロダクトへの利用等の様々な場面でのプロンプト利用において有効ではないか
- モデルの精度向上によりぽいものはどのような設計でも出力されてしまう。なので品質評価方法・軸の設定は必須だが、目的を踏まえるとやりすぎな詳細設定はむしろ生成ai特有の手軽さという良さを半減させてしまうとも感じた。
- だからこそ意識する中で適した評価方法・評価軸を場面・目的に応じて設定することが求められる。
- 適した評価方法・評価軸によって出力された評価は、普段のプロンプトであれば労力以上の出力結果の汎用性を保証してくれるだろうし、プロダクトに搭載する際の不確実性に耐えうる共通言語として利用できるのではないか
むっちゃしっくりきた記事
Discussion