『Prompt Engineering for Generative AI』読書メモ
雑感
2024年5月の本なので記述に古い部分があるであろうことに注意。
- 序文では、今後5年間のAIの変化に耐えうるスキルを共有すると書かれてはいる
- 原則の部分は確かにそうかもしれない
- 具体的な記述は古くなっているものもあるはず
2章で、執筆時点までのざっとしたLLMの歴史と各社のLLMの特徴についてまとめられている。
- あまり追えていなかった身としてはありがたい
4章以降では、RAGやLangChainなどを試すためのコードと解説が記載されているので、試しながら学ぶことができる。
- PineconeというSaaSの使い方（軽め）なども（Pinecone初めて知った）
全体的に、生成AIを使ってアプリケーションを作る人向けに見える。
- 1章（プロンプティングの5原則）・2章（モデルの紹介）・3章（テキスト生成の標準プラクティス）は他の人でも学びになる
- 他の章も、生成AIアプリケーションの仕組みを知るという意味で学びになる
『LLMのプロンプトエンジニアリング』と比べて、LangChainを使ったLLMアプリケーション構築や画像生成といったテーマが含まれている。
- 他の箇所（例えば品質評価）に関しては『LLMのプロンプトエンジニアリング』の方が詳しい部分もある
- 『Prompt Engineering for Generative AI』は画像も範疇なので「LLM」ではなく「Generative AI」なのかもしれない
理解の整理
プロンプティングの5つの原則
- 明確な方向性
- フォーマット指定
- 例示
- 品質評価
- 分業
- 製品にAIモデルを組み込むのであればプロンプトの工夫が必要
- 期待していない出力が返ってくるプロンプトの場合、下記のコストがかかるため
- プロンプトと出力の長さに応じてAIモデルにかかる料金が増える
- 期待通りでない出力をユーザーが修正するのに時間がかかる
- 期待していない出力が返ってくるプロンプトの場合、下記のコストがかかるため
1. 明確な方向性
- 問題
- 提示する方向性が曖昧だと、的はずれな出力がされてしまう
- 対応
- どういう出力を期待しているのかをAIに明示する
- 役割を与える
- 外部規則を取り込む
- プレウォーミング
- まず問題領域のベストプラクティスのアドバイスを求め、その後そのアドバイスに従うよう指示する
- メタプロンプト
- AI自身に別のAIまたは自身のためのプロンプトを生成させる
- どういう出力を期待しているのかをAIに明示する
補足
メタプロンプトは、few-shotプロンプトと比較して、トークンの効率・公平な比較・ゼロショット有効性という点で優れているという研究もある模様。
2. フォーマット指定
- 問題
- AIからの出力をプログラムで解析するのが困難な場合がある
- 番号付きリストが返されることもあれば、先頭にテキストが付いていることもある
- AIからの出力をプログラムで解析するのが困難な場合がある
- 対応
- jsonやymlなどのフォーマットを指定する
3. 例示
- 問題
- 例示しない場合、AIはトレーニングデータの平均的情報を使って補完を行うが、それが本当に期待する出力とは限らない
- 対応
- 期待する出力の例を挙げる
- 例を1つ提供するだけ（one-shot）でも効果がある
- 研究者の間では、複数の例（few-shot）で検証するのが標準になっている
- 期待する出力の例を挙げる
補足
推論モデルでは、まずzero-shotを試し、必要に応じてfew-shotするのがよいらしい。
Try zero shot first, then few shot if needed: Reasoning models often don't need few-shot examples to produce good results, so try to write prompts without examples first. If you have more complex requirements for your desired output, it may help to include a few examples of inputs and desired outputs in your prompt. Just ensure that the examples align very closely with your prompt instructions, as discrepancies between the two may produce poor results.
4. 品質評価
- 問題
- 評価が無いか限定的な場合、再利用に耐えうるプロンプトを作成できない
- 出力を手動で評価する場合、コストがかかる
- 対応
- 出力を評価し、出力の有効性を左右する要因を検証する
- 人間による評価
- 出力ごとに評価する
- 良い・悪いでのラベリング
- 1〜10点等の段階評価
- 出力ごとに評価する
- 自動評価
- より高度なLLMを用いて出力を評価する
- 例えば、GPT-4でGPT-3.5-turboの出力を評価する
- LLMは人間レベルの評価者であるという研究も、LLMの評価方法に矛盾があるとする研究もある
- 著者は、GPT-4によるGPT-3.5-turboの出力への評価は信頼性が高いとしている
- より高度なLLMを用いて出力を評価する
- 人間による評価の方がコストが高く時間もかかるため、最終的には手動レビューをする場合でも自動評価を行うことでコスト削減できる
補足
プロンプトを実行して結果を確認するだけ、という方法は「ブラインドプロンプティング」と呼ばれるらしい。 （この記事は本（1章の4）の中で紹介されていたもの）
今日、プロンプトエンジニアリングを実践していると主張する人の多くは、実際には単なるブラインドプロンプティングです。
「ブラインドプロンプティング」とは、最小限のテスト、あるいは全くテストを行わず、プロンプティングに関するごく表面的な知識のみで、大まかな試行錯誤のアプローチでプロンプトを作成する手法を指すために私が用いている用語です。
ブラインドプロンプティングはプロンプトエンジニアリングではありません。
「テストがないコードはレガシーコードだ！」を思い出してしまった
品質評価は『LLMのプロンプトエンジニアリング』でも取り上げられていた。
- 『Prompt Engineering for Generative AI』では、「出力が簡潔であれば1、冗長であれば0と評価するように」といったプロンプト例でLLMに評価させている
- 『LLMのプロンプトエンジニアリング』では、「1から5の尺度で採点してください」といった段階評価になっており、1〜5が何を意味するかも提示する方法が紹介されていた
- SOMAアセスメント
- 後者のほうがより精度が高そうに思う
5. 分業
- 問題
- プロンプトが長く複雑になると、出力精度が落ち、幻覚や異常が増加する
- 対応
- タスクを複数のステップに分割し、複雑な目標を達成するために連鎖して実行する
- 例: 1つずつ考えてみましょう。以下の製品名リストを評価してください。あらゆる足のサイズに合う靴のペアに適した製品名です。評価は10点満点で、製品名の横に直接記入してください。
補足
1つずつ考えてみましょう はChain of Thoughts(CoT)、思考の連鎖だが、o3系等の推論モデルでは、プロンプトに指定不要とされている。
Avoid chain-of-thought prompts: Since these models perform reasoning internally, prompting them to "think step by step" or "explain your reasoning" is unnecessary.
GPT4.1などの非推論型のモデルでは、ベストプラクティスとして紹介されている。
As mentioned above, GPT-4.1 isn't a reasoning model, but prompting the model to think step by step (called "chain of thought") can be an effective way for a model to break down problems into more manageable pieces.
RAG・ベクトルデータベース
- 問題1
- 小規模なタスクであれば、ドキュメントや製品リストをAIに渡してもトークン制限内に収まるが、大規模なタスクでは制限内に収まらずコスト過剰になるリスクが有る
- 対応1
- Retrieval Augmented Generation(RAG)=検索拡張生成を利用する
- ユーザーの入力をベクトル化し、ベクトル検索した結果をプロンプトにコンテキストとして含めてAIに投げる
- 問題2
- 例えば、チャットボットとの会話で、トレーニングデータに含まれていない質問をされると、チャットボットは事実を捏造する=幻覚を起こす傾向がある
- 対応2
- ベクトル検索で、ユーザーの入力と意味的に類似した文書を見つけ、それをプロンプトにコンテキストとして含めることで幻覚のリスクを大幅に下げられる
- データソースとして扱うドキュメントをチャンクに分割する際に工夫が必要
- チャンクを大きくしすぎると、平均回帰が起こり、すべてのベクトルの平均に近づき、意味的な情報がほとんど含まれなくなる
- チャンクを小さくしすぎると、文や段落の途中でテキストが途切れてしまい、意味が失われてしまう可能性がある
- レコード保存時のメタデータ戦略はチャンク戦略と同様に重要
- メタデータを使用してフィルタリングできるので
- メタデータは、より最近のタイムスタンプを検索したり、特定の価格以上の製品を検索したりするのに利用される
- ベクトル検索はアプリケーションのコストとレイテンシを増やすので、トレードオフを把握する必要がある
- 静的な例を提示するだけで問題なく機能する場合もある
- 類似性に基づいて動的にコンテキストを反映させたい場合はRAGとベクトル検索が推奨される選択肢となる
エージェント
- エージェントは、指定された環境内で行動・認識・意思決定を行うことで、提示された目標を達成する
- エージェントの動作は、3つの主なコンポーネントで制御される
- 入力
- 目標または報酬関数
- 利用可能なアクション
- ReAct(Reasoning and Acting)
- エージェントフレームワークの1つ
- CoT(Chain of Thoughts)の改良版
- 下記のような思考ループを使用する
- 環境を観察する
- 環境を思考で解釈する
- 行動を決定する
- 環境に対して行動する
- ツールを用いて行動できる
- ステップ1〜4を、解決策が見つかるか、または反復回数が多すぎた場合まで繰り返す
蛇足
『Prompt Engineering for Generative AI』と関係ない記述も含む
品質評価について
- この辺りが参考になりそう
- 『LLMのプロンプトエンジニアリング』にもいくつか記述があった
- 既存のリポジトリの特定のコードを消してモデルに補完させてテスト（unit test的な）が通ればok
- これを数百のリポジトリで実施
- SOMAアセスメント
- Specific questions: 明確な質問
- Ordinal scaled answers: 順序尺度の回答
- Multiaspect coverage: 複数の側面のカバー
- 出力を単一の要素だけで評価できることは少ない
-
https://docs.anthropic.com/en/docs/test-and-evaluate/define-success で、
Most use cases will need multidimensional evaluation along several success criteria. ほとんどのユースケースでは、いくつかの成功基準に沿った多次元の評価が必要になります。とあるのと同じ話
- 既存のリポジトリの特定のコードを消してモデルに補完させてテスト（unit test的な）が通ればok
- github copilot chat(vscode)のpromptsとか、claude codeのcommandに書くような再利用を前提としたプロンプトで同様のテストができないか
- RAGの評価手法でRagasというものがあるらしいが、ページを見たら
Ragas is a library that provides tools to supercharge the evaluation of Large Language Model (LLM) applications. Ragasは、大規模言語モデル（LLM）アプリケーションの評価を高速化するツールを提供するライブラリです。となっていた
プロンプトエンジニアリングとは
『Prompt Engineering for Generative AI』では、
Prompt engineering is the process of discovering prompts that reliably yield useful or desired results.
プロンプトエンジニアリングは、信頼性が高く有用または望ましい結果を確実に得られるプロンプトを発見するプロセスです。
『LLMのプロンプトエンジニアリング』では、
そして「プロンプトエンジニアリング」は、最も単純な形では、目の前の問題に対応するために必要な情報を含むように、プロンプトを巧みに作り上げるプラクティスです。
「信頼性が高く有用または望ましい結果を確実に得られるプロンプトを発見するプロセス」の「プロセス」の具体的説明として、「眼の前の問題に対応するために必要な情報を含むように、プロンプトを巧みに作り上げるプラクティス」があると解釈した。
- 個人的には、問題に対応するために必要な情報を含められるようにプロンプト作成する手法、という方が分かりやすくて好き
- 但し、前述の、評価をしないプロンプト作成はプロンプトエンジニアリングではない、という議論を見ると、「プロセス」という言葉を使うのは分かる気がする
Discussion