第15回WI2研究会 2日目セッション2「評価・サービス統合」

遅刻しました。
ホント申し訳ないです。
まさか、ICOCAのチャージが0円になってるとは思わず、駅に駆け込もうとしたところで

ピンポーン☆

泣く泣く切符を買ってる間に電車は行ってしまいました。。。
私の阿呆。。。

幸先の悪いスタートでしたが、発表はきっちりと聞かせていただきました。
以下、メモです。

===============
■関連単語抽出アルゴリズムの改良と評価
九州大学　倉門先生

・提案手法
関連語の抽出：TF-IDFを用い、ある範囲内にある語のみに絞り、目的語に近い語に高い評価値を与える。
複数文書間の重み付け：文書頻度の逆数（IDF）を利用して、多くの文書に習われる単語の評価値を抑える
　　→語数の多いテキストの重みを抑えるために、正規化を行う
？？今まで正規化しなかったのか？？

・実験
従来手法、提案手法、従来手法＋局所的重み付け、従来手法＋大局的重み付け、TF、IDF。
元データはGoogleの検索結果の上位ページ：検索結果が不良となるクエリを用いるべき？
被験者４人、４パターンで確認。
　　→平均値は向上した。


質問1
限定する範囲は、段落をまたいだ場合でも有効なのか？
　　→今は有効になっている。今後は対応していきたい。

質問2
Googleのサジェストと真っ向からぶつかるところを目指している。瞬時に候補を出せるメリットがある。
　　→Googleサジェストの結果と比較すると、Googleの方が履歴を利用しているので真っ当な感じがする。

質問3
統計的なベーシックな手法だと感じた。クエリの分野マップを見たときに自分の研究はどこに位置していると思うか？
　　→今後関連研究についても詳しく調べる

質問4
実験について詳しく教えてほしい
提案手法のスコアが高い方がユーザが高く評価していると本当に言えるのか？

質問5
どういうページを検索したいんでしょうか？不良なページを使うと結局精度が下がってしまうのでは？
　　→かも知れない。


■ODPを利用したユーザプロファイル作成と個別化検索システムの評価
九州大学　中村さん

・研究背景
→検索システムの性能の向上が必要
・ODP　Open Direcotry Project
話題の階層向上でWebページを分類した世界最大のWebディレクトリ
人手に寄ってWebページを分類
・提案手法
ODPの各ディレクトリに属するWebページの内容に着目
トップだけでなく、ODPの上位2階層を利用したユーザの興味・関心を細かく表現したユーザプロファイルの作成

・ユーザプロファイルの作成
　　ODPの各ディレクトリをインデックスとするベクトル
　　従来手法ではODPの各最上位ディレクトリをインデックスとしたベクトルで表現
　　→提案手法：下位ディレクトリ2層目まで。細かなプロファイリングが可能

　　1.ODPに属するWebページ群から単語を抽出
　　2.各単語が各ディレクトリにどのくらい関連しているか？
　　3.パーソナルドキュメントから単語を抽出（E-mailとか）
　　4.関連度を見る

一般のWeb検索エンジンで検索された結果をReranking
　　↑ベクトルの比較はcos類似度を用いる、これの順にランキング
　　各単語の関連度算出→エントロピー
　　ページベクトル：Webページのディレクトリへの関連度
最上位ディレクトリの選定
　　初期検索結果の上位10件、20件のタイトルとSNIPPET（紹介文）から単語を抽出
　　ODP最上位ディレクトリの関連度を求め、一番大きいのを選定

・評価実験
初期検索における適合率が50％以下のものを使用する。
？？この実験条件は不味くないか？？
ここでちょっと力尽きた。。。

質問1
ページを一つ選んだらそれを基準にRerankingする。最初に選んだページが本当にパーソナルデータであるのか？
　　→一応、全部に目を通してもらってから選んでもらっている。
複数のカテゴリにまたがるような文書がほしい場合は最大のディレクトリ一つをとるのは適切な結果をだせるのか？例えば証券システムがダウン場合、経済、システム対応の2つが見たい
　　→プロファイルのベクトルが両方のカテゴリに対して値を持っていれば、見つけることはできる

質問2
一番上のところでは粒度が粗すぎて、もっと下の方を見ないといけないのでは？
　　→階層構造なので、下が膨大になってしまうので
それは分かるが、そういう問題に立ち向かうにはこれと戦わないといけない
　　→今回1、2層と広げてみた。今後も掘り下げていきたいと思っている。
どういうユーザが対象のシステムなのか？
　　→検索のときに自分の見たいページをうまく見つけたいというユーザ全般。
リランキングしたいんであれば、もっと最初のところから入っていかないといけないのでは？

質問3
第一階層よりも第二階層の方が粒度が上がる？パーソナルデータから出たtf-idfを使った方が良いのでは？何故ODPを使ったのかがよく分からない。
　　→単にカテゴリを使おうと思った。

■拡張可能関係データベース管理システムを用いたWebサービス統合
山口大学 松井さん（同姓同名が研究室にいてビビッた。。。）

・提案手法
それぞれ存在するWebサービスへのアクセスをSQLによる問い合わせを行う
DBMSに全てのアクセスを集中させる。
PHP/PLでユーザ関数を記述する
　　→ユーザ自身の手で作るのは負担になるし、ソフトウェアの信頼性も下がる
Pg/WAFL：ユーザ定義関数のXMLによる仕様記述
　　※ とりあえず帰ってくるカラム名は自力で調べる必要があるっぽい
RSSリーダとかが実装例
　　？？XMLデータベースを使わないのか？？
・Webサービス
HTTPを用いた情報交換によりサービス
XMLで利用（SOAPなど）

・関連研究
　　EaRDB：ユーア定義関数を用いてWebサービスにアクセス。ユーザ定義関数の自動生成はできない。
　　YahooQueryLanguage：データソースのXMLによる記述を与える。複数のWebサービスへのアクセスは不可。

質問1
PgWAFLはWPLに比べるとアプリケーションよりの技術になっているのでは？あまり手間が減らないんじゃ？
　　→調査不足もあってWPLなどにあわせた記述にすべきだった。
RESTを対象としているところで結構ややこしいように思える。RSSについてもベンダ独自だったり、して大混乱する。Webアプリケーションの開発では統合的な記述としては解決できてないのでは？どの辺まで解決したいの？
SOAPはXMLのフォーマットで仕様記述が完全だけど、RESTは記述に限界がある。RESTを使うなら、その辺も考えて作らないといけない。

質問2
SQLの形でアクセスしようとしている。ユーザ定義関数を作るメリットは？

質問3：XMLで表現できる情報の空間とRDBで表現できる空間って違うようね？Amazonのデータは著者が複数帰ってきてその人数は分からない。その場合ユーザ定義関数はどうかけるのか？
　　→対応できない。
XMLとRDBの本質的な違いになる部分をちゃんと定義できるようにしてしまわないと難しい。

質問4
認証付きサービスについては考えているの？

質問5
全検索結果からのどこからどこまで取る？
　　→ページ数の指定はできる
全ての検索結果をえるのに何度もリクエストをしないといけない場合もある。それは大丈夫？
　　→ユーザ定義処理の中に繰り返し記述をする。
===============

関連単語の抽出とODPは、結構うちの研究室でも使えそうな技術だな。
Webサービス統合は魅力的な提案ではあるけど、やっぱり難しそう。
XMLDBを使えば良いのにと簡単に考えていたけど、その後先生たちから
　・XMLDBの知名度や実用性
　・XMLDBの形がアプリケーション実装者にとって嬉しい形なのか
という問題が挙がった。。。確かに。

それにWebサービス統合って、結局利用するアプリケーション依存、そこで拡張が激しくなってしまいそう。認証とかセキュリティの話が入ってくると尚更。
そういやRESTメインでやってたけど、確かGoogleAppsにSOAPじゃないと取れないデータがあった気が。。。ムツカシイなぁ。