チャットボットにおけるユーザー入力の曖昧さ
チャットボットの問題点の一つとして、ユーザー入力の曖昧さを十分に吸収できていない点がある。
特に、RAGを用いたチャットボットでは、ユーザーの質問文と検索対象の文書表現が一致しない場合、適切な情報を取得できず、回答精度が低下する。
この「曖昧さ」は、単なる表記揺れだけではなく、以下のように複数の要因に分解できる。
ユーザー入力の曖昧さの主な要因
1. 表現の曖昧さ
ユーザーが正式名称ではなく、略称・省略表現・日常的な言い換えで質問するケースである。
例えば、以下のような入力が該当する。
- 「育休」
- 「給付金いくら？」
- 「パパ育休」
- 「会社休んだらお金出る？」
一方で、制度文書や公的資料では、以下のような正式表現が使われる。
- 育児休業
- 育児休業給付金
- 出生時育児休業
- 支給額
- 支給率
- 支給上限額
このように、ユーザーの自然な表現と、資料内の制度上の表現にズレがあると、検索クエリと文書表現が一致せず、必要な情報を取得できない可能性がある。
2. 意図の曖昧さ
ユーザーが何を知りたいのかが明確でないケースである。
例えば、次のような質問がある。
育休について教えて
この質問だけでは、ユーザーが知りたい内容を特定できない。
考えられる意図は複数ある。
- 育児休業を取得できる条件を知りたい
- 育児休業の期間を知りたい
- 育児休業給付金の金額を知りたい
- 申請手続きを知りたい
- 社内制度を知りたい
- 社会保険料免除について知りたい
このような場合、単純にRAG検索を行うだけでは、検索範囲が広くなりすぎたり、ユーザーの意図と異なる文書を取得したりする可能性がある。
3. 複数論点の混在
一つの質問の中に、複数の論点が含まれているケースである。
例えば、次のような質問がある。
育休中の給付金と社会保険料と復職後の時短勤務について教えて
この質問には、少なくとも以下の3つの論点が含まれている。
- 育児休業給付金
- 社会保険料免除
- 復職後の短時間勤務制度
このような質問を一つの検索クエリとして扱うと、取得される文書が分散し、回答に必要な情報を十分に集められない可能性がある。
そのため、質問を論点ごとに分解し、それぞれに対して検索を行う必要がある。
4. 回答に必要な条件情報の不足
制度に関する質問では、ユーザーの属性や状況によって回答が変わることが多い。
例えば、次のような質問がある。
育休はいつから取れますか？
この質問に正確に回答するには、以下のような条件情報が必要になる場合がある。
- 雇用形態
- 入社時期
- 子どもの生年月日
- 休業開始予定日
- 男性か女性か
- 有期雇用か無期雇用か
- 社内規程上の適用条件
このような前提情報が不足している場合、検索クエリを拡張するだけでは正確な回答にたどり着けない。
そのため、必要に応じてユーザーへ聞き返す仕組みが必要になる。
5. 公的制度と社内制度の混同
育児制度のような業務領域では、ユーザーが公的制度と社内制度を区別せずに質問することがある。
例えば、次のような質問がある。
育休中に会社からお金は出ますか？
この質問には、以下の2つの観点が含まれる可能性がある。
- 雇用保険制度に基づく育児休業給付金
- 会社独自の給与・手当・福利厚生制度
厚生労働省の資料だけを検索しても、会社独自の制度については回答できない。
一方で、社内規程だけを検索すると、公的な給付制度を見落とす可能性がある。
そのため、質問内容に応じて、検索対象を切り替える、または複数の情報源を組み合わせる必要がある。
対策の方向性
ユーザー入力の曖昧さに対応するには、原因ごとに対策を分けて考える必要がある。
| 要因 | 内容 | 主な対策 |
|---|---|---|
| 表現の曖昧さ | 略称、省略、言い換え、表記揺れ | Query Expansion、Query Rewrite、同義語辞書、Hybrid検索 |
| 意図の曖昧さ | 何を知りたいのかが不明確 | 意図分類、選択肢提示、質問の具体化 |
| 複数論点の混在 | 1つの質問に複数テーマが含まれる | 質問分解、Multi-query検索 |
| 条件情報の不足 | 回答に必要な前提情報が足りない | 不足条件判定、聞き返し、スロット補完 |
| 公的制度と社内制度の混同 | 検索すべき情報源が不明確 | 情報源分類、検索先の切替、複数RAGの使い分け |
Query ExpansionとAgent SDKの役割整理
表現の曖昧さに対する対策としては、LLMによるQuery ExpansionやQuery Rewriteが考えられる。
例えば、以下のような変換である。
| ユーザー表現 | 補正後の検索表現 |
|---|---|
| 育休 | 育児休業 |
| 給付金いくら | 育児休業給付金、支給額、支給率、上限額 |
| パパ育休 | 出生時育児休業 |
| いつまで | 支給期間、対象期間 |
ただし、Agent SDKを用いる場合は注意が必要である。
Agent SDKでは、LLMが検索結果を確認しながら、必要に応じて検索クエリや検索手法を変更し、再探索することができる。
例えば、以下のような動きが可能である。
1回目: search_hybrid("育児休業給付金はいくらもらえますか")
2回目: search_bm25("育児休業給付金 支給率 67% 50%")
3回目: search_bm25("育児休業給付金 上限額 支給期間")
## ベンダー製チャットボットでLLM活用が限定的になりやすい理由
ベンダー製チャットボットでは、LLMの活用が限定的になっているケースがある。
その背景として、LLMを全面的に組み込むと、費用・品質・運用の見積もりが難しくなる点があると考えられる。
従来型のFAQチャットボットであれば、FAQ件数、利用ユーザー数、月額費用などをもとに比較的シンプルに提案できる。
一方で、LLMを利用する場合は、入力トークン数、出力トークン数、利用モデル、RAGで渡す文脈量、検索回数、再検索回数などによって費用が変動する。
特にAgentic RAGのように、LLMが検索クエリを変更しながら複数回探索する構成では、1問い合わせあたりの処理量が可変になる。
そのため、ベンダー側としては、固定価格での提案や運用費用の見積もりが難しくなりやすい。
また、LLMを用いると回答内容が動的に生成されるため、従来のFAQ型チャットボットと比べて、回答品質の保証や誤回答時の責任範囲も設計しにくい。
このため、ベンダー製チャットボットでは、まずはシナリオ型、FAQ検索型、キーワード検索型を中心に設計し、LLMの利用は限定的にしている可能性がある。