
Revolut selects ElevenLabs Agents to bolster customer support
Reducing time to ticket resolution by 8x with multilingual conversational agents.
今日、LLMは会話型AIシステムの中心として登場しました。特に、LLMは会話型AI — 元々は複雑な電話ツリーを中心に構築されていましたが — 動的な機能を備え、人間のような体験を提供します。しかし、LLMは万能な解決策ではなく、デフォルトで人間の言葉に最適化されていないため、専門的なプロンプトが必要です。
デベロッパーは、会話型AIのためにLLMをプロンプトする際に、よくある間違いを犯します。それは、人間の従業員を訓練するために使用された同じ手法を再利用することです。この戦略は一見簡単そうに思えますが、ほとんどの場合うまくいきません。LLMは典型的な人間とは異なる仮定をし、デフォルトのトーンや範囲は口頭でのやり取りに適していません。
今日は、LLMをプロンプトして成功する会話型AIシステムを構築する方法について知っていることを明らかにします。このトピックに関するより包括的で技術的なガイドは、ElevenLabsデベロッパードキュメントで読むことができます。
LLM以前は、会話型AIシステムは、音声入力に基づいてリクエストを振り分ける広範なロジックツリーを活用していました。このセットアップは、カスタマーサービス番号(例:航空会社のホットライン)や支払いシステム(例:クレジットカードの電話サービス)で人気がありました。
これらの古いシステムは遅く、ロボットのように感じられ、非常に限られた人間の入力しか許可しませんでした。多くのユーザーがこの経験をしたことがあるでしょう。電話で「YES」と叫んでプロンプトに答えることもありました。この悪い経験により、多くのユーザーはシステムを「打ち負かし」、生の人間のエージェントとの会話を強制しようとしました。
しかし、これらの電話ツリーには利点がありました。それは制約されていたことです。会話が取ることができるパスは限られており、デベロッパーは許可されていない入力を無視するためのガードレールを簡単に実装できました。この制約は、LLMの長所と短所の基盤となっています。LLMは電話ツリーの限られた性質を大幅に超えて拡張しますが、予測不可能であり、不可能な約束をしたり、顧客に怒ったり、機密データを漏らしたりするなどの落とし穴を開くパンドラの箱を開けることになります。
LLMが元々人間向けに設計されたハンドブックで単に訓練されると、いくつかの基本的なギャップのために成功は中程度になります。これらのギャップを理解することで、それらに対処するプロンプトを設計するのに役立ちます。
LLMは強化学習を通じて訓練され、人間のフィードバックがLLMに構造化されたフィードバックを返すように促します。具体的には、LLMの応答は冗長で、箇条書きやコールアウトブロック、見出しが多く含まれる傾向があります。
しかし、会話型AIの文脈では、LLMは口頭でのやり取りの簡潔で平坦な性質を模倣する必要があります。
LLMは、未知の情報を質問する代わりに推測された知識で埋める傾向があります。これにより、ユーザーを誤解させる誤った仮定をすることがあり、(例:返金を約束する)高額なミスにつながることがあります。後で、知識ベースとガードレールを使用して、LLMが誤った約束をしたり、許可されていない行動を実行したりしないようにする方法を見ていきます。
LLMはプログラム的に関数呼び出しを行い、人間に代わってデータを収集し書き込むことができます。これは一般的にLLMの最大の利点の一つですが、以前の訓練指示が不要になったことも意味します。しかし、関数呼び出しも瞬時ではないため、遅延が予想される場合にはユーザーに正確に警告する必要があります(例:「ケースを調べるのに少しお待ちください」)。
LLMはスタイルに合わせてトーンを調整するのにかなり成功しています。LLMは、フレンドリー、ユーモラス、簡潔、フォーマル、またはスタイルの組み合わせで聞こえるように設定できます。これはLLMをプロンプトする際の重要な入力です。
例えば、不満を持つ航空会社の顧客をサポートするために設計されたカスタマーサービス会話型AIアプリケーションのデベロッパーは、次のようなプロンプトを使用するかもしれません。
Nicole
LLMはどのように応答するかについて明確な指示を受ける必要があります。追加の余分なテキストを含まないようにするために、LLMにはユーザーに渡される応答をカプセル化する構造を提供する必要があります。
例えば、LLMは次のようにプロンプトされるかもしれません。
このスキャフォルディングは、LLMが音声で読み上げるように設計された応答を提供することを促します。
しかし、LLMは時々、書かれた内容と直感的に異ならないものに躓くことがあります。一般的な例は数字です。LLMは10023のような郵便番号を印刷するかもしれませんが、テキスト読み上げモデルは「一万二十三」と言うことになります。代わりに、LLMは数字を個別に言うように明示的にプロンプトされるべきであり、数字が何を意味するのかを示すべきです。例:「郵便番号は一、ゼロ、ゼロ、二、三です。」
温度は、会話型AIのためにLLMを設定する際の重要なパラメータです。低い温度は、タスク指向の会話に理想的な、より集中した決定論的な応答を生成し、高い温度は、より創造的で多様な応答を生成します。
低温度は、一貫した応答を好む会話型AIシステムに理想的です(例:返金のためのカスタマーサービスライン)。一方、より魅力的でリアルな感覚を顧客に提供したいシステム(例:デジタルコーチ)には、高温度が適しています。
より大きな知識のリザーバーにアクセスする会話型AIシステムでは、プロンプトの長さを最小限に抑えるために知識ベースを活用する必要があります。実際には、これは通常、ベクターデータベース(PineconeやElasticsearchなど)やLLMプロバイダーの直接の知識ストアを通じて実現されます。
一般的に言えば、知識ベースはLLMの応答を事実に基づいた承認済みの情報に基づかせるために不可欠です。会話型AIシステムを構築する際には、製品、サービス、ポリシー、手順に関する正確で最新の情報を含む包括的な知識ベースをLLMに提供する必要があります。これにより、LLMが幻覚を見たり情報を作り上げたりすることを防ぎ、会話全体で一貫性と信頼性のある応答を促進します。
LLMはしばしばユーザーに代わって関数を呼び出すため、どの入力が明示的に必要かを知る必要もあります。例えば、LLMの仕事がユーザーのヘアカットの予約を手伝うことである場合、次の情報を確保する必要があります。
単純な実装では、LLMが会話の一回のターンで全ての情報を求める結果になるかもしれません。これはテキストとしては問題ありませんが、会話では圧倒されることがあります。
情報は通常、会話を通じて段階的に収集されるため、LLMはこの情報を少しずつ取得するように促される必要があります。その結果、より会話的な体験が得られます。
分散システムを構築する際には、サーバーがいつかクラッシュすることを前提とします。同様に、AIシステムを構築する際には、LLMがいつかミスをすることを前提とするべきです。そのミスの影響範囲を最小限に抑えるために、これらのシステムには必要最低限の権限を与えるべきです。以下はその方法の例です。
ツールを使用してアクションを実行する会話型AI音声エージェントシステムを作成する際には、ユーザーから正しい情報を収集していることを確認するために、検証と確認のプロセスを組み込むことが役立ちます。今日、人間のエージェントと話すとき、彼らはあなたが提供した重要な情報を繰り返して、正しく聞き取ったかどうかを確認し、顧客が言い間違えなかったことを確認します。LLMも同様のエラーチェックのレベルから利益を得ることができます。
検証のために、顧客から受け取った情報はその情報の典型的な構造と照らし合わせて確認する必要があります。電話番号は正しい桁数ですか?顧客が提供した年齢は妥当な範囲内ですか?顧客は有効な住所を提供しましたか?
使用ケースに応じて、受け取ったすべての情報を確認するか、検証に失敗した情報のみを確認することができます。また、情報が入ってくるたびに確認するか、最後にすべてを確認するかを決定できます。
会話型AIエージェントシステムを成功裏にプロンプトするには、適切な設定とガードレールをバランスよく組み合わせて、人間と話すような体験を効率的に再現することが重要です。このプロセスは、古いトレーニング資料を使用してLLMをプロンプトするほど簡単ではありません。むしろ、LLMは予測可能で効果的な結果を生み出すために、専門的な構造と戦略を必要とするツールです。

Reducing time to ticket resolution by 8x with multilingual conversational agents.
.webp&w=3840&q=95)
Yampa leverages ElevenLabs Flash V2.5 to scale human-like outbound voice agents with ultra-low latency and massive concurrency.