[エンタープライズ・システムのためのWeb 2.0]

2007年10月2日(火)ファストサーチ＆トランスファ

技術的背景：検索機能に特化したアルゴリズムとパフォーマンス

エンタープライズ2.0は、サーチプラットフォームで非常に戦略的に統合しており、それによって、企業とシステムの全体を管理するというケースが登場し始めている。その1つの基本的な背景というのは、次の1枚の図が表現している。

これはサーチから少し外れるが、RDBをベースとした30種類くらいのSQLのベンチマークである。横軸がレスポンスタイム、縦軸が頻度となる。ブルーが通常のRDBのレスポンスタイムで、オプティマイズされると4割くらいのものは16分の1秒以内に収まっている。横軸で見ると分かりやすいが、複雑なクエリが入ってしまうと、20秒、30秒になってしまう。これがRDBの特徴である。

図　検索機能に特化したアルゴリズムとパフォーマンス

それに対して、この事例ではFASTのオレンジの部分の100パーセントが4分の1秒以内に収まっている。これはどういうことがというと、RDBのような更新系のシステムでは、ロックメカニズムを避けて通れない。データのインテグリティを保たなければならないため、ありとあらゆるところでロックをかけなくてはならない。ある意味、SQL DBの制約は、この点にあるといえる。

検索というのは、基本的にはリードーオンリーである。つまりロックというボトルネックが外れて、オプティマイズされた結果、サーチによるハイパー パフォーマンスメカニズムを生むことができる。コロンブスの卵ではないが、更新系と参照系を明確に分けるというのは、非常に有利な事例となる。

日本では、リクルートが非常に大きな現業部門でリードオンリー系をサーチに変えたことによってRDBのワークロードが40％程度減少し、パフォーマンスが2倍にもなったという事例がある。

すでにこうした事例が出始めている時代になっている。そして次の段階として、メリルリンチなどの大手の金融機関は、基幹系システムを含めて、サーチプラットフォームで、システムの再構築を始めているのだ。

サーチ：基本的構成要素

エンタープライズ2.0、ウェブ2.0といったときに考える検索は、コンポーネント的に考えると、3つぐらいしかない。情報の取り込み、情報を選択、そして利用頻度だ、リアルタイムで情報を取り込み、その場で登録するという極端な例から、マンスリーな情報を取り込んでいくものもある。ニュース系だったら、検索対象をどこまでとってくるのかと、情報の取り込み方もさまざまだ。コンテンツ リファイメント パイプラインと書かれた、図の左側の「検索対象」からまとめて情報を得る。その構造化データと自然言語的なデータ、マルチメディア的なデータを共通の軸でどのように統合していくのか、ここが重要なポイントになっている（後述）。

図　検索の基本構成要素

複数の企業をM＆Aした結果、3つも4つも分散しているCRMのシステムを統合するというのも、実はここのコンテンツ リファインメントを含めて統合していく。図の右側における検索サイドは、基本的にはクエリープロセッシング（質問を投げかける側）である。集めた検索をどのように見るのかというのが、重要なテーマとなる。

質問する側は当然、個人によっても部門によっても異なったものとなる。パーソナライゼーションとは、過去にこういう事例があったから、「この人はこういうことを知りたいだろう」というところまで絞り込んでいくことだ。具体例でいうと、カタカナで「オート」と書くと、人によっては半角だったり、全角だったり、それぞれだが、最低限「オート」とやれば、「車」にまつわるすべてのことが出てくる。あるいは「自動車」というキーワードでも情報を引き出すことができる。もう１つ「付加価値」をつけると、ファイナンシャルタイムス系などがそうだが、「オート」と入れた途端にホンダからGM、クライスラー、自動車業界の情報がまとめて引っ張ってくることができる。クエリープロセッシングのところも、非常に付加価値が出てくる商品なのだ。

最終的には右下にあるリザルトプロセッシングで、検索結果を顧客に渡すときに、企業や個人にとって大事なものから優先的に表示する。こういったロジックを明確にして、情報を提供する側が明確な方針を持たなければならない。決してブラックボックス的なものではなく、企業の基本思想を反映したものが、リザルトプロセッシングとして重要になる。eコマースの現場では、この検索結果１つで、利益率が違ってくることにもなる。

構造化・非構造化データの統合：パイプライン

構造化・非構造化という課題、つまりどうやって数値データなのか、ワープロのデータなのかブログのデータであるのかを見分け、統合化を図るのかということは、サーチの重要な課題だ。この事例では、データを取り込んだ段階でいろいろなランゲージディテクション（Language Detection）を行っている。

図　構造化・非構造化データの統合

先進的なユーザーでは、日本語の検索と英語の検索を、取り込んだ段階で翻訳して一緒にしてしまう。ランゲージディテクションの一番の本質的なものが、右下にある自然言語である。パリのロイター発の事例なのだが、文章の中でオレンジやピンクになっている文字がいわゆるエンティティ ディストラクション、5W1Hの中のWの部分を意味しており、WhoとかWhenのことである。「いつ、どこで、誰が、何をした」的なものが、人名なのか、地名なのか、製品名なのか、金額なのか、ここの段階で分解して、抽出している。抽出したデータが人名だと分かった段階で、顧客ファイルとリンクして、統合したものを出力する。これも辞書やモルフォロジー（Morphology）を使ったやり方などいろいろなアルゴリズムがあるが、企業独自にアルゴリズムをカスタマイズして使う場合もある。

最終的には、顧客がコールセンターで話している声をテキストに落として、顧客名、製品名、クレーム内容などを１つのクラスターという形で統合し、これを基に検索しているという事例もある。