「Prompt Engineering for LLMs」を読んで
最近のLLM本の中でも、「プロンプト＝一発芸」ではなくアプリ設計そのもの”として語ってくれる本は貴重。O’Reillyの『Prompt Engineering for LLMs』はまさにそれで、読みながら参考になった内容をまとめてみました。
1) LLMの正体を前提に設計する
LLMは次トークン予測器。巻き戻せない／左から一度読む／中盤が抜けやすい——この“体質”を前提に。
重要な条件は冒頭と終盤に。中盤は情報が沈む（“Mehの谷”）。
文字レベルの作業（字数カウント・逆綴り）は機械的に前後処理でやる。
迷ったら温度0〜0.2で評価用、0.3〜0.7でアイデア探索用。
結論：性格に合わせて台本を書く。魔法に頼らず、舞台監督になる。
2) プロンプトは「台本」——構造を決める
良い出力は良い台本からしか生まれない。本書は「文書型」を決める重要性を繰り返し説く。
助言会話型：Chat向け。質問→回答のリズムを固定。
分析レポート型（Markdown）：見出し固定、最後に“Stop見出し”を置いて暴走を止める。
構造化（JSON/XML/YAML）：機械可読が必要なとき。ツール連携が安定。
コード生成や差分説明はMarkdownレポート型、ツール連携はJSONに統一したら、後処理が劇的に楽になりました。
3) 静的×動的で“中身”を組む
プロンプトの中身は静的（行動規範・フォーマット・few-shot）と動的（ユーザー文脈・検索/RAG）の二層で考える。
静的：禁止事項より推奨事項を短く。few-shotは形式学習にだけ使う（量を増やさない）。
動的：関連スニペットを短く切って優先度付きで並べる。無関連は入れない（“使わなきゃ”バイアスが働く）。
実装メモ：スニペットは長短ペア（Elastic）を用意しておくと、トークン予算が足りないときに自動で短い方へ落とせて便利。
4) Chat時代の基礎体力：RLHF・ChatMLを活かす
ベースモデルは“作文の続き”。SFT→RM→PPOのRLHFで**HHH（Helpful/Honest/Harmless）**になる。
使い手として効かせるポイントは：
systemに行動規範・口調・出力フォーマットを短く定義。
ユーザー入力はsystemに混ぜない（保護の崩壊を防ぐ）。
Chat APIのstopやtool呼び出しで“終わり”と“行動”を明示。
5) モデルを“手なずける”実務テク
開始・終端の判定可能性：主回答は見出しや```で囲む。stopシーケンスは必ず設定。
logprob活用
冗長排除：挨拶や免責は後置に追い出す（few-shotで体裁ごと学習させる）。
6) 会話型エージェントは「道具×思考×文脈」
Function Calling
ReAct/CoT/Plan/Reflexion：検索→思考→再試行の“言語的作業興奮”を回す。
文脈管理：使わないツールは見せない。履歴はトピック転換で刈込、検索結果は要約で弾力化。
7) 汎用チャットの限界は“ワークフロー化”で越える
大きな課題は小さく分ける。各タスクは入出力スキーマを固定し、DAGで束ねる。
まずユニット（単体）で正しく動くかを担保。
失敗モードを**言語で自己修正（Reflexion）**させる経路を用意。
クローラやDBは従来ソフトで。LLMは必要箇所に限定。
8) 最初に評価基盤を敷く
オフライン：代表ケース→自動ハーネス。部分一致・機能テスト・LLM採点（SOMA）で回す。
オンライン：A/Bの帯域は貴重。Acceptance/Impact（採用率・実行成功）をKPIに、レイテンシとトークンも常時記録。
“評価を先に作る”——これは自分の反省点。ここからは最初にやります。
チェックリスト
文書型を決める（レポート/JSON/会話）。
systemを短く（目的・出力形式・禁止より推奨）。
few-shotは最小で形式学習用
動的文脈は優先度付け＋Elastic
stop設定＋主回答の囲い込み
logprobで品質分岐（再試行/追加RAG/昇格）。
ツールは少数精鋭＋承認フロー
ユニットテスト→DAG化→回帰評価
まとめ：プロンプトは“仕様書”、使用者は“監督”
この本が教えてくれるのは、「LLMの賢さに期待する前に、台本と舞台装置を設計する」という姿勢です。
赤ずきん原則（訓練分布に合わせて書く）を守り、余計な文脈を削り、必要情報は先に入れる。あとは評価で回して直す。シンプルですが、結局ここに尽きます。
#oreilly #AI #LLM
コメント