2009年7月6日月曜日

第15回WI2研究会 2日目セッション3「ユーザ行動分析とWebページ解析」

2日目午前の後半戦。
空腹との戦いでした。

============
■リアルタイム閲覧者ネットワークによる検索システムの提案
京都産業大学 松井さん

・背景と問題点
情報取得:検索サービス、コミュニケーションサービス
→Webページをライブで閲覧しているユーザのネットワークをリアルタイムで構築

・Wiredシステム
  ライブ検索機能
    ライブ閲覧者の発見
    注目記事をすばやく発見
  ページコミュニケーション機能
    同じ興味を持つユーザからの支援

・システム概要
リアルタイムな閲覧人数に基づいて既存の検索エンジンによって返される結果をリランキング(人数順)
Firefoxアドオンで実現しているっぽい
同一ページ閲覧ユーザとコミュニケーションが行える
  ページに入ると、そのページ内にいる別のユーザが緑色の●として浮いてチャットができる。

・アドオンのダウンロードページ
http://klab.kyoto-su.ac.jp/~matui

質問1
同じページを見ているからといって同じ興味を持つのか?探している者同士だとお互いにそのテーマが分かっていないのでは?
  →アバウトに考えてるので、もうちょっと考察した方が良いとは考えている。

質問2
どういうユーザを想定しているのか?新しいコミュニケーションメディアを提案しているのか検索システムを提案しているのか?
  →同列に考えいている

質問3
たくさんの人が使ったら破綻しちゃいそう。
  →ユーザの表示上限数は提示できる。目的別のチャットルームを立てる。

質問4
同時閲覧しているかはサーバ管理。検索結果のコンテンツからさらにリンクをクリックとれる?
  →とれる

質問5
実際にWebページをみているひとが一覧で出たサービスがあった気がするんだけど、
  →検索と組み合わせてユーザの発見をやりやすくしている点は独自性がある。


■非タスク試行型対話システムにおける非同期並列的相互作用による言語獲得手法の提案
北海道大学 若原さん

・雑談のできるロボット=非タスク志向型対話システム
・知識源としてWebを用いる→予め何でも知っているように見えるシステムができる
  →コストが高い
・チャットルームを公開し多数のユーザに利用してもらう→人間との対話から学習する
  →少しずつ話せるようにする

・非同期並列的相互作用
システムとユーザがきれいに交互というのが多くのシステム。
実際のチャット:必ずしも二者ではないし、交互でもない。
  →内部状態を挟んで入力フェーズと出力フェーズが独立している
・入力フェーズ
  4文字部分のWindowを使ってセグメント分割
  セグメントを発話キャッシュに保存
・出力フェーズ
  内部状態を常に監視し、内部状態でもっとも重みの高いセグメントを発話 (マルコフ連鎖)

・miniブログ上に人間と対話を行うシステムを実装
  →Twitterにて公開 @hadzimmo
人間同士の対話から学習
全く白紙の初期状態→現在:学習開始から1ヶ月程度
キャッシュ:対話の開始から終了まで保持
対話の観測対象ユーザ数300人
対話に実際に参加9名

「おはよう」「おかえり」くらいは出来たらしい。他にも。
「デートしてください」「喜ん。。。wwww」
「おはようございます」「おめでとうございます」
「お、お疲れ様です」「仙台から乙ありでーす」
  ※ ちょっと笑える。おもろー!

・考察
  学習量がたりない
  整合性のない対話が多く見られた
・今後の課題
  マルコフ連鎖に代わる発話生成方の開発
  あいづちの挿入
  ユーザの感情を判断


質問1
Twitterをターゲットにしたのは?
  →チャットらしいチャットだと、話題が錯綜して対応できない。Twitterだと大体一つの話題でまとまっている。
Twitterは頻繁に会話にならない。あまり会話らしい会話ができない。
  →今のままでは困難なので、Twitterに限らずにやっていきたい。

質問2
雑談を成立させようとすると、意味の塊が重要になってくる。表層を貯めていくと、意味に転換することを考えているのか?それともある程度データをためたら、内部に意味を組み込むようなフェーズに踏み込むのか?
  →今のところ表層以外を考えていない。今後検討する。

質問3
ワンパターンな会話に陥ってしまわないか?
  →出力リストの一番上のものだけを用いるのではなく、ランダムで出力している。


■情報探索プロセスにおける利用者の検索履歴活用行動の分析
筑波大学 松村さん

・モチベーション:Googleなどの検索システムが持つ多様な機能は、本当に情報探索に役立っているのか?

・利用者の情報探索プロセスを明らかにする
→今回は検索履歴の活用、どんなとき、何故、どのように使ってるのか
→検索履歴の有効な使い方を明らかにする

・実験 2007年8月~2008年5月
協力者:10名(図書館情報学、看護学、教育学、医学) エキスパート??
フェーズ1 自分でテーマを決定、文献収集、適合判定 どんなテーマがあったの??
フェーズ2 追加収集
  ここまでは通常の検索システム
フェーズ3 履歴活用行動取得実験(ログ、発話思考法、インタビューなど)
  履歴を見ながらやってもらった
  タスク1 過去に自分が検索したテーマで5件
  タスク2 過去に自分が検索していない、他者がやったテーマで3件
関連クエリ(検索キーワード)=テーマ
適合だと思ったってのはどうやって抽出しているの??

他者の関連文献について、入力キーワードの妥当性が確認できる
検索戦略の切り替え、自分他人の渡り歩き→行き詰ったとき、レスポンスがおそいとき

・今後
ミクロな分析からプロセス全体へ

質問1
ログの量に差はなかった?
  →かなりあった。

■ユーザ関与を伴った推薦方式設計
大阪大学 甲斐さん

・モチベーション:推薦の精度はある程度向上した、今後は精度向上だけでなくユーザ満足度を向上させるべき

・ユーザ関与
ユーザが推薦仮定に介入し、推薦機構を制御すること
ユーザ負荷を下げる
  MediaUnbound:35もの質問に答える必要がある
  eHarmony:一時間程度かかるアンケート  ユーザ負荷がかかるが

 ??どういうユーザを対象にしているかによりけりで、負荷に耐えられるかどうかは何を得たいかによるのでは??

・提案手法
推薦過程に関与すると言う好意事態が満足度に影響するのでは
音楽推薦システムを実装、
  どのような関与を用いるか
  どうのような推薦アルゴリズムを用いるか?
    ・Rating(好き、嫌い)
    ・コンテキスト入力(いつ、どこで、誰と):ユーザの嗜好は状況によって違う
    ・コンテンツ属性指定(推薦してほしいコンテンツの属性を明示的に指定)
    ・プロファイル編集(ユーザプロファイルの可視化)
  推薦結果にRatingするのは全部同じ。
  関与を反映しているグループと反映していないグループの2とおり。

ベイズ推定を用いた内容に基づくフィルタリング
  ユーザが好きな曲・好きでない曲のコンテンツ属性の頻度を学習
  各楽曲をユーザが好む確率を学習

??夜好きな曲っていう曲の属性情報はどうやって求めている??

・分析項目
  満足度
  関与の度合い
  推薦精度
  被験者の音楽に対する興味の度合い

質問1
コンテンツ量が増大した場合、コンテンツの属性をどうやって対応するのか?
  →ユーザに評価してもらう。またランダムに幾つかとって評価してもらい、それで補完していく。

質問2
負荷に耐えられるかどうかは何を得たいかによるのでは?
  →実験で真剣さについても検討する。


■Webページ間の共通性の発見に基づく多層的な発見に基づく多層的なWeb閲覧セッションの抽出
兵庫県立大学 木村さん

・閲覧履歴を多層的に表現する手法

・Web閲覧セッションとする
  →ラベルを付与し、一繋がりを1セッションとする
・上位階層の発見
  となりあうセッション同士をTF-IDFで主な用語を抜き出し、重なった用語の中で分散が最小の語を上位階層ワードとする
・下位階層の発見
  各ページの候補キーワードの和集合を求め、なんちゃらかんちゃら
・実験
  セッション切れ目に失敗が多い

質問1
情報推薦に結び付けたいとはどうやった形なのか?推薦に利用するとなるとどういう風な粒度でどういう風にとるのかが影響するのでは?
  →割と楽観的に考えている。ゴールを先に決めておくべきだった。
研究で整理された事項が、役立つようにしてほしい。

質問2
将来像があまり明確でないようだが、、、グルーピングした結果をユーザに見せてあげて推薦するのか、取った情報を裏方として使うのか?
  →裏方として考えている。
その場合、かなり精度が必要になる。インタラクションしながらだと、もうちょっと気持ち悪さはないのでそちらを考えてはどうか?

質問3
内容に加えてアクセスや時間は活用するの?
  →していない。

■ソーシャルブックマークの分析に基づく競合Webページの発見
兵庫県立大学 湯本さん

・目的:ソーシャルブックマークを用いて競合ページを発見し、その情報を用いて対象ページの価値判断を支援する
競合Webページの定義:分類できる最も細かいカテゴリが対象ページと同じWebページ
  タグの親子関係を求め、代表タグ集合(ページに付与された主要なタグのうち、子を持たないトピックタグ)を形成する
  ↑親子関係そのものはソーシャルブックマークから調べる

・提案手法
1.対象ページの代表タグ集合を取得
2.代表タグ集合内のタグが用いられるページ集合を取得
3.ランキングするっぽい

ブックマークされていないWebページ:自動タグ付け(Tf-idfなどを使う)

競合Webページへのリンクを提示してあげる。
 ??Googleでいう関連ページのことかな??

・予備実験
代表タグ集合によるページ集合の取得→条件の緩和が必要
自動タグ付けの精度確認→不正解のタグを含んでしまうことが多かった

質問1
タグを階層化するべきか?もともとタグはディレクトリ構造へのアンチテーゼでは?
  →完全に全てを階層化するわけではない。
親子関係というのは完全なツリー構造なのではない?
  →そのとおり。
競合Webページというより、分類が同種であるというニュアンスを持たせた方が良い。
============

ハジモ君は面白かった。
後でTwitter見に行ったけど。。。なかなか苦労していらっしゃるようで<苦笑
一番興味があったのは「ユーザ関与を伴った推薦方式」
これは「設計」というよりも、ユーザ関与と推薦の精度の両者の「相関を定式化」する研究として捉えるべきかな。
大変興味深い研究。結果が楽しみ。
音楽を対象にしてるなら、Music Genome Projectとかも良い感じに使えそう。




ユーザが提供するデータが増えれば増えるほど勿論推薦の精度はあがる。
ただそれを嫌がったり面倒くさがるユーザが多いから、クリック履歴や閲覧履歴からこっそりユーザのデータを取ってくる方向に今は進んでいる。。。

見つかる.jpとかはそこを思いっきり踏み倒して、ユーザに面倒くさい入力を求める代わりに的確な商品の推薦を行うように工夫されている。(ファジィ理論も少しあるみたい)
あそこらへんのユーザ関与を「定式化」できれば推薦に良い指標が生まれそうだなぁ。

0 件のコメント: