本記事について

プログラムングから長く離れていたので、練習・復讐を兼ねてPythonの超初心者用コードを実際に動かしてみました。

プログラムを実際に動かした経験を備忘録を兼ねて残しています。
誰かのお役に立てれば幸いです。

変数宣言

Pythonでは変数を事前に宣言する必要はありませんが、変数宣言は可能です。
必要性は薄いですが、可読性を高める必要がある場合などに利用します。
※実行結果は type()で確認してみてください。

# integer 型
num: int = 1

# string型
text: str = '1'

# boolean型
isEnabled: bool = True

変数名に使える文字

• 英字（小文字）
• 英字（大文字）
• 数字
• アンダースコア（ _ ）

変数名のルール

• 数字から始まるものは使えない

型の確認方法

pythonは、変数宣言（型指定）の必要がありません。
何の型が設定されているか確認する場合は、オブジェクトの型を取得・確認するtype()関数を使用します。

num: int = 1
print(num , type(num))
#1 <class 'int'>

text: str = '1'
print(text, type(text))
#1 <class 'str'>

isEnabled: bool = True
print(isEnabled , type(isEnabled))
#True <class 'bool'>

ここではPythonにsympyをインストールして連立常微分方程式を解いてみたいと思います。

sympyのサイト

https://docs.sympy.org/latest/index.html

ウォーミングアップ

まずはsympyを用いた基本的な関数の微分の例を書いておきます。

import sympy as sym
x = sym.Symbol('x')
h = x**3 + 3*x + 1
h.diff(x,1)

連立一次常微分方程式

ではおもむろに連立一次常微分方程式を解いてみましょう。

x = sym.Symbol('x')
f = sym.Function('f')
g = sym.Function('g')
h = sym.Function('h')
eq1 = sym.Eq(f(x).diff(x,1),g(x)+h(x))
eq2 = sym.Eq(g(x).diff(x,1),h(x)+f(x))
eq3 = sym.Eq(h(x).diff(x,1),f(x)+g(x))
sym.dsolve([eq1, eq2, eq3])

偏微分方程式には対応してない？

調子に乗って偏微分方程式を解いてみましょう。

偏微分の計算自体は可能です。

x = sym.Symbol('x')
y = sym.Symbol('y')
u = x**2 - y**2
u.diff(x,1)

しかし、以下の様な計算をさせようとしても上手く答えが出てきません。

x = sym.Symbol('x')
y = sym.Symbol('y')
u = x**2 - y**2
v = sym.Function('v')
eq1 = sym.Eq(u.diff(x,1), v(x,y).diff(y,1))
eq2 = sym.Eq(u.diff(y,1), -v(x,y).diff(x,1) )
sym.dsolve([eq1, eq2])

う～む…。大学２年生相当くらいまでは対応していて、３年生相当以上になるとまだちょっと対応できてないのですかね。(;^_^A

CSV

Pandasを用いたCSVの読み込み

CSVは値をカンマで区切って羅列したファイルで
データ分析等において非常に扱いやすいので、一般的によく使われます。

Pandasでcsvファイルを読み込むには、read_csv()関数を用います。

read_csv("csvファイルが置いてあるファイルパス", header=)

headerの法則として

• headerオプションを省略すると読み込んだファイルの1行目を列名とし

• header=Noneを指定するとPandasが適当な列名を割り当てます。

• header=1のように行番号を指定すると、読み込んだファイルの2行目のデータを列名とし
  それ以降の行から読み込みを開始します。

• なお、行番号は0から開始するのでデータの1行目の行番号は0になります。

例えば、列名の情報を持たないワインのデータセットをディレクトリから読み込みます。
そのままでは数値が何を表しているのか分からないので、値の内容を示す列名（カラム）を追加します。

import pandas as pd

df = pd.read_csv("./4050_data_cleansing_data/wine.csv", header=None)

# それぞれの数値が何を表しているのかカラムを追加します
df.columns = ["", "Alcohol", "Malic acid", "Ash", "Alcalinity of ash", "Magnesium","Total phenols", "Flavanoids", "Nonflavanoid phenols", "Proanthocyanins","Color intensity", "Hue", "OD280/OD315 of diluted wines", "Proline"]
df

ファイルパスの./はカレントディレクトリを示しています。
カレントディレクトリとは、現在Pythonを実行している作業ディレクトリのことです。

CSVライブラリを用いたCSVの作成

Python3に標準で搭載されているCSVライブラリを用いてCSVデータファイルを作成します。

過去10回分のオリンピック開催の都市、開催の年、季節のデータをCSVデータファイルとして出力します。

import csv

# with文を用います
# csv0.csvファイルを変数csvfileとして、書き込みモード （"w"）で開きます
with open("./4050_data_cleansing_data/csv0.csv", "w") as csvfile:
    # writerメソッドには引数として、変数csvfileと改行コード（\n）を指定します
    writer = csv.writer(csvfile, lineterminator="\n")
    # writerow（リスト）を用いて行を追加します
    writer.writerow(["city", "year", "season"])
    writer.writerow(["Nagano", 1998, "winter"])
    writer.writerow(["Sydney", 2000, "summer"])
    writer.writerow(["Salt Lake City", 2002, "winter"])
    writer.writerow(["Athens", 2004, "summer"])
    writer.writerow(["Torino", 2006, "winter"])
    writer.writerow(["Beijing", 2008, "summer"])
    writer.writerow(["Vancouver", 2010, "winter"])
    writer.writerow(["London", 2012, "summer"])
    writer.writerow(["Sochi", 2014, "winter"])
    writer.writerow(["Rio de Janeiro", 2016, "summer"])

# 出力
# csv0.csvファイルを変数csvfileとして、読み込みモード("r")で開きます
with open("./4050_data_cleansing_data/csv0.csv", "r") as csvfile:
    print(csvfile.read())

実行するとcsv0.csvというCSVデータファイルが作成され、データの内容が表示されます。
なお、CSVデータファイルを作成した場所を調べるには

import os # を行い
print(os.getcwd()) # を実行します。

Pandasを用いたCSVの作成

CSVライブラリを用いずに
Pandasを用いてもCSVデータを作成 することができます。
PandasDataFrame形式のデータをCSVデータにする時はPandasを用いた方が便利です。

Pandasでcsvファイルを作成するには、to_csv()関数を用います。

to_csv("作成するcsvファイル名")

DataFrameの例として先のサンプルと同様、過去10回分のオリンピック開催の都市、開催の年、季節のデータをCSVデータファイルとして出力します。

import pandas as pd

data = {"city": ["Nagano", "Sydney", "Salt Lake City", "Athens", "Torino", "Beijing", "Vancouver", "London", "Sochi", "Rio de Janeiro"], 
        "year": [1998, 2000, 2002, 2004, 2006, 2008, 2010, 2012, 2014, 2016],
        "season": ["winter", "summer", "winter", "summer", "winter", "summer", "winter", "summer", "winter", "summer"]}

df = pd.DataFrame(data)

df.to_csv("4050_data_cleansing_data/csv1.csv")
# これを実行するとcsv1.csvというファイルがcleansing_dataディレクトリに作成されます。

欠損値

リストワイズ削除/ペアワイズ削除

読み込んだデータに空白などがあると欠損値NaN（Not a Number）であると認識されます。データの精度を高めるために、欠損値NaNを削除するには

dropna()関数を用います。

# まずは、わざと表の一部を欠損させた表をランダムに作成します。

import numpy as np
from numpy import nan as NA
import pandas as pd

sample_data_frame = pd.DataFrame(np.random.rand(10, 4))

# 一部のデータをわざと欠損させます
sample_data_frame.iloc[1, 0] = NA
sample_data_frame.iloc[2, 2] = NA
sample_data_frame.iloc[5:, 3] = NA

sample_data_frame

リストワイズ削除

データ欠損のある行や列（NaNを含む行）をまるごと消去することを
リストワイズ削除といいます。

dropna()関数を用いて

1つでもNaNを含む行をすべて取り除きます。また
引数にaxis=1を指定すると1つでもNaNを含む列を取り除きます。

sample_data_frame.dropna()

ペアワイズ削除

リストワイズ法で欠損のある行をすべて削除してしまうとデータが少なすぎる場合
利用可能なデータのみを用いる方法もあります。
欠損の少ない列（例えば、0列目と1列目）を残し
そこからNaNを含む行を消去することをペアワイズ削除といいます。

sample_data_frame[[0, 1]].dropna()

欠損値の補完

データの精度を高めるには欠損値を削除する以外に
代替データを欠損値に代入する方法もあります。

欠損値NaNに代替データを代入（置き換え）するには

fillna()関数を用います。

わざと表の一部を欠損させた表をランダムに作成します。

import numpy as np
from numpy import nan as NA
import pandas as pd

sample_data_frame = pd.DataFrame(np.random.rand(10, 4))

# 一部のデータをわざと欠損させます
sample_data_frame.iloc[1, 0] = NA
sample_data_frame.iloc[2, 2] = NA
sample_data_frame.iloc[5:, 3] = NA
# fillna()関数を用いると、引数として与えた数をNaNの部分に代入します。今回は0で埋めてみます。

sample_data_frame.fillna(0)

# methodにffillを指定すると前行の値で埋めることができます。

sample_data_frame.fillna(method="ffill")

欠損値の補完（平均値代入法）

欠損値をその列（または行）の平均値によって穴埋めをする方法を平均値代入法といいます。

平均値はmean()関数を用いて算出します。

import numpy as np
from numpy import nan as NA
import pandas as pd

sample_data_frame = pd.DataFrame(np.random.rand(10, 4))

# 一部のデータをわざと欠損させます
sample_data_frame.iloc[1, 0] = NA
sample_data_frame.iloc[2, 2] = NA
sample_data_frame.iloc[5:, 3] = NA

# fillnaを用いてNaNの部分にその列の平均値を代入します
sample_data_frame.fillna(sample_data_frame.mean())

データ集約

キーごとの統計量の算出

統計量は代表値と散布度に区分できます。
代表値とはデータの基本的な特徴を表す値のことで
例えば、平均値、最大値、最小値などのことです。

import pandas as pd

df = pd.read_csv("./4050_data_cleansing_data/wine.csv", header=None)
df.columns=["", "Alcohol", "Malic acid", "Ash", "Alcalinity of ash", "Magnesium","Total phenols", "Flavanoids", "Nonflavanoid phenols", "Proanthocyanins","Color intensity", "Hue", "OD280/OD315 of diluted wines", "Proline"]

# DataFrame `df` のキー"Alcohol"の平均値を算出します
df["Alcohol"].mean()
# 出力結果
13.000617977528091

重複データ

データの重複がある場合、そのデータを削除してデータの精度を高めます。
実際にデータの重複があるDataFrameを用意して
重複データの抽出や削除を行ってみます。

import pandas as pd
from pandas import DataFrame

dupli_data = DataFrame({"col1":[1, 1, 2, 3, 4, 4, 6, 6]
                       ,"col2":["a", "b", "b", "b", "c", "c", "b", "b"]})
dupli_data

duplicated()メソッドを用いると

重複がある行にTrueを返すSeries型のデータを生成し、重複データを抽出します。

# 重複データを抽出します
dupli_data.duplicated()
# 出力結果
0    False
1    False
2    False
3    False
4    False
5     True
6    False
7     True
dtype: bool

dtypeとは "Data Type" のことで、要素のデータ型を示します。

drop_duplicates()メソッドを用いると、重複するデータを削除します。

dupli_data.drop_duplicates()

マッピング

マッピングとは共通のキーを持つデータに対して
別のテーブルからキーに対応する値を参照する処理です。
実際にDataFrameを用意して、マッピング処理を行ってみます。

import pandas as pd
from pandas import DataFrame

attri_data1 = {"ID": ["100", "101", "102", "103", "104", "106", "108", "110", "111", "113"]
        ,"city": ["Tokyo", "Osaka", "Kyoto", "Hokkaido", "Tokyo", "Tokyo", "Osaka", "Kyoto", "Hokkaido", "Tokyo"]
        ,"birth_year" :[1990, 1989, 1992, 1997, 1982, 1991, 1988, 1990, 1995, 1981]
        ,"name" :["Hiroshi", "Akiko", "Yuki", "Satoru", "Steeve", "Mituru", "Aoi", "Tarou", "Suguru", "Mitsuo"]}
attri_data_frame1 = DataFrame(attri_data1)

attri_data_frame1

cityに対応する地域名を持つ、辞書型のデータを作成します。

city_map ={"Tokyo":"Kanto"
          ,"Hokkaido":"Hokkaido"
          ,"Osaka":"Kansai"
          ,"Kyoto":"Kansai"}
city_map

はじめに用意したattri_data_frame1のcityカラムをキーに、city_mapから対応する地域名データを参照して、新しいカラムに追加します。これがマッピング処理です。Excelに詳しい方であればvlookup関数のような処理をイメージしてください。
map()関数を用いてマッピング処理を行い、新しいカラムとしてregionをattri_data_frame1に追加します。

attri_data_frame1["region"] = attri_data_frame1["city"].map(city_map)
attri_data_frame1

出力結果を見ると、regionカラムに地域名が追加されているのが分かります。
対応するデータがcity_mapに存在しない要素にはNaNが埋められます。

ビン分割

ビン分割とは、数値データを大まかに区切ってカテゴリ分けをする処理のことです。
例えば、年齢を0～9歳、10～19歳、20～29歳のように分ける処理です。
あらかじめビン分割したリストを用意して

pandasのcut()関数を用いて処理を行います。

import pandas as pd
from pandas import DataFrame

attri_data1 = {"ID": [100,101,102,103,104,106,108,110,111,113]
        ,"city": ["Tokyo", "Osaka", "Kyoto", "Hokkaido", "Tokyo", "Tokyo", "Osaka", "Kyoto", "Hokkaido", "Tokyo"]
        ,"birth_year" :[1990, 1989, 1992, 1997, 1982, 1991, 1988, 1990, 1995, 1981]
        ,"name" :["Hiroshi", "Akiko", "Yuki", "Satoru", "Steeve", "Mituru", "Aoi", "Tarou", "Suguru", "Mitsuo"]}
attri_data_frame1 = DataFrame(attri_data1)

分割の粒度をリストで指定し、ビン分割を実施します。ここではbirth_yearに着目します。

# 分割の粒度のリストを作成します
birth_year_bins = [1980,1985,1990,1995,2000]

#ビン分割を行いします
birth_year_cut_data = pd.cut(attri_data_frame1.birth_year,birth_year_bins)
birth_year_cut_data
# 出力結果
0    (1985, 1990]
1    (1985, 1990]
2    (1990, 1995]
3    (1995, 2000]
4    (1980, 1985]
5    (1990, 1995]
6    (1985, 1990]
7    (1985, 1990]
8    (1990, 1995]
9    (1980, 1985]
Name: birth_year, dtype: category
Categories (4, interval[int64]): [(1980, 1985] < (1985, 1990] < (1990, 1995] < (1995, 2000]]

"()"はその値を含まず、"[]"はその値を含むことを意味します。
例えば (1985, 1990] の場合、1985年は含まず，1990年は含まれます。

それぞれのビンの数を集計したい場合は

value_counts()メソッドを用います。

pd.value_counts(birth_year_cut_data)
# 出力結果
(1985, 1990]    4
(1990, 1995]    3
(1980, 1985]    2
(1995, 2000]    1
Name: birth_year, dtype: int64

それぞれのビンに名前をつけることも可能です。

group_names = ["first1980", "second1980", "first1990", "second1990"]
birth_year_cut_data = pd.cut(attri_data_frame1.birth_year,birth_year_bins,labels = group_names)
pd.value_counts(birth_year_cut_data)
# 出力結果
second1980    4
first1990     3
first1980     2
second1990    1
Name: birth_year, dtype: int64

あらかじめ分割数を指定して分割することも可能です。
これを用いると、ほぼ同じサイズのビンを作成することができます。cut()関数の第2引数に分割数を指定します。

pd.cut(attri_data_frame1.birth_year,2)
# 出力結果
0      (1989.0, 1997.0]
1    (1980.984, 1989.0]
2      (1989.0, 1997.0]
3      (1989.0, 1997.0]
4    (1980.984, 1989.0]
5      (1989.0, 1997.0]
6    (1980.984, 1989.0]
7      (1989.0, 1997.0]
8      (1989.0, 1997.0]
9    (1980.984, 1989.0]
Name: birth_year, dtype: category
Categories (2, interval[float64]): [(1980.984, 1989.0] < (1989.0, 1997.0]]

herokuでデプロイする際に、slugsizeに気を付ける必要があります。（現時点では500MB以下）
ググれば、slugsizeの削減方法が出てきます。
それだけでもダメなら、djangoのrequirement.txtからインストールに必要のないパッケージを削除すればうまくいきます。僕の場合、Tensor-flowのサイズが大きく、原因でした。

概要

• low-codeで、機械学習ができるライブラリのPyCaretがついに、v1.0になりました。
  • https://pypi.org/project/pycaret/#history
• 下記の様な記事でも、すでに紹介されています。(概要はこちらを参照下さい。）
  • 最速でPyCaretを使ってみた
  • DataRobotの無料版！？機械学習を自動化するライブラリ『PyCaret』入門
• 私が触ってみた印象だと、機械学習モデルの 可視化 がかなり便利に感じました。
• よって、モデルの可視化 に着目し、記事にしてみたいと思います。
• なお、ソースを確認すると、部分的に内部でYellowbrickを利用しているようです。

やること

列挙してみると下記の通りですが、pycaretの自動化により数行で実行できます。

• ①クレジットカードデフォルトのデータをロード
• ②前処理
• ③モデル比較（アルゴリズム間の性能比較）
• ④パラメータチューニング
• ⑤モデルの可視化（★ここがメインなので、冒頭でここを説明★）

やってみる（⑤モデルの可視化）

• 手順上は １番最後 なのですが、この記事の目的が可視化なので、最初 に扱いたいと思います。

⑤モデルの可視化

• 出来上がったモデル（tuned_model)に対してモデルの特性を可視化していきます。
• evaluate_model関数に、出来上がったモデルを渡すことで、下記のメニューが表示されます。
• tuned_modelがどう出来上がったか？は後述します。まずは可視化を説明。

evaluate_model(tuned_model)

• ハイパーパラメータの列挙、ROC曲線、混同行列等々、様々なプロットが可能です。
• 気になったものを取り上げて、一つ一つ見ていきたいと思います。

AUC (ROC曲線)

• AUCとは書いてありますが、ROC曲線を描画できます。
• 2クラス分類だったので、Positive/Negativeクラスに対して２種類描画されます。

Confusion Matrix

• こちらもよく見る混同行列です。ヒートマップで出力されます。

Error

• 実際のクラス毎に、Positive/Negativeのどちらに予測をしたか？が表示されます。

Threshold

• しきい値毎の、precision/recall/f-measureが出力されます。
• 求められる予測特性に対して、しきい値をどの程度に設定すればいいかの検討に利用できます。

Precision Recall

• 同じく予測特性の議論に利用できるのが、Precision-Recallのグラフです。
• PrecisionとRecall共に、どの程度のしきい値であれば、予測特性を満たすことができるか？の検討 に利用できます。

Learning Curve

• 学習曲線（学習の回数 vs 精度）が表示されます。
• TrainとCVセットに対してスコアが表示されるので、Underfittng/Overfittingの判断に利用できます。
• 学習曲線とunder/overfittingの判断については、StanfordのAndrewNg先生の資料が参考になります。

Validation Curve

• モデル毎の正則化パラメータに対する、Trainセット／CVセットのスコアが表示されます。
• LightGBMの場合は、max_depth(木の深さを制御する）パラメータを横軸に取ります。
• このモデルの場合、
  • max_depth=7のときに、汎化性能(CVスコア）が高い。
  • それ以上のときは汎化性能は上昇しない一方、Trainセットに対して（若干）過学習している。
  • よって、max_depthを制御したほうが良さそう。
• といった判断に利用できます。

• 正則化を制御するパラメータはモデルにより異なるため、横軸はアルゴリズム毎に異なります。
• 例えばロジスティック回帰では、正則化のパラメータは C なので、横軸はCとなります。

Feature Importance

• このモデルがどの特徴量を重要視しているか？が表示できます。

Manifold Learning

• t-SNEを利用した多様体学習（次元圧縮）の結果を表示します。
• モデルというよりは、用いている特徴量、データ自体に分解能があるのか？
• 2値分類の場合、Positive/Negativeに分離可能なのかが確認できます。
• 今回のデータでは、前処理で24列->90列まで特徴量を増やしている（後述）なので、90列を次元圧縮により2次元にし、その結果を可視化しています。

Dimensions

• こちらも、データ自体の可視化で、RadViz Visualizerの結果を表示します。

やってみる（①データロード～④チューニング）

①データロード

• pycaretには、様々なデータが搭載されています。詳細は、Getting Data - PyCaretを参照。
• 今回はクレジットカードのデフォルトを予測してみたいと思います。

from pycaret.datasets import get_data
# creditデータセットをロードします。
# profileオプションをTrue指定すると、pandas-profilingによるEDAが走ります。
data = get_data('credit',profile=False)

②前処理

• creditデータセットは、２値分類（予測対象は、 default列）です。
• よって、分類のライブラリをインポートし、targetにdefaultを指定します。

from pycaret.classification import *
exp1 = setup(data, target = 'default')

• 様々な前処理が自動で走ります。
• このデータセットの場合は、24列→90列まで特徴量が展開されます。

③モデル比較

• 下記で、複数の分類アルゴリズムに対するモデリングが可能です。
• 求める予測の特性にもよりますが、まずは、AUCで並べておきます。

compare_models(sort="AUC")

• GBM、XGB、CatBoost、LightGBM等が並びます

④パラメータチューニング

• AUCが一番良かったGBMで試しても良いのですが、比較的計算の早いlightGBMで試してみます。

tuned_model = tune_model(estimator='lightgbm')

まとめ

• モデルの可視化の方法をバラバラと書いてしまったので、最後に用途毎に整理して終えたいと思います。
• 入力データ→モデリング→結果を想定し、下記５用途でグルーピングしてみたいと思います。
  • A)　入力データや特徴量自体を理解する。
  • B)　モデルが見ている特徴量を理解する。
  • C)　モデルの予測特性や、目的が達成できるしきい値を検討する。
  • D)　モデルの学習状況（学習が足りない、過学習）を判断する。
  • E)　モデルの予測性能や予測結果を理解する。

用途	観点	可視化手段
A)入力データや特徴量自体を理解する。	正／負のデータが分離可能か	Manifold Learning
	同上	Dimensions
B)モデルが見ている特徴量を理解する。	どの特徴量が重要か	Feature Importance
C)モデルの予測特性や、目的が達成できるしきい値を検討する。	求める予測特性に対応するしきい値はどれか	Threshold
	PrecisionとRecallの関係性はどうか	Precision Recall
D)モデルの学習状況（学習が足りない、過学習）を判断する。	予測性能向上を学習回数増で実現できるか	Learning Curve
	正則化により過学習をおさえられているか	Validation Curve
E)モデルの予測性能や予測結果を理解する。	AUC（予測性能）はどの程度か。	AUC
	予測の間違い方を理解する	Confusion Matrix
	同上	Error

はじめに

機械学習の分類タスクにはその目的に応じて幾つかの性能評価指標があります。二項分類の主な性能評価指標であるROC曲線やPR曲線、そしてそのAUC(曲線の下側面積)についてまとめます。

参考

ROC曲線とPR曲線の理解にあたって下記を参考にさせていただきました。

• ROC曲線とPR曲線の違いについての考察
• scikit-learnとTensorFlowによる実践機械学習

分類タスク

文書分類タスクの具体例を交えて性能評価方法の説明を行います。その前段としてこの章では分類タスクの実施手法を簡単に記載しますが、分類タスク自体についての記事ではないためモデルの詳細な解説は省いています。

使用したライブラリ

• numpy 1.15.4
• lightgbm 2.3.1
• pandas 0.25.1
• scikit-learn 0.22.2
  

データセット

今回データセットは「livedoor ニュースコーパス」を使用しています。データセットの詳細やその形態素解析の方法は以前投稿した記事で投稿をご参照ください。

日本語の場合は事前に文章を形態素単位に分解する前処理が必要となるため、全ての文章を形態素に分解した後下記のようなデータフレームに落とし込んでいます。

一番右のカラムが文章を全て形態素解析して半角スペースごとに区切ったものになります。こちらを使用して分類タスクを実施します。

モデルの作成と分類の実施

今回は「Peachy」の記事と「独女通信」の記事(どちらも女性向けの記事)を分類します。今回は二項分類であるため、「独女通信」の記事か否かを判定する分類タスクと同義になっています。データセットを7:3に分割し、7を学習用、3を評価用にしています。

import pandas as pd
import numpy as np
import pickle
from sklearn.feature_extraction.text import TfidfVectorizer

#形態素分解した後のデータフレームはすでにpickle化して持っている状態を想定
with open('df_wakati.pickle', 'rb') as f:
    df = pickle.load(f)

#今回に2つの種類の記事を分類できるかを検証
ddf = df[(df[1]=='peachy') | (df[1]=='dokujo-tsushin')].reset_index(drop = True)

vectorizer = TfidfVectorizer()
X = vectorizer.fit_transform(ddf[3])

def convert(x):
    if x == 'peachy':
        return 0
    elif x == 'dokujo-tsushin':
        return 1

target = ddf[1].apply(lambda x : convert(x))

from sklearn.model_selection import train_test_split
X_train, X_test, y_train, y_test = train_test_split(X, target, train_size= 0.7, random_state = 0)

import lightgbm as lgb
from sklearn.metrics import classification_report

train_data = lgb.Dataset(X_train, label=y_train)
eval_data = lgb.Dataset(X_test, label=y_test)

params = {
    'boosting_type': 'gbdt',
    'objective': 'binary',
    'random_state':0
    }

gbm = lgb.train(
    params,
    train_data,
    valid_sets=eval_data,
)
y_preds = gbm.predict(X_test)

こちらで予測が完了しました。y_predsにはその文書が「独女通信」である確率の値が入っています。

分類性能の評価方法

ROC曲線とPR曲線を見ていく前にその前段である混合行列について復習しておきます。
混合行列は二項分類タスクの出力結果をまとめたマトリクスで、下記のように表されます。

	Positiveと予測された	Negativeと予測された
実際にPositiveクラスに属する	TP(真陽性)	FN(偽陰性)
実際にNegativeクラスに属する	FP:(偽陽性)	TN(真陰性)

混合行列の中の各値を使用してROC曲線を描くことができます。

ROC曲線

ROC曲線の概要

\text{FPR} = \frac{FP}{TN + FP}

\text{TPR(recall)} = \frac{TP}{TP + FN}

ROC曲線とは$\text{FPR}$(偽陽性率)に対する$\text{TPR}$(真陽性率)をプロットしたものです。
このプロットが何を意味するのかという話ですが、まずは$\text{FPR}$と$\text{TPR(recall)}$の意味を具体例に当てはめて考えます。

{{\begin{eqnarray*}

\text{FPR} &=& \frac{分類モデルが「\text{Peachy}」の記事を誤って「独女通信」の記事であると予測した件数}{実際の「\text{Peachy}」の記事の全件数} \\

\end{eqnarray*}}}

{{\begin{eqnarray*}

\text{TPR(recall)} &=& \frac{分類モデルが「独女通信」の記事であると予測した結果が正解であった件数}{実際の「独女通信」の記事の全件数} \\

\end{eqnarray*}}}

この意味を整理すると下記のように言えます。

• $\text{FPR}$は誤って陽性(「独女通信」の記事)と分類された陰性（「Peachy」の記事）データの割合を表している→陰性データの判別の不正確さ表している(低いほど良い)
• $\text{TPR}$は正しく陽性(「独女通信」の記事)と分類された陽性（「独女通信」の記事）データの割合を表している→陽性判定の網羅性を表している(高いほど良い)

つまり、$\text{FPR}$が低い状態でありながら$\text{TPR}$が高いというのが理想的です。

様々な閾値における$\text{FPR}$と$\text{TPR}$をプロットすることでROC曲線を描くことができます。「$\text{FPR}$が低い状態でありながら$\text{TPR}$が高いというのが理想的である」ということを考えると、ROC曲線のカーブの形が直角に近いほどよい=AUC(ROC曲線の下側面積)が大きいほどよい、という発想に繋がっていきます。

ROC曲線の描画

ROC曲線を実際に描画してみましょう。

from sklearn import metrics
import matplotlib.pyplot as plt
fpr, tpr, thresholds = metrics.roc_curve(y_test, y_preds)
auc = metrics.auc(fpr, tpr)
print(auc)

plt.plot(fpr, tpr, label='ROC curve (area = %.2f)'%auc)
plt.plot(np.linspace(1, 0, len(fpr)), np.linspace(1, 0, len(fpr)), label='Random ROC curve (area = %.2f)'%0.5, linestyle = '--', color = 'gray')

plt.legend()
plt.title('ROC curve')
plt.xlabel('False Positive Rate')
plt.ylabel('True Positive Rate')
plt.grid(True)
plt.show()

今回作成した分類器を用いてROC曲線を描画しました。ROC曲線の曲線が直角に近く、AUCが$0.98$(最大値が$1$)であることを考えると非常に精度が良いことがわかるかと思います。ランダムの分類器の場合AUCは$0.5$となることが決まっているため、ランダムとの比較の容易です。

PR曲線

PR曲線の概要

\text{precision} = \frac{TP}{TP + FP}

\text{recall(TPR)} = \frac{TP}{TP + FN}

PR曲線とは$\text{recall}$(再現率)に対する$\text{precition}$(適合率)をプロットしたものです。
このプロットが何を意味するのかという話ですが、まずは$\text{precition}$と$\text{recall}$の意味を具体例に当てはめて考えます。

{{\begin{eqnarray*}

\text{precision} &=& \frac{分類モデルが「独女通信」の記事であると予測した結果が正解であった件数}{分類モデルが「独女通信」の記事であると予測した全件数} \\

\end{eqnarray*}}}

{{\begin{eqnarray*}

\text{recall} &=& \frac{分類モデルが「独女通信」の記事であると予測した結果が正解であった件数}{実際の「独女通信」の記事の全件数} \\

\end{eqnarray*}}}

• $\text{precision}$は分類モデルが陽性と分類したデータ内、本当に陽性(「独女通信」の記事)であるデータの割合を表している→陽性判定の確からしさを表している(高いほど良い)
• $\text{recall}$は正しく陽性(「独女通信」の記事)と分類された陽性（「独女通信」の記事）データの割合を表している→陽性判定の網羅性を表している(高いほど良い)

つまり、$\text{precision}$が高い状態でありながら(確からしさを担保しながら)$\text{recall}$もできるだけ高い(網羅もできている)というのが理想的です。

様々な閾値における$\text{precision}$と$\text{recall}$をプロットすることでPR曲線を描くことができます。これもまたROC曲線と場合と同様にAUC(PR曲線の下側面積)が大きいほど精度が良いと言えます。

precision, recall, thresholds = metrics.precision_recall_curve(y_test, y_preds)

auc = metrics.auc(recall, precision)
print(auc)

plt.plot(recall, precision, label='PR curve (area = %.2f)'%auc)
plt.legend()
plt.title('PR curve')
plt.xlabel('Recall')
plt.ylabel('Precision')
plt.grid(True)
plt.show()

今回作成した分類器を用いてPR曲線を描画しました。AUCが$0.98$(最大値が$1$)であることを考えると、PR曲線の観点で見ても非常に精度が良いことがわかるかと思います。ただROC曲線の場合とは違ってランダムの分類器の場合でおAUCは$0.5$となるとは限りません。

ROC曲線とPR曲線

ROC曲線とPR曲線のどちらを使えばよいのか、という話ですが一般的には不均衡データの場合(negativeの数がpositiveの数よりも圧倒的に多い等)はPR曲線を使い、それ以外はROC曲線を使用するのがよいとされています。

解釈としては、ROC曲線においてはPositiveをPositiveであると判断できていること、NegativeをNegativeと判断できること両方を観点として持っていますが、PR曲線はPositiveをPositiveと判断できるていることのみに着目しています。なので、分類器の性能指標としては両方のバランスを見ているROC曲線を使用するのがよいのですが、Negativeの方が圧倒的に多い場合は大多数のNegativeをNegativeと判断することによって精度が良いと判断されてしまいます。(Positveの判断は適当であっても。)なので、少数のPositiveをちゃんと判断できているか見るためにPR曲線を使用する、というのが私の見解です。

極端な例ですが、Positive100件のデータとNegative99900件のデータにおいて、Positiveは適当に予測し、NegativeはNegativeと確実に判断するモデルがあったとします。するとROC曲線とPR曲線は下記のようになります。

rand_predict = np.concatenate((np.random.rand(100) , 0.5*np.random.rand(99900)))
rand_test = np.concatenate((np.ones(100), np.zeros(99900)))

from sklearn import metrics
import matplotlib.pyplot as plt
fpr, tpr, thresholds = metrics.roc_curve(rand_test, rand_predict)
auc = metrics.auc(fpr, tpr)
print(auc)

#ROC曲線
plt.plot(fpr, tpr, label='ROC curve (area = %.2f)'%auc)
plt.plot(np.linspace(1, 0, len(fpr)), np.linspace(1, 0, len(fpr)), label='Random ROC curve (area = %.2f)'%0.5, linestyle = '--', color = 'gray')

plt.legend()
plt.title('ROC curve')
plt.xlabel('False Positive Rate')
plt.ylabel('True Positive Rate')
plt.grid(True)
plt.show()

##PR曲線
precision, recall, thresholds = metrics.precision_recall_curve(rand_test, rand_predict)

auc = metrics.auc(recall, precision)
print(auc)

plt.plot(recall, precision, label='PR curve (area = %.2f)'%auc)
plt.legend()
plt.title('PR curve')
plt.xlabel('Recall')
plt.ylabel('Precision')
plt.grid(True)
plt.show()

AUCに大きな差があることがわかるでしょうか(ROC曲線のAUCは$0.72$、PR曲線のAUCは$0.47$)。同じデータにも関わらずみる指標によって精度の判断が大きく変わってしまいます。基本は上記の観点でROC曲線とPR曲線を使い分けつつ、タスクに応じて個別で判断することが重要です。

Next

分類以外の機械学習の性能評価についてもまとめていければと思います。

Mask R-CNNを実装してみたかった

深層学習超初心者がエラーを解決した話です。
誰かの助けになればと思い、記事を書きました。

画像認識でMask R-CNNを使ってみたい場合、matterport社のMask_RCNNというコードを利用するのが近道です。

https://github.com/matterport/Mask_RCNN

これだけ読んでも良くわからなかったので、下記のサイトを読みながら、
Google colaboratory上でdemo.ipynbを実行しようとしました。

https://tech-blog.optim.co.jp/entry/2019/03/28/173000
http://maruo51.com/2020/02/22/mrcnn/

しかし！
そのまま実行しようとしても、

AttributeError: module 'tensorflow' has no attribute 'log' 

が発生してしまうのです。（2020年4月20日時点）

そこで、これを解決するために2日間くらい試行錯誤したので、
書き記しておきます。

解決方法（仮）

参考になるのは、以下に示すgithubのお悩み相談箱みたいなものです。

https://github.com/matterport/Mask_RCNN/issues/1797#

全部英語なのですが、頑張って読み進めたところ、ヒントになるような投稿を見つけました。

どうやら、tensorflowのバージョンが違ってメゾットが変更になっていることに起因するエラーのようです。

この通りに、mrcnn/model.pyの該当箇所を書き直せばいいはずです。

注意点！

注意すべきは、エラーが出る最後まで行ってからmodel.pyを変更するのではなく、
最初にレポジトリをクローンした直後にmodel.pyを書き換えてしまうことです。

修正版model.pyでsetupとかを進めることで解決できたようでした。
（本当の原因を知っている人がいたら教えてください。）

一件落着！
参考になったらいいねお願いします！

本記事の目的

機械学習の推論web APIの典型的な構成を紹介します。必ずしもWEBの知識や機械学習の知識はなくても読める内容だと思います。（実装例は除く）
紹介する構成は、業務でいくつかの機械学習モデルの推論web APIをたてた経験からきていますが、あくまでも個人的見解なので、こっちのほうがいいよーってのがあればコメントで教えていただけると幸いです。
実装例ではweb frameworkは非同期処理の扱いやすさ、実装のシンプルさの観点からFastAPIを使います。

目次

1. 機械学習の推論web APIの構成
2. 実装例

1. 機械学習の推論web APIの構成

本記事では、2つのパターンを紹介します。

注) まず、共通部分の説明をします。機械学習の知見が必要なのは基本的に共通部分だけです。もし、機械学習に詳しくない or webに詳しくない場合は、共通部分と後述の部分で役割を分担できるので、そんなもんかと流してもらってもかまいません。

推論API (共通部分)

学習させたモデルに推論させる場合、一般的に以下のような機械学習モデルの推論APIを構築すると思います。
ローカルPCやJupyter Notebook上での開発しかしていない場合でもこのようなAPI (パイプライン) は作ると思います。

詳細は割愛しますが、負荷分散やモデル管理の便利さのためにクラウド上のサーバに機械学習モデルを使うAPIだけ切り出してもいいと思います (参考: GCP AI platform Prediction)。 負荷だけではなく、推論にもGPUを使わないとパフォーマンスに問題がでるような重いモデルの場合、よくあるWEBアプリ用のサーバーでは対応できないので、切り分けできるようにしたほうが柔軟だと思います。
また、学習済みモデルを用いた外部サービスを用いる場合も同じ構成になると思います。

データ量が大きくなってくると前処理などをGoogle Cloud Dataflowのような大規模データ処理エンジンに置き換えるなどの工夫が必要になると思います。

上記のようなローカルPCやJupyter Notebook上で開発した推論APIをベースにしてweb APIをたてる際、主に2種類のパターンが考えられます。これらは、入出力データの扱いが異なります。

• 1.1. オンライン予測（HTTP予測とも呼ばれる）
• 1.2. バッチ予測

(GCPのAI platformで使われている名称を用いています。参考: オンライン予測 vs バッチ予測)

1.1. オンライン予測

http requestが来たらMLの関数を動かして、outputをhttp responseで即時返すというシンプルな構成です。サーバーの起動時に一度だけ重みをloadしておきます。重みのload時に、cloudのstorage(google storageなど)から重みを取得するようにしておくとモデルの変更がしやすくなります。

利点

• ローカルで動かすような推論用の関数をweb frameworkの中に移すだけでだいたい動く
• 1つのAPIを叩くだけで推論結果が返るのでたたきやすいAPIになる
• モデルが小さく、データが少ない場合は、レスポンスが速い

欠点

• web APIは、負荷分散の観点から数十秒から数分でタイムアウトするように設定されることが多いので、推論に時間が長時間かかると処理が失敗してしまいます。なので、重いモデルや一度に大量のデータをさばくのには適していないです。

1.2. バッチ予測

即時にレスポンスを返せない or 返す必要がない場合には以下のようにML APIの推論結果を直接レスポンスせずに、何らかのstorageに格納します。以下の様に、処理を3段階に分けて考えることができます。（2と3が分かれていればいいです。upload APIはML APIに統合してもいいです）

1. upload API: 入力用のデータをStorage (Databaseやcloud storageなど) に貯める
2. ML API（非同期で実行）: Storageからデータを取得、MLの関数を動かし、結果をStorageに保存。ただし、処理が終わるより先にレスポンスを返しておく
3. download API: Storageから結果を取得し、返す

それぞれのAPIは疎結合にできます。なので、upload APIとdownload APIの実装はかなり自由度が高いです。
使い方は以下の様に様々です。

• 入力データをに一定期間ためて、1日の終りに一気に推論
• タイムアウトしてしまうような複雑なモデルを用いて推論
• 推論結果をキャッシュして、同じ入力に対して繰り返し推論を行わない
• など

また、uploadとdownload APIの実装はPython以外の言語でも何の問題もないですし、同じstorageに読み書きできれば、異なるサーバーにAPIがたっていてもいいです。APIを経由せずStorageにフロントエンドから直接読み書きしてもいいです。特に入出力が画像の場合はcloud storageを直接扱うほうが簡潔なフローになります。

利点

• タイムアウトで失敗することがなくなる
• 自由度が高い
• 学習用のAPIも同様な構成で実装できる

欠点

• オンライン予測よりも構成が複雑なので、使いにくい
• オンライン予測よりも処理に時間がかかる

2. 実装例

online予測とbatch予測のAPIをFastAPIで実装してみます。
以下の例を見ると、ローカルで推論のパイプラインをちゃんと関数化しておけばweb APIにするのは結構ハードルが低いなと感じてもらえるのではないかと思っています。

やらないこと

本記事では以下は扱いません。

• security
• deploy

FastAPIとは

PythonのWeb frameworkで、Flaskのようなマイクロフレームワークにあたります。
パフォーマンスの高さ、書きやすさ、本番運用を強く意識した設計、モダンな機能などが強みです。
特に、非同期処理が扱いやすいです。

以下、FastAPIの基本知識を前提としています。
もし細かいことが知りたい場合は、適宜以下などを参照して下さい。

• 公式Doc
• [FastAPI] Python製のASGI Web フレームワーク FastAPIに入門する

推論API (共通部分)

汎用性をもたせるために、非常にざっくりとしたmockを定義します。
特に意味はないですが簡単のため、自然言語処理の感情分析のタスクということにします。

必要な機能は、以下のようになります。ただし、モデルだけ別サーバーに切り出されている場合は、loadとモデルの保持は要りません。

• 重みのloadやjoblib, pickleなどを用いたmodel instanseの読み込み
• モデルの保持
• 推論パイプライン

今回は、predictでランダムな感情を返すモデルとします。処理時間はリアルにしたいのでload時に20秒間フリーズし、predict時に10秒間フリーズするようにしています。

ml.py

from random import choice
from time import sleep

class MockMLAPI:
    def __init__(self):
        # model instanse
        self.model = None

    def load(self, filepath=''):
        """
        when server is activated, load weight or use joblib or pickle for performance improvement.
        then, assign pretrained model instance to self.model.
        """
        sleep(20)
        pass

    def predict(self, x):
        """implement followings
        - Load data
        - Preprocess
        - Prediction using self.model
        - Post-process
        """
        sleep(10)
        preds = [choice(['happy', 'sad', 'angry']) for i in range(len(x))]
        out = [{'text': t.text, 'sentiment': s} for t, s in zip(x, preds)]
        return out

リクエスト・レスポンスのデータ形式

リクエストデータの形式を定義します。
以下の様に、複数入力に対応できるようにしてみます。

{
  "data": [
    {"text": "hogehoge"},
    {"text": "fugafuga"}
  ]
}

レスポンスデータは、入力に推論結果を加えて返すような形式にします。

{
  "prediction": [
    {"text": "hogehoge", "sentiment": "angry"},
    {"text": "fugafuga", "sentiment": "sad"}
  ]
}

なので、以下の様にSchemaを定義します。

schemas.py

from pydantic import BaseModel
from typing import List

# request
class Text(BaseModel):
    text: str

class Data(BaseModel):
    data: List[Text]

# response
class Output(Text):
    sentiment: str

class Pred(BaseModel):
    prediction: List[Output]

2.1. オンライン予測

上述の共通部分を使ってオンライン予測を行うweb APIを実装します。
必要なのは、

• サーバーの起動時に学習済み機械学習モデルを読み込む
• データの受け取り、ML APIで推論、結果を返す

です。以下の様に実装すると最低限のAPIが完成します。

main.py

from fastapi import FastAPI
from ml_api import schemas
from ml_api.ml import MockMLAPI

app = FastAPI()
ml = MockMLAPI()
ml.load() # load weight or model instanse using joblib or pickle

@app.post('/prediction/online', response_model=schemas.Pred)
async def online_prediction(data: schemas.Data):
    preds = ml.predict(data.data)
    return {"prediction": preds}

動作確認

ローカルで動作確認します。
CuRLでsampleの入力をpostします。すると、想定していた出力が返ってくることが確認できます。
また、レスポンスが返ってくるまでにかかった時間は10秒なので、ほぼpredictの処理時間だけしかかかっていないことも確認できます。

$ curl -X POST "http://localhost:8000/prediction/online" -H "accept: application/json" -H "Content-Type: application/json" -d "{\"data\":[{\"text\":\"hogehoge\"},{\"text\":\"fugafuga\"}]}" -w  "\nelapsed time: %{time_starttransfer} s\n"

{"prediction":[{"text":"hogehoge","sentiment":"angry"},{"text":"fugafuga","sentiment":"happy"}]}
elapsed time: 10.012029 s

2.1. バッチ予測

上述の共通部分を使ってバッチ予測を行うweb APIを実装します。

1. upload API: 入力用のデータをStorage (Databaseやcloud storageなど) に貯める
2. ML API（非同期で実行）: Storageからデータを取得、MLの関数を動かし、結果をStorageに保存。ただし、処理が終わるより先にレスポンスを返しておく
3. download API: Storageから結果を取得し、返す

Input/Output

本来であれば、cloudのstorageやDBにデータを保存すべきですが、簡単のため、本記事ではローカルのストレージにcsv形式でデータを保存します。
まず、読み書きのための関数を定義します。入力データの保存時にランダムな文字列でファイル名を作成し、そのランダムな文字列をapiでやりとりすることで一連のバッチ予測を行います。
実装が長く感じるかもしれないですが、実際は、以下の3つの処理しかないです。

• csvの読み書き
• fileのpathを調整
• ランダムな文字列の生成

io.py

import os
import csv
from random import choice
import string
from typing import List
from ml_api import schemas

storage = os.path.join(os.path.dirname(__file__), 'local_storage')

def save_csv(data, filepath: str, fieldnames=None):
    with open(filepath, 'w') as f:
        writer = csv.DictWriter(f, fieldnames=fieldnames)

        writer.writeheader()
        for f in data:
            writer.writerow(f)

def load_csv(filepath: str):
    with open(filepath, 'r') as f:
        reader = csv.DictReader(f)
        out = list(reader)
    return out

def save_inputs(data: schemas.Data, length=8):
    letters = string.ascii_lowercase
    filename = ''.join(choice(letters) for i in range(length)) + '.csv'
    filepath = os.path.join(storage, 'inputs', filename)
    save_csv(data=data.dict()['data'], filepath=filepath, fieldnames=['text'])
    return filename

def load_inputs(filename: str):
    filepath = os.path.join(storage, 'inputs', filename)
    texts = load_csv(filepath=filepath)
    texts = [schemas.Text(**f) for f in texts]
    return texts

def save_outputs(preds: List[str], filename):
    filepath = os.path.join(storage, 'outputs', filename)
    save_csv(data=preds, filepath=filepath, fieldnames=['text', 'sentiment'])
    return filename

def load_outputs(filename: str):
    filepath = os.path.join(storage, 'outputs', filename)
    return load_csv(filepath=filepath)

def check_outputs(filename: str):
    filepath = os.path.join(storage, 'outputs', filename)
    return os.path.exists(filepath)

web API

upload、推論、uploadの3つのAPIをたてます。なお、バッチ推論では即時にレスポンスを返さないので、モデルのloadはAPIがたたかれる度に行います。

ここではFastAPIのBackgourndTasksを使ってモデルの推論を非同期処理させています。推論はバックグラウンドで処理を行い、終了を待たずに先にレスポンスを返すことができます。

main.py

from fastapi import FastAPI
from fastapi import BackgroundTasks
from fastapi import HTTPException
from ml_api import schemas, io
from ml_api.ml import MockBatchMLAPI

app = FastAPI()

@app.post('/upload')
async def upload(data: schemas.Data):
    filename = io.save_inputs(data)
    return {"filename": filename}

def batch_predict(filename: str):
    """batch predict method for background process"""
    ml = MockMLAPI()
    ml.load()
    data = io.load_inputs(filename)
    pred = ml.predict(data)
    io.save_outputs(pred, filename)
    print('finished prediction')

@app.get('/prediction/batch')
async def batch_prediction(filename: str, background_tasks: BackgroundTasks):
    if io.check_outputs(filename):
        raise HTTPException(status_code=404, detail="the result of prediction already exists")

    background_tasks.add_task(ml.batch_predict, filename)
    return {}

@app.get('/download', response_model=schemas.Pred)
async def download(filename: str):
    if not io.check_outputs(filename):
        raise HTTPException(status_code=404, detail="the result of prediction does not exist")

    preds = io.load_outputs(filename)
    return {"prediction": preds}

動作確認

オンライン予測と同様に動作確認します。
CuRLでsampleの入力をpostします。すると、想定していた出力が返ってくることが確認できます。
また、download APIをたたくまでに30秒待っています。しかし、それぞれのresponseは非常に早く返ってきていることがわかります。

$ curl -X POST "http://localhost:8000/upload" -H "accept: application/json" -H "Content-Type: application/json" -d "{\"data\":[{\"text\":\"hogehoge\"},{\"text\":\"fugafuga\"}]}" -w  "\nelapsed time: %{time_starttransfer} s\n"
{"filename":"fdlelteb.csv"}
elapsed time: 0.010242 s

$ curl -X GET "http://localhost:8000/prediction/batch?filename=fdlelteb.csv" -w  "\nelapsed time: %{time_starttransfer} s\n"
{}
elapsed time: 0.007223 s

$ curl -X GET "http://localhost:8000/download?filename=fdlelteb.csv" -w  "\nelapsed time: %{time_starttransfer} s\n"   [12:58:27]
{"prediction":[{"text":"hogehoge","sentiment":"happy"},{"text":"fugafuga","sentiment":"sad"}]}
elapsed time: 0.008825 s

おわりに

機械学習の推論web APIの典型的な構成であるオンライン予測とバッチ予測の2つを紹介しました。
一般的なweb APIの構成から多少ひねりが必要となっていますが、FastAPIを使ってシンプルに構築する実装例も紹介しました。ローカルで推論のパイプラインをちゃんと関数化しておけばweb APIにするのはハードルが低いなと感じてもらえたら嬉しいです。
機械学習の盛り上がりは留まるところをしらないですが、web APIの構成などの情報はまだまだ少ないと感じています。本記事で紹介した構成も荒削りだと思います。改善点などあればコメントしていただけるとありがたいです！

本記事の目的

機械学習の推論web APIの典型的な構成を紹介します。必ずしもWEBの知識や機械学習の知識はなくても読める内容だと思います。（実装例は除く）
紹介する構成は、業務でいくつかの機械学習モデルの推論web APIをたてた経験からきていますが、あくまでも個人的見解なので、こっちのほうがいいよーってのがあればコメントで教えていただけると幸いです。
実装例ではweb frameworkは非同期処理の扱いやすさ、実装のシンプルさの観点からFastAPIを使います。

目次

1. 機械学習の推論web APIの構成
2. 実装例

1. 機械学習の推論web APIの構成

本記事では、2つのパターンを紹介します。

注) まず、共通部分の説明をします。機械学習の知見が必要なのは基本的に共通部分だけです。もし、機械学習に詳しくない or webに詳しくない場合は、共通部分と後述の部分で役割を分担できるので、そんなもんかと流してもらってもかまいません。

推論API (共通部分)

学習させたモデルに推論させる場合、一般的に以下のような機械学習モデルの推論APIを構築すると思います。
ローカルPCやJupyter Notebook上での開発しかしていない場合でもこのようなAPI (パイプライン) は作ると思います。

詳細は割愛しますが、負荷分散やモデル管理の便利さのためにクラウド上のサーバに機械学習モデルを使うAPIだけ切り出してもいいと思います (参考: GCP AI platform Prediction)。 負荷だけではなく、推論にもGPUを使わないとパフォーマンスに問題がでるような重いモデルの場合、よくあるWEBアプリ用のサーバーでは対応できないので、切り分けできるようにしたほうが柔軟だと思います。
また、学習済みモデルを用いた外部サービスを用いる場合も同じ構成になると思います。

データ量が大きくなってくると前処理などをGoogle Cloud Dataflowのような大規模データ処理エンジンに置き換えるなどの工夫が必要になると思います。

上記のようなローカルPCやJupyter Notebook上で開発した推論APIをベースにしてweb APIをたてる際、主に2種類のパターンが考えられます。これらは、入出力データの扱いが異なります。

• 1.1. オンライン予測（HTTP予測とも呼ばれる）
• 1.2. バッチ予測

(GCPのAI platformで使われている名称を用いています。参考: オンライン予測 vs バッチ予測)

1.1. オンライン予測

http requestが来たらMLの関数を動かして、outputをhttp responseで即時返すというシンプルな構成です。サーバーの起動時に一度だけ重みをloadしておきます。重みのload時に、cloudのstorage(google storageなど)から重みを取得するようにしておくとモデルの変更がしやすくなります。

利点

• ローカルで動かすような推論用の関数をweb frameworkの中に移すだけでだいたい動く
• 1つのAPIを叩くだけで推論結果が返るのでたたきやすいAPIになる
• モデルが小さく、データが少ない場合は、レスポンスが速い

欠点

• web APIは、負荷分散の観点から数十秒から数分でタイムアウトするように設定されることが多いので、推論に時間が長時間かかると処理が失敗してしまいます。なので、重いモデルや一度に大量のデータをさばくのには適していないです。

1.2. バッチ予測

即時にレスポンスを返せない or 返す必要がない場合には以下のようにML APIの推論結果を直接レスポンスせずに、何らかのstorageに格納します。以下の様に、処理を3段階に分けて考えることができます。（2と3が分かれていればいいです。upload APIはML APIに統合してもいいです）

1. upload API: 入力用のデータをStorage (Databaseやcloud storageなど) に貯める
2. ML API（非同期で実行）: Storageからデータを取得、MLの関数を動かし、結果をStorageに保存。ただし、処理が終わるより先にレスポンスを返しておく
3. download API: Storageから結果を取得し、返す

それぞれのAPIは疎結合にできます。なので、upload APIとdownload APIの実装はかなり自由度が高いです。
使い方は以下の様に様々です。

• 入力データをに一定期間ためて、1日の終りに一気に推論
• タイムアウトしてしまうような複雑なモデルを用いて推論
• 推論結果をキャッシュして、同じ入力に対して繰り返し推論を行わない
• など

また、uploadとdownload APIの実装はPython以外の言語でも何の問題もないですし、同じstorageに読み書きできれば、異なるサーバーにAPIがたっていてもいいです。APIを経由せずStorageにフロントエンドから直接読み書きしてもいいです。特に入出力が画像の場合はcloud storageを直接扱うほうが簡潔なフローになります。

利点

• タイムアウトで失敗することがなくなる
• 自由度が高い
• 学習用のAPIも同様な構成で実装できる

欠点

• オンライン予測よりも構成が複雑なので、使いにくい
• オンライン予測よりも処理に時間がかかる

2. 実装例

online予測とbatch予測のAPIをFastAPIで実装してみます。
以下の例を見ると、ローカルで推論のパイプラインをちゃんと関数化しておけばweb APIにするのは結構ハードルが低いなと感じてもらえるのではないかと思っています。

やらないこと

本記事では以下は扱いません。

• security
• deploy

FastAPIとは

PythonのWeb frameworkで、Flaskのようなマイクロフレームワークにあたります。
パフォーマンスの高さ、書きやすさ、本番運用を強く意識した設計、モダンな機能などが強みです。
特に、非同期処理が扱いやすいです。

以下、FastAPIの基本知識を前提としています。
もし細かいことが知りたい場合は、適宜以下などを参照して下さい。

• 公式Doc
• [FastAPI] Python製のASGI Web フレームワーク FastAPIに入門する

推論API (共通部分)

汎用性をもたせるために、非常にざっくりとしたmockを定義します。
特に意味はないですが簡単のため、自然言語処理の感情分析のタスクということにします。

必要な機能は、以下のようになります。ただし、モデルだけ別サーバーに切り出されている場合は、loadとモデルの保持は要りません。

• 重みのloadやjoblib, pickleなどを用いたmodel instanseの読み込み
• モデルの保持
• 推論パイプライン

今回は、predictでランダムな感情を返すモデルとします。処理時間はリアルにしたいのでload時に20秒間フリーズし、predict時に10秒間フリーズするようにしています。

ml.py

from random import choice
from time import sleep

class MockMLAPI:
    def __init__(self):
        # model instanse
        self.model = None

    def load(self, filepath=''):
        """
        when server is activated, load weight or use joblib or pickle for performance improvement.
        then, assign pretrained model instance to self.model.
        """
        sleep(20)
        pass

    def predict(self, x):
        """implement followings
        - Load data
        - Preprocess
        - Prediction using self.model
        - Post-process
        """
        sleep(10)
        preds = [choice(['happy', 'sad', 'angry']) for i in range(len(x))]
        out = [{'text': t.text, 'sentiment': s} for t, s in zip(x, preds)]
        return out

リクエスト・レスポンスのデータ形式

リクエストデータの形式を定義します。
以下の様に、複数入力に対応できるようにしてみます。

{
  "data": [
    {"text": "hogehoge"},
    {"text": "fugafuga"}
  ]
}

レスポンスデータは、入力に推論結果を加えて返すような形式にします。

{
  "prediction": [
    {"text": "hogehoge", "sentiment": "angry"},
    {"text": "fugafuga", "sentiment": "sad"}
  ]
}

なので、以下の様にSchemaを定義します。

schemas.py

from pydantic import BaseModel
from typing import List

# request
class Text(BaseModel):
    text: str

class Data(BaseModel):
    data: List[Text]

# response
class Output(Text):
    sentiment: str

class Pred(BaseModel):
    prediction: List[Output]

2.1. オンライン予測

上述の共通部分を使ってオンライン予測を行うweb APIを実装します。
必要なのは、

• サーバーの起動時に学習済み機械学習モデルを読み込む
• データの受け取り、ML APIで推論、結果を返す

です。以下の様に実装すると最低限のAPIが完成します。

main.py

from fastapi import FastAPI
from ml_api import schemas
from ml_api.ml import MockMLAPI

app = FastAPI()
ml = MockMLAPI()
ml.load() # load weight or model instanse using joblib or pickle

@app.post('/prediction/online', response_model=schemas.Pred)
async def online_prediction(data: schemas.Data):
    preds = ml.predict(data.data)
    return {"prediction": preds}

動作確認

ローカルで動作確認します。
CuRLでsampleの入力をpostします。すると、想定していた出力が返ってくることが確認できます。
また、レスポンスが返ってくるまでにかかった時間は10秒なので、ほぼpredictの処理時間だけしかかかっていないことも確認できます。

$ curl -X POST "http://localhost:8000/prediction/online" -H "accept: application/json" -H "Content-Type: application/json" -d "{\"data\":[{\"text\":\"hogehoge\"},{\"text\":\"fugafuga\"}]}" -w  "\nelapsed time: %{time_starttransfer} s\n"

{"prediction":[{"text":"hogehoge","sentiment":"angry"},{"text":"fugafuga","sentiment":"happy"}]}
elapsed time: 10.012029 s

2.1. バッチ予測

上述の共通部分を使ってバッチ予測を行うweb APIを実装します。

1. upload API: 入力用のデータをStorage (Databaseやcloud storageなど) に貯める
2. ML API（非同期で実行）: Storageからデータを取得、MLの関数を動かし、結果をStorageに保存。ただし、処理が終わるより先にレスポンスを返しておく
3. download API: Storageから結果を取得し、返す

Input/Output

本来であれば、cloudのstorageやDBにデータを保存すべきですが、簡単のため、本記事ではローカルのストレージにcsv形式でデータを保存します。
まず、読み書きのための関数を定義します。入力データの保存時にランダムな文字列でファイル名を作成し、そのランダムな文字列をapiでやりとりすることで一連のバッチ予測を行います。
実装が長く感じるかもしれないですが、実際は、以下の3つの処理しかないです。

• csvの読み書き
• fileのpathを調整
• ランダムな文字列の生成

io.py

import os
import csv
from random import choice
import string
from typing import List
from ml_api import schemas

storage = os.path.join(os.path.dirname(__file__), 'local_storage')

def save_csv(data, filepath: str, fieldnames=None):
    with open(filepath, 'w') as f:
        writer = csv.DictWriter(f, fieldnames=fieldnames)

        writer.writeheader()
        for f in data:
            writer.writerow(f)

def load_csv(filepath: str):
    with open(filepath, 'r') as f:
        reader = csv.DictReader(f)
        out = list(reader)
    return out

def save_inputs(data: schemas.Data, length=8):
    letters = string.ascii_lowercase
    filename = ''.join(choice(letters) for i in range(length)) + '.csv'
    filepath = os.path.join(storage, 'inputs', filename)
    save_csv(data=data.dict()['data'], filepath=filepath, fieldnames=['text'])
    return filename

def load_inputs(filename: str):
    filepath = os.path.join(storage, 'inputs', filename)
    texts = load_csv(filepath=filepath)
    texts = [schemas.Text(**f) for f in texts]
    return texts

def save_outputs(preds: List[str], filename):
    filepath = os.path.join(storage, 'outputs', filename)
    save_csv(data=preds, filepath=filepath, fieldnames=['text', 'sentiment'])
    return filename

def load_outputs(filename: str):
    filepath = os.path.join(storage, 'outputs', filename)
    return load_csv(filepath=filepath)

def check_outputs(filename: str):
    filepath = os.path.join(storage, 'outputs', filename)
    return os.path.exists(filepath)

web API

upload、推論、uploadの3つのAPIをたてます。なお、バッチ推論では即時にレスポンスを返さないので、モデルのloadはAPIがたたかれる度に行います。

ここではFastAPIのBackgourndTasksを使ってモデルの推論を非同期処理させています。推論はバックグラウンドで処理を行い、終了を待たずに先にレスポンスを返すことができます。

main.py

from fastapi import FastAPI
from fastapi import BackgroundTasks
from fastapi import HTTPException
from ml_api import schemas, io
from ml_api.ml import MockBatchMLAPI

app = FastAPI()

@app.post('/upload')
async def upload(data: schemas.Data):
    filename = io.save_inputs(data)
    return {"filename": filename}

def batch_predict(filename: str):
    """batch predict method for background process"""
    ml = MockMLAPI()
    ml.load()
    data = io.load_inputs(filename)
    pred = ml.predict(data)
    io.save_outputs(pred, filename)
    print('finished prediction')

@app.get('/prediction/batch')
async def batch_prediction(filename: str, background_tasks: BackgroundTasks):
    if io.check_outputs(filename):
        raise HTTPException(status_code=404, detail="the result of prediction already exists")

    background_tasks.add_task(ml.batch_predict, filename)
    return {}

@app.get('/download', response_model=schemas.Pred)
async def download(filename: str):
    if not io.check_outputs(filename):
        raise HTTPException(status_code=404, detail="the result of prediction does not exist")

    preds = io.load_outputs(filename)
    return {"prediction": preds}

動作確認

オンライン予測と同様に動作確認します。
CuRLでsampleの入力をpostします。すると、想定していた出力が返ってくることが確認できます。
また、download APIをたたくまでに30秒待っています。しかし、それぞれのresponseは非常に早く返ってきていることがわかります。

$ curl -X POST "http://localhost:8000/upload" -H "accept: application/json" -H "Content-Type: application/json" -d "{\"data\":[{\"text\":\"hogehoge\"},{\"text\":\"fugafuga\"}]}" -w  "\nelapsed time: %{time_starttransfer} s\n"
{"filename":"fdlelteb.csv"}
elapsed time: 0.010242 s

$ curl -X GET "http://localhost:8000/prediction/batch?filename=fdlelteb.csv" -w  "\nelapsed time: %{time_starttransfer} s\n"
{}
elapsed time: 0.007223 s

$ curl -X GET "http://localhost:8000/download?filename=fdlelteb.csv" -w  "\nelapsed time: %{time_starttransfer} s\n"   [12:58:27]
{"prediction":[{"text":"hogehoge","sentiment":"happy"},{"text":"fugafuga","sentiment":"sad"}]}
elapsed time: 0.008825 s

おわりに

機械学習の推論web APIの典型的な構成であるオンライン予測とバッチ予測の2つを紹介しました。
一般的なweb APIの構成から多少ひねりが必要となっていますが、FastAPIを使ってシンプルに構築する実装例も紹介しました。ローカルで推論のパイプラインをちゃんと関数化しておけばweb APIにするのはハードルが低いなと感じてもらえたら嬉しいです。
機械学習の盛り上がりは留まるところをしらないですが、web APIの構成などの情報はまだまだ少ないと感じています。本記事で紹介した構成も荒削りだと思います。改善点などあればコメントしていただけるとありがたいです！

前置き

テキスト『python django超入門』(秀和システム)をやっているところで、テキスト通りに入力してエラーが発生しました。出版社提供の正誤表に記載がなかったので勉強を兼ね投稿させていただきました。
テキストではhelloアプリケーションを作成しています。

実行環境

django:3.0.2
python:3.7.4
OS:macOS Mojave 10.14.6

エラー内容

それは、2-2のP.82(複数ページの移動)をやっていた時に起こりました。

index.html

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="utf-8">
    <title>{{ title }}</title>
</head>
<body>
    <h1>{{ title }}</h1>
    <p>{{ msg }}</p>
    <p><a href="{% url goto %}">{{ goto }}</a></p>
</body>
</html>

views.py

# 修正前
# index()のみ抜粋
def index(request):
    params = {
        'title': 'Hello/index',
        'msg': 'これは、サンプルで作ったページです。',
        'goto': 'next',
    }
    return render(request, 'hello/index.html', params)

この状態でindex.htmlにアクセスすると下記エラーが発生しました。

NoReverseMatch at /hello/
Reverse for 'next' not found. 'next' is not a valid view function or pattern name.

「next」って？？と怒られています。。。
＃おかしいな、何度見直してもテキスト通りなんだけど。。。

原因、解決方法

結論から書くと、views.py内の'goto'の書き方が原因でした。
下記の通りに修正したら正常になりました。

views.py

# 5行目
# 変更前：
'goto': 'next',

# 変更後：
'goto': 'hello:next',

実行結果画面：

リンク部分の表示がテキストと違っていますが、そこは本質ではないのでここでは触れません。
（テキストでは「next」だけが表示されることになっている）
原因は、index.html内のテンプレート{% url goto %}部分に正しい書式で送信されていないためでした。
goto部分の書式は'アプリ名:name'となるはずが、nameしか来ていないので不整合が起きていました。

あとがき

上記は出版社サポートページの正誤表に記載がなく、同じ部分でつまづく人がいるかもと思い、自身の勉強を兼ねて投稿させていただきました。
私自身djangoはまだ勉強中ですので、ツッコミなどありましたらお願いしますm(_ _)m

はじめに

先日、ポケモンたかさおじさんこと、生㌔Pのブログにて次のような記事が投稿された。

ポケモンらしさ-2_意見分析　マスコット感検証
https://pkmnheight.blogspot.com/2020/04/2.html

ざっくり引用すると、以前バズってた以下の海外の分析画像を、転載したTweetがあった。

ポケモンのデザインはどんどん生物的じゃなくなって行ってて、色んな部位が丸みを帯びてただの可愛いマスコットキャラクターと化してるっていう海外の分析画像が凄い pic.twitter.com/qHHVaHzEue

— Χ十 ◤カイジュー◢(⃔ *`꒳´ * )⃕↝♡ (@KaijuXO) June 13, 2019

このTweetに対して、ポケモンたかさおじさんが 猛撃 していたというものである。
ざっっっくり要約すると、各世代ごとに幼虫・昆虫ごとに部位をピックアップし、
そう単純にマスコット化しているわけではないと分析している。

恐ろしい観察・分析力とボリュームなので、是非読んでいただきたい。

---

ところで、ポケモンという巨大なコンテンツは20年以上続いているだけあり、
各人のポケモンに対する思い入れや付き合い方は異なる。

最も大きなインパクトだった1996年のポケモン赤緑直撃世代にとって
ポケモンは今でも初代のポケモン151匹なのだろう。

音楽バンドの古参ファンが
「やっぱ初期のアルバムの方がいいよね」
「最近はPOPになったなあ・・・」 などと言いがちなのと同様に、

「最近のポケモンはポケモンらしくない」
「昔のポケモンの方がよかった」
と言いがちなのである。

そんな古参ファンにとって、最近のポケモンがポケモンらしくない理由については、それぞれ思うところがあったのだろう。（だからこそ、先程の海外の分析画像を転載した方のように、昔のポケモン・最近のポケモンの一部を切り取り、その理由を求めるのだ）

先日のポケモンたかさおじさんのアンケートでは、古くからポケモンを嗜んできた者たちによって、以下のような意見が多く寄せられた。

• 最近のポケモンは、デザインが複雑になってきた。
• 最近のポケモンは、シンプルさがない。
• 最近のポケモンは、マスコットキャラっぽい。
• 最近のポケモンは、ゆるキャラっぽい。
• 最近のポケモンは、丸い。
• 最近のポケモンは、生物感がない。

各々で感じる方向性は違えども、デザインについて今と昔で変わったと感じる意見が非常に多かった。

先程紹介したポケモンたかさおじさんの記事では、これらの意見に対してポケモンのデザインについて、主に生物的な面から分析が成されていた。

私の方はこの件に関して、「最近のポケモンは複雑になった」　かどうかについて調査を行った。

---

ポケモンのデザインの複雑さを情報量として定量化する

左のポケモンは1996年初出のメタモン。
右のポケモンは2019年初出のムゲンダイナである。

なるほど！！！！たしかに最近のポケモンは複雑である。

・・・・・・・・。
これで話を終わらせても良いが、
ポケモンは現在、全890種類もいる。
更に、リージョンフォーム・メガシンカなど、姿の違う者をあわせると、私の集計だと1056種類にもなる。

全てのポケモンについて、デザインの複雑さを調べてみなければ、最近のポケモンほど複雑かどうかはわからないはずだ。

そもそも我々が感じるデザインにおける複雑さとは何だろうか？
私は、以下のような手法で全ポケモンの複雑さ≒情報量として定量化した。

---

ポケモンの情報量=「描き込み量」の数値化

アンパンマンのデザインにおける情報量は、北斗の拳のケンシロウに比べれば少ないのは明らかだ。
ここからは、情報量＝「描き込み量」として、各ポケモンを数値化していく。

1.グレースケールへの変換

import cv2
import numpy as np

def read_cv2(filename,method):
    #windowsでは日本語ファイルを開くにはこうしなきゃいけない
    stream = open(filename, "rb")
    bytes = bytearray(stream.read())
    numpyarray = np.asarray(bytes, dtype=np.uint8)
    bgrImage = cv2.imdecode(numpyarray, method)
    return bgrImage

filename = "フシギダネ.png"
img_gray = read_cv2(filename,cv2.IMREAD_GRAYSCALE)

2.白部分を膨張させる

kernel = np.ones((4,4),np.uint8)
dilation = cv2.dilate(img_gray,kernel,iterations = 1)

3.グレースケールとの差分を取る

diff = cv2.subtract(dilation, img)
negaposi = 255 - diff

このような処理で、結果として輪郭や色の境が残る。

最後に、抽出された線部分の全ピクセル数を、画像内でポケモンに使われている全ピクセル数で割って規格化する

#主線部分が残った画像の黒い部分のピクセル数を合計する
black_area= np.where(np.array(img_negaposi).flatten().reshape(-1)<250,1,0).sum()

# アルファチャンネルのわかる画像ファイルを使用
# 公式のポケモン図鑑の画像にはアルファチャンネルが使用されている。
alpha_img = Image.open("フシギダネ_アルファ.png")

alpha_array = 255-np.array(alpha_img)[:,:,3]
used_area=np.where(alpha_array<255,1,0).sum()

#これがポケモンの情報量となる
poke_entropy = black_area/used_area

#フシギダネの部分のピクセル数:48114
#主線部分のピクセル数:23366
#フシギダネの情報量: 23366/48114 = 0.4856

この処理でフシギダネの情報量＝0.4853となる

---

ポケモン世代ごとの情報量の集計

同様に、全ポケモンの情報量を計算し、情報量の多いポケモン。少ないポケモンごとに集めたのがこちらである。

• 情報量の少ないポケモン

---

• 情報量の多いポケモン

こうして眺めてみると、前述した方法で求めた情報量が直感的にも間違いではないのがわかる。

• 情報量多いポケモン：複雑。描き込みが多い。細長い。ゴツい。伝説のポケモン。
• 情報量少ないポケモン：シンプル。丸い。かわいい。未進化ポケモン。

と、情報量多い・少ない組でそれぞれ明らかに特徴が表れている。

今回使用する画像は全てポケモンずかん公式サイトから入手した。
ポケモンずかん（公式）
https://zukan.pokemon.co.jp/

---

やっぱり最近のポケモンはデザインが複雑だった！？

「フシギダネの情報量は0.4853」と書いても、この数字が多いのか少ないのか直感的に分かりにくいので、各情報量から平均値を引き、標準偏差で割ることで、標準化を行った。

以降は標準化後の情報量を、改めて情報量として扱う。
情報量が０に近いほど、全ポケモン中平均的な情報量。
プラスの値が大きいほど情報量が多く、
マイナスの値が大きいほど情報量が少ない。
と考えていただきたい。

なお、先の画像の2者は、最も情報量の少ないポケモン・多いポケモンである。
情報量が多い方も少ない方もだいたいプラマイ0.6くらいになれば、全ポケモン中で両極端にいると思っていただきたい。

こうして求めた情報量に基づいて、各世代ごとに集計した。(メガシンカ・キョダイマックスは除外)

たしかに１世代に比べて後の世代は情報量が多くなっているようだ。
1世代の情報量中央値-0.025に対し、最新作の8世代では0.0235まで増加している。

世代	中央値	最小値	最大値	25%	75%
1	-0.025	-0.667	0.420	-0.140	0.094
2	-0.053	-0.476	0.412	-0.148	0.069
3	-0.017	-0.508	0.519	-0.159	0.141
4	0.033	-0.452	0.495	-0.096	0.147
5	-0.002	-0.517	0.402	-0.149	0.126
6	-0.007	-0.563	0.543	-0.145	0.123
7	0.013	-0.497	0.544	-0.112	0.148
8	0.024	-0.455	0.560	-0.141	0.164

５世代以降は中央値
-0.002,
-0.007,
0.013,
0.024と増加を続け、

６世代以降は最大値を
0.543,
0.544,
0.56と更新している。

つまり、古参ポケモンファンが物申す際の
「最近のポケモンはデザインが複雑になった」
と言うのは、根拠の無いものではないということらしい。

「ほら！！最近のポケモンは複雑じゃないか！！！
俺は知っていたぞ！！だから俺は最近のポケモンは好きじゃなかったんだ！」
と思う古参の方々の気持ちをどうすることもできない。

---

話は変わるが、1世代のゲームボーイと、最新作のNintendo Switchでハードの解像度による表現力の差は著しいものである。

解像度が変わっただけではなく、色もゲームボーイの白黒4段階ドット絵から
256×256×256色の3Dモデルとなり、ポケモンの息づく表現も可能になった。
　　

このようにハード性能が開放されることによって、より複雑なデザイン・よりシンプルなデザインをも表現が可能になった。

一方で、この著しいハード能力の向上にしては、ポケモンデザインの情報量を、ある程度の範囲にコントロールしようと努めているのかもしれない。

また、これは増やす時は意識して情報量を増やしている形跡でもある。

4世代以降のポケモンで、デザインが極めて特集な群がある。以下の性質を持つデザインだ。これらの要素は、各ポケモン世代を代表する要素と言っても過言ではない。

• 4世代:追加進化(ドサイドン・モジャンボなど)
• 6世代:メガシンカ
• 7世代:ウルトラビースト・カプ
• 8世代:キョダイマックス

我々は新しいポケモンが発表される度に、言葉に形容し難い「こいつらは何かが違うぞ！？！？！？」と思わせるモノがある！そう感じていたが、その一つが、情報量だったのだろう。

キョダイマックスのみこの方法ではむしろ情報量が低い分類となってしまった。
キョダイマックスポケモンは以下のように大幅にパースがついている。手前の部位で面積が増えている分、今回の手法では情報量が大きくならない

---

各世代のポジション別の情報量変動

古くからポケモンを嗜んできた方々はお気づきだろうが、毎世代、新しく登場するポケモンには、ある程度お決まりが存在する。
序盤の草むらにはほぼ確実に鳥ポケモンや小動物ポケモンが登場,少し進めば森に虫ポケモンが現れる。
毎回ストーリー終盤には600族と言われる、バトルで強いポケモンが捕まえられるようになる。
更に言えば、ゲームスタート直後に草・炎・水タイプから一匹を選べる言わゆる”御三家”といわれるポケモンも恒例だ。

それらポジション毎での世代別情報量の変化を見れば、何かがわかるのではないかと思い、調査してみた。
皆もそれぞれ思い当たる節があるだろうが、4つに絞って紹介する。

---

序盤鳥ポケモン枠(未進化)

赤い線は全ポケモンの平均である。

日本人が転載してバズっていた海外のTweetでも取り上げられていたポッポ・ヤヤコマ・ツツケラが含まれている。

YO ? I never really noticed this about some of the newer Pokémon and now I can't unsee it ? pic.twitter.com/YEvNRIsULT

— DM me for Toilet Paper ? (@Mega_Arcanine1) June 6, 2019

（翼を広げている画像か、畳んでいるかで情報量が変化してしまうので一概には言えないが）ポッポからヤヤコマまで情報量が減少しているため、このことから「最近のポケモンはマスコット化している」という印象を受けているのかもしれない。

---

ピカチュウ枠

皆は何と呼んでいるかは知らないが、私は「ピカチュウ枠」と呼ぶ。私のカウントでは、毎世代必ずこういったカワイイポケモンが存在するのだ。

特にパチリス以降のピカチュウ枠は、ポケモンアニメでサトシの同行者、もしくはライバルの手持ちポケモンとなっているのもあり、このポケモンのグッズを売らなければいけない！！！ という何らかの力を感じる。

「最近のポケモンはマスコット化している」という文言のマスコットとは何なのか改めて考えるとよくわからないが、ピカチュウ枠はマスコット的なのだろう。皆かわいらしい見た目であり、情報量も平均値を下回っている。丸い形状のトゲデマルを除けば、世界一有名なポケモンであるピカチュウが最も情報量が低いく、徐々に情報量が増えているのがわかる。
ひょっとすると、「最近のポケモンは複雑」というのは、情報量が低いはずのピカチュウ枠ですら、最近は情報量が多い。 ということかもしれない。

---

幻ポケモン枠（配布ポケモン）

幻ポケモンといえば、ポケモン映画の顔となることもあり、ポケモンのゲーム自体やったこと無くても名前や姿を知っている人も出てくるだろう。
初代・金銀くらいまでをポケモンだと思っている方々にとっては、後の世代のポケモンはあまりにも情報過多に思えるかもしれない。

---

パッケージの伝説ポケモン枠

第二世代以降はストーリーに関わってくる伝説のポケモンがパッケージを飾っている。ポケモンを買わなくなった方々はパッケージを見て「最近のポケモンってこうなってるんだ・・・」と思うのだろう。
ホウホウの情報量は比較的多い。しかし、主に羽の描き込みによるところが大きい。主観的な感想だが、ホウオウは基本的にはタダの派手な鳥である。数値上の情報量ほどにはホウオウ複雑なポケモンには見えないのかもしれない。
一方、カイオーガ以降は体に特別な模様のようなものがあり、情報量を増やす要因となっている。
新作タイトルのパッケージを飾るようなポケモンは、その世代の顔であるのと同時に「これは新しいポケモンだ！！！」と思わせなくてはいけない。情報量が増えてでも、新しく、特別なデザインに挑戦したのだろう。

---

種族値の高いポケモンほどデザインが複雑！！！？？？

多くのポケモンガチ勢にとっては、バトルで強いポケモンこそ愛すべきポケモンであり、デザインは二の次・三の次であろう。
だが、強いポケモンとは、

• 爪
• 牙
• 翼
• 武器
• 首
• 炎
• トゲ
• ウロコ
• 子供

など、より強力な武器を、時には多く持つことで、様々なライバルと戦えるポケモンではないだろうか？

つまり、「種族値の合計が多い＝情報量が多い」　が成立しうるのではないか？と考えた。

（異論はあるだろう。本当はタイプや覚える技。特性やバトルでのメタれ具合なども考慮したいが、それだけで一つの研究になってしまう）

まず、特に条件を設けず、伝説・幻・進化前・メガシンカなど、全て引っくるめて情報量と種族値合計の相関を見てみる。

相関係数0.443と、それなりの相関が見て取れる。
「情報量が多い＝種族値合計が大きい」という傾向はあるようだ。

---

公式大会のガチバトルに出すポケモンに絞ったらどうか？

さきほどの散布図には進化前や伝説のポケモン・メガシンカポケモンまで含まれているが、では、公式大会のバトルに出す選択肢となりうるポケモンに絞ったらどうなるだろう。

先程の相関から
- 進化前ポケモン
- 伝説・幻ポケモン

を除外したポケモンでの、情報量と種族値合計の相関がこちら。（斜めの赤い線は、相関図にフィットさせた回帰線である）

バトルに出すポケモンに絞っても、やはり情報量と種族値合計は相関があるということらしい。

また、条件を絞ったことで、ある程度どんなポケモンが図のどこに位置するのかが認知しやすくなった。

例えば、左下のピンク色の部分方には、ピカチュウ枠に属するポケモンが集まっている。
右下の緑色の部分には、序盤に捕まえられる虫ポケモンが固まっている。

---

「進化でポケモンは可愛くなくなる」が数値化できるか？

「生き物の赤ちゃんは、親に世話してもらえるように普遍的にカワイく見えるように生まれる」みたいな話を聞いたことがあると思う。

説明はすっ飛ばすが、生き物の赤ちゃんの共通した特徴として、以下のようなものがあるらしい。
これをベビースキーマという。
ベビースキーマによると、あらゆる動物の赤ちゃんに共通する特徴として、以下のようなものがあるらしい

• 手足が短い
• 頭が丸い
• 頭が大きい
• 顔が平坦

いかにも情報量を減らしそうな要因が揃っているではないか？

そこで、ポケモンが、情報量も進化しているのかを確かめて見る。（ポケモンでは、生物学的な意味での『変態』のことも『進化』と言う）
2段階進化ポケモンと、1段階進化ポケモンそれぞれで集計した結果がこちら。

やはり、一段階進化・二段階進化共に、「情報量が増える(≒カワイくなくなる)」という傾向が表れている！！！！

• ベイビィポケモンから０進化目
  

• メガシンカ
  

メガシンカによる情報量増は、分散が広すぎてよくわからないが、ポケモンにとって基本的に進化するということは情報量が増えるということらしい。

ポケモンは生き物の体をなしているが、ワザを使って戦うモンスターである。そのため、進化において、より強くなるために要素を追加していくのは戦闘を生業とする生命として理に叶っている。

ちなみに、情報量の変化が激しかったポケモンはこちら。

ポケモンはこちらの想像を超える進化を見せるものだなあ。と改めて実感した。

---

まとめ

• 「最近のポケモンは複雑になった」とか言われがちである
• ポケモンのデザインの複雑さを定量化するために、openCVを用いてデザインの境界線部分を取得し、情報量 を計算した。
• 最近のポケモンほど、情報量が増す傾向はある。
• 種族値の高いポケモンほど、情報量が高い傾向もあった。
• 進化によってポケモンは情報量を増やす。

課題

今回の情報量の算出法には欠点が多い。

例えば、エルレイド→メガエルレイドのように、
メガシンカでマントが追加されたにもかかわらず、情報量が大幅に下がっている。これはマントの追加によって描き込み量よりも分母の面積の方が大きく増えてしまったためだ。

この方法はフラクタル次元による画像の複雑度を使用することによって解決することが出来る。

参考にさせていただいたコード
https://gist.github.com/viveksck/1110dfca01e4ec2c608515f0d5a5b1d1

def boxcount(Z, k):
    # ２値化したZについて、サイズkのボックス化
    S = np.add.reduceat(
        np.add.reduceat(Z, np.arange(0, Z.shape[0], k), axis=0),
                           np.arange(0, Z.shape[1], k), axis=1)
    return S

threshold=0.9
image_file = image_files[0]
img = Image.open(image_file)
Z = np.array(img)[:,:,0]/256.0

# しきい値によって2値化
Z = (Z < threshold)

# 短い方の幅を使用
p = min(Z.shape)

#2のべき乗で、画像の幅を超えない最大値
n = 2**np.floor(np.log(p)/np.log(2))
n = int(np.log(n)/np.log(2))

# 2のべき乗の配列(256,128,,,,4)
sizes = 2**np.arange(n,1,-1)

# ボックスの数をカウント。
box_list = []
for size in sizes:
    box = boxcount(Z,size)
    size=box.shape[0]
    plt.figure(figsize=(size/12,size/12))
    plt.imshow(255-box,cmap="gray")

    box_list.append(box)

# ボックス内の点の数をカウント
counts=[len(np.where((box > 0) & (box < size*size))[0]) for box,size in zip(box_list,sizes)]




plt.plot(np.log(sizes),np.log(counts),label="黒点の数",marker="o")
plt.plot(np.log(sizes),coeffs[1] + np.log(sizes)*coeffs[0],label="近似式",ls="--")
plt.title("両対数軸")
plt.xlabel("log(ボックスの大きさ)")
plt.ylabel("log(点の数)")
plt.legend()

ボックスの大きさ・ボックスの数を対数にして近似線を作成した際の、傾きがフラクタル次元となる。

#両対数軸について、回帰線を作成
coeffs = np.polyfit(np.log(sizes), np.log(counts), 1)
print("フシギダネのフラクタル次元:{}".format(-coeffs[0]))

# フシギダネのフラクタル次元:1.4960451082147515

この手法では、エルレイドはメガシンカによって情報量が増加するので、今回使用した手法に比べれば、この点では優れているかもしれない。

しかし、全体的に見れば、解釈が難しかったため、採用に至れなかった。
フラクタル次元の小さいポケモンは比較的、今回の手法と一致するのと、直感的にも正しそうなのだが、
フラクタル次元の多いポケモンでは解釈が難しかったため、採用を断念した。なぜ、アローラニャースが最もフラクタル次元が大きいのか？なぜヤバチャ(最下端のティーカップのようなポケモン)がフラクタル次元が大きいのか？直感的にわかりにくい。

フラクタル次元の小さいポケモンの例

フラクタル次元の多いポケモンの例

また、今回の手法ではイラストでのポーズが情報量に大きく影響してしまうのも不完全である。より正確に行うには、3Dモデルによる分析が必要不可欠だろう。

今日は落書きで書いた図形をプログラムで描いてみようと思い，Pythonを使って描いてみた。

今回使うプログラム

fractal.py

import matplotlib.pyplot as plt
import matplotlib.collections as mc
import numpy as np

def return_point(p1, p2):
    point = (p2-p1)*0.08 + p1
    return point

N = 1000
x = np.linspace(-1, 1, N)

x_point = [0, 100, 200]
y_point = [0, 200, 0]
for i in range (N):
    new_x_point = return_point(x_point[i], x_point[i+1])
    new_y_point = return_point(y_point[i], y_point[i+1])
    x_point.append(new_x_point)
    y_point.append(new_y_point)

fractal = [[(x_point[i], y_point[i]), (x_point[i+1], y_point[i+1])] for i in range(N)]

lc = mc.LineCollection(fractal, colors='#333333', linewidths=1, antialiased=True)


fig = plt.figure(figsize=(10,10))
ax = fig.add_subplot(1,1,1)

# ↓非本質的な設定
ax.set_axis_bgcolor('#f3f3f3')
plt.gca().spines['right'].set_visible(False)
plt.gca().spines['left'].set_visible(False)
plt.gca().spines['top'].set_visible(False)
plt.gca().spines['bottom'].set_visible(False)
plt.tick_params(labelbottom=False, labelleft=False, labelright=False, labeltop=False)
# ↑非本質的な設定

ax.add_collection(lc)
ax.autoscale()
plt.savefig('./fractal.png')

7行目point = (p2-p1)*0.08 + p1の0.08の値を変えてみるのも一興.

実行後

あら，美しい（CDのジャケットにありそう）
（ところで，何か名前がついていたらコメント欄で教えてください）

【追記】

厳密にはフラクタル図形でないと考え，タイトルを"フラクタル図形をPythonを使って描いてみた"から"擬似フラクタル図形をPythonを使って描いてみた"に変更しました。

参考にした記事

ありがとうございました。

pythonでフラクタル図形を作成part1(シェルピンスキーのギャスケット）
https://qiita.com/okakatsuo/items/f2e79fc501ed9f799734

Matplotlibで複数の線分を描画する方法
https://omedstu.jimdofree.com/2019/10/04/matplotlibで複数の線集合を描画する方法/

matplotlibのめっちゃまとめ
https://qiita.com/nkay/items/d1eb91e33b9d6469ef51#2-グラフaxesの作成

AWS Lambda（以下、Lambda）に外部モジュールをデプロイする方法を見ていきたいと思います。ここではPythonを例に見ていきます。

実行順序
1. Amazon Linux 2（Lambdaの実行環境）を準備する
2. ソースファイルとともにLambdaにデプロイ
2. Lambda Layerを使う方法

*2はどちらを選んでも構いません。

1. Amazon Linux 2（Lambdaの実行環境）を準備する

requestsモジュール等、内部でC言語などを使わず、Pure Pythonで書かれたモジュールの場合、このステップは不要です。
しかし、numpyやscipyといった、C言語に依存する場合、Lambdaの実行環境と同じ環境で開発するのが開発しやすくなります。 windowsやMacでインストールしたnumpyをzipで固めてデプロイしてもエラーとなります。

ここでは、Amazon Linux 2の環境としてDockerを使用します。Lambdaイメージ、lambci/lambda:build-python3.7　が公開されているので、それを使います。

適当なディレクトリを作って、Lambdaで実行するソースコード(lambda_function.py)とDockerfileを作成してください。

Dockerfileの中身

FROM lambci/lambda:build-python3.7
ADD . . 
CMD pip3 install numpy -t /var/task

lambda_function.pyの中身は適当

import numpy as np

def lambda_handler(event,context):
    print(np.arange(10).reshape(2,5)) 

ソースとDockerfile作成完了

~$ ls
Dockerfile  lambda_function.py

あとは、ビルドして、runしてください。

~$ docker image build -t numpy:latest .
~$ docker container run --rm -v ${PWD}:/var/task numpy:latest

コンテナ内でインストールした外部モジュールを、ホストOSでも参照するために、-v ${PWD}:/var/taskしています。

ちなみに、/var/taskはLambdaが外部モジュールをインポートするために参照するパスの１つです。Dockerコンテナで実行する場合は、このパスの中に外部モジュールを置く必要があります。
試しに、Lambdaで以下のようにして、パスを確認してみてください。

import sys
def lambda_handler(event,context):
    print(sys.path)

"""
python3.7 における実行結果

['/var/task', '/opt/python/lib/python3.7/site-packages', '/opt/python', '/var/runtime', '/var/lang/lib/python37.zip', '/var/lang/lib/python3.7', '/var/lang/lib/python3.7/lib-dynload', '/var/lang/lib/python3.7/site-packages', '/opt/python/lib/python3.7/site-packages', '/opt/python']
"""

上記コマンドが成功していると、ソースと外部モジュール（numpy）が同じ階層にあるはずです。あとは、Lambda Layer、もしくはソースファイルとともにzipで固めてデプロイするだけです。なので、以下2のどちらかを選んでください。

~$ ls
Dockerfile  bin  lambda_function.py  numpy  numpy-1.18.3.dist-info  numpy.libs

2. Lambda Layerを使う方法

前述の通り、Lambdaが外部モジュールを読み込めるように、python ディレクトリを作成して、そこにnumpy関連のファイル、ディレクトリを移動します。
実行手順の最初の段階で python ディレクトリを作成していれば以下の作業は不要です。

~$ mkdir python
~$ mv bin numpy  numpy-1.18.3.dist-info  numpy.libs python

外部モジュールをzipで固めてLambda Layerにデプロイします。

~$ zip -rq numpy.zip python

ソースファイルをzipで固めて、Lambda コンソール or AWS CLIでデプロイします。

~$ zip -q lambda_function.zip lambda_function.py

2. ソースファイルとともにLambdaにデプロイ

zipで固めて、Lambda コンソール or AWS CLIでデプロイします。

~$ zip -rq numpy.zip *

Lambdaにデプロイする際にサイズが大きくて、画面に表示できない場合がありますが（numpyはほぼ表示不可能）実行自体はできます。

郵便番号から住所を特定したい時に使う

郵便局の地域検索を利用
https://www.post.japanpost.jp/zipcode/index.html

上記フォームの結果をパースして戻り値をdictionaryで返すfunction

import requests
from bs4 import BeautifulSoup
import re


pref_key = {
    '北海道': 1,
    '青森県': 2,
    '岩手県': 3,
    '宮城県': 4,
    '秋田県': 5,
    '山形県': 6,
    '福島県': 7,
    '茨城県': 8,
    '栃木県': 9,
    '群馬県': 10,
    '埼玉県': 11,
    '千葉県': 12,
    '東京都': 13,
    '神奈川県': 14,
    '新潟県': 15,
    '富山県': 16,
    '石川県': 17,
    '福井県': 18,
    '山梨県': 19,
    '長野県': 20,
    '岐阜県': 21,
    '静岡県': 22,
    '愛知県': 23,
    '三重県': 24,
    '滋賀県': 25,
    '京都府': 26,
    '大阪府': 27,
    '兵庫県': 28,
    '奈良県': 29,
    '和歌山県': 30,
    '鳥取県': 31,
    '島根県': 32,
    '岡山県': 33,
    '広島県': 34,
    '山口県': 35,
    '徳島県': 36,
    '香川県': 37,
    '愛媛県': 38,
    '高知県': 39,
    '福岡県': 40,
    '佐賀県': 41,
    '長崎県': 42,
    '熊本県': 43,
    '大分県': 44,
    '宮崎県': 45,
    '鹿児島県': 46,
    '沖縄県': 47
}


def get_html_text(url: str) -> str:
    try:
        req = requests.get(url)
    except requests.exceptions.ConnectionError:
        return False
    return req.content


def getAddress(postal_code: int) -> dict:
    url = f'https://www.post.japanpost.jp/smt-zipcode/zipcode.php?zip={postal_code}'
    content = get_html_text(url)
    if not content:
        return False
    soup = BeautifulSoup(content, 'html.parser')
    dds = [i.text.strip() for i in soup.body.findAll('dd')]
    if not dds:
        return False
    dds = dds[:4]
    info = {
        'postal': dds[0].replace('-', ''),
        'pref': dds[1],
        'city': dds[2],
        'address': re.sub(r'\(.*', '', dds[3])
    }
    info['pref_no'] = pref_key[info['pref']]
    return info


if __name__ == "__main__":
    data = getAddress(1000004)
    print(data)

"""
結果
{
　　'postal': '1000004', 
　　'pref': '東京都', 
　　'city': '千代田区', 
　　'address': '大手町（次のビルを除く・ＪＡビル）', 
　　'pref_no': 13
}
"""