Retell の音声システムは、3つのコアステップから成るライブなチェーンのように機能します。そして各ステップは、その前のステップに依存しています。
ASR → LLM → TTS
ASR(自動音声認識)は発信者の声を聞き取り、その音声をテキストに変換します。
LLM(言語モデル)はそのテキストを読み取り、何が話されたかを理解し、何を返答するかを決定します。
TTS(テキスト読み上げ)はその応答を受け取り、発信者が聞く音声に変換します。
つまり流れは基本的に次のようになります:発信者が話す → ASR が文字起こしする → LLM が応答を生成する → TTS が読み上げる。
通話中は、ASR と LLM の両システムがリアルタイムで動作する重要なシステムです。そしてどちらも、障害を起こしたり、遅くなったり、予測不能な動作をしたりする可能性があります。私たちは両システムが機能していることに頼る必要があるため、常に監視し、バックアップを取り、リアルタイムで切り替える仕組みを構築しました。ここでは、この2つがどのように連携するのか、そしてなぜこれらのアップデートが重要なのかをご説明します:
まず、(障害ではなく)遅延を監視します
私たちは常に1つのシンプルな問いを立てています:「システムは会話についていけているか?」 0.1秒ごとに、次を比較します:
その差が5秒を超えて広がった場合、それが私たちのシグナルです:このプロバイダーは遅れをとっています。停止したわけでも、故障したわけでもありません。しかし、そちらに向かっています。そこで私たちは行動します。
お客様の音声のライブな「セーフティネット」を保持します
音声が処理される間、まだ完全に処理されていないものすべてのローリングバックアップを保持します。次のように考えてください:
- システムが何かを処理したと確認したら → それを破棄します
- まだ処理していない場合 → 保持し続けます
そのため、どの瞬間でも、失われるリスクが最も高い部分である「中間の」音声の完全なコピーを持っています。推測なし。ギャップなし。
次に、バックアップに切り替えます
遅延を検知した瞬間、私たちは待ちません。私たちは:
- バックアッププロバイダーを起動します(優先順位があります:最速、最も近い、最も信頼できるものが最初)
- その「宙ぶらりん」の音声をすべて送信して追いつけるようにします
- 苦戦しているプロバイダーを停止します
また、新しいプロバイダーには、パフォーマンスの判定を始める前に安定するための短い猶予期間(約20秒)を与えます。
その結果は?
文字起こしは、ただ…続いていきます。飛びもせず、巻き戻りもせず、おかしなギャップもありません。発信者の視点からは、何も起きていません。
なぜこれが重要なのか
ほとんどのシステムは、切り替える前にプロバイダーが完全にクラッシュするのを待ちます。
私たちは待ちません。苦戦し始めた瞬間を捉え、問題になる前に置き換えます。
結論
- 私たちは障害を待ちません
- 遅延をリアルタイムで検知します
- 音声を1秒たりとも逃さず保持します
- プロバイダーをシームレスに切り替えます
そのため、会話はあるべき姿のまま流れ続けます。
LLM:プロバイダーレベルからデプロイメントレベルのルーティングへ
LLM のフォールバックの仕組み
さて、応答側では、障害はそれほど明白ではありません。もっと微妙です。各 LLM モデル(例:GPT-4.1)には、そのモデルを提供する一連の「デプロイメント」があります。デプロイメントを物理的なデータセンターと考えてください。AI 応答を生成したい場合、または精度を高めてハルシネーションを減らすために LLM Knowledge Graph からグラウンディングされたコンテキストを取得したい場合、そのリクエストを処理する特定のデプロイメントを指定する必要があります。
内部的には、いくつかの可動部分があり、少し複雑になることもありますが、核となる考え方はシンプルです:
私たちはよりレイテンシ(遅延)の低いデプロイメントにルーティングします
応答がより速く生成されることを保証し、遅延を減らして会話をリアルタイムで同期させ続けます。
私たちは各デプロイメントのエラー率を常に測定・監視します
そして、エラー率の高いものへのトラフィックを遮断します。
デプロイメントにリクエストを送信する際、私たちはスピードを求めます
遅い場合、私たちは待ちません。リクエストを別の場所に送り、いずれかが応答するまで続けます。
最良の AI モデルに軍配を
あるモデルが複数のデプロイメントで失敗した場合、私たちはそれを試し続けません。別のモデルに切り替えて続行します。
結論
私たちは1つのモデルや1つのプロバイダーに頼っていません。
私たちは常に:
- 最良の選択肢にルーティングし
- 失敗しているものを避け
- より速い応答を競い
- 必要に応じて切り替えています
そのため、システムに不調な日があっても、お客様の会話には影響しません。