PyData.tokyo One-day Conference 2018に参加した
PyData.tokyo One-day Conference 2018に参加したので、メモ書きを記載する。
なお自分の記憶のためのメモなので、内容の正確さは保証できません。
PyData.Tokyo
データ分析のための Python パフォーマンスチューニングテクニック @atsuoishimoto
PythonとNumPyの歴史
- Pythonは科学技術計算に昔から強い(IEEEでも紹介)
- 1995年くらいにはNumPyの前進numericがあった
- NumPy
- NumPyが科学計算ライブラリエコシステムの核
- C拡張ライブラリの作成簡単さ
- 元々NumPyはPythonの標準ライブラリとして開発
- NumPyのellipsis
- NumPyのndarray(Cでの構造体)はPythonのデータ交換用として登録
分析処理の平行処理
- マルチプロセス、マルチスレッドにして高速化したいんですけど、、、
- 実際はそんなに早くならない
- 計算量・データ量の削減が基本
- concrurrent.futures
- threadingやmultiprocessよりこっち使うべき
- マルチスレッド vs マルチプロセス
- データ処理であれば可能ならマルチスレッドで
- GIL (Global Interpreter Lock)
- Pythonインタプリタは複数のスレッドを同時に実行できない
- GILを持つスレッドだけが処理を実行可
- GILは定期的な開放(5ms)以外に、自発的に開放できる
- Pythonの処理以外(printとかのosの機能など)はGIL必要ない
- つまり、Python以外の機能の部分をGILを持つスレッド以外で実行すれば良いよ
- NumPyの場合のマルチスレッド
- numpy.add()
- マルチスレッドでもマルチプロセスでも対して高速化できない
- 最近のCPUであれば行列の足し算は高速
- マルチスレッド、マルチプロセス化のオーバヘッドの方が基本的に大きい
- 4スレッド/プロセス程度くらいまではパフォーマンス向上
- NumPyはGILを解放するので、マルチスレッド有効
- numpy.dot()
- マルチスレッド/プロセスで遅くなること多々
- 内部のライブラリ(BLAS)などで並列化してくれているので、余計な処理は邪魔
- numpy.add()
- GPUの場合
- CPUとGPUの通信のストリーム
- GPUの演算が終了する前に次の演算を開始
- GPUに演算は非同期に実行
- データ転送は同期的に実行
- ストリームを活用できれば、演算中に次の演算のデータ転送
- Nvidia Visual Profiler
- CPUとGPUの通信のストリーム
- マルチGPUの場合
- それぞれのGPUは別々のストリームで通信
PythonによるWikipediaを活用した自然言語処理 @山田育矢 (Studio Ousia)
参考
- https://github.com/ikuyamada/wikipedia-nlp
- https://www.slideshare.net/ikuyamada/pythonwikipedia-120034699
- https://github.com/wikipedia2vec/wikipedia2vec
前置き
- Wikipediaを自然言語処理に使うと良い
- テキストコーパスとして
- 記事の見出し語(エンティティ)を辞書として活用
- エンティティのリダイレクト構造
- リンク
Wikipediaをテキストコーパスとして使う
- DBpediaプロジェクトがテキストやリンクなどをRDF形式で配布
- wikiマークアップの除去を行わなくていい
- dumpしたやつよりこっちの方が良い
- word2vecで簡単に単語表現学習できるよ
WIkipediaから表記ゆれしやすい文字ペアを抽出
- wikipediaリダイレクト
- エンティティにアクセスする際のある程度の表記揺れを解消する機能
- 日本語で67万件
- 同義語辞書として使用できる
- wikipediaのリダイレクトを全て集計
- レーベンシュタイン距離が1のエンティティペアを抽出
- 異なる文字のペアをカウント
- カタカナ、漢字、記号などの表記ゆれ
- 旧字体と新字体とかも
- wikipedia2vec
wikipediaエンティティ辞書を活用する
- アップルが”アップル(企業)”なのか”リンゴ”なのか
- 記事に出現するリンクについて、リンクテキスト(エンティティ名)とリンク先(エンティティ)を記録して集計
- 専門用語や固有名詞を含む辞書
- エンティティ辞書の2つの指標
- リンク確率
- コモンネス
- 利用例1(単語・フレーズ辞書)
- エンティティ名で辞書作成 - リンク確率でエンティティ名フィルタリング
- 利用例2(エンティティリンキング)
- ある文章から辞書に含まれるエンティティ名を抜き出して、該当するwikipediaのエンティティを抽出 - wikipediaの情報を用いたタグ付け - テキスト分類にエンティティを用いる
wikipediaから単語とエンティティのベクトル表現を学習する
- word2vecを拡張、単語+wikipediaエンティティを同一空間にマップ
- エンティティは曖昧性や表記ゆれがない
- wikipediaに含まれる世界の物事の知識を自然にモデル化
- 手法の詳しいことはGithubとかみて
- 高速化
- 実装の大半をCythonを用いてCに変換
- skip-gramでは、学習対象の単語やエンティティのペアからベクトルを更新する処理を高速に行う必要
- 可視化
- TensorBoardのProjector
wikipedia2vevとエンティティリンキングで早押しクイズAI
- Quiz bowl
- 質問が与えられて、文が説明しているwikiのエンティティを予測
- クイズをテキスト分類で解く
- 文章の単語と出現したエンティティ
- エンティティは、質問文からエンティティリンギングで抽出
Pythonでマテリアルズ・インフォマティクス ~機械学習と物性・材料の融合領域~ @福島 真太朗 (TOYOTA)
Materials Informaticsの存在
- 物性・材料とデータ科学の融合領域
- 従来
- 材料を作って物性値を調べる
- Materials Informatics
- 欲しい物性を持つ材料を見つける
- 歴史
- 2011年にアメリカでオバマ政権が始めた
- 日本でも2015年にNIMSがプロジェクト開始
- 成果例
- 富士通・理研
- TDK・京都大学
- NEC
- NIPSでもワークショップ
Materials Informaticsの基礎
- 分子の文字列表現
- SMILES
- 記述子
- つまり特徴量
- 材料から記述子Xを定義
- 材料Xと物性Yの関係を Y=f(X)
- Fingerprint
- Extended Connectivity FingerPrint (ECFP)
PythonでMaterials Informatics
- RDkitライブラリ
- 大部分はC++で実装
- https://www.rdkit.org/
- Chem.MolFromSmiles(smiles)
- 記述子の計算
- 多くの方法が用意
- 具体例
- 溶解度予測(物質の解けやすさ)
- 記述子を入力として溶解度を予測する問題
- ここにデータある?
最近の動向
- 分子生成
- そもそもGAN
- Generatorが人工データ生成
- 生成モデル
- Discriminatorがデータの真偽を識別
- Generatorが人工データ生成
- SeqGAN
- 分子のsmilesで次に来る記号に利得が最大になるように分子を生成
- ORGAN
- SeqGANでsmiles生成、強化学習で評価
- MolGAN
- 分子をグラフ構造の生成
- smilesの文法に従うように生成する方法
ソニーが提供するディープラーニングの開発環境の最新情報 @成平 拓也 (Sony)
開発者向けソフトウェア
- Neural Network Libraries
- 研究開発者向けフレームワーク
- オープンソース
- Neural Network Console
- GUIツール
ソニーグループ内事例
- 画像認識
- aibo
- ジェスチャー認識
- Xperia Ear
- 価格推定
Neural Network Libraries
- Mixed Precision学習
- NVIDIAのPascal世代以降のGPUを用いた場合に利用できる
- 可能な限りfloatの32bitの代わりに16bitの表現を用いた学習
- メモリ使用量削減
- NVIDIAのVOLTA世代以降では、TenserCoreによる高速化の恩恵
ソニー不動産におけるビジネス現場での活用と運用
...
データサイエンスのワークフローを加速する為のNVIDIA GPU
NVIDIAについて
- ...
データサイエンティストのためのNVIDIAのソリューション
- RAPID
- GPUでデータサイエンスのフローを加速
- データの読み込み、加工、学習などのフローをGPUで高速に
- データサイエンスの問題点
- 前処理が重い
- 学習が重い
- ここらをGPUで加速
- RAPIDSライブラリ
- cuDF
- データをGPUに配置
- cuML
- 機械学習
- cuGRAPH
- グラフ解析
- cuDF
- GPU DataFrame
- Apach Arrowの仕様に基づいている
- Apach arrow
- 背景としてライブラリによってデータフォーマットが異なる
- 変換が重い
- 共通化したい
- libgdf
- Cから使える
- Pygdf
- Pythonから使える
- dask_gdf
- Apach arrow
- Apach Arrowの仕様に基づいている
- 配布
- dockerコンテナ
- ソースコード
- RAPIDSの使用例
- dockerコンテナpullすればすぐに使える
- pandasで読み込んでgdfに変換できる
- メソッド等はpandasライクに書ける
- GPUでデータサイエンスのフローを加速
- GPUのメモリサイズ小さくてデータ入らないのでは?
- GPUも進化してるもんね?
競馬予測の苦楽 @heartz2001
自己紹介
- Fringe81
- 普段はレコメンド
- +競馬予測
競馬予測の楽しみ
- 毎週解くべき問題となるデータが追加
- 結果がリアルタイムで映像で確認できる
- データ豊富
- 日本競馬の難易度
- JRAに売上の20~25%が入るようにオッズが動的に変化
- パチンコは15%程度
- ランダムに購入すると回収率の期待値は75~80%程度
- 回収率100%の壁を超えることは難しいが、不可能ではない
- JRAに売上の20~25%が入るようにオッズが動的に変化
競馬予測の苦しみ
- 問題設定
- 出走馬1頭1頭に関数fを学習して、スコア化
- 何を解くのか?
- 分類?回帰?ランキング?
- 分類
- 0/1に丸めると情報が欠落
- ラベル不均衡
- 回帰
- 自由度高く選択が難しい
- ランキング
- 回帰よりも学習コストが重いかつ精度もそんなに高くない
- 回帰の目的関数
- 着順
- タイム
- 本賞金
- etc...
- 目的関数のエンジニアリング
- 特徴量作成やハイパーパラメータ調整より重要
- 試行錯誤するしかない
- 30種類くらい試している
- ドメイン特価のエンジニアリング
- レース内標準化
- 絶対的なタイムに意味はないので
- 4位以下のスコア同じに
- 馬券に絡まないので
- レース内標準化
- 解く問題を分ける
- 強さ
- 回収しやすさ
- 人気
- データ整形
- 馬柱をモデル化してデータ処理を簡潔に
- 特徴量
- 出走履歴
- 可変長
- 過去N走の成績を横に並べる
- 出走数が馬ごとに異なるので欠損値が多く発生
- 次元数の割に情報量が少ない
- 集計値に丸める
- 次元数を丸めて情報密度が高い
- RNNのような可変長な入力をとれるモデルを選択するアプローチ
- 時系列データ
- 集計特徴量
- レース条件の切り分け方は競馬ドメイン知識が必要
- 出走履歴
- オッズ
- 馬券発売締切まで変動
- レース区分
- 競馬場
- 芝・ダート
- 距離
- etc...
- レース区分ごとに予測モデルを作成
- どの粒度が適切かは特徴量と目的変数に大きく依存
- 学習
- LightGBM
- カテゴリ変数をカテゴリ変数として扱うことが可能
- 欠損値を欠損値として扱うことができる
- GCEのプリエンプティブインスタンス
- 利用料金約70%OFF
- 1プロジェクト72CPU
- それ以上はプロジェクト分ける必要
- プロジェクト間でイメージのコピーはできない
- 予告なしに落ちる、探索状態を逐次保存、再開できるように
- 学習に進捗をslackに通知
- 評価
- nDCG
- ランキング問題でよく使われる
- 非負かつ高ければ良いもの
- 競馬だと賞金
- 評価データの期間
- 年間3000レース
- 季節性なども考慮して最低1年間は評価に必要
- コースの改修があるので古いデータは役にたたない
- nDCG
- 勝てる馬券≠売れる馬券
- ....
- ...
Daskによる並列分散処理 @堀越 真映 (ARISE)
Daskとは
- 問題
- 計算が単一スレッドで行われるため処理速度が遅い
- データがメモリに乗らない
- 解決策
- 並列処理
- 複数のタスクを並列に
- Out-of-core処理
- メモリに乗らないデータを逐次処理する
- 並列処理
- Dask
- データ処理、数値計算が主目的
- Numpy、Pandasと同じように使える
- データ構造
- Dask Array
- NumPyのndarray
- Dask Dataframe
- pandasDataFrame
- Dask Array
- Dask Array
- Dask DataFrame
- 複数のPands DataFrameで構成
- indexに沿ってPartitionに分割
- 2つの表ができるイメージ
- ddf = dd.from_pandas(df, 2)
- ddf.mean()
- 計算グラフの実行イメージ
- 計算グラフの依存関係の解析
- 不要なタスクの削除
- 計算順序の静的・動的な解析
- 計算グラフの最適化
- 特定処理のインライン化
- 計算グラフの依存関係の解析
- Linear Algebra
- コレスキー分解とか特異値分解とか
- データ処理、数値計算が主目的
機械学習におけるDaskの活用
- scikit-learnでの並列処理
- n_jobsで指定
- 内部的にはjoblibを利用
- ノード内並列 (threading, multiprocessing)
- Out-of-core (OOC) 処理はできない
- Daskでの並列処理
- Daskその前に
- 本当に全てのデータが必要?
- サンプリングでいいのでは?
- 本当に全てのデータが必要?
- Dask ML
- Daskのデータ構造に対して機械学習
- 機械学習アルゴリズムを並列化、OOC処理
- scikit-learnにDaskのarrayを投げると内部でNumPy Arrayに変換
- 逐次メモリを確保してOOMの可能性
- Dask MLではDaskのデータ構造を維持して処理を実行
- Incremental
- Daskのchunkごとにscikit-learnのpartitial_fitを行う
- ParallelPostFIt
- 学習済Estimatorのtrasnformやpredictを並列で行う
- テストデータが大きいとき有効
- 学習済Estimatorのtrasnformやpredictを並列で行う
- Dask Distributed
- ノード間分散処理を行うスケジューラを提供
- スケジューラでの計算を複数ノードで分散
- 低レイテンシ
- worker間でのデータ共有
- プラガブルAPI
- withブロックでjoblib.Parallelの既定バックエンドを変更可
- Daskその前に