自動応答システム「ダイアログナビ」
以前の試みだが、対話的自動応答システム「ダイアログナビ」について紹介したい。マイクロソフトが提供するテキスト知識ベースを元に、Windows環境のユーザーを対象にしたカスタマーサポートの自動応答システムである。
ネット上には大規模なテキスト集合が存在し、潜在的にはどのような質問にもどこかに答えがあるという状況が生まれつつある。にも関わらず、コンピュータには対話的な能力がなく、ユーザーは未だに多大な労力を費やして適切なテキストを探す必要がある。これは、ユーザーが漠然と質問を行う場合でも、ある目的を持って質問する場合でも同様である。
仕組み
全体の質問対応に関するフローチャートは下記の図で表される。ポイントは下記の3つである。
①テキスト知識ベースの活用
②テキスト検索
ユーザーからの質問に適合するテキストを検索する。質問タイプの同定、同義表現辞書などによる表現ずれの吸収、係り受け関係の重みづけを行っている。なお、同義表現辞書は下記の通りである（3512語・217フレーズ）。
また、上位・下位表現を紐づけるために下記のような上位・下位表現辞書を構築している（200語）。
③ユーザーへのナビゲート
ユーザーが曖昧な質問をしたとき、対話的に聞き返しを行うことによってユーザーを具体的な答えにナビゲートする。聞き返しの方法としては対話カードと状況説明文の抽出の2種類を組み合わせて用いる。
上記の例では、「エラーが発生する」という漠然とした質問に対して聞き返しを行い、ユーザーの意図を明確化した後に知識ベースを検索してその結果を抽出している。
なお、対話カードとは典型的なユーザー質問文を定型化しカードとしてまとめた物である。
予備調査
マイクロソフトが提供する「話し言葉検索」の検索ログを分析したところ、全体の3割のユーザーの質問はその意図が不明確だったことが分かった。この曖昧な質問に対してはユーザーの意図しない回答がマッチするため、満足度は高くない。
テキストの検索
質問応答システムにおいて重要なことは、質問の意図を把握し、適切な回答を返すということである。どのように検索の精度を向上させるかを以下に示す。
マッチングの前処理
ユーザー質問文と回答事例はそれぞれ構文解析を行って文節単位の係り受け構造に変換した上でマッチングを行う。まず、ユーザー質問文と回答事例について、JUMANおよびKNPによって構文解析を行い、各文節に含まれるキーワード抽出を行う。
JUMANにおいては普通名詞・固有名詞・人名・地名・組織名などと解析された語の原形をキーワードと見なす。
また、文節の分割・併合処理を行う。これは例えば下記のような文章は同じ意図を持つにも関わらず4文節、2文節と異なる文節数として認識されてしまう。従って、「～について」「～こと」などの複合辞・形容名詞・副詞的名詞からなる文節、キーワードを含まない文章は直前の文節に併合する。
さらに、否定表現のバリエーションを吸収するため、文節にフラグを付与する。具体的には、形容詞「ない」、助動詞「ぬ」、形容動詞「不可能だ」を含む場合には否定フラグを付与する。
ユーザー質問文のタイプ推定と文末表現の削除
ユーザーからの質問を解析した結果、主に下記3種類のパターンがあることが判明した。
この文末表現パターンを用いて、質問タイプを推定することにした。また、文末表現のうち「～って何ですか」「～方法を教えて」というものはノイズとしてユーザー質問文から削除する。
表現ずれの吸収
適切なテキスト検索を行うため、表現の揺れを辞書を用いて問題に対処する。
同義表現辞書
「パソコンを起動する」、「Windowsを起動する」、「電源を入れる」などの文章は同様の意図を持つと解釈できる。ここでは同義語のみならずフレーズレベルでのものを含む同義表現をグループ化した同義表現辞書を作成し、これを用いて同義表現のマッチングを行う。
また、例えば「メールを読む」という文章には「メール」「読む」の2つのキーワードを含むが、「メール」には「メイル」「Email」が同義語として存在し、「読む」には「読み込む」という同義語が存在する。この場合、「メールを読む」というフレーズを3×2=6通りに展開する。
質問文と回答事例のマッチングを行うには、同義表現辞書を調べてそこに含まれる同義表現グループを抽出し同一グループがあればマッチするものとみなす。回答事例については下記の通り、「使う」「メール」「読む」「メールを読む」という4つの同義表現グループが抽出されている。
上位・下位語辞書
同義表現辞書ではうまく扱えない表現ずれも存在する。例えば、「ブラウザ」⇔「IE6」、「ブラウザ」⇔「IE5」というような表現のずれに対して、「ブラウザ」「IE6「IE5」をすべて同義語として扱うことは困難である。なぜなら、「IE6」の質問については「IE5」の回答を示すのは適切ではないためである。
そこで、上位・下位語辞書を作成し、テキストに現れるキーワードの上位・下位語をキーワードと同様に扱うことによってこの問題に対処する。例えば「IE6」がテキストに現れるならその上位語である「IE」「ブラウザ」もキーワードとして扱い、「IE」がテキストに現れる場合はその上位語「ブラウザ」、下位語「IE5」「IE6」もキーワードとして扱う。ユーザー質問文についてはこの扱いを行わず、「IE5」「IE6」がマッチすることが避けられる。
テキストのスコア計算
文類似度の計算
下記の流れで、ユーザーからの質問文と回答事例の類似度計算を行う。互いに対応する文節（対応度）と係り受け関係の割合（被覆率）を計算し、その積を2文の類似度とする。
- ユーザー質問文の文節A中のキーワードと、文節A'に含まれるキーワードのいずれかが一致する場合、AとA'を対応付ける。
- （対応度）＝（共通して含まれるキーワード数）／（A、A'のうち多い方のキーワード数）
- 例えば、「Windows 98 SE」と「Windows 98」は、「Windows」「98」が共通して含まれるため対応度は2/3と計算できる。一般的には文節は1キーワードのみを含むので対応度は1となる。
- AのキーワードとA'のキーワードの上位語、下位語が一致する場合は、対応度は0.9となる。
- AとA'の否定フラグが一致しない場合は、対応度は一致する場合の0.6倍とする。
ユーザー質問文、テキスト文の被覆率は下記の通り算出される。
（被覆率）＝（文節の対応度の和）＋（係り受け関係の対応度の和）×2／（文節の総数）＋（係り受け関係の総数）×2
ユーザー質問文、テキスト文の両者の被覆率の積を、両者の類似度とする。
例えば、下記の事例を見てみよう。「outlookでメールが壊れた」という質問文が来た場合に、「Outlookにおいて、Internet Mailから受信したメールが壊れる」という回答文との類似度を考える。
この場合、文節の対応度と係り受け関係の対応度はすべて1である。両者の被覆率は1.0、0.54であるので、類似度は0.54となる。
選択肢の絞り込み
テキスト検索モジュールは、3つのテキスト集合（用語集・ヘルプ集・サポート技術情報）ごとに、テキストスコアに基づいてユーザーに提示する選択肢を絞り込む。テキストをスコア順に表示し、閾値を下回るものは対象外とする。
実験
2002年から公開サービスを行っており、ユーザーの質問ログは対話データベースとして蓄積、この評価としては対話セッションの評価、ユーザーとシステムの振る舞いの分析、状況説明文の抽出が適切かどうか、3種類の評価を実施した。
実験結果：対話セッションの評価
無作為に300回のアクセスを選択し、378個の対話セッションを得た。対話セッションあたりの発話ペア回数は平均1.42回であった。評価は、下記のような分類とした。
対話セッションの結果は下記表の通りである。成功の割合は「範囲外」を除いた230対話セッションのうち75%であった。
対話セッションにおいて対話カードが用いられた割合は17%（38/（38+192））であり、大部分は成功と判定されている。また、範囲外の質問についても対話カードでカバーされている範囲においてはほぼ適切に対応できることが確認できた。
対話セッションの失敗の最も大きな要因は、知識ベース、同義表現辞書の不足である。知識ベースの不足とは、ユーザーから問い掛けられるであろう質問を事前に用意できなかったものである。同義表現辞書の不足とは、同様に想定される言い回しの辞書が足らなかったものによる。逆に、自動応答においては事前に想定される内容を周到に用意しておくことが重要になるだろう。
一方で、2002年時点で対話セッションでの76%という結果を得た点については一定の評価が可能であろう。なお、現時点ではダイアログナビは提供されておらず、その進化は確認できない。
参考：大規模テキスト知識ベースに基づく自動質問応答―ダイアログナビ－（自然言語処理）
