Hugoでポートフォリオサイトみたいなものを作ってGitHub Pagesで公開した

最近アウトプットを増やしたいという思いがあり、とりあえず形からでもと思ってポートフォリオサイトっぽいものを作ろうと思いました。

どうやって作ろうかと思っていた中で、何となく知っていたHugoとかSphinxみたいな単語で調べてみると、そもそも静的サイトジェネレータというものがあることを知りました。

この辺の説明は以下のスライドが分かりやすかったです。

slideship.com

最近はほぼPythonばかり触っていることもあり、普通ならSphinxとかを選択するかもしれませんが、さすがにPythonばかりだとな、、、という思いがあり今回はHugoを選択しました。特に深い理由はありません。

ちなみに静的サイトジェネレータのメリットとしてはHTMLとかを書く必要がないことのようですが、テンプレート的なものを自分の用途に変えようと思うと普通にHTMLを書く必要がありました。この辺はもっと良いやり方があったのかもしれません。

作成したサイトはGitHub Pagesで公開しました。

GitHub PagesはGitHubが提供している静的サイトのホスティングサービスです。

今回作成したサイトは以下のものです。

kishimoto-banana.github.io

Hugoの使い方

基本的にはHugoのquick startを参照しました。

gohugo.io

Hugoのインストール

MacOSであればHomebrewでインストールできます。

brew install hugo

ウェブサイトを作成する

以下のコマンドで my_site という名前で新しいHugoのプロジェクトを作成します。

hugo new site my_site

Gitリポジトリの作成・テーマの追加

https://themes.gohugo.io/ から使いたいテーマを選択し、submoduleとして追加します。今回はGoaというテーマを選択しました。

cd my_site
git init
git submodule add https://github.com/shenoybr/hugo-goa.git themes/hugo-goa

テーマを適用

実際にテーマを適用してサイトを作成します。 ここからのやり方は複数あるような気がしますが、今回はテーマのディレクトリ以下にあるディレクトリをプロジェクト直下のディレクトリにコピーして適用します。

Goaの場合、具体的には themas/hugo-goa/ 以下から layouts を、 themas/hugo-goa/exampleSite 以下から contentstaticdataconfig.toml をコピーします。

ここでHugoサーバを起動します。

hugo server

http://localhost:1313/ にアクセスすれば、テーマのデモサイトと同じ内容が表示されるはずです。

カスタマイズ

基本的な変更は、プロジェクトディレクトリ直下の config.toml を変更します。

ただしサイトの構成を変えるような変更は、layouts 直下のHTMLファイルを修正しなければなりません。

例えば今回採用したテーマのGoaは、トップページから自己紹介ページやブログページに遷移する構成でしたが、自分はトップページに経歴などの内容を全て記載したかったので、 layouts 以下にHTMLファイルを追加しました。

GitHub Pagesでホスティング

こちらも基本的には以下のHugoのドキュメントを参照しました。 gohugo.io

場合によって2つの方法があるようです。

https://<username>.github.io/ というURL、もしくはhttps://<username>.github.io/<projectname> といったように任意のプロジェクトのURLの場合です。

今回は前者の場合です。

2つのリポジトリを作成

ソース管理リポジトリをcloneする

git clone <my-siteリポジトリのURL>

作成したHugoプロジェクトのコピー

cloneした my-site に Hugoプロジェクトの my_site 以下をコピーする。

cp -p -f -R my_site/* my-site/

ローカルで動作確認

my-site ディレクトリに移動して、再度ローカルにてHugoサーバを起動して表示内容を確認します。

cd my-site
hugo server

http://localhost:1313/ にアクセスして内容を確認します。

問題なければ Ctrl+C で停止します。

publicディレクトリを公開先リポジトリとしてサブモジュール化

publicディレクトリを削除して、公開先リポジトリとしてサブモジュール化します。

rm -rf public
git submodule add -b master https://github.com/<username>/<username>.github.io.git public

リモートリポジトリにpush

ドキュメントに載っていたシェルを叩くだけです。

#!/bin/bash

echo -e "\033[0;32mDeploying updates to GitHub...\033[0m"

# Build the project.
hugo # if using a theme, replace with `hugo -t <YOURTHEME>`

# Go To Public folder
cd public
# Add changes to git.
git add .

# Commit changes.
msg="rebuilding site `date`"
if [ $# -eq 1 ]
  then msg="$1"
fi
git commit -m "$msg"

# Push source and build repos.
git push origin master

# Come Back up to the Project Root
cd ..

後は https://<username>.github.io/ にアクセスすれば自分のサイトが公開されています。

PyData.tokyo One-day Conference 2018に参加した

PyData.tokyo One-day Conference 2018に参加したので、メモ書きを記載する。

pydatatokyo.connpass.com

なお自分の記憶のためのメモなので、内容の正確さは保証できません。

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)などで並列化してくれているので、余計な処理は邪魔
  • GPUの場合
    • CPUとGPUの通信のストリーム
      • GPUの演算が終了する前に次の演算を開始
      • GPUに演算は非同期に実行
      • データ転送は同期的に実行
      • ストリームを活用できれば、演算中に次の演算のデータ転送
    • Nvidia Visual Profiler
  • マルチGPUの場合
    • それぞれのGPUは別々のストリームで通信

PythonによるWikipediaを活用した自然言語処理 @山田育矢 (Studio Ousia)

参考

前置き

  • Wikipedia自然言語処理に使うと良い
    • テキストコーパスとして
    • 記事の見出し語(エンティティ)を辞書として活用
    • エンティティのリダイレクト構造
    • リンク

Wikipediaをテキストコーパスとして使う

  • DBpediaプロジェクトがテキストやリンクなどをRDF形式で配布
  • 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がプロジェクト開始
  • 成果例
  • NIPSでもワークショップ

Materials Informaticsの基礎

  • 分子の文字列表現
    • SMILES
  • 記述子
    • つまり特徴量
    • 材料から記述子Xを定義
    • 材料Xと物性Yの関係を Y=f(X)
  • Fingerprint
    • Extended Connectivity FingerPrint (ECFP)

PythonでMaterials Informatics

  • RDkitライブラリ
  • 具体例
    • 溶解度予測(物質の解けやすさ)
    • 記述子を入力として溶解度を予測する問題

最近の動向

  • 分子生成
  • そもそもGAN
    • Generatorが人工データ生成
      • 生成モデル
    • Discriminatorがデータの真偽を識別
  • SeqGAN
    • 分子のsmilesで次に来る記号に利得が最大になるように分子を生成
  • ORGAN
  • MolGAN
    • 分子をグラフ構造の生成
  • smilesの文法に従うように生成する方法

ソニーが提供するディープラーニングの開発環境の最新情報 @成平 拓也 (Sony)

開発者向けソフトウェア

ソニーグループ内事例

Neural Network Libraries

  • Mixed Precision学習
    • NVIDIAPascal世代以降のGPUを用いた場合に利用できる
    • 可能な限りfloatの32bitの代わりに16bitの表現を用いた学習
    • メモリ使用量削減
    • NVIDIAのVOLTA世代以降では、TenserCoreによる高速化の恩恵

ソニー不動産におけるビジネス現場での活用と運用

...

データサイエンスのワークフローを加速する為のNVIDIA GPU

NVIDIAについて

  • ...

データサイエンティストのためのNVIDIAのソリューション

  • RAPID
    • GPUでデータサイエンスのフローを加速
      • データの読み込み、加工、学習などのフローをGPUで高速に
      • データサイエンスの問題点
        • 前処理が重い
        • 学習が重い
        • ここらをGPUで加速
      • RAPIDSライブラリ
      • GPU DataFrame
        • Apach Arrowの仕様に基づいている
          • Apach arrow
            • 背景としてライブラリによってデータフォーマットが異なる
            • 変換が重い
            • 通化したい
          • libgdf
            • Cから使える
          • Pygdf
          • dask_gdf
      • 配布
      • RAPIDSの使用例
        • dockerコンテナpullすればすぐに使える
        • pandasで読み込んでgdfに変換できる
        • メソッド等はpandasライクに書ける
  • GPUのメモリサイズ小さくてデータ入らないのでは?
    • GPUも進化してるもんね?

競馬予測の苦楽 @heartz2001

自己紹介

  • Fringe81
  • 普段はレコメンド
  • +競馬予測

競馬予測の楽しみ

  • 毎週解くべき問題となるデータが追加
  • 結果がリアルタイムで映像で確認できる
  • データ豊富
  • 日本競馬の難易度
    • JRAに売上の20~25%が入るようにオッズが動的に変化
      • パチンコは15%程度
    • ランダムに購入すると回収率の期待値は75~80%程度
    • 回収率100%の壁を超えることは難しいが、不可能ではない

競馬予測の苦しみ

  • 問題設定
    • 出走馬1頭1頭に関数fを学習して、スコア化
    • 何を解くのか?
      • 分類?回帰?ランキング?
      • 分類
        • 0/1に丸めると情報が欠落
        • ラベル不均衡
      • 回帰
        • 自由度高く選択が難しい
      • ランキング
        • 回帰よりも学習コストが重いかつ精度もそんなに高くない
      • 回帰の目的関数
        • 着順
        • タイム
        • 本賞金
        • etc...
      • 目的関数のエンジニアリング
        • 特徴量作成やハイパーパラメータ調整より重要
        • 試行錯誤するしかない
          • 30種類くらい試している
        • ドメイン特価のエンジニアリング
          • レース内標準化
            • 絶対的なタイムに意味はないので
          • 4位以下のスコア同じに
            • 馬券に絡まないので
        • 解く問題を分ける
          • 強さ
          • 回収しやすさ
          • 人気
  • データ整形
    • 馬柱をモデル化してデータ処理を簡潔に
  • 特徴量
    • 出走履歴
      • 可変長
      • 過去N走の成績を横に並べる
        • 出走数が馬ごとに異なるので欠損値が多く発生
        • 次元数の割に情報量が少ない
      • 集計値に丸める
        • 次元数を丸めて情報密度が高い
      • RNNのような可変長な入力をとれるモデルを選択するアプローチ
        • 時系列データ
      • 集計特徴量
        • レース条件の切り分け方は競馬ドメイン知識が必要
  • オッズ
    • 馬券発売締切まで変動
  • レース区分
    • 競馬場
    • 芝・ダート
    • 距離
    • etc...
  • レース区分ごとに予測モデルを作成
    • どの粒度が適切かは特徴量と目的変数に大きく依存
  • 学習
    • LightGBM
    • カテゴリ変数をカテゴリ変数として扱うことが可能
    • 欠損値を欠損値として扱うことができる
    • GCEのプリエンプティブインスタンス
      • 利用料金約70%OFF
      • 1プロジェクト72CPU
        • それ以上はプロジェクト分ける必要
        • プロジェクト間でイメージのコピーはできない
      • 予告なしに落ちる、探索状態を逐次保存、再開できるように
      • 学習に進捗をslackに通知
  • 評価
    • nDCG
      • ランキング問題でよく使われる
      • 非負かつ高ければ良いもの
      • 競馬だと賞金
    • 評価データの期間
      • 年間3000レース
      • 季節性なども考慮して最低1年間は評価に必要
      • コースの改修があるので古いデータは役にたたない
  • 勝てる馬券≠売れる馬券
    • ....
  • ...

Daskによる並列分散処理 @堀越 真映 (ARISE)

Daskとは

  • 問題
    • 計算が単一スレッドで行われるため処理速度が遅い
    • データがメモリに乗らない
  • 解決策
    • 並列処理
      • 複数のタスクを並列に
    • Out-of-core処理
      • メモリに乗らないデータを逐次処理する
  • Dask
    • データ処理、数値計算が主目的
      • Numpy、Pandasと同じように使える
    • データ構造
      • Dask Array
        • NumPyのndarray
      • Dask Dataframe
        • pandasDataFrame
    • Dask Array
      • Numpyのndarrayを分割
      • np.ones*1 -> dx = da.ones*2, chunk=(5,5))
        • 内部で5×5の4つの行列に分割
        • 計算グラフを作成するだけ、メモリの確保はしていない
      • dy = dx.sum(axis = 0)
        • axis=0に沿って値を計算
      • dy.compute()で初めて計算が行われる
        • 結果はndarrayで得られる
      • chunk間の処理が発生するときは、chunkサイズを一致させたほうがいい
    • 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を並列で行う
          • テストデータが大きいとき有効
    • Dask Distributed
      • ノード間分散処理を行うスケジューラを提供
      • スケジューラでの計算を複数ノードで分散
        • 低レイテンシ
        • worker間でのデータ共有
      • プラガブルAPI
        • withブロックでjoblib.Parallelの既定バックエンドを変更可

*1:10, 10

*2:10, 10

NumPyでmatrixなら行列の積を*演算子で書けるしPython3.5以上なら@演算子で書ける

Python数値計算ライブラリであるNumPyについて、2014年くらいからちゃんと調査せずに使っていたが、@演算子で行列の積を計算できることを知って色々調べてみた。

そもそも、影響を受けてるはずのMATLABでも*演算子は行列の積だし、C++のEigenでも*演算子は行列の積なのに、何故NumPyだけ*演算子が要素積なんだろう。

なお、NumPyのmatrixについて紹介するが、公式ドキュメントには以下のように書かれており、基本的には使うべきでないかもしれない。

It is no longer recommended to use this class, even for linear algebra. Instead use regular arrays. The class may be removed in the future.

numpy.matrix — NumPy v1.15 Manual

普通の積はnp.dot()

import numpy as np

X = np.array([[0, 1],
             [2, 3]])
print(type(X))
# <class 'numpy.ndarray'>
print(np.dot(X, X))
# [[ 2  3]
#  [ 6 11]]

# メソッドでも可能
print(X.dot(X))
# [[ 2  3]
#  [ 6 11]]

matrixなら*演算子で書ける

X_mat = np.matrix([[0, 1], 
                 [2, 3]])
print(type(X_mat))
# <class 'numpy.matrixlib.defmatrix.matrix'>
print(X_mat * X_mat)
# [[ 2  3]
#  [ 6 11]]

# もちろんnp.dot()の可能
print(np.dot(X_mat, X_mat))
# [[ 2  3]
#  [ 6 11]]

Python3.5以上なら@演算子で書ける

X = np.array([[0, 1],
             [2, 3]])
print(X @ X)
# [[ 2  3]
#  [ 6 11]]

X_mat = np.matrix([[0, 1], 
                 [2, 3]])
print(X_mat @ X_mat)
# [[ 2  3]
#  [ 6 11]]

Display Advertising with Real-Time Bidding (RTB) and Behavioural Targetingを読む (1. Introduction)

ディスプレイ広告に関連することがほとんど全て書かれている本、”Display Advertising with Real-Time Bidding (RTB) and Behavioural Targeting”がarXivで公開されているため、読んでいる。

[1610.03013] Display Advertising with Real-Time Bidding (RTB) and Behavioural Targeting

内容をまとめていく。

1. Introduction

広告とは、潜在的な顧客が商品を購入したりサービスに加入したりすることを促すマーケティングメッセージである。

広告を掲載する主なチャネルとして、テレビ、ラジオ、新聞、雑誌などが存在するが、多くのビジネス・サービスがオンライン空間上に移行しているので、インターネットは潜在的な顧客を獲得する自然な選択である。

ディスプレイ広告やモバイル広告における近年の最重要な進歩は、リアルタイムオークションを可能にするReal-Time Bidding (RTB)の進歩である。

科学的には、RTBの自動化・統合・最適化のさらなる需要により、情報検索(IR)、データマイニング(DM)、機械学習(ML)、経済学などの分野で新たな研究分野が生じる。

例えば、情報検索の研究者は、広告キャンペーンの目標が与えられたとき、潜在的なオーディエンスとの関連性を定義するという課題に直面しており、その結果、リアルタイムの入札リクエストデータを基に潜在的なオーディエンスを見つけてフィルタリングする技術を開発している。

データマイニングの研究者の基本的なタスクは、入札リクエスト、落札単価、広告インプレッションの大規模なデータに対する繰り返しパターンを特定することである。

機械学習の研究者にとって、新たな問題は、コストを最小限に抑えながらコンバージョンを最大化するために、広告主のために上手に入札することを学習するなど、データを基に機械に学習させることである。

さらに興味深いことに、インプレッション単位の最適化によって広告主と代理店は、自身やサードパーティの複数のデータソースから得られるユーザーデータに基づいた有効性を最大化することができる。

広告主は、クリック数やコンバージョンなどの特定のKPIを最大化するために複数のサイト運営者からインプレッションを購入し、サイト運営者は収益を最適化するためにインプレッションを複数の広告主へ販売する。

これにより、オンライン広告市場は、市場の統合が強く推進されている金融市場に近づいている。

ウェブページ、広告主、ユーザー間でクリックやコンバージョンを最適化するなどの共通の目的は、機械学習データマイニング、情報検索、行動ターゲティングを、ゲーム理論、経済学、最適化と組み合わせた多分野にわたる多大な研究を必要とする。

急速な成長と巨大な可能性にもかかわらず、RTBの多くの側面はさまざまな理由で研究コミュニティに対して未知のままである。

この本では、実世界システムに関する知見を提供し、産学間のギャップを埋めるとともに、オンライン広告の最先端のインフラ、アルゴリズム、技術的課題および研究課題の概要を提供する。

1.1 A short history of online advertising

最初のオンライン広告はウェブ上には約3,000万人にしかいなかった、1994年に現れた。

HotWiredの1994年10月27日号のWeb版は、AT&Tのバナー広告を初めて表示した。

1.1.1 The birth of sponsored search and contextual advertising

スポンサードサーチの枠組みは1998年にIdealabのBill Grossによって作成された。

IdealabはGoto.comに設立されたが、Goto.comは、Yahoo!によって2003年に買収され現在のYahoo! Search Marketingとなっている。

一方、Googleは2002年2月にGSP(Generalized Second Price Auction)を使用して独自のサービスAdWordsを開始し、2002年5月に品質基準の入札を追加した。

2007年、Yahoo! Search Marketingも続いて、品質基準の入札を追加した。

スポンサードサーチにおける検索結果と広告を一致させる技術に関する特許紛争を解決するため、Googleが270万株をYahoo!に支払ったことに言及する価値はある。

スポンサードサーチでは、広告主はビジネスを促進するために特定のキーワードを購入することができ、ユーザーはそのような検索エンジンを使用することで、継続的に無料サービスに貢献することができる。

一方、1998年に、ディスプレイ広告がコンテキスト広告として開始された。

Gilad ElbazとAdam Weissmanが始めたOingoは、単語の意味に基づいた独自の検索アルゴリズムを開発し、WordNetと呼ばれる根本的な辞書を作成した。

Googleは2003年4月にOingoを買収し、そのシステムの名前をAdSenseとした。

その後、Yahoo! Publish Network、Microsoft adCenter、およびAdvertising.comなどの多くが、同様のサービスを提供するために作成された。

コンテキスト広告プラットフォームは、ビデオ、オーディオ、地理情報を含むモバイルネットワークなど、より豊かなメディア環境に適応して進化た。

これらのプラットフォームにより、サイト運営者はウェブページ、ビデオクリップ、アプリケーション上のスペースの一部を使ってお金を稼ぐことができた。

通常、このようなサービスは、広告ネットワークまたはディスプレイネットワークと呼ばれ、膨大な数のサイト運営者や広告主から構成されるため、必ずしも検索エンジンを必要としない。

スポンサードサーチ広告は、単純なコンテキスト・クエリキーワードと一致するコンテキスト広告の一種と考えることもできるが、初期の発達、市場の大規模化、研究の注目を受けて重点を置かれてきた。

1.1.2 The arrival of ad exchange and real-time bidding

2005年頃にインプレッションを売買することに基づくreal-time bidding (RTB)に焦点を当てた新しいプラットフォームが作成された。

例としては、ADSDAQ、AdECN、DoubleClick Advertising Exchange、adBrite、Right Media Exchangeなどがある。

これらはad exchangesとして知られている。

従来の広告ネットワークとは異なり、これらの広告交換は複数の広告ネットワークをまとめて集め、市場での需要と供給のバランスをとっており、ユーザの訪問によって生成された広告のインプレッションをリアルタイムで販売する。

サイト運営者や広告ネットワークは、そのようなビジネスに参加することで利益を得ることができる。

サイト運営者は、関連するユーザープロファイルとコンテキストに興味のある広告主にインプレッションを販売するが、広告主はより多くのサイト運営者に接触してより良いマッチングのインプレッションをリアルタイムで購入することができる。

同時に、異なる機能を持つ他の同様のプラットフォームが出現した。

(i) demand side platform (DSP)

広告主がキャンペーンを管理し、各入札リクエストに対するリアルタイムの入札レスポンスをアルゴリズムによってad exchangesに応答する。

(ii) supply side platform (SSP)

サイト運営者がウェブサイトの広告在庫を管理する。

しかし、real-time bidding (RTB)や複数の広告ネットワークの集約は、そのような市場(インプレッションの売買が行われる場所)の性質を変えることはなく、オークションの仕組みを介してリアルタイムで取引を行う。

簡単のために、取引が行われるより広いプラットフォームを表現するために、この本で"ad exchanges"という用語を使用する場合がある。

1.2 The major technical challenges and issues

リアルタイム広告は、時間の経過とともに大量のデータを生成する。

グローバルなDSPのFikisuは、毎日320億件、ピーク時間に毎秒250万件のインプレッションを処理していると主張している。

規模をより想像するための例として、ニューヨーク証券取引所は毎日約120億株を取引している。

ディスプレイ広告の取引量はすでに金融市場を上回っている。

さらに重要なのは、ディスプレイ広告産業は、コンピュータサイエンスの研究者や経済学者に、インターネットのトラフィック、ユーザーの行動や動機、オンライン取引を研究して理解するユニークな機会を提供する。

この業界だけが、広告取引におけるウェブサイトやユーザー全体にわたるほぼすべてのウェブトラフィックを集計している。

RTBエコシステムは、Cookieベースのユーザー追跡と同期によるリアルタイムのインプレッション購入により、ユーザーの行動ターゲティングとパーソナライゼーションの力を完全に引き出す機会とインフラを提供する。

これは、機械駆動アルゴリズムが、広告とユーザとの間の関連性の一致を自動化および最適化することを可能にする。

RTB広告は、ユーザーの反応(クリックスルー率、CTR)推定、行動ターゲティング、知識抽出、関連性フィードバック、不正検知、経済学、推薦システムやパーソナライゼーションなど、多くの研究課題におけるデータサイエンス研究の重要な戦場になっている。

1.2.1 Towards information general retrieval (IGR)

オンライン広告の基本的な技術目標は、広告主とサイト運営者が合意した適切な価格で適切なユーザーに適切な広告を適切なタイミングで自動的に配信することである。

そのため、RTBベースのオンライン広告は、情報検索(IR)の分野と強く相関している。

これは、伝統的に情報のニーズと文書の関連性を構築することに重点を置いている。

情報検索の研究は、典型的にはテキストデータを扱うが、画像、ビデオ、およびオーディオ信号を含むマルチメディアデータに拡張されている。

また情報検索の研究は、Collaborative FilteringとRecommender Systemsを含む、カテゴリデータと順位データもカバーしている。

これらのすべてのケースにおいて、情報検索の重要な研究課題は、検索とフィルタリングの2つの特有のタスク、すなわちクエリとドキュメントの関連性を研究し、モデル化することである。

検索タスクは、情報のニーズ(クエリ)がアドホックであり、ドキュメントの集合は比較的静的である。

対照的に、情報フィルタリングタスクは、情報のニーズ(クエリ)が静的であるときに定義され、ドキュメントはシステムに入り続ける。

情報検索は、Web検索やエンタープライズ検索の応用を超えて、他の多くの応用に由来する一般的な検索の問題について考えることで、研究範囲を広げることができる。

基本的に、2つの情報オブジェクト間の対応を構築することに興味がある限り、様々な目的と基準の下で、一般的な検索問題とみなすことができる。

オンライン広告はこの応用分野の1つであり、この本では新しい情報の一般的な検索問題(IGR)を明らかにしたい。

例えば、リアルタイムに広告に提示する技術は、情報検索とデータマイニング機械学習および他の関連分野の豊富な文献に基づいて構築され、広告とユーザとの間の関連性マッチングに関連する様々な問いに答えることができる。

しかし、典型的な情報検索問題と比較した差異と難点は、様々な経済的制約を考慮していることにある。

制約の一部は、オークションの仕組みから継承された動機に関連するものもあれば、参加者(広告主およびサイト運営者)の異なるの目的に関連するものもある。

さらに、RTBは、2つの一致した情報オブジェクトの間で双方向で統一された、関連性マッチングの有用なケースを提供する。

RTBでは、広告、ユーザー、サイト運営者の間に内部的なつながりがある。

広告主は、潜在的なユーザーと広告のマッチングによって最終的にコンバージョンにつながることを望んでいる。

一方サイト運営者は、広告とウェブページのマッチングによって高い報酬を得ることを望んでいる。

関連性が計算されるとき、両方の目的は達成されることを必要とする。

1.3 The organisation of this monograph

この本の対象読者は、この分野の学術研究者および業界実務家である。

その目的は、読者がドメイン知識を取得し、一般的なRTBとオンライン広告で研究活動を促進することである。

本の内容は主に4つである。

まず第2章と第3章では、RTB広告とその仕組みの概要を説明する。

具体的には、第2章では、業界で普及している主流のユーザー追跡と同期技術と同様に、RTBがどのように動作するかについても説明する。

第3章では、オークション市場におけるRTBオークションの仕組みと、その結果として得られる予測手法について紹介する。

次に、広告主の視点から問題を説明する。

第4章では、過去に提案されたさまざまなユーザー応答モデルを説明して、ユーザーをターゲットにし、潜在的なユーザーのパターンに合わせて広告を作成する。

第5章では、さまざまな市場設定での広告主の視点から最適な入札を提示する。

第6章では、サイト運営者に焦点を当てて、最低入札価格の動的設定、プログラムによる直接販売、新しいタイプの広告契約について説明する。

この本は、RTBの2つの重要な主題である、第7章のアトリビューションモデルと第8章の広告不正検知で終わる。

読者の技術的背景や興味に応じていくつかの読書経路がある。

学術研究者のために、第2章と第3章は、現在産業に展開されているリアルタイムのオンライン広告システムを理解するのに役立つ。

後の章では、産業界の実務者がこの分野の研究課題、最先端のアルゴリズムおよび潜在的な将来のシステムを把握するのに役立つ。

これらの後の章は特殊なトピックに関するものなので、より深いレベルで個別に読むことができる。

BUMP OF CHICKENの歌詞をスクレイピングした

何故したか

仕事において自然言語処理をする機会が増えそうであり、自然言語処理っぽいことをしてみたかった。

また、某ゲームのED曲がBUMP OF CHICKENの新曲かと騒がれるほど曲の雰囲気が似ていると言われているので、類似具合を定量評価したかった。

www.youtube.com

やったこと

J-LyricのwebサイトからBUMP OF CHICKENの歌詞のみをスクレイピングしました。

今回も、Python+Beautiful Soupでスクレイピングしました。

曲のタイトルをファイル名とするテキストファイルで保存しました。

以下にソースコードを示します。

import urllib.request
from bs4 import BeautifulSoup
import re
import time

fqdn = 'http://j-lyric.net'
path_bump = '/artist/a000673/'
url = fqdn + path_bump

response = urllib.request.urlopen(url)
data = response.read()
soup = BeautifulSoup(data, "lxml")

select1 = soup.find("div", id="mnb")
select2 = select1.find("div", class_="cnt")

contents = select2.find_all('div', id=re.compile('ly'))

for i in range(len(contents)):
    select4 = select2.find("div", id="ly" + str(i+1))
    select5 = select4.find('p', class_='ttl')
    title = select5.find('a')
    title = re.sub('<a href=".+">', '', str(title)).replace('</a>', '')
    
    path_lyric = select5.a.get('href')
    response_lyric = urllib.request.urlopen(fqdn + path_lyric)
    data_lyric = response_lyric.read()
    soup_lyric = BeautifulSoup(data_lyric, "lxml")

    select6 = soup_lyric.find("div", id="mnb")
    select7 = select6.find("div", class_="lbdy")
    select8 = select7.find("p", id="Lyric")
    lyric = str(select8).replace('<p id="Lyric">', '').replace('</p>', '').replace('<br/>', '\n')
    
    f = open(title + '.txt', 'w')
    f.write(lyric)
    f.close()
    
    # スクレイピングマナー
    time.sleep(1)

今後やりたいこと

Doc2Vecなどを使って、歌詞の類似度を算出したい。

また音の特徴量を抽出して、曲調の類似度も算出したい。

ベイズ統計モデルを勉強している

『岩波データサイエンス Vol.1』を読んでいます。

https://www.amazon.co.jp/%E5%B2%A9%E6%B3%A2%E3%83%87%E3%83%BC%E3%82%BF%E3%82%B5%E3%82%A4%E3%82%A8%E3%83%B3%E3%82%B9-Vol-1-%E5%B2%A9%E6%B3%A2%E3%83%87%E3%83%BC%E3%82%BF%E3%82%B5%E3%82%A4%E3%82%A8%E3%83%B3%E3%82%B9%E5%88%8A%E8%A1%8C%E5%A7%94%E5%93%A1%E4%BC%9A/dp/4000298518

前からベイズ統計に興味があったので、その勉強内容をまとめます。

今回は、『階層ベイズ最初の一歩』の内容をトレースしてみます。

問題設定

日本国内の10県で、県ごとに異なる2種類の給食タイプが身長ののびに影響を与えるか調査。

半分の5県では普通の給食、もう半分が異なるタイプの給食を与えられる。

現在の身長と、1年後の身長を測定し、特殊なタイプの給食の効果を推定する。

正解としては、特殊なタイプの給食が身長に与える効果は無い。

以下に解析対象のデータを示す。

測定回目の0が現在の身長測定結果を、1が1年後の測定結果を表す。

給食タイプの0が普通の給食を、1が特殊な給食を表す。

つまり、県A,B,D,E,Iが特殊な給食を与えられる県。

f:id:pompom168:20171217204501p:plain

モデル1 直線あてはめ

後日まとめます。。。

モデル2 ベイズモデル

後日まとめます。。。

以下、コードと結果なぶり書き。

library(rjags) # R と JAGS をつなげる package
library(R2WinBUGS) # write.model() 使うため
model.bugs <- function()
{
  for (i in 1:N) {
    mean.Y[i] ~ dnorm(mu[i], tau)
    mu[i] <- beta[1] + (beta[2] + beta[3] * X[i]) * Age[i]
  }
  for (k in 1:N.beta) {
    beta[k] ~ dunif(-10000, 10000)
  }
  tau <- 1/(sd * sd)
  sd ~ dunif(0.00000E+00, 10000)
}
file.model <- "model.bug.txt"
write.model(model.bugs, file.model)

load("data.RData") # データ d の読みこみ
N.beta <- 3 # beta[1], beta[2], beta[3]
list.data <- list( # データ
  mean.Y = d$mean.Y,
  X = d$X, Age = d$Age,
  N = nrow(d), N.beta = N.beta
)
# パラメーターの初期値
list.inits <- list(beta = rep(0, N.beta), sd = 1)

# 事後分布からのサンプリングの詳細
n.burnin <- 1000
n.chain <- 3
n.thin <- 10
n.iter <- n.thin * 3000

model <- jags.model(
  file = file.model, data = list.data,
  inits = list.inits, n.chain = n.chain
)
update(model, n.burnin) # burn in

# 推定結果を post.mcmc.list に格納する
post.mcmc.list <- coda.samples(
  model = model,
  variable.names = c("mu", names(list.inits)),
  n.iter = n.iter,
  thin = n.thin
)

pdf("plot1.pdf") 
plot(post.mcmc.list) 
dev.off()

以下、パラメーターの事後分布。 f:id:pompom168:20171217210446p:plain

回帰分析と機械学習で中央線の高コスパ物件を探す(コスパ高物件導出)

前回は、家賃予測モデルの生成を行いました。

pompom168.hatenablog.com

今回は、Random Forestで生成した家賃予測モデルを使って、コスパ高物件を見つけます。

予測された家賃より実際の家賃が安いほうが、コスパが高いとします。

結果

1位〜5位を掲載します。

f:id:pompom168:20171204183529p:plain

最もコスパが高い物件は、三鷹駅の物件で予測家賃より実際の家賃が65,626円も安くなりました。

その物件が以下のものです。 f:id:pompom168:20171204185656p:plain

三鷹の2LDKの家賃相場が約16万(2017/12/4ホームズ調べ)の中では、かなりお買い得なのではないでしょうか。

これで終わりです。

これからも、色々なデータを扱って遊んでみたいと思います。