[AWS Summit Japan 2024 現地レポ]プロンプトエンジニアリングのコツを拾ってきた
当日の動き
早速ですが、当日の動きを含めて現地レポートをご紹介します。
まずはざっくりとした当日の動きです。
- 9:00 海浜幕張駅到着☔️
- 9:20 会場入場(※まだブースなどは関係者以外入れないためひたすら待機)
- 10:00〜11:30 基調講演
- 11:50〜12:30 セッション
- 〜14:00 お昼休憩をしつつ各ブース徘徊🚶
(午後から私用があり半日ほどの滞在でした。。)
全体的な所感
- やはりAI関連のトピックが熱い🔥
- Amazon Bedrockなど、基調講演でもAIのトピックがメイン
- 150以上の多様なセッションがあるが、どれもかなり人気で満席が目立つ
- なるべく早めの予約が吉(予約後のキャンセル可)
- 2日前の申し込み時点で気になるセッションはことごとく満席
- 満席でもキャンセルが出る可能性があるため、定期的に申し込み状況を確認すべき
- 興味のあるセッションが被る可能性が高いため、複数人で行って後でシェアするのがお勧め(後日オンデマンド配信もあるが期間限定)
- Partner Solution Expo(企業の展示ブース)
- 企業のオリジナルグッズなどが貰え、活気もあり楽しい!
その他現地情報
- 人は多いが会場が広いためスムーズに回れる
- お手洗いは時間帯によって並ぶため要注意
- 先着でお弁当が無料で貰える(基調講演の指定席券に引換券が付いている)
- 基調講演を見に行く時間帯にはペットボトルのドリンクが無料で配られていたため、飲み物は持参必須ではない
- お弁当配布時と企業ブースでもドリンクを貰ったため、自前で持っていくと逆に荷物になる可能性も
- セッションの間が20分くらいしかないため、予定を詰めすぎは注意
写ってはないですが、左側にももう1つ大きい会場がありました。
なんとSnowball Edgeの現物が!!
セッションについて
セッションの種類は大きく分けて以下の3つです。
- 「AWSセッション」:AWSのエキスパートが各種テクノロジーを解説する
- 「パートナーセッション」:AWSのパートナーが技術や取り組みを語る
- 「事例セッション」:AWSの顧客がAWSの導入事例を語る
また「AWSセッション」については難易度に応じてレベル(数字)が割り振られているため、
レベル感を見て受講することをお勧めします
- Level 100 : 入門者向け
- Level 200 : 初級者向け
- Level 300 : 中級者向け
- Level 400 : 上級者向け
より具体的なレベル感についてはこちらの記事をご覧ください。
参加セッション
以下のセッションに参加しました。
- 参加セッション:『大規模言語モデルのプロンプトエンジニアリングのコツ』
- Level 300(中級者向け)
- 概要:プロンプトエンジニアリングのテクニックをClaude特有のプロンプトを中心に紹介。
全体のタイムテーブルはこちらです。
セッション内容
まずは紹介されていたテクニックの一覧です。
テクニック一覧
- 明確かつ直接的に
- XMLタグの利用
- 例示
- 出力形式の指定&Claudeの代弁
- 考える時間を与える
- 役割のアサイン
- ハルシネーションへの対処
- 不適切なユーザー入力への対処
- プロンプトチェーン
- 長い文章でのテクニック
ただし、全てのプロンプトにこれら全ての要素が必要というわけではありません、
まずは高い精度を出せるように要素を増やした後に削っていくのが良いとアプローチだと解説されていました。
適切なプロンプトを設計する方法
- 経験の科学:常にプロンプトをテスト、頻繁に反復
- 評価データを作成(※エッジケースも用意)⇒準備用のプロンプトを作成⇒評価データでテスト⇒プロンプト修正⇒完成
まず、プロンプトの設計という点で新しい視点を得られました。
今まではとりあえず思いつく限りの指示を与え、
期待通りの回答でなければ都度足りていなさそうな指示を補足して期待通りの回答に近づくまで対話を繰り返していました。
しかしこれまで評価データを作成したことがなく、そもそも「プロンプトを設計する」という意識もありませんでした。
今後、繰り返し使用するプロンプトについてはこのような設計の観点を意識しようと思います。
Claude3のAPIフォーマットについて
前提として、本セッションではClaude3を取り上げて解説されていました。
- Claude3は”user”(人間の入力)と”assistant”(Claudeの出力)を交互に繰り返す形で対話を進める
- APIリクエストのJSONで
”role”: "user"
と指定して質問する
- APIリクエストのJSONで
つまり以下のような指示であれば、ユーザーがClaudeに対して「なぜ空は青いのですか?」という質問をする意味になります。
{
"role": "user",
"content": "なぜ空は青いのですか?"
}
より詳細なAPIの使用方法はユーザーガイドをご覧ください。
明確かつ直接的に
- 明確で直接的な指示に最もいい答えを出す
- 自分のプロンプトを他人に見せて、求めている結果を相手が出せるか聞いてみる
こちらはClaudeに限らず、どのLLMでも同じかと思います。
人間もLLMも心までは読めないので、明確な指示の重要性はセッション内で強調されていました。
XMLタグの利用
- 区切り目がないとClaudeは理解しにくい
- XMLタグを使うとClaudeがプロンプトの構造を認識しやすくなる
XMLとはHTMLと似たようなマークアップ言語で、以下のようにタグを使って文書を構造化することができます。
食べたいものリスト
<foods>
<food>カレー</food>
<food>ラーメン</food>
<food>寿司</food>
</foods>
LLMは次に来る単語やフレーズを確率的に予測して出力するため、
構造化を行うことでよりその精度が高まるというわけです。
ちなみに構造化による精度の向上はClaudeに限らずどのLLMでも同じかと思います。
例えば、マークダウンでも構造化が可能です。
例示
例示とは、プロンプトにいくつかの適切な使用例を提供することです。
- 例はいくつ必要か?(※以下2024年6月時点の情報)
- 最適な例の数に厳しいルールはない
- 少なくとも3〜5この例を含むことを目指す
- Claudeの振る舞いが期待通りでない場合は、例を幾つ追加してもいい
- Claude2.0に128個以上の例を与えても精度が向上した実験がある
- 悪意のある例を増やすと、悪意のある回答が出力される可能性も上がる
また、前述のように例示についてもXMLタグを利用して<example></example>
タグで囲むことをお勧めします。
Claudeが使用例とそれ以外の部分を簡単に区別できるようになります。
出力形式の指定&Claudeの代弁
こちらはClaudeに行って欲しいことを正確に言わせるためのテクニックです。
- 出力のフォーマットを指定し、Claudeの代弁として出力の一部を書く
以下のようなイメージです。
// User(入力)
猫についての俳句を書いてください。
"first_line", "second_line", "third_line"
をキーとしてJSONフォーマットを使用してください。
// Assistant(出力):代弁として出力を書き始める
{
この例ではJSONフォーマットでの回答が欲しいケースであるため、
{
という出力の書き始めを与えています。
考える時間を与える
「考える時間を与える」とは、複雑な質問やタスクを与えた際にClaudeに問題を段階的に考えてもらうように指示をするということです。
これによりClaudeの思考過程を知ることができ、プロンプトの不明確さのトラブルシューティングが可能になります。
- 思考過程と回答の出力形式を指定する
- 例: 答える前に、
<thinking></thinking>
XMLタグ内で質問について考えてください
- 例: 答える前に、
これも自身にとって新しい視点になりました。
確かに思考過程がわかれば、どのように指示を改善すればいいかが明白になります。
指示の明確性でも述べましたが、やはり基本的にはLLMも人間と同じということです。
一気に複雑なタスクを行うよりも段階的に行う方が精度が上がるようです。
役割のアサイン
役割のアサインは割と有名なテクニックではないでしょうか。
膨大な情報から特定の回答を作るよりも、ある程度背景情報が絞られた方が精度が向上するのは感覚的にわかると思いました。
- Claudeに役割を認識させることで回答が変わってくる
ハルシネーションへの対処
ハルシネーションとは、AIが事実に基づかない情報を生成する現象のことを指します。
普段からAIを利用している方は一度はこの現象に遭遇したことがあるのではないでしょうか。
- Claudeがわからない場合に 「知らない」と言う許可を与える
- Claudeが自分自身の回答に自信がある時だけ答えるように言う
- Claudeに長いドキュメントの中から適切な引用を見つけてその引用を使って答えるように頼む
上記のように依頼することでハルシネーションの発生を抑制することができるようです。
こちらも新たな学びでした。
不適切なユーザー入力への対処
こちらは不適切または有害なコンテンツを生成することを目的とした行為への対処についてです。
- Claudeはプロンプトインジェクションや不適切な入力に対して元来耐性が高い(他の主要な大規模言語モデルと比較して)
- 不適切なら応答をブロックするように指示
このテクニックは個人で質問するだけならあまり利用機会がないかと思いますので、割愛します。
詳細は以下のガイドをご確認ください。
プロンプトチェーン
1つのプロンプトで処理させるタスクが多くなればなるほど、精度が低下する可能性が高くなります。
そこで、あるプロンプトの出力を別のプロンプトの入力として使用すること(=プロンプトのチェーン化)により精度の向上を狙います。
- ステップ数の多いタスクではタスクを分割する
こうすることで各ステップでの精度向上が期待できるので、複雑なタスクもこなすことが可能です。
また、トラブルシューティングも容易になるため軌道修正も行い易いことがメリットだと思います。
長い文章でのテクニック
長い(10K〜100Kトークン)プロンプトでは以下を行うことが推奨されていました。
前述の内容の複合技のようなイメージですね。
- 後から質問するとあらかじめ伝える
- XMLタグで構造化をする
- 引用を見つけさせる
- 例:質問に答える際はまず引用をみつけ、<quote></quote>XMLタグで示してください
- プロンプトの最後で質問をする
最後に
1人で拾える情報には限界があるため、可能であれば複数人で行くことをお勧めします!
大きなイベントはただただ楽しいですし、熱気に触れてモチベーションが上がりました👏
セッションの内容までご紹介したため少し長くなりましたが、最後までお読みいただきありがとうございました!!
おまけ
現地参加された方は全体アンケートに答えると25ドル分の販促クレジットが貰えます。
AWS Summitに行き、使ってみたいサービスを見かけたらこれを利用して実際にサービスを触ってみるのも良さそうですね!
最上部に載せた写真の看板裏にはメッセージが(こういうさりげないこだわりが好き)
Discussion