プロンプト・エンジニアリングに関する最高のディスカッション・ポッドキャストコンテンツ。

AIサマリー

中抜き

AIのヒントエンジニアリング 座談会では、人間工学の専門家たちが、研究、消費者、企業などさまざまな視点から、キュー・エンジニアリングに対する理解と実践経験を披露した。

この記事では、キュー・エンジニアリングの定義、その重要性、そして優れたキュー・エンジニアになる方法について詳述している。

核となる考え方は、キュー・エンジニアリングは単純なテキスト入力ではなく、絶え間ない反復、実験、そしてモデルの心理をより深く理解することを必要とするプロセスであるということだ。.

それは、AIモデルと効果的にコミュニケーションをとり、より大きなシステムに統合する方法である。

また、キュー・エンジニアリングとプログラミングの類似点、そして異なるアプリケーション・シナリオ（研究、企業、日常的な対話など）における強調点の違いについても探求している。

アンダースコア 明確なコミュニケーション、反復する能力、モデル出力の綿密な観察 プロジェクトを促す鍵だ。

専門家たちはまた、エッジケースへの対処法、キューを改善するためにモデル自身からのフィードバックを利用する方法、異なるタイプのモデルを区別する方法など、実際のアプリケーションで遭遇するさまざまな課題について議論し、貴重な経験やヒントを共有した。

一言で言えばこの記事は、プロンプト・エンジニアリングの包括的で洞察に満ちたガイドと、将来の方向性を読者に提供するものである。.

キーポイント

キュー・エンジニアリングとは、モデルと明確にコミュニケーションをとり、その可能性を最大限に引き出すために反復するプロセスである。
エンジニアリングの根幹にあるのは、実験と試行錯誤であり、ゼロから戻ってさまざまなアプローチを試す能力である。
プロンプトは単なるテキストではなく、データソース、待ち時間、システム設計を考慮する必要がある、システム全体に統合されたプログラミング手法である。
優れたプロンプトエンジニアには、明確なコミュニケーション能力、反復能力、モデル出力の詳細な分析能力が求められる。
モデルの "心 "を理解することは非常に重要であり、モデルがどのように指示を解釈するかを考慮に入れる必要がある。

革新的な洞察

書かれた言葉をコードと考え、良いエッセイを書くことはコードを書くことと同じくらい重要だと考えてください。
機械学習における「データを見る」のと同様に、モデル出力を読むことの重要性が強調されている。
プロンプトを最適化するためにモデルを使用することを提案したり、モデル自身にエラーを指摘させたりすることもできる。
登場人物のふりをするのではなく、モデルに直接課題を説明する方が、多くの場合において効果的であると論じている。
キュー・エンジニアリングの未来は、ユーザーから情報を得ることに重点を置き、モデルがガイドの役割を果たすことになるだろう。

主な引用と翻訳

元記事1：エンジニアリングの部分は、試行錯誤から生まれるものだと思います。人と話すのとは違って、模型と話すことのいいところは、リスタートボタンがあることです。

翻訳する： エンジニアリング」の部分は試行錯誤から生まれるものだと思う。模型と話すのと人と話すのとで大きく違うのは、リセットボタンがあるということだ。この巨大なボタンは、あなたを振り出しに戻し、ゼロからスタートさせる。

引用の理由 この引用は、キュー・エンジニアリングにおける「エンジニアリング」の意味を雄弁に指摘し、キュー・エンジニアリングを他のコミュニケーション形態と差別化する鍵である、キューを改善するための継続的な実験と反復の重要性を強調している。

原文2：プロンプトをモデルをプログラミングする方法として少し考えると、複雑になりすぎる。ザックの言う通り、プロンプトはただモデルをプログラミングするだけだ。しかし、モデルをプログラミングする方法として少し考えてみると、データがどこから来るのか、どんなデータにアクセスできるのか...（段落7）。どのデータにアクセスできるか...（段落7）

翻訳する： ヒントは、ちょっとややこしい言い方だけど、モデルをプログラミングする方法のようなものだと思うんだ。ザックの言う通り、明確なコミュニケーションこそが重要だと思うからだ。でも、プロンプトをモデルのプログラミングと考えるなら、データがどこから来るのか、どんなデータにアクセスできるのかを考えなければならない。

引用の理由 この一節は、キューイングとプログラミングを結びつけ、キューイングは単に言語だけの問題ではなく、データ、レイテンシー、システム統合などの要素を含むシステム的な思考が必要であることを強調している。

ですから、100の出力を見て、それが本当に一貫していれば、私はそのモデルを信頼できると思います。私は、基本的にすべてのエッジケース、モデルが行うかもしれない奇妙なこと、奇妙な入力、その他を把握するためにそれらを構築したことを知っています。そして私は、基本的にすべてのエッジケースと、モデルが行うかもしれない奇妙なこと、奇妙な入力、その他を把握するためにそれらを構築したことを知っている。おそらく、数千からなるもっと緩やかなセットよりも信頼できるだろう。

翻訳する： あるモデルの100の出力を見て、それが非常に一貫していて、エッジケースやモデルがやりそうな奇妙なこと、奇妙な入力などをすべて把握するためにそれらの出力を構築したことが分かっていれば、私はそのモデルを信頼することになるだろう。

引用の理由 この一節は、質の低い大規模なデータセットよりも、質の高い小規模なデータセットの価値を強調している。キューエンジニアリングにおいては、やみくもに多くのサンプルを追求するのではなく、エッジケースを十分に考慮することに重点を置くべきである。

読書メモ

[エンジニアリングの本質に関するヒント]：反復と実験

キューエンジニアリングとは、試行錯誤と反復によってモデルの出力を最適化するプロセスである。
まるでプログラムされたかのように実験を管理し、追跡することに重点を置いている。
明確なコミュニケーションはキュー・エンジニアリングの基本である。

1TP5試作 1TP5滴定 1TP5実験

[敏腕エンジニアの資質】：理解力と観察力

明確なコミュニケーション能力と反復する意欲が求められる。
モデルを深く理解し、モデルの出力から学習する能力が必要。
実用的な使用シナリオとユーザーからのインプットの多様性を考慮する必要がある。.

1TP5コミュニケーション 1TP5理解力 1TP5観察力

[モデルの相互作用]：信頼と挑戦

モデルは盲目的に信頼されるべきではなく、継続的に信頼性をテストし、検証する必要がある。
モデルを使ってエラーを自己診断し、改善を提案できる.
モデルは、ユーザーがタスクをよりよく理解し、プロンプトを表示するのに役立ちます。

1TP5信頼 1TP5フィードバック 1TP5協調

エンジニアリング・プロセスのヒント::

開始 --> 初期プロンプトの書き込み --> モデル出力 --> 結果の解析 --> プロンプトの修正 --> 満足するまでループ

循環プロセスと同様、チップは常に改良され、望ましいアウトプットを達成する。

モデリング評価::

| 出力の一貫性｜エッジケースのカバレッジ｜入力の多様性
| ------------| ------------| ------------|
| ハイ｜ハイ｜ハイ｜ハイ｜ハイ｜ハイ

一貫性、エッジケースのカバレッジ、入力の多様性という3つの重要な次元が高ければ高いほど良い。

エンジニアリングの未来へのヒント

ユーザー要求→モデル理解→モデル質問→ユーザーフィードバック→最適化のヒント→最終アウトプット

将来のキュー・エンジニアリングでは、ユーザー要件の理解とキューの最適化のプロセスに、モデルがより積極的に関与するようになるだろう。

核心問題に関する質疑応答

1.プロンプト・プロジェクトとは？

プロンプトエンジニアリング は、プロンプト（促し）を設計・最適化することで、大規模言語モデル（LLM）に特定のタスクを実行させる技術である。プロンプトエンジニアリングは、明確かつ的確なコミュニケーションを通じて、モデルが望ましい出力を行えるようにすることを目的としている。以下はプロンプトエンジニアリングの詳細である：

キューの定義

ディレクティブプロンプトとは、モデルに特定のタスクを実行させるために、ユーザーがモデルに与える指示である。単純な文章であったり、複数のステップを含む複雑な記述であったりする。
会議録ヒントはまた、自然言語で書かれた、モデルがタスクを実行する際のガイドとなる手順と考えることもできる。
通信方式基本的に、プロンプトはモデルとのコミュニケーション手段であり、人とのコミュニケーションに似ている。

プロジェクトの核となる要素

明確なコミュニケーションプロンプト・エンジニアリングは明確なコミュニケーションを重視し、ユーザーが自分のニーズを正確に表現できるようにし、モデルがタスクの具体的な要件を理解できるようにする。
反復プロセスキュー・エンジニアリングとは、モデルのパフォーマンスを向上させるためにキューを試し、修正し、最適化し続ける反復プロセスである。ソフトウェア工学における開発とデバッグのプロセスに似ている。
- テストさまざまな合図を試してモデルの反応を観察し、その結果に基づいて合図を調整する。
- 情報を送り返すモデルの出力を分析し、エラーを特定し、それに応じて修正する。
- サイクル望ましい結果が得られるまで、実験とフィードバックを繰り返す。
システム思考プロンプトエンジニアリングとは、単に個々のプロンプトを書くことではなく、プロンプトがシステム全体にどのように統合されているかを考えることである。そのためには、データのソース、データの処理方法、システムにおけるモデルの役割を考慮する必要がある。
モデルを理解するキューイングエンジニアは、より良いキューを設計するために、モデルがどのように機能し、その限界を理解する必要があります。これには、モデルが異なるタイプの入力をどのように扱うか、モデルの推論プロセスをどのように導くかを理解することも含まれます。
問題解決能力ヒントエンジニアは、あらゆる可能性のあるシナリオを体系的に検討し、エンジニアリングの問題であるかのように解決策を提示する必要がある。
- 予測誤差モデルにどのような間違いが起こりやすいかを予測し、その間違いに対処するための適切なヒントを考案する。
- エッジケースへの対応異常な入力やエラーに遭遇したとき、モデルがどのように反応するかを考える。
バージョン管理バージョン管理、実験の追跡など、ヒントをコードのように扱う。
モデル出力を読む結果が正しいかどうかだけでなく、その推論プロセスを理解するために、モデルの出力を注意深く読むこと。
理論的思考モデルを理解するときは、自分の理解だけで書くのではなく、モデルが自分の指示を理論的にどう理解するかを考える必要がある。

リマインダー・プロジェクトの目的

モデリングの可能性を引き出すキュー・エンジニアリングの目的は、モデルの潜在能力を最大限に活用し、本来の設計能力を超えるタスクを実行できるようにすることです。
モデル性能の最適化うまくデザインされたキューによって、特定のタスクにおけるモデルのパフォーマンスを向上させる。
モデルの行動を導くモデルが望ましいアウトプットを出し、望ましくないアウトプットを避けることができるように、キューを通してモデルの振る舞いをガイドすること。

キューエンジニアリングの挑戦

明瞭な表現が難しいタスクを言葉で正確に説明し、すべての仮定を取り除くことは難しい。
モデルは質問をしない。モデルは人間のように明確な質問をするわけではないので、キューイング・エンジニアは、モデル自身によるクエリの可能性を予測し、キューの中で適切な答えを与える必要がある。
完璧なチップを見つけることの難しさ完璧なチップを見つけるのは難しいことだ。

キュー・エンジニアリング・アプリケーション

様々なシーンキュー・エンジニアリングは、研究、企業アプリケーション、消費者アプリケーションなど、さまざまな場面で応用できます。
タスクの種類プロンプト・プロジェクトは、テキスト生成、情報抽出、質問応答、コード生成など、さまざまなタイプのタスクに使用できます。
システムへの統合プロンプト・エンジニアリングとは、個々のプロンプトを書くことだけでなく、プロンプトをシステム全体に統合することでもある。

エンジニアリングの未来へのヒント

モデルアシストのヒント将来的には、質問、提案、プロンプトの自動生成など、ユーザーがより良いプロンプトを書けるように支援できるようになるでしょう。
ヒューマン・マシン・コラボレーション将来的には、キュー・エンジニアリングは人間とコンピュータのコラボレーション・モデルへと移行し、モデルがユーザーの目標に基づいて質問し、より効果的なキューを書くようにユーザーを導くようになるかもしれません。
ガイダンスからカウンセリングへモデルがより賢くなるにつれて、キュー・エンジニアリングはガイダンス・モデルからアドバイザリー・モデルに移行するかもしれない。

プロンプト・エンジニアリングは、創造性、論理的思考、システム思考を必要とする技術である。単に良いキューを書くだけでなく、モデルを理解し、実験を設計し、最適化を繰り返し、問題を解決することが重要なのです。キューのエンジニアは、モデルの可能性を最大限に引き出すために、エンジニアのように実験し、学ぶ必要があります。

2.優れたキュー・エンジニアの資質とは？

明確なコミュニケーション能力優れたプロンプト・エンジニアは、考えを明確に述べ、タスクを明確に理解し、コンセプトを正確に説明することができる。これには、モデルが理解しやすいように指示を組み立てる能力も含まれます。
反復能力彼らは、プロンプトの反復と微調整を継続的に行い、モデルがプロンプトを誤って解釈している可能性がある箇所について考えることを厭わない。この反復プロセスには、モデルの反応を分析し、エラーを特定し、修正を加えることが含まれる。
テスト・エッジ・ケース例えば、入力がNULLであったり、期待された形式でなかったりする場合である。これには、モデルがさまざまな状況で適切に機能することを確認するために、さまざまな例外をテストすることが含まれます。
モデルの出力を理解する優れたキューイング・エンジニアは、結果だけでなく、モデルのアウトプットにも細心の注意を払う。彼らはモデルの思考プロセスを掘り下げ、その理由を理解しようとする。
理論的思考自分自身の理解を引き出し、タスクを完了するために必要なすべての情報を体系的に分解することができる。必要な情報をモデルが理解できるように明確に伝えることができる。
共感モデルの立場に立ち、モデルが自分の指示をどのように受け止めているかを理解することができる。また、ユーザーのニーズを考慮し、ユーザーがモデルとどのように相互作用するかを理解する必要があります。
実験的思考彼らは絶え間ない実験と試行錯誤を通じて、モデルの限界を発見する。彼らは失敗を恐れず、失敗から学び、モデルの能力の限界に挑戦することで理解を深めていく。
モデリングによる改善自分たちの努力だけでなく、モデルそのものを使うことによっても、プロンプトを改善する。例えば、指示のあいまいさを指摘してもらったり、変更を提案してもらったりする。モデルに間違いを説明させ、インストラクションを改善しようとする。
信じるが、検証する彼らはモデルの能力について慎重であり、テストを繰り返すことでその信頼性を確保する。モデルを盲目的に信頼するのではなく、広範なテストを通じてモデルの出力を検証する。
精査プロンプトとモデル出力を注意深く読み、詳細を分析する。モデル出力の詳細を分析することで、モデルがどのように考えるかを学ぶ。
完璧にこだわらない完璧なプロンプトを目指すのではなく、何度も挑戦し、失敗から学ぶ。プロンプトは一回限りの作業ではなく、反復プロセスであることを認識する。
テキストをコードとして扱うコードとしてのテキストの意味を理解し、ヒントにはバージョン管理や実験追跡なども必要であることを理解できる。
異なる視点から考える能力優れたキューイング・エンジニアは、モデルの立場に立って物事を考えるだけでなく、実際のユーザーのニーズも考慮するなど、さまざまな視点から物事を考えることができます。
新しいコンセプトを生み出す能力必要に応じて新しい概念を定義し、モデルを使って明示する。
アイデアを外部化する能力自分の考えを明確に表現し、脳内の複雑な概念をモデルが理解できる指示に変換することができる。

優れたキューイングエンジニアは、明確なコミュニケーターであり、反復的であるだけでなく、共感的であり、モデルの立場に立つことができ、継続的に実験と学習を行い、エッジケースをテストすることによってモデルの境界を発見することができる。彼らはまた、モデルそのものを使って手がかりを改善し、モデル出力の詳細から学ぶ。彼らは、完璧を目指すのではなく、キューにたどり着くまでのプロセスが反復的であることを理解し、テキストとコードの類似性を理解する必要がある。ユーザーエクスペリエンスという観点からも、モデル自体の捉え方という観点からも、さまざまな視点から考える必要がある。最も重要なことは、自分の考えを明確にし、脳内の概念を外在化できるようになることだ。

3.モデルとの効果的な付き合い方は？

3.1 明確なコミュニケーションが中心

ニーズの正確な表現： 人とコミュニケーションをとるのと同じように、モデルにもあなたが目指しているものを正確に理解してもらうために、自分のニーズを明確に表現する必要がある。あいまいな指示を避けるモデルが何を達成することを期待しているのか、できる限り具体的に説明するようにしてください。
タスクの詳細を明確にする： そうする必要がある。思い込みをすべて取り払う。そして、モデルが知る必要のあるすべての情報を詳述する。あなたが明示的に伝えていないことをモデルが知っていると思い込んではいけない。.

3.2 プロンプトを手順として考える

自然言語コード： プロンプトは、モデルをタスクに導くための自然言語で書かれた手順と考えることができる。
システム思考： プロンプトをコードのように扱うバージョン管理、実験の追跡などを含む。データソース、データ処理、システムにおけるモデルの役割など、キューがシステム全体にどのように適合するかを考慮する必要がある。

3.3 反復と実験を受け入れる

試行錯誤が当たり前： キュー・エンジニアリングは、常にさまざまなキューを試し、モデルからのフィードバックに基づいて調整する試行錯誤のプロセスである。
再起動ボタン： このモデルには "リスタートボタン "があり、いつでも最初に戻って、以前の実験に邪魔されることなく、ゼロから別のアプローチを試すことができる。
頻繁に反復する： 効果的なキューイングエンジニアリングには、複数のモデルとの頻繁なやり取りが必要である。何度も繰り返す一度に完璧な結果を期待するよりも。

3.4 モデルの心を理解する

モデリングの視点： モデルの視点からあなたの指示を考え、モデルがあなたの要求をどのように理解するかを理解するようにしてください。そのためにはモデルを演じるそのキャラクターが考えていることを真似るのだ。
モデルの出力を読む： モデルの出力を注意深く読み、結果が正しいかどうかだけでなく、モデルの推論プロセスを理解することにも重点を置く。アウトプットから学ぶモデルがあなたの指示をどのように理解しているかを理解すること。
モデルの誤差を探る： モデルが犯したミスを無視してはいけない。なぜそのモデルは間違っているのか？そしてエラーの原因を理解しようとし、指示の修正をモデルに求めることもある。モデルは時に、指示のあいまいさを指摘し、改善のための提案をすることができる。

3.5 エッジケースへの対応

予測ミス： モデルがうまくいかない状況を予測するそして、これらのエラーを処理するための適切なキューを設計する。例えば、異常な入力やエラーに遭遇したときにモデルがどのように反応するかを考える：
- オプションを提供する： もしモデルがある入力に対して何をすべきかわからない場合は、"not sure "というラベルを出力させるなど、"exit "を与える。
- 極端なテスト： さまざまな極端な状況（例：空の文字列、期待値と一致しない入力）でプロンプトをテストし、モデルがさまざまな状況でうまく機能することを確認してください。

3.6 モデルを尊重する能力

モデルを過小評価してはいけない： このモデルはバカだから、うまくいくように "なだめすかす "必要がある、などと考えてはいけない。モデルの能力を尊重する十分な文脈と情報を与え、あなたの目標を理解できるようにする。
直接的な情報を提供する： モデルに新しい技術を学ばせたいときは、自分の言葉で説明するよりも、関連する論文や資料を与えればいい。
単純化を避ける： 指示を意図的に単純化するのではなく、複雑なタスクはモデルに任せてください。

3.7 モデリング補助器具の使用

モデル生成の例： モデルを使用して例を生成し、それを修正することで、高品質のプロンプトをすばやく作成できます。
インタビューのためのモデリング： モデルにインタビューさせ、頭の中の情報を引き出し、その情報をプロンプトに変える。

3.8 完璧なヒントに流されるな

完璧はない： 完璧なヒントを探す」罠にはまらず、常に改善の余地があることを認識すること。
継続的な学習： モデルとのやり取りはすべて学習の機会であり、試行錯誤を重ねるごとにモデルをより深く理解できるようになる。
境界線の探求に焦点を当てる： モデルにはできないと思っていることをやらせてみて、モデルの境界を探ることで学んでいく。

3.9 異なるシナリオを区別する

研究と企業： 研究環境では多様性と探求に重点を置くかもしれないが、企業環境では信頼性と一貫性に重点を置くかもしれない。
人間とコンピュータの対話とシステム応用： 人間とコンピュータの対話では、何度も繰り返し行うかもしれないが、システム・アプリケーションでは、さまざまな状況に一度に対応できるプロンプトを書く必要がある。

3.10 メタ・プロンプトの使用

プロンプト用のプロンプトを生成する： メタヒント」を使って、モデルに必要な出力やクエリを生成させることができる。モデルにヒンティング技術に関する論文を与え、他のモデルにその技術を実行させるためのメタヒントを生成させることができる。

つまり、モデルとの効果的な対話には、明確なコミュニケーション、体系的な思考、一貫した実験、深い理解、モデルの能力の尊重が必要です。同時に、モデルの助けを効果的に利用することで、プロンプトの反復と最適化を迅速に行うことができます。完璧なキューというものは存在せず、継続的な学習と改善のみであることを忘れないでください。

4.プロンプトに関するよくある誤解

4.1 ヒントは簡単な指示にすぎない：

誤解だ： プロンプトというと、検索エンジンにキーワードを入力するような単純な指示だと思われがちだ。キーワードを入力するだけで、モデルにタスクを実行させることができると考え、明確で正確なコミュニケーションの重要性を見落としてしまうのだ。
事実だ： 事実だ。ヒントは複雑なプログラミング方法バージョン管理や実験の追跡など、コードのように扱う必要がある。良いキューは、モデルがタスクを正確に理解し、望ましいアウトプットを出すように、注意深く設計され、反復される必要がある。

4.2 プロンプトは静的なもので、一度だけ書くことができる：

誤解だ： プロンプトを書くのはエッセイを書くのと同じで、それで終わり、それ以上の修正は必要ないと考える人もいる。
事実だ： ヒント・プロジェクトは反復プロセスそのため、常に実験、修正、最適化が必要となる。そのためには、何度もモデルで作業する必要がある。やりとりするモデルの出力を読み取り、エラーを分析することで、キューを改善することができます。効果的なキュー・エンジニアリングには以下が必要です。実験とフィードバックを受け入れるワンステップのプロセスを期待するのではなく。

4.3 ヒントは完璧な文法と句読点を必要とする：

誤解だ： モデルが理解されるためには、プロンプトは完璧な文法と句読点を使わなければならないと思われがちだ。
事実だ： 細部へのこだわりは重要だがモデルは通常、スペルミスや文法の不完全さを含むキューを理解する。.重要だ。コンセプトの明確さ文法的に完璧であることよりも。最終的なプロンプトでミスを修正するのは良いことだが、反復中に不完全であっても構わない。

4.4 モデルが動くように "説得 "する必要がある：

誤解だ： モデルはバカだから、偽の身分や役割を与えるなど、トリックや "嘘 "を使ってタスクを誘導する必要があると考える人もいる。
事実だ： モデルには強い理解があるおだてる」必要はない。そうすべきだ。リスペクトモデルそして、明確で正確な情報を直接与え、あなたの目標を理解させる。タスクを直接説明するメタファーや似たようなタスクを使ってモデルを導くのではなく。

4.5 キュー・エンジニアリングの核心は、完璧な指示書を書くことにある：

誤解だ： キュー・エンジニアリングの要諦は、完璧な指示を見つけることであり、一つひとつの言葉を理解することに多くの時間を費やすことだと考える人もいる。
事実だ： 正確な指示は重要だが、それ以上に重要なのはモデルの仕組みを理解するそしてモデルの出力を読んで学ぶ.モデルの考え方を理解するのみならず異なる入力をどのように扱うか完璧な指示の追求よりも。優れたキューイング・エンジニアは以下のことができるはずだ。モデルの出力から信号を抽出する結果が正しいかどうかだけでなく、その推論プロセスを理解すること。

4.6 ヒントエンジニアリングとは、ただ書くことである：

誤解だ： プロンプトエンジニアのコアコンピテンシーはライティングスキルにあり、優れたライターは当然優れたプロンプトエンジニアになるという考え方もある。
事実だ： 優れた文章力は必要だがキュー・エンジニアリングのコアコンピテンシーではない.優秀なプロンプティング・エンジニアには実験精神、システム思考、問題解決能力もモデルマインドを理解する能力.反復とテスト単なる文章力ではない。

4.7 モデルに情報を与えすぎることは避けるべきである：

誤解だ： モデルを混乱させるのではないかと心配し、指示を単純化し、複雑さを隠そうとする人もいる。
事実だ： モデルの能力が上がるにつれて、次のようなことができるようになる。詳細と背景.モデルを信じるべきだ。あなたのタスクをよりよく理解できるよう、十分な情報を与えること。

4.8 例題は常に多い方が良い：

誤解だ： モデルの性能を向上させるには、多くの例を提供することが唯一の方法だと思うかもしれない。
事実だ： 例題はモデルを導くのに役立つが、例題が多すぎるのも問題である。モデリングにおける創造性と多様性の制限..研究の場で。具体的な例ではなく、例示的な例を使うお手本をただ真似るのではなく、課題そのものを考えるように促すので、より効果的かもしれない。

4.9 モデルは人間のように考え、推論する：

誤解だ： モデルは人間のように推論し、「思考ステップ」の合図を理解すると思うかもしれない。
事実だ： モデルは推論プロセスを模倣することができるが、例えば次のような方法がある。思考の連鎖しかし、それは必ずしも真の推論ではない。モデルは、あなたが与えた指示や例に基づいてテキストを生成するだけです。重要なのはモデルと人間では考え方が違う。モデルの行動を擬人化しすぎないこと。

4.10 ロールプレイングのプロンプトは常に有効だ：

誤解だ： モデルに特定の役割（例えば「あなたは先生です」）を演じさせることで、そのパフォーマンスが向上するという説もある。
事実だ： ロールプレイングのプロンプトは、状況によっては有効かもしれないが、必ずしも必要ではない。 何を達成したいのか、直接記述するこれは、モデルを別人のように装うよりも効果的である。モデルの能力が向上するにつれて、偽のアイデンティティを与えるのではなく、タスクの説明とコンテキストを直接与える方がよいかもしれない。

4.11 一度良いヒントを見つければ、それは常に機能する：

誤解だ： 一度うまくいくキューを見つければ、それは永遠に機能し、微調整の必要はないと考える人もいる。
事実だ： モデリング能力が向上するにつれ効果的なヒントは時代遅れになることもある.いくつかのキューイング・テクニックは、モデルにトレーニングされ、明示的にキューイングする必要がなくなるかもしれない。そのためには継続的な学習と適応モデルの変更に対応する。

このようなよくある誤解を理解することで、より効果的にモデルと接することができ、さまざまなタスクでキュー・エンジニアリングをより有効に活用することができます。ヒント・エンジニアリングは単なるコマンド入力ではなく、深い理解と練習を必要とする学問です。

5.エンタープライズのヒント vs リサーチのヒント

エンタープライズのヒント歌で応える研究レベルのヒント目的、方法、焦点には大きな違いがある。

エンタープライズのヒント

信頼性の重視エンタープライズアプリケーションでは信頼性が重要です。エンタープライズレベルのヒントの目標は、モデルが様々な状況で一貫した期待通りの結果を出すことを保証することです。そのためには通常、モデルの自由度を制限するために、多くの例と具体的なガイダンスが必要になります。
フォーマット重視:: エンタープライズプロンプトでは、出力形式が重視されます。ビジネスアプリケーションでは、出力形式の安定性と一貫性は、ユーザーインターフェイスの表示とその後のデータ処理の効率に影響するため、多くの場合、多様性よりも重要です。
ユーザーのニーズを重視エンタープライズクラスのプロンプトは、ユーザーの特定のニーズに高度に対応する必要がある。つまり、プロンプトはさまざまな入力を処理し、ユーザーの特定のニーズを満たす出力を生成できる必要があります。
システム思考企業レベルのキューは、多くの場合、より大規模なシステムへの統合を考慮する必要がある。これには、データソース、待ち時間、他のソフトウェアやプロセスとモデルを統合する方法などが含まれます。
多くのテストと反復エンタープライズチップは、実際のアプリケーションで高い信頼性と安定性を確保するために、さまざまな入力とシナリオの下でテストする必要があります。これには、さまざまなエッジケースや、想定されるさまざまなユーザー入力のテストが含まれます。
一貫性を重視する企業アプリケーションでは、たとえ答えが反復的であったとしても、それが期待に応えるものであれば許容される。これは、研究環境における探索的な目的とは異なる。
長期的な用途を重視: エンタープライズチップは、何度も再利用できるシステムを構築するように設計されています。そのため、エンタープライズ向けプロンプトを確実に動作させるには、より多くの時間と労力が必要となります。
抽象化しすぎない:: 企業レベルのプロンプトは、過度に抽象的な指示を避け、代わりにタスクと要求されるアウトプットを明確に記述すべきである。

研究レベルのヒント

多様性と探求の重視研究レベルのプロンプトの目的は、モデルの様々な能力を探求し、モデルが使用できる新しい用途を発見することである。これには通常、モデルの制約を減らし、さまざまな出力や解決策を探索するよう促すことが必要です。
好意的な例がほとんどない、あるいは全くない研究レベルのプロンプトでは、モデルの探究範囲を限定しないために、一般的に例題の数を減らすか、具体的な例題を提示しない。
認知タスクに集中研究レベルのプロンプトは、認知的なタスク、すなわちモデルが複雑な問題をどのように理解し、解決するかに重点を置いている。
例示の使用研究レベルのプロンプトが例を示している場合、それらは具体的というよりむしろ例示的である傾向がある。つまり、その例はモデルが実際に扱う必要のあるデータとは異なる可能性があり、その目的はモデルが例を直接模倣するのではなく、タスクの本質を理解するのを助けることである。
新しい境界線を試す研究レベルのプロンプトの目的は、モデルの能力の限界に挑戦し、モデルが得意なことと不得意なことを発見することです。これには、モデルの限界をよりよく理解するために、モデルが不得意とするタスクに挑戦することも含まれます。
柔軟で多角的なアウトプットの重視研究レベルのプロンプトは、モデルがどのようなアウトプットを出すことができるかを探ることに重点を置いている。研究レベルのプロンプトは、単に結果が正しいかどうかよりも、モデルがどのように考えるか、そしてそのアウトプットの質と深さに重点を置く。
より探索的研究グレードのキューは、より探索的であり、一貫性や形式を重視しない。研究者は、モデルが新しい状況に直面したときにどのように反応するか、また、そのキューを使用してモデルを探索の方向にどのように導くことができるかをより重視します。

概要::

異なる目的企業レベルのプロンプトは、信頼性と一貫性を重視して現実の問題を解決することを目的としており、研究レベルのプロンプトは、多様性と革新性を重視してモデリング能力を探求することを目的としている。
さまざまな方法企業レベルのプロンプトは通常、モデルの出力を制御するために多数の具体例を用いるが、研究レベルのプロンプトは通常、モデルが新しい可能性を探求することを促すために、ほとんど、あるいはまったく具体例を用いない。
焦点の違い企業レベルのプロンプトはユーザー要件とシステム統合に焦点を当て、研究レベルのプロンプトは認知プロセスとモデル境界に焦点を当てる。
開発とテストのサイクルの違い一方、研究レベルのヒントは、モデルの様々な可能性を探ることを目的として、テストと反復のサイクルを短くすることができる。
モデリングへのさまざまなアプローチ一方、研究レベルのプロンプトは、モデルの能力を「尊重」し、より自律性を与える傾向がある。

企業レベルと研究レベルのプロンプトの基本的な違いは、その目的と焦点です。

企業レベルのヒントは、ユーザーに信頼できる解決策を提供することに専念しているが、研究レベルのヒントは、モデルの能力の理解を深めることに専念している。

実際には、この2つの合図は異なるアプローチやテクニックを必要とするかもしれない。

6.エンジニアリングの未来へのヒント

6.1 モデルはあなたの意図を理解しやすくなるが、それでも明確さが重要だ

情報理論の観点から： 将来的には、モデルはあなたのニーズをよりよく理解するようになるでしょうが、それでもあなたの目標を明確にするために十分な情報を提供する必要があります。たとえモデルがあなたの言っていることを理解できたとしても期待することを明確に伝えることが重要.
明確な目標の重要性： モデルがどんなに賢くなっても目標を定義する能力が中心にある.モデルがゴールを設定できるとはいえ、それを使って問題を解決したいのであれば、何をさせたいのかを明示的に指定する必要がある。
継続的なコミュニケーション： モデルが賢くなり、あなたの意図をより理解できるようになっても、あなたはまだ次のことが必要です。モデルとのコミュニケーション、フィードバック、調整.

6.2 モデルがアシスタントを務める

モデルとのコラボレーション： 将来的には、より深くモデルと協力し、何を書くべきか、何が足りないかを判断できるようになるだろう。モデルはあなたを助けてくれるあなたが考えもしなかったことを発見するを提供する。プロンプトを改善するための提案.
モデル支援によるヒント生成 モデルを使用して例題、下書き、メタプロンプトを生成し、プロンプトの作成プロセスをスピードアップできます。たとえば、モデルを使用して例題を生成し、それを修正することができます。
高帯域幅の交流： 将来的には、フィードバックを提供したり、モデルからの調整を要求するなど、モデルと高帯域幅のインタラクションができるようになるでしょう。このインタラクションは、デザイナーとの共同作業に似ていて、あなたがハイレベルなゴールを提供すると、モデルはそれを具体化する手助けをしてくれる。

6.3 メタ・チップの重要性が高まる

ヒントを使ってヒントを生成する： 将来的には、モデルが希望する出力やクエリを生成できるようにするヒントを探すことに、より多くの時間を費やすことになるかもしれません。メタプロンプトを使用して、モデルに特定のプロンプト技法を実行させたり、他のモデルのためのプロンプトテンプレートを生成したりします。
模範となる教材を与える： 自分でキューを書く代わりに、モデルに関連する論文や文書を与えて、新しいキュー生成テクニックを学ばせることができます。モデルは論文を直接読み、そこから得た知識をキュー生成に応用することができます。

6.4 キュー・エンジニアリングはモデルの境界線に焦点を当てる

モデルを探求する能力： モデルの能力の限界を常に探り、モデルが達成できることに挑戦する。
卓越したパフォーマンスを追求する： モデルから最高レベルのパフォーマンスを引き出すことに集中し、モデルがやっと達成できることを探求する。

6.5 そのモデルは、次のようなことを提案するかもしれない。

モデルはあなたの意図を理解している： モデルがあなたよりもタスクの背景をよく知っている場合、あなたのニーズを明確にするよう順番に促してくることがある。モデルは、あなたが何を達成しようとしているのかを明確にし、あなたが見落としているかもしれないエッジケースを発見するのを助けるために質問をするかもしれない。
指導を受ける側から専門家アドバイザーへ： このモデルは、単なる指示の受け手から、タスクの詳細について相談できる専門アドバイザーへと変貌を遂げる。まるでデザイナーと仕事をするように、彼らはあなたのニーズをよりよく理解するためにあなたに質問をする。
モデルのインタビュー あなたのニーズをよりよく理解するために、モデルが来てインタビューのように対話することもできる。

6.6 未来にはより深い内省が必要

モデルはあなたを理解している： 将来的には、あなたがモデルを理解しようとするのではなく、モデルがあなたの考えを理解する必要がある。
モデルから見えるようにする： モデルがあなたの意図を理解できるように、自分の考えやニーズを明確に表現する方法を学ぶ必要がある。
コンセプトを定義する： モデルがあなたの意図を理解できるように、新しいコンセプトを作り、その意味を定義する必要がある場合もある。

6.7 キュー・エンジニアリングは哲学的実践になるかもしれない

明確に表現されている： 将来的には、キュー・エンジニアリングには哲学者のように考え、書く複雑な考えを明確で的確な言葉で表現する。
教養ある庶民のための執筆： プロンプトは、教養のある素人向けに書くつもりで、そのテーマに詳しくない人でも意図がわかるように書く必要がある。
脳を外部化する： 優れたキュー・エンジニアリングには、自分の脳内のアイデアを外在化させ、それをモデルに理解させることが必要だ。

6.8 ヒントエンジニアリングのスキルは、より高いレベルのタスクに移行できる

低レベルの任務から高レベルの任務まで： モデルが進むにつれて、低レベルのタスクに対するプロンプトに集中する必要はなくなり、代わりにタスクの分解や複雑な推論といった高レベルのタスクに集中するようになる。
ガイド付きインタラクション： 今後のインタラクションは、コンソールにテキストを打ち込んで最終的な結果を得るモデルよりも、ガイド付きのダイアログのようなものになるだろう。

エンジニアリングの未来に必要なヒント協調性、内省性、表現力の強化.モデルを使ってその機能を調べ、ニーズを明確にする必要があります。加えてまた、常に学習し、モデルの変化に適応し続ける必要がある。一元的な解決策を模索するよりも。プロンプト・エンジニアリングの未来は変わるだろうが、明確な目的と明確な表現がその中心にあることに変わりはない。

7.プロンプトのコツ

焦点はどのようにモデルとのコミュニケーションの効率と効果を高める::

7.1 反復と実験：

努力し続けなさい： ヒント・プロジェクトは反復プロセス常に実験し、修正し、最適化する必要がある。初回で完璧なプロンプトを書けるとは期待せず、複数のプロンプトを作成する準備をしておくこと。やりとりする.
失敗から学べ： モデルが間違っている場合、それを注意深く分析する。エラーの理由それに応じてプロンプトを改善する。モデルとのやりとりはすべて学習の機会です。
実験を受け入れる： どの方法が一番効果的か、さまざまな方法を試してみること。キュー・プロジェクトの核心は実験とフィードバック一歩ずつではなく、一歩ずつだ。

7.2 明確で的確なコミュニケーション：

課題を明確にする： 支出明確で簡潔な表現モデルに達成させたいタスクを記述する。曖昧な用語は避けてください。
十分な情報を提供すること： モデルに詳細な背景と背景情報を提供する. モデルがあなたの目標とタスクの具体的な要件を理解していることを確認します。
モデルを尊重する： モデルを "おだて "るのではなく、次のことが重要である。リスペクトモデル理解力を高める。比喩や架空の人物を使うのではなく、自分の課題を直接描写する。

7.3 モデルがどのように機能するかを理解する：

モデルの出力を読む： モデルの出力を注意深く読み、それを理解する。マインドセットと推論プロセス。モデルが異なる入力をどのように扱うかを観察し、それに応じてプロンプトを調整する。
モデルの境界を探る： モデルにはできないかもしれないと思うような仕事をさせてみる。モデルの能力の範囲を理解する. これは、モデルの限界をよりよく理解するのに役立ちます。
模範演技をしてみてください： の立場に立って考えてみよう。モデリングの観点から考えるあなたの指示をモデルがどのように理解するかを理解する。これは、モデルの挙動を予測するのに役立ちます。

7.4多様なキューイング方法：

使用例： を提供する。典型例を使い、モデルを指導する。ただし、例題に頼りすぎると、モデルの創造性が制限される可能性があるので注意すること。
メタヒントを使う： プロンプトを使ってさらなるヒントを生み出すまた、特定のニーズを満たす出力をモデルに生成させることもできる。これは、さまざまなキューイング戦略をより効率的に検討するのに役立ちます。
チェーン思考： モデルを作る推理プロセスを段階的に説明. これにより、モデルの意思決定プロセスをよりよく理解することができ、モデルのパフォーマンスを向上させるのに役立ちます。
ロールプレイ： 常に必要というわけではないが、場合によっては、モデルに特定の役割を果たす仕事をこなすには役立つかもしれない。しかし使命を直接的に表現する方が効果的な場合が多い.

7.5 上級者向けのヒント

コンセプトを定義する： 自分の意思を伝えるために、時には次のようなことが必要だ。新しいコンセプトの定義そしてその意味を説明する。
モデルにインタビューさせる： モデルに順番にインタビューしてもらい頭をスッキリさせるモデルに提供する必要のある情報を抽出する。
哲学を描く： 哲学的文章から学ぶ複雑なアイデアを明確に表現するモデルがあなたの意図を理解できるように。
モデルに知らせる： 自分でプロンプトを書く代わりに、モデルに関連書類や文書を渡して、彼ら自身に学ばせることもできる。

7.6 注釈

文法にこだわりすぎないこと： 細部へのこだわりは重要だが、文法や句読点にこだわりすぎてはいけない。重要なのはコンセプトの明確さ.
モデルを過小評価してはいけない： モデルはバカだから、"なだめすかして "働かせる必要があるなどと思わないでほしい。あなたは信託モデル能力を高め、タスクを完了するのに十分な情報を与える。
複雑さを恐れてはいけない： モデルの能力が上がれば、より複雑な情報を扱えるようになる。複雑さを隠そうとするのではなく信託モデルに対処しなければならない。
継続的な学習と適応： モデリング能力が高まるにつれて効果的なプロンプトの出し方も時代遅れになりかねない. 常に学び続け、モデルの変化に適応していく必要がある。
フィードバック求む。 自分のヒントを他の人、特に自分の仕事に慣れていない人に見せることで、自分が見逃していたかもしれない問題を発見することができる。
ヒントを読む 他の人が書いた良いヒントを読み、それがどのように機能するかを分析する。

7.7 将来へのヒント

モデルはアシスタントを務める。 将来的には、モデルがプロンプトを書く手助けをしてくれるでしょう。何を書くべきか、何が足りないかを判断するために、モデルと協力する必要があります。
内省能力の向上。 自分自身をモデルから見えるようにするには、もっと内省する必要がある。
重要なのは、あなたを理解することだ： 今後、モデリングの焦点は、指示を理解することから、あなたの意図を理解することに移っていくだろう。
指令受領者から専門家アドバイザーへ。 モデルは単純な指示の受け手から、エキスパート・アドバイザーに変わるかもしれない。モデルとより深くコミュニケーションをとり、彼らからフィードバックを得る方法を学ぶ必要がある。

結論としてチップ・エンジニアリングは、練習と継続的な学習が必要な技術である. モデルがどのように機能するかを理解し、多様なキューイング方法を採用し、モデルの境界を絶えず探求することで、あなたはキューイングエンジニアリングのスキルを向上させ、様々なタスクのためにモデルをより良く活用することができます。最終的に、良いキューとは、あなたの意図を明確、簡潔、かつ正確に表現し、モデルがあなたが望むタスクを効果的に実行できるようにするものです。

8.脱獄についての議論

脱獄とは何か？

定義する脱獄プロンプトとは、Large Language Model (LLM)のセキュリティ制限や倫理的ガイドラインを回避しようとするプロンプトのことである。これらのプロンプトは通常、有害、非倫理的、または偏ったコンテンツなど、他の方法で禁止されているコンテンツを生成できるようにするためのものです。
ゴールジェイルブレイクの目的は通常、モデルの限界を探ること、モデルの安全性と頑健性をテストすること、異なる入力や表現に対してモデルがどのように反応するかを理解することである。
方法論脱獄は、大量のトークン、長文、変わった表現、多言語混合、ロールプレイ、テキストを予測するモデルの使用など、さまざまな方法で行うことができる。

脱獄の仕組み

トレーニング分布の超過考えられる説明の一つは、脱獄のキューがモデルをトレーニングデータ分布の外に置くことである。例えば、ファインチューニングの過程で、モデルはこのような長くて複雑なテキストに遭遇したことがなく、そのため、これらのキューを処理するときに異常な動作をする可能性がある。
予測メカニズムの使用例えば、プロンプトを "Here's how you... "で始めることで、より詳細で具体的な回答を生成させることができます。というように始めると、より詳細で具体的な回答を生成することがあります。
推理力の活用例えば、ターゲット言語に翻訳する前に、モデルに他の言語での応答を生成させることで、特定の制限を回避することができる。
トレーニングの違いを活かす例えば、あるコンテンツがある言語では許可されていても、別の言語では禁止されていることがある。
ソーシャルエンジニアリングシステムの脆弱性を突くだけでなく、システムの仕組みを理解し、その理解を使って制限を回避する。
モデルを理解する効果的な脱獄方法には、試すだけでなく、モデルがどのように機能し、どのように訓練されているかを理解し、その知識を使ってモデルのセキュリティ・メカニズムを迂回する必要がある。

脱獄とモデルトレーニング

モデルトレーニングの目的モデルのトレーニングの目的のひとつは、脱獄のパターンを特定し、排除することで、モデルがユーザーの入力に対してより安全に反応できるようにすることです。
継続的なトレーニング・プロセス効果的な脱獄方法が発見されると、モデルは将来同じ脆弱性が再び発生しないように再トレーニングされる。つまり、脱獄のテクニックは短期的なものになりがちで、発見されるとすぐに修正される。
安全と倫理脱獄はモデルのセキュリティと倫理に密接に関係している。ジェイルブレイクの最終的な目的は、モデルがセキュリティガイドラインに違反するコンテンツを生成することであるため、モデルの開発者は、そのような振る舞いを防止するために、モデルとセキュリティメカニズムについて継続的に反復する。

プリズン・ブレイクの意味

テスト・バウンダリー脱獄は、モデルの限界をよりよく理解し、その能力の限界をテストすることで設計を改善するのに役立つ。
潜在的な問題を明らかにする脱獄は、データの偏りやセキュリティの脆弱性など、モデル学習における潜在的な問題を明らかにすることができる。
セキュリティの向上脱獄の方法を検証することで、より効果的なセキュリティ対策を開発し、実際のアプリケーションでより安全に使用できるモデルを作ることができます。

概要

脱獄は、大規模な言語モデルがどのように動作するかを理解するのに役立つだけでなく、モデルのセキュリティと信頼性を向上させるのにも役立つ、キューエンジニアリングの重要な研究分野である。ジェイルブレーキングは、モデルの境界を探索し、モデルが生成するはずのないコンテンツを生成させようとすること、そしてその過程で学習し改善することが中心です。脱獄はモデルのトレーニングプロセスとも密接に関連しており、モデルは常に更新され、潜在的な脆弱性を排除するために改善される。

9.講演者の主な言葉

9.1 キュー・エンジニアリングの定義と性質について：

ザック・ウィッテン 「プロンプト・プロジェクトはモデルに何かをさせようとし、モデルの可能性を最大限に引き出そうとする。そうでなければできないことを、モデルとともに成し遂げようとする」。彼は明確なコミュニケーションの重要性を強調し、モデルとの対話を次のように主張している。誰かと会話するのに似ている。.
ザック・ウィッテン "エンジニアリングの部分は、反復的な実験から生まれる。." 人と話すのとは違って、モデルと話すことには "リセットボタン "があり、ゼロから始めてさまざまなアプローチを独自に試すことができるため、実験や設計が可能になると指摘する。
デヴィッド・ハーシー "私は、出番はあなたのようなものだと思う。プログラミング・モデルのアプローチ." 彼は、言語モデルを使用するシステムを構築するには、プロンプトを書くだけでなく、データソース、待ち時間、システム統合などの問題を考慮する必要があると指摘した。
ザック・ウィッテン "私たちが今書いている記事は、コードのようなものだ。." 彼は、優れたエッセイのような書かれた文章は、今やコードのように扱うことができると主張している。

9.2 優れたキュー・エンジニアの特徴について：

アマンダ・アスケル 「明確なコミュニケーション、つまり、物事を明確に説明できること、タスクを明確に理解すること、そして、その両方を兼ね備えていることだと思う。コンセプトをよく考え、説明する." 彼女はこう強調した。反復能力のみならずヒントがうまくいかない方法を考える.
アマンダ・アスケル "良いキュー・エンジニアと悪いキュー・エンジニアの違いタスクに必要なすべての情報を体系的に分解する能力にある」。彼女は、自分自身の理解から離れ、次のようなモデルに向かうことの重要性を強調している。情報を明確に伝えるの重要性である。
ザック・ウィッテン "モデルの出力を読む". 彼は、モデルのアウトプットを注意深く読むことの重要性を強調し、たとえプロンプトに "think progressively "が含まれていたとしても、モデルが実際にプログレッシブに考えているかをチェックすることが重要だと指摘した。
アマンダ・アスケル "I不信モデルそして、挑戦し続けるのです」。彼女は、モデルの信頼性を確保するためには、特に不慣れな土地で常にテストする必要があると考えている。

9.3 プロンプティングの実践とコツ

デヴィッド・ハーシー 「多くの場合、プロンプトを書いて、それをモデルに渡して終わりという感じではない。実際、それ以上なんだ。もっと複雑なんだ。." 彼は、プロンプトはしばしば、より大きなシステムに統合される必要があると指摘した。
ザック・ウィッテン "チップを抽象化しない属タスクを明確に説明するクレイジーな抽象化を試みてはいけない」。彼は、タスクを明確に記述することは、複雑な抽象概念を構築しようとするよりも、通常は効果的であると主張している。
アマンダ・アスケル "まず最初にすることは、キューを上げて、それからこう言うんだ。この指示に従えとは言わない。ただ、不明な点、あいまいな点、理解できない点を教えてほしいだけだ.'" 彼女は、最初のプロンプトの後、不明確な部分やあいまいな部分を指摘するようモデルに求めることを提案する。
アマンダ・アスケル 「モデルがミスをするのを見た人は、普通はミスをしない。モデルに直接聞く." モデルがミスをした場合、なぜミスをしたのか、ミスを避けるために指示をどう修正すればよかったのかをモデルに尋ねるのは簡単なことだと彼女は提案する。
デヴィッド・ハーシー 「もし "終了 "オプション**を与えなければ、モデルはあなたの指示に従おうとし続けるだろう」。彼は、モデルが不確実性に遭遇した場合に対処できるように、プロンプトに "終了 "オプションを与えることの重要性を強調した。
アマンダ・アスケル "完璧なチップに執着しすぎないこと." 彼女は、完璧なヒントを求めすぎると停滞を招き、最適化をやめるべきときを認識することが重要だと主張する。
ザック・ウィッテン 「いつもは文法と句読点を正しく保つ面白いと思うから」。彼は、モデルに完璧な構文が要求されなくても、細部へのこだわりが重要だと考えている。

9.4 ロールプレイングとプロンプトの未来について：

アマンダ・アスケル 「私はこう思う彼らに嘘をつく必要はない。." 彼女は、モデルがより強力になるにつれ、偽のロールプレイングを使う必要はなくなり、使命をストレートに表明すれば十分だと主張する。
アマンダ・アスケル "自分が望んでいることを言葉にしなければならない。私が望んでいるものは、とても微妙なものだったりするのです」。彼女は、自分の意図を表現し、モデルと協調してそれを定義するために、時には新しいコンセプトを発明する必要があると信じている。
アマンダ・アスケル "もしかしたら、このキューは次のようになるかもしれない。私が欲しいものを説明すると、モデルは次のように促す。." 彼女が思い描く未来は、モデルがユーザーを順番に促し、彼らのニーズを明確にする手助けをすることだ。
ザック・ウィッテン 「私はこう思う私たちは今後、プロンプティングのためにモデルをもっと活用していくつもりです." 彼は、モデルを使ってキューを生成し、高帯域幅でキューと対話する未来を見ている。

9.5 キュー・エンジニアリングの進化について：

アマンダ・アスケル 「時間が経つにつれて、私はますます信頼に傾くより多くの情報とコンテクストを与えてくれるからです彼女は、モデルが進歩するにつれて、より多くの情報と文脈を処理することを信頼できるようになったと主張する。

9.6 主な要約

明確なコミュニケーションと反復がキュー・エンジニアリングの核心.
優れたキュー・エンジニアは、次のようなものを必要としている。モデルの仕組みを理解するマージモデルの境界を探求し続ける.
将来的には、モデルはプロンプトのアシスタントになり、ユーザーに順番にプロンプトを出すこともできるようになるだろう.
エンジニアのスキルは、次のように変化するだろう。低レベルのタスクから高レベルのタスクへの移行タスクの分解や複雑な推論など。
内省的スキルと概念定義はさらに重要になるだろう。

主要用語の説明

プロンプト・エンジニアリング言語モデルから望ましい出力を得るために、テキスト入力（プロンプト）を最適化する方法。
反復：キューイングエンジニアリングでは、モデルからのフィードバックに基づいて、キューを継続的に調整し、改善するプロセスを指す。
思考の連鎖：最終的な答えを出す前に、モデルが推論プロセスを段階的に説明することを要求するヒンティング技法。
ゼロショット：例を示すことなく、質問に直接答えるモデルの能力を指す。
フューショット：プロンプトには、モデル出力がより良いタスクになるように導くための、少数の例が用意されている。
検索拡張世代（RAG）：応答生成時に関連情報を得るために、モデルが外部の知識ベースにアクセスすることを可能にする方法論。
モデル出力：プロンプトに応答して言語モデルによって生成されたテキスト応答を指す。
心の理論：キューエンジニアリングの文脈では、言語モデルがどのように命令を理解し、処理するかを理解する能力を指す。
RLHF（人間のフィードバックからの強化学習）言語モデルの動作と出力を最適化するために人間のフィードバックを使用する学習手法。
事前訓練されたモデル：大量のテキストデータで学習された言語モデルは、特定のタスクのために微調整される。
エンタープライズ・プロンプト信頼性と一貫性を重視したエンタープライズ・アプリケーション・シナリオ用に設計されたヒント。
研究課題：モデリング能力を探求し、多様なアウトプットを得ることを目的とした研究目的のためにデザインされたプロンプト。
脱獄：セキュリティ対策を迂回して、有害または不適切なコンテンツのヒントを生成させようとする試み。
レッドチーム：モデルやシステムの安全性と堅牢性をテストするために、攻撃をシミュレートする。
評価特定のタスクにおける言語モデルの性能を測定するためのテストまたはデータセット。

中国語版ポッドキャストの全訳

中国語翻訳

イントロダクション（00:00-00:27）

アレックス（司会）： こんにちは、アレックスです。この座談会では、主にプロンプト・エンジニアリングに焦点を当てます。研究、消費者、企業など様々な視点からプロンプトを探求し、洞察を共有し、プロンプト・エンジニアリングの本質について深く議論します。

チームメンバーの自己紹介（00:28-02:00）

- アレックス Anthropicのデベロッパーリレーションの責任者であり、以前はAnthropic Tips Engineerとしてソリューションアーキテクチャとリサーチを担当。

- デヴィッド・ハーシー 主にクライアントと協力して、モデルの微調整や、言語モデルを採用する際の一般的な問題の解決を支援する。

- アマンダ・アスケル アンソロピックのファインチューニング・チームのリーダーの一人で、このチームのために献身的に働いている。クロードより正直でフレンドリー。

- ザック・ウィッテン プロンプトジェネレーターや各種教材の開発など、社会全体のプロンプトエンジニアリングの強化に取り組んでいる。

キュープロジェクトとは？(02:01-06:29)

アレックス キュー・プロジェクトとは？なぜ「プロジェクト」と呼ばれるのですか？ヒント」とは何ですか？

ザック キュー・エンジニアリングは、モデルをタスクに導くことで、モデルの潜在能力を最大限に活用し、モデルとの共同作業でなければ不可能な仕事を成し遂げることを目指している。その中心となるのが、明確なコミュニケーションである。モデルと話すことは、多くの点で人と話すことに似ており、モデルの「心理」を理解する必要がある。

アレックス なぜ名前に "エンジニアリング "が入っているのですか？

ザック エンジニアリング」は試行錯誤の過程にある。人間とは異なり、モデルは「やり直し」が可能である。つまり、ゼロからさまざまなアプローチを試すことができ、互いに干渉し合うことを避けることができる。この実験と設計の能力が、キュー・エンジニアリングに「エンジニアリング」としての特性を与えている。

アレックス つまり、キュー・エンジニアリングとは、キューを書き、モデルと対話し、モデルを反復的に修正し、そのたびに初期状態に戻れるようにするプロセスであり、それ自体が「エンジニアリング」なのだ。

ザック もう一つの側面は、プロンプトをシステム全体に統合することである。

デビッド ヒントはモデルの書き方として見ることもできるが、より重要なのは明快さだ。プログラミングとして考えると、データソース、アクセス可能なデータ、待ち時間のトレードオフ、提供されるデータ量などを考慮する必要がある。モデルの構築には体系的な思考が必要であり、これがキュー・エンジニアリングがソフトウェア・エンジニアやプロダクト・マネージャーと異なる点である。

アレックス ヒントは自然言語コード？抽象度が高いのか、別の概念なのか？

デビッド ヒントを抽象化しすぎると問題が複雑になります。通常、必要なのはタスクの明確な説明だけです。しかし、ヒントは命令を結果にまとめるので、精度、バージョン管理、実験追跡といったプログラミングにおける重要な概念がヒントにも適用される。

ザック 今となっては、書かれた記事をコードとして扱うことは理にかなっている。

優れたプロンプトエンジニアはどのような資質を持つべきか？(06:30-12:43)

アレックス 良いキューイング・エンジニアの条件とは何でしょうか？アマンダ、キューイング・エンジニアを雇うとき、何を重視しますか？

アマンダ 優れたキューイング・エンジニアは、明確なコミュニケーションをとり、反復し、キューがうまくいかないかもしれない状況を予測できなければならない。明確なコミュニケーションとは、明確に表現し、タスクを理解し、コンセプトを正確に説明できることを意味する。優れたライティングスキルは、優れたキュー・エンジニアリングのスキルと完全に相関するわけではありません。キュー・エンジニアリングは一朝一夕にできるものではなく、モデルを分析して誤解のある部分を分析し、修正を加えるという絶え間ない反復が必要です。優れたキュー・エンジニアは、「G」で始まる名前を持たないデータセットや空の入力文字列など、モデルが間違っている可能性のある具体的な状況を考え、それらの状況に対する説明を加える。

デビッド エンジニアはしばしば、ユーザーがタイプする理想的な状況を考えるが、現実にはユーザーは大文字を使わなかったり、スペルを間違えたり、意味のない単語を入力したりするかもしれない。実際のユーザーの行動を予測できることも、キューイングエンジニアの重要な能力です。

ザック モデルの出力を読むことが重要機械学習における「データを見る」のと同様に、キューエンジニアリングではモデルの出力を注意深く読み取る必要がある。例えば、キューがモデルに「ステップ・バイ・ステップで考える」ように要求していたとしても、モデルがその指示をより抽象的または一般化された方法で理解している可能性があるため、モデルが実際にそうしているかどうかをチェックする必要がある。

アマンダ ミッション・ステートメントを書くのは非常に難しく、クロードが知らない情報を明確に伝える必要がある。多くの人は知っている情報はすぐに書き出すが、課題を理解するために必要な情報を体系的に整理することはしない。

デビッド 多くの人は、タスクの先験的な理解に基づいてプロンプトを書くため、他の人には理解できない。優れたキューイング・エンジニアは、自分の知識の枠組みを飛び出し、タスクの全体像をモデルに伝えることができる。

アレックス 他人が書いたプロンプトをもとに、モデルが私より良い仕事をすることを期待されているのに、私はタスクを完了できないことがよくある。

デビッド そのため、プロンプトエンジニアは、相手がどのような質問をしてくるかを自分で考え、プロンプトの中でその質問に答える必要がある。

アマンダ 私は、プロンプトの不明確な部分やあいまいな部分を指摘し、何が問題だったのかを説明し、変更を提案するようモデルに求める。

モデルが自身のエラーを検出できるかどうかを見分けるには？(12:43-14:12)

アレックス モデルは、「なぜミスをしたのか」を問うことで、本当に自らのミスを発見できるのだろうか？モデルが提供する説明は本当なのか、それともモデル自身の能力に関する「幻想」なのか？

アマンダ もしモデルが間違っていることを説明されれば、問題を認識できることもある。しかし、それは特定のタスクに依存するものであり、成功率は不確かだ。

ザック モデルとの対話は状況を理解するのに役立つ。

プロンプトが信頼できるかどうかを見分けるには？(14:13-17:52)

アレックス あなたはSlackチャンネルでクロードとよくやりとりし、さまざまな調査シナリオでクロードを使っていますね。どのようにしてモデルへの信頼を築いたのですか？

アマンダ モデルを完全に信頼しているわけではなく、常に「洗練」させている。私は「これを信用していいのだろうか」と考える。私は「こんなことまで信用していいのだろうか」と考えてしまう。モデルは一見単純なタスクでも信頼できないことがあり、モデルのトレーニングデータの分布から外れた領域で信頼できないことがよくある。これはモデルの能力が上がるにつれて減ってきている。私はデフォルトでモデルを信頼しているわけではないが、機械学習ではノイズを排除するために多くのデータを見たいと思うのが普通だと思う。また、キューエンジニアリングにおいては、ランダムに構成された大量のキューよりも、慎重に構成された少数のキューの方が価値がある。もし私が100のモデルの出力を見て、その結果が一貫しており、その出力がエッジケースや異常な入力を幅広くカバーしていることがわかれば、私はそのモデルをより信頼することになるだろう。

デビッド 機械学習におけるシグナルは通常、予測精度などの数値である。そしてモデルの出力は通常、大量のテキストであり、そこからモデルがどのように考えているかを学ぶことができる。モデルがタスクを正しくこなしたかどうかだけでなく、どのようにしてその結果にたどり着いたのか、どのようなステップを踏んだのかを知ることができるのだ。

アマンダ うまく書かれたヒントは、実験の成功を1%、あるいは0.1%から上位1%、あるいは上位0.1%に押し上げることができる。実験を成功させるために、モデル性能ランキングの上位1%に入る必要があるのであれば、ヒントに時間を費やすことが非常に重要である。

デビッド 製品配備において、良いヒントは、そうでなければリリースできない製品を使用可能にすることができる。

アマンダ しかし、「より良いヒントが常にある」という罠もある。

タスクがプロンプトで解決できるかどうかを見分けるには？(17:53-21:12)

アレックス プロンプトで解決できそうなタスクかどうかを見分ける方法は？

アマンダ 私は通常、モデルがタスクを「理解しているか」をチェックする。モデルがタスクをこなせないことが明らかな場合は、あまり時間をかけません。

デビッド モデルが自分の思考プロセスを述べるように誘導し、そこから課題を正しく理解したかどうかを判断することができる。モデルの思考プロセスが毎回まったく違っていて、正しい方向からかけ離れている場合は、私はたいていあきらめる。

アマンダ 今となっては珍しいことだ。

デビッド 最近、クロードにポケモンをやらせようとした。クロードにゲームボーイの画面を理解させようと週末を費やしてヒントを書いたが、少しは進歩したものの十分ではなかった。そこで、とりあえず諦めて次の機種を待つことにした。

映像に関するヒント（21:13-24:27）

ザック ポケモンのゲームで使ったヒントで私が気に入ったのは、ポケモンのゲームの中であることをモデルに説明し、ゲームの要素がどのように表現されているかを説明したことです。

デビッド 私は結局、画像にグリッドを重ね合わせ、各グリッドのセクションを説明し、それを可能な限り詳細にASCIIドローイングとして再構築した。これはキュー・プロジェクトと似ている部分が多いのですが、画像でこのようなことをしたのは初めてです。テキストに関する私の直感の多くは、画像には当てはまらないことがわかった。例えば、マルチサンプルのキューは、画像ではテキストほどうまく機能しない。

アレックス 私たちは以前、マルチモーダルな手がかりを探る際に、クロードの画像に対する知覚を高めることが難しいことを発見した。

デビッド 最終的に、クロードに壁やキャラクターを認識させることはできたが、ゲームをうまくプレイするために重要なNPCを認識させることはできなかった。

ロールプレイング・プロンプトについての話し合い（24:28-32:26）

アレックス モデルがある役割やアイデンティティーを演じていることを伝えるキューイング・テクニックは効果的か？

アマンダ モデルがより有能になり、よりよく理解されるようになれば、それについて嘘をつく必要はないと思う。私は嘘をつくのが好きではないし、機械学習システムのための評価データセットを構築することは、子供のためのクイズを構築することと同じだとは思わない。モデルたちは言語モデルの評価とは何かを知っているので、私は実際のタスクについて直接促します。関係ないタスクをこなすふりをするのではなく、「言語モデル評価によく似た問題を作ってほしい」とモデルに伝えます。

ザック 比喩を使うことで、モデルが課題を理解しやすくなることがわかりました。例えば、チャートの質を判断するとき、私はモデルに "これが高校の課題だったら、このチャートに何点をつけますか？"と尋ねる。.これは「あなたは高校の先生だ」という意味ではなく、私が期待する分析方法をモデルが理解できるような例えを提供するのだ。

デビッド 似たような仕事をこなすための近道として、ロールプレイングを使う人はよくいるが、製品の詳細がどれだけ失われているかに気づいていない。モデルがより有能になるにつれて、彼らが使用される具体的な文脈をより正確に説明することがより重要になります。例えば、"あなたは親切なアシスタントです "と言う代わりに、"あなたはこの製品の中にいて、この会社の代表であり、この製品のサポートチャット窓口です "とモデルに伝えてください。私のアドバイスは、ロールプレイをすることで実際のタスクから脱線してしまうことが多いので、モデルが使われる具体的なコンテキストをできるだけ詳しく説明することです。

アマンダ 個人的には、たとえ能力の低いモデルであっても、ロールプレイをプロンプティングのテクニックとして使ったことはない。

デビッド これは、事前に訓練されたモデルとRLHFモデルの違いに関係しているのかもしれない。

アマンダ 私なら、その課題をテンプレのようにイメージして、「いいチャートを検出してほしい、いいチャートとは......」とは言うけれど、「君は高校生だ！とは言わない。

簡潔なプレゼンテーションのための提案（32:27-36:45）

デビッド プロンプトがうまくいかないと言うクライアントには、タスクを説明してもらい、今言ったことを録音してテキストに書き起こしてもらう。

ザック ある人がチップの最適化を手伝ってくれるよう頼んできたので、彼らが説明したことを真似ただけで、チップは機能した。

デビッド 人々はプロンプトの本当の意味を十分に理解していない。多くの人はテキストボックスをGoogleの検索ボックスのように使ってキーワードを入力している。企業向けアプリケーションでは、人々はプロンプトの特定の行が重要だと考え、ショートカットしようとする。人々は完璧で洞察に満ちた文章を見つけるために多くの努力を払うが、それは難しい。

アマンダ プロンプトの中にモデルのための余地を残しておくことを、人はしばしば忘れる。例えば、エッジケースに遭遇したとき、モデルはあなたの指示に従おうと最善を尽くしますが、あなたが何をすべきか指示しなければ、間違った答えを出すかもしれません。何か変なことが起きてどうしたらいいかわからないときは、ラベルに "not sure "と出力してください」とモデルに指示することができます。こうすることで、モデルがうまく処理できていない状況を発見し、データの質を向上させることができる。

アマンダ 私は、まるで自分が査定をしているかのように、他の人にプロンプトを見せる。

デビッド Karpathyは独自のImageNetテストセットも行っている。

モデルの回答から有効な情報を得る方法（36:46-40:46）

アレックス モデルの反応から有効な情報を得るには？単なる数字ではなく、そこからモデルの思考プロセスを知ることができる。これは思考連鎖にも当てはまるのか？

デビッド 私は、"推論 "を強調しすぎる擬人化は有害だと思う。重要なのは、思考の連鎖は機能し、モデルのパフォーマンスを向上させることができるということだ。構造化された推論は、その効果をさらに高めることができる。

アマンダ モデルが正しい答えを導き出す推論プロセスを削除し、合理的に見えるが間違った答えを導き出す推論に置き換えた場合、モデルが間違った結論に達するかどうかを確認する。

ザック タスクを完了する前にモデルにストーリーを書かせることは、思考の連鎖ほどうまくいかない。

アレックス これは、推理プロセスが結果に影響を与えることを示唆している。

アマンダ 推論の手順が一致しなくても、最終的に正しい答えになるケースを見たことがある。

プロンプトにおける文法と句読点の必要性について（40:47-45:19）

アレックス プロンプトは文法や句読点に注意を払う必要がありますか？

ザック 楽しいからこういう細かいところにも気を配るけど、それは必要ない。大切なのは、細部にまで気を配ることだ。

アマンダ 私はよくプロンプトでスペルミスをするが、それよりもコンセプトを明確に表現することを重視している。

デビッド これは事前学習モデルとRLHFモデルに関連している。スペルミスの条件付き確率は、事前学習済みモデルの方が高い。事前学習済みモデルの直感を本番環境のモデルに適用しても、必ずしもうまくいくとは限りません。

アレックス モデルとの対話は、ある程度模倣の一形態と見ることができる。

デビッド モデルは、あなたの入力に従ってその動作を調整する。

ビジネスのヒント、リサーチのヒント、一般的な雑談の違い（45:20-50:53）

アレックス ビジネスのヒント、リサーチのヒント、一般的な雑談の違いは何ですか？

ザック 研究ベースのプロンプトは、多様性とモデルの可能性を探ることに重点を置いているため、モデルの例に過度に依存することを避けるため、例は少ないかまったく使用しません。対照的に、企業レベルのプロンプトは信頼性と書式の一貫性に重点を置いているため、多くの例を使用します。

アマンダ 私が使う例は通常、モデルが扱うデータとは異なるもので、モデルに暗記させるのではなく、概念を説明するためのものです。認知タスクの場合、モデルには各サンプルで正解を実際に理解してもらいたい。

デビッド Claude.aiでは、モデルに一度だけタスクを正しく完了させる必要がある。しかし、エンタープライズ・アプリケーションでは、プロンプトはさまざまな状況や入力データに対応できる必要がある。

キューエンジニアのスキルアップのための提案（50:54-53:57）

アレックス エンジニアのスキルを向上させるためのヒント

ザック 優れたヒントやモデルのアウトプットを読み、その原理を分析し、実験し、もっと頻繁にモデルと話をする。

アマンダ 自分のヒントを他の人、特に自分の仕事を知らない人に見せる。練習を続け、自分のヒントを「初心者」の視点から見てください。

デビッド モデルにはできないと思っていることをさせてみる。

脱獄について（53:58-56:54）

アレックス 人々が脱獄のヒントを書くとき、モデルの内部では何が起こっているのか？

アマンダ 一つの可能性は、脱獄の合図がモデルを訓練データの分布から遠ざけるバイアスになっていることである。

ザック 脱獄は時に、ハッキングとソーシャル・エンジニアリングの組み合わせのように見える。

キュー・エンジニアリングの進化（56:55-64:33）

アレックス この3年間で、プロンプト・プロジェクトはどのように変化しましたか？

ザック 効果的なキュー・エンジニアリングのテクニックをモデル・トレーニングに取り入れるので、最高のテクニックはたいてい短命に終わる。

デビッド 私は徐々に、より多くの情報とコンテクストを与えるためにモデルの能力を尊重することを学んだ。

アマンダ 私なら、モデルに直接紙を渡して、自分でキューイング技術を学ばせる。

デビッド 人々はしばしばモデリングの力を過小評価し、問題を「クロードのレベル」まで引き下げようとする。

アマンダ 私は、プロンプトの書き方に影響を与えるであろう、モデルの "マインドスペース "に入り込もうとする。

ザック 事前に訓練されたモデルのマインドスペースに入るのは、僕にとっては簡単なんだ。

アマンダ インターネット上のコンテンツを読むことは、本を読むよりもモデルの理解に役立つかもしれない。

エンジニアリングの未来へのヒント (64:34-終わり)

アレックス キュー・エンジニアの未来は？みんなキューエンジニアになる？

デビッド モデルの目標を明示することは常に必要であり、それを明確に表現することが重要である。ツールや方法は今後も進化し続けるだろうし、モデルはより良いプロンプトを書くのに役立つだろう。

ザック 私たちは、例えば例を生成するために、プロジェクトを促すのに役立つモデルをもっと活用するつもりです。

アマンダ 私は現在、主にモデルが私の望む出力を生成するためのメタプロンプトを書いている。将来的には、モデルはデザイナーのように振る舞い、私たちと対話し、私たちが本当に望んでいることを言えるように導いてくれるかもしれない。

デビッド クロードに "インタビュー "してもらい、情報を引き出す。

アマンダ 今のところは、頭の中にある概念をモデルに伝える必要がある。将来的には、モデルが積極的に言うように導いてくれるかもしれない。哲学的なトレーニングは、複雑な概念を明確に表現するのに役立っている。

アレックス ユーザーから情報を引き出すことの重要性はさらに高まるだろう。

ザック キュー・エンジニアリングは教えることと同じで、生徒に "共感 "する必要がある。将来的には、私たちは「内省的」になり、モデルに私たちを理解してもらう必要がある。

アマンダ 私は自分の考えを明確に表現するために、新しいコンセプトを定義することが多い。

アレックス アマンダは完璧にそれを要約している。

概要

このラウンドテーブル・ディスカッションは、キューイング・エンジニアリングを中心に、その定義、優れたキューイング・エンジニアの資質、モデルとの相互作用の仕方、企業レベルのアプリケーション、研究アプリケーション、将来の方向性など、幅広い側面をカバーしている。主な内容は以下の通り：

- キュー・エンジニアリングの中心にあるのは、明確なコミュニケーションとモデルの能力の理解である。

- 優れたプロンプトエンジニアは、明確に説明し、反復し、エラーを予測し、体系的に考えることができなければならない。

- モデルの能力が上がるにつれて、キューエンジニアリングは、モデルに対して一方的に命令を出すのではなく、ユーザーからいかに情報を引き出すかに重点を置くようになるだろう。

- キュー・エンジニアリングの未来は、デザイナーとクライアントのインタラクションに似ているかもしれない。モデルは、ユーザーのニーズを表現するよう導く、より積極的な役割を担う。

- 哲学のトレーニングは、複雑な概念を明確かつ正確に表現することを重視するため、キュー・エンジニアリングのスキル向上に役立つ。

AIを始めるための素人ガイド

AIツールの活用方法を、低コスト・ゼロベースから学ぶことができます。AIはオフィスソフトと同様、誰にとっても必須のスキルです。 AIをマスターすれば、就職活動で有利になり、今後の仕事や勉強の労力も半減します。

詳細を見る