RAG・音声認識・音声合成を組み合わせたAIデジタルヒューマンの仕組み

画面の中の案内役が話す場合でも、裏側は一つのモデルが全部を判断しているわけではありません。音声を文字にし、用意した知識から該当箇所を探し、回答文を作り、それを音声に戻す、という処理が分かれています。

この記事では、その接続だけを扱います。どの施設で使ったか、人員や費用がどう変わったかは書きません。開発としての担当範囲は、集合住宅向けの音声応対に分けてあります。

処理は五段に分かれる

1. 利用者が話す。
2. 音声認識（ASR）が、発話をテキストにする。
3. 検索が、あらかじめ登録した知識から該当箇所を取る。
4. 言語モデルが、その箇所を使って回答文を作る。
5. 音声合成（TTS）が回答文を読み、デジタルヒューマンの口の動きと合わせる。

キーボード入力を受ける場合は、2を飛ばして3から始まります。画面表示だけにする場合は、5を省略できます。知識の検索は、どちらでも残します。

音声認識で落ちるところ

ASRは、静かな短い発話では安定しやすいです。施設の案内端末では、周囲の音、言い直し、固有の設備名が混ざります。認識結果が質問とずれていると、その後の検索は別の文書に当たります。

このため、認識テキストをそのまま利用者に見せ、聞き取れなかったときは聞き直す、という戻りを先に置きます。認識できなかった発話を、それらしい質問へ補正して検索には進めません。

検索は、登録した知識の範囲だけ

回答の材料は、管理側が文章として渡した手順、料金、連絡先、設備の説明です。一般的な建物の知識で穴を埋めません。

文書は項目ごとに分け、質問と近い断片を検索します。当たった断片が無い、または質問と条件が違うときは、回答文を作らず「登録情報では分からない」と返します。数字や状態が表で決まっている項目は、文章の検索ではなく、条件で引けるデータ側に残す方が確実です。

回答文と音声は、検索の後

言語モデルの役割は、当たった断片を、話して聞ける長さの文にすることです。検索結果に無い料金や手続きを補う設定にはしません。

TTSはその文を読みます。デジタルヒューマンは、同じ文のタイミングに合わせて表示します。見た目の動きと、検索で当たった内容は別です。動きが自然でも、根拠の断片が無ければ回答にはしません。

この構成が向かない場合

• 現場に行って確認しないと答えられない故障
• 登録していない、その場の個別事情
• 人の判断が必要な苦情や緊急の対応

これらは音声案内の外に戻します。一次的な説明と、人が対応する案件の切り分けが、この構成の境界です。応答の正確さや、対応件数の変化は、知識の中身と質問のセットを決めてから測るもので、構成だけでは約束できません。