📝 この記事は forge.workstyle.tech に掲載した記事の転載です。

音声で対話するアバターに、こういう発話が来る。

👤 YouTubeで配信するときの記事はあるかな。   → 記事を特定できた
👤 それを詳しく説明してくれる?               → 「はい、詳しく説明しますね。」だけ
👤 あれ、詳しく説明してくれないの?           → 「すみません、もう少し…」だけ

前のターンで対象を特定できているのに、次のターンで根拠を失う。 会話としては最も自然な
続け方なのに、検索としては最も弱い。「それを詳しく」には検索できる語が入っていない。

素直な対策と、その結果

直前のユーザー発話を足して検索するようにした。回答に渡す発話そのものは変えない
（書き換えるとモデルが「訪問者が言っていないこと」に答え始める）。

しばらく運用してから、実際のサイト（38ページ）で測り直した。

発話	素のみ	直前を足す	期待
それを詳しく説明して	0.435 ❌	0.602 ❌	正解は2位。トップページを引いた
さっきのアバターのはなし	0.597 ❌	0.594 ❌	別のアバター記事を引いた
このサイトには他にどんな記事が	0.489 ✅	0.429 ⚠️	足すと下がる
なぜ無音配信が必要なの?	0.627 ✅	0.579 ❌	足すと正解を落とす

1勝3敗だった。 直したつもりの対策が、3例で悪化させていた。

指示語が3種類混ざっていた

実際の会話ログを読むと、「この」「それ」がまったく違うものを指していることが分かった。

👤 このページには何が書いてあるの?        ← いま見ている画面
👤 このサイトには他にどんな記事が?        ← いま見ているサイト
👤 それを詳しく説明して                   ← 直前のやり取り
👤 さっきのアバターのはなし               ← 数ターン前のやり取り

日本語文法では、これを現場指示（発話の現場にあるものを指す）と文脈指示（前に出た
言語表現を指す）として区別する。音声＋画面のUIでは、現場＝画面になる。

そして文脈指示は、さらに2つに分かれた。直前を指すものと、数ターン前を指すものだ。

種別	例	必要な文脈
現場指示	このページ／このサイト	足さない。答えは今のページが持っている
直近文脈	それ／あれ／詳しく／続けて	直前の往復を足す
遠隔文脈	さっきの◯◯／例の◯◯	◯◯ で履歴を探し、該当の往復だけ足す
（疑問詞）	なぜ／なんで／どういう	指示語ではない。足すと正解を落とす

疑問詞をリストに入れていたのが、4例目の悪化の原因だった。「なぜ無音配信が必要なの?」は
独立した質問で、引き継いでいない。

足すべきは「ユーザーの発話」ではなく「往復」だった

「それを詳しく」の「それ」が指しているのは、普通アバターが今説明した内容だ。
一つ前の質問文ではない。

検索クエリの作り方	1位	スコア
素の発話のみ	❌ 無関係な記事	0.435
前のユーザー発話＋今	❌ トップページ	0.602
前の往復すべて＋今	✅ 正解	0.741
前のアバター回答＋今	✅ 正解	0.729

往復（ユーザーの発話＋アバターの回答）を足したときだけ、正解が1位になった。

遠隔文脈は「窓で遡る」と、遡らないより悪くなる

「さっきのアバターのはなし」で、その話題が3ターン前にあった場合を測った。

	1位	スコア
素の発話のみ	❌ 別のアバター記事	0.597
直前1往復＋今	❌ 同上	0.587
直前2往復＋今	❌❌ 無関係な配信記事	0.564
直前3往復＋今（正解を含む）	✅ 正解	0.732
該当する往復だけ＋今	✅ 正解	0.813

3つのことが分かる。

「さっき」は直前1往復では届かない。 どこまで遡るかが不定なのがこの語の性質だ。
中途半端に遡ると、遡らないより悪くなる。 間に挟まった別の話題に引きずられる。
全部足すより、該当する往復だけを選ぶほうが良い（0.813 対 0.732）。余計な文脈は薄める。

幸い、この発話は自分で手がかりを持っている。「さっきのアバターのはなし」の
「アバター」だ。会話履歴の中からこの語に近い往復を探せばいい。照合は文字の2-gram の
重なりで足りた。形態素解析も追加の埋め込みも要らない。

⚠️ 抽出した語をプロンプトに埋め込もうとして失敗した。文字単位で機能語を落とす実装
だったので、「それをもうちょっと詳しく」から取れたのは 「うちょ詳」 だった。
検索の鍵としては使えても、日本語として読めるものではない。質問文そのものはプロンプトに
入っているので、そもそも再掲する必要がなかった。

「詳しく」を文字数で切っていた

もう一つ、実データで分かったことがある。ユーザーからこういう指摘を受けた。

「詳しく」という言葉が出る時は、必ず依頼もしくは意思のどちらかの言葉が付随するはずです。

実データ22件で確かめた。

	件数
「詳しく」「具体的」を含む	22件（全件）
うち依頼（教えて・説明して）が付随	12件
うち意思（知りたい・聞きたい）が付随	2件
どちらも無い	8件（36%）

意味としては指摘のとおりだが、表層では3分の1が省略されていた。

配信枠の作成について詳しく。
具体的なステップは。
具体的なコンテンツ、パイプラインについて。

依頼の意味は明らかにあるのに、動詞が消えている（体言止め）。日本語では普通の言い方で、
これはゼロ照応と同じ現象だ。だから「依頼か意思の語が付随すること」を必須条件にすると、
3分の1を落とす。

一方、「詳しく」「具体的」という語そのものは22件すべてに現れた。最も信頼できる印は
語そのものだった。

そしてこの検証で、もっと大きな欠陥が見つかった。22件のうち4件が25字を超えていた
（最長70字）。

いや、その話じゃなくて、セットインターバルで30FPSを刻むことによって、
だんだん口と音声が合わなくなるっていう話を詳しく知りたいんだけど。

掘り下げの判定を、文脈を足すかどうかの判定に載せていた。そこには「短くて単独では検索
できない発話」を拾うための25字の足切りがある。だからこれらは掘り下げ要求として扱われて
いなかった。

「文脈を足すか」と「掘り下げを指示するか」は別の軸だった。 長い発話は自前で検索できるが、
掘り下げの指示は必要だ。

結果

発話	修正前	修正後
それを詳しく説明して	0.602（誤答）	0.741（正解）
さっきのアバターのはなし	0.594（誤答）	0.832（正解）
このサイトには他にどんな記事が	0.502（正解）	0.483（正解）
なぜ無音配信が必要なの?	0.624（正解）	0.627（正解）

LLMの往復はゼロで、応答時間は変わっていない。

一般化できること

会話検索の分野では、この処理を Conversational Query Rewriting と呼ぶ。扱う現象は
照応（「それ」が前を指す）と省略（語そのものが落ちる）の2つで、日本語では後者が
「ゼロ照応」として専門の研究分野になっている。

実務側の報告では、フォローアップ発話の60%以上に未解決の照応や暗黙の文脈があるとされる。
書き換えは小型モデルで足り、p95で100ms未満という数字も出ている。

ただし "Not All Queries Need Rewriting" という研究結果もある。もともと十分な情報を
持つクエリを書き換えると、密検索の性能が落ちる。推奨されているのは、用途が安定した領域では
書き換えないことを既定にし、選択的に書き換えるなら検索の確信度を判断の代理指標にすることだ。

私の実装は「発話の見た目」（文字数と語のリスト）で決めていた。それが4例中3例の悪化を生んだ。

そして音声＋画面のUIでは、研究の前提が1つ変わる。テキストだけの会話検索と違い、
「この」が指す先に画面という選択肢が加わる。実データでは、指示語の多くが会話ではなく
画面を指していた。この区別は、日本語文法の現場指示／文脈指示の区別とそのまま対応していた。

シリーズ: 音声対話アバターに、ちゃんと答えさせるまで

この記事は第2部言葉を解くにあたります。

← 前: スマホの指がエコーキャンセラを壊していた
→ 次: 巨大なプロンプトの末尾に置いた1行は、4回とも無視された

シリーズ全8本

第1部音を止める

同じ名前のイベントが2種類あった
自己エコー対策が、一度も動いていなかった
スマホの指がエコーキャンセラを壊していた

第2部言葉を解く
4. 「それ」と「このページ」と「さっきの」は、別物だった ← いまここ
5. 巨大なプロンプトの末尾に置いた1行は、4回とも無視された
6. 謝罪の言葉が、次の検索を汚していた

第3部見極める
7. 全部の発話が質問ではない
8. 測っていたつもりが、別のものを測っていた

知見の元になったノートは音声対話アバターの応対品質にまとめてあります。

元記事: https://forge.workstyle.tech/blog/three-kinds-of-it/?utm_source=qiita&utm_medium=crosspost&utm_campaign=three-kinds-of-it