1. はじめに
前回までの連載で作成したレストラン検索では、条件にジャンル「イタリアン」を指定するにはユーザーは一字一句間違えずに語を入力する必要がありました。これではコマンド入力と変わらず、自然言語対話の特徴である「ユーザーが自由に操作できる環境」にほど遠いと言えます。
「イタめし」「イタリア料理」等でも「イタリアン」を指定できるようになればもっと自由度が上がるのですが、単純にジャンルの要素としてこれらの語を追加するだけでは、データベースの情報と一致しないため、認識はできても検索の条件としては使えません。
このような問題を解決するのがAnswers Anywhereのシノニム（同義語）の機能です。シノニムを使うことでエージェント・ネットワークの語彙を増やし、ユーザーに表現の自由を与えます。
またシノニムをうまく使うことで、語彙の開発生産性や管理性の向上にも役立てることができます。記事の後半ではその点についても触れたいと思います。
2. シノニム（同義語）とは
エージェント・ネットワークはエージェントに定義された語（KeywordプロパティやFileプロパティに記述した語など）をもとにユーザー入力を認識します。シノニムとはこの語に対する同義語のことです。例えば「イタリアン」という語（この語をターゲットと呼びます）に対して「イタめし」というシノニムを与えると、エージェント・ネットワークはユーザーの入力「イタめし」は「イタリアン」と同義であると解釈します。
図1にエージェントでのシノニムの動作概要を示します。エージェントにシノニム辞書ファイルが設定されていない状態では、入力にターゲットが含まれているかどうかを調べ、含まれていればクレームを出す、含まれていないならば出さないといった動きをします。
一方、シノニム辞書ファイルが設定されている場合は、ターゲットが入力に含まれるかどうか、ターゲットのシノニムが辞書に存在しないかも調べます。存在するのであればクレームをし、ターゲットをエージェントの出力とします（注1）。
厳密にはポリシーのアクション節で*.targetと記述されている場合はターゲット（図では「イタリアン」）、*.matchedと記述されている場合はマッチした入力語を出力します（図では「イタめし」）。field.templateの既定動作は前者を出力するように設定されています。
3. シノニム辞書ファイルの書式
エージェントはシノニム辞書ファイルを1つ持つことができます。シノニム辞書ファイルの中にはそのエージェントの中で参照するかどうかにかかわらず複数のターゲットを含めることができます。その書式をリスト1に示します。{targetN}にはターゲットを記述し、{wordNn}にはそれに対するシノニムを記述します。
{target1}: {word11},{word12},...
{target2}: {word21},{word22},...
{target3}: {word31},{word32},...
:
リスト2に記述例を示します。この定義により入力「イタめし」や「イタリア料理」が「イタリアン」と同義であると解釈され、「中国料理」は語「中華」と同義であると解釈されるようになります。
イタリアン: イタめし,イタリア料理 中華: 中国料理
4. シノニムの設定
シノニムファイルを設定するには設定したいエージェントをダブルクリックし、エージェントエディタを開きます。［Synonym Table］タブをクリックすると、このエージェントに設定されているシノニム辞書ファイルの内容が表示されます。
［New］を押し、このエージェントに新規のシノニム辞書ファイルを設定することにします。ターゲットとそれに対するシノニムを記述し最後に［Save As］を押します。ファイル保存のダイアログが表示されるので表示内容の保存先となるファイル名を入力し［OK］を押します。一連の流れを図2～図5に示します。
5. シノニムの使用例
連載で作成しているレストラン検索サンプルでは、現状ではジャンルはgenre.txtに定義した語しか認識ができません。そこでシノニムを利用してユーザーのジャンルの言い回しの自由度を上げてみましょう。また、語「有名」に星の数が多いという意味を持たせると「新宿の有名レストラン」のような問い合わせに対し「新宿の3つ星レストラン」を提示します。こうすると有名店を探したいというユーザーの要望に答えられそうです。このような意味づけもシノニムを使うことで可能となります。
上記を実現するために必要なシノニム設定の内容を表1に示します。前節の手順に従い設定を行います。
| エージェント | シノニム辞書の内容 | ファイル名 |
| ジャンル | イタリアン: イタめし,イタリア料理 | genre.synonym |
| 中華: 中国料理 | ||
| 星 | 3: 有名 | stars.synonym |
シノニムを追加したレストラン検索を実行してみます。Interaction Consoleより「新宿の有名なイタめし」と入力すると「ジャンル=イタリアン AND 星=3」の条件でレストランが1件検索されました（図6）。シノニムが想定どおり動作しています。
シノニムが解釈された様子は解析結果のデバッグツールであるClaim Viewerでも確認できます。
メニューの［View］-［Claim Viewer］を選択してClaim Viewerを開くと、入力した質問に対する、個々のエージェントの解析結果が階層表示されます（図7）。エージェント名が太字で書かれている部分をクリックして展開するとそのエージェントの出力したクレームが表示されます。その中の「Input claimed」にはクレーム対象となった入力語、「Pattern matched」にはターゲットの語が表示されます。
ジャンルのエージェントを見るとシノニムとして設定した「イタめし」が「イタリアン」として認識され、星のエージェントでは「有名」は「3」と同義として認識されています。
6. シノニム辞書ファイルの管理方法
シノニム辞書ファイルは複数のターゲットのシノニムを定義して複数のエージェントで共有することができます。これを活用し辞書の構築の生産性やメンテナンス性を向上することができます。
小規模なエージェントネットワークの場合は、エージェントごとにシノニム辞書を定義し分散させるよりも、図8に示すように1つのエージェント・ネットワークには1つのシノニム辞書ファイルを割り当てるとよいでしょう。またエージェントのキーワードなどのターゲットにも語そのものではなくエージェント名などを使い語はすべてシノニムとします。こうすることで次のような利点が得られます。
- エージェント・ネットワークの構造と辞書が分離できるため分業開発が可能
- 語彙が各エージェントに分散せず一箇所で管理できるためメンテナンス性が良い
- 辞書ファイルの交換により語彙が一括で入れ替えられるため他国の言語に対応させるのが容易
一方で大規模な場合についてですが、その多くは図9のように小～中規模のエージェント・ネットワークが横方向に結合した場合であると考えられます。例としてはレストラン検索とホテル検索をくっつけて1つの検索アプリケーションとしたような場合が考えられます。この場合はエージェント・ネットワークの部分ごとにシノニム辞書を構築し個々の部分ごとで管理を行う方が、作業が分業しやすいなどの利点があります。メンテナンスに関しても同様に独立して実施できるため、同じターゲットがあったとしても（図9の「target3」）、そのターゲットに対する一方のシノニム修正はもう片方には影響しません（注2）。
評価版SDKで使用できるシノニム辞書の形式はファイルのみですが、データベースでシノニム辞書を管理するためのプラグインも製品のオプションとして提供しています。メンテナンスはSDKではなくWebの管理画面にて行うような方式となっています。
7. おわりに
シノニムを使うことでユーザーの自由度が増え利便性を与えられることが理解していただけたのではないかと思います。それだけでなく開発者やシステム管理者にも語彙の実装や管理という面で利用する価値がある機能であると思います。
次回は、データベースに格納された語を辞書としてエージェント・ネットワークで利用できる「データ連携機能」について紹介する予定です。既存システムのマスタデータなどをそのまま辞書として利用でき、動的な値の変更にも対応する、他の対話エンジンとは一線を画する機能です。
