不均衡データ (imbalanced data) からクラス分類を行うとき、マイナーなクラスに属するサンプルの oversampling や、メジャーなクラスに属するサンプルの undersampling (downsampling とも) が大切（cf.『不均衡データのクラス分類』）： （▲ Tom Fawcett氏による記事 "Learning from imbalanced data" 中の5番目の図を引用） このテクニックを使って学習した分類器による予測確率は、少し調整してから解釈したほうがいいらしい、という話。 Imbalanced data と Oversampling/Undersampling たとえば2クラス分類をしたいとき、ラベル1のサンプル（正例）がわずか 0.01% しか存在せず、その他 99.99% のサンプルはラベル0（負例）、みたいな状況がある。 そこまで顕著

Courseraの"Functional Programming in Scala Specialization"を修了した ここ1年くらい暇を見つけてちまちまと遊んでいたCourseraの "Functional Programming in Scala Specialization" という一連のプログラムを修了した。 4つのコースから構成されていて、（修了証は出ないけど）課題を含めてすべて無料で受講できた。課題はスケルトンコードとデータが与えられて、指定されたメソッドを実装する、というよくある形式。 Functional Programming Principles in Scala 関数型プログラミングの基礎 パターンマッチとか高階関数とかImmutableなデータ構造の話とか Functional Program Design in Scala 発展的な関数型プログラミングの概念

この記事に関連する話題: "AI"を紐解く いま、世の中は空前の人工知能ブームである。あれもこれも人工知能、こっちだってAI、そっちはディープラーニング。『ファジィ』という言葉が流行り、ファジィ炊飯器などが大量に出回った90年代を想起する先輩方も多いらしい。 一方で、バズワードとしての『人工知能』を鼻で笑うエンジニア、研究者、学生もいる。彼らは世間の期待と現実のギャップを理解している。だからこそ、そんなバズワードを安易には受け入れない。 この現状に何を思うか。 僕だって、会話の中で AI という単語がでると胸がザワザワするのが正直なところ。しかし、じゃあその言葉が使われなくなれば良いのかというと、それもちょっと違う気がする。 はむかず先生の記事『「人工知能」という言葉について考える』を読んで触発されたので、この『人工知能』という言葉の使われ方・使い方について、個人的な気持ちを書きなぐってみ

『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 事例が幾つか紹

このデータを各ユーザの demographics を表す特徴量（カテゴリ変数）として使いたい。 大まかな流れは、 前処理 クラスタリング（i.e., 次元削減 未知のJob Titleが属するクラスタの予測 こんな雰囲気。 前処理 Job Titleはユーザが好き勝手に入力したデータなので、表記揺れが激しく前処理が必須。 "Mining LinkedIn: Faceting Job Titles, Clustering Colleagues, and More" では、実際にLinkedInのデータを取得して前処理、�可視化、クラスタリングする際の流れがPythonコードと共に紹介されている。Job Titleに対して行う前処理は、"President/CEO" といったスラッシュ区切りの�Titleを分割して、略語をルールベースで展開する�というもの： transforms = [ ('