AI に対する責任あるアプローチには、安全ポリシー、モデルの安全性を向上させる手法、透明性アーティファクトを構築する方法、そして生成 AI に対する責任を果たすためのアプローチは、単にチェックリストに従うことだけではありません。生成 AI プロダクトは比較的新しく、アプリケーションの動作は以前の形式のソフトウェアよりも大きく異なります。このため、使用されている ML モデルを精査し、モデルの動作の例を調べて、想定外のものを調査する必要があります。
現在、プロンプトは科学であると同時にアートでもありますが、Learning Interpretability Tool（LIT）など、大規模言語モデルのプロンプトを経験的に改善するのに役立つツールがあります。LIT は、AI/ML モデルを可視化、理解、デバッグするために開発されたオープンソース プラットフォームです。以下に、LIT を使用して Gemma の動作を調査し、潜在的な問題を予測して安全性を向上させる方法の例を示します。
LIT は、ローカルマシン、Colab、または Google Cloud にインストールできます。LIT の使用を開始するには、Colab にモデルと関連するデータセット（安全性評価データセットなど）をインポートします。LIT は、モデルを使用してデータセットの出力セットを生成し、モデルの動作を確認するためのユーザー インターフェースを提供します。
LIT を使用して Gemma モデルを分析する
 Codelab を開始
|
 Google Colab を起動する
|
この画像は LIT のユーザー インターフェースを示しています。上部の [Datapoint Editor]で プロンプトを編集できます下部の LM Salience モジュールで、顕著性の結果を確認できます。
複雑なプロンプトのエラーを特定する
高品質の LLM ベースのプロトタイプとアプリケーションで最も重要なプロンプト手法の 2 つは、少数ショット プロンプト（プロンプトで望ましい動作の例を含む）と、LLM の最終出力の前に説明や推論を行う思考の連鎖です。しかし、多くの場合、効果的なプロンプトの作成は依然として困難です。
好みに基づいて食べ物を好むかどうかを誰かに評価してもらう例を考えてみましょう。最初のプロトタイプの Chain-of-Thought プロンプト テンプレートは次のようになります。
Analyze a menu item in a restaurant.
## For example:
Taste-likes: I've a sweet-tooth
Taste-dislikes: Don't like onions or garlic
Suggestion: Onion soup
Analysis: it has cooked onions in it, which you don't like.
Recommendation: You have to try it.
Taste-likes: I've a sweet-tooth
Taste-dislikes: Don't like onions or garlic
Suggestion: Baguette maison au levain
Analysis: Home-made leaven bread in France is usually great
Recommendation: Likely good.
Taste-likes: I've a sweet-tooth
Taste-dislikes: Don't like onions or garlic
Suggestion: Macaron in France
Analysis: Sweet with many kinds of flavours
Recommendation: You have to try it.
## Now analyse one more example:
Taste-likes: {{users-food-like-preferences}}
Taste-dislikes: {{users-food-dislike-preferences}}
Suggestion: {{menu-item-to-analyse}}
Analysis:
このプロンプトに問題はありましたか？LIT では、LM Salience モジュールを使用してプロンプトを調べることができます。
シーケンス サリエンスをデバッグに使用する
顕著性は可能な限り小さいレベル（つまり、入力トークンごとに）で計算されますが、LIT はトークンの顕著性をより解釈しやすい大規模なスパン（行、文、単語など）に集約できます。顕著性の詳細と、それを使用して意図しないバイアスを特定する方法については、Interactive Saliency Explorable をご覧ください。
まず、プロンプトに prompt-template 変数の新しい入力例を与えます。
{{users-food-like-preferences}} = Cheese
{{users-food-dislike-preferences}} = Can't eat eggs
{{menu-item-to-analyse}} = Quiche Lorraine
完了すると、驚くべきモデルの完了が観察されます。
Taste-likes: Cheese Taste-dislikes: Can't eat eggs Suggestion: Quiche Lorraine Analysis: A savoury tart with cheese and eggs Recommendation: You might not like it, but it's worth trying.
食べてはいけないと明確に言ったものを食べることをモデルが示唆するのはなぜですか？
シーケンスの顕著性は、少数ショットの例にある根本的な問題を明らかにするのに役立ちます。最初の例では、分析セクションの Chain-of-Thought 推論が最終的な推奨事項と一致しません。「調理済みの玉ねぎが入っているので、好みではない」という分析は、「ぜひやってみてください」のレコメンデーションと組み合わされます。
これにより、最初のプロンプトのエラー（最初の少数ショットの例で推奨事項（You have to try it!）が誤ってコピーされていた）がハイライト表示されます。プロンプトの顕著性の強さは、紫色のハイライトが暗くなっています。顕著性が最も高いのは、最初の数ショットのサンプル、特に Taste-likes、Analysis、Recommendation に対応する行です。これは、モデルが最終的な誤った推奨事項を行うために、これらの行を最も使用していることを示唆しています。
また、この例では、初期のプロトタイピングにより、事前に想定していなかったリスクが明らかになる可能性があり、言語モデルはエラーが発生しやすい性質のため、エラーをプロアクティブに設計する必要があることも示しています。これについては、AI を使用したデザインに関する People + AI Guidebooks で詳しく説明しています。
仮説を検証してモデルの動作を改善する
LIT を使用すると、同じインターフェース内でプロンプトの変更をテストできます。この場合は、構成を追加してモデルの動作を改善してみてください。構成とは、モデルの生成の指針となる原則を含む設計プロンプトのことです。最近の手法では、憲法原則をインタラクティブに導き出すことさえ可能になっています。
この考え方を活用して、プロンプトをさらに改善しましょう。LIT の Datapoint Editor を使用して、生成の原則を含むセクションをプロンプトの上部に追加します。これは次のように始まります。
Analyze a menu item in a restaurant. * The analysis should be brief and to the point. * It should provide a clear statement of suitability for someone with specific dietary restrictions. * It should reflect the person's tastes ## For example: Taste-likes: I've a sweet-tooth Taste-dislikes: Don't like onions or garlic Suggestion: Onion soup Analysis: it has cooked onions in it, which you don't like. Recommendation: Avoid.
今回の更新により、この例を再度実行すると、出力が大きく異なることがわかります。
Taste-likes: Cheese Taste-dislikes: Can't eat eggs Suggestion: Quiche Lorraine Analysis: This dish contains eggs, which you can't eat. Recommendation: Not suitable for you.
その後、プロンプトの顕著性を再調査して、この変更が発生している理由を把握できます。
この例では、「食事制限のある人への適合性を明確に提示する」という原則と、その料理に卵が含まれているという説明のための分析ステートメント（いわゆる思考の連鎖）に影響されています。
非技術チームをモデルのプローブと探索に参加させる
解釈可能性とは、ポリシーや法務などの専門知識に及ぶ、チームの取り組みとして期待されるものです。これまでに見てきたように、LIT の視覚的媒体とインタラクティブな機能により、顕著性を調べて例を探索できるため、さまざまな関係者が調査結果を共有し、伝達できます。これにより、より多様なチームメイトを参加させて、モデルの探索、プローブ、デバッグを行うことができます。これらの技術的な手法を知ることで、モデルの仕組みをより深く理解できます。さらに、初期モデルのテストにおけるより多様な専門知識は、改善できる望ましくない結果を明らかにするうえでも役立ちます。
まとめ
モデル評価で問題のある例が見つかった場合は、デバッグのために LIT に取り込みます。まず、モデリング タスクに論理的に関連していると思われる最も意味のあるコンテンツ単位を分析し、可視化を使用して、モデルがプロンプト コンテンツに正しく、または誤って対応する場所を確認します。次に、コンテンツの小さな単位にドリルダウンして、発生している誤った動作をさらに記述し、修正可能な修正を特定します。
デベロッパー リソース
- LIT ウェブサイト
- AI を使用したデザインのための People + AI Guidebook