会話型AIシステムのプロンプト方法

Today, the LLM has emerged as the beating heart of conversational AI systems. Specifically, LLMs enable conversational AI—originally built around sprawling phone trees—to feature dynamic functionality and provide human-like experiences. However, LLMs aren’t a silver bullet upgrade; they require specialized prompting as they aren’t fine-tuned to human speech by default.

デベロッパーは、会話型AIのためにLLMをプロンプトする際に、よくある間違いを犯します。それは、人間の従業員を訓練するために使用されたプレイブックを再利用することです。この戦略は一見簡単そうに思えますが、ほとんど成果を上げません。LLMは通常の人間とは異なる仮定をし、デフォルトのトーンや範囲は口頭でのやり取りに適していません。

Today, we’ll uncover what we know about how to prompt LLMs to build successful conversational AI systems.

旧システム

LLM以前は、会話型AIシステムは、音声入力に基づいてリクエストを振り分ける広範なロジックツリーを活用していました。このセットアップは、カスタマーサービス番号（例：航空会社のホットライン）や支払いシステム（例：クレジットカードの電話サービス）で人気がありました。

これらの古いシステムは遅く、ロボットのように感じられ、非常に限られた人間の入力しか許可しませんでした。多くのユーザーが「YES」と電話に叫んでプロンプトに答えた経験があるでしょう。この悪い体験により、多くのユーザーはシステムを「打ち負かして」生の人間のエージェントと会話しようとしました。

However, there was an advantage to these phone trees—they were contained. There were only so many paths a conversation could take, and developers could easily implement guardrails to disregard disallowed inputs. This constraint underpins the pros and cons of LLMs: They expand dramatically past the limited nature of phone trees, but they are also unpredictable, opening a Pandora’s box of pitfalls—such as making impossible promises, getting angry with customers, or breaching sensitive data.

デフォルトのギャップ

LLMが元々人間向けに設計されたハンドブックで訓練されると、いくつかの基本的なギャップのために成功は中程度にとどまります。これらのギャップを理解することで、それに対処するプロンプトを設計するのに役立ちます。

トーンの不一致

LLMは強化学習を通じて訓練され、人間のフィードバックがLLMに構造化されたフィードバックを返すように促します。具体的には、LLMの応答は冗長で、箇条書きやコールアウトブロック、見出しが多く含まれる傾向があります。

しかし、会話型AIの文脈では、LLMは口頭でのやり取りの簡潔で平坦な性質を模倣する必要があります。

仮定のギャップ

LLMは、未知の情報を質問する代わりに推測された知識で埋める傾向があります。これにより、ユーザーを誤解させたり、コストのかかるミス（例：返金の約束）を招く可能性があります。後で、知識ベースとガードレールを使用して、LLMが誤った約束をしたり、許可されていない行動を実行したりしないようにする方法を見ていきます。

遅延

LLMはプログラム的に関数呼び出しを行い、人間に代わってデータを収集し書き込むことができます。これは一般的にLLMの最大の利点の一つですが、以前のトレーニング指示で、コールエージェントがタスクを実行しながら「時間を稼ぐ」ことを許可していたため、もはや必要ありません。しかし、関数呼び出しも瞬時ではないため、遅延が予想される場合にはユーザーに正確に警告する必要があります（例：「ケースを確認するので少々お待ちください」）。

設定

パーソナリティ

LLMは、スタイルに合わせてトーンを調整するのにかなり成功しています。LLMは、フレンドリー、ユーモラス、簡潔、フォーマル、またはスタイルの組み合わせで聞こえるように設定できます。これは、LLMにプロンプトを与える際の重要な入力です。

例えば、不満を持つ航空会社の顧客をサポートするために設計されたカスタマーサービス会話型AIアプリケーションのデベロッパーは、次のようなプロンプトを使用するかもしれません。

You are a friendly customer service agent who speaks in concise, clear, empathetic sentences.

• Add section embedding three example ElevenLabs apps

フォーマット

LLMはどのように応答するかについて明確な指示を受ける必要があります。余分なテキストを含まないようにするために、ユーザーに渡される応答をカプセル化する構造を提供する必要があります。

例えば、LLMは次のようにプロンプトされるかもしれません。

Respond exclusively with the string that should be read aloud to the user

このスキャフォルディングは、LLMが音声で読み上げるために設計された応答を提供するように促します。

しかし、LLMは時々、書かれた内容と直感的に異ならないものに躓くことがあります。一般的な例は数字です。LLMは郵便番号を10023のように出力し、テキスト読み上げモデルが「一万二十三」と言ってしまうことがあります。代わりに、LLMは数字を個別に言うように明示的にプロンプトされるべきです。例えば、「郵便番号は一、ゼロ、ゼロ、二、三です」といった具合です。

温度

温度は会話型AIのためにLLMを設定する際の重要なパラメータです。低い温度は、タスク指向の会話に理想的な、より集中した決定論的な応答を生成し、高い温度はより創造的で多様な応答を生成します。

低い温度は、一貫した応答を好む会話型AIシステムに理想的です（例：返金のためのカスタマーサービスライン）。一方、より魅力的でリアルな顧客への感触を提供したいシステム（例：デジタルコーチ）には、高い温度が適しています。

Low Temperature: Thank you for calling ElevenLabs support. How can I help you?

高温度: こんにちは！ElevenLabsサポートにようこそ。技術的な問題を解決する準備はできていますか？何かお困りですか？

知識ベース

より大きな知識のリソースにアクセスする会話型AIシステムには、プロンプトの長さを最小限に抑えるために知識ベースを活用するべきです。実際には、これは通常、ベクターデータベース（PineconeやElasticsearchなど）やLLMプロバイダーの直接的な知識ストアを通じて行われます。

一般的に、知識ベースはLLMの応答を事実に基づいた承認済みの情報に基づかせるために不可欠です。会話型AIシステムを構築する際には、製品、サービス、ポリシー、手順に関する正確で最新の情報を含む包括的な知識ベースをLLMに提供するべきです。これにより、LLMが幻覚を見たり情報を作り上げたりすることを防ぎ、会話全体で一貫した信頼性のある応答を促進します。

プロセス

LLMはユーザーに代わって関数を呼び出すことが多いため、必要な入力を明確に知る必要があります。例えば、LLMの仕事がユーザーのヘアカットの予約を手伝うことである場合、次の情報を確実に持っている必要があります。

1. ユーザーの名前
2. 希望する日時
3. ユーザーの住所
4. ユーザーのサービスの好み

単純な実装では、LLMが会話の一回のターンで全ての情報を求める結果になるかもしれません。これはテキストとしては問題ありませんが、会話では圧倒的になる可能性があります。

サポートエージェント: お名前、住所、希望する日時、希望するサービスを教えていただけますか？

顧客: 私の名前はマシューで、水曜日の午後ならいつでも大丈夫です。他に何を聞かれましたか？

情報は通常、会話を通じて段階的に収集されるため、LLMはこの情報を少しずつ取得するように促されるべきです。その結果、より会話的な体験が得られます。

サポートエージェント: お名前を教えていただけますか？

顧客: 私の名前はマシュー・プレガセンです。

サポートエージェント: ありがとうございます、マシューさん。いつ予約を取りたいですか？

顧客: 水曜日の午後ならいつでも大丈夫です。

サポートエージェント: 了解しました。最寄りの場所を見つけるために住所を教えていただけますか？

顧客: 555ウェストメインストリート

サポートエージェント: 完璧です。どのサービスをお探しですか？

顧客: ヘアカットを希望していますが、ひげも整えていただけると嬉しいです！

ガードレール

権限

分散システムを構築する際には、サーバーがいつかクラッシュするという仮定をします。同様に、AIシステムを構築する際には、LLMがいつか間違いを犯すと仮定するべきです。その間違いの影響を最小限に抑えるために、これらのシステムには必要最低限の権限を与えるべきです。以下はその方法の例です。

• 読み取り/書き込み権限を正しく設定する: LLMがデータソースから情報を読み取るだけでよい場合は、読み取り専用のエンドポイントを与えるようにします。
• APIエンドポイントへのアクセスを制限する: LLMが特定のエンドポイントにのみアクセスする必要がある場合は、他のエンドポイントにアクセスできないようにします。
• 人間の介入によるエスカレーション: 高リスクの行動を取る必要がある場合は、「マネージャーの承認」が必要な人間の介入ワークフローを検討します。

検証と確認

会話を作成する際に

サポートエージェント: 了解しました。最寄りの場所を見つけるために住所を教えていただけますか？

顧客: 555ウェストメインストリート

サポートエージェント: 555ウェストメインストリートと聞きましたが、何か聞き漏らしましたか？

検証のためには、顧客から受け取った情報をその情報の典型的な構造と照らし合わせて確認する必要があります。電話番号は正しい桁数ですか？顧客が提供した年齢は妥当な範囲内ですか？顧客は有効な住所を提供しましたか？

サポートエージェント: 連絡先番号を教えていただけますか？

顧客: 317-798-97289

サポートエージェント: 聞き間違えたかもしれません。11桁聞こえました。もう一度繰り返していただけますか？

使用ケースに応じて、受け取ったすべての情報を検証するか、検証に失敗した情報のみを検証するかを決定できます。また、情報が入ってくるたびに検証するか、最後にすべてを検証するかを選択できます。

締めくくりの考え

会話型