より良い結果を得るためのプロンプトエンジニアリング戦略（その３）【複雑なタスクをより単純なサブタスクに分割する】

戦術: 意図分類を使用して、ユーザークエリに最も関連性の高い指示を特定する

さまざまなケースを処理するために多数の独立した命令セットが必要なタスクの場合、最初にクエリの種類を分類し、その分類を使用して必要な命令を決定すると便利です。これは、固定カテゴリを定義し、特定のカテゴリのタスクの処理に関連する命令をハードコーディングすることで実現できます。このプロセスを再帰的に適用して、タスクを一連のステージに分解することもできます。このアプローチの利点は、各クエリにタスクの次のステージを実行するために必要な命令のみが含まれるため、単一のクエリを使用してタスク全体を実行する場合と比較してエラー率が低くなることです。また、プロンプトが大きいほど実行コストが高くなるため、コストも低くなります (価格情報を参照)。

たとえば、顧客サービス アプリケーションの場合、クエリは次のように分類できるとします。

You will be provided with customer service queries. Classify each query into a primary category and a secondary category. Provide your output in json format with the keys: primary and secondary.

Primary categories: Billing, Technical Support, Account Management, or General Inquiry.

Billing secondary categories:
– Unsubscribe or upgrade
– Add a payment method
– Explanation for charge
– Dispute a charge

Technical Support secondary categories:
– Troubleshooting – Device compatibility
– Software updates

Account Management secondary categories:
– Password reset
– Update personal information
– Close account
– Account security

General Inquiry secondary categories:
– Product information
– Pricing
– Feedback
– Speak to a human

I need to get my internet working again.

{
“primary”: “Technical Support”,
“secondary”: “Troubleshooting”
}

モデルは、会話の状態が変わったときにそれを示す特別な文字列を出力するように指示されていることに注意してください。これにより、システムを状態マシンに変えることができ、状態によってどの命令が挿入されるかが決定されます。状態、その状態で関連する命令、およびオプションでその状態から許可される状態遷移を追跡することで、構造化されていないアプローチでは実現が難しいユーザー エクスペリエンスの周囲にガードレールを配置できます。

モデルのコンテキストの長さは固定されているため、会話全体がコンテキスト ウィンドウに含まれるユーザーとアシスタント間の対話は無期限に継続することはできません。

この問題にはさまざまな回避策がありますが、その 1 つは、会話の以前のターンを要約することです。入力のサイズが事前に設定されたしきい値の長さに達すると、会話の一部を要約するクエリがトリガーされ、以前の会話の要約がシステム メッセージの一部として含められる可能性があります。または、会話全体を通じて、以前の会話をバックグラウンドで非同期的に要約することもできます。