サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
都知事選
takuti.me
『PyTorchのautogradと仲良くなりたい』でPyTorchに入門したので、応用例としてMatrix FactorizationをPyTorchで実装してみようね 1。 Matrix Factorization Matrix Factorizationは以前『Courseraの推薦システムのコースを修了した』でも触れたとおり、ユーザ-アイテム間の $m \times n$ 行列を、ユーザの特徴を表す行列 $P \in \mathbb{R}^{m \times k}$ (user factors) とアイテムの特徴を表す行列 $Q \in \mathbb{R}^{n \times k}$ (item factors) に分解する: これを二乗損失のSGDで素直に実装すると、user_factors と item_factors の更新や評価値予測はこんな感じ: import nump
Amazonのビジネスモデルから大切なことを学びましょう、といった趣旨の本を読んだ: The Amazon Way on IoT: 10 Principles for Every Leader from the World's Leading Internet of Things Strategies いろいろなビジネス書やえらい人の講演で断片的に語られる、聞けば(フムフム)と思える程度の内容がコンパクトにまとまっていた。新しいことをはじめるときに、チェックリスト的に使えそう。 ちなみにタイトルの "IoT" は釣りで、トレンドにのっただけのように思えた。読者の興味がIoTにあるか否かに依らず、広く応用できそうな真っ当な話が多い。 Customer Obsession 前提知識として、Amazonでは "Customer Obsession"(お客様第一)という全社的な理念があることを覚え
EuroScipy 2017 でPythonの concurrent.futures についての話を聞いたので、改めて調べてみた。 2系まではPythonの並列処理といえば標準の multiprocessing.Pool が定番だったけど、3系からは新たなインタフェースとして concurrent.futures という選択肢もふえた。 Scalaなんかでおなじみの Future とは、並行処理の結果を参照する存在。Pythonの Future f = concurrent.futures.Future() は処理の『実行中 f.running() 』『キャンセル済み f.canceled() 』『完了 f.done() 』といった“状態”を参照するメソッドを提供している。そして f.result() を呼べば完了までブロッキング。 実際には、非同期処理は Executor オブジェクトに
(希望) せっかくEuroScipy 2017でFacebook AI researchのSoumith Chintala氏から直に PyTorch のお話を聞いたので、触ってみるしかないぞ!と思いました。 特に、PyTorchのウリだと言っていた autograd(自動微分)が気になるので、まずは公式チュートリアルから入門してみる。 x という変数を requires_grad=True オプション付きで定義する。値は1: import torch from torch.autograd import Variable # [x1, x2; x3, x4] = [1, 1; 1, 1] x = Variable(torch.ones(2, 2), requires_grad=True) "PyTorch is numpy alternative" と言うだけあって、配列(テンソル)操作は
Yahoo!がOSSとして開発している異常検知フレームワーク "EGADS" (Extensible Generic Anomaly Detection System) について書いた次の論文を読んだ: Generic and Scalable Framework for Automated Time-series Anomaly Detection (KDD 2015) リアルタイムなデータをモデリングする種のアルゴリズムの実装とはどうあるべきなのか、という話は難しい。 僕も異常検知や情報推薦のためのアルゴリズムをパッケージ化してみてはいるものの、 時系列データの入力、モデリング、予測、出力といったコンポーネントをいかに切り分けて実装するか バッチとオンラインアルゴリズムのバランスをいかに取るか どこまで自動化して、どこにヒューリスティクスを取り入れる余地を残すか といった点は本当に悩ま
8月30, 31日にドイツのエルランゲンで開催された EuroSciPy 2017 に発表者として参加してきた。カンファレンス参加を積極的にサポートしてくれる弊社に感謝感謝。 このカンファレンスは "Scientific Computing in Python" に関するあらゆる話題が対象で、numpy, scipy, matplotlib, pandas, Jupyter notebooks あたりが絡んでいればよろしい。SciPy Conference US のヨーロッパ版ということになる。本会議前2日間はチュートリアル、9月1日にはSprintもあったけど、そっちは不参加。 全体で200名程度の参加があったらしい。思っていたよりもずっと賑やかな会議だったなーという印象がある。参加者のバックグラウンドは教授から学生、企業の研究者、データサイエンティスト、エンジニアまで様々。 しゃべった
Holt-Winters Method(別名: Triple Exponential Smoothing)というデータの予測手法がある。これについて素晴らしい解説記事があるので読みながら実装していた。 コードは takuti/anompy にある。 この手法、Graphite が実装しているということもあり、近年ではDevOpsコミュニティを中心に一躍有名になったんだとか。 ここでは解説記事の内容に沿って、Holt-Winters Method に至るまでに知っておくべき手法たちの“気持ち”をまとめる。数式は元記事やWikipediaに譲る。 問題 『連続するN点の時系列データを観測していたとき、N+1点目の値を予測する問題』を考える。 もし次の瞬間の値が予測できれば、そこからデータの“異常”を察知することができる。 たとえばDatadogなどで監視しているシステムのメトリクスを対象とすれ
先週はPostgreSQL上でテキストのFuzzy Searchを試した。そのときは fuzzystrmatch や pg_trgm といったモジュールが活躍していた。 では、同じことをHiveで実現するとどうなるだろう。 データ 適当にテーブル sample をつくっておく: hive> CREATE TABLE sample AS > SELECT 1 AS id, 'I live in Tokyo.' AS document > UNION ALL > SELECT 2 AS id, 'Are you happy?' AS document > ; hive> SELECT * FROM sample; OK sample.id sample.document 1 I live in Tokyo. 2 Are you happy? Time taken: 0.066 seconds,
Seven Databases in Seven Weeks を読んでいたら、PostgreSQLでテキスト検索をする話が出てきた。先日 Levenshtein Distance(編集距離)について書いたばかりでホットな話題なので、少し遊んでみよう。 $ postgres --version postgres (PostgreSQL) 9.6.3 ※インデックスと英語以外の言語の場合については割愛。 データ お気に入りのアメリカのクラフトビールデータセットを使う。適当に create table してCSVからデータを読み込む: create table beers ( key int, abv real, ibu real, id int, name varchar(128), style varchar(64), brewery_id int, ounces real ); \copy
WikipediaはAPIがあったり、データのMySQLダンプを惜しみなく公開していたりする。便利。しかし、いかんせん規模が大きいので、APIアクセスやRDBへの問い合わせに依存したデータ収集は辛いものがある。 今回はWikipediaデータの中でも、特に『カテゴリ』を効率的にdigる方法を fastcat というPythonコードから学ぶ。 ゴール Wikipedia上の、あるカテゴリに対する上位・下位カテゴリの一覧を得る。 たとえば、英語版Wikipediaの Computers というカテゴリには、 上位カテゴリ Office equipment Computing 下位カテゴリ Computer hardware companies Computer architecture Classes of computers Information appliances Computing
ある文字列Aに対して『1文字の追加・削除・置換』を何回繰り返せば他の文字列Bになるか。このときの最小回数を、文字列A, B間の編集距離 (Levenshtein Distance)と呼ぶ。 花火 から 火花 までの編集距離は各文字の置換なので 2 クワガタ から カブトムシ までの編集距離はなんかもう全文字違うので総入れ替え&文字『シ』の追加で 5 この編集距離、文字列の“類似度”と見ることができて、なかなか便利な子である。『Job Titleの前処理&クラスタリングをどうやって実現するか問題』では、人々の肩書きを編集距離を使って前処理(クラスタリング)している事例も紹介した。 さて、ここでは Levenshtein Distance を求めるアルゴリズムを実装して、備忘録として書き留めておく。ネット上にも多数の解説記事があり「今更ァ?」という話だが、正直どれを読んでもピンとこなかったのだ
しましょう。 gensim とは、人類が開発したトピックモデリング用のPythonライブラリです。 良記事『LSIやLDAを手軽に試せるGensimを使った自然言語処理入門』のサンプルコードが少々古いので、最新版で改めてやってみる次第。 準備 Index of /jawiki/latest/ から jawiki-latest-pages-articles.xml.bz2 を入手する。下手すると数時間かかる。 コーパス 基本的には英語版Wikipediaからコーパスを作る公式サンプルがそのまま使える。 我々は gensim.corpora.WikiCorpus が内部的に使っている分かち書き用の関数 gensim.corpora.wikicorpus.tokenize を日本語向けに置き換えればよろしい: import gensim.corpora.wikicorpus as wikicor
データマイニングの現場で頻発する Leakage という問題について本気出して考えてみた、的な論文を読んだ: Leakage in Data Mining: Formulation, Detection, and Avoidance. KDD 2011. 概要 Leakage とは、モデルを作るときに、本来知らないはずの情報(変数やデータ)を不当に使ってしまうこと 手元のデータではメッチャ高い精度が出たのに、本番環境ではまったく精度が出ない、といった事態になる その問題について定式化を試みると同時に、Leakage を検知・回避する方法を考える こういう議論がまじめにされてこなかったせいで、KDD Cup 2008 のようなプロが企画・主催したコンペでさえ、問題の不備による Leakage が発生している おもしろ事例集 はじめに、データマイニングコンペでの Leakage 事例が幾つか紹
DMM英会話を1ヶ月間やってみて思う、オンライン英会話は『やらないよりマシ』なのか問題 #DMM英会話 話の種にDMM英会話を1ヶ月間やってみた1。1日25分×30日間で5500円。安い。方針は次のような感じ: 基本的にレッスンは朝、出社前に自宅で。たまに夜。寝ぼけてても酔ってても頑張る。 ネイティブオプション(課金)は使わない。 講師はリピートせず、多様な人と話す。 いろいろなレッスン内容を試す。 以下、自戒の念も込めつつこの1ヶ月を振り返る。 序 はてな民なんてここ数年ずっと、英語の勉強のやり方の勉強ばっかりやってる。 — 【英語スレ】ネットでただで勉強できる教材教えてくれ とか | ライフハックちゃんねる弐式 本記事は個人の感想をつらつらと書き連ねるだけのものですが、個人的にオンライン英会話は目的がハッキリしていれば『やらないよりマシ』だと思います。 その上で、1ヶ月続けてみて、『や
IEEE Internet Computingの2017年5・6月号に "Two Decades of Recommender Systems at Amazon.com" という記事が掲載された。 2003年に同誌に掲載されたレポート "Amazon.com Recommendations: Item-to-Item Collaborative Filtering" が Test of Time、つまり『時代が証明したで賞』を受賞したことをうけての特別記事らしい 1。 「この商品を買った人はこんな商品も買っています」という推薦で有名なAmazonが1998年にその土台となるアルゴリズムの特許を出願してから20年、彼らが 推薦アルゴリズムをどのような視点で改良してきたのか 今、どのような未来を想像するのか その一端を知ることができる記事だった。 アイテムベース協調フィルタリング 20年前も
Q&Aサイトにおける質問推薦、そして Incremental Probabilistic Latent Semantic Analysis トピックモデリングの一手法として有名な Probabilistic Latent Semantic Analysis (PLSA) を incremental(逐次更新可能, オンライン型)アルゴリズムに拡張して、Yahoo!知恵袋のようなQ&Aサイトの質問推薦に応用した論文を読んだ: Hu Wu, et al. Incremental Probabilistic Latent Semantic Analysis for Automatic Question Recommendation. RecSys 2008. 推薦システムのトップ会議 RecSys の2008年の採択論文なのでとても古く、アブストでは "web 2.0" という渋い記述も見られる
途中長いこと放置していたせいで takuti/nand2tetris の initial commit から1年くらい経ってしまったけど、『コンピュータシステムの理論と実装』を読み終えた。 内容 『コンピュータシステムの理論と実装』(通称 nand2tetris)は、その名の通りNANDのような論理演算からテトリスのようなアプリケーションの実装までを一気に学ぶことでコンピュータシステム全体を俯瞰しましょう、という一冊。 章が進むにつれてハードウェアからソフトウェアへと話が進んでいき、各章には“プロジェクト”として何らかの実装パートがある。実装の結果は予め用意されたシミュレータやエミュレータを通して確認・デバッグできる。 公式サイト 目次を見るとそれだけでワクワクする: Boolean Logic HDLでANDやORなどの論理ゲートを実装する Boolean Arithmetic HDLで
情報推薦=機械学習 ではない。 もちろん機械学習アルゴリズムを使えば精度は高くなるかもしれないが、実際は推薦理由の説明が必要であったり、膨大なデータサイズや要求されるパフォーマンスに応えるために、『いかに機械学習をしない選択をするか』も重要になる。 さらに、RecSys2016のLinkedInとQuoraのチュートリアルで語られたように、現実の推薦システムはヒューリスティクスに基づく単純な手法から深層学習まで、複数のものを組み合わせた ハイブリッド なものであることが多い。 ヒューリスティクス/機械学習の混在したハイブリッドな推薦手法 適切な指標による精度の評価とモデルの改善 サービスごとに異なる多様なデータフォーマットの扱い ということを考えると、推薦システム専用の実装 というものが必要になってくる。というわけで、推薦システム構築に使える/参考になるOSSをいくつか紹介する。 ※チョイ
これが行動履歴から傾向を判断し、推薦につなげていく基本的なアイディアになる。そして 共に好まれやすい傾向 をログから数値的に見つけ出してくれる機能を備えたのが、Mahoutというライブラリだ。 3. 高速な検索技術を活用する 今、きんモザとごちうさが共に好まれやすいという傾向がわかった。それでは、ここでもし新しい登場人物・サトシが "きんモザ BD" というキーワードでAmazonを検索していたら、Amazonのシステムはどう対応すべきだろう? 答えはシンプルだ。すかさず、ごちうさのBDも こんな商品もいかがですか? と表示すればいい。 (ここまで書いてから確かめたら案の定そうなった) これが現実的なシーンでの推薦システムの動きになる。傾向に基づいた推薦は闇雲に広告を打つよりよっぽど賢いし、効果的だ。 ただし、「きんモザで検索していたら、すかさずごちうさも表示する」という推薦処理は高速に行
今週から Coursera の Big Data Analysis with Scala and Spark を受講している。その初回で出てきた "Why Scala? Why Spark?" に関する議論をざっくりとまとめる。(導入なので『RDDとは』みたいな話はしない) Stack Overflow Developer Survey 2016 "Top Paying Tech in US" を見ると、なんと上位2つが Spark と Scala になっている: なぜこんなに人気なのか? 時はビッグデータ戦国時代、もちろん「大規模データを効率的に処理できるから」という事実が一因であることは言うまでもない。しかし、それ以上に強調すべき点がある。 Developer Productivity Dr. Heather Miller いわく Scala, Spark を選択する理由は、それらが
会津大学から東大情報理工へ進学して早2年、この春無事に修士号をゲットした。めでたい。 この2年間はこれまでの人生で最も濃く、楽しい時間だった。関わったすべてのみなさんに感謝したい。積もる話は山ほどあるけど、ここでは研究活動でこの2年間を振り返ってみる。 修士課程で僕が置かれた状況は標題の通りで、この分野の人気が高まっている昨今、卒業論文や修士論文のテーマ設定に際して同じような境遇のひとは少なくないと思う。この記事がひとつの事例として、そんなみなさんの参考になれば。 ※個人の経験を述べるだけで、『機械学習を学ぶ際のオススメテキスト』とか『数学の知識はこれさえあればOK!』といった内容ではない。 TL;DR 大学院の外に“先生”を求める ガチっぽい機械学習関連のインターンに参加する(3社;e.g., 『Treasure Dataインターンにみる機械学習のリアル』) 機械学習サマースクールに行く
"Deep Work"を読んだけど微妙だったから皆は"How to Write a Lot"と"エッセンシャル思考"を読めばいい ―と思いました。 MIT卒のコンピュータ科学者によって書かれた本『Deep Work: 大事なことに集中する』を読んだ。が、冗長かつ抽象的な内容で、非常に退屈な一冊だった。 主張 「集中して長時間、中断することなく知的作業を続けること (Deep Work) が生産性を高め、大きな仕事を成し遂げることにつながる」ということを言っている。構成としては、成功者たちの実例を示して主張に説得力を持たせた上で、実践にあたってのTips的な部分を延々と述べている。ざっくりまとめると次のような感じ。 『何かを作り出さなければ、成功しない』 自分のスキルは作り出した成果物で示せ 生産性を高めるためには『難しいが重要な知的作業をまとめて、長期間、中断することなくつづけること』が大
AUCの実装 is 台形(長方形)の面積の逐次計算 この True Positive が False Positive より上位にランキングされるか という考えを念頭に置くとAUCの実装が理解しやすい。 具体的には、降順にソートされた予測スコア pred と、それらの真のラベル label を順に処理して、各時点での True Positive, False Positive の増分から面積を求めて加算的に計算していく。 コードにすると以下のような雰囲気。 def trapezoid(x1, x2, y1, y2): """与えられた長方形(台形)の面積を求める """ base = abs(x1 - x2) height = (y1 + y2) / 2. return base * height def auc(pred, label): """ソート済スコアとラベルのリストからAUCを
"SLIM: Sparse Linear Methods for Top-N Recommender Systems"を読んだ Matrix Factorizationよりも高い精度が出るという話をよく聞く Sparse Linear Method (SLIM) を提案した論文を読んだ。 Xia Ning and George Karypis. SLIM: Sparse Linear Methods for Top-N Recommender Systems. ICDM 2011. 概要 Top-N推薦を高速に行う Sparse Linear Method (SLIM) を提案する。 ユーザ-アイテム行列 $A \in \mathbb{R}^{\textrm{\#user } \times \textrm{ \#item}}$ の未観測値を $\tilde{A} = AW$ のように補完す
昨年、Hive向けの機械学習ライブラリ Hivemall がApache Software Foundationのincubatorプロジェクトになった。Treasure Dataがオフィシャルでサポートしているということもあり、名前くらいは聞いたことがあるという人も多いと思う。 とはいえ、やれHadoopだHiveだとスケールの大きな話をされると、手元でちょっと試すなんて気分にはならないものである。というわけで、実際にMacのローカルでHadoop, Hiveの導入からHivemallを動かすまでをやってみた。 Hadoopのインストール $ brew install hadoop (今回のバージョンは 2.7.3) /usr/local/Cellar/hadoop/{バージョン} 以下を直接漁ることになるのでエイリアスを設定しておく。 export HADOOP_DIR=/usr/lo
昨年の話だけど、Courseraで開講されていた "Introduction to Recommender Systems" を履修・修了した。教えてくれたのはこの分野で知らぬ者はいない、ミネソタ大学のJoseph Konstan先生。2000年あたりの協調フィルタリングなど古典的な推薦手法に関する文献を漁ると、必ず彼のグループの論文にたどり着く。かの有名なMovieLensデータセット(画像処理でいうMNIST的な、定番データセット)も、このグループが提供している。 コースは全8回で内容は以下。 Introduction to Recommender Systems 推薦システムの歴史やその背景 Non-Personalized Recommenders 『最も人気のアイテムを常に推薦する』といった、個人化を行わない推薦手法 Content-Based Recommenders TF-I
Last week, I introduced a Julia package for recommender systems: Recommendation.jl: Building Recommender Systems in Julia. However, its functionality is still low, and I argued that implementing more powerful recommendation techniques and update() function is important. Thus, this article provides FluRS, another open-sourced library for recommendation. Unlike Recommendation.jl, this recommender-sp
8月1日から9月30日まで、大学院の同期で小学生時代は落ち着きがなかった @ganmacs と、小学校の給食ではソフト麺が出なかった @amaya382 と一緒に Treasure Data (TD) Summer Internship に参加した。 Treasure Data インターンで最高の夏過ごしてきた #td_intern - memo-mode トレジャーデータでインターンしてた話 #td_intern - 水底 インターンの途中で1週間アメリカへ行ってしまうという事情を酌んだ上で採用していただき、限られた期間で物凄く適切な課題設定とメンタリングを行なってくださった@myuiさんには頭が上がらない。本当にありがとうございました。 TDインターン全体としての見どころは、 全方位ウルトラエンジニアで気を抜くと死ぬ環境 丸の内の一食1000円オーバーの飲食店事情 ラウンジの炭酸強めで
推薦システムのトップ会議 RecSys2016 が9月15日から19日までアメリカのボストンで開催され、ワークショップ発表者&学生ボランティアとして参加してきた。これまで学会発表はひとりで行くことが多く、今回も例外ではなかったが、ボランティアのおかげで他の学生との交流や伝説的な研究者との接触が多くてとても楽しめた。みんなもやると良いと思う。 RecSys2016@Boston RecSysは今回で10回目を迎えた推薦システムのトップ会議で、本会議の採択率はショートペーパーでも20%という狭き門。僕はワークショップのひとつ Profiling User Preferences for Dynamic Online and Real-Time Recommendations(長い)で、ECサイトとかでよく見られる persistent cold-start という問題と、それに絡めて Fact
次のページ
このページを最初にブックマークしてみませんか?
『blog.takuti.me』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く