![機械学習の世界の分類
l 問題設定に基づく分類
l 教師有学習 / 教師無学習 / 半教師有学習 / 強化学習 など ..
l 戦うドメインの違い
l 特徴設計屋（各ドメイン毎に, NLP, Image, Bio, Music）
l 学習アルゴリズム屋（SVM, xx Bayes, CW, …)
l 理理論論屋（統計的学習理理論論、経験過程、Regret最⼩小化）
l 最適化実装屋
l 好みの違い
l Bayesian / Frequentist / Connectionist
l [Non-|Semi-]Parametric
43
この⼆二つの問題設定だけは
知っておいてほしいので説明](https://image.slidesharecdn.com/20130518twitter-130516072651-phpapp02/85/Twitter-4-Twitter-43-320.jpg)
![接尾辞配列列 Suffix Arrays (SA)
l 全接尾辞を辞書式順序でソートした結果
l ⻑⾧長所 漏漏れがない、どんなクエリでも⾼高速
l 短所 索索引が⼤大きい、構築に時間がかかる
abracadabra$
11 $
10 a$
7 abra$
0 abracadabra$
3 acadabra$
5 adabra$
8 bra$
1 bracadabra$
4 cadabra$
6 dabra$
0 abracadabra$
1 bracadabra$
2 racadabra$
3 acadabra$
4 cadabra$
5 adabra$
6 dabra$
7 abra$
・・・
dabra = dabra$
辞書式
順序
ソート
出現位置(先頭位置からのオフセット)
例：dabraを検索する
1. 配列 SA の大きさは 11 なので配列インデックス
の中心値 5 から検索
2. SA[5] = 8 、この 8 は “abracadabra” の “bra”
の
出現位置を指している
3. 検索クエリの "dabra" と "bra" を比較すると
"dabra" の方が辞書式順で大きい
4. よって検索範囲は SA[5] から SA[11] の間に絞
り込まれる
5. SA[5] と SA[11] の間 → SA[8] = 6
6. SA[8] = 6 の 6 は “abracadabra” の dabra
に
一致。よって dabra の出現位置は 6 と判明](https://image.slidesharecdn.com/20130518twitter-130516072651-phpapp02/85/Twitter-4-Twitter-75-320.jpg)
More Related Content
Similar to Twitter分析のためのリアルタイム分析基盤@第4回Twitter研究会(20)
Twitter分析のためのリアルタイム分析基盤@第4回Twitter研究会
- 1.
- 2. ⾃自⼰己紹介 l 海野 裕也 (@unnonouno) l プリファードインフラストラクチャー l 情報検索索、レコメンド l 機械学習・データ解析研究開発 l Jubatus l 分散オンライン機械学習フレームワーク l 専⾨門 l ⾃自然⾔言語処理理 l テキストマイニング 2
- 3.
- 4. l イントロ Project 311 l リアルタイム分析を⽀支える技術 l リアルタイム検索索技術 l リアルタイム機械学習技術 4
- 5. 東⽇日本⼤大震災ビッグデータワークショップ Project 311 l 東⽇日本⼤大震災発⽣生後１週間のデータを元に、どのような サービスを開発できるか l https://sites.google.com/site/prj311/ l 情報源は、Twitter、Google Trends、朝⽇日新聞記事など 5
- 6. 災害時に利利⽤用可能なサービスを提供する l 災害時には様々なメディアからの情報が錯綜した l Twitterなどを介してリアルタイムかつ⾝身近な情報が多く発信されたが、 必要な情報のみを集める⽅方法ができなかった l 実家がいわき市にある岡野原の個⼈人的な体験 l TVやラジオ経由の情報は原発や県・市単位の情報のみ l 原発の情報は⼤大事だが今⽇日のご飯・移動⼿手段を困っている⼈人も多い l ガソリンや⾷食料料はいつ/どこで配布するのか、避難できるのか l 各⼈人・各⽴立立場の⼈人にとって必要な情報が調べられるサービス l キーワード検索索では不不⼗十分 l 災害時だけではなく、平常時から利利⽤用可能なサービス l ユーザーに慣れてもらう、サービスも常時改善される 6
- 7. 提案サービス l 時間/話題/地域/キーワード毎に情報をフィルタリング l 個⼈人・組織が必要な情報を集められるようなサービスを作る l twitter、新聞、TV、レスキューの情報を横断フィルタリング l テキスト情報から必要な情報は抽出 7 時間 軸 地域（全国都道府県市町村レベル） トピック （避難・⽣生活イ ンフラなど） 時間・トピック・地域 キーワードを指定して フィルタリング • 例 • 3/11 15:00 – 16:00 • 福島県いわき市平地区 • 生活インフラ
- 8. システム概要図 8 Twitter NHK 朝⽇日新聞JCC(TV) 震災に関係する情報のみフィルタリ ング 地域情報の抽出 要望トピックの抽出 情報フィルタリングエンジン + UI 地域情報は地名や駅名、 路路線名、ランドマーク名 から市町村レベルで推定 関連情報の抽出 トピックは本⽂文から推定 「避難, インフラ, ⾼高齢者, 医療療 」など 21トピック URLや内容のクラスタリ ングにより、関連情報を 抽出 ⽂文書分類器を震災関連 ハッシュタグを正解例例 にして学習し、分類
- 9.
- 10. Twitterとその他のメディアの⽐比較 Twitter (CGM) 既存メディア 情報の鮮度度直近 遅れる 情報の信頼度度 デマも拡散する 精査されている 情報の粒粒度度 局所的な情報 ⼤大域的な情報 情報の密度度 不不要な情報が殆ど 精査されている 10
- 11. Twitterの良良さを活かすには？ l 最新の情報を届ける l リアルタイムに情報にアクセスできるようにする l 個別の情報を整理理する l つぶやきに含まれる情報を抽出する l 細かく情報を整理理する l 有⽤用な情報だけをフィルタリングする l 情報の価値を判定する l デマに惑わされない l 情報の信頼度度の評価 l 情報の⾃自動整理理 11
- 12. ⼤大量量のデータで溺溺れない l 太平洋で砂⾦金金を探しているようなもの l 本当に欲しい情報は1％もないと思って良良い l 闇雲に探してもダメ、強⼒力力な武器が必要 12
- 13.
- 14. 必要な情報を⾒見見つけ出すにはどうすれば良良いか？ l ⼤大量量の情報を効率率率的に精査する必要がある l ユーザーの欲しい情報だけに絞り込む l 事前に出来るだけ整理理しておく l 必要な情報は予め抜き出しておく l しかも、⼤大量量のデータを、リアルタイムに 14
- 15. ⼤大量量データから欲しい情報を得るための2つの技術 l 能動的な情報の取得 l ユーザーが興味のある情報を発⾒見見しにいく à情報検索索技術 l 受動的な情報の整理理 l ユーザーの興味がありそうな情報を提⽰示する à 機械学習技術 15 データ
- 16.
- 17.
- 18. 何故2つのアクセス⽅方式が必要なのか？ l 能動型アクセス l ユーザー固有の要求を提⽰示できる l 必ずしもユーザーがニーズを理理解していない l 想像の範囲外の要求を出せない l 受動型アクセス l ユーザーは何もしなくても情報が⼊入ってくる l 想定外の情報も⼊入ってくる l ユーザーのきめ細かい要求を反映しづらい 18 両者には相補的な関係になっている
- 19. 先ほどのデモを⾒見見なおしてみる 19 Twitter NHK 朝⽇日新聞JCC(TV) 震災に関係する情報のみフィルタリ ング 地域情報の抽出 要望トピックの抽出 情報フィルタリングエンジン + UI 関連情報の抽出 事前に情報 を自動整理 アドホックな 情報検索
- 20.
- 21.
- 22.
- 23. 情報検索索の全体像 l 効率率率的な検索索をサポートするためのインデクシング l 能率率率を上げるためのインターフェース l ⼤大規模データを扱うための分散技術 l 情報を回収するためのクローリング 23
- 24. 情報検索索のコアの仕組み l 事前に検索索効率率率をあげるための情報を整理理しておく l 本の索索引を作るイメージ l この整理理のおかげで効率率率的に検索索できるようになる 24 元データ インデックス
- 25. テキスト全⽂文検索索におけるインデックス⽅方式の違い 転置ファイル N-gram SuffixArray 辞書の必要 必要 不不要 不不要 漏漏れのない検索索 × ○ ○ 検索索速度度 ○ △ ○ インデックス構築速 度度 ○ ○ △ インデックスサイズ ○ × × HDD搭載 ○ △ × SSD搭載 ○ ○ ◎ 25 SSD利利⽤用時に最⼤大限の⼒力力を発揮
- 26. SSDがストレージ・プロセッサ・ネットワークのト レードオフを⼤大きく変えた SSD (Crucial m4 256GB) HDD (Seagate ST2000DL003) Read 415MB/s 140MB/s Write 260MB/s 140MB/s 4K Read IOPS 40000 150 4K Write IOPS 50000 400 26 SSDの特性を活かすことで スケーラブル・⾼高性能・低 コストな検索索基盤を実現 x100 FAST!!
- 27. 余談：インデックスを⽤用いないとどうなるか？ l 事前に整理理しないで、⾼高性能マシンや超⼤大量量マシンで愚 直に全部探す⽅方法もある l Hadoopなどはこうしたアプローチの⼀一種 l 効率率率が悪く、数万倍のコストがかかることも 27 元データ
- 28. Twitter検索索と従来の記事検索索のどこが違うか？ l 流流量量が膨⼤大 l 秒間数千〜～万というオーダーで⽂文書が増え続ける l ⽌止まることなく流流れ続ける l 常にデータを追加し続ける必要がある l 特にデータの鮮度度が重要で、直近のデータを探せる 必要がある l 原則追記だけで削除や更更新がほとんどない 28
- 29. ⼤大規模データ分析のリアルタイム化 l ⼤大規模データ分析のリアルタイム化に対するニーズは 急増中 l Hadoop Summitにおいても、多くのセッションで“リアルタ イム”がテーマとなっている l Google Dremel, Google BigQueryが発表され、 Apache Drill, Cloudera Impala等が注⽬目を集めている l リアルタイム分析に必要とされる技術の複雑さは様々 l Jubatusによるリアルタイム機械学習 l ImpalaなどSQLベース、DWHの⼤大規模化 l 検索索技術をベースにしたアドホック分析 → Splunk、Solr Cloudなどを利利⽤用 29
- 30. 技術的な克服 l メモリとSSDのハイブリッド l オンメモリのサーバーと、SSDサーバーの併⽤用で、直近のデー タはオンメモリですぐさま検索索結果に反映できる l ⾼高頻度度の書き換えに弱いSSDを守る意味でも重要 l 追記に特化 l オンメモリサーバーにどんどん追記、古くなったらSSDに回す l あふれたら古いデータから順番に消していって、最新の重要な データだけを保持できるように 30
- 31. Twitterの分析にはまず検索索を l 実際にTwitterのデータを解析するには、まず検索索 l 分析対したい事柄に対して検索索で当たりをつける l この時点でデータが少なすぎたら要検討 l たとえ秒間数千件でも⽉月に1回しかつぶやかれないような内容も ある l 特にB2Cのサービス・製品、メディア、スポーツ、芸能系は⾔言 及が多いが、B2Bのサービスや製品は少ない 31
- 32. クエリの⼯工夫での限界を知る l 途中で検索索クエリの限界に到達 l 表記揺れなどで検索索漏漏れがある l 多義語のフィルタリングができない（例例：PFI） l 検索索クエリではそもそも絞り込めない（例例：男性だけ探す） l データを細かく整理理するには機械の助けが必要 32 機械学習の登場
- 33.
- 34. 機械学習とは l 経験（データ）によって賢くなるアルゴリズムの研究 l データから知識識・ルールを⾃自動獲得する l データの適切切な表現⽅方法も獲得する l ⼈人⼯工知能の中で、⼈人が知識識やルールを 明⽰示的に与える⽅方法の限界から⽣生まれてきた 34 学習データ 分類モデル
- 35. 様々な分野に適⽤用可能 l データから有⽤用な規則、ルール、知識識、判断基準を抽出 l データがあるところならば、どこでも使える l 様々な分野の問題に利利⽤用可能 35 レコメンデー ションクラス タリング 分類、識識別 市場予測 評判分析 情報抽出 ⽂文字認識識 ロボット 画像解析 遺伝⼦子分析 検索索ランキン グ ⾦金金融 医療療診断 適用分野
- 36. 例例１：スパム判定 l メールがスパムが否かを⾃自動判定する l スパムキーワードの事前登録だとイタチごっこ l GoogleのGmailでもスパム判定は機械学習が使われている 36 スパム 通常 新着メール
- 37.
- 38. 例例3：コンピュータ将棋・囲碁・チェス 38 http://blog.livedoor.jp/yss_fpga/archives/53897129.html 詳細は鶴岡慶雅先生のチュートリアル 「自然言語処理とAI」 l ゲームごとに機械学習の応⽤用⼿手法が次々に進歩 l チェス・将棋、囲碁、ポーカー、etc. l 機械の性能改善以上に⼿手法の改善が⽬目覚ましい
- 39. 機械学習の⻑⾧長所 (1/4) データがあればすぐ試せる l 分類ルールを学習したい場合、正解事例例がいくつかあれ ば学習可能 l 質問：データがどれくらいあったらうまくいくのか？ l 答え：正解事例例が1つしかなくても動く、多ければ精度度 は⾼高くなる l 以下のファクターで正解事例例はより多く必要とする l 問題の複雑さ l 正解事例例に含まれるノイズ量量 l 学習モデルの複雑さ l 実際は数⼗十から数百、⼈人⼿手で作れる規模が殆ど l すぐ試せる 39
- 40. 機械学習の⻑⾧長所 (2/4) メンテナンスフリー l 学習の元となるデータを与え続ければ最適化される l ルールベースの場合、ルールをメンテナンスしなければ ならない l 時間経過とともに運⽤用コストが⼤大きくなり、例例外も次々と発⽣生 l ⼈人の引き継ぎや、システム統合が発⽣生した場合、メンテナンス は⾮非常に困難になる l 機械学習の場合は、ルールではなく、データをメンテナ ンスする必要がある l ⾃自由度度はルールベースより⾼高く、スケールする 40
- 41. 機械学習の⻑⾧長所 (3/4) 問題に対してスケールする l 問題のデータサイズを増やしたり、分類対象数を増やし たり、他の似た問題にも展開可能 l ある部署でうまくいっていた⼿手法を他の部署や会社でも展開可 能 l 例例：ニュース記事の5カテゴリへの分類を次のように変 更更可能 l カテゴリ数を5から100に増やす l 分類対象をニュース以外にもブログやメールにも増やす 41
- 42. 機械学習の⻑⾧長所 (4/4) ⼈人や⼈人⼯工システムを凌凌駕する性能を出す l 速度度、網羅羅性、可⽤用性といった部分ではコンピュータが 凌凌駕する l ⼈人はルールや評価関数をうまく表現できない場合も多い l ⾔言語処理理・ゲーム・画像認識識・⾳音声認識識などは知識識表現が⼤大変 l ⼈人⼯工知能の研究分野では、知識識・ルール・評価関数を⼈人が明⽰示 的に与えることに限界があり、データからの獲得に⼒力力を⼊入れた l 箱庭的な問題だと精度度⾯面でも⼈人を凌凌駕する l 関係する特徴数が多い場合 l 医療療診断、広告最適化、スパム分類 l 評価関数が分からない場合： l コンピュータ将棋/囲碁/チェス、機械翻訳、⾳音声認識識42
- 43. 機械学習の世界の分類 l 問題設定に基づく分類 l 教師有学習 / 教師無学習 / 半教師有学習 / 強化学習 など .. l 戦うドメインの違い l 特徴設計屋（各ドメイン毎に, NLP, Image, Bio, Music） l 学習アルゴリズム屋（SVM, xx Bayes, CW, …) l 理理論論屋（統計的学習理理論論、経験過程、Regret最⼩小化） l 最適化実装屋 l 好みの違い l Bayesian / Frequentist / Connectionist l [Non-|Semi-]Parametric 43 この⼆二つの問題設定だけは 知っておいてほしいので説明
- 44. 教師有り学習 l ⼊入⼒力力 xに対して期待される出⼒力力 y を教える l 分析時には未知の x に対応する y を予測する l y がカテゴリの場合を分類問題、実数値の場合を回帰問 題と呼ぶ l 分類 l スパム判定、記事分類、属性推定、etc. l 回帰 l 電⼒力力消費予測、年年収予測、株価予測、etc. 44
- 45. 教師無し学習 l ⼊入⼒力力 xをたくさん与えると何かしらの結果を返す l クラスタリング l 与えられたデータをまとめあげる l 異異常検知 l ⼊入⼒力力データが異異常かどうかを判定する 45
- 46. 安易易に教師なし学習に⾶飛びつかない！ l どのような分類基準になるか予測できない l 分類結果の意味を解釈するのが難しい場合が有る l できたクラスタに意味を割り当てるのは困難 46 問：下の図形を2つのクラスタに分けなさい
- 47. Twitter分析に求められる機械学習は？ l ⼤大量量データ処理理 l 秒間数千件のデータを捌くことができる l データの増⼤大に耐えられるスケーラビリティー l リアルタイム性 l データが来たらすぐさま処理理できる 47 これからのビッグデータ解析に求められる特徴
- 48. l NTT SIC*とPreferred Infrastructureによる共同開発 l 2011年年10⽉月よりOSSで公開 http://jubat.us/ Jubatus 48 リアルタイム ストリーム 分散並列列 深い解析 * NTT研究所 サイバーコミュニケーション研究所 ソフトウェアイノベーションセンタ
- 49. 機械学習はスケーラブルかつリアルタイムに l Jubatusは２つの流流れを融合している 49 WEKA 1993-‐ SPSS 1988-‐ Mahout 2006-‐ Online ML alg. Structured Perceptron 2001 PA 2003, CW 2008 リアルタイム オンライン Batch 小規模 単体 大規模 分散並列 Jubatus 2011-‐
- 50. バッチ学習 l 解析対象のデータが全てある 状態で解析を⾏行行う l 速度度が遅い l データ全体の保持が必要 l 実装は⼀一般的に煩雑 l データを１つずつ受け取るた びに解析を⾏行行う l 速度度が速い l データを保持する必要がない l 実装は⼀一般的に単純 l 近年年急速に研究が進んでいる 50 オンライン学習 近年年の多くの場⾯面でオンライン学習を採⽤用
- 51.
- 52. 「緩いモデル共有」による分散の仕組み l みんな個別に⾃自学⾃自習 l たまに勉強会で情報交換 l ⼀一⼈人で勉強するより効率率率がいいはず！ 52 学習器
- 53. Jubatusの機能概要 l Jubatusでは様々な分析⼿手法をサポート l 多値分類・回帰 l 統計 l 近傍探索索 l グラフ解析 l 外れ値検出 l これらを組合せることにより、多くの課題を解決が可能 l スパムフィルタ（メール分類） l 電⼒力力消費量量予測（回帰） l ユーザー属性推定（レコメンデーション） l ログからの異異常検知（外れ値検出） l 攻撃の標的になりやすいハブノードの発⾒見見（グラフの中⼼心性） 53
- 54. 情報検索索と機械学習を統合したリアルタイム分析基 盤 l ⼤大量量データを2つの側⾯面から整理理する l リアルタイムで⼤大量量の情報を検索索可能にする情報検索索エンジン l リアルタイムに⼤大量量の情報を整理理する機械学習エンジン l 整理理されたデータの分析を⽀支える可視化機能 54 Sedue for BigData
- 55.
- 56. まとめ l 情報源としてのTwitterの可能性 l リアルタイムで粒粒度度の細かい情報源としての活⽤用ができる l ⼤大量量のデータから必要な情報を抜き出す技術が必要 l 情報検索索技術 l ユーザーの欲しい情報を⾒見見つけ出す技術 l 事前にどこまで情報を整理理できるかが肝 l 機械学習技術 l データの分類・整理理を⾃自動的に⾏行行う技術 l 急速にリアルタイム処理理、⼤大量量処理理の技術開発が進んでいる 56
- 57.
- 58.
- 59.
- 60.
- 61.
- 62.
- 63.
- 64.
- 65. 今後の予定 l デモサービスをベースに実⽤用化・提供を⽬目指す l （再掲）災害時にいざ使おうとするとうまくいかない。 平常時からも使ってもらえるようなサービスを考える l 被災者や関係当局の話を聞き、何が必要であるかを絞る l システム側の技術的課題 l 全メディア情報をリアルタイムに分析して安定して提供できる 基盤 l 秒間1万tweet、秒間数百万〜～数千万の位置情報を処理理 l サンプリング/サマリではなく、細かい粒粒度度のまま提供可能 l 名寄せ・地域情報の推定（⾔言及位置、ユーザーの位置） 65
- 66.
- 67.
- 68.
- 69.
- 70.
- 71.
- 72.
- 73. 転置ファイル Inverted File Indexing l 各単語毎に、どの⽂文書に出現したかを記録 l ⻑⾧長所 シンプル、速い、分散処理理しやすい l 短所 検索索漏漏れが⽣生じる フレーズ検索索が苦⼿手 東京 10 15 16 20 21 22 東寺 10 15 …. 文書番号を記録
- 74. l ⻑⾧長さN（=2,3)の部分⽂文字列列を単語とみなし転置ファイ ルを構築 l ⻑⾧長所 漏漏れがない、シンプル l 短所 索索引が⼤大きい ⾮非常に遅くなる場合もあ る 東京都庁に今日… 東京都 京都庁 都庁に 庁に今 0 1 2 3 102 150 出現位置を記録 N-gram⽅方式
- 75. 接尾辞配列列 SuffixArrays (SA) l 全接尾辞を辞書式順序でソートした結果 l ⻑⾧長所 漏漏れがない、どんなクエリでも⾼高速 l 短所 索索引が⼤大きい、構築に時間がかかる abracadabra$ 11 $ 10 a$ 7 abra$ 0 abracadabra$ 3 acadabra$ 5 adabra$ 8 bra$ 1 bracadabra$ 4 cadabra$ 6 dabra$ 0 abracadabra$ 1 bracadabra$ 2 racadabra$ 3 acadabra$ 4 cadabra$ 5 adabra$ 6 dabra$ 7 abra$ ・・・ dabra = dabra$ 辞書式 順序 ソート 出現位置(先頭位置からのオフセット) 例：dabraを検索する 1. 配列 SA の大きさは 11 なので配列インデックス の中心値 5 から検索 2. SA[5] = 8 、この 8 は “abracadabra” の “bra” の 出現位置を指している 3. 検索クエリの "dabra" と "bra" を比較すると "dabra" の方が辞書式順で大きい 4. よって検索範囲は SA[5] から SA[11] の間に絞 り込まれる 5. SA[5] と SA[11] の間 → SA[8] = 6 6. SA[8] = 6 の 6 は “abracadabra” の dabra に 一致。よって dabra の出現位置は 6 と判明
- 76. 圧縮接尾辞配列列(CSA) l 接尾辞配列列の機能はそのままに、コンパクトに保存 （テキストサイズと同程度度） l 接尾辞配列列をさらに変換し圧縮 l 検索索対象テキスト⾃自⾝身の情報も同時に保持 l スニペットも索索引から復復元できる l 実装は難しい l Sedueは圧縮接尾辞配列列を搭載した初の商⽤用検索索エンジン