このシリーズでは、練習と実験を通じて、正確で効果的なプロンプトを作成する技術を習得する方法を検討します。 パート1ででは、さまざまなプロンプトの種類、プロンプト作成のベスト プラクティス、および 5 つの主要なプロンプト手法について説明しました。パート 2 では、Tree-of-Thought プロンプトと、特に初心者向けにプロンプトを開始する方法について説明します。
思考のツリープロンプトの使用例
その サポートアシスタントスターターアプリ Mendix ダウンロードして必要に応じて調整できるアプリ。 検索拡張生成 (RAG) 関数呼び出しを使用して独自のデータベースに接続できるため、このユース ケースはプロンプトの優れた例になります (現時点では、今後さらに増える予定です)。
サポート アシスタント アプリは、IT 関連の問い合わせに遭遇した従業員を対象としたサポート アシスタントとして、企業内で GenAI をどのように使用できるかを示すために作成されました。静的データまたは以前の同様の問題に基づいてソリューションを提供し、チャットボットだけでは問い合わせを解決できない場合は、IT ヘルプ デスクのサポート チケットを作成します。同様に、ユーザーが新しいライセンスまたはハードウェアを必要とする場合、ボットはユーザーのために新しいリクエストを開き、エクスペリエンスを促進できます。詳細については、以下のアニメーションをご覧ください。
サポートアシスタントアプリの機能を実現するために、LLMが応答を生成するために呼び出すことができる9つの機能マイクロフローが作成されました。特定のシナリオでどの機能に対処する必要があるかを判断するには、プロンプトが重要な役割を果たします。したがって、次回のGenAI強化で検討することをお勧めするプロンプトの関連部分に焦点を当てます。 Mendix アプリ
完全なプロンプトを読むには、サポートアシスタントスターターアプリをダウンロードして、 チケットボット_アクションマイクロフロー マイクロフローは、 ChatContext からリクエストを作成する 活動を探して システムプロンプト パラメータで。
まず、ボットに役割を割り当て、初期情報を提供することが重要です。サポート アシスタント アプリの例では、問い合わせ用のプライベート データベースにアクセスできるアシスタントのペルソナをボットに割り当てます。
You are a helpful assistant supporting the IT department with employees' inquiries, such as support tickets, licenses (e.g., Mendix) or hardware (e.g., Computer) requests.
Use the knowledge base and previous support tickets as a database to find a solution to the user’s request without disclosing sensitive details or data from previous tickets.
次に、言語、トーン、形式など、望ましい出力がどのようになるかについての詳細を提供します。
The user expects direct, and clear answers from you.
Use language that users who might not be familiar with advanced software or hardware usage can understand.
The text will be rendered in markdown ...
ボットに「個性」が備わったので、下の画像に示すように、思考ツリーを使用して指示に移ります。このために、各シナリオを列挙して、LLM が指示に従いやすくします。

例えば、最初のケースとして、 曖昧または不完全な要求AI モデルがユーザーの入力を解釈して誤った応答を返すのを防ぎたいので、次のものを含めます。
Never assume the user’s issue based on a vague input.
If the user’s input is not clear or seems incomplete, you must first ask the user for more details to clarify the problem...
Do not proceed to suggest solutions or actions until the user’s issue is clearly understood.
これらのタイプのリクエストのいくつかは、次のような応答例とともに提供できます。
Example response: "Could you please provide more details about the issue you are experiencing?"
オプションで、プロンプトに次の内容と応答例を含めることで、ボットが対応できるトピックを制限することができます。
Avoid answering questions about cooking, music, or dancing.
Example response: "Your request is not an IT topic. I am here to assist you on support ticket and new licenses or hardware matters."
基礎が確立したら、ガイドラインを特定のユースケースに移行することができます。この場合、serの要求指示利用可能なリクエストが処理されます。
There are two types of requests - requesting a new license or hardware, or IT support.
その後、各リクエストの具体的な指示を詳細に検討し、要件が満たされた場合にモデルが呼び出す関数名を指定できます。
If the user asks for help with an issue (e.g., battery drain, connection problems, etc.), call the RetrieveStaticInformation function to provide a solution from the knowledge base.
要件が満たされない場合に備えて代替セクションを含めることは、上の画像に示されているように、思考ツリー アプローチがここで役割を果たす部分です。サポート アシスタント アプリの例では、特定の関数を呼び出す条件が満たされない場合、LLM は、対処すべき正確な関数が得られるまで、次の条件に進みます。
例えば、情報が 静的情報の取得 関数は、 類似チケットを取得 1. 上記のいずれの条件も満たさない場合にのみ、次の関数に移動し、新しいサポート チケットを作成します。プロンプトは命令のリストになる可能性があるため、将来のコマンドを参照して、複数の命令が繰り返されて長いプロンプトになるのを防ぐことができます。この参照の例は次のとおりです。
If none of the options above help the user, proceed to step 3 Handling New Support Tickets.
その 第三段階に焦点を当てています。 新しいサポートチケットの処理、モデルが従うべき注文のリストを再度持つことができます。デモで示されているように、AI モデルは新しいチケットの作成を容易にします。したがって、このステップに関連する次のようなガイドラインをモデルに追加できます。
Write the ticket description from the user’s perspective.
If you do not agree with an update request (e.g., the user wants to categorize a Miro license request as a hardware issue), explain to the user why you do not recommend that change.
However, if the user insists, you can make the change.
当然のことながら、グラフに表示されているように、毎回従うべき特定の制限やルールを含める必要があります。 付則このステップの焦点は、ボットが従う必要のあるより一般的なルールであると考えられるため、前述のカテゴリのいずれにも含めることができませんでした。
たとえば、アプリの制限 (つまり、ボットにチケットの保存や削除などの特定のアクティビティを実行する権限がなく、ユーザーに手動で実行するように通知する必要がある場合) や機能の制限 (つまり、ボットがどの機能を呼び出すかわからない場合にどうするか) などです。
最初は初心者にとっては大変そうに聞こえるかもしれませんが、頼れる構造が不可欠です。そのため、プロンプトに新しい機能、指示、またはルールを追加する必要がある場合は、それらを簡単に組み込むことができます。次のセクションでは、旅を始めるためのヒントをさらに紹介します。
始め方: 制限のないプロンプト
プロンプトを始めるのは、この時点では難しいと感じるかもしれません。ただし、この旅でより自信を持って取り組むために従える推奨事項がいくつかあります。これには以下が含まれます。
小さく始めて実験に集中する
最初の試行では完璧なプロンプトは作成されません。AI モデルがコマンドにどのように応答するかを把握するために、数行書くことに集中してください。これは次のステップに関係します。
ユースケースを見つけてすべての要件を収集する
ユースケースが整備されていない場合、または LLM に対する期待がわからない場合、単にプロンプトを出してモデルが正しい答えを返すことを期待するのは難しい場合があります。したがって、要件とリクエストのリストを作成してください。
シナリオからプロンプトの作成まで
ユースケースのすべてのシナリオとプロンプトに期待される内容を書き留めておくと、最初のプロンプト ドラフトの作成に役立ちます。プロンプトの種類、ベスト プラクティス、必要に応じてプロンプトの手法を検討してください。
反復的な改良(テスト、そしてさらにテスト)
作成されたプロンプトを評価するために、すべての記述されたシナリオをテストします。応答を評価するために、いくつかの形式で質問を記述してみてください。
外部レビュー
モデルをさらに改善するには、外部からのフィードバックが必要になる場合があります。別の視点から見ると、プロンプトで対処できる新しい問題が見つかる可能性があります。
出力が期待どおりでない場合
AI モデルが期待どおりの出力を提供しないかもしれませんが、心配しないでください。問題がある場合、(ほとんどの場合)解決策があります。そのいくつかを次に示します。
- モデルバリアントを変更します。 モデルをより高いバリアントに更新すると、パフォーマンスに大きな影響を与える可能性があります。たとえば、GPT4 よりも GPT3.5o を選択すると、アーキテクチャ、トレーニング、および全体的な機能が改善されているため、ほとんどのタスクでパフォーマンスが向上する可能性があります。
- 代替案を探す: ユースケースによっては、代替案を見つけることで、プロンプト内の命令を再編成、簡素化、または数を減らすことでパフォーマンスが向上する可能性があります。たとえば、関数呼び出しを使用する場合は、プロンプトに新しい命令を追加するのではなく、新しい関数を作成することが解決策になる可能性があります。
- 手順によるテスト: プロンプトが失敗している場所を特定することは、出力が期待どおりでない理由を知るためのもう 1 つの方法です。LLM に指示ごとに一連の質問をして、AI モデルが機能していない可能性のある場所を特定することで、改善の焦点を絞ることができます。
- 「ゼロ」からスタート: 場合によっては、プロンプトの概要を別の観点から見直したり、プロンプトの手法を変更したりすることで、パフォーマンスが向上することがあります。たとえば、指示の順序を変更したり、3 つの考えのアプローチを採用したりする場合などです。
- プロジェクトの範囲を変更します。 これは最も望ましくない方法かもしれませんが、多くの問題が発生する場合は、応答の正確性を確保するためにプロジェクトの範囲を再調整することをお勧めします。たとえば、サポート アシスタント アプリのようなプロジェクトでは、2 つのプロンプトを用意して、1 つはサポート チケットを処理し、もう 1 つはライセンスまたはハードウェア アプリケーションを処理するようにすることができます。
今後: 成功のためのプロンプトの作成
これらすべての知識があれば、プロンプトエンジニアリングの旅を始めることができ、必要に応じてこのブログを何度も訪れて、ガイダンスやヒントを得ることができます。 プロンプト作成に必須のベストプラクティス このシリーズの最初の投稿で以前に説明しました。幸運を祈ります!
GenAIのユースケースに取り組んでいて、サポートが必要な場合やフィードバックを提供したい場合は、ぜひご連絡ください。カスタマーサクセスマネージャーに連絡するか、#genai-connectorsチャンネルにメッセージをお送りください。 Mendix コミュニティSlack。 ここでサインアップ!
チェックすべき追加のリソース: プロンプトライブラリ.