以下では、ヒント工学の基本的な考え方と、それが大規模言語モデル（LLM）の性能をどのように向上させるかに焦点を当てる...
LLMのインターフェイス：大規模な言語モデルがこれほど注目されている主な理由のひとつは、そのテキスト・トゥ・テキスト・インターフェイスによって最小限の操作体験が可能になることだ。以前は、ディープラーニングでタスクを解くには、少なくとも一部のデータを微調整して、対応するタスクの解き方をモデルに教える必要があった。しかし、ほとんどのモデルは、特定のタスクに関する専門的な深さしか持っていなかった。しかし現在では、LLMの優れた文脈学習機能のおかげで、1つのテキストヒントで幅広い問題を解くことができる。もともとの複雑な問題解決プロセスが、言語によって抽象化されたのだ！
"プロンプトエンジニアリングは、様々なアプリケーションや研究トピックのためにプロンプトを開発し、最適化するための言語モデルの効率的な使用に焦点を当てた比較的新しい分野である。" - 引用文献: [1］
チップ・プロジェクトとは？LLMはシンプルであるため、より多くの人が利用しやすくなっています。LLMを使うのにデータサイエンティストや機械学習エンジニアである必要はなく、英語（または好きな言語）を理解するだけで、LLMを使って比較的複雑な問題を解くことができる！しかし、LLMで問題を解決する場合、その結果はモデルに与えるテキストの手がかりに大きく依存することが多い。その結果、キューエンジニアリング（つまり、LLMのパフォーマンスを最適化するために、経験を使ってさまざまなキューをテストする方法）が非常にポピュラーになり、大きな影響力を持つようになり、多くのテクニックやベストプラクティスが生まれました。
プロンプトのデザイン方法LLMのプロンプトをデザインする方法はたくさんある。しかし、ほとんどのヒント戦略にはいくつかの共通点があります：
- 入力データ：LLMが処理する必要のある実際のデータ（翻訳または分類される文章、要約される文書など）。
- 例：プロンプトに含めるべき正しい入出力ペアの例。
- 指示(Instruction): モデルの期待される出力をテキストで記述したもの。
- ラベル (インジケータ): プロンプトの構造を作成するラベルまたはフォーマット要素。
- コンテキスト：プロンプトでLLMに与えられた追加情報。
以下の図では、上記のすべてのキューイング要素を1つの文の分類キューに統合する方法を例示している。
コンテキストウィンドウ：事前学習中、LLMは特定の長さの入力配列を見る。事前学習では、このシーケンス長をモデルの「コンテキスト長」として選択する。このコンテキスト長を大幅に超える長さのテキストが入力された場合、モデルは予測不可能な反応を示し、誤った結果を出力する可能性がある。しかし実際には、自己拡張[2]や位置補間[3]など、モデルのコンテキストウィンドウを拡張するために使用できる方法がある。
LLMに関する最近の研究では、長い文脈ウインドウの作成が強調されている。これは、モデルが手がかりごとにより多くの情報（例えば、より多くの例やより多くの文脈）を処理できるようにするためである。しかし、すべてのLLMが文脈情報を完璧に処理できるわけではない！LLMが長い文脈窓で情報を処理する能力は、通常「干し草の山の中の針テスト」 [4]によって評価されます。
1.文脈の中に無作為の事実を埋め込む。
2.この事実を見つけるためには、モデルが必要である。
3.さまざまな文脈の長さ、文脈の中の事実の位置で、このテストを繰り返す。
このテストでは、以下のような画像が生成される（出典[4]）。
私のキュー・エンジニアリング戦略：キュー・エンジニアリングの詳細は、使用するモデルによって異なります。しかし、キュー・エンジニアリングのプロセスでガイドとして使用できる一般原則もいくつかあります：
- 経験的アプローチ：キュー・エンジニアリングの最初のステップは、キューの修正を単純に測定するために、キューを評価する信頼できる方法（テストケース、人間による評価、ルーブリックとしてのLLMなど）を設定することです。
- 単純なものから複雑なものへ：プロンプトの最初の試みは、複雑な連鎖思考プロンプトやその他の専門的なプロンプト技法を最初から試すのではなく、できるだけ単純なものにする。最も初期のプロンプトは単純なものとし、パフォーマンスの変化を測定しながら徐々に複雑さを増していき、さらに複雑さが必要かどうかを判断する。
- できるだけ具体的かつ直接的であること：プロンプトのあいまいさをなくし、期待されるアウトプットをできるだけ簡潔に、直接的かつ具体的に記述するよう努める。
- 例を含める：期待されるアウトプットを説明するのが難しい場合は、プロンプトに例を含めてみてください。例は期待されるアウトプットの具体例を提供し、曖昧さを取り除くことができます。
- 可能な限り複雑さを避ける：複雑なプロンプトストラテジーが必要な場合もある（例えば、多段階の推論問題を解く場合）が、このようなアプローチをとる前によく考える必要がある。経験的な見解を持ち、確立された評価ストラテジーを使って、そのような複雑さを含める必要があるかどうかを本当に判断する。
以上をまとめると、私の個人的なキュー・エンジニアリング戦略は、i) 優れた評価フレームワークにコミットする、ii) シンプルなキューから始める、iii) 望ましいレベルのパフォーマンスを達成するために、必要に応じて徐々に複雑さを加える、というものだ。
注釈
[1] https://promptingguide.ai
[2] https://arxiv.org/abs/2401.01325
[3] https://arxiv.org/abs/2306.15595
[4] https://github.com/gkamradt/LLMTest_NeedleInAHaystack
