協調フィルタリングが面白い!

Webマイニング分野でポピュラーな「情報推薦」、そこで頻繁に使われるのが協調フィルタリングですね。私も興味を持ったので調べました。

1番最初に詰まったのが「推薦方法には(1)コンテンツベース手法と(2)協調フィルタリング手法があり、協調フィルタリングには(2-1)アイテムベース手法と(2-2)ユーザベース手法がある。」という説明。コンテンツベースとアイテムベースって同じようなものに聴こえたんですけど・・ん?(混乱)

というわけで、このあたりの違いに着目しながらまとめます。ポイントはコンテンツ特徴に着目するのか、購買履歴に着目するのかです。

コンテンツベースフィルタリング(content-based filtering)

コンテンツ特徴に着目して情報推薦する手法。推薦は応用範囲が広く、店頭に並ぶ製品に加えて観光地・音楽・映画などが挙げれます。これらをまとめてコンテンツと呼びます。

コンテンツベースフィルタリングでは各コンテンツに手動で特徴設定が必要です。これにはセンスが問われます。例えば、「君の名は。」の特徴には「アニメーション」「新海誠」「恋愛」などが考えられます。

これらを特徴ベクトルで表現して、距離定義に基づいて算出した類似度でソートすることで、検索キーワード(例『映画、新海誠』)に対して「君の名は。」を推薦できます。

ここで「ん?」と思った方がいるかもしれません。「君の名は。ってジャンル『恋愛』なの?」「もっと色々な特徴あるんじゃないの?」と。

実はコンテンツベース手法には次の弱点があります。
①特徴設定に専門性(ドメイン知識)が求められる
②特徴の多様性に欠ける

そこで協調フィルタリングの出番です。

協調フィルタリング(collaborative filtering)※アイテムベース

協調フィルタリングにはアイテムベースとユーザベースとありますが、ここではアイテムベースの説明をします。

協調フィルタリングではコンテンツの特徴ではなく購買履歴に着目します。各コンテンツがどんなものなのかという特徴を職人が知恵を凝らして設定するのではなく、「ユーザからの評価は?」「どんなコンテンツと一緒に購入された?」といった購買履歴を分析して特徴抽出します。

コンテンツベース手法には①専門性が求められる、②多様性に欠けるという弱点がありましたが、購買履歴を分析するので手動の特徴設定が不要()、購買行動はコンテンツの特徴に基づいて発生する()ことから弱点を解決しています。

ここでいう特徴とはジャンルや作家といった明確なものではなく、「こんな人たちに売れてる」という程度の曖昧な数値です。推薦とは「コレが好きな人はコッチも好きだろうな」というコンテンツ同士の類似度が必要で、コンテンツがどんな特徴を持っているか曖昧でも成り立つのです。

協調フィルタリング(collaborative filtering)※ユーザベース

同じく購買履歴に着目します。先ほどはコンテンツを分類しましたが今回はユーザを分類します。この背景には「ユーザの購買行動には傾向と特徴があり、分類可能である。」という仮定があります。そこでユーザ類似性を算出して「似たユーザには同じものを推薦すればいい。」という考えから、何を推薦するのか決定します。

以下のGifがわかりやすいのでご覧ください。


By MoshaninOwn work, CC BY-SA 3.0, Link

ColdStart問題

購買履歴がないと協調フィルタリングは使えません。つまり新規ユーザや新商品には適用できない問題があります。新商品は誰もまだ購入していないため「この商品は誰にも買われていません」という結果になります。

市場投入してしばらく経つのに購入されてないならレコメンドしないのが正解ですが、市場投入したばかりで購入履歴がないからレコメンドしないのは不適切ですよね。

このようにデータが足りない状況を欠損値問題といい、欠損値をどう補うのか様々な研究がされています。

少数派問題

独特な好みを持つユーザや、今までに類がないような斬新な商品といった少数派には、類似するものを見つけられないため協調フィルタリングが有利に働かないという問題も報告されています。

協調フィルタリングのまとめ

・購買履歴から似たユーザ、似たコンテンツを定義

・ドメイン知識が不要

・ユーザが多いと購買履歴が集まりやすいので有利

・新商品投入など新陳代謝が激しい場合は不利

・類似する仲間がいなければ推薦できない少数派問題

GoogleChartsがおもしろい!(ScatterChart編)※サンプルプログラムあり

GoogleChartsの第2弾、今回はScatterChartを触ってみました。

ScatterChart
https://developers.google.com/chart/interactive/docs/gallery/scatterchart

こちらは主に散布図を作成するものです。実は以前にJavaScriptで相関関数を算出したときに使っていました。(JavaScriptで相関関数の算出

既に使用経験がありますし、だんだん慣れてきましたし、ちょっとGISっぽく画像上にデータをプロットしてみました。以下の画像ではラグビーのフィールド上にデータをプロットしています。(サンプルはコチラ

ScatterChartには背景画像を設定する機能がどうもなかったようで、フィールド上へのデータプロットは次の手順で実現しました。

① divを配置してstyle-backgroundを任意の画像にする
② ScatterChartでデータプロットする
③ このときbackgroundColorをtransparent(透明)に設定

ただ座標の調節が難しいですね、そもそもラグビーの10mラインは中央から10mなのに対して、22mラインはエンドラインから22mだったりしますし。

 

今日はここまで

ブロックチェーンの特徴・メリット・デメリット②

前回、ブロックチェーンについて記事を書きましたが、その後に「パブリックブロックチェーンとプライベートブロックチェーンは別物として考える必要がある」と述べている鋭い記事を発見しました。

参考:https://imoz.jp/note/blockchain.html

私が前回記載したブロックチェーンの特徴・メリット・デメリットはパブリックブロックチェーンのことでした。というわけで今日はプライベートブロックチェーンとの違いに着目します。

パブリックブロックチェーンとプライベートブロックチェーン

<呼び方の定義>

以下3つは呼び方が異なるだけで同じものと考えます
・パブリックブロックチェーン
・オープンブロックチェーン
・パーミッションレスブロックチェーン

同様に、以下3つも呼び方が異なるだけで同じものと考えます
・プライベートブロックチェーン
・クローズドブロックチェーン
・パーミッションドブロックチェーン

 

この記事ではパブリックブロックチェーンプライベートブロックチェーンの2つの呼び方に統一しますね。

う~ん、、、なんかこう見ると、プライベートブロックチェーンはせっかくのブロックチェーンのメリットを潰して中央集権型に戻っているような気が・・・・

プライベートブロックチェーンのメリット

基本的に中央集権型と変わらないですね。中央集権型が機能分散を進めていって、仲介を務める存在が1つから2つ、2つから3つに増えていったらほぼプライベートブロックチェーンになるようなものです。

異なる点は取引履歴が延々と残っている点と、冒頭記載した参考リンク先にも記載されている通り合意形成に至る仕組みが簡単なことくらいかと。

近い将来にイノベーションを起こすとしたらパブリックブロックチェーンでしょうね。私も実際に扱うとしたらパブリックブロックチェーンの方がわくわくします。報酬を設定して採掘者を募る仕組みが必要なので企業様にとっては活用に踏み出しにくいでしょうけど。

GoogleChartsがおもしろい!(GeoChart編)※サンプルプログラムあり

GoogleChartsの第2弾、今回はGeoChartです!

GeoChart
https://developers.google.com/chart/interactive/docs/gallery/geochart

こちらは地図上にデータを可視化するものです。下図は試しに歴代高校ラグビー優勝回数を都道府県別に表示したものです。(偏ってるな~)

参考:http://www.mbs.jp/rugby_common/history/

 

GoogleMAPのおかげで既に各国の地図や都市名が組み込まれているため、「JAPAN」や「京都」を指定すればそれだけで地図が表示&都市の位置にデータがプロットされました。

サンプルはコチラ

さすがに都道府県の境界までは反映されず、優勝回数に応じた色で都道府県を塗りつぶそうとしたら失敗しました。(サンプルページを見る限りでは国境には対応しているみたいですね。)

 

ほんと手軽に動きますね、コレ・・・(驚

ブロックチェーンの特徴・メリット・デメリット

こんばんは、ロードローラーです。本日はブロックチェーンについて調べてみました。ビットコインがキラーコンテンツのため、ブロックチェーンとビットコインをイコールで捉えている方もいらっしゃいますが、ビットコインはサービス、ブロックチェーンは仕組みです。

ブロックチェーンの詳細な仕組みは置いといて、「で、けっきょくブロックチェーンって何ができるの?」ということをまとめてみました。

ブロックチェーンの特徴 ~分散台帳によって中央機関をなくす~

私はブロックチェーンを分散処理にもかかわらずセキュリティ担保できる仕組みだと解釈してます。

そもそも、目の前にいる相手と取引(例:ビットコイン送金)するときに、わざわざ中央機関に仲介手数料を取られるのは何故か?それは全取引の監視者である中央機関がいなくてはセキュリティ担保が難しいからです。しかし人間とは知恵を凝らすもので、セキュリティ担保は必要だけど仲介料も取られたくない、なにかいい手はないものかと考えました。そこで生まれた中央機関がいなくても全員で協力し合ってセキュリティ担保する仕組みがブロックチェーンだと解釈しています。

ブロックチェーンの1番の特徴は分散台帳によって中央機関を必要としないことです。これには様々なメリットがあるので、正しく理解しておきたいですね。

ブロックチェーンのメリット

<コスト>
現状は個人間の取引でも中央機関が仲介手数料を取る。この仲介手数料が分散台帳の仕組みによって無くなる、または安くなるということである。安くなるというのは、中央機関に仲介手数料を支払うよりも、ブロックチェーンに参加している採掘者へ報酬を支払う方が安くつくという意味である。

また、手数料のような運用面のコスト低下と別途で、システム構築の初期コスト低減というメリットもある。つまりゴツい中央集権サーバを用意しなくてもシステム構築できるということだ。これらは全く別種類のメリットなので気を付けてほしい。

<信頼性>
従来は中央機関が落ちればシステムはそのままダウンという状態だった。しかしブロックチェーンでは全員で力を合わせてシステムを回しているという状況なので、どこか数か所が落ちたところでシステム継続には何ら影響がない。

<セキュリティ
(これは詳細な仕組みの説明が必要かもしれないが)、ブロックチェーンへの参加者全員で取引記録を監視しているためセキュリティ(消去・改ざん防止)に優れている。

<監視範囲が広がる>
これは個人的な見解だが、中央機関の目が届く範囲しか監視できなかった従来と比べて、参加者全員で監視するため目の届く範囲が広がると思っている。機密性は低くとも匿名性は高いので(※後述)、個々人の細かな行為にまで監視の目が届き、保証可能な範囲が広がる可能性がある。

ブロックチェーンのデメリット

<低いパフォーマンス>
速度が遅い。これは参加者全員でコンセンサスを取りながら進めるためである。ビットコインではブロックチェーンによって取引記録が安全に記録されるのに平均10分かかるとされていた。

<オンラインでしか動かない>
取引自体は不可能ではないが、取引が実行されたことをブロードキャスト等で参加者に通知、取引内容を含んだブロックの生成、チェーンに追加といった一連処理はオンラインでしか動かず、オフラインでは不可。

<ストレージの圧迫>
今誰が何を持っているかという現状態ではなく、今までどんな取引がされてきたのかという履歴を保存するため、管理するデータ量が膨大となる。

<機密性が低い>
ブロックチェーンでは参加者全員で取引を監視するため取引内容が暗号化されず平文のままである。暗号化してしまうと取引内容が確認できず正しいかどうかジャッジできないからだ。

ただし匿名化はされているという点に注意していただきたい。例えばビットコインにおいては取引内容は平文だが、取引者は公開カギによって匿名化されている。「どこかで送金取引があったみたいだけど誰から誰になのかは不明」という状態だ。

ダイヤモンド取引の透明化

Everledger社はブロックチェーンを利用してダイヤモンドの採掘から消費者に届くまでの過程・認定書・取引履歴などを全て記録して「ダイヤモンド取引の透明化」を実現しようとしています。

たしかに採掘・加工・輸送・販売・転売などの全取引を追跡して1箇所で管理できる中央機関の存在は考えにくいので、ブロックチェーンの良き活用例だと思います。

 

さて、これからはどのような分野で活用・発展していくのでしょうか、楽しみですね。

Javascriptで相関係数の算出

こんばんは、ロードローラーです。京都はすっかり熱くなりましたね。

さて、ここ最近はGoogleChartsでデータ可視化を色々と試してました。ついでにJavascriptで基本的なデータ分析が出来ればいいなぁと思い立ちました。

詳細な分析は専用ソフトを使ってくれればいいんですが、データ可視化ついでにせめて相関係数くらい提示できれば、なんとなく因果関係がありそうな分布に数値エビデンスを加えられるからです。

というわけで早速実装。①温度と②湿度を2次元にプロットして相関係数を算出しています。2次元散布図ということでScatter Chartを利用しました。

Scatter Chart
https://developers.google.com/chart/interactive/docs/gallery/scatterchart

サンプルはコチラで動作させられます

が・・・、あれ?

温度と湿度って基本的に負相関だと思ってたんですが正相関になってますね、しかも0.95とかなり強烈な。。。。おそらく屋外の環境ではなく、室内の人工的に調整された環境のデータだからですね。加湿機能付きヒーターによって温湿度が同時上昇したとか。

今日はここまで、それではごきげんよう♪

GoogleChartsがおもしろい!(LineChart編)※サンプルプログラムあり

便利で無料で手軽に動作するGoogleCharts。IoTで収集したデータをとりあえず可視化したいという需要が増しているので活用機会は多々あります。

今回は「LineCharts」を動かします。

GoogleCharts
https://developers.google.com/chart/interactive/docs/gallery

LineCharts
https://developers.google.com/chart/interactive/docs/gallery/linechart

自室の温湿度を可視化しました。屋外と異なって変動が小さいですね。
実際にコチラで動作させられます。

 

手順としては下記のとおり

  1. GoogleCharts使用開始のおまじない
  2. データTableの定義
  3. データ読み込み(今回はajaxによるhttp通信でjsonファイルを取得。)
  4. 取得したデータを加工しながら格納
  5. 可視化実行

 

ちなみにソースコード貼り付けには以下を利用。WordPressにペタッと貼れるかと思ったらプラグインやらマークアップ対策やら案外手間でした。
http://tomari.org/main/java/html-mojihenkan.html

クラウドと機械学習

こんにちはロードローラーです。今日はクラウドと機械学習について書きます。先週にJAPAN IT WEEK 2017春@東京ビッグサイトが開催され、クラウド関連の出展ブースでは機械学習がトレンドだと言われ新聞記事にもなっていました。

実際のところ、IoTサービスによってデバイスからクラウドにデータ送信できるし、DWHサービスによってデータをクラウドに蓄積できるので、「だったら分析もそのままクラウドですればいいじゃん」というのは必然的な流れですね。

AmazonのAWS、GoogleのGCP、MicrosoftのAzure、IBMのBluemix、みんなやはり機械学習プラットフォームをクラウドで提供しており、他のIoTやDWHと連携させてクラウド完結できる仕組みを提供しています。

で、ここで私が気になったのは、各社が提供する機械学習プラットフォームにて、自分でかき集めたデータを使ってモデル選定とパラメータ調節を繰り返し、「学習済みモデル」をクラウド上に構築した場合に著作権や特許がどうなるのかです。

Business lawyerさんを引用すると、

学習済みモデルは、通常、関数、行列またはパラメータ等の形式で自動的に出力されますので、それ自体は創作性または発明性が否定されることもあり、著作権法または特許権法による保護の対象とすることが難しい場合が多いと思われます。
https://business.bengo4.com/category5/article153

とのこと。こうなると「事業のキモとなる認識器(学習済みモデル)が特許保護を受けていない状態で他社様のクラウド上にあるのってなんかイヤじゃない??」と私は考えてしまうわけです。

あと、もっとシンプルな突っ込み所としては、深層学習を突き詰めて利用すればするほど、環境構築においてCUDAやCaffeのバージョンも細かく指定したくなるだろうから「手軽で簡単に深層学習を開始できますよ!」ってコンセプトはいかがなものかと。。。

ひょっとして、そもそも玄人ではなく初心者をターゲットにしていて、いずれクラウド離れされても構わないのでとにかく深層学習のプレイヤーを増やすことが目的なのだろうか(ありえる)。

個人的には「深層学習なんてみんな自分で好きなように環境構築したいに決まってるでしょ!」という潔いスタンスで、GPU搭載サーバのレンタルをするだけというさくらインターネット株式会社様のような取り組みが好みです。環境構築は1から自分でしないといけません。なんというかさすが関西企業!そこにシビれるアコがれるぅ!!と思ってしまいました。

IoTで絶え間なく入ってくる新しいデータによって、毎日どんどん認識器を賢く更新していきたいという場合はやっぱりクラウドが向いてるんでしょうね。どこかでリビジョンを切って、いずれは認識器をコンポに落とし込みたいといった開発途中段階の場合は悩む点がありそうです。

今日はここまで。

変化点検出ChangeFinderのインストール&動かしてみた①

こんばんは、ロードローラーです。

今日は変化点検出を試したので紹介します。

IoTでデータを取得できる場面は広がりました。特に多いのが正常/異常を検出したいといった取り組みですが、いずれも「What is 異常?」を定義できずに悩んでいるようです。

そんな状況で私が注目したのが変化点検出のChangeFinder。これは「具体的にはわからないけど何かしら変化があった。」という瞬間を検出をする処理です。閾値処理のように高周波な変化やノイズに反応しにくく、傾向の変化を捉えるので、サンプルデータを入手しにくく定義困難な異常の検出に向いています。

 

インストール方法

私が実行した環境はUbuntu14.04です。以下を実行すればOKです。

が、しかし、これだけでは動かないこともあります。だいたいこのあたりを追加すれば動きます。(うろ覚えでスイマセン。。。)

 

サンプルソースと実行結果

ガウス分布で疑似的にデータを作り出してChangeFinderするサンプルがよく公開されてます。ソースと実行結果は以下の通り。

赤色がデータ値、青色がChangeFinder結果。データ値(赤色)の高周波な変動には反応せず、元となるガウス分布が変化しときにChangeFinder(青色)が反応しているのがわかります。こういった「そもそものデータ発生源の傾向変化」は単純な閾値処理では検出できません。

 

手持ちのデータに適用してみた

これだけじゃ面白くないので適当に採取したデータにChangeFinderを実行してみました。csvファイルを読み込んで実行するようにpythonプログラムを少々変更しています。

対象データは、とある楽曲演奏時のdB値を加工したものです。イントロ⇒メロ⇒サビといった雰囲気の変化を「やかましさの傾向変化」でキャッチできないかなという実験です。

う~ん、微妙。。。07:00:00と22:00:00にサビで盛り上がる場面がくるのですが、捉えられているといえば捉えられてる・・・か??

ここから先はChangeFinderの3パラメータ調節が必要そうですね。このあたりはまた次回に調べてみます。

それではまた

クラウドの対義語「オンプレ」とは? ~その1~

こんにちは、ロードローラーです。今日は「オンプレ」について整理してみました。

普段からIoTやデータ分析に携わっている私ですが、あるとき「で?オンプレとクラウドとどっちが適切なの?」と質問されてΣ(゚д゚) エッ!?っとなった次第です。

まずは、オンプレの定義から確認しますね。

オンプレミス 【 on-premises 】 自社運用:
組織における情報システムの設置形態の分類。クラウドの普及に伴って対義語として広まった呼称がオンプレ。

想像ですが、一昔前はなんでもかんでもオンプレ型で運用していて、クラウドの登場によって皆がどんどんクラウド型に移行した。しかしその後、やはりクラウド型だけでなくオンプレ型も使いこなさなければならない事情が出てきたのだと思います。クラウドとオンプレをハイブリッドに使いこなすためのサービスも次々と登場しているくらいですからね。

そしておそらく、大きな理由は①セキュリティ②データ量の増大かと。。。IoTやセンシング技術の発展によってデータ量は膨大になりましたし、個人情報を含んだデリケートな情報も増えてますからね。

企業様は導入や拡張が容易なクラウドを活用したいものの、セキュリティ観点や従量課金制の料金モデルを背景にオンプレも使いこなさなければならない状態なのだと思います。

<クラウドとオンプレの比較>

クラウド型
・外部の事業者が用意した機材やソフトウェアを通信回線を経由して利用する
・遠隔地の機器との通信に伴う通信遅延や通信障害が発生する
・機密情報を他社の機器上に保管することになる
・提供される構成や機能でしか利用できない
・導入が用意
・初期費用が低い
・拡張しやすい

オンプレミス型
・自社に機器を設置してシステム運用する
・自社内の機器を利用するので通信遅延等の心配なし。
・機密情報を自社の機器上に保管できるので安心
・構成や機能を自由にカスタマイズ可能
・導入に時間がかかる
・初期費用が高くつきやすい
・拡張や変更に手間がかかる

とりあえず今日はここまで