IBM Watson DiscoveryはAI技術を活用した検索エンジンと位置付けられています。

IBM Watson™ Discovery is an AI-powered search engine that helps you to extract answers from complex business documents.
https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-about

AIの定義は色々とあるかと思いますが、この記事ではデータの特徴を元に振る舞いを変えるシステムや機能くらいとします。IBM Watson Discoveryが提供するAI技術を活用した機能は多々あります。例として以下のようなものを挙げますが、これ以外にも色々な機能が存在します。

名前	説明	リンク
Relevancy Training	検索結果のランキングを調整	https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-train
Document Classifier	文書を分類	https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-domain-classifier
Smart Document Understanding	見出しや表などの文章の構成要素を分類	https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-configuring-fields
Entity Extractor	文書から情報を抽出	https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-entity-extractor

この記事では検索結果のランキングを調整するRelevancy Trainingに注目して、Watson Discoveryが何を学習しているのかを「外から」紐解いていきたいと思います。

ドキュメントの説明

いきなり答えを示してしまいますが、ドキュメントには以下のように書いてあります。

When you teach Discovery with examples, the service figures out for you how much weight to give to each field.
Discovery builds a model that assigns different weights to term, bigram, and skip-gram matches for each of the root-level fields and balances them against matches from all of the other document fields. With enough examples, Discovery can return better answers because it knows where the best answers are typically stored.

(太字は筆者によるもの)

どのフィールドの、どのようなヒットの仕方を重要視すればユーザーの好みに合うランキングになるかを学習しているようです。とは言えども、なかなか分かりづらいので少し紐解いて見ていきます。

Discovery Query LanguageとNatural Language Query

Watson Discoveryで文書を検索するにはDiscovery Query Language(DQL)か、Natural Language Query(NLQ)を使います。

DQLはいわゆる検索構文でありORやANDなどのブーリアン演算子や、スコアに影響するスコア乗算演算子などをサポートしています。検索条件を柔軟に指定することが出来ますが、探し求めている情報を取得するためには、その要望を適切にDQLに変換する必要があります。言うなればユーザーがシステムに合わせる必要があり、どのように検索要望を検索構文に変換するかはユーザーのスキルに寄るところが大きくなります。適切なDQLを構築することが出来れば、本当に入手したい情報を含む文書は上位にランキングされます。実際の業務アプリでは、フィールドごとにテキストボックスを用意するなどのUIの工夫によって、エンドユーザーが自身でDQLを構築するための負担を減らすことが考えられます。

一方で、NLQは自然言語クエリとも訳され、名前通りに我々人間が普段使っている言葉で検索することができます。検索の要望をDQLに変換する必要はないので、どの様に検索演算子を使いこなすなどのスキルはユーザーに求められません。その代わり、検索要望に対して適切なランキングで文書を返すように、システムを人間に合わせて構成する必要があります。そして、その一つの機能がRelevancy Trainingになります。

（補足）フィールドとは

Watson Discoveryは文書をフィールドの集合として扱います。フィールドは名前と値のペアになります。例えば、後半に使うワクチン接種証明アプリFAQのデータを読み込むと、以下のようなデータが１文書として検索索引に入ります。

フィールドの名前	値
id	1
catetogy	1_接種証明書アプリについて
title	接種証明書アプリはいつから利用できますか
text	本アプリの提供開始日は2021年12月20日です。
date	2022年1月21日

また、値はさらに下位のフィールド群をもちえて、それをNested Fieldと呼びます。Nested FieldはRelevancy Trainingには使われないとドキュメントにはありました。

(補足)NLQを使う場面

検索要望を検索構文に変換すること自体を避けたい場面も多々あります。例えば、コールセンターのエージェントはお客さまの質問に回答するために社内の情報を検索するとします。エージェントがいちいち検索構文を考えて検索するよりも、会話を逐次、テキストに変換してそのままNLQとして検索していくシステムの方が効率的になります。

Relevancy Training

再び、ドキュメントの抜粋を見てみます。

Discovery builds a model that assigns different weights to term, bigram, and skip-gram matches for each of the root-level fields and balances them against matches from all of the other document fields. With enough examples, Discovery can return better answers because it knows where the best answers are typically stored.

先ほどの記述を少し言い換えると、Relevancy Trainingは、NLQを幾つかのパターンで解釈し、各パターンでどのフィールドにヒットしたのかを特徴として、それに重みを掛けるモデルを作ります。

Term, bigram, skip-gramの詳細はドキュメントには書いてはいないのですが、NLQを検索構文に変換するための手法と考えて良いかと思います。
例えば「接種証明書は無料ですか」というNLQが「接種 OR 証明書 OR 無料」とバラバラのキーワードに分割してORで結ばれた検索クエリに変換されたり、「“接種証明書” OR 無料」と近傍のキーワードはフレーズでまとめてからORで結ばれた検索クエリに変換されたり、などです。なお、これらは説明のための例なので実装とは異なる可能性があることはご了承ください。さらにmatches for each of the root-level fieldsとあるので、それぞれのパターン（Term, bigram, skip-gram）でフィールドでヒットしたのかを特徴量としています。例としてまとめると、3種類のクエリの変換方法があり、フィールドが5個あるとすると、少なくとも15個の特徴量が算出されることになります。

これがモデル作成のための入力、すなわち学習している内容となります。もっとも、ドキュメントから読み取れるのは以上であり、その他の特徴をつかっている可能性はあります。

さらに想像しやすい様に作成されたモデルの挙動をナラティブに書くならば、「NLQをバラバラのキーワードに分割してORで結んで検索した際、それがField Aでヒットする文書は、それがField Bでヒットする文書よりはランキングの上位に来るように重みをつける。さらにはNLQをすこしフレーズでも検索して、それがField Aでヒットする文書は、それがField Bでヒットする文書よりはランキングの上位に来るように重みをつける（以下組み合わせになり略）」などとなるかと思います。

Relevancy Trainingを試してみた

ついでに、実データをつかってRelevancy Trainingによってランキングが変化するところをみていきます。

今回はデジタル庁がオープンデータとして提供しているワクチン接種証明アプリのFAQデータを使用しました。
https://www.digital.go.jp/policies/vaccinecert_faq/

上記のサイトからダウンロードしてきたCSVに、以下のようなヘッダー行を追加して、プロジェクトを作成します。

さらに、ストップワードも設定しました。
https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-stopwords

Relevancy Trainingを行なっていない状態で「海外で受けた接種の証明はできますか」と検索すると、このような検索結果になります。全てのフィールドが等しく扱われるので、ランキングの1番目にはbodyでキーワードがヒットした文書が来ていますが、ランキングの３番目にある文書のtitleフィールドは入力したNLQに近いので、検索の意図としてはこの3番目の文書が一番合っているようです。したがって、この３番目の文書が１番目にランキングされると、より望ましい検索システムになりそうです。

そこで、titleフィールドでヒットしたときにランキングの上位に来るようにトレーニングをしていきます。トレーニングは管理ツールの画面からもAPI経由からでもできます。画面からは、NLQを入力し、それで検索されてきた文書がそのNLQと関連している（Relevant）か、関連していない(Not relevant)か、を選択していきます。

すこし恣意的ですが、FAQのタイトルに類似した文をクエリの例と入力して、それがtitleフィールドでヒットした文書はRelevantを、textフィールドでヒットした文書はNot Relevantを選択してトレーニングデータを作成していきました。そうすることで、titleフィールドでヒットしたときにランキングの上位になるように重みを学習してくれることを期待しています。

十分なトレーニングデータが入力されると、トレーニング（学習）が始まります。

モデルが無事に作成された後に、先ほどのNLQで検索してみると、期待通りタイトルでヒットした文書が上位の結果になっていることが確認できました。

この例だとユーザーは私だけなのと文書の数が少ないので、ランキング調整の恩恵は少なく見えます。一方で、数百人数千人が1日に何回も検索するシステムを考えると、適切なランキングで返すことが組織全体の大きな時間の節約になります。

さらに上記の例はtitleフィールドでのヒットを重視するようRelevancy Trainingを構成しました。これは説明を簡単にするために、かなり単純化していることをご理解ください。特にNLQがどのように解釈されて、どのように挙動に影響を与えているかは外からは確認が難しいので触れていません。

(補足)検索漏れがある場合

Relevancy Trainingは検索された文書のランキングを調整するものになります。検索漏れなどには同義語辞書やファセットなどで対処する必要があります。

おわりに

Watson Discoveryのドキュメントは日々、更新がされているようでRelevancy Trainingの項もリリース当初よりも詳しく書かれています。実例とともに、ご紹介する目的でこの記事を書きました。お役に立てば嬉しいです。

お断り

このサイトの掲載内容は私自身の見解であり、必ずしも所属会社の立場、戦略、意見を代表するものではありません。記事は執筆時点の情報を元に書いているため、必ずしも最新情報であるとはかぎりません。記事の内容の正確性には責任を負いません。自己責任で実行してください。