音声AIナレッジベースの構築方法
製品・地域・対象者のメタデータでタグ付けした512トークンの再帰的Markdownチャンクとして構造化し、0.65以上の類似度しきい値で明示的な拒否指示とともに検索します。これは、 Retell AIのようなプラットフォーム上で本番稼働する音声エージェントが、手順をでっち上げる失敗モードを防ぐために使う4層パターン（キュレーション、チャンキング、メタデータによるスコープ設定、デフォルト拒否型の検索）です。
このガイドの残りの部分では、各層について正確な設定値、Lenovoのようなエンタープライズサポートライブラリをモデルにしたリファレンス構造、そして発信者に届く前にハルシネーションを捕捉するテストプロトコルを解説します。
すべてのエージェント応答を検証済みコンテンツに根拠づけ、モデルが手順を発明するのをブロックし、自然な電話会話に必要なレイテンシ予算内に収める検索アーキテクチャです。
このチュートリアルを終える頃には、あなたのナレッジベースは以下を実現します：
1ページでもインデックス化する前に、古い、矛盾している、またはそのトピックの単一の信頼できる情報源ではないすべてのドキュメントをアーカイブします。音声エージェントのハルシネーションの最大の原因はモデルではありません。ソース素材の中の矛盾したコンテンツや古いコンテンツです。
2つのページが返金期間について食い違っている場合、検索エンジンには正しいものを選ぶ手段がなく、LLMは類似度スコアで勝ったチャンクを自信満々に読み上げます。インデックス化する予定のすべてのドキュメント、FAQ、ヘルプ記事を集めてください。それぞれについて3つのことを確認します：今四半期時点で最新か、そのトピックの単一の信頼できる情報源か、そしてベテランのサポート担当者が実際に電話で話す内容と一致するか。顧客の質問への回答に使うべきでないドキュメントは、そもそもナレッジベースに入れるべきではありません。 ElevenLabs
これで、そのまま顧客に送っても問題ないと思えるキュレーション済みのドキュメントセットが手元にあるはずです。
すべてを構造化されたMarkdownに変換します。1ドキュメントにつき1つのH1、解決可能なユーザーの質問ごとに説明的なH2、そして明示的な主語を持つ短い段落を使います。音声エージェントが検索するのはレンダリングされたWebページではなく、テキストチャンクです。Markdownは、最も意味的な構造を保ったままチャンキングパイプラインを通過できる形式です。
Retell独自のドキュメントも、よく構造化された見出しが検索エンジンに分割のためのクリーンな境界を与えるため、.txtよりもMarkdownを推奨しています。「ここをクリック」や「上記のとおり」はすべて具体的な参照に置き換えてください。「上記」を含むチャンクは、それが指すチャンクなしで検索される可能性があるからです。各チャンクは単独で読まれるため、各チャンクが単独で意味をなす必要があります。
これで、各ファイルが1つの製品領域をカバーし、各H2が1つの解決可能なユーザーの質問をカバーするMarkdownファイルのフォルダが手元にあるはずです。
Markdownの見出しをまず優先して分割し、次に段落、次に文で分割する、512トークンで10〜15%のオーバーラップを持つ再帰的チャンキングを使います。これは一般的なRAGコンテンツに対してベンチマークで検証されたデフォルトであり、特に音声サポート素材でも十分に有効です。
15%のオーバーラップとメタデータエンリッチメントを備えた、適切に調整された512トークンの再帰的スプリッターは、ほとんどの実世界のドキュメントセットにおいて、高価なセマンティックチャンキングアプローチを上回ります。長いチャンクはLLMのコンテキストウィンドウをノイズで埋めます。短いチャンクは指示を複数の検索に分断し、エージェントが説明の途中で手順を飛ばす原因になります。厳守ルール：番号付きの手順を2つのチャンクに分割してはいけません。「ステップ3」がチャンクAに、「ステップ4」がチャンクBにある場合、検索エンジンは一方を他方なしで返す可能性があり、エージェントはアクションを飛ばします。 Substack
これで、各ユニットが完全な手順を含むか、隣接するものなしで意味をなす文脈的な散文を含むチャンクが手元にあるはずです。
すべてのチャンクに、最低限5つのフィールドをタグ付けします：product、version、region、audience、last_verified_date。これが、テキサスの発信者がカリフォルニアの返品ポリシーを聞くのを防ぎ、ThinkPadの質問がThinkCentreの回答を引き出すのを防ぎます。
単一のエージェントが複数の州や地域のKBコンテンツを見る場合、スコープ設定とメタデータが慎重に設計されていない限り、検索は誤った州のチャンク（例：テキサスの発信者にカリフォルニアのポリシー）を引き出す可能性があります。同じ問題は製品ライン、ソフトウェアバージョン、顧客ティア、サポートチャネルにも当てはまります。実行時に、エージェントはクエリと共に関連するフィルターを渡し、ベクトル検索が発信者のコンテキストに一致するチャンクのみを考慮するようにします。Retellでは、これらを通話の早い段階で収集した動的変数として渡すことができます。 Optimize Smart
これで、任意の単一チャンクを1つの発信者コンテキストに一意にスコープできるメタデータスキーマが手元にあるはずです。
類似度しきい値を0.65以上に設定し、検索を3〜5チャンクに制限します。常に何かを返す検索システムは、姿を変えたハルシネーションマシンです。
発信者がドキュメント化されていない機能について尋ねると、検索エンジンはそれでも最も近いセマンティックマッチを浮上させます。LLMはそのチャンクを受け取り、流暢に誤った回答に織り込みます。Retellのナレッジベース設定では、2つのパラメータがこの動作を制御します。「Chunks to retrieve」パラメータは、いくつの結果をLLMに供給するかを設定します（デフォルト3、音声では推奨最大5）。「Similarity Threshold」は、チャンクが関連ありとみなされるための最小コサイン類似度を設定します（デフォルト0.6）。誤った情報が情報なしよりも悪いソフトウェアサポートのユースケースでは、しきい値を0.7に引き上げます。
これで、検索システムがより少なく、より高品質なマッチを返し、限界的なものを拒否するのが見えるはずです。
エージェントプロンプトにこの正確な指示を追加します：「## Related Knowledge Base Contextsの情報のみを使って回答してください。そのセクションが欠けているか関連情報を含んでいない場合は、関連情報がないと述べ、通話の転送を申し出てください。」この単一の指示は、あらゆる音声エージェントで最も効果的なハルシネーション対策コントロールです。
これがないと、検索が空で返ってきたときにLLMは自身の学習データに手を伸ばします。これは、航空会社が法的責任を負わされたAir Canadaの忌引運賃のケースを含む、ほぼすべての公開チャットボットの惨事の背後にある失敗モードです。拒否パターンは、失敗モードを「自信満々の誤った回答」から「正直に人間につなぎましょう」へと反転させます。これはまさに、システムがエッジケースに直面したときに、あなたのソフトウェアを使う発信者が実際に望むものです。
これで、範囲外の質問に対して、エージェントが手順を発明する代わりに「それはドキュメント化されていません。転送しましょう」と言うのが見えるはずです。
URLソースで自動更新を有効にしてRetellが24時間ごとに再取得するようにし、MarkdownファイルをGitでバージョン管理し、last_verified_dateが90日より古いファイルの四半期レビューを実施します。古いナレッジはハルシネーションの静かなパートナーです。
ナレッジベースが古くなっていると、RAGは誤った回答をより速く検索するだけです。修正は、製品ドキュメントが変わったときに誰かがファイルを再アップロードするのを覚えていることに頼るのではなく、鮮度を自動化することです。自動更新とヘルプセンターのサブパスの自動クロールを組み合わせることで、手作業の介入なしに新しい記事が自動的にインデックス化されます。 CX Today
これで、基盤となるコンテンツが更新されると、人間が介在せずに自動更新されるナレッジベースが手元にあるはずです。
50件の実際の発信者の質問を検索システムに通し、LLM生成が起こる前に何が返ってくるかを検査します。各クエリで3つのことが重要です：正しいチャンクが上位3件に入っているか、類似度スコアがしきい値を超えているか、そして検索されたチャンクだけを読んだ人間が質問に答えられるか。
検索が失敗するどの質問についても、修正はほぼ常にソースにあります。関連コンテンツが完全に欠けているか、チャンキングが手順を境界をまたいで分割したか、メタデータがそれをフィルタリングで除外しているかのいずれかです。検索の失敗をエージェントプロンプトに指示を追加して修正したい衝動に抵抗してください。プロンプトのパッチは、ナレッジベースが保守不能な混乱へと漂流する原因です。ライブ通話にデプロイする前に、テストセットで90%以上の検索精度を目指してください。
これで、上位の発信者の質問に対する測定された検索精度の数値と、失敗した質問についてのソースドキュメントの修正リストが手元にあるはずです。
発信者の意図が個別のワークフローに分かれる音声エージェント、特にソフトウェアサポート、ヘルスケアのスケジューリング、マルチ製品環境では、ノードレベルのナレッジベースを持つ会話フローを使います。単一プロンプトの下にあるフラットなナレッジベースは、考えうる最も緩いアーキテクチャです。
特にソフトウェアサポートでは、最高品質のパターンは、各ノードが通話のその部分に関連するドキュメントのスライスからのみ検索する会話フローです。典型的なソフトウェアサポートフローには、トリアージ、アカウント検索、トラブルシューティング、エスカレーション、解決後確認のためのノードがあります。トラブルシューティングノードはトラブルシューティングKBをロードします。アカウント検索ノードはAPIを呼び出すべきなので、KBをまったくロードしません。この構造は、1つの巨大なKBを持つ1つの巨大なプロンプトよりも保守が信頼できます。組み込みの 通話後分析と組み合わせることで、どのノードが検索を発火させているか、どのクエリがしきい値を下回って返ってきているかを確認できます。
これで、すべてのターンですべてのドキュメントを検索する代わりに、会話が絞り込まれるにつれて検索範囲が狭まるデプロイメントが手元にあるはずです。
ナレッジベースを対象者別にティア分けし、検索を発信者のティアにスコープします。これは、教師向けの教室管理コンテンツが技術的なエンジニアリングコンテンツと衝突しないようにするために、Lenovoのエンタープライズサポートライブラリが使う構造パターンです。
Lenovoは3つのレベルの記事を確立しました。一般的なトピックと製品情報、教師固有のトピック、技術的なトピックと問題です。3つのすべてのティアにわたって、焦点を絞った記事、冗長性の排除、命名規則の標準化を行いました。同じパターンを音声AIナレッジベースに適用します： Contiem
ティア1：一般的な製品と価格。すべての発信者が尋ねる可能性のある一般公開向けの事実。audience: allとタグ付け。すべてをインデックス化します。
ティア2：エンドユーザー向けハウツー。標準的な発信者向けのステップバイステップの手順。audience: end_userとタグ付けし、productとregionでスコープします。このティアが検索トラフィックの大部分を担います。
ティア3：技術および管理者向け。設定、統合、エッジケース。audience: adminとタグ付け。発信者が通話の早い段階で管理者として識別された場合にのみ検索されます。
内部のランブック、エスカレーションマトリックス、エンジニアリングノートは、完全に別のナレッジベースに入れ、顧客向けエージェントには決してアクセスできないようにします。ティア分けこそが、エンドユーザーのトラブルシューティング通話が誤って内部のエスカレーション手順を浮上させるのを防ぎます。
いいえ。ナレッジベースは補足情報を供給するためのものであり、エージェントの動作のためのものではありません。「Xが起きたときにエージェントがどう振る舞うべきか」というタイトルのMarkdownファイルをアップロードしていると気づいたら、そのコンテンツはプロンプトまたは会話フローノードに属します。両者を混ぜると両方が薄まります：検索エンジンは動作指示を事実クエリに対してランク付けし、誤ったタイミングで引き出します。
機能名ではなく、ユーザーの目標から始めます。「二要素認証を設定する」は「二要素ログインをオンにする」になります。検索エンジンは発信者が話す言葉に対してマッチし、自然言語の質問は製品用語よりも自然言語の見出しにはるかによくマッチします。
各チャンクは単独で検索されます。代名詞の代わりにフルネームを使い、「そのプラットフォーム」の代わりに完全な製品名を使い、3段落後に「管理者コンソールを使っている場合は…」と言う代わりに、各ステップで条件付きコンテキストを繰り返します。この単一のルールは、驚くほどの割合のハルシネーションを排除します。なぜなら、LLMが推測によって解決しようとする曖昧さを取り除くからです。
すべての通話で、検索されたチャンク、類似度スコア、メタデータフィルターをトランスクリプトと共にキャプチャします。最終的なエージェントの応答のみをロギングすると、ハルシネーションのデバッグはほぼ不可能になります：誤った回答は見えますが、検索エンジンが誤ったチャンクを返したのか、正しいチャンクが誤って生成されたのかは見えません。ほとんどの「ハルシネーション」チケットは、実は検索ランキングの問題であることが判明し、それはソースで修正されます。
チャンキングパイプラインは、表を読みやすくする空間的関係を保持できないため、表のセルはしばしば列見出しなしで検索されます。重要な表は、明示的な文を持つ散文として書き直します。「Proプランは50ユーザーをサポートし、APIアクセスを含みます」は、検索エンジンが列見出しから切り離す表のセルに勝ります。
特定の発信者に対して50件が関連する4,000チャンクのナレッジベースは、50件が関連する400チャンクのナレッジベースよりも悪いです。なぜなら、検索エンジンには混乱させる競合マッチが10倍多いからです。代わりに、ワークフローごとに狭いナレッジベースを構築し、ノードレベルでリンクします。
エージェントが何か誤ったことを言うと、本能的にプロンプトに「Xと言うな」を追加したくなります。これが3つになるとプロンプトは矛盾し、10になると管理不能になります。なぜLLMがXと言ったのかを突き止めてください。ほぼ常に、KBの中のチャンクがそれを示唆したか、チャンクの不在がモデルを学習データにフォールバックさせたかです。ソースにパッチを当ててください。
追加のチャンクごとに、プロンプトにトークンが加わり、応答にミリ秒が加わります。より多くのコンテキストが安全に感じるからといって「chunks to retrieve」を10に設定するのは、よくある間違いです。典型的なサポートコンテンツでは3チャンクにとどまり、発信者の質問が複数のトピックにまたがる場合にのみ5に増やし、精度が向上するのを測定していない限り、それ以上には決してしないでください。
明示的な拒否指示なしにエージェントが話すことを許されているからです。Air Canadaのチャットボットは、航空会社の実際のルールと矛盾する存在しない忌引ポリシーを生成した後、責任を負わされました。そして、拒否層を飛ばすベンダー全体で同様の失敗が繰り返し発生し続けています。拒否を明示的にし、それが発火することをテストし、エージェントが情報を発明するあらゆるケースをP0バグとして扱ってください。 CanLII
新しいドキュメントを追加すると、既存のすべてのクエリの検索環境が変わります。昨日1位にランクしたチャンクが、今日は3位にランクするかもしれません。50問のテストセットを自動化しておき、基盤となるコンテンツが大きく変わるたびに再実行してください。
SWTCHは、EV充電器のサポート通話を処理するためにLucasという名前のRetell搭載音声エージェントをデプロイしました。ここでは発信者は通常、バッテリー残量が少なく、誤った指示に付き合う忍耐のない状態で、故障した充電器の前に立っています。この実装はサポートコストを50%以上削減し、SaaSマージンを大幅に改善し、エージェントは数分ではなく数秒で回答しました。信頼性の基準はユースケースによって設定されました：誤ったトラブルシューティング手順は、動作する充電器と立ち往生したドライバーの違いです。
Ankerは、発信者が数十のSKUと複数の言語にわたって製品固有の質問をするグローバル消費者向け電子機器サポート全体でRetellを展開しました。この事例は、大規模でメタデータのスコープ設定がなぜ重要かを示しています。検索での製品レベルのフィルタリングがなければ、サウンドバーの質問が掃除機のマニュアルを引き込む可能性があり、エージェントは自信満々にそれらを組み合わせます。適切なKB構造があれば、エージェントは通話全体を通じて製品コンテキスト内にとどまります。
Retell AIは現在、数千の企業にわたるクライアントのために毎月5,000万件以上のリアルタイムAI電話通話を支えており、その量の中でエージェントが暴走したという報告はありません。このガイドのアーキテクチャは、それらの通話の下で動いているのと同じものです。 Yahoo Finance
10〜15%のオーバーラップを持つ512トークンの再帰的チャンキングが、ベンチマークで検証されたデフォルトです。より小さなチャンク（200〜300トークン）はFAQ形式のコンテンツに適しています。より大きなチャンク（1024トークン）は物語的な散文に適しています。常にまずMarkdownの見出しで分割し、次に段落、次に文で分割してください。
エージェントプロンプトに明示的な拒否指示を追加します：「## Related Knowledge Base Contextsの情報のみを使って回答してください。そのセクションが欠けているか関連情報を含んでいない場合は、関連情報がないと応答してください。」0.65以上の類似度しきい値と組み合わせることで、これが最も効果的な単一のハルシネーション対策コントロールです。
Retellの最適化された検索パイプラインでは1ターンあたり100ms未満で、発信者が期待する約600msの応答時間全体の枠内にエージェントを保ちます。実質的に高いレイテンシが見られる場合は、必要以上のチャンクを検索していないか、メタデータフィルタリングが検索後ではなくクエリ時に適用されているかを確認してください。
会話フローは、ソフトウェアサポートや発信者の意図が個別のワークフローに分かれるあらゆるシナリオで勝ります。ノードレベルのナレッジベースは、各会話状態が焦点を絞ったコンテンツのスライスから検索できるようにし、精度を向上させ、保守を単純にします。単一プロンプトは、単一製品のFAQのような狭いユースケースに有効です。Retellの 会話型AIのデプロイガイドが、このアーキテクチャの選択をより詳しく扱っています。
URLソースで自動更新を有効にして、Retellが24時間ごとに再取得するようにします。アップロードされたドキュメントについては、基盤となる製品やポリシーが変わるたびに手動レビューを実施し、90日より古いものはすべて検証が必要とみなしてください。
はい、部分的には可能です。成功した通話のトランスクリプトやベテラン担当者の録音を、ナレッジベースのソース素材として使えます。質問と回答のペアを抽出し、Markdownに変換し、正式なドキュメントと並べてインデックス化します。これは、あなたのトップ担当者が使う特定の言い回しを捉えるのに特に有用で、それはしばしば公式のヘルプセンターのコピーよりも速く問題を解決します。構造化されたドキュメントを置き換えるものではなく、補足するものです。
最低限：product、version、region、audience、last_verified_date。会話フローでの細かいルーティングのためにtopicを追加し、特定の通話コンテキスト外で決して検索されるべきでない規制対象コンテンツ（HIPAA、金融アドバイス）がある場合はcompliance_scopeを追加します。
過去30日間のサポートチケットから、50〜100件の実際の発信者の質問のテストセットを構築します。それぞれについて、LLM生成の前に検索されたチャンクを検査します：正しいチャンクが上位3件に入っているか、類似度スコアがしきい値を超えているか、そして人間がそれらのチャンクだけから質問に答えられるか。デプロイ前に、テストセットで90%以上の検索精度を目指してください。
拒否指示が設定され、0.65以上の類似度しきい値があれば、エージェントはその情報がドキュメント化されていないと述べ、伝言を受けるか、 通話転送で完全な会話コンテキストを持つ人間のエージェントにウォームトランスファー（事前取次）します。これらのコントロールがなければ、エージェントは基盤となるLLMの学習データにフォールバックします。それはまさに、このガイドが防ぐために設計された失敗モードです。
これで、すべてのエージェント応答を検証済みコンテンツに根拠づけ、発信者コンテキストで検索をスコープし、回答がドキュメント化されていない場合は回答を拒否し、ソース素材が変わると自動更新するナレッジベースアーキテクチャが手元にあります。これが、音声エージェントがソフトウェアサポート、規制業界、あるいは速さよりも誤った手順が重大となるあらゆる高リスクな通話を処理できるようにする基盤です。
これをさらに拡張するには、同じ検索アーキテクチャが、 AIカスタマーサポートの自動化、製品固有のルーティングを備えた リード選別、そしてコンプライアンスのスコープ設定が譲れないヘルスケア診療向けのAI搭載受付 といったユースケースをサポートします。同じパターンは、ハルシネーションのコストが単なるカスタマーエクスペリエンスではなく規制上の問題となる ヘルスケアや保険のデプロイメントにも当てはまります。
retellai.comで$10の利用クレジットを使って無料で構築を始めましょう。
AI搭載の音声エージェントに切り替えることで、あなたのビジネスがどれだけ節約できるかをご確認ください。
Total Human Agent Cost
AI Agent Cost
Estimated Savings
Retell クリニックオフィスのデモ電話番号
Start building smarter conversations today.
.avif)
.avif)
