グループ指向 WWW 検索アシスタント PA-search の実現

グループの情報検索支援を目的としたWWW検索システム, PA-search (Prospect accumulated search)を実現した。 ユーザグループがアクセスした情報を検索母集合とし、 検索結果に情報の利用履歴を表示する事で、 シンプルな構造で高品質な検索支援をめざした点が特徴である。 著者らが日常的に利用している小規模なプロキシサーバのログから 検索母集合を構成して実験した結果、著者らの検索需要のうち およそ2割を支援することができた。

PA-search: Prospect accumulated WWW-search assistant

This paper describes imprementation of WWW search system to meet information needs of workgroups. This system indexes all resources accessed by a workgroup as prospective good information, and accumulates 'search and retrieved' flag as a recommendation signal from group member. Using access-log of workgroup proxy server, experimental result showed that about 20% of information needs of the workgroup was successfully assisted.

1. はじめに

これら汎用サービスは概してうまく機能しているが、 改善すべき点も多く残されている。 例えばディレクトリサービスを効率的に利用するには分類項目についての 十分な理解が前提となるが、 目的の情報が見つからなかった場合、システムがその情報を持っていないのか、 別の分類項目にあるのかが不明である。このため可能性として考えられる 複数の分類項目を確認しなくてはならなくなる。 またテキスト検索サービスの利用には、求める情報の持つ属性 (キーワードなど)についての正確な知識が必要であるうえ、 様々な検索オプションを理解し使いこなすのは難しい。

また、両者に共通する問題点として、 規模が巨大化するにつれてサービスの維持運営に多大なコストがかかるようになる事が挙げられる。

そこで、情報検索システムを利用するユーザの行動に注目し、 検索対象となる母集合をあらかじめ絞り込む手法について検討する。 ソーシャルフィルタリング[2]や 協調フィルタリング[3]、 様々な推薦システム[4]と同様の手法を用いて なるべく質の高い情報を検索母集合とし、 適合率の高いシステムの構築をめざす。

本稿では、WWWのアクセス履歴から検索母集合を構築し、3ヵ月に 渡って運営したプロトタイプシステムについて報告する。 以下2章では既存サービスの現状と課題を指摘し、 3章で我々が構築しようとしているシステム(グループ指向検索アシスタント) のイメージと試作したシステム(PA-search...Prospect Accumulated search assistant) の実装について述べる。 4章で実際の利用データから評価を試み、5章で問題点と今後の展望を述べる。

2. WWW検索の現状と課題

2.1 情報検索におけるユーザ意図

1. 確認を求める要求(Verificative need)
   ユーザは求める情報の内容を良く理解しており、 情報の細部や記憶の不完全な部分などを確認しようとする。

2. 意識的なトピックの要求(Conscious topical need)
   ユーザは求める情報のトピックについてはっきりした意識を持ち、 そのトピックに属する情報を閲覧しようとする。

3. 雑然としたトピックの要求(Muddled topical need)
   ユーザは自分がどのような情報を欲しているのかはっきり意識していないが、 何か興味をひきそうなトピックを探したり、 自分の要求が明らかになるような情報を探している。

WWW 上の情報を対象とする検索システムでは、 検索対象となる情報が頻繁に更新されるという点で、 従来システムとは異なった特徴をもつ。 しかし情報を検索する際のユーザ意図は、 従来システムの場合とWWWを対象としたシステムの場合で、大きな違いは ないと思われる。以下、本論文ではWWW検索システムが支援すべき検索需要の 類型として、上記を用いる。

2.2 WWW情報検索の現状

ディレクトリサービス(yahoo [6] など)

情報が階層的に分類されており、 検索キーワードを入力しなくても階層を降りていくだけで質の揃った情報に 到達できる。 類型3の雑然としたトピックの要求に適している。一方、 良質な情報を収集するため人手によるフィルタリングが施されており、 類型1や類型2で求める情報が含まれない可能性がある。また、 階層化の方針はディレクトリサービスによって様々であり、 自分の求める情報がどの階層にあるかを見つけるまでに 試行錯誤が必要である事が多い。

テキスト検索サービス(goo [7]など)

WWWロボットを用いて網羅的に情報を集めてあり、キーワードや日付、 データタイプなど様々な検索オプションを駆使して情報検索を行う。 類型2の意識的トピックの要求に適しているほか、 ディレクトリスタイルを採り入れ、類型3の支援を狙ったものも 増えてきている(Infoseek [8]など)。 しかし、求める情報を他から選り分けるためには検索条件をうまく指定する必要があり、 通常何度かの検索再試行を伴う。これは類型1の確認を求める要求を 満たそうとする場合も同様である。

2.3 WWW情報検索の課題

類型1に対する支援

従来システムでは、既に良く知っている情報の細かい点を確認したい場合、 類型2の場合と同様の戦術を用いて再度、情報の海に挑まなければならない。

現状、類型1の要求を満たすための努力は個人に任されている。 WWWブラウザのヒストリ機能 (ブックマーク、お気に入り情報) を使うのが一般的だが、URLを集めた HTML ファイル (リンク集) をローカルに用意したり、 URLを登録して自動巡回や更新検出が可能な補助アプリケーションを用いたり、 情報をローカルに転送して個人DBを構築したり、といった努力がなされている。

しかしこうした手法で整理できる情報の規模には上限がある。 数が多くなってくると、ローカルなデータの管理コストが大きくなり、 汎用サービスで探し直すのと手間があまり変わらない場合が出てくる。

情報を捜し出す労力の軽減

前章でも述べたが、既存の検索サービスの多くはデータ量が非常に多いため、 目的の情報を得るまでに検索結果を閲覧し、検索条件を調整して再検索し、 といった試行を何度か繰り返すのが普通である。

例えば、著者らの検索行動をHTTPプロキシサーバから抜きだして見ると、 1セッションあたり平均3.2回の検索を行い、 5.3回の閲覧(検索結果から元データを閲覧しに行く)を経ている。 ここでセッションとは、 最初の検索語を入力してから最後の閲覧先にジャンプするまでの過程である。 1セッションの平均持続時間は 10分7秒であり、 相当な知的労力を払っている事が伺える。 こうした結果得た情報を後でもう一度見たいと思った時に、 再度同じ労力を費すのは効率が悪い。

情報を捜し出した戦略の共有、再利用

例えば情報探索について書かれた文献 [9] を読んで 有名な錯視図形である「ルービンの壷」を探そうと思った場合、 goo や Infoseek では「ルービンの壷」というキーワードでは検索に失敗する。 「ルビンの壷」で始めて幾つかの情報が現われるが、 実際に画像が含まれる情報は goo には存在せず、 Infoseek でないと出てこない (しかもこの情報には「ルビンの図形」という言葉が使われていた)。 このようなキーワードの調整や、 使用する検索サービスの選択といった戦略は個人の経験として残るが、 再び同じ記事を思い出して同じ情報を探したくなった時に、 思い出せるとは限らない。

3. グループ指向検索アシスタント

ワークグループでは、 メンバが異なるタイミングで同種の情報にアクセスしたり、 同じ目的を持って情報を探索する事が多い。 このため一人一人が行った検索処理を蓄積し、 共有することでグループ全体として高品質な情報支援が 期待できる。

メンバが普段アクセスしている情報や、検索に用いたキーワード、 検索中に閲覧した情報を自動的に蓄積しインデクシングを行う事で、 メンバの知的活動が自然に保存され、 メンバが必要と判断した情報が検索可能な形で充実していく。 グループのメンバは自分が過去に見て忘れている情報を確認す ることが容易にできる(=類型1の支援)だけでなく、 他のメンバがアクセスしたり、検索して探してきた情報にも容易に触れる事が できる(=検索処理の共有、再利用)。また検索母集合が比較的小さい為、 検索再試行の回数も少なく済む(=検索労力の軽減)。

このようなシステムは単に情報検索サーバとして有用なだけでなく、 グループで蓄積した情報に基づき、特定のトピックに関する情報を 自律的に収集/維持するシステムに発展する可能性を持つ。 グループメンバの興味領域が専門化している場合、その分野に 関する良質な情報が自然に収集され検索可能になることから、 グループメンバ以外の利用者にとっても有用な情報検索システム となることが期待できる。

我々はこの発展形をグループ指向検索アシスタントと名付け、 開発目標とした。ここでは、「あるワークグループに属する ユーザ行動を蓄積し解析することで、グループ全体の情報検索 コストを低減する為の支援機能を提供するエージェント」を グループ指向検索アシスタントと定義する。

3.1 情報活動の捕捉

• ユーザがアクセスした事のある情報や、目にした事のある情報の収集。
  ブックマークを入力したり、HTTPプロキシサーバのログからURLを取り出す。 これは類型1の確認を求める情報要求を直接支援するのが狙いである。

• ユーザが用いた検索語と辿ったリンクの組
  シンプルで品質の良い処理が可能な情報で、関連語作成にも用いられる ([10])。ここでは関連語辞書の作成よりも リンクが辿られたという情報に注目し、類型1の支援を行う。

プロキシサーバのログを用いる手法は、ユーザに与える負荷が ブラウザの設定だけであり、透過性に優れ、手軽である。

処理対象としたのは著者らが日頃利用している小規模なHTTPプロキシサーバ (ユーザ3名,Squid[11]利用)である。 平日の一日に1000から4000件のHTTPリクエストがあり、 このうち30%程度が文字情報(text/html, text/plain)である。

参考のため、対象プロキシサーバのアクセス傾向を表1に示す。 1997年5月から7月の3ヵ月間のアクセスのうち、ユニークな URL数、2回以上の アクセスのあったURL数、ユニークなホスト数、2回以上のアクセスのあった ホスト数を挙げている。

3.2 試作システムの実装方針

1. HTTPプロキシのログを蓄積し検索可能にするだけでなく、 汎用の検索サービスの検索結果も併用する。
2. 検索結果のうち、リンクをたどった事がある情報を強調表示する。

1は、本システムで支援しようとしている 「確認を求める要求」以外の検索要求に応えるための処置である。 全体の情報要求のうち、確認を求める要求が何割を占めるのかは個人依存であるし、 検索時の意図をユーザが自己判断してシステムを使い分けるようでは負担が大きすぎるため、 この機能は必須である。基本的に、 ローカルに蓄積した情報が少ない時や、 まったく情報がなかった場合に補う形で併用する。

これによりサービスの立上り時や、 これまでとは全く違った領域の情報を必要とするような場合、 「検索結果無し」となってユーザ離れの原因となるのを防ぐ。

2は、本システムが 「確認を求める要求」に対して支援をしている事を強調する意味がある。 「一度見た事のある」情報をはっきり表示する事で、 その情報へのアクセスが容易になる。また、 自分に覚えがない情報であっても「他の誰かが見た」 というサインが示される事で興味を喚起する効果もある。

以上の検討を踏まえ、グループ向けWWW検索システム PA-search を実装した。 PA-search のユーザ画面を図1に、検索結果画面を図2に示す。 図1からわかるように、ローカルな集合の他に Infoseek などを併用しており、 ユーザがどのサービスを併用するか指定する事も可能である(方針1)。 また図2に示した結果のうち、顔のようなアイコンが 「以前にクリックしてリンクをたどった事がある」ことを示している(方針2)。

図1. PA-search ユーザ画面

図2. PA-search 検索結果

3.3 構造

図3. PA-search の構造

大きく分けて以下の4つの部分にわかれており、 試作システムは Perl で 1500行程度となった。

• CGI 処理部
  ユーザからのキーワード入力、検索条件を処理する検索処理部(I)と、 ユーザの検索結果クリックからキーワード-URL組とアクセス履歴を 保存するフィードバック部(II)にわかれている。フィードバック部については [10]の手法によった。
• 外部検索サービス処理部
  それぞれの外部サービスに合わせて問い合わせを変換し、接続する。 返って来た検索結果を統一形式に変換する。タイムアウト処理も含まれる。
• ローカルDB I/O
  ローカルDB(キーワードによる全文検索システム)に問い合わせを 発行し結果を得る。ローカルDBには Perlで書かれたフリーソフトウェアである SSE [12]を用いている。
• プロキシ I/O
  プロキシのログを処理し、 重複を除いた文書情報URLのみをローカルDBの入力ファイルとして出力する。 ローカルDBはこのURLを元に情報を取得し、インデクシングを行う。

以上のように、現在のシステムは基本機能のみの実装であり、 非常にシンプルな構成となっている。

4. 評価

4.1 使用実績

図4に有効検索数(全410件)のうちプロキシ由来のURLにジャンプした検索数の 比率推移を示す。プロキシ由来でないジャンプ先は、外部検索エンジンから 提供された物である。

図4. 有効検索数とプロキシ由来URLへのジャンプ数の比率推移
(1997年7月15日より15週間(105日間)) 青-平均値(15.2%)

図4から、全体の2割弱の検索需要をプロキシ由来のURLが受け持って いる事がわかる。サンプルとした検索数が少ない(週に数十件)ため 参考評価であり、数値そのものに客観的な意味を持たせる事はできないが、 小規模な試行としては妥当な結果を得た物と考えている。

実装方針で触れた通り、全ての検索のうち「確認を求める要求」の割合が どの程度を占めるかはユーザグループによって様々であり、また時間とともに 変化すると考えられる。我々の試用では、「確認を求める要求」 を検索によって解決する割合が15週間にわたって2割程度存在する事が わかったが、例えば上記の要求をキーワード検索でなく Bookmarkや アシスタントソフトウェアの機能を使って満たしているユーザが 多ければ、比率は低くなると思われ、逆にほとんどの情報要求を キーワード検索で満たしているユーザが多ければ、比率は高くなると 思われる。

以上のように、本稿で議論したシステムの客観的評価は難しい。 しかしながら、グループの情報要求支援と言う点において著者らの 使用感は良好であり、機能拡張により検索アシスタントとしての 価値を高める事が可能であると考えている。

5. 問題点と今後の展望

5.1 試作システムの課題

蓄積情報の削除

本稿で議論している種類の情報システム (ユーザ行動の蓄積に基づくシステム)では、 情報の追加よりも削除が問題となる事が多い。 現在はユーザ数が少ない事から削除は手動となっており、 事実上システムに実装されていない。

実験の規模では三ヵ月の運営で7000件程度の情報が付加されたが、 実際に利用された情報が 5% 程度であった事からわかる通り不要な情報も多く含まれている。

ただし、 どの情報が不要かは必ずしもアクセス件数や頻度だけからは判断できない。 さまざまなヒューリスティクス (HTMLに gif イメージが一枚含まれているだけで、URLのホスト部が 新聞社の物であれば広告ページである、など) を容易に利用できる枠組が必要がある。

検索結果のリオーダリング(ソーティング)

現在の実装ではプロキシログから単にURLのリストを取ってくるだけであり、 検索結果の順位付けはローカルDBが付与するスコアをそのまま採用している。 プロキシログからは URL 毎のヒット率や再読み込みレートも取得できるため、 これらの情報を生かした検索結果の順序付けを行う事が望ましい。

フロー情報とストック情報の混在

新聞社のWWWサーバなど、同じURLで常に内容が変化する場合、 あるスナップショットを取ってインデックスを作ってもあまり意味がない。 こうしたフロー性の強いURLは除外しておく事が望ましい。 一方、特定分野のFAQのようにアップデートがトピックの変動を意味しない場合、 ロボットなどで更新を監視し、 常に最新の情報を検索可能にしておく事が望ましい。 アクセス履歴だけからこうした区別を自動化するのは難しいが、 自動巡回リストなどのヒントを与えて処理できるような仕組みを検討する。

検索結果のグルーピング

一部の汎用WWW検索システムではすでに行われているが、 ミラーされた情報のようにURLが異なるだけで内容が同じ物をまとめる機能や、 URLのpath部に現われるディレクトリ階層の深さに応じて部分的にソートし、 セクションやサブセクション毎に離散しがちなHTML情報をまとめて見せる機能が 望まれる。

5.2 今後の予定

また、このようにして遍在する複数の検索サーバ間の関係が明らかになれば、 スケーラブルな検索インフラストラクチャの構築をめざすIngrid( [13])への応用も可能であると考えている。

5.3 関連研究

平岩らの InfoPlaza[14] は、興味が近いグループで 一種のブックマークサーバ(Plaza-Server)を共有し、興味の近いユーザの行為 から計算された URL の推薦を受けるシステムである。グループにおける情報流通 と言う意味で興味深い。

Kautz らの Referral web プロジェクト[15]は、 情報自体を探すより知っている人を探した方が効率が良いことから 専門家と関連情報を結びつけるツールを研究している。グループ指向 検索アシスタントの立場からは、情報自体を探すより、それに強い検索 アシスタントを探した方が効率が良いと言う事になり、専門家をユーザグループ に持つ検索アシスタントと関連情報を結びつける手法として参考になる。こうした 手法により、複数のグループ指向検索アシスタントを協調動作させる事ができれば 既存の汎用サービスより効率的な(=適合率の高い)分散検索システムが 構築できると考えている。

6. おわりに

今後、分散検索に興味を持つユーザグループに本システムを使ってもらえるよう、 システムの公開をめざして実装していく。

参考文献/URL

1. 清水. 日本のサーチエンジンのリスト,http://www.ingrid.org/w3conf-bof/search.html, 1995-1997.
2. U. Shadanand, et al.Social Filtering: Algorithms for Automating 'Word of Mouth', CHI'95, pp.210-217, ACM Press.
3. P. Resnick, et al.GroupLens: An Open Architecture for Collaborative Filtering of Netnews, CSCW'94, pp.175-186, ACM Press.
4. P. Resnick ed.Recommender Systems, CACM Vol.40, No.3, pp.56-89, March 1997.
5. P. Ingwersen. Information Retrieval Interaction,1992 (藤原 監訳、「情報検索研究 - 認知的アプローチ -」トッパン,1995)
6. Yahoo. http://www.yahoo.co.jp/
7. goo. http://www.goo.ne.jp/
8. InfoSeek. http://www.infoseek.co.jp/
9. 斉藤. 桶と壷, bit Vol. 28, No.7 pp.46-50, 共立出版, 1996.
10. 原田, 清水. WWW検索システムにおける不特定多数の 操作履歴の活用 情報処理学会研究報告 97-DPS-81, 1997.
11. Squid Object Cache,http://squid.nlanr.net/
12. Sony Drive Search Engine, SSE v1.1, available from http://www.sony.co.jp/Search/download-j.html
13. P.フランシス他. 次世代情報検索インフラストラクチャ Ingrid, NTT R&D Vol.45 No.2, 1996.
14. 平岩, 神田, Info-Plaza:他人の知識を利用した情報フィルタリングシステム, Japan World Wide Web Conference in Kobe, 1995, IAJ
15. H. Kautz, B. Selman and M. Shah, The Hidden Web, AI magazine Vol.18, No.2, pp27-36, 1997