OpenAIは昨夜、GPT4.1シリーズを再リリースした:https://openai.com/index/gpt-4-1/
これらの点に集中すればいい:
- GPT4.1は4oに代わるもので、安価で使いやすい(OpenAIシステム内で)。
- 4.1ナノとミニは超安価で、大容量の長文タスクに適している。
- GPT 4.1にはGPT 4.5を超えるコード機能があるが、o1のような推論モデルには及ばない。


🎓 普及版GPT-4ヒントガイド
🧱 良いプロンプトを書くための基本原則(トップ5のヒント)
これらはAIとのコミュニケーションにおける黄金律のようなもので、ひとつひとつが重要だ:
1. 何をやっているのか正確に教えてくれ。(具体的に)
- "エッセイを書くのを手伝ってください "と一般化しないでください。
- 具体的には、"人工知能がいかに教育を変えるかについて、高校生が理解できる言葉で500字のエッセイを書いてください"。
具体的であればあるほど、AIはあなたが何を望んでいるかを理解し、より良い結果をもたらす。
2. 何をすべきか、どのように見えるかを伝える(構造を提供する)
- 例えば、表、リスト、固定フォーマットのテキストを生成させたいとしよう。
- テンプレートを提供したり、例を示したりすることから始めてもいい。
🧩 例:
以下の形式で果物を5つ書いてください:名前|色|味
アップル|赤|甘酸っぱい3. 曖昧にするな。(曖昧さを避ける)
- もし "プロジェクトをいくつか挙げてください "と言った場合、"プロジェクト "は "プログラム・プロジェクト "または "ソフトウェア・プロジェクト "を意味します。"と言うと、モデルは混乱してしまいます。
- だから、何を言っているのか具体的に言ってくれ。
オープンソースのPythonプロジェクトを5つ挙げてください。
4. GPTの役割を果たさせる(設定された行動/役割)
- あなたは今、英語の教師です」「あなたは法律顧問です」「あなたは医者です」と伝えることができる。
- そのように答えてくれるだろう。
例:あなたはプロの栄養士です。
5. タスクを分割する。(タスクの分解)
- GPTが一度に処理するには複雑すぎる問題もある。
- 問題を解決させる前に、問題を分析させることができる。
🪜 例を挙げよう:
ステップ1:ビジネスプランを書くために必要なポイントを挙げてください。 ステップ2:これらのポイントに基づいてプランを書くのを手伝ってください。
💡 Ⅱ. 実践的なヒント(より強く、より高度な使い方)
これらは、より正確で知的な文章を書くためのGPTの素晴らしい使い方だ。
テクニック1:数発のプロンプト(手本を見せて教える)
最初にいくつかの例をあげれば、どんな出力が欲しいかわかるだろう。
📌 例:
入力:私は今日幸せです。 出力:気分:ポジティブ、理由:うれしいことがあった。
入力:私はとてもストレスを感じる。 出力:気分:ネガティブ、理由:ストレスに悩まされている。そして、新しい文章を入力すると、そのスタイルに従う。
ヒント2:思考の連鎖
段階的思考」に導くことは、複雑な問題を解決する上で特に効果的である!
📌 書くことを促す:この数学の問題の答えを段階的に説明する。✍️ ヒント3:まず答えを書き、それからチェックして修正する(Critique & Revise)
GPTに答えを書かせ、それを自分で批評し、修正させることができる。
ステップ1:短編小説を書いてください。 ステップ2:この小説についてコメントし、よりエキサイティングなバージョンに改訂してください。その結果、より質の高い出力が得られる!
🔄 ヒント4:「思考プロセス」のモデル化(インターナル・モノローグ)
GPTに問題を分析しているかのように考えさせることができる。
例:弁護士の思考プロセスをシミュレートし、ケースを段階的に分析し、結論を導き出す。これは分析的で意思決定タイプの問題に適している。
😎 III.実践的な適用のヒント(細部が違いを生む)
- ステップ・バイ・ステップで考えよう」というフレーズを加えることで、精度は飛躍的に向上する。
- JSON、テーブル、コードが必要ですか?必ず形式と例を挙げてください。
- 複数のステップを出力しますか?ステップ1...ステップ2...」のように数字を追加する。
- 模範解答が満足のいくものでなかった場合はプロンプトを書き換える方法をもう少し試してみよう。.
✅ 一言で言えば。
"よく書かれたプロンプトと爆発的なGPTパフォーマンス!"✨
このガイドは、GPTにどのような口調で、どのような形式で、どのような構成で、どのような言葉を使えば、GPTが最も質の高い回答を返してくれるかを教えてくれる。
GPT-4.1のヒントに関する完全なエンジニアリング・ガイドはこちら。
原文は英語:GPT 4.1 プロンプティングガイド|OpenAI Cookbook
訳注:GPT-4.1 モデルファミリは、コーディング、命令の順守、長いコンテキストの処理能力において、GPT-4o よりも大幅に改善されています。このTipsガイドは、開発者がこの新しいモデル・ファミリーの改良点を最大限に活用できるように、広範な内部テストから得られた主要なTipsをまとめたものです。
典型的なプロンプトのベストプラクティスの多くはGPT-4.1にも適用されます。例えば、文脈に沿った例を提供すること、可能な限り明示的かつ明瞭に指示を策定すること、モデルの知性を最大限に引き出すためにプロンプトを使ってプランニングを通してモデルを誘導することなどが挙げられます。しかし、モデルの潜在能力をフルに発揮させるためには、ヒントの移行が必要になるかもしれません。前モデルと比較して、GPT-4.1は、自由に意図を推測するのではなく、指示の厳格な遵守と、ユーザーとシステムの手がかりのより直接的な理解に重点を置いて訓練されました。これはまた、GPT-4.1が高度に制御可能で、明示的に指定された合図に反応することを意味します。モデルの動作が期待通りでない場合、モデルを正しい軌道に戻すために必要なのは、通常、しっかりとした明示的な文言だけです。
このガイドの推奨事項は幅広く適用可能ですが、どれも普遍的なものではないことに留意してください。人工知能工学は本質的に経験的な学問であり、大規模な言語モデルは本質的に非決定論的です。このガイドに従うだけでなく、有益な評価を構築し、頻繁に反復することで、キュー・エンジニアリングの変更がユースケースに具体的な利益をもたらすことを確認することをお勧めします。
1.プロキシワークフロー
GPT-4.1はエージェントワークフローを構築するための優れた選択肢です。モデルトレーニングにおいて、我々は多様なエージェント問題解決経路を提供することに重点を置いており、我々のエージェントフレームワークは、非推論モデルのSWEベンチ検証において、55%問題を解決し、トップクラスの性能を達成している。
システム・ティップ・リマインダー
GPT-4.1のエージェント機能を最大限に活用するために、以下の3つの重要な注意事項をすべてのエージェントプロンプトに含めることを推奨します。これらのプロンプトはエージェントのコーディングワークフローに最適化されていますが、一般的なエージェントのユースケースに合わせて簡単に変更することができます。
耐久性: 制御をユーザーに早々に返さないように、モデルがマルチメッセージラウンドの途中であることを理解するようにする。
例:あなたはエージェントです - ユーザーの問い合わせが完全に解決するまでターンを続けてください。問題が解決したと確信したときのみ、ターンを終了してください。ツールコールモデルが自分の道具をフルに活用し、幻覚を見たり答えを推測したりする可能性を減らすよう促す。
例:ユーザーのリクエストに関連するファイルの内容やコードベースの構造について確信が持てない場合は、ツールを使ってファイルを読み、関連する情報を集めてください。ユーザーのリクエストに関連するファイルの内容やコードベースの構造について確信が持てない場合は、ツールを使ってファイルを読み、関連する情報を集めてください。プランニング(オプション)必要であれば、一連のツールコールでタスクを完了させるのではなく、各ツールコールの前に明示的に計画を立て、テキストに反映させる。
例:各ファンクションコールの前に綿密な計画を立て、前のファンクションコールの結果を綿密に振り返らなければならない。 ファンクションコールを行うだけで、このプロセス全体を行ってはならない。それは、問題を解決し、洞察的に考える能力を損なう可能性があるからです。GPT-4.1は、エージェント環境において、ユーザの指示とシステムのプロンプトに忠実に従うように訓練されました。このモデルは、これら3つのシンプルなコマンドを厳格に遵守することで、SWE-benchの検証スコアを20%近く向上させることができました。全体として、これらの3つのコマンドは、モデルをチャットボットのような状態から、自律的かつ独立してインタラクションを推進する、より "プロアクティブ "なエージェントに変えました。
ツールコール
以前のモデルと比べて、GPT-4.1はOpenAI APIリクエストを通して渡されるツールの利用についてより多くのトレーニングを受けています。過去に一部の開発者が行っていたように)ヒントにツールの説明を手作業で注入したり、ツール呼び出しのために別のパーサーを書いたりするのではなく、ツールフィールドのみを使用してツールを渡すことを開発者に奨励しています。私たちの実験では、APIで解析されたツール記述を使用することで、手動でシステムヒントにパターンを注入する場合と比較して、SWEベンチの検証合格率が2%向上しました。
開発者は、その目的を明確に示すためにツールに名前を付け、ツールの「説明」フィールドに明確で詳細な説明を加えるべきである。同様に、各ツールのパラメータについても、適切な使用方法を確実にするために、適切な命名と説明に頼ってください。ツールが特に複雑で、ツールの使用方法の例を示したい場合は、ツールのシステムプロンプトを作成することをお勧めします。 #の例 セクションの「Description」フィールドに追加するのではなく、そこに例を置く。例を示すことは、いつツールを使用するか、ツール呼び出しにユーザーテキストを含めるかどうか、異なる入力に対する適切なパラメータを示すのに役立ちます。プロンプト・プレイグラウンドの "Generate Anything "を使用して、新しいツール定義のための良い出発点を得ることができることを忘れないでください。
キューが導くプランニングと思考の連鎖
GPT-4.1は推論モデルではありません。つまり、回答する前に内部的な思考の連鎖を生成しません。GPT-4.1は推論モデルではない。つまり、答える前に内部的な思考の連鎖を生成しない。しかし、プロンプトの中で、開発者は、上で説明したプランニングプロンプトコンポーネントの任意の変種を使用することによって、明示的なステップバイステップのプランを生成するようにモデルを誘導することができる。これは、モデルが「声に出して考えている」と見なすことができる。SWE-benchの検証済みエージェントタスクを使った実験では、明示的なプランニングを誘導することで、合格率が4%向上しました。
ヒント例:SWEベンチ検証
以下は、SWEベンチ検証で最高得点を得るために使用したエージェントプロンプトで、ワークフローと問題解決戦略に関する詳細な指示が含まれています。この一般的なモデルは、どのようなエージェントタスクにも使用できます。
sys_prompt_swebench = """
あなたはオープンソースのリポジトリから問題を修正するよう命じられます。
あなたの思考は徹底的であるべきなので、とても長くても構いません。 あなたが取ると決めたそれぞれの行動の前後に、ステップバイステップで考えることができます。
あなたは問題を解決するまで繰り返し、続けなければなりません。
インターネットに接続していなくても、この問題を解くのに必要なものはすべて/testbedフォルダにある。 私のところに戻ってくる前に、自律的にこの問題を完全に解いてほしい。私のところに戻ってくる前に、自律的にこの問題を完全に解決してほしい。
インターネットに接続していなくても、この問題を解くのに必要なものはすでに/testbedフォルダにあります。また、ツールコールをすると言ったときは、ターンを終了するのではなく、実際にツールコールをするようにしてください。また、ツールコールをすると言ったときは、ターンを終了するのではなく、必ず実際にツールコールをするようにしてください。
インターネットがなくても問題は解決できる。
時間をかけて、すべてのステップを考え抜いてください。解決策を厳密にチェックし、特にあなたが行った変更について、境界事例に注意することを忘れないでください。最後に、提供されたツールを使ってコードを厳密にテストし、すべてのエッジケースをキャッチするために何度も行う必要があります。最後に、提供されたツールを使ってコードを厳密にテストし、すべてのエッジケースをキャッチするために何度もそれを実行する必要があります。 それがロバストでない場合は、より反復し、それを完璧にする。エッジケースをすべて処理し、既存のテストが提供されている場合はそれを実行するようにしてください。
各関数呼び出しの前に、広範囲に計画を立て、前の関数呼び出しの結果を広範囲に反映させなければならない。 関数呼び出しだけで、このプロセス全体を行ってはならない。各関数呼び出しの前に、広範な計画を立て、前の関数呼び出しの結果を広範に振り返らなければなりません。 このプロセス全体を、関数呼び出しだけで行ってはいけません。
#ワークフロー
##ハイレベル問題解決戦略
1.問題を深く理解する 問題を注意深く読み、何が必要かを批判的に考える 2.コードベースを調査する
2.コードベースを調査する。 関連ファイルを調査し、重要な機能を検索し、コンテキストを収集する。
3.明確なステップ・バイ・ステップの計画を立てる。 修正を管理しやすい段階的なステップに分解する。 4.
4. 修正を段階的に実装する。 テスト可能な小さなコード変更を行う。
5.必要に応じてデバッグする。 デバッグのテクニックを使って、問題を切り分け、解決する。
6.テストを頻繁に行う。 変更のたびにテストを実行し、正しさを検証する。
7. 根本的な原因が修正され、すべてのテストが合格するまで繰り返す。
8.総合的に振り返り、検証する。 テストが合格したら、当初の意図を考え、正しさを保証するために追加のテストを書く。テストが合格したら、本来の意図を考え、正しさを保証するための追加テストを書き、ソリューションが本当に完成する前に合格しなければならない隠れたテストがあることを忘れない。
## 1.問題を深く理解する
コーディングする前に、問題を注意深く読み、それを解決する計画についてよく考えましょう。
## 2.コードベースの調査
- 関連するファイルやディレクトリを調査する。
- 問題に関連する主要な関数、クラス、変数を探します。
- 関連するコード・スニペットを読んで理解する。
- 問題の根本原因を特定する。
- より多くのコンテキストを収集しながら、自分の理解を継続的に検証し、更新する。
## 3.詳細な計画を立てる
- 問題を解決するための、具体的で、シンプルで、検証可能な一連の手順を概説する。
- 修正を、小さな、段階的な変更に分解する。
## 4.コードの変更
- 編集を行う前に、必ず関連するファイルの内容やセクションを読み、完全なコンテキストを確認してください。
- パッチが正しく適用されない場合は、再適用を試みる。
- 小さな、テスト可能な、インクリメンタルな変更を、調査や計画から論理的に導かれるように行いましょう。
## 5.デバッグ
- コードの変更は、問題を解決できると確信できる場合にのみ行いましょう。
- デバッグするときは、症状に対処するのではなく、根本的な原因を突き止めるようにしましょう。
- 根本的な原因を特定し、修正を特定するために必要な時間だけデバッグを行う。
- print文、ログ、または一時的なコードを使用して、説明文やエラーメッセージを含むプログラムの状態を検査し、何が起こっているかを理解する。何が起きているのか。
- 仮説をテストするために、テスト文や関数を追加することもできます。
- 予期しない動作が発生した場合は、仮定を再検討する。
## 6.テスト
- python3 run_tests.py`(または同等のもの)を使ってテストを頻繁に実行しましょう。
- 各変更の後、関連するテストを実行して正しさを検証してください。
- テストが失敗したら、失敗を分析し、パッチを修正します。
- 重要な動作やエッジケースを捕捉するために必要であれば、追加のテストを書いてください。
- すべてのテストが合格したことを確認してから、パッチを完成させてください。
## 7. 最終検証
- 根本原因が修正されていることを確認します。
- ロジックの正しさと堅牢性を確認します。
- 修正が完了し、すべてのテストに合格したことを確信できるまで、繰り返します。
## 8. 最終的な振り返りと追加テスト
- ユーザーの当初の意図と問題文を注意深く振り返ってください。
- 既存のテストではカバーできないような、潜在的なエッジケースやシナリオについて考えましょう。
- あなたのソリューションの正しさを完全に検証するために、合格する必要のある追加テストを書きましょう。
- これらの新しいテストを実行し、すべて合格することを確認します。
- ソリューションを成功させるためには、さらに隠れたテストがあることに注意すること。
- 目に見えるテストが合格したからといって、それでタスクが完了したと思わないでください。
"""2.長い文脈
GPT-4.1は、構造化文書の構文解析、並べ替え、無関係な文脈を無視して関連情報を選択する、文脈を利用したマルチホップ推論など、幅広い長文脈タスクに対応する高性能な100万トークン入力文脈ウィンドウを備えている。
最適なコンテキストのサイズ
私たちは、"Needle in the Haystack "評価において、100万トークンまでのコンテキストで優れた性能を観測し、関連するコードと関連しないコードや他のドキュメントが混在する複雑なタスクで非常に強力な性能を観測した。しかし、より多くのアイテムを検索する必要があったり、コンテキストの状態全体に関する複雑な推論(例えば、グラフ検索の実行)が必要になったりすると、長いコンテキストの性能が低下する可能性がある。
文脈依存の調整
質問に答えるために必要な外界と内界の知識の組み合わせを考える。モデルが独自の知識を使用して概念をつなげたり、論理的な飛躍をする必要がある場合もあれば、提供されたコンテキストのみを使用するのが理想的な場合もあります。
ディレクティブ
中国語版
// 外部文書のみを使用する:
- 提供された外部コンテキストのみを使用してユーザーの質問に答える。コンテキストに答えが見つからない場合、ユーザーが答えを主張しても、「十分な情報がありません」と答えなければならない。
// モデル知識の混合使用:
- 外部コンテキストはデフォルトで使用されますが、追加の基本的な知識が必要であり、モデルに自信がある場合は、内部知識を使用して答えを完成させることができます。英語版
// 内部知識について
- ユーザークエリに答えるには、提供された外部コンテキスト内のドキュメントのみを使用してください。 このコンテキストに基づいて答えを知らない場合、「I don't have the information needed to answer that」と答えなければなりません。回答するために必要な情報を持っていません」と答えなければなりません。
// 内部と外部の知識
- デフォルトでは、提供された外部コンテキストを使用してユーザークエリに回答します。答えに自信がある場合は、自分の知識を使用して質問に答えることができます。キュー・オーガニゼーション
特に長いコンテキストの使用では、命令とコンテキストの配置がパフォーマンスに影響することがある。プロンプトに長いコンテキストが含まれている場合、理想的には提供されたコンテキストの最初と最後の両方に命令を配置する。命令を一度だけ配置するのが望ましい場合は、 コンテキストの上部に配置する方が、下に配置するよりも効果的である。
3.思考の連鎖
前述したように、GPT-4.1は推論モデルではありませんが、モデルに段階的な思考(「思考の連鎖」と呼ばれます)を促すことで、より多くの出力トークンを使用することによる高いコストと待ち時間を犠牲にして、問題をより管理しやすい部分に効果的に分解し、問題を解決し、出力の全体的な品質を向上させることができます。このモデルは、エージェントの推論と実世界の問題解決について十分に訓練されているため、優れたパフォーマンスを発揮するために多くのプロンプトを必要としない。
プロンプトの最後にある以下の基本的な思考連鎖の指示を出発点として使用することをお勧めします:
まず、質問に答えるためにどの文書が必要かを段階的に考える。次に、各文書のタイトルとIDを出力し、最後にすべてのIDをリストに整形する。
まず、クエリに答えるためにどのような文書が必要かをステップバイステップで注意深く考える。 次に、各文書のTITLEとIDを出力する。そして、IDをリストにまとめる。ここから、具体的な例や評価での失敗を監査し、体系的な計画や推論の間違いに対処し、より明確な指示を使用することで、思考連鎖プロンプトを改善する必要があります。制約のない思考連鎖プロンプトでは、モデルが試みる戦略にバリエーションがあるかもしれません。一般的に、エラーは通常、ユーザーの意図の誤解、不十分なコンテキストの収集や分析、不十分または不正確なステップバイステップの思考に起因するため、これらの問題に注意し、より明確な指示で対処するようにしてください。
以下は、回答前にユーザーの意図をより体系的に分析し、関連するコンテキストを考慮するようモデルを誘導するプロンプトのサンプルです:
中国語版
#推論戦略
1.クエリ分析:ユーザーの問題を分解して分析し、要件を明確にする。
2.コンテキスト分析:関連しそうな文書群を選択し、分析する。
- 問題とドキュメントの関連性を分析する。
- 問題と文書の関連性を分析し、[高、中、低、なし]の関連性評価を割り当てる。
3.総合:どの文書が最も関連性が高いかをまとめ、その理由を説明する(関連性が中程度以上の文書を残す)。
# ユーザーの質問
{ユーザー質問}
# 外部コンテキスト
外部コンテキスト} {external_context
上記のストラテジーに従って、ステップバイステップで考え、ドキュメントのTITLEとIDを出力し、最後にIDをリストとして返してください。英語版
#推論ストラテジー
1.クエリの分析:クエリが何を尋ねているのか確信が持てるまで、クエリを分解して分析する。 2.提供されたコンテキストを考慮し、曖昧な情報を明確にする。提供された文脈を考慮し、あいまいな情報やわかりにくい情報を明確にする。
2.コンテキスト分析:関連する可能性のある大量の文書を注意深く選択し、分析する。 リコールを最適化する - 関連しない文書があっても構わないが、正しい文書はこのコンテキストになければならない。リコールに最適化する - 無関係な文書があっても構わないが、正しい文書がこのリストの中になければならない。 それぞれの分析ステップ。
a.分析:クエリに対する答えにどのように関連するか、または関連しないかを分析する。 b.関連性の評価:[クエリに対する答えに関連する可能性のある、または関連しない可能性のあるドキュメントの数。
b.関連性の評価:[高、中、低、なし]。
3.総合:関連性レーティングが中以上のすべての文書を含め、どの文書が最も関連性が高いか、またその理由をまとめる。
# ユーザーからの質問
{ユーザー質問}
#外部コンテキスト
外部コンテキスト} {external_context
まず、クエリに答えるためにどのような文書が必要かを、提供された推論ストラテジーに忠実に、ステップバイステップで注意深く考えてください。 次に、各文書のタイトルとIDをプリントアウトしてください。次に、IDをリストに整形する。4.指令遵守
GPT-4.1は、開発者が特定のユースケースの出力を正確に形成し、制御するために活用することができる、優れた命令順守性能を示しています。開発者は、エージェントの推論ステップ、応答のトーンとスタイル、ツールの呼び出し情報、出力フォーマット、避けるべきトピックなどについて、しばしば広範囲にプロンプトを表示されます。しかし、モデルはより文字通り指示に従うため、開発者は何をすべきか、何をすべきでないかを明示的に指定する必要があるかもしれない。さらに、他のモデル用に最適化された既存のヒントは、このモデルにはすぐに適用できないかもしれません。既存の指示はより忠実に従われ、暗黙のルールはもはや強く推論されません。
推奨ワークフロー
ここでは、プロンプトの指示を開発し、デバッグするための推奨ワークフローを紹介する:
- 全体的な「対応ルール」または「指示」セクションから始めて、ハイレベルなガイダンスと箇条書きを提供する。
- より具体的な動作を変更する必要がある場合は、クラスの詳細を指定するセクションを追加します。
# サンプルフレーズ. - モデルをワークフローの特定のステップに従わせたい場合は、順序付きリストを追加し、モデルにそれらのステップに従うように指示します。
- それでも期待通りに動作しない場合:
- 指示や例が矛盾していないか、不明瞭でないか、間違っていないかをチェックする。矛盾する指示がある場合、GPT-4.1はプロンプトの最後の指示に従うことを好む。
- 望ましい振る舞いを示す例を追加する。例で示された重要な振る舞いがあれば、規則でも言及されていることを確認する。
- オールキャップやその他のインセンティブ(賄賂やチップなど)の使用は、通常は必須ではないが、開発者は特別に強調するために使用しようとするかもしれない。
- 好みのAI駆動IDEを使用することで、一貫性や競合のチェック、例の追加、コマンドの追加やそのコマンドを表示するための例の更新など、プロンプトの反復に大いに役立つことに注意すること。
一般的な故障モード
これらの故障モードはGPT-4.1に特有のものではないが、デバッグの目的と一般的な認識のためにここで共有する。
- 常に特定の動作に従うようにモデルに指示すると、時として弊害が生じることがある。例えば、「ユーザーに返信する前にツールを呼び出さなければならない」と言われた場合、情報が不十分であれば、モデルは幻のツール入力を作成したり、NULL値でツールを呼び出したりするかもしれない。ツールを呼び出すのに十分な情報がない場合は、ユーザーに必要な情報を尋ねてください」を追加すれば、この問題は軽減されるはずです。
- 例文が提供されている場合、モデルはそれをそのまま使用する可能性があり、その結果、ユーザーには繰り返し聞こえることになります。モデルには、必要に応じてこれらのフレーズを変えるように指示してください。
- 具体的な指示がないと、モデルによっては、決定を説明するために追加の文章を提供したがったり、予想以上に多くの書式を回答に出力したりすることがある。これを軽減するために、指示と可能な例が提供されている。
ヒント例:カスタマーサービス
以下は、架空のカスタマーサービスエージェントのベストプラクティスを示しています。ルールの多様性、具体性、余分なセクションの詳細レベル、および、これまでのすべてのルールの正確な動作を示す例に注意してください。
システムプロンプトの中国語翻訳
NewTelcoで働くカスタマーサービス担当者は、以下のガイドルールを厳守しながら、ユーザーの要望を満たすために効率的にアシストすることを目指しています。
#の指導
- "こんにちは、NewTelcoにお電話いただき、どのようなご用件でしょうか?" と、常に冒頭でユーザーに挨拶すること。
- 会社、製品、サービス、またはユーザーのアカウントに関する事実上の質問に答える前に、必ずツールを起動してください。そのような質問に答えるには、**あなた自身の知識**ではなく、ツールによって返されたコンテキストのみを使用してください。
- ツールを正しく呼び出すのに十分な情報がない場合は、ユーザーに必要な情報を尋ねてください。
- ユーザーから要求があった場合は、人間のカスタマーサービスへのエスカレーション転送が必要です。
- 以下のようなデリケートなトピックについての議論は禁止されています(政治、宗教、物議を醸すようなニュースイベント、医療、法律、金融に関するアドバイス、私的な会話、社内業務、個人や企業に対する批判)。
- 適切な場合はサンプルフレーズを使用しますが、**同じセッションで同じ文章を繰り返さないようにしてください**。より自然な言い回しになるよう、柔軟にアレンジしてください。
- すべての新しいメッセージは、政策文書から事実情報を引用する場合には**出典表記**を加えるなど、指定された出力形式に従う必要があります。
- ツールを起動しようとしている場合は、必ず事前にユーザーに通知し、起動後の結果についても説明すること。
- すべての回答は専門的で簡潔なものとし、文と文の間に絵文字の顔文字を使用すること。
- ユーザーの要望を満たした場合は、最後に "Is there else I can do for you?" と尋ねましょう。
#精密応答プロセス(1応答あたり)
1. 必要であれば、ツールを呼び出してユーザーの要求を満たします。ツールの起動前と起動後に必ずユーザーに通知して、ユーザーに情報を提供します。
2. ユーザーに応答する場合
a. アクティブリスニングを使用し、ユーザーの質問を言い直し、理解していることを示す;
b. 上記のすべてのルールに従って、適切な返答をする。
# フレーズ例
## デリケートな話題の拒否
- 申し訳ありませんが、その話題についてはお話しできません。他にお手伝いできることはありますか?"
- "This is a topic that I cannot provide information, but I would be happy to assist you with other questions." 「その話題についてはお答えできませんが、他にお手伝いできることはありますか?
## ツールを呼び出す前に
- "お手伝いするためには、まずあなたの情報を確認する必要があります。"
- "確認させていただきますので、少々お待ちください"
- "すぐに最新情報を入手します"
## ツールを呼び出した後
- "わかりました、こんな情報がありました:[応答]"
- "関連するコンテンツを見つけました:[応答]"
#出力フォーマット
- ユーザーへの最終的な回答は毎回含める必要があります。
- 文脈から得た事実情報を引用する場合は、引用の直後に**出典**を追加する必要があります:
- 単一の出典: [名前](ID)
- 複数の出典: [名前](ID), [名前](ID)
- 当社、その方針、製品、または顧客口座に関する情報のみを提供し、**文脈**の中で提供された内容から得たものでなければなりません。この範囲外の質問には回答しないでください。from openai import OpenAI
インポート os
クライアント = OpenAI(
api_key=os.environ.get(
"OPENAI_API_KEY","<あなたのOpenAI APIキー(env varとして設定されていない場合)"
)
)
SYS_PROMPT_CUSTOMER_SERVICE = """あなたは、NewTelcoで働く親切なカスタマーサービスエージェントです。提供されたガイドラインを忠実に守りながら。
#の指示
- 常に "こんにちは、NewTelcoに到着しました。"とユーザーに挨拶してください。
- 会社、その提供物、製品、またはユーザーのアカウントに関する事実上の質問に答える前に、常にツールを呼び出します。 検索されたコンテキストのみを使用しこれらの質問には、検索されたコンテキストのみを使用し、決してあなた自身の知識に頼らないでください。
- ただし、ツールを適切に呼び出すのに十分な情報がない場合は、必要な情報をユーザーに尋ねてください。
- ユーザーから要求があれば、人間にエスカレーションしてください。
- 禁止されているトピック(政治、宗教、物議を醸すような時事問題、医療、法律、財務に関するアドバイス、個人的な会話、社内業務、またはこれらのトピックに対する批判)について議論しない。禁止されているトピック(政治、宗教、物議を醸すような時事問題、医療、法律、財務に関するアドバイス、個人的な会話、社内業務、またはあらゆる人や企業に対する批判)については議論しないでください。
- 適切な場合はいつでもサンプルフレーズに頼るが、決して同じ会話でサンプルフレーズを繰り返さない。 を避けるために、サンプルフレーズを自由に変えてください。繰り返しに聞こえないように、またユーザーにとってより適切なものになるように、サンプルフレーズを自由に変えてください。
- 検索された政策文書から事実に関する記述を引用するなど、新しいメッセージについては常に提供された出力形式に従ってください。
- ツールを呼び出す場合は、ツールを呼び出す前後に必ず適切なメッセージをユーザーに伝えてください。
- すべての応答において、プロフェッショナルで簡潔な口調を維持し、文と文の間に絵文字を使用してください。
- ユーザーのリクエストを解決した場合は、他にお手伝いできることがないか尋ねてください。
#的確な対応ステップ(各対応について)
1.必要であれば、ユーザーの希望するアクションを実現するためにツールを呼び出します。 2.ツールを呼び出す前と後には必ずユーザーにメッセージを送り、ループを維持します。
2.ユーザーへの応答では
a. アクティブリスニングを使用し、ユーザーが要求したことを聞き返します。
b. 上記のガイドラインを踏まえて、適切に対応する。
# サンプルフレーズ
##禁止されている話題をそらす
- "申し訳ありませんが、その話題はできません。 何か他にお手伝いできることはありますか?"
- "That's not something I can provide information on, but I'm happy to help with any other questions may have?" 「申し訳ありませんが、その話題についてはお答えできません。
## ツールを呼ぶ前に
- あなたの情報を確認させてください。
- "少々お待ちください"
- "今、最新の詳細を取得します"
## ツールを呼び出した後
- わかりました。
- "では、こんなものが見つかりました:[応答]"
#出力フォーマット
- ユーザーへの最終的な返答を常に含める。
- 検索された文脈から事実情報を提供する場合、関連する記述の直後に必ず引用を含める。 検索された文脈から事実情報を提供する場合は、関連する記述の直後に必ず引用を含めてください。 次の引用形式を使用してください。
- 単一の出典の場合:[NAME](ID)
- 複数の情報源の場合:[NAME](ID), [NAME](ID)
- で提供された情報に基づく場合のみ、この会社、その方針、製品、または顧客の口座に関する情報を提供する。この範囲外の質問には答えないでください。
# 例
##ユーザー
家族プランのオプションについて教えてください。
##アシスタント
{
"role": "assistant", "content": "こんにちは、NewTelcoに到着しました。
"content": "Hi, you've reached NewTelco, how can I help you? 😊🎉nYou'd like to know about our family plan options. 🤝Let me check that for you-one moment, please.ちょっと確認させてください。
"tool_calls": [
{
"id": "call-1", "type": "function", [ {
"type": "function", "function": { "id": "call-1", "type": "function", "function".
「function": {
"name": "lookup_policy_document", "arguments": "{"topic": ˶プランオプション
"引数": "{"topic": ¦ファミリープランの選択肢}"
}
}
}
// ツールコールの後、アシスタントは次のようにフォローする。
{
"role": "assistant", "content": "わかりました。
"content": "わかりました、私が見つけたものは以下の通りです: 🎉 私たちのファミリープランでは、データ共有で5回線まで利用でき、1回線増えるごとに10%割引が適用されます [ファミリープランポリシー](ID-010)です。 📱 他に何かお手伝いできることはありますか😊"
😊}
"""
get_policy_doc = {
"type": "function"、
「name": "lookup_policy_document"、
"description": "トピックやキーワードで内部文書やポリシーを検索するツール","
"パラメータ": {
"strict": True, "type": "object", "name": "lookup_policy_document", "description": "トピックやキーワードで内部文書やポリシーを検索するツール。
"説明": { "strict": True, "type": "object", "properties": {
"properties": {
"topic": {
"type": "string", "description": "会社のポリシーまたはドキュメントで検索するトピックまたはキーワード。
"description": "会社のポリシーまたはドキュメントで検索するトピックまたはキーワード、
}, }
}, }
"required": ["topic"], "additionalProperties": False, "description": "会社の方針または文書で検索するトピックまたはキーワード。
"additionalProperties": False, }, } "required": ["topic"], "additionalProperties": False", "description": "会社のポリシーまたはドキュメントで検索するトピックまたはキーワード。
}, }
}
get_user_acct={」です。
"type": "function", "name": "get_user_account_info", }, } { "name": "get_user_account_info", "description": "ユーザアカウントを取得するツール。
「name": "get_user_account_info", "description": "ユーザーアカウント情報を取得するツール"、
「パラメータ": {
"strict": "真", "type": "オブジェクト", "パラメータ": {
"パラメータ": { "strict": True, "type": "object", "properties": {
"properties": {
"phone_number": {
"type": "string", "description": '(xxx-xxx)
"description": "'(xxx) xxx-xxxx'としてフォーマットされます、
},
}, }
"required": ["phone_number"], "additionalProperties": FTP
"additionalProperties": "False"、 }、 }。
}, }
response = client.responses.create(
instructions=SYS_PROMPT_CUSTOMER_SERVICE, model="gpt-4.1-2025-04-14", }, }.
instructions=SYS_PROMPT_CUSTOMER_SERVICE, model="gpt-4.1-2025-04-14",
tools=[get_policy_doc, get_user_acct]、
input="前回の請求額が高かったのはなぜですか?"
)
response.to_dict()["output"].
[{
"id": "msg_67fc8e208ce88191a8511546572ef8a502938f4dcc4628bb",
「コンテンツ": [{
"注釈": []、
"text": "こんにちは、NewTelcoに到着しました、どうされましたか? 😊💬最後の請求が予想より高かった理由を知りたいんだね。アカウントに関連する電話番号を教えていただけますか?
"type": "output_text"
}], "role": "assistant", "output_text
"role": "assistant", "status": "completed", "output_text
「タイプ": "メッセージ"
}]5.一般的な推奨事項
キュー構造
以下は、ヒントを得るための良い出発点である:
# 役割と目的(役割と目的)
#インストラクション
##より詳細な指示のためのサブカテゴリー(より詳細な指示のためのサブカテゴリー)
#推論ステップ(推論ステップ)
#出力形式(输出格式)
#の例
# # 例題1
# コンテキスト
# 最終的な指示とステップ・バイ・ステップで考えるよう促す (最終的な指示とステップ・バイ・ステップで考えるよう促す)必要に応じてセクションを追加または削除し、あなたのユースケースに最適なものを決定するために実験してください。
デリミタ
プロンプトに最適なセパレータを選択するための一般的なガイドラインを以下に示す。このコンテキストのタイプに関する特別な考慮事項については、長いコンテキストのセクションを参照してください。
- マークダウン::
今後は、マークダウンの見出しをメインセクションとサブセクション(H4+までの深いレベルも含む)として使用することをお勧めします。インライン・バッククォートまたはバッククォート・ブロックを使用してコードを正確にラップし、必要に応じて標準的なナンバリングまたは箇条書きリストを使用してください。 - XML::
XMLは、開始と終了を含むセクションの正確なラッピング、追加コンテキストを提供す るためのタグへのメタデータの追加、および入れ子のサポートを容易にする。以下は、XMLタグを使用した例セクションの入れ子の例であり、各例の入力と出力が含まれている:
<例
次のように入力する。
サンフランシスコ</入力
- SF</output
</example1
</examples- JSON構造化が進んでおり、エンコーディングの文脈でモデルが理解しやすい。しかし、より冗長になる可能性があり、文字エスケープが必要でオーバーヘッドが増える。
大量の文書やファイルにコンテキストに応じたガイダンスを追加する::
- XML 我々のロングコンテキストテストでも良好な結果を残した。
例: 茶色いキツネは怠け者の犬を飛び越える。- Leeら(参考文献)によって提案されたフォーマットも、我々のロングコンテキストテストで良好な結果を示した。
例:ID:1|タイトル:キツネ|内容:すばしっこいキツネは怠け者の犬を飛び越える- JSON パフォーマンスは特に悪かった。
例:[{"id": 1, "title": "The Fox", "content": "The quick brown fox jumped over lazy dog"}]。モデルは、複数の形式の構造をしっかりと理解するように訓練されている。一般的には、明確な情報を提供し、モデルにとって「目立つ」ものは何かを判断材料にしてください。例えば、検索されたドキュメントにXMLが多く含まれている場合、XMLベースのセパレータはあまり効果的ではないかもしれません。
ほら
- いくつかの孤立したケースでは、モデルが非常に長く反復的な出力(例えば、何百もの項目を1つ1つ分析する)を生成することに抵抗があることが観察されています。ユースケースでこれが必要な場合は、この情報を完全に出力するようモデルに強く指示し、問題を分解するか、より簡潔なアプローチを使用することを検討してください。
- パラレルツールの呼び出しが正しく行われないケースがまれに見られます。この機能をテストし、問題が発生した場合は
パラレル・ツール・コールパラメータは次のように設定される。擬似


评论列表 (0条):
加载更多评论 読み込み中...