【読書記録】LLMのプロンプトエンジニアリング

• プロンプトエンジニアが誕生する可能性

  • 問題をLLMが理解できる情報の単位、つまり「プロンプト」と呼ばれるものに変換し、LLMの補完を、アプリケーションを利用するユーザーに価値をもたらす結果に変換することが、プロンプトエンジニアの仕事です。

• LLMは本質的に、トレーニング中に提供されるテキストを模倣するテキスト補完エンジンにすぎない

  • LLMが予測しやすいということを考える

Ⅰ部 基礎

• GPT登場時の論文

  • https://cdn.openai.com/research-covers/language-unsupervised/language_understanding_paper.pdf
  • GPTはファインチューニング後、そのファインチューニングを行った単一のタスクにおいてのみ優れた能力を発揮したのです。

• モデルはトレーニングデータに依存する

• プロンプトを具体的にすることでハルシネーションが出る確率が低くなる

• 実際には「複数のトークン」から「次の1つのトークン」を求め続けている

  • モデルはただ、必要なだけこの操作を繰り返し、単一トークンを積み重ねていくことで、最終的に整ったテキストを生み出す
    • 途中で誤りを指摘しても取り消すことができない

• temperature が0だと最も有力なもの、 1だと出現確率分布をそのまま反映され、1より大きいとより乱雑な値になる

  • ただ0の場合こうもがいつまでも出続けられるという問題が発生する可能性がある

• LLMは文章の後戻りができないため、プロンプトエンジニアリングにおいて順序が重要

• アプリケーションはLLMへプロンプトを投げるときに下の基準を同時に満たす必要がある (ユーザーではなくアプリケーション側がやる)

  1. プロンプトは、トレーニングデータのコンテンツとよく似た形式でなければならない。
  2. プロンプトには、ユーザーの問題解決に必要なすべての情報が含まれていなければならない。
  3. プロンプトによってモデルが問題解決に役立つ補完を生成するよう誘導されなければならない。
  4. 補完には自然な終止点があり、生成が自然に止まるようになっていなければならない。

Ⅱ部 中心的なテクニック

• 使えそうなものは何でも活用するとよい

  • 情報をできるだけたくさんかき集める
    • その後に絞り込む

• コンテンツを区別

  • 静的なコンテンツ（常に変わらないもの）
    • 明示的なもの
      • 「〇〇にしてください」、「〇〇は行わないでください」
      • 「～しないで」といった否定的な表現を避け、「～してほしい」といったポジティブな指示を心がける。
      • なぜそのルールが必要か、理由を付ける
      • 過度に厳格な表現は避ける
        • 例：「絶対に殺してはいけない」ではなく「生命を奪う行為は極めて限定的な状況でのみ検討し、その妥当性を慎重に判断してください」
      • Zero-shotプロンプティング
        • 例をまったく与えない（つまり明示的な指示だけの）プロンプト
    • 暗黙的なもの
      • 出力例など
      • 察してもらうための内容
      • Few-shotプロンプティング
        • 出力して欲しい内容の例をいくつか示す
          • 特に出力形式など、一部分の意図だけを手っ取り早く示すのに向いている
        • 想定される主要なパターンの例をすべて含めるようにすることが推奨される
        • デメリット
          • 例示された情報に偏る
  • 動的なコンテンツ（その都度変わるもの）
    • タスクの主題（多くの場合、ユーザーや扱うトピック）に関する有用な背景となるさまざまな「動的」な情報を収集することが最も重要な部分
    • ⭐️ 動的なコンテキストを見つける方法 (「外部設計, タスク, 詳細設計に使えそう」)
      • モデルに手伝ってほしい質問を中心に据えてマインドマップを描く
        • 中央に質問を書き、それに関連する要素をさまざまに膨らませる
        • まずは大まかな質問を考え、それに続く追加の質問を書き加えていくのも有効いくとよい

• 無関心の谷（Valley of Meh）

  • プロンプトの末尾に近い情報ほど、モデルに大きな影響を与えやすい
  • モデルはプロンプト冒頭と末尾の情報は比較的思い出しやすいのですが、中間に埋め込まれた情報は活用が難しくなるという傾向がある
  • リフォーカスが有効

• モデルの選択

  • 知能
  • スピード
  • コスト
  • 使いやすさ
  • 機能

Ⅲ部 プロンプト作成のエキスパート

• ツール定義のガイドライン

  1. 人にとって理解しやすいものは何でも、LLMにとっても理解しやすいものです。
  2. トレーニングデータに倣ってプロンプトをパターン化することで、最適な結果が導き出されます（別名「赤ずきんの原則」）。

• ReAct

  • https://arxiv.org/abs/2210.03629
  • 質問の後に「思考 -> アクション -> 観察」を繰り返した後に「思考 -> 行動」を行う
  • アクション時はツールを使う

• Plan-and-Solve

  • まず、問題を理解し、問題を解決するための計画を立てましょう。それから、その計画を実行し、段階的に問題を解決しましょう。

• LLMは、従来のソフトウェアよりも高価で、遅く、非決定論的で、信頼性が低いもの。

生成AI活用のアプローチ

• さまざまなことの学習
  • LLMに具体的な問題に関する個別のチュートリアルを作成してもらい、さらにその話題についてのQ&Aを行う
• AIの学習
  • 歴史を学習
  • raadmap.shを学習
  • https://zenn.dev/dhirooka/articles/dc3d31f15cccb6

まとめ

1. LLMは学習時に見たテキストを模倣する、単なるテキスト補完エンジンにすぎません。
2. LLMに共感し、その思考方法を理解する必要があります。

• 赤ずきんの原則: プロンプトはトレーニングセット中のドキュメントに近い形式であるべき
• LLMをインターネットの内容の多くを知っている、大きくて単純な機械の友達だと考える
  1. LLMは気が散りやすい
     • 「うまくいけば」役立つかもしれない無用な情報でプロンプトを埋めないでください。すべての情報が意味を持つようにしましょう。
  2. LLMはプロンプトを解読できるはずである
     • 人間であるあなたが完全に展開されたプロンプトを理解できないのであれば、LLMも同様に混乱する可能性が非常に高いです。
  3. LLMは何かに導かれる必要がある
     • 何を達成すべきかについて明示的な指示を提供し、適切な場合は、タスクをどのように進めるべきかを示す例を提供してください。
  4. LLMは超能力者ではない
     • プロンプトエンジニアとして、モデルが問題に対処するために必要な情報をプロンプトに含めることはあなたの仕事です。あるいは、モデルにツールと指示を与えて、それを取得できるようにしましょう。
  5. LLMには内的な独り言がない
     • LLMが問題について声に出して考えること（思考の連鎖、CoT）を許可されれば、有用な解決策に到達するのがはるかに容易になります。

論文

• https://arxiv.org/pdf/2203.02155