How to Prompt a Conversational AI System

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.

Developers make a common mistake when prompting LLMs for conversational AI: recycling the same playbook that was used to train human employees. This strategy, despite sounding straightforward, is rarely fruitful. LLMs make different assumptions than typical humans, and their default tone and scope aren’t conducive to verbal interactions.

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

The Old System

Prior to LLMs, conversational AI systems leveraged sprawling logic trees that requests would triage through based on verbal inputs. This setup was popular among customer service numbers (e.g., airline hotlines) and payment systems (e.g., credit card phone services).

These older systems were sluggish, felt robot-like, and could only permit very limited human inputs. There’s a fair chance you experienced this yourself, bluntly yelling “YES” into a phone to answer a prompt. This poor experience led most users to attempt to “beat the system” to force a conversation with a live human agent.

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.

The Default Gaps

If LLMs are simply trained on a handbook originally designed for humans, they’ll have mediocre success due to a few core gaps. Understanding these gaps will help you design prompts to address them:

Tone Mismatch

LLMs are trained via reinforcement learning, where human feedback incentivizes LLMs to return structured feedback. Specifically, LLM responses tend to be verbose and filled with bullets, call-out blocks, and headlines.

However, in the context of conversational AI, LLMs need to emulate the concise and flattened nature of verbal interactions.

Assumption Gaps

LLMs have a tendency to fill any unknowns with inferred knowledge instead of asking questions. This can lead them to make incorrect assumptions that’ll mislead users—or lead to costly mistakes (e.g., promised refunds). Later, we’ll see how we can use a knowledge base and guardrails to better ground the LLMs from making incorrect promises and executing disallowed actions.

Latency

LLMs can programmatically invoke function calls, gathering and writing data on behalf of humans. While this is generally one of the biggest advantages of LLMs, it also means that previous training instructions, which allowed call agents to “buy time” while performing tasks, are no longer needed. However, function calls aren’t instantaneous either, meaning that LLMs need to accurately forewarn the user whenever a delay is expected (e.g., “give me a moment to examine your case”).

Configurations

Personality

LLMs are fairly successful at augmenting tone to match a style. An LLM could be configured to sound friendly, humorous, concise, formal, or a combination of styles. This is an important input when prompting an LLM.

For example, developers of a customer service conversational AI application designed to support disgruntled airline customers might use a prompt such as:

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が特定のエンドポイントにのみアクセスする必要がある場合は、他のエンドポイントにアクセスできないようにします。
• 人間の介入によるエスカレーション: 高リスクの行動を取る必要がある場合は、「マネージャーの承認」が必要な人間の介入ワークフローを検討します。

検証と確認

ツールを使用してアクションを実行する会話型AIシステムを作成する際には、ユーザーから正しい情報を収集していることを確認するために、検証と確認のプロセスを組み込むことが役立ちます。今日、人間のエージェントと話すとき、彼らは聞いた重要な情報を繰り返して、正しく聞いたことを確認し、顧客が言い間違えなかったことを確認します。LLMも同様のエラーチェックのレベルから利益を得ることができます。

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

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

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

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

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

顧客: 317-798-97289

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

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

締めくくりの考え

会話型AIシステムにプロンプトを成功させるには、適切な設定とガードレールをバランスよく組み合わせて、人間と話すような体験を効率的に再現することが重要です。このプロセスは、古いトレーニング資料を使ってLLMにプロンプトを与えるほど簡単ではありません。むしろ、LLMは予測可能で効果的な結果を生み出すために、専門的な構造と戦略が必要なツールです。