JujuとMAASで機械学習基盤を展開・管理する
はじめまして！キスモインターン生の鈴木健太です．
今年の5月からインフラエンジニアとして働いています．
今回，オンプレの機械学習基盤の管理を効率化するシステムを組んだのでご紹介します．
モチベーション
今回のシステムを組むに至ったのは，
- 何度も同じ構築作業をしたくない
- 人為的なミスを削減したい
- マシンの設定を一貫させたい
という思いがあったためです．
新しい計算機が手に入るたびに，同じセットアップ作業を繰り返していては時間の無駄ですし，見落としや作業を行う人による差異などが発生しかねません．
そこで，構成管理ツールなどを用いた計算資源の管理を行うことにしました．
アーキテクチャ
今回は以下のようなシステムを構築しました．
以前ご紹介したように，キスモの機械学習インフラにはRancherを使用してます．
その構築をJuju + MAASで行い，各ノードの監視・管理をLandscapeで行うという形になっています．
このシステムの提供する主な機能は，以下の通りになります．
- Jujuによる構成管理
- MAASによるOS展開
- Landscapeによるパッケージ管理・モニタリング
Jujuによる構成管理
JujuとはChef，Ansible，Puppetなどと同じ構成管理ツールの一種です．数ある構成管理ツールの中でもJujuを選んだ理由は，OSの展開から自動化したいという思いがあり，それを実現するMAASとの相性が良かったためです．
JujuはCharmというアプリケーションの構築手順書を使用し，パブリッククラウドやプライベートクラウドにアプリケーションを展開します．ここで言うパブリッククラウドとはAWSやGCPなどを，プライベートクラウドとは後述するMAASなどを指します．
Charmには単一のアプリケーションの構成，各種動作などが定義されており，「構築」「スケーリング」「アップグレード」「削除」などの操作をコマンド1つで実行可能にします．
e.g.) Rancherのサーバ展開
juju deploy rancher-server
弊社では，Rancherと後述するLandscapeの展開に使用しています．
MAASによるOS展開
MAASとはベアメタルへのOSのインストールを自動化するシステムです．IPMIによるPCの電源操作やOSのインストール，RAIDセットアップなどを自動化してくれます．
内部にPXEサーバ，DHCPサーバなどを備えており，MAASの管理するネットワーク上でPXEブートしたマシンを自動的に登録し，GUIからの操作だけで指定したOSイメージをマシンへインストールできるようにします．
JujuはこのMAASが提供するAPIを使用することで，アプリケーションの展開に必要なマシンへのOS展開の指示などを行います．
Landscapeによるパッケージ管理・モニタリング
Landscapeとは，Canonicalが開発しているコンピュータの管理・監視ツールです． 主な機能としては，
- パッケージの一元管理
- サーバ上のユーザ管理
- 各種ハードウェア情報のモニタリング
- サーバ上でのスクリプト実行
が挙げられます．これらの操作はGUIから行うことができます．また，複数のサーバに対して同じ操作を同時に行うことができるため，サーバの数が増えたとしても，操作の実行に必要な手数はほとんど変わりません．
弊社では，先程紹介したJujuを用いてLandscapeのサーバを展開すると共に，Rancherが動いているノード上にLandscapeのクライアントを展開することで，クラスタに属する各ノードのパッケージ管理，モニタリングなどを行っています．
今後の課題
このシステムではログの一元管理ができておらず，障害発生時にJujuやLandscapeだけで原因が特定できない場合，サーバから直接ログを収集するしかない状況です．なので，今後はログの管理や障害検知の仕組みを工夫していけたらと考えています．
最後に
今回は社内で構築した計算資源の管理を効率化するシステムを紹介させていただきました． 今後もキスモの社内環境の整備に尽力していきますので，また何かまとまれば紹介していきたいと思います．
それでは，最後までお付き合いいだだきありがとうございました！
もっとキスモのことを知りたい方は
こちらをご覧ください！
【簡単解説】協調フィルタリングの計算方法
こんにちは！
株式会社キスモのPythonエンジニアの久保です。
後半の今回は前半の協調フィルタリングの概要に続き、具体的な計算方法の例をお伝えします。
計算の流れ
協調フィルタリングの計算の流れは大きく3つに分けられます。
* 評点行列の作成
* 類似度行列の作成
* 推薦スコアを計算
具体例
評点行列の作成
まずは、評点の作成です。ユーザーがアイテムにつけたポイントを下の図のように行列にまとめます。
ユーザー1-8のアイテムA-Kに対する評点を表しています。「0」は、アイテムに評価をつけていないことを意味します。これらの「0」のついたアイテムに対し、ユーザーへの推薦度を計算していきます。
類似度行列の計算
続いては、推薦するユーザーと嗜好の類似したユーザーとの度合い（類似度）を計算します。
類似度の計算方法ですが、ここでは基礎的は2つの計算方法を紹介します。
* ユーグリット距離
* ピアソン相関係数
これらの類似度を全ての組み合わせパターンで計算し、評点行列のように行列にして表現します。ちなみにこちらはピアソンの相関係数を使ったユーザーベースの協調フィルタリングで用いる、ユーザー類似度の行列です。
ユーグリット距離
ユーグリット距離の定義は以下の引用の通りです。
引用：https://wikimedia.org/api/rest_v1/media/math/render/svg/ffb93a5ebb9746add918b02af3da0098b6e23a07
例として、上の評点の行列のユーザー1とユーザー3の類似度を計算します。計算対象は両ユーザーが評点をつけたアイテムへの評点です。
※0点は評点をつけていないことを意味するので、ここでは無視します。
√{(1-4)2 + (3-1)2 + (5-1)2} = 5.39
ピアソン相関係数
ピアソン相関係数の定義は以下の引用の通りです。
引用：https://wikimedia.org/api/rest_v1/media/math/render/svg/940c0a6429b8cdecb1ebe8b1fdcfbab547a557a9
まずは、ユーザー1とユーザー3のピアソン相関です。計算対象はユーグリット距離と同様、両ユーザーが評点をつけたアイテムへの評点です。
x(ユーザー1)の平均が３、y(ユーザー3)の平均が2なので、分子は(1-3)(4-2)+(3-3)(1-2)+(5-3)(1-2)=-6、分母は{(1-3)2 + (3-3)2 + (5-3)2}{(4-2)2 + (1-2)2 + (1-2)2}の平方根なので√48になります。−6を√48で割ることで−0.866という類似度が導かれます。
これらの計算を、ユーザーベースの協調フィルタリングであればユーザーの全ての組み合わせで、アイテムベースの協調フィルタリングであれば全てのアイテム同士で類似度の計算を行い、行列を作ります。
推薦スコアを計算
これらの類似度行列と、評点行列を元に推薦のスコアを求めていきます。
これは先ほどお見せした評点の行列と、右にあるのはユーザー1に対する類似度を示したものです。 ここからは例としてユーザー1に対するレコメンドを考えたいと思います。ユーザー1が評点をつけていないA、B、C、G、H、I、Kについてのレコメンドスコアを求めていきます。
表はユーザー1との類似度と、ユーザー[2−8]のアイテム[A-K]に対する点数を掛け合わせたものです。例えばB3は、ユーザー3のBに対する1点、ユーザー1とユーザー3の類似度が−0.866なので、1×(-0.866)で-0.866となっています。
次に、それぞれの数の和を求めます。さらに、アイテムA-Kが何ユーザーに評点をつけられているかをカウントします（評点数）。
最後に、その和をカウント数割った数（図の中の「和」÷「評点数」）を求めそれがスコアになります。つまり、ユーザー1にはアイテムAとアイテムIが最もおすすめできるものとなります。
このような計算手順を踏むことで協調フィルタリングのスコアを求めることができます。
以上が協調フィルタリングの具体的な計算方法です。 前回の概要編と今回の計算方法編の2部を通し、協調フィルタリングの基本的な考え方をご理解いただければ幸いです。
余談ですが。
前回と今回でご説明した協調フィルタリングは、かねてからメッセナゴヤと共同開発していたAIマッチングシステムでも活用しております。詳しくはこちらをご覧ください。
また、AIマッチングシステムについてmarvinでも取り上げていただきましたので、ご興味がおありの方はぜひこちらもご覧ください。
もっとキスモのことを知りたい方は
こちらをご覧ください！
【簡単解説】機械学習でも用いられる協調フィルタリングとは
こんにちは！
株式会社キスモのPythonエンジニアの久保です。
今回と次回の全2回で、推薦システムの中で基本的なアルゴリズムである、協調フィルタリングについてお話しします。前半の今回は、協調フィルタリングの概要を、次週更新予定の後半では実際の協調フィルタリングの計算方法についてお伝えします。
概要
協調フィルタリングとは、「自分と嗜好が類似しているユーザーとの差分を推薦する」推薦アルゴリズムです。
例えば、キス男くんが、果物の中でりんご🍎、みかん🍊、いちご🍓、ぶどう🍇が好きだったとします。一方、キス子さんはりんご🍎、みかん🍊、いちご🍓が好きだったとします。
キス男くんの好み：「りんご🍎」「みかん🍊」「いちご🍓」「ぶどう🍇」 キス子さんの好み：「りんご🍎」「みかん🍊」「いちご🍓」
キス男くんとキス子さんは2人とも🍎と🍊と🍓が好きなので、好き嫌いが類似していると言えます。そこでキス子さんに他の果物を推薦する際に、嗜好が似ているユーザーであるキス男くんとの差分の「ぶどう🍇」も好きだろうという仮説が立てられます。これをもとにキス子さんに推薦すれば良いわけです。
これが協調フィルタリングの基本的な考え方です。
協調フィルタリングの立ち位置
推薦システムの側面から
推薦システムのアルゴリズムは大きく以下の2つに分けることができます。
* 内容ベース
* 協調フィルタリング
内容ベースとは、「好きなアイテムと同じカテゴリのアイテム」を推薦するものです。例えば「北野武」監督の「コメディー」映画に高評価をつけたら、同じ「北野武」監督の「コメディー」映画を見つけ出し、ユーザーに推薦します。
推薦の基準がアイテム側に存在するのが内容ベースのアルゴリズムです。
これに対し、アイテムを選んだユーザー側に推薦の判断要素が存在するのが協調フィルタリングです。内容ベースとは違いアイテムの特徴を全く考慮しないことが大きな特徴です。
機械学習の側面から
協調フィルタリングはデータを貯めるほど精度が高くなることから、機械学習の1つとして認識されています。教師データがあるわけではないので、ジャンルとしては教師なし学習のアルゴリズムです。
協調フィルタリングの特徴として、データが存在しない状態では推薦の精度が全く期待できないことが問題として挙げられます。この問題は「コールドスタート問題」と呼ばれています。
協調フィルタリングの大枠
協調フィルタリングも以下の2つのジャンルに大別できます。
* ユーザーベース
* アイテムベース
ユーザーベースの協調フィルタリングは、ユーザー同士の嗜好の類似度を計算し、それをもとに行う協調フィルタリングです。概要で説明した協調フィルタリングも、ユーザー(キス男くんとキス子さん)の嗜好の類似度を計算し行われた推薦なので、ユーザーベースの協調フィルタリングです。
簡単に図にすると下の図のようになります。
ユーザー1とユーザー2はそれぞれ「晴れ」と「月」と「曇り」が好きなので、両者は嗜好の類似度が高いといえます。ユーザー1にアイテムを推薦する場合、類似するユーザーであるユーザー2との差分の「雷」をユーザー1に推薦します。このようにユーザー同士の類似度を基にアイテムを推薦するのがユーザーベースの協調フィルタリングです。
これに対し、アイテム同士で好まれ方の類似度を計算し、それによって行われる推薦がアイテムベースの協調フィルタリングです。
簡単に図にすると下の図のようになります。
「晴れ」と「月」はユーザー1、2、3に好きと言われているとします。「晴れ」を好きなユーザーの多くは「月」も好きと言っていることから、「晴れ」と「月」は好まれ方の類似度が高いと言えます。このとき、ユーザー4にアイテムを推薦する場合、ユーザー4は「晴れ」を好きと言っていることから、類似度の高い「月」を推薦することができます。
このようにアイテム同士がどれほど同じユーザーに好きとされているかを計算し、その類似度をもとに推薦するのがアイテムベースの協調フィルタリングです。
以上が前半の、協調フィルタリングの概要説明です。
後半では、実際の計算方法についてお伝えします！
もっとキスモのことを知りたい方は
こちらをご覧ください！
世界一のデータサイエンティストを目指して 〜Kaggle参加レポート5〜
こんにちは！株式会社キスモのKaggler 大越です。
またまた嬉しい報告があります！
Kaggleで開かれていた、データ分析の世界大会”Home Credit Default Risk”で、史上最多の7198チームが参加する中で2位に入り、再びゴールドメダルを獲得しました。またそれに伴い、Kaggle Master※になりました！！
※Kaggle Master : メダルの数に応じて付与される称号の中で、最上位のGrandmasterに次ぐ2番目の称号のこと。
前回はAvitoでゴールドメダルを取った後に報告をさせていただきましたが、今回もまたまた良い報告ができ嬉しいです。
さて、今回のブログではそんなKaggleで開かれたKaggle insight challengeの内容を試したので、それをブログにします。
Kaggle insight challengeとは？
9月末に4日間の日程で開かれたデータ分析の説明性に関するLessonです。
4日間の内容は以下の通りです。
- day1 PermutationImportanceを用いた特徴量の重要度の計算
- day2 Partial Dependence Plots(pdp)を用いた、特徴量とtargetの関係の可視化
- day3 SHAPを用いた個々の予測の構成可視化
- day4 SHAPを用いた予測モデル全体の構成可視化
今回は上記のうち、day1, day2の内容を試しました。
使用したデータ
Kaggle Telcom Customer Churnのデータを使用しました。
そのため、コードはKaggleのkernel内に公開しています。
タスクとしては電気通信事業の顧客情報から、その人が1ヶ月以内に解約するかどうかを2値で分類するもので、target=1が解約した、0が解約しなかったとなっています。
サービスには以下のものがあり、どれを利用したかのデータが含まれています。
phone, multiple lines, internet, online security, online backup, device protection, tech support, and streaming TV and movies
また、その他に顧客の属性情報も含まれています。
今後の分析で登場する"TotalCharges"は請求した合計金額、"Contract"は契約期間(月間、1年、2年)、"Dependents"は顧客に扶養家族がいるか、"Partner"は顧客にパートナーがいるか、"DeviceProtection"はデバイス保護の契約をしたかを示しています。
モデリング
今回、特にモデリングには気を使わずこちらのカーネルから抜粋しました。
使用したモデルは木系のランダムフォレストです。
モデルの評価もカーネルに沿ってaccuracyとconfusion matrix, roc curveを使用しました。
図はスコアを示したものです。accuracyは0.7927でした。
PermutationImportance
図はPermutationImportanceの概要を示しています。
このように、ある特徴量についてランダムにシャッフルした時の精度の下がり方を使い、特徴量の重要度を算出しています。
この時、精度が大きく下がるようなら、その特徴は予測において重要であることを示しており、逆に精度が上がる場合は、予測にノイズ成分として悪影響を及ぼしていると判断できます。
今回はeli5というライブラリを使用して実験を行いました。
import eli5 from eli5.sklearn import PermutationImportance perm = PermutationImportance(clf, random_state=1).fit(df_val[features], df_val["Churn"]) eli5.show_weights(perm, feature_names = list(features))
図は結果を示しており、Featureが特徴量の名前、Weightが精度の推移を示しています。
一番左の列の数値を見てみると、+のものが”精度が下がった、つまり予測に重要な特徴量”、-のものが”精度が上がった、つまり予測に悪影響を及ぼす特徴量”を示していることが分かります。
真ん中の列の、+-で示されている数値は、ランダム性を持つ分析なので何回か行った際の標準偏差になっています。
これを見ると"TotalCharges", "Contract"が予測において重要な特徴であることがわかります。
また、"Dependents", "Partner", "DeviceProtection"は予測に悪影響を及ぼすノイズ成分になっていることがわかります。
そこで、これらを除いたモデルを作ってみました。
結果は図の通りで、accuracyは0.7946でした。
元のモデルと比較して特徴量を3つ除いた結果、0.7927->0.7946とわずかな精度向上を実現しました。
ただ、何回かやってみると、ノイズ成分と示される特徴が変わったり、精度が悪化するケースがあったりしました。
今回の結果でも標準偏差を見るとノイズ成分もプラスに振れることもありそうですし、もう少しはっきりと負の影響を示すものは除くような処理になるのではと思っています。
Partial Dependence Plots(pdp)
図はpdpの概要を示しています。
このように、ある行に着目し、1つの特徴量の値を上下させた時の出力の変化を見ます。
これを複数の行で行い、その平均を取ることで、ある特徴量の推移とtargetの値との関係を見ることができます。
from matplotlib import pyplot as plt from pdpbox import pdp, get_dataset, info_plots # Create the data that we will plot features = df_val.drop(["Churn"], axis=1).columns.values feature_to_plot = 'TotalCharges' pdp_goals = pdp.pdp_isolate(model=clf, dataset=df_val[features], model_features=list(features), feature=feature_to_plot) # plot it pdp.pdp_plot(pdp_goals, feature_to_plot) plt.show()
今回はpdpboxというライブラリを使用して実際に分析しました。
PermutationImportanceで特に重要だった"TotalCharges"を対象にしています。
図は結果を示すもので、横軸が"TotalCharges"の推移、縦軸が”target”の推移になります。
青で示された範囲が信頼度を示しています。
これを見ると"TotalCharges"が0から2000付近までは”target”が急激に低下し、その後もなだらかに低下している様子がわかります。
"Contract"についての結果を見ても、値の増加に伴い、”target”が下がっている様子が確認できました。
まとめ
今回はKaggle insight challengeの内容を応用し、「PermutationImportanceで重要度を算出->悪影響を及ぼす特徴を除いてモデリング/重要な特徴とtargetの関係をpdpを使って可視化」という流れを実施しました。
実装はKaggle kernelでも公開しましたのでよろしければご覧ください。
ランダムな要素の影響で多少結果が変わっていますが、ご容赦ください。
もっとキスモのことを知りたい方は
こちらをご覧ください！
データサイエンティストの生産性を高めるキスモのクラウド資源の使い方
こんにちは！キスモインターン生の岡野です。
5月にインフラのインターンが1人増えまして、オンプレに関してはある程度お願いしてしまい、僕自身は現在クラウドの管理に注力しています。
5月から7月くらいでAWSの現状把握からTerraformを利用したコード化、DevOps系作業としての自動化および今回ブログで紹介するクラウド資源のオンデマンドな運用に着手していました。
本記事に載せる内容以外の部分についても今後紹介していけたらなと思います！
なんでクラウド資源？？？
前回のブログにも記述したようにキスモでは現状、機械学習にはオンプレミスの資源を利用しています。
しかし、おかげさまで案件も少しずつ増えてまいりまして計算資源が少し足りないという状況となってしまいました。この時に省力化をもう一段階進めようという話になりました（現状のオンプレはRancher 2.0を利用していることもあり、ぽちぽち作業が少し多い）。k8sをもっと柔軟に使う施策についてももっと進めていけたらなと思いますがすぐにどうこうなるという話ではなさそうです。
以上の理由からキスモではクラウド資源も併用しようという結論に至りました。
キスモで実現したいインフラ管理
1コマンドで終わる環境構築
これに尽きるわけです。
データサイエンティストがやりたい仕事はデータの処理であって、環境構築であったりAWSコンソールのぽちぽち作業ではありません。TerraformとCIツールを使って自動化していたとしてもプルリクを投げて承認をもらうという作業が付きまといます。そもそもJSONを書いてもらうのさえ得策だとは考えません。
このことからキスモで目指すべきインフラというのは「コマンド1つ入力したら環境構築がされていて、データが揃っているという環境を作り出すこと」です。
なお、これにはセキュリティ的なメリットも副次的に発生します。
具体的にはデータサイエンティストにIaaSインスタンスの作成や削除に関わる権限を直接与えなくていいという点です。この部分をアプリケーション側で吸収することが可能で、ミスがミスじゃなくなる環境づくりに向けて前進しているなと実感しました。
機能要件
とはいえこんなものを作るのは正直言って時間がかかるなぁという印象を受けたので、ある程度要件を簡易化して作業を行いました。その中で実現したものが以下のものです。
- 前処理を行なったデータのあるディレクトリを指定すると起動するインスタンスにデータがアップロードされる。
- インスタンスはコマンドから指定可能。
- ローカルの環境は可能な限り汚さない。
- 作成完了、作業終了時にSlackに通知が飛ぶ。
- 使っていない資源を見つけてアラートを出す。
非機能要件
機能以外のところでも目指した部分はいくつかありますのでご紹介します。
- "pay as you go"を最大限に実現する。
- インフラエンジニアがいなくても運用可能。
- 拡張、開発が容易。
実現方法
AWSが提供しているFaaSであるLambdaを利用してシステムの構築を行いました。
アーキテクチャはこんな感じです！
FaaSを利用することで起動等のアプリケーションの運用コストをほぼ0にしました。
100万リクエストあるいは400 GB-秒のメモリ割り当てまでは無料で運用できるというのはかなり嬉しい部分です。
具体的にはPythonのAWS用SDKであるboto3やawscliを利用することで実装がなされています。アーキテクチャ的にはデータのアップロードとインスタンスの起動は分かれているのですが、実際には1コマンドにまとめてあります。
全体として、認証情報は環境変数や外部からのマウント、クラウド資源に権限を直接アタッチすることで実現しています。結果として、ソースコードやリポジトリに認証情報は一切含まれず、セキュアな状態が保たれています。
awscliの使い方
awscliはPythonで実装されているので、多くのPython環境を行き来するデータサイエンティストが利用するのはあまり得策ではないと考えました。そこでコンテナを利用することで環境が汚れることを回避しています。具体的にはローカルからデータをS3に与える際に利用しています。
インスタンス起動
データはハードコーディング的に埋め込むことはせず、環境変数で定義しています。環境変数にはインスタンス起動時に実行されるシェルスクリプトであるユーザデータも含みます。なお、改行等の扱いが面倒臭かったためにシェルスクリプトは一旦BASE64にエンコードしています。このユーザデータを利用してS3にあるデータの取得や流動的な部分の環境の構築を行なっています。
開発するにあたり、環境変数やユーザデータの定義が少しずつ面倒臭くなったためにユーザデータは独立ファイルに切り離し、デプロイスクリプトに含め、自動的にLambda用の形式に変換されるようにしています。なお、デプロイにはlambda-uploaderを利用しています。
Slack通知
通知にはSlackを利用しました。社内にチャット文化は根付いていますし、メンションされた場合にはチャットを見るということは徹底されています。ここに通知を貯めればひとまず問題ないと判断しています。
SageMaker、なぜ使わない？
この辺りまで来るとAWSを使っているのになぜSageMakerを使わないのかという話になってきます。
これについてはサービスとして継続的に利用している機械学習モデルでないことや、現在キスモで利用している省力化手法とSageMakerの相性があまり良くなかったという理由が挙げられます。とはいえめちゃくちゃ大きな問題というわけではないですし、SageMaker自体はとても便利なものであるということに違いはないので将来的に利用しているという可能性は多いにあるのかなという印象を持っています。
利用方法
現状はこんなような形で利用してもらっています。 場合によってはインタラクティブにしないかもしれないですが、その辺りは方針を見定めて決めていければいいなと思っています。
動作監視について
これに関しては現状は最低限となっています。具体的には毎時メモリ利用率の監視をしています。メモリ利用率が閾値を割った場合に処理を行います。これについては勤務中と勤務外で挙動は分かれるようになっています。これもLambdaで実装しています。
勤務中→Slackに該当ユーザ向けのメンションを送信する。
勤務時間外→2回連続でメモリ利用率が低かった場合にインスタンスを停止する。
なお、停止インスタンスに関しては勤務時間になると起動するようになっています。現状は出力ファイルが一意に定まるわけではないみたいなので推論終了時にS3にアップロードしてインスタンス削除という方法に関しては実装できていません。
勤務時間外のLambdaはステートを利用した処理が必要になってくるわけですが、これに関してはS3を利用しています。理由としては処理に速度が求められないことから価格面を最優先したためです。他の方法だとLambdaマネージドのキャッシュやElastiCache、DynamoDBを使うような解決策があります。
これからの開発について
最低限利用できる状態としては現在のものでも提供されていますが、実現しなければならないものはまだまだいくつも存在します。
具体的には、
- 金銭見積もり機能の実装。
- OSイメージのコード化およびCI。
- 機械学習実行環境としてのコンテナ利用。
というようなことが挙げられます。
今後もデータサイエンティストが使いやすい技術資本を作っていけたらなと思います。
おわりに
今回はキスモの社内省力化に向けて行なってきたクラウド資源の利用方法について紹介しました。
FaaSやコンテナを駆使したクラウドネイティブな基盤構築ができたんじゃないかなと自分では思っています。
それではまた、何かまとまれば技術発信できればいいなと思っています。
ここまでお読みいただき、ありがとうございました！
もっとキスモのことを知りたい方は
こちらをご覧ください！
世界一のデータサイエンティストを目指して 〜Kaggle参加レポート4〜
こんにちは！
株式会社キスモのKaggler 大越です。
まずはじめに嬉しい報告があります！
Googleが運営するKaggleで6月末まで開かれていた、データ分析の世界大会Avito Demand Prediction Challengeで、なんと、1917チームある中で7位に入りました！
またそれに伴い、上位13チームのみに送られる、最上位メダルのゴールドメダルを獲得しました！！
Kaggleを初めて約1年、最大の目標だったゴールドメダルを取れて嬉しすぎです！
さて、今回のブログではその際に使ったテキストデータの処理に注目して紹介しようと思います。
テキストデータとは？
テキストデータとは文字通りテキストで書かれたデータの事を言います。
この例は、コメントからお店の評価を予測するものです。
応用例としてはECサイトのコメント分析やニュース記事の分析、医療系の書類分析などが挙げられますね。
どのようにお店の評価を予測するのか
予測の際は、まずテキストを数値になおす必要があります。
この例では出てくる単語の数をカウントして数値にしています。
そして、その数値を使って下記のような式を作ります
こうして見るととても簡単ですよね！
一般的にテキストを用いた分析は、テキスト->数値->予測というプロセスを通して行ないます。
avitoでのソリューション
ここからは技術的な話になります。
今回のavitoの最終的なモデルはstacknetでした。
そのため多様なモデルを作る必要があり、様々なテキストの処理を行いました。
ツールはsklearnのCountVectorizerやTfidfVectorizerを使用しています。
CountVectorizerの説明はこちらがわかりやすいと思います。
vectorizer = FeatureUnion([
('text_word',CountVectorizer(
ngram_range=(1, 2),
max_features=500000,
min_df=3,
binary=True,
preprocessor=get_col('txt'))),
('text_char',CountVectorizer(
ngram_range=(2, 4),
max_features=200000,
min_df=30,
binary=True,
analyzer="char",
preprocessor=get_col('txt')))
])
avitoではこれを基本として、下記のような様々な処理を施して多様性を生み出し、ベストなテキスト特徴を探索しました。
- text_char(文字レベルのngram処理)を使う or 使わない
- ngram_rangeの変更
- binary = True or False
- CountVectorizer or TfidfVectorizer
- stemmingを使う or 使わない
- 3種類あったテキストを別々に処理 or 結合して1つのテキストとして処理
どこまで効果があったか正確には測れていないですが、モデルを量産できた1つの要因はこのようなテキスト処理にあります。
これらの処理はメルカリコンペの1位のソリューションを参考にしたものです。
char ngram, ngram rangeの説明
ngramとは指定したnの値分の単語または文字を1つのまとまりとする方法です。
n=2なら「見た目・は」という2単語を1つのまとまりとして、CountVectorizerの処理を行います。
また、ngramは分割の方法が2種類あります。
char ngramは「見た目は」というテキストを「見・た・目・は」のように文字ごとに分割してとngram処理を行います。
一方、word ngramは「見た目は」というテキストを「見た目・は」と単語ごとに分割して行います。
stemmingの説明
stemmingを使用すると、「美味しかった」と「美味しい」のように過去形現在形の表記揺れがあるものを同じ「美味しい」として扱ってくれるので、より単語の意味に沿った特徴を作れます。
今回はロシア語だったのでnltkのstemmingを使用しました。
まとめ
今回紹介したのはあくまでsolutionの1部で、さらに詳しいものはこちらに書いてあります。ぜひ読んでみてください！
もっとキスモのことを知りたい方は
こちらをご覧ください！
製造業×AI｜画像認識を利用した傷部品分類
株式会社キスモの大越です。
今回は製造業でのAI活用事例を題材に、簡易的なデータで実験した例をご紹介します！
製造業とAI
昨今、製造業においてAIの活用が進みつつあります。
これまで属人化していた作業をAIで代替し、作業を効率化したいというニーズを多く耳にします。
代表的な例は、画像認識を用いた不良品検知やセンサーデータを用いた機器の故障予測などが挙げられます。
課題定義
今回は、工場などで作られる部品の異常検知をテーマに、「画像認識を利用した傷部品分類」を行います。
右が正常画像、左が異常画像で、こちらには黒い線で傷が入っています。
データは自分たちで撮影した部品画像にランダムな黒い線を入れて作りました。
下記はその枚数です。
| データ種類 | 学習データ数 | 検証データ数 |
|---|---|---|
| 正常画像 | 888 | 222 |
| 異常画像 | 888 | 222 |
具体例、技術的な解説
画像分類で広く利用されているCNNを用いた画像分類モデルを作成しました。
弊社ではモデルのサイズや性能の異なる3つのモデルを用意しており、今回は1番単純なモデルを使用しました。
| score | |
|---|---|
| val loss | 0.000682493 |
| val acc | 1 |
| val precision | 1 |
| val recall | 1 |
検証データのスコアです。
これを見ると精度100%(val acc=1)で予測できていることがわかります。データが少し簡単すぎましたね。
評価指標の詳細についてはこちらの記事が参考になります。
また、lossには2値分類で一般的に用いられるbinary cross entropyを使用しました。
| true=正常 | true=異常 | |
|---|---|---|
| pred=正常 | 222 | 0 |
| pred=異常 | 0 | 222 |
混同行列です。
左上が正常を正常と予測した数、左下が正常を異常と予測した数...です。
これを見ても、正常なものを正常、異常なものを異常と予測できていることがわかります。
最後に
製造業における異常検知は、データさえご用意していただければ、弊社のソリューションを用いて解決することができます。
このような事例に取り組みたいとお考えの企業さまは、弊社のAI導入支援サービスLeadAIより、お気軽にお問い合わせください！
最後まで読んでいただき、ありがとうございました！
もっとキスモのことを知りたい方は
こちらをご覧ください！
【テキスト分析】Word2vecのための前処理入門
こんにちは、キスモインターン生の杉森です。
今回はテキスト分析において必要不可欠な前処理と最も有名な技術の1つであるWord2vecについてご紹介します。
テキスト分析を取り巻く環境
まずはじめに、テキスト分析を取り巻く環境について簡単に説明します。
近年の情報技術の発展に伴い、ニュースがインターネットを通じて配信され、私たちもTwitterやFacebookなどのソーシャルメディアを通して様々な情報を発信できるようになりました。これらの情報の総量は日々増加しており、莫大な量のテキストデータがオンライン上に存在しています。
このような背景のもと、オンライン上の莫大な量のテキストデータから様々な情報を抜き出すことで、今までは得ることができなかった情報や知見を得ることができると期待されています。
テキスト分析の簡単な例として、キスモの技術ブログの記事でよく使われている単語を表現するワードクラウドを構築しました。
AIやCNN、Pythonなどキスモの事業と関連のある単語が見て取れますし、役員の大越が参加している世界的なデータ分析コンペティションであるKaggleという単語を見ることができます。
このように、頻出単語を調べるという非常にシンプルなテキスト分析でも、キスモという企業の特徴をつかむことができます。
前処理
では、早速テキスト分析において非常に重要なプロセスである前処理について説明します。
形態素解析
テキスト分析を実行するためには、私たちが普段使っている自然言語で構成されているテキストを、コンピュータが扱いやすい形式に変換する必要があります。そのための第一歩として、文章を単語で区切ったリストに変換する必要があります。
英語の場合は、単語がスペースで区切られているため簡単にリストに変換することができますが、日本語のテキストは英語のように単語の区切りが存在しないため、テキストから単語を特定する形態素解析という処理を行う必要があります。
- 英語：”I live in Nagoya” -> [“I”, “live”, “in”, “Nagoya”] スペースで単語の分割可能
- 日本語：”私は名古屋に住んでいます” -> どうやって分割するのか?
形態素解析を行うためのライブラリは複数ありますが、本稿ではMecabを利用し、その辞書にはデフォルトの辞書ではなく、NEologdと呼ばれる辞書を利用します。
NEologdを使うメリットは、通常の辞書よりも固有名詞を抜き出せるという点が挙げられます。実際に、NEologdのGithubを参考にデフォルト辞書との違いを比較してみます。
「10日放送の「中居正広のミになる図書館」（テレビ朝日系）で、SMAPの中居正広が〜」という文章に対して、形態素解析を行うと、以下のような結果が得られます。
デフォルトの辞書
NEolod
デフォルト辞書では番組名や個人名等が分割されてしまっていますが、NEologdを利用した場合では、番組名や個人名を固有名詞として抽出できていることが確認できます。
日本語の文章では文法上の問題で、助詞（「は」、「の」、「が」など）などの一部の品詞が頻繁に出現します。そのため、これらの品詞を無視して、文章の意味を構成している単語に注目できるようにするために、「名詞」、「動詞」、「形容詞」などのような重要な意味を有する品詞以外は削除するのが一般的です。
ストップワード
また、ストップワードと呼ばれる単語を取り除く処理が重要になります。
英語の場合のストップワードはa, theなどのような必然的に出現回数が多くなる単語などが該当します。英語などの主要な言語については、NLTK（Natural Language Toolkit）が提供しているストップワードリストを利用するのが一般的です。
しかし、NLTKは日本語のストップワードリストを提供していないため、デファクトスタンダードと言える日本語のストップワードが存在しないという問題があります。そのため、日本語の場合は自身でストップワードリストの用意をする必要があります。日本語のストップワードの具体例としては、「する」、「れる」、「ある」などのほとんど意味をなさないにも関わらず、文章中に頻繁に出現する単語が挙げられます。
ここまでの処理を実行することで、文章を単語で区切られたリストに変換することができます。ですが、このままではコンピュータが演算を行うことができないため、リストに含まれている各単語をone-hotベクトルと呼ばれる形式に変換します。
one-hotベクトル
単語にユニークなインデックスを与え、単語をそのインデックスの要素が1それ以外の要素を0とするベクトルに変換します。このベクトルの次元数は出現する単語の種類数になります。
このように、日本語のテキスト分析は英語などの言語のテキスト分析と比べると前処理が少し複雑になっていますが、この一連の前処理を行うことで英語などの言語と同様に、後述するWord2vecなどを利用したテキスト分析を行うことができるようになります。
Word2vec
ここからは、Word2vecについてご紹介します。
Word2vecとは文章中の単語を任意の次元のベクトルに変換し、単語同士の演算や単語の類似度の導出を可能にします。（Word2vecを実装する際には、Pythonのライブラリgensimを利用するのがおすすめです。）
単語同士の演算で最も有名なものは、以下の式で表されます。
「王」 - 「男性」 + 「女性」 = 「女王」
これは、「王」のベクトルから「男性」のベクトルを引き、「女性」のベクトルを足し合わせたベクトルと最も近いベクトルを持つ単語が「女王」であるというものです。
このように、Word2vecを利用することで今までにはできなかった様々な分析が可能になります。
Word2vec：単語のベクトル化
Word2vecでは、文章中の単語とその周辺単語に注目をして、NN（ニューラルネットワーク）の学習を行います。このNNの重み行列として単語ベクトルが学習されます。
次にWord2vecの2種類のアルゴリズムを紹介します。
ここでは、注目している単語を単語:X、その周辺単語を単語:A~Dとします。また、ベクトルの次元は次元:n、出現する単語の種類数を個数:mとします。
CBoW
周辺の単語を入力として、各単語の出現確率が出力になります。ターゲットとなっている単語の出現確率が最大となるように学習を行います。
Skip-gram
ターゲットとなっている単語が入力データで、各単語の出現確率が出力になります。周辺の単語の出現確率の和が最大となるように学習を行います。
Skip-gramを利用する場合を例として、Word2vecの原理について詳しく見ていきましょう。
Skip-gramの場合、入力はone-hotベクトルで表現された一つの単語のみ、つまり、m次元のベクトルとなります。出力も同様にm次元のベクトルであり、one-hotベクトルにおいて周辺単語が相当する要素の確率の和が最大になるように学習を行います。
次は、NNの重み行列に注目したいと思います。この重み行列の大きさはn×mであり、各行成分が各単語のベクトルに相当します。これは、入力が一つの要素の値が1で、それ以外の要素の値が0である、m次元のベクトルであることに基づいています。
最後に
今回の記事でご紹介したように、テキスト分析は比較的簡単に実装することができます。
この記事を通して、テキスト分析に興味を持っている方々や、これからやってみようと思っている方々に、テキスト分析の基本的な知識を学んでいただき、実際に挑戦していただければ幸いです。
ここまで読んでいただきありがとうございます！
参考
NEologd
https://github.com/neologd/mecab-ipadic-neologd/
gensim
https://radimrehurek.com/gensim/
もっとキスモのことを知りたい方は
こちらをご覧ください！
CNNを用いた物体検出アルゴリズムYOLOv3に迫る！
キスモインターン生の内山です！
最近かなり暑くなってきていますね、夏の訪れを感じます。
さて今日は物体検出についてお話ししようと思います。
物体検出とは、
下の画像のように、画像に写っている物体の座標を予測し、その物体が何かをクラス分類するものです。
(YOLO論文[1]より引用)
今回はその中でもCNNを用いた物体検出に着目し、論文リサーチを行いました！
R-CNN
この物体検出の先駆けとして、2014年に発表された論文がR-CNNです。
R-CNNのアルゴリズムは、
- 画像をinputする。
- 画像から物体領域の候補を最大2000枚選び出す。
- 選び出した候補画像を全て一定の大きさにリサイズして、CNNにかけ、特徴量を取り出す。
- 取り出した特徴量を用いて物体のクラス分類と、物体を囲う位置座標(バウンディングボックス)の回帰を行う。
というのが主な流れです。
(R-CNN論文[2]より引用)
R-CNNの登場以前は、深層学習を用いない物体検出方法がメインでしたが、その認識精度からかなりの向上を果たすことができました。
一方で、1枚の画像に対し、最大2000枚の物体候補の特徴量を取り出して、クラス分類と回帰を行うので、実行時間がかなりかかってしまうことが問題点とされていました。
その後、Fast R-CNNやFaster R-CNNといったR-CNNの改良版が続々と発表され、速度・精度共に改善されていきましたが、リアルタイムで検出するための速度まではなかなか達しませんでした。
YOLO
その後、2016年に発表されたのが、YOLO(You Only Look Onceの略)です。
You Only Live Once（人生は一度きり）をもじったタイトルで発表されました。著者のお茶目さがにじみ出ていますね。
それまでのモデルでは物体領域候補をたくさんあげ、それぞれに対してクラス分類をしていましたが、YOLOは物体領域候補を選び出さずに、1つのCNNで物体の検出からクラス分類まで一気に予測してしまうという画期的なモデルです。
その結果、20クラスの物体をリアルタイム検出が可能な速度で認識することができるようになりました！
アーキテクチャには24層のCNNが使われており、過学習を防ぐためにepoch数に応じて学習率を変化させているのも特徴的です。1つのCNNで予測を完結させるために、CNNの出力層の形式に工夫が見られます。
(YOLO論文[1]より引用)
7×7×30の出力層は、inputした画像を7×7のグリッドに分割し、各グリッドに対して、2つのバウンディングボックス(5チャンネル×2)と1つのクラス(20チャンネル)を予測することを意味します。バウンディングボックスの5チャンネルは、中心の座標(x,y)と高さと幅(h,w)、さらにそのボックスの信頼度cが計算されます。信頼度cが閾値を超えた時のそのボックスのクラスを出力します。
イメージは下の図のような感じです。
(YOLO論文[1]より引用)
さらに、2017年にはYOLO9000[3]というタイトルで、9000クラスの物体検出ができるYOLOのver.2の論文が発表され、2018年にはさらにその進化版のYOLOv3[4]が発表されました。 どんどんと発展していますね。
簡易実験
ソースコードや学習済みモデルが公開されているので、今回はYOLOv3で精度を検証してみました！
まず1つ目の実験に使う画像はこちらです！
キスモ創立1周年の時に、代表取締役三野から記念のGODIVAをもらった時の写真です！(GODIVA美味しかったなあ。)
写っている7人全員を検出できるのか、手前のテーブルを検出できるのかといったところが鍵になりそうです。
YOLOv3により物体を検出した結果がこちらです！
見事に7人全員とテーブルを検出できています。さらに一見、人の目で見ても認識できない左下のソファも検出できています！すごい！
ではもう1枚いきましょう！
普段の業務の様子を撮った写真で検証します。
先ほどよりも写っている物が増えたので検出が難しそうです。机の上のものや奥にある家具はどのように認識されるのでしょうか？
検出した結果がこちらです！
先ほどと同様に、人は高精度で検出できているのに加えて、ノートパソコンやテーブル、椅子なども正しく検出できています。左側の本棚の中にある本も検出しているのはすごいですね！
右下の役員鈴木の手の間の黒い部分をマウスと、ディスプレイのリモコンを携帯電話と誤認識してはいますが、物体の特徴は捉えられているので、許容範囲という印象です。
最後に
このように物体検出はこのレベルまで技術が向上しています。今回は、YOLOを中心にご紹介しましたが、SSDをはじめ、他にも物体検出のモデルはいくつか発表されています。バウンディングボックスでなく、クラスの領域をピクセル単位で求めるセグメンテーションという分野の研究もどんどん進んでいます。
このような技術を応用して、世の中がどんどん便利になっていくのが楽しみです！ 「働くをアップデートする」を理念に掲げるキスモもその一翼を担い、AIの民主化を進めるべく、精進してまいります！！！
最後まで読んでいただきありがとうございました。
参考文献
[1] Redmon, Joseph, et al. "You only look once: Unified, real-time object detection."
[2] Girshick, Ross, et al. "Rich feature hierarchies for accurate object detection and semantic segmentation."
[3] Redmon, Joseph, et al. ”YOLO9000: Better, Faster, Stronger”
[4] Redmon, Joseph, et al. “YOLOv3: An Incremental Improvement”
もっとキスモのことを知りたい方は
こちらをご覧ください！
開発を爆速にするキスモの機械学習基盤
こんにちは！キスモインターン生の岡野です。
キスモではインフラエンジニアとして働いています。
今回はキスモで新たに構築した機械学習基盤をご紹介します。
結論から言うと以下のようになったのですが、
ここに至る経緯と結果的に享受できるメリットを書いていきます。
クラウド or オンプレ
インフラを構築していく場合、
まずこのあたりから選択することになると思います。
2005年のAWSのローンチを皮切りにして、
MicrosoftのAzure、GoogleのGCP等が非常によく利用されるようになりました。
このような背景から、
IT分野はとにかくクラウドに移行すればいいのではないかという疑問も生まれます。
しかしながらオンプレミスにするメリットもまだまだ多く残っています。
そこでまず、クラウドとオンプレを比較します。
クラウドのメリット
クラウドのメリットは"とにかく柔軟であること"
これに尽きると思います。
クラウドを利用する場合、資源はクラウドの提供ベンダが持つため、
ユーザは必要なときに必要な分の資源を利用することができます。
また、使った分だけお金を払う従量課金制であることも大きな特徴です。
このような特徴から、
等には非常に適しています。
オンプレミスのメリット
オンプレのメリットは "お金を気にせずに利用できる" という部分になると思います。
また、ハードウェアの選定が自由であるというのも大きな特徴になってきます。
結果として、
- トラフィックがめちゃめちゃシビアなシステム
- 安定してアクセスが期待できるシステム
- 薄利多売のビジネスモデルを持つシステム
にはオンプレミスはまだまだ根強く使われています。
キスモでの選択
キスモでは、計算資源としてオンプレミスを利用することにしました。
理由としては
- 性能の高い計算資源をすでに持っている
- Kaggleと業務で断続的に学習が行われている
- コンサル業務なのでクライアントに応じて多くのアプローチを試す必要がある
- 計算資源として利用するために使用量の変化は人員の増加速度に依存し、むちゃくちゃ高速というわけではない
というものです。
キスモの開発基盤で満たしたいこと
次に、オンプレミスをどのように利用していくかというところを考えていきます。
キスモでのインフラに対する要求と対応方法を下表にまとめています。
| 要求 | 対応方法 |
|---|---|
| 「やってみたい」がすぐ試せる | コンテナ技術の利用 |
| インフラ基盤を気にしなくて良い | Kubernetes, etcdを利用した資源のクラスタ化 |
| 開発にかかる時間やストレスの軽減 | Rancherを利用してGUIで利用 |
| どこでも自由に開発ができる | IP-VPNを利用した通信路の確保 |
アーキテクチャについて
再掲載となりますが、結果として以下のようなインフラとなりました。
各技術の概要
Kubernetesについて
環境を簡単に作っては壊してというところを実現するために
コンテナ技術(Docker)を利用しています。
しかし、Dockerを動かすためにどこにメモリやGPUの余裕があるのかを
開発者にいちいち考えさせるのは得策ではないと考えています。
そこで資源管理をある程度作業から切り離すために、
コンテナオーケストレーションツールとしてKubernetesを利用しています。
また、Kubernetesに計算資源を追加する際にラベルをつけ、
開発者は使いたいGPUを指定して学習することができます。
クラスタ化について
Kubernetesを利用することで複数の計算機はクラスタとして扱われます。
データの共有はetcdという分散KVSで行われています。
複数の計算資源をまとめて扱うことができるため、
開発者はどの計算資源を使うかを悩む事なく学習を行うことができます。
また、クラスタ化されているからこそ、
必要に応じて容易に計算資源を追加できるようになっています。
Rancherについて
キスモではKubernetesでWebサービスを運用しているわけではありません。
結果として、Kubernetesの中で使いたい機能は比較的少ないです。
それでも慣れるまでそこそこの時間的コストがかかります。
そこで、キスモではKubernetesの管理にRancherを利用しています。
Rancherを利用することで開発者はGUIでKubernetesを操作できます。
また、資源の管理状態が一目で確認できるようになるので、
管理者としてもかなり扱いやすくなっています。
VPNについて
キスモでは役員2人が常時リモートで働いているほか、
必要に応じてリモートで働くことを認めています。
今回は計算資源をオンプレミスに配置しているため、
ここに対して外部からアクセスできるようにする必要がありました。
そこで、端末とオフィスのルータの間でIP-VPNを設定し、
何処からでもセキュアに計算資源へアクセスできるようにしています。
得られたメリット
これらの技術を組み合わせてインフラを構築したことで得られたメリットは、
- コンテナ技術を利用するため得られる、ユーザおよびプロジェクトごとの独立性
- コンテナならではのポータブルで軽快な実行環境
- どの計算資源に空きがあるか考えなくても良い簡単さ
- どのコンテナからでも共通の資源にアクセスできる利便性
- インターネットさえあれば何処からでも作業ができる快適さ
- Kubernetesの利用により得られるスケーラビリティ
です。
今後の拡張
MAASを利用した構成の自動管理を行い、
ほとんど何もせずともクラスタに資源を追加できるようにしたいと考えています。
そのほか、AWSに関してもInfrastracture as Codeをきちんと意識して
社内で利用している環境の透明化を目指します。
その後、AWSとオンプレミスの資源をうまく連携させ、
何処の資源も自由に使うことのできるインフラを目指します！
おわりに
今回は技術的な側面からキスモのインフラについて記述しました。
自分は今後もキスモの労働環境整備に努めます。
まとまったらまた技術に関する情報を発信しますので
今後ともよろしくお願いします！
