目次


IBM Content Analyzer の Rule Editor を使用してセマンティック・ルールを作成する

簡潔な手順でルールを構築しテスト

Comments

IBM Content Analyzer を使用したテキスト解析

意思決定のプロセスには、情報の分析が大変重要です。分析には常に、特定のルールのセットが関係します。構造化 (関係) データと非構造化データ (電子メール、テキスト文書、ボイス・コールなど) のいずれも、このセットに基づいて分析が行われます。正しく有効なルールを編成することは、構造化データおよび非構造化データから目的の情報を抽出する上できわめて重要です。

テキスト解析とは、テキストから意味を抽出するプロセスのことです。テキスト解析は、一連の反復プロセスとしてしばしば実装されます。プロセスは、言語検出、構文解析、トークン化などの単純なものから、表現されている心情を認識するといったより複雑なものまで多岐にわたります。テキスト解析の出力は、図 1に示すように、元のテキストと、そのテキストについて付加されたメタデータから成ります。

図 1. テキスト解析の例
テキスト解析の例
テキスト解析の例

IBM Content Analyzer (前身は IBM OmniFind Analytics Edition) を使用すると、構造化データとともに、非構造化ソースからも抽出した情報を調査、統合、および分析できます。このソフトウェアでは、自然言語解析機能を使用して非構造化コンテンツを処理することで、エンティティー、関係、心情などの該当情報を分類および抽出します。この情報を、関連する構造化データと組み合わせて分析することにより、使用できる情報すべてを活用します。

Content Analyzer の各モジュールの相互関係を図 2に示します。矢印は、データの流れを示します。

図 2. IBM Content Analyzer のアーキテクチャー
IBM Content Analyzer のアーキテクチャー
IBM Content Analyzer のアーキテクチャー

ルールとは

ルールは、IBM Content Analyzer の最も強力なの機能の 1 つです。ルールを使用すると、自然言語で表現可能なほとんどすべての概念をマイニングできます。ルールには、意味と概念を構造化属性に変換する機能があります。

次の例で説明します。 「マンモハン・シン首相がカシミール地方を訪問しました。」

基本的なテキスト解析では、「マンモハン・シン首相」が固有名詞、「訪問」が動作動詞、「カシミール地方」が場所であることがわかります。しかし、ここで表現されていることは、そのことではありません。ここでの要点は、著名なインドの首相であるマンモハン・シン首相が、カシミール地方にいたということです。つまり、「マンモハン・シン首相はどこに行っていたか?」という質問に分析エンジンが答えられるようにするには、マンモハン・シン首相とその所在地との文法的な関係を確立するための辞書ルールが必要です。

ルールの構造

IBM Content Analyzer のすべてのルールは、図 3に示すような構造を持っています。

図 3. ルールの構造
ルールの構造
ルールの構造

ルールは複数のトークンに分割され、それぞれのトークンはさらに複数の制約に分割されます。各トークンが、照合する単一の語 (キーワード) を表し、各制約の値が、照合する特定のトークンのプロパティーを定義します。有効な制約は、以下のとおりです。

  • 文字列 - この制約タイプには、どんな入力文字列でも値として指定できます。
  • Lex - 語の原形を表します。これは、実際の語に対して使用します。
  • 品詞 (POS) - この制約タイプには、特定のドメインまたはアプリケーションについて定義された、値のセットを指定できます。例としては、名詞、動詞、および形容詞があります。
  • 機能 (ftrs) - この制約タイプには、特定のドメインについて許可されている、任意の値のセットを指定できます。これは、より詳細な文法を示すために使用されるもので、品詞制約に入力された値に依存します。
  • カテゴリー - この制約には、カテゴリーツリー内のカテゴリーのセットの値を指定できます。

Rule Editor

Rule Editor は、IBM Content Analyzer によってサポートされる形式でルールの作成と編集を行うために使用される Web アプリケーションです。これらのルールは、後で、文書集合から情報をマイニングするために Text Miner によって使用されます。Rule Editor は、辞書ツリーと結び付けられ、カテゴリツリー内のカテゴリーに関連付けられているルールに対する操作のみをサポートします。

Rule Editor と、Dictionary Editor および Text Miner との関連は図 2 に示されています。

Rule Editor によって、次のことが可能になります。

  • 新規のルールを辞書ツリーの異なるカテゴリーに追加する
  • 特定のカテゴリー内、またはすべてのカテゴリー内のルールを表示する
  • ルールの編集 - ルール名、ルール値を編集し、それらを新規のルールとして保存する
  • トークンの編集 - 制約値を編集し、それらを新規のトークンとして保存する
  • ルールを削除する
  • 参照ビューで各ルールの詳細を表示する
  • ルール名、または制約のタイプと値に基づいてルールを検索する
  • ルールをバックアップおよび復元する
  • ルール・ファイルを .RPF 形式から .PAT 形式に変換する
  • 非構造化テキストの小さなセットを使用してユーザー・インターフェースからルールをテストする

Rule Editor は、Dictionary Editorと結び付けられているため、まず、ブラウザーで次の URL を指定して、Dictionary Editorを開始する必要があります。
http://localhost:9080/TAKMI_DIC/.

Rule Editor は、図 4に示すように、Dictionary Editor に用意されているリンク「ルール編集 (Edit Rules)」からアクセスできます。

図 4. Rule Editor ホーム・ページ
Rule Editor ホーム・ページ
Rule Editor ホーム・ページ

ルールの作成

新規のルール作成における作業の流れを次の図 5のフローチャートに示します。

図 5. 新規のルール作成における作業の流れ
新規のルール作成における作業の流れ
新規のルール作成における作業の流れ

IBM Content Analyzer での正規表現構文

IBM Content Analyzer では、正規表現の照合に Java® の java.util.regex パッケージを使用しています。Java の正規表現処理に加えて、以下のいくつかの演算子も、すべての言語処理に適用されます。

/演算子

/演算子は、Java の正規表現の構文にはありません。これは、ルールに対して Java の正規表現処理を呼び出すようにルール・インタープリターに伝えるために使用します。このため、str="love" は "love" のみとしか一致しませんが、str="/love/" は "love" を含む文字列 ("lover"、"lovely"、"beloved"、"glove"、"loves" など) と一致します。

OR (|) 演算子

ルールを記述する中心となる演算子は、縦棒(|) 演算子で、ブール演算 OR と解釈されます。文字列制約を記述するときには、この制約が、正規表現とは対照的なリテラル制約であると認識することが重要です。つまり、ルールは正規表現インタープリターで解釈されません。さらに、どのインタープリターにもまったく解釈されません。唯一一致するのは、厳密に一覧にあるその言葉のみです。このため、str="(happy) OR (good)" は、"happy" と "good" のいずれかを含む文字列と一致します。

AND (&) 演算子

アンパーサンド文字 (&) もルールで頻繁に使用される演算子で、ブール演算 AND と解釈されます。AND 演算子に含まれるパターンと一致するには、すべての言葉が厳密にテキスト内のものと一致する必要があります。このため、str="(happy) AND (good)" は、"happy" と "good" の両方を含む文字列と一致します。

^ 演算子および $ 演算子

キャレット、つまり曲折アクセント記号 (^) は、行の先頭の文字のみを照合します。ドル記号($) は、行の末尾の文字のみを照合します。次に例を示します。

  • str="/^love/" は "love" に加えて、"love" で始まる文字列 ("lover"、"lovely"、"loves" など) と一致しますが、"beloved" または "glove" とは一致しません。
  • str="/love$/" は "love" に加えて、"love" で終わる文字列 ("glove"、"truelove" など) と一致しますが、"lovely" または "loves" とは一致しません。

単純な使用事例

ルールを作成する前に、まず、ルールを作成する使用事例、ルールによる収集対象のテキスト、ルールを適用する状況などを把握しておく必要があります。ルールを作成する単純な使用事例を考えてみましょう。ルールの構築を段階的に表すために、記事中でこの同じ使用事例を以降も使用します。

ユーザーの苦情から否定的なパターンを見いだすことに関心がある事例を考えてみましょう。ユーザーの苦情は、車に問題があった消費者からのフィードバックです。この苦情は、各文書内の非構造化テキストで構成されています。ユーザーの苦情に含まれる否定的な心情を収集するパターンを特定しようとしています。

  • Brakes designed poorly
  • Engine performs badly
  • Fuel tank leaks excessively

上のパターンを収集するには、最終的に、ルールをリスト 1 のようにする必要があります。

リスト 1. 使用事例ルール
<w id="0" cat=".components"/>	
<w id="1" pos="verb"/>
<w id="2" str="/^((excessively)|(poorly)|(badly)|(hardly))$/"/>

上のルールでは、次のような文字列を見つけることになります。
車のコンポーネントの任意の組み合わせが最初の (0) 位置にあり、次に、任意の動詞が 2 番目の (1) 位置にあり、次に、文字列「excessively」、「poorly」、または「badly」が 3 番目の (2) 位置にあるもの。

ステップ 1: ルールの作成

すべてのルールは、特定のカテゴリー下に定義する必要があるため、Dictionary Editor に用意されている「カテゴリツリー編集」リンクでカテゴリーを既に作成済みであると想定します。新規のルールを作成するには、Rule Editor ホーム・ページに用意されている、ルールを定義するカテゴリーの「ルール追加 (Add a Rule)」リンクをクリックします。

たとえば、Problems カテゴリーに Negative Patterns というカテゴリーを定義済みだとします。リンクをクリックすると、ルール作成のユーザー・インターフェースが新しいウィンドウで開きます。ルール追加のユーザー・インターフェースのスクリーン・ショットを図 6 に示します。

図 6. ルール作成のユーザー・インターフェース
ルール作成のユーザー・インターフェース
ルール作成のユーザー・インターフェース

このインターフェースには、以下をはじめとするいくつかのオプションが用意されています。

  • ルール名 (Rule Name) : ルール名を指定して、ルールの作成を開始します。この名前は、一意にする必要はありません。後で名前に基づいて検索するために使用されます。
  • トークンの編集 : 既存のトークンを編集します。
  • トークンの追加 : 空のトークンを追加するか、既存のトークンをコピーします。
  • 繰り返し (Repeats) : このパラメーターを使用すると、トークンを繰り返すことができる最小回数と最大回数の制限を割り当てることができます。
  • 上に移動 (Move Up) : トークンが表示される順序を変更します。
  • ルール値 (Rule Value) : ルール値を入力してルールの構築を完了します。これは、このルールを呼び出したときに返される値です。ルール値を入力するには、次の2つの方法があります。
    • ルール値を文字列として入力
    • ルール値を対話式に入力
  • ルール保存 (Save Rule) : ルールの作成が完了したときに、ルールを保存します。

リスト 1 にあるようなルールを作成するには、それぞれのトークン値を入力する必要があります。これを行うには、ルール作成のインターフェースの「編集」ボタンをクリックします (図 6を参照)。

ステップ 2: トークンの編集

編集」ボタンをクリックすると、特定のトークンに対して値を入力できるインターフェースが開きます。このインターフェースを使用して、最初のトークンを作成してみましょう。最初のトークン (トークン ID 0) にはカテゴリー制約が含まれるため (リスト 1を参照)、画面上部に用意されている「カテゴリー」ラジオ・ボタンをクリックします。このラジオ・ボタンをクリックしたら、図 7に示すように、ドロップダウン・メニューからいずれかのカテゴリーを選択する必要があります。制約値の記述の終了後、「トークン保存 (Save Token)」ボタンをクリックします。

図 7. カテゴリー制約の記述
カテゴリー制約の記述
カテゴリー制約の記述

注 : 上の例では、Dictionary Editor ホーム・ページの「カテゴリツリー編集」リンクを使用して既にコンポーネント・カテゴリーを作成済みであること、かつ、そのコンポーネント・カテゴリーの下に、「キーワード編集」リンクを使用して engine、brake、clutch、fuel tank などのキーワードを追加していることを想定しています。

次に、2 つめのトークン (トークン ID 1) の作成に進みましょう。新規のトークンを作成するには、まず、ルール作成のインターフェースに用意されている「追加」ボタンを使用してトークンを追加する必要があります。トークンの追加後、「編集」ボタンをクリックしてそのトークンの値を入力します。このトークンには品詞制約が含まれるため (リスト 1を参照)、最初のトークンを作成したのと同様の方法でこのトークンを作成します。「品詞」ラジオ・ボタンをクリックして、その制約値を動詞として入力します。このスクリーン・ショットを図 8に示します。

図 8. 品詞制約の記述
品詞制約の記述
品詞制約の記述

これまでに作成したのと同様の方法で、最後のトークンを作成します。すべてのトークン値を記述したら、最終ステップであるルールの保存に進みましょう。3 つめのトークンのスクリーン・ショットを図 9に示します。

図 9. 文字列制約の記述
文字列制約の記述
文字列制約の記述

ステップ 3: ルールの保存

すべてのトークン値の定義が完了したら、ルール値を定義して、ルールの構築を完了します。ルール値は、パターンを文書に適用した結果を示すものです。ルール値の記述後に、「保存」ボタンをクリックしてルールを保存します。ルール値の記述と保存のスクリーン・ショットを図 10に示します。

図 10. ルール構築のユーザー・インターフェース
ルール構築のユーザー・インターフェース
ルール構築のユーザー・インターフェース

ルールは、作成されると、ルールの定義元のカテゴリーの名前でファイルに保存されます。このルール・ファイルは、.rpf 形式で保存されます。作成されたルール・ファイルを図 11に示します。

図 11. ルール・ファイル (.rpf 形式)
ルール・ファイル (.rpf 形式)
ルール・ファイル (.rpf 形式)

ステップ 4: ルールのテスト

ルールの構築が完了したら、そのルールを実際の入力コーパスに配置する前にテストする必要があります。このために、Rule Editor ホーム・ページに「ルールテスト (Test Rule)」リンクが用意されています。ルールをテストするインターフェースのスクリーン・ショットを図 12に示します。

図 12. ルールテストのインターフェース
ルールテストのインターフェース
ルールテストのインターフェース

ルールの正確性をテストするには、表示されるテキスト・ボックスにサンプル・テキスト (非構造化テキスト) を入力する必要があります。このテキストには、ルールで特定するパターンを含める必要があります。ルールの実行対象であるサンプル・テキストの入力後、ルールの定義元のカテゴリーを選択します。

注 : このサンプル・テキストはインポートすることも、後で使用するために保存することもできます。

必要な入力を完了したら、「テスト」ボタンをクリックして、結果ページに進みます。サンプル・テキストに対するこのルールの処理は、8~10 秒間かかります。処理が終わると、図 13に示す結果ページが開きます。

図 13. ルールのテストの結果インターフェース
ルールのテストの結果インターフェース
ルールのテストの結果インターフェース

ルールの正確性を調べるには、前のページで選択したカテゴリーが結果に表示されているかどうかを調べます。表示されていない場合は、ルールが正しくないと考えられます。サンプル・テキストから希望したパターンを収集できていないためです。結果ページに該当カテゴリーが表示されている場合は、対応するラジオ・ボタンをクリックします。これにより、入力されたサンプル・テキストから収集されたテキストが強調表示されます。

たとえば、上の事例では、結果リストにカテゴリー「Negative Patterns」が表示されています。強調表示された収集済みテキスト (「brakes working poorly」) も表示されています。この収集済みテキストは、ルールで収集する目的のパターンを明確に示します。結果を表示すると、作成したルールが意味的に正しく、目的の結果を取得していることがわかります。実際の入力データ・セットに対してこの自然言語プロセッサーを実行することで、このルールをリアルタイムの状況に配置する準備ができました。

ルールのバックアップと復元

Rule Editor には、ルールのバックアップと復元の強力な機能があります。すべてのルールをいつでもバックアップでき、別のときにいつでも復元できます。この仕組みを次に示します。

バックアップ時に、すべてのルール・ファイルはハード・ディスク上の1つのフォルダーに格納されます。「ルール・バックアップ (Backup Rules)」リンクは、Rule Editor ホーム・ページに用意されています。このリンクをクリックすると、ルール・ファイルのバックアップ先のフォルダー名を入力するように求められます。このポップアップ・ウィンドウのスクリーン・ショットを図 14に示します。

図 14. ルールのバックアップ・ウィンドウ
ルールのバックアップ・ウィンドウ
ルールのバックアップ・ウィンドウ

バックアップされるルール・ファイルは、次のパスによって指定されるディレクトリー構造内に格納されます。
%TAKMI_HOME%/databases/database_name/pattern/backup/rule-files-folder-name。 ここで、%TAKMI_HOME% は IBM Content Analyzer がインストールされているパスです。

バックアップ・フォルダー内のフォルダー名は、次の 2つの部分から成ります。

  • フォルダー名の前半は、Rule Editor ウィンドウで入力したのと同じ名前です。
  • フォルダー名の後半は、タイム・スタンプです。タイム・スタンプは、yyyymmdd 形式のシステム日付と hhmm 形式のシステム時刻を連結したものです。

すべてのルール・ファイルが格納されるフォルダーの完全な名前は、この 2つの部分の組み合わせで構成されています。たとえば、フォルダー名 NewFolder.20080409_2137 では、指定したフォルダー名に、システムの日付と時刻が付加されています。これにより、名前だけではなく、日時によってもさまざまなバックアップ状態を識別しやすくなります。

復元機能も、バックアップ機能と同様の方法で機能します。復元機能を図 15に示します。

図 15. ルールの復元ウィンドウ
ルールの復元ウィンドウ
ルールの復元ウィンドウ

ルール復元 (Restore Rules)」リンクも、Rule Editor ホーム・ページに用意されています。このポップアップ・ウィンドウには、ファイルが格納されているすべてのフォルダー名の一覧が表示されます。また、ルール・ファイルが配置されている場所のパスも表示されます。

まとめ

この記事では、IBM Content Analyzer のテキスト解析機能について記述しました。ルールの強力な機能と非構造化データから意味と概念を抽出するのに役立てる方法を説明しました。次に、IBM Content Analyzer の Rule Editor とそこで使用されるルール構文を紹介しました。さらに、Rule Editor アプリケーションを使用して、段階的にルールを作成しテストする方法を示しました。最後に、このアプリケーションに用意されているバックアップと復元の機能について説明しました。

この記事は、Rule Editor アプリケーションを使用してルールを作成する上で有利な第一歩になります。ただし、それぞれのデータ・セットにどのルールを構成するか、またどのように構成するかを決定するのは難しいことです。上達する唯一の方法は、実際に取り掛かり、考え始めることです。この記事では、非構造化データから情報を最大限に抽出するために、正確で意味のあるルールを記述する正しい方法を説明しています。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=405579
ArticleTitle=IBM Content Analyzer の Rule Editor を使用してセマンティック・ルールを作成する
publish-date=09252008