Amazon SageMaker ハンズオンレポート

はじめに

AIシステム部・AI研究開発グループの益子です。 現在はオートモーティブ事業において、AI研究開発エンジニアとして働いています。

先月20日、DeNA社内において、アマゾン ウェブ サービス ジャパン(AWS)様より「Amazon SageMaker」ハンズオンを実施していただきましたので、その模様をレポートさせていただきます。

DeNAでは、すでに数多くのサービスでAWSを活用しています。私の所属するAIシステム部もその例外ではなく、機械学習のモデル開発に幅広く利用しています。

昨年のAWS re:Invent 2017において「Amazon SageMaker」が発表されましたが、発表の後さっそく社内でも利用したいという声が上がり、AWS様より社内エンジニア向けハンズオンを実施していただけることになりました。

Amazon SageMakerとは

Amazon SageMakerとは

  • AWSインスタンス上にJupyter Notebookを構築
  • Notebook上での機械学習モデル実装
  • AWSのインフラを利用した、分散学習
  • 学習したモデルを組み込んだ予測APIの自動生成

まで一貫して行える、フルマネージドサービスです。 https://aws.amazon.com/jp/blogs/news/amazon-sagemaker/

Jupyter Notebookといえば、すでにデータ分析/機械学習アルゴリズム開発においてデファクトとなりつつあるツールですが、それがコンソールからポチポチするだけで、簡単に構築できるのはかなり大きなメリットとなります。

img1.png

SageMakerの機能 (講義資料より)

また、これまで機械学習サービスを開発する場合には

  1. 学習環境構築とデータ整備 (インフラエンジニア)
  2. 機械学習モデル実装(機械学習エンジニア)
  3. 学習済みモデルをサービス内にデプロイ(サービス開発エンジニア)

の手順が必要であり、案件によっては複数のエンジニアが関わる必要がありました。

SageMakerにより1.と3.の手順がほぼ自動化されるため、機械学習エンジニアはモデル実装に集中でき、また単独でサービス展開まで行うことも可能になります。

ハンズオンの流れ

20180309_190140.jpg

当日は、AWSより志村誠さんを講師に迎え、主に機械学習アルゴリズムのサービス適用という話題を中心に講演していただきました。

前半はスライドを用いてSageMakerの概要の説明、後半は実際に弊社環境内にJupyter Notebookを立ち上げて、ハンズオンという形式になっています。

ハンズオン参加者の内訳

DeNAからはエンジニアを中心に50名超参加しました。

chart_capture.png

参加者の内訳

参加者の内訳を見ると、幅広い分野のエンジニアが参加しています。また今回エンジニア向けとして開催したのですが、ビジネスメンバーからも参加があり、機械学習への関心が非常に高いことが伺えます。

それでは、以下当日のハンズオンの流れに沿って、詳細をレポートしていきます。

前半: 講義

前半は講義形式をとり、SageMakerについて解説していただきました。

img2.png

講義資料より

SageMakerを利用して機械学習を行う場合、主に3つの選択肢があります。

  • ① AWSが提供するアルゴリズムを利用
  • ② AWSがサポートするフレームワークを利用
  • ③ それ以外のアルゴリズム・フレームワークを利用

もっともお手軽なものが①で、すでにある程度の機械学習アルゴリズムはプリセットとして用意されています(後述)。

②は①に含まれないアルゴリズム、例えばディープラーニングモデルを独自に実装したい場合に利用することになります。対応しているフレームワークは限られていますが、分散学習もサポートされるので、柔軟性もありつつ、クラウドのメリットを享受できます。

もっとも柔軟性があるのは③の方法ですが、こちらは学習用のDockerコンテナを自前で用意する必要があり、一手間必要です。その代わり、①、②で提供されていないアルゴリズム・フレームワークが利用可能となります。 DeNAではchainerで開発しているチームも多く、その場合は③の方法になります。今後も①〜③の方法を適材適所で使い分けていくことになると思います。

①のAWS提供アルゴリズムですが、すでに一般的な回帰・分類問題などがカバーできるように用意されているようです。

img3.png

講義資料より

今回のハンズオンでも、①Amazon提供のアルゴリズムを利用した線形回帰問題のケースを実装していきました。

後半: ハンズオン

img4.png

当日の様子

ここからは、参加者全員分のJupyter Notebookインスタンスを立ち上げ、実際にSageMakerによる機械学習をいくつか試していきます。

Notebook インスタンスの作成

Notebookに利用するインスタンスタイプなどを設定するだけで、あっという間にJupyter Notebookが立ち上がりました。 notebook_creation.png img5.png

AWS提供アルゴリズムによる線形回帰 - 学習

サンプルとして、まずはAWS提供アルゴリズムの線形回帰モデルを試しました。 img6.png

img7.png

ハンズオンに使用したノートブック

データロードの部分は省きますが、AWS提供のアルゴリズムを利用した場合、上記コードだけでモデル学習を実行してくれます。学習用の関数であるlinear_estimator.fitを実行すると、Notebook インスタンスとは別に学習用のコンテナが立ち上がり、ジョブを実行してくれます。

img8.png

講義資料より

内部の挙動としては、SageMakerがS3から事前に配置した学習データを読み込み、コンテナ上で学習、学習した結果のモデルを再度S3に書き戻しておいてくれる、という仕組みになります。

S3に出力される学習済みモデルファイルですが、AWS提供アルゴリズムの場合はSageMaker専用になっているためエンドポイント経由での推論が前提となります。一方でDLフレームワークで独自実装した場合や、学習用コンテナを用意して学習したモデル(手法②、③)に関しては、S3から直接モデルファイルを取得して推論アプリケーションに組み込むことができるそうです。

AWS提供アルゴリズムによる線形回帰 - デプロイと推論

img8_2.png

講義資料より

学習が終われば、上記のようにdeployを実行するだけで推論エンドポイントが作成されます。

img9.png

講義資料より

作成したエンドポイントに対して、入力データを投げると、推論結果が返ってきます。ハンズオンではHTTPリクエストをする代わりに、ノートブック上から直接エンドポイントを実行する方法をとりました。 img10.png

今回割愛させていただきますが、ハンズオンではその他、tensorflowによるirisデータセットの分類問題にも取り組みました。

DeepAR による時系列予測

講演の中では、DeepAR 使った時系列予測タスクも紹介されましたので、手元でも試してみました。

データセットとして予め波形データを作成し、これを学習させます。 img11.png

データセット

ここでは実行コードは省きますが、全体の処理の流れは線形回帰で試したものと同様です。

img12.png

DeepARによる推論結果

推論結果として、80%信頼区間と予測中央値を得ることができました。 トレンドはうまく捉えられているようですが、ピーク部分にずれがあります。ここはさらなるチューニングで改善できるかもしれません。

DeepARは元々、Amazon.com内における予測タスクに利用していたものだそうです。 AWS提供アルゴリズムのため、特別なセットアップをする必要なく、時系列予測問題に適用することができます。 時系列予測モデルはビジネスシーンでも利用頻度が高く、例えば機械学習アルゴリズムには詳しくないエンジニアやアナリストが、とりあえず現場のデータで精度が出るかやってみたい、という場合に使えそうです。

まとめ

以上、ハンズオンでは実際にAWS上で機械学習アプリケーションの学習とデプロイまでを行うことができました。

モデルの実装から推論用のエンドポイントの作成まで、特別インフラを意識する必要はありません。機械学習エンジニアにとってはよりアルゴリズム開発に集中できるのではないかと思います。

現在Google Cloud Platform上にも同様なサービスとして「Cloud Machine Learning Engine」がありますが、機能の違いなど比較すると面白そうです。

最後に、個人的に便利だと思った点をいくつか上げておきます。

  • 単純にmanaged Jupyterとしても利用できる
    • SageMakerはモデル実装から学習、デプロイまで一貫して行えるサービスですが、それぞれ一部だけ利用することもでき、Jupyter Notebookだけの利用も可能です。これを使えば簡単にGPUインスタンス上にJupyterを立ち上げてさっと使う、ということもできそうです。
  • データの暗号化に対応
    • 学習データ/推論結果も、プロダクションレベルにおいては高いセキュリティレベルでの取扱いを要求される場合も多く、データを暗号化する仕組みがサポートされているのは助かります。

注意点も上げておきます。

  • 現在SageMakerは東京リージョンでは提供されていませんので、実際のサービスに組み込む際には留意しておく必要があるでしょう。
  • Notebookインスタンス数など、SageMaker に利用するリソースはアカウントごとに上限が設定されています。もし社内で大規模に利用する場合には、事前に上限を上げる申請をしておく必要があります。(今回のハンズオンでも実施しました。) https://docs.aws.amazon.com/jajp/general/latest/gr/awsservice_limits.html

以上.

続きを読む
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

DeNA TechCon 2018 開催レポート[1]

こんにちは!SWETグループの加瀬です。
この時期の恒例行事となった今年のDeNA TechCon 2018が2018年2月7日に開催されました。今年は第3回目の開催となります。

tech_con_day1_1_resized.jpg

今回から全4回の予定でTechConの様子をお伝えしていきます。第1回はOpeningとKeynote、そしてYELLOW Stage『DeNAが切り拓くAI』の発表の紹介です。

オープニング

tech_con_day1_2_resized.jpg

オープニングでは木村よりDeNA TechConの概要についての説明がありました。
DeNAは色々な事業に参入しており、その中のエンジニアも色々な領域でチャレンジをしています。それを知ってもらう場がDeNA TechConであり、また少しでも技術の進歩の役に立てればという思いが語られました。

Keynote - エンジニアが引っ張るDeNAの"モノづくり"

tech_con_day1_3_resized.jpg

エンジニアが引っ張るDeNAの"モノづくり" from DeNA

今年のKeynoteは、代表取締役社長兼CEOである守安からDeNAにおける"モノづくり"の発表でした。

自身は元々エンジニア出身で、DeNA初期の頃の主力事業であったEコマースの『ビッダーズ』(現『Wowma!』)に夜勤でシステムの監視をする仕事から関わっていたという話から始まり、その後の『モバオク』、『Mobage』、そして現在、力を入れているオートモーティブ事業まで、DeNAのサービスにおいて発生した技術的な課題と、それらをどのように解決してきたかということが語られました。

その中で、分業体制で開発されていたために開発スピードを出すことができなかったビッターズの反省から、当時アルバイトだった川崎(現取締役)にモバオクの開発を一任し、1人で3ヶ月という短期間で完成させたエピソードが紹介されました。

最後に、サービスづくりをエンジニアが引っ張ることと、サービスの課題を高い技術力で解決することをDeNAの強みとして持ち続けたい、という話で発表を締めくくりました。

深層学習を用いたコンピュータビジョン技術とスマートショップの実現

tech_con_day1_4_resized.jpg tech_con_day1_5_resized.jpg

深層学習を用いたコンピュータビジョン技術とスマートショップの実現 from DeNA

AIシステム部の西野と李による、現在のコンピュータビジョン技術の紹介と、その中の姿勢推定技術を活用したスマートショッププロジェクトについての話でした。

スマートショッププロジェクトとは、Eコマースで行われている商品推薦のような、一人ひとりに合わせた接客をリアル店舗でも行えるようにしようという試みです。 そのためには入店したお客の状況を把握する必要があり、カメラ映像から同一人物であることを検出するために姿勢推定技術をどのように用いているかという内容でした。

車両運行管理システムのためのデータ整備と機械学習の活用

tech_con_day1_6_resized.jpg tech_con_day1_7_resized.jpg

車両運行管理システムのためのデータ整備と機械学習の活用 from 英爾 関谷

AIシステム部の関谷と森による、車両運行システムを支える技術と、深層学習を用いて車両停車が可能な位置を自動的に見つける仕組みについての話でした。

自動運転、配車予測、経路探索といった車両運行管理システムがどのような技術によって実現されているかという紹介です。また自動運転を活用した物流オペレーションを実現するために、自動車が停車可能な安全で交通の妨げにならない位置を深層学習を用いて画像からどのように推定するかという内容でした。

ゲーム体験を支える強化学習

tech_con_day1_8_resized.jpg tech_con_day1_9_resized.jpg

DeNA TechCon2018 ゲーム体験を支えるための強化学習 from Jun Okumura

AIシステム部の奥村と田中による、アプリゲームのバランス調整を強化学習・深層学習で行うという話でした。

最近のアプリゲームは、リリースされてから長期間に渡り継続的にバージョンアップを続ける流れになってきており、DeNAがリリースしている『逆転オセロニア』においては新しいキャラクターを追加しながら全体のバランスを調整することが難しくなりつつあるという問題が起きています。 そこで強化学習・深層学習を用いて人間らしいプレイを行うAIを作り、そのAIによるシミュレーションを行うことでバランス調整に活用させるという取り組みについての内容でした。

深層学習を用いたコンピュータビジョン技術と運転行動モニタリングへの応用

tech_con_day1_10_resized.jpg tech_con_day1_11_resized.jpg

深層学習を用いたコンピュータビジョン技術と運転行動モニタリングへの応用 from Yusuke Uchida

AIシステム部の内田と本多による、コンピュータビジョン技術を活用した交通事故を減らす取り組みについての話でした。

深層学習を用いたコンピュータビジョン技術の解説と、それらを用いて運転中のよそ見や車間距離不足といった不安全行動を減らすことで重大な交通事後を減らすという取り組みが紹介されました。 また、大規模な演算処理が必要な深層学習をエッジデバイスである車両で行うために、精度を保ったまま演算数を減らす深層学習の軽量化手法についても発表がありました。

研究開発と事業貢献を両立させるAI組織の作り方

tech_con_day1_12_resized.jpg

YELLOW Stageの最後は、AIシステム部の山田によるDeNAのAI組織についての話でした。

DeNAのAI組織体制、AI/機械学習を活用したサービスの紹介、研究開発と事業開発の関わり方、AI・分析の基盤技術、AI研究開発エンジニアとデータサイエンティストの役割、先端技術をキャッチアップするための精度や設備といった非常に多岐にわたる内容の紹介と、今後力を入れていくところについての発表でした。

次回の第2回ではRED Stage『DeNAのチャレンジ』の発表を紹介する予定です。

続きを読む
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

サブカルのためのword2vec

はじめに

AIシステム部AI研究開発グループ アルバイトの五十嵐です。(@bonprosoft, ポートフォリオ:http://vbcpp.net/about/ ) 現在、東北大学大学院の修士1年で、大学院では(自然言語ではなく)高速な文字列処理アルゴリズムに関する研究を行っています。

私は2017年9月上旬から3週間ほど、アルバイト兼インターンとしてハッカドールチーム内のNLPのタスクに取り組んでいました。 その後はアルバイトとして、期間中にできなかった追加実験と実際の製品への適用に取り組んでいます。

取り組んだタスク

突然ですが、みなさま、ハッカドールはインストールされていますか? ハッカドールは、主にサブカルチャーに関する記事に特化した、ニュースアプリケーションです。 アプリケーション内のユーザーのクリックや「ホシイ/イラナイ」などのアクションを通して、ハッカドールがユーザーの好みを自動的に学習し、様々なジャンルの記事があるなかから、1日3回のおすすめ記事を配信してくれます。

さて、ハッカドールの裏側ではユーザーへ記事を配信するために日々膨大なWeb記事をクロールして、どの記事がどのジャンル・要素のものであるのかなどを識別し、検索サービスと同じようにユーザーへ記事を配信しています。 Web記事を適切に解析するためには、毎クール増えるアニメのタイトルはもちろん、話題となっている単語にもいち早く対応しなければなりません。

そこでハッカドールチームでは、形態素解析のための辞書を毎日自動的に構築するジョブを用意しています。 これにより、大部分の解析処理はうまくいくようになりますが、まだいくつかの課題が残っています。 それは、シノニム辞書の構築 です。 ここで言う「シノニム辞書」とは、アニメの作品名をはじめとした何らかの名称と略称/愛称を関連付けるための辞書のことを指しています。 シノニム辞書は、ハッカドール内において記事のタグ付けや検索において利用されています。 有名な例としては、次のようなものがあります。

  • ご注文はうさぎですか? ⇔ ごちうさ
  • Re:ゼロから始める異世界生活 ⇔ リゼロ
  • この素晴らしい世界に祝福を! ⇔ このすば

略称/愛称自体の分かち書きは、前述のジョブによりうまく動作しますが、その略称/愛称が指している名称との紐づけは現状自動的に獲得できておらず、この紐づけは現在手動で行っています。 2017年10月現在、シノニム辞書に登録されたエントリ数は約5600件にも達し、日々増えていくシノニムを今後も管理し続けるのはとても大変な作業です。 そこで今回は「シノニム辞書を何とか自動で獲得できないか」というタスクに取り組みました。

なお、シノニム辞書の自動構築にあたって、ハッカドール内で利用できるデータセットとしては次のようなものがあげられます。

  • 日々のWeb記事のクロール結果
  • アニメ/サブカルに関するタグ/キーワード集合
  • 日々更新される形態素解析用辞書
  • アプリ内の検索キーワード
  • 現時点で登録されているシノニムペア

以降の章では、先行研究と提案手法、評価実験に関する詳細を説明していきますが、もし読むのが大変に感じる場合や先に成果物だけを見たい場合には、次のURLからスライドとデモサイトをご覧ください。

サブカルのためのWord2vec from DeNA

先行研究

最初の1週間は、今回のタスク設定と近い、同義語獲得/同義性判定関連の先行研究を調査しました。 その結果、大きく分けて先行研究で用いられていた手法は、次の3種類に分けられると考えました。

  • 単語表記を考慮した同義語判定
  • 周辺文脈を利用した同義語判定
  • 検索クエリなどの関係情報を利用した同義語判定

それぞれの手法において、特に印象に残った論文を、簡単にご紹介します。

単語表記を考慮した同義語判定

同義語がもともとの名称をベースに作られることを仮定すると、編集距離などの表記を考慮した手法を適用することを考えるのが自然です。 2008年に高橋らが提案した手法[a]では、同義語を以下の3種類から生成されるものと仮定して、これらを考慮した同義語判定のためのフローおよび素性の作成を行っています。

  • 定型文字列の追加: 接頭/接尾辞等の文字列を追加
  • 表記変換: 読みを保存して表記を変換
  • 省略: 文字順を保存して文字を削除

判定ルールのなかには、例えば音節数を考慮した正規化や、SVMを用いた省略関係にあるかどうかの判定ロジックが含まれており、2つの単語の単語表記について、様々な観点から距離を計算するための手法が組み込まれています。

周辺文脈を利用した同義語判定

「同じ文脈に出現する単語は類似した意味を持つ」という分布仮説(Harris, 1954)に基づいて、単語の意味を表すベクトルを求めるためのモデルとして、近年ではSkip-gramモデル(Mikolov+, 2013,[b])を用いた研究が活発に行われています。 ここではSkip-gramモデルの詳細の説明は割愛させていただきますが、原理を簡単に説明すると、ある単語を与えたときに、出力と周辺に出現する単語が一致する確率が高くなるように図1の$W_e$と$W$を学習することで、適当なイテレーションを回した後に得られる$W_e$が単語ベクトルとして利用できるという仕組みになっています。 なお以降の図では、Skip-gramモデルを図1右下のような、省略された図を用いて表現することにします。(図1右上と右下は等価なモデルを示しています。)

図1 Skip-gramモデル ▲図1 Skip-gramモデル

Skip-gramモデルを利用した同義語獲得のアプローチとしては様々な手法がありますが、特に新しい手法として、城光らによって提案された、文脈限定Skip-gram(城光+, 2017,[c])があります。 この手法では、特定の品詞のみ/左右特定の位置のみを考慮するような制約を加えて、異なる制約を持った複数のSkip-Gramモデルを学習したあと、2つの単語ペアを与えたときに、これらのSkip-gramが出力するコサイン類似度を素性として、同義語か否かの教師あり学習を行っています。 論文中では、実際に合計254種類のSkip-gramを学習させたあと、これらのモデルを用いて同義語判定を行ったところ、通常のSkip-gramモデルだけの場合と比較して、F値が大幅に向上したと述べています。

検索クエリなどの関係情報を利用した同義語判定

同義語判定は検索エンジンにおいても重要となります。 2012年にMicrosoft Researchから発表された論文では、固有表現のシノニムを自動的に検出する手法に用いる指標の一つとして、Pseudo Document Similarity(Kaushik+,2012,[d])が提案されました。 この指標の前身となったClick Similarity(Cheng+, 2010,[e])は、2つのクエリの類似度を測るための手法として、検索クエリ集合とWebドキュメント集合を頂点とした二部グラフを考えたうえで、ある検索クエリからあるWebドキュメントにたどりついたときにエッジを張り、2つのクエリが与えられたときに、その値がどの程度一致するかという情報を用いています。 これに加えて、Pseudo Document Similarityでは、特に検索クエリが複数の単語からなる場合にもRecallがあがるよう、エッジの張り方を工夫しています。

先行研究の本タスクへの適用

先ほど挙げたそれぞれの手法を、今回のタスクへ適用することを考えてみます。はじめに次の例をご覧ください。

  • 終末何してますか?忙しいですか?救ってもらっていいですか? ⇔ すかすか
  • 友達ない ⇔ はがない

この例は、近年放送されたアニメの作品名とそのシノニムのペアを示しています。 1番目の例は、すかが3回繰り返し出現しているにもかかわらず、シノニムはそのうちの2回から構成されています。 また、2番目の例では、有用と思われる名詞や形容詞、漢字表記などを無視して、シノニムは主に助詞から構成されています。

これは主観ですが、1クール毎に増えるアニメ作品名の略称の競合を避けるためにも、作品名からのシノニムの推測は年々難しくなっていると考えています。 したがって、単語表記を考慮した同義語判定は、今回のタスクへ適用するのは難しいと考えました。

続いて、周辺文脈を利用した同義語判定ですが、単語分割さえできていればSkip-gramの学習が可能であり、周辺単語から単語自体が出現するコンテキストを推測する(単語表記を考慮しない)という性質から、今回のタスクにおいて応用可能であると考えました。 しかし、城光らの手法では、2つの単語がシノニムの関係にあるかどうかを判定するために、シノニムペアを教師データとして使用しており、教師データ作成のコストが必要です。 さらに、分類機の入力として合計254種類ものSkip-gramを用いており、この手法でモデルを頻繁に更新するのは難しいと考えました。

最後に、検索クエリなどの関係情報を利用した同義語判定ですが、今回のタスクへ適用するにはエッジを張るために必要な情報が足りません。 これは、検索クエリなどはデータセットに含まれるものの、その後のユーザーの行動に関する情報が含まれていないため、先行研究のようなエッジを張ることができないためです。 代わりに、検索クエリが文章に含まれているという関係をエッジとして使うことを考えましたが、この関係が果たしてどれくらい有効に働くかという点が見通せなかったため(3週間という限られた時間のなかで成果を出すため)今回はこの手法の採用を見送りました。

以上の理由から、今回のタスクは周辺文脈を利用した同義語判定ベースの手法で取り組みました。 しかし城光らの手法をそのまま適用することは難しいため、予備実験として、ひとまず従来のSkip-gramを学習させたうえで、何か改善できる点がないかを調べました。

予備実験

従来のSkip-gramを用いて単語ベクトルの獲得を行い、シノニムを与えたときのk近傍を観察してみます。

実験設定

学習に用いたデータセットとしては、Webからクロールした記事250,000件を使用しました。 このデータセットに含まれる単語数は533,999単語(のべ123,273,881語)です。

Skip-gramの学習に関する主要なハイパーパラメータとしては、窓幅を5単語、学習する単語ベクトルの次元を100次元としました。 また、ある単語の出現回数が全データセット中で5回より少ない場合には、その単語を学習から除外しました。 したがって最終的には、172,257単語(のべ93,799,316語)の単語を用いて学習を行いました。

実験結果

次の表は、学習済みモデルを用いて、アニメ作品のシノニムの単語ベクトルとコサイン類似度の高いベクトルを持つ5単語をそれぞれ列挙したものです。

表1 従来のSkip-gramを用いたときの、シノニムの単語ベクトルとコサイン類似度の近いベクトルを持つ上位5単語
ごちうさ
(ご注文はうさぎですか?)
リゼロ
(Re:ゼロから始める異世界生活)
このすば
(この素晴らしい世界に祝福を!)
けもフレ
(けものフレンズ)
よう実
(ようこそ実力至上主義の教室へ)
#1 リゼロ 0.71542 ごちうさ 0.71542 幼女戦記 0.67590 二次創作 0.58515 プリアラ 0.71460
#2 きんモザ 0.70086 ガーリッシュナンバー 0.69933 はいふり 0.65225 エンドレスエイト 0.57156 クロムクロ 0.66699
#3 まどマギ 0.67969 緋弾のアリア AA 0.66972 ハルチカ 0.63882 シュタゲ 0.55419 ガーリッシュナンバー 0.63846
#4 ラブライブ 0.67866 ワンパンマン 0.66917 リゼロ 0.63733 グレンラガン 0.54987 えとたま 0.61215
#5 アイマス 0.67314 幼女戦記 0.66810 暗殺教室 0.63500 ラブライブ 0.54697 正解するカド 0.60950

それ以外の単語で試した場合でも、上の表と同様にして、アニメタイトルを表す単語を与えた場合には、何らかのアニメタイトルを表す単語がk近傍に存在するという結果になりました。

しかし「ごちうさ」から「ご注文はうさぎですか?」、「リゼロ」から「Re:ゼロから始める異世界生活」が捉えられないことから、同一の作品を表すアニメタイトルの距離が近くなるように学習できていないことが分かります。 言い換えると、従来のSkip-gramでは、アニメタイトル同士は正しく距離が近くなるように学習されるものの、それ以上の特徴は捉えられていないということが分かります。 (この結論は、一度でもword2vecを使ったことのある方なら、頷いていただけると思います。)

したがって、今回のタスクを解決するには、従来のSkip-gramでは難しいという結論になりました。

予備実験に関する考察

先ほどの表1をご覧ください。 従来手法では「ごちうさ」に類似したベクトルを持つ単語として「リゼロ」が、また「リゼロ」に類似したベクトルを持つ単語として「ごちうさ」がそれぞれ出現しています。 これは、学習の結果で得られた100次元のベクトル表現において「ごちうさ」と「リゼロ」がお互いに近い位置に存在するということを意味しています。 では、なぜ「ごちうさ」と「リゼロ」が近くなるのでしょうか。 以降ではこの問題を、ごちうさ-リゼロ状態として呼ぶことにしましょう。

ごちうさ-リゼロ状態はなぜ起こるのか

図2 「ごちうさ」(左)「リゼロ」(右)という単語の周辺5単語に出現する単語を、頻度の高い順にソートした結果
▲図2 「ごちうさ」(左)「リゼロ」(右)という単語の周辺5単語に出現する単語を、頻度の高い順にソートした結果

図2をご覧ください。 この表は、それぞれ「ごちうさ」「リゼロ」という単語の周辺5単語に出現する単語を、頻度を高い順にソートしたものです。

ところで、皆さんは、この表にあるような周辺単語の分布から「ごちうさ」「リゼロ」という作品名まで言い当てることができますか? (実際にアニメ作品名を知らせない状態で、作品の正式名称を除いた分布を与えて作品名を推測してもらったところ、あくまで主観ですが、半数程度の人が異なる作品名を答えていました。) 確かに作品を表すような特徴を持つような単語を含んでいるものの、基本的に確信を持って言えることは「アニメ作品」(もしくはサブカル全般)ということ程度かと思います。 Skip-gramを含むWord2vecは、基本的にこのようなタスクを解くことを目標にして、単語ベクトルを学習しているのです。

さて、図2をよく観察すると、次のことが言えます。

  1. 「店舗限定」や「コラボ」などの、今回のタスクにおいてはノイズとなりそうな単語が上位に来ている
  2. 「アニメ」「キャラ」「イベント」などのアニメ全般で使われる単語が上位に来ている

この2点を手掛かりに解決策を探していきます。

まず一つ考えられる要因としては、複数作品に関して言及している記事が学習に含まれているという点です。 図3は、クロールされた記事に、アニメ/サブカルに関するタグ/キーワード集合(タスク設定の章で説明)を用いて付与されたキーワードの数に関するヒストグラムです。

クロールされた記事に付与されたキーワードの数
▲図3 クロールされた記事に付与されたキーワードの数

キーワードを多く含むような記事としては、どのようなものがあるのでしょうか? 実際にデータセットを確認してみると、コミックマーケットをはじめとしたイベントにおける出展情報に関する記事が多く含まれていることがわかりました。 「リゼロ」や「ごちうさ」のような人気作品はグッズも多く取り上げられることから、出展情報に関する多数のウェブページに出現しており、これが、ごちうさ-リゼロ状態の一つの要因になっているのではないかと考えました。

また二つ目に考えられる要因として、単語ベクトルの学習に周辺単語を使うだけでは、今回のタスクを解くには不十分であるという点です。 周辺単語を見ると、アニメ全般で用いられるような単語が多く出現していることがわかります。 これらの単語はWord2vecの学習において、一般名詞のなかからアニメ全般に関する概念を獲得する(アニメに関する単語の距離が近くなるように学習する) には重要ですが、今回のような、もう少し詳細にアニメ作品を考慮した単語ベクトルを獲得したい場合には、これらの アニメ全般用語は、いわばストップワードと同じ扱いになると言っても良いでしょう。

次の章では、アニメ作品に関するドメインの知識を考慮するような仕組みを組み込んだモデルを提案します。

提案手法

前述の要因二つについて、まず一つ目の解決策としては、前処理として1記事にキーワードを10個以上含む記事については除外を行いました。 これにより、なるべく1つの作品について言及しているようなWeb記事からのみ学習を行うようにするという狙いがあります。

二つ目に解決策ですが、学習モデルにこのキーワード情報をうまく埋め込むことで、アニメ作品に関するドメインの知識も単語ベクトルに埋め込むことができないかを検討しました。 そこで考えたのが、以下の3つのモデルです。

モデル1号

モデル1号
▲図4 モデル1号

モデル1号は、ある単語を入力としたときに、その周辺単語とドキュメントに付与されたキーワードを出力として学習を行うモデルです。 つまり、通常のSkip-gramモデルに加えて、キーワード情報を推測するような層を途中に付け足して、マルチタスク学習を行っています。

モデル2号

モデル2号
▲図5 モデル2号

モデル2号は、ある単語と、その単語が出現するドキュメントに付与されたキーワード情報を入力としたときに、その単語の周辺単語を学習するモデルです。 これが学習できると、単語だけではなく、あるキーワードが出現するドキュメントにおいては、特定の単語が周辺に出現しやすいという、条件付きの周辺単語の推測もできるようになります。 また、単語ベクトルの学習と同時に、キーワード情報に関するベクトルも学習できる点も魅力的です。

モデル3号

※こちらのモデルは、インターン期間終了後に追加実験として試したモデルです。

Rev. A

モデル3号 Rev.A
▲図6 モデル3号 Rev.A

モデル3号 Rev.Aは、基本的にはモデル2号と同じです。 しかし、モデル2号では1つのドキュメントに複数のキーワードが付与されていた場合に、そのSumを取って入力としていたところを、このモデルでは1つずつ入力として取るようにした点が異なります。 このように変更することで、モデル2号と比較して全体のモデル構成が浅くなり、学習が進みやすいのではないかと考えたためです。

Rev. B

モデル3号 Rev.B
▲図7 モデル3号 Rev.B

モデル3号 Rev.Bは、Rev.Aに加えて、concatの後に1層のFully Connected層を挟んでいます。 これにより、例えば入力として与えられたキーワード情報が周辺単語の推測に役に立たないような場合でも、学習が可能になるのではないかと考えました。

Rev. C

model3c.pngのサムネール画像
▲図8 モデル3号 Rev.C

モデル3号 Rev.Cは、Rev.Bに加えて、ResNet(He+, 2016,[f])で用いられているようなShortcut Connectionを加えました。 これにより、仮にキーワード情報を用いた場合のほうが性能が悪くなるような場合でも、最悪時の性能を通常のSkip-gramと同等くらいに保証できるのではないかと考えました。

キーワードのみSkip-gram

図9 キーワードのみSkip-gram
▲図9 キーワードのみSkip-gram

これは、モデル1号において、周辺単語への出力層を無くしたものと一致します。 すなわち、マルチタスク学習の有効性を検証するために実験に用いたモデルです。

キーワードのみSkip-gramは、基本的にモデル構成はSkip-gramと同様ですが、ある単語を入力としたときに周辺単語を学習するのではなく、ある単語が出現するドキュメントのキーワード情報を学習している点が異なります。

評価実験

従来のSkip-gram、キーワードのみモデル、モデル1号~3号 Rev.Cまでをすべて実装し、評価実験を行いました。 なお、すべてのモデルはChainerを用いて実装しました。

実装は後日公開予定です。

評価手法

現在ハッカドールが持っているシノニムペア5600組を用いてモデルの評価を行うために、次の3つの評価手法を用いました。

  • コサイン類似度
  • K近傍一致度
  • 相互ランク

コサイン類似度

コサイン類似度は、単純にシノニムペアがどれくらい近くなっているかを測定するための指標として取り入れました。

シノニムペアを$x, y$としたときに、コサイン類似度$cos(x,y)$は次のように定義されます。

$$\text{cos}(x,y) = \frac{\sum_{i=0}^d{w_{x_{i}} w_{y_{i}}}}{\sqrt{\sum_{i=0}^d{w_{x_{i}}^2}} \sqrt{\sum_{i=0}^d{w_{y_{i}}^2}}}$$

ここで、$w_{x}$は単語$x$の単語ベクトル、$d$は単語ベクトルの次元を示しています。

k近傍一致度

k近傍一致度は、シノニムペアとなる2単語の周辺に存在する単語がどれくらい一致しているかを測定することを目的として取り入れました。

シノニムペアを$x, y$としたときに、単語$x$(単語$y$)に対するコサイン類似度が高い上位$k$単語を集めた集合を$S_{x}$($S_{y}$)とします。 すなわち、すべての単語集合を$S$としたときに、$S_{x}$($S_{y}$)は次の2式を満たすように定義されます。

$$|S_{x}| = k$$ $$ \forall p \in S \setminus S_{x}.~\forall q \in S_{x}.~\text{cos}(x, p) \le \text{cos}(x, q)$$

このとき、k近傍一致度$\text{Jaccard}_{k}(S_{x}, S_{y})$は次のように定義されます。

$$\text{Jaccard}_{k}(S_{x}, S_{y}) = \frac{\sum_{w \in S_{x} \cup S_{y}}{\text{min}(\text{cos}(x, w), \text{cos}(y, w))}}{\sum_{w \in S_{x} \cup S_{y}}{\text{max}(\text{cos}(x, w), \text{cos}(y, w))}}$$

つまり、単語$x$と$y$のk近傍が、どれくらい一致しているかを重み付きのJaccard係数を用いて計算しています。

相互ランク

相互ランクは、単語$x$と単語$y$がどれくらい相互に近くなっているかを測定するための指標として導入しました。

単語$x$について、すべての単語とコサイン類似度を計算し、値の高い順にソートしたリストにおいて単語$y$が出現する順位を$d_{x\rightarrow y}$とします。 また単語$y$について、すべての単語とコサイン類似度を計算し、値の高い順にソートしたリストにおいて単語$x$が出現する順位を$d_{y\rightarrow x}$とします。

このとき、相互ランク$\text{rank}(x, y)$は次のように定義されます。

$$\text{rank}(x, y) = \frac{d_{x\rightarrow y} + d_{y\rightarrow x}}{2}$$

つまり、この値は単語$x$の類似単語を検索したときの単語$y$の順位と、単語$y$の類似単語を検索したときの単語$x$の順位の平均を示しており、この値が小さければ小さいほど良いモデルであると判断できます。

実験設定

学習に用いたデータセットとしては、Webからクロールした記事集合のなかで、1記事にキーワードを10個以上含まない記事集合から100,000件を使用しました。 このデータセットに含まれる単語数は331,138単語(のべ49,187,387語)、キーワード数は47,751です。

Skip-gramの学習に関する主要なハイパーパラメータとしては、窓幅を5単語、学習する単語ベクトルの次元を100次元としました。 また、ある単語の出現回数が全データセット中で5回より少ない場合には、その単語を学習から除外しました。 したがって、最終的には、114,045単語(のべ37,128,122語)の単語を用いて学習を行いました。

同様にして、頻度が5回以下のキーワードについても除外しました。 除外した結果、キーワードを含まなくなった記事については、特殊なキーワード(None)を与えました。 したがって、最終的には、キーワード数は11,824となりました。

また、k近傍一致度で用いた$k$の値は20としました。 スコアには、シノニムペア5600組に対してそれぞれの評価手法を適用したときの値の平均を採用しました。 ただし考察で述べる理由から、相互ランクにおいてのみ、中央値の算出も行いました。

実験結果

表2 モデルの評価結果
モデル コサイン類似度 K近傍一致度 相互ランク(平均値) 相互ランク(中央値)
従来のSkip-gram 0.4041 0.0660 9523.5263 892.0
キーワードのみモデル 0.5063 0.1918 5745.6675 22.5
1号 0.5293 0.1923 4926.6754 19.0
2号 0.3706 0.0532 14301.6743 2599.0
3号 Rev.A 0.3348 0.0544 12626.5088 1696.0
3号 Rev.B 0.3599 0.0616 11804.2098 1296.5
3号 Rev.C 0.3585 0.0619 12003.0603 1292.0

実験結果から、従来のSkip-gramと比較すると、提案したモデル1号の性能は大幅に向上していることがわかります。 では実際に、どのような出力がでるようになったかを実際に試してみましょう。

表3 モデル1号を用いたときの、シノニムの単語ベクトルとコサイン類似度の近いベクトルを持つ上位5単語
ごちうさ
(ご注文はうさぎですか?)
リゼロ
(Re:ゼロから始める異世界生活)
このすば
(この素晴らしい世界に祝福を!)
けもフレ
(けものフレンズ)
よう実
(ようこそ実力至上主義の教室へ)
#1 ご注文はうさぎですか? 0.87631 Re:ゼロから始める異世界生活 0.78200 めぐみん 0.84121 たつき監督 0.73934 ようこそ実力至上主義の教室へ 0.70415
#2 ご注文はうさぎですか?? 0.85684 長月達平 0.67824 ダクネス 0.79038 けものフレンズ 0.73272 zitsu 0.57993
#3 チノ 0.82150 エミリア 0.67667 この素晴らしい世界に祝福を! 0.77038 サーバルちゃん 0.72079 軽井沢 0.56846
#4 シャロ 0.75929 レム 0.67260 駄女神 0.75584 アライさん 0.69193 清隆 0.55031
#5 千夜 0.74842 MJ文庫J 0.64899 カズマ 0.74682 ドッタンバッタン 0.66814 綾小路 0.54770

表1と比較すると、既存手法に比べて、取りたかったものがだいぶ取れていることが分かります。ほかの例も試してみましょう。

図10 従来手法(Skip-gram)と提案手法(モデル1号)の比較
▲図10 従来手法(Skip-gram)と提案手法(モデル1号)の比較

図10の例では、様々な単語を既存手法と提案手法(モデル1号)に与えたときの類似5単語を示しています。 この例から、例えば「すかすか」→「週末なにしてますか?忙しいですか?救ってもらっていいですか?」といった既存手法では獲得するのが難しいと思われていたシノニムも正しく獲得できていることがわかります。 また「ほたるん」(のんのんびよりのキャラクターの愛称)を与えた場合に、既存手法ではキャラクターの語尾や一般名詞などが混在し、正しく距離を計算できていない結果となってしまっていますが、提案手法では 同作品のキャラクターの愛称が近くなるようなベクトルが得られていることにも注目です。 さらに「お仕事シリーズ」や「マスター」といった単語を与えた場合にも、ユーザーが想定しているであろう作品関連の単語が近くなるように学習されており、従来手法と比較すると、提案手法ではアニメタイトルやキャラクター同士が近くなるのはもちろん、作品なども考慮して距離が計算されるように制約がかかっているように見えます。

考察

相互ランクの値が大きいシノニムペアの特徴

はじめに、モデル1号について、実際にモデルに単語を与えたときの印象と比べて、評価データでの相互ランクの平均値が大きい(順位が低い)ことに注目しました。 そこで、モデル1号の相互ランクのヒストグラムを求めた結果、次の図のようになりました。

図11 モデル1号の相互ランクに関するヒストグラム
▲図11 モデル1号の相互ランクに関するヒストグラム

図11から、一部の相互ランクの値が大きいシノニムペアに影響されて、平均値も大きくなっていることが推測できます。 これが、実験において相互ランクの中央値を求めた理由です。

では、モデル1号ではどのようなシノニムペアが相互ランクの値が大きくなっているのか(すなわち、正しく取れなかったのか)を考察してみます。 評価データとして用いたシノニムペア 5600組のうち、モデル1号で相互ランクの値が大きかった(順位が低かった)シノニムペアを観察した結果、大きく分けて次の5種類に分類されると考えました。

  • 表記ゆれによる単語の重複
  • 評価データセットに古いデータが含まれている
  • 評価データセットに一般名詞が含まれている
  • 評価データセットにセリフ・その他が含まれている
  • 同じ単語で複数の意味を持つ単語が存在

1番目の項目は、例えば「ニコ生」と「にこなま」のような単語です。 Web記事において出現する単語の数は、前者のほうが圧倒的に多く、後者が出現することはまれです。 つまり、前者は正しく学習することができますが、後者は正しく学習することが難しくなります。 このため、評価データに含まれる「にこなま」などの表記ゆれがある単語とのシノニムペアは、距離が離れてしまうと考えました。

2番目の項目は、例えば(「ワールドイズマイン」,「ワイズマ」)のようなシノニムペアが評価データに含まれているケースです。 今回の学習に用いたデータセットは、2014年3月~2017年9月の期間に公開された記事で構成されており、その期間より古いものや新しいもので出現するような単語については、正しく学習することが難しいという理由が考えられます。

3番目の項目は、例えば(「コメント」,「comment」)のようなシノニムペアが評価データに含まれているケースです。 今回の学習には、主にサブカル関係のWeb記事をデータセットとして用いており、マルチタスク学習にもアニメ作品関連のキーワードを利用しています。 そのため、一般名詞に関する順位は低いままでもおかしくないと考えました。

4番目の項目は、例えば(「イチロー」,「打ってみた」)のようなシノニムペアが評価データに含まれているケースです。 これらは主にニコニコ動画などのサービスで、動画のタグ機能として用いられているのをよく見かけますが、2番目の理由と同様にして今回の学習で獲得するのは難しいと考えました。

5番目の項目は、例えば「私モテ」や「とある」のような単語です。 例えば、前者の「私モテ」は「私がモテないのはどう考えてもお前らが悪い!」(2013年7月アニメ化)と「私がモテてどうすんだ」(2016年10月アニメ化)の2作品の愛称として知られています。 実際にGoogleで検索した場合にも、両方の作品が表示されていることがわかります。 後者の「とある」は、アニメ分野においては「とある魔術の禁書目録」「とある科学の超電磁砲」の2作品を指し、さらに一般的には連体詞として用いられています。

このような場合には、複数のコンテキストで同一の単語が出現することになり、正しく学習することが困難になります。 実は、このような曖昧性解消問題はアニメ関連においても深刻な問題となりつつあり、上記の作品名以外にも、例えば「凛」という名前が指すキャラクターが多い(有名なところでは「星空凛」「松岡凛」「遠坂凛」「渋谷凛」など)という問題があります。 このアニメドメインにおける曖昧性解消問題を凛状態と呼ぶことにしましょう。

凛状態の解決に向けて

では凛状態を解決するにはどうすれば良いでしょうか。

「どの凛を指しているかはキーワードと周辺文脈から区別できる」という仮定を置くと、次のナイーブなアルゴリズムを考えることができます。

  1. キーワードごとに異なる「凛」となるように区別
  2. 提案モデルを学習
  3. 1エポックごとに「凛」間の距離を測り、一定閾値以下であればマージ
  4. 2.へ戻る

図12 凛状態解決に向けたアルゴリズム
▲図12 凛状態解決に向けたアルゴリズム

3週間のうちに実際に実験することはできませんでしたが、上記のアルゴリズムを組み込むことで、適切にコンテキストの異なる同一単語を分離することができるのではないかと考えています。

モデル2号・3号の単語ベクトルのスコアが低い理由

従来のモデルとモデル2号・3号は、出力として周辺単語を予測するように学習を行っており、スコアの高いキーワードのみモデルとモデル1号は、出力としてキーワード情報を予測するように学習を行っています。 このことからも、評価実験でのスコアに大きく貢献したのは、キーワード情報からのロスであると考えることができます。

ところで、モデル2号と3号もキーワード情報をモデルの入力として用いています。 この入力は、本当に無意味だったのでしょうか?

評価実験では単語ベクトル$W_e$のみを評価していたためスコアとしては現れていませんが、実はキーワードベクトル$W_e$にも面白い特徴が得られていました。 モデル3号 Rev.Bの学習を通して得られた$W_d$に表1,3と類似したキーワードを与えると次の結果が得られました。

表4 モデル3号 Rev.Bを用いたときの、キーワードの単語ベクトルとコサイン類似度の近いベクトルを持つ上位5キーワード
ご注文はうさぎですか? Re:ゼロから始める異世界生活 この素晴らしい世界に祝福を! けものフレンズ ようこそ実力至上主義の教室へ
#1 ココア 0.68947 レム 0.78615 めぐみん 0.83319 サーバル 0.82906 よう実 0.69769
#2 シャロ 0.67518 エミリア 0.69870 ダクネス 0.73124 サーバルちゃん 0.77726 セントールの悩み 0.55141
#3 ティッピー 0.56429 長月達平 0.66962 駄女神 0.61180 ジャパリパーク 0.72899 恋と嘘 0.54268
#4 きんいろモザイク 0.51485 スバル 0.3048 ダークホース 0.60308 けもフレ 0.72134 紗霧 0.53223
#5 のんのんびより 0.51027 鬱展開 0.56276 角川スニーカー文庫 0.56557 かばんちゃん 0.71177 夏アニメ 0.48676

これもこれで面白い結果が出ていますね。 例えば「ご注文はうさぎですか?」に類似したキーワードとして「きんいろモザイク」や「のんのんびより」が出現している点や、「Re:ゼロから始める異世界生活」に「鬱展開」というキーワードが出現している点、さらには「ようこそ実力至上主義の教室へ」に類似したキーワードとして同時期に放送されたアニメなどが多数含まれている点など、何らかの知識が埋め込まれていると考えて良さそうです。

この結果から、モデル2号や3号においてモデルの学習に役立つアニメドメインに関する知識はキーワード情報からの入力を直接受け取る$W_d$が獲得しやすいため、$W_e$ではドメインに特化しない一般的な単語ベクトルの獲得が行われた、すなわち$W_e$にアニメドメインに関する知識の埋め込みが行われなかったのではないかと考えることができます。

これを踏まえると「なぜ1号のようにマルチタスク学習を行わなかったのか?」と疑問に思われる方も多いと思います。 実は今回の記事を執筆するにあたって間に合わなかったという理由もあるため、この実験は今後のタスクの1つでもありますが、実験を通して以下の2つの問題も出てくるのではないかと考えています。

  • 入力と出力に同じデータが来るため、正しく学習されない可能性もある
  • (他のモデルと比較して)学習時間が大幅に増加する
    • 入力と出力のキーワード情報の組み合わせが二乗個になるため

モデルファイルとデモサイト

今回の取り組みで得られた単語ベクトルがどのようなものかを、実際に試せるデモサイトを次のURLで公開しました。

このウェブサイトでは、上部に単語を入力しEnterキーを押すことで、各モデルにおける類似度が高い単語(入力された単語のベクトルとコサイン類似度が高いベクトルを持つ単語)を検索することができます。 利用できるモデルは次の通りです。

  • Original Raw (250k, 100dim) : 従来のSkip-gram(250,000件のWeb記事を元に学習)
  • Original (100k, 100dim) : 従来のSkip-gram (100,000件の前処理済みWeb記事を元に学習)
  • Keyword Only (100k, 100dim) : キーワードのみモデル (100,000件の前処理済みWeb記事を元に学習)
  • Model 1 (100k, 100dim/Best) : モデル1号(100,000件の前処理済みWeb記事を元に学習。提案モデルのなかで最も精度が高い。)
  • Model 1 Large (1M, 300dim/Best) : モデル1号(1,000,000件の前処理済みWeb記事を元に学習。提案モデルのなかで最も精度が高い。)
  • Model 2 (100k, 100dim) : モデル2号 (100,000件の前処理済みWeb記事を元に学習)
  • Model 3 Rev.A (100k, 100dim) : モデル3号 Rev.A (モデル2号と同様)
  • Model 3 Rev.B (100k, 100dim) : モデル3号 Rev.B (モデル2号と同様)
  • Model 3 Rev.C (100k, 100dim) : モデル3号 Rev.C (モデル2号と同様)

また、学習済みの単語ベクトルも配布しますので、手元に環境がある方はこちらでも試してみてください。

なお、配布形式には次の3種類あります。

  • tsv : 単語にスペースを含めることを許容するために、独自のフォーマットとなっています。単語と値の間がタブ区切りになっています。値はスペース区切りとなっています。
  • Google-txt : Googleが公開したword2vec実装の出力形式(テキスト形式)に準拠しています。 そのため、既存のword2vec実装で読み込むことができます。(単語と値の間がスペース区切りとなっています。そのため単語にスペースが含まれる場合(1つのエントリが複数語からなる場合)には、アンダーバー_ で置換されています。)
  • Google-bin : Googleが公開したword2vec実装の出力形式(バイナリ形式)に準拠しています。 Google-txtと同様の処理が行われています。

まとめ

今回の3週間のインターンでは、アニメやサブカルに関連したシノニムの自動獲得タスクに取り組みました。 1週間目では、同義語獲得に関する先行研究の調査を行い、主な既存手法の要点を整理しました。 2週間目では、予備実験として、Skip-gramモデルを用いて現状のデータセットから単語ベクトルを学習し、得られた単語ベクトルから現状のタスクに適用する場合の問題点(ごちうさ-リゼロ状態)を調査しました。 また、予備実験で明らかになった問題点から、改善するための仕組みを取り入れたモデルを提案・実装し、評価実験を行いました。 評価実験の結果、提案モデルはアニメ作品に関する知識も同時に埋め込んだ単語ベクトルを獲得できることが明らかになり、従来のモデルよりも高い精度で今回のタスクを解くことが可能となりました。 3週間目では、これらの実験モデルに関する考察とデモの作成を行いました。 考察を通して、特に複数のコンテキストを持つ同一単語の単語ベクトルを学習することが困難である(凛状態)ことがわかり、アニメドメインにおける曖昧性解消の必要性について言及しました。

今回の提案手法によって得られた単語ベクトルの応用先の例として、ハッカドール内における検索システムで用いる同義語辞書などが挙げられます。 その理由として、例えばユーザーが「ごちうさ グッズ」のようなクエリで検索した場合に「(ごちうさ OR ご注文はうさぎですか? OR チノ OR ココア OR ...) AND (グッズ OR トートバッグ OR ...)」のように展開されたクエリで検索を行うほうが嬉しい場合もあるからです。

また、今回はキーワード情報としてアニメ関連の単語を使用しましたが、異なるドメインと関連した単語をキーワード情報として用いることで、別のドメインに関する知識を単語ベクトルに埋め込むことができると考えています。 例えば、料理やお店に関する情報をキーワードとして持っておき、これらの単語を文章のキーワード情報として与えることで、幅広い分野に本提案モデルを適用できるでしょう。

今後のタスクとしては、凛状態の解決とモデル2号・3号の性能改善などが挙げられます。

最後に、インターン開始前から業務内容をはじめ様々な点でお世話になりました、メンターの鴨志田さん、人事の戸上さん、山本さんに感謝いたします。 土田さん、濱田さんには特に研究を進めるうえで有益なアドバイスをいただきました。ありがとうございます。 本タスクに関して一緒にディスカッションしてくださった鈴木政隆さん、内田さんにも感謝いたします。

そして、今回のインターンを無事に終えるにあたって、さまざまな場所で支えてくださった、AIシステム部とハッカドールチームの皆様に、心から感謝いたします。

参考文献

[a] 高橋いづみ, et al. "単語正規化による固有表現の同義性判定." 言語処理学会第 14 回年次大会発表論文集 (2008): 821-824.http://www.anlp.jp/proceedings/annual_meeting/2008/pdf_dir/D4-5.pdf
[b] Mikolov, Tomas, et al. "Distributed representations of words and phrases and their compositionality." Advances in neural information processing systems. 2013. http://papers.nips.cc/paper/5021-distributed-representations-of-words-and-phrases-and-their-compositionality
[c] 城光英彰, 松田源立, and 山口和紀. "文脈限定 Skip-gram による同義語獲得." 自然言語処理 24.2 (2017): 187-204. https://www.jstage.jst.go.jp/article/jnlp/24/2/24_187/_article/-char/ja/
[d] Chakrabarti, Kaushik, et al. "A framework for robust discovery of entity synonyms." Proceedings of the 18th ACM SIGKDD international conference on Knowledge discovery and data mining. ACM, 2012. https://www.microsoft.com/en-us/research/wp-content/uploads/2012/01/idg811-cheng.pdf
[e] Cheng, Tao, Hady W. Lauw, and Stelios Paparizos. "Fuzzy matching of web queries to structured data." Data Engineering (ICDE), 2010 IEEE 26th International Conference on. IEEE, 2010.
[f] He, Kaiming, et al. "Deep residual learning for image recognition." Proceedings of the IEEE conference on computer vision and pattern recognition. 2016. https://www.cv-foundation.org/openaccess/content_cvpr_2016/html/He_Deep_Residual_Learning_CVPR_2016_paper.html

続きを読む
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

chainercvを用いたMask R-CNNの実装

はじめに

皆さんこんにちは。DeNAのAI研究開発エンジニアの本多です。DeNAからは初日のRealtime Multi-Person Pose Estimationにつづき2回目のChainer Advent Calendar への投稿となります。私は2017年よりDeNA AIシステム部にジョインし、以来コンピュータビジョンの研究開発に従事しております。 12/16に行われた第43会CV勉強会@関東にてICCV 2017現地レポートをさせていただいたこともあり、同学会でBest Paper Awardを獲得した'Mask R-CNN' [1]を、chainercvをベースに実装してみることにしました。

rcnn_1.png

図1 実装したMask R-CNNによる推論結果

背景

Mask R-CNNは、一つのネットワーク・モデルで、以下のような複数の情報を取得することのできるマルチタスク検出器です。

  • 画像中の物体位置と大きさ (bounding box)
  • 物体のカテゴリ (人なのか、ソファなのか)
  • 物体のセグメンテーション (画素レベルでの物体位置)
  • 人の体パーツ位置 (頭・肩・足など)

一枚の画像の各ピクセルをクラス分類するsemantic segmentationと異なり、本手法でのセグメンテーションは、オブジェクト毎の個別segmentationであることから、instance segmentationと呼ばれます。 例えば図1ですと、左の人と右の人は別のオブジェクトとしてsegmentationされています。ポーズ推定でも同様で、複数の人が別のオブジェクトとして認識されつつ、それぞれの体パーツの推定がおこなわれます。

このように、Mask-RCNNでは、画像内の物体領域を求め、それぞれの物体について個別に、詳細な情報を推論していくことができます。 今回は、chainercvのexampleに含まれており、Mask R-CNNの前身であるFaster R-CNNをベースに、簡単な変更だけでMask R-CNNの機能を実装していきます。

ネットワークの構成

Mask R-CNNのネットワークは、Extractorと呼ばれる特徴抽出器と、物体の候補領域をピックアップするRegion Proposal Network、そして各タスクに対応するheadと呼ばれる子ネットワークから構成されます。

①class and box head
②mask head

①はFaster R-CNNに含まれており、ピックアップした候補領域を1次元ベクトルに変換したのち、全結合ネットワークによりクラス分類、及び物体の境界であるbounding boxの位置を出力します。今回追加するのは②、すなわちセグメンテーションマスクを推定するためのheadネットワークのみです。

rcnn_2.png

図2 Mask R-CNNのネットワーク構成 [1] (K. He et al., 2017)

データセットの読み込み

学習にはCOCO dataset 2017のtrainを用います。 COCO datasetは、80のオブジェクト分類及び位置、セグメンテーションマスク、人に関しては体パーツ位置など、多くのアノテーションが付与されたデータセットで、13万枚程度の学習用画像が含まれます。データセットをサンプルする関数であるget_exampleが返すのは、画像と、bounding boxラベル、そして上記 セグメンテーションマスク の4つとなります。

ここでは、セグメンテーションマスクの読み込みについて説明します。 マスク情報は、ポリゴン座標のリストという形でアノテーションデータに含まれています。ある画像に対するセグメンテーション情報をseg_polygonsに読み込んだのち、

mask_in = np.zeros((int(h), int(w)), dtype=np.uint8)
for annot_seg_polygon in annot_seg_polygons:
       N = len(annot_seg_polygon)
       rr, cc =    polygon(np.array(annot_seg_polygon[1:N:2]),
                   np.array(annot_seg_polygon[0:N:2]))
       mask_in[np.clip(rr,0,h-1), np.clip(cc,0,w-1)] = 1

のようにして、ポリゴンをセグメンテーションマスクに変換しながらmask_inに格納していきます。ここで、マスクはバイナリで、'1'が物体のある場所を表します。ここでh,wは画像のサイズと同じです。

モデルの実装

実装は、chainercvのexamplesに含まれているfaster_rcnnをベースに行っていきます。

1.ExtractorとRegion Proposal Network

まず入力画像からfeature map (特徴マップ)を抽出します。

features = self.mask_rcnn.extractor(imgs)

ここでextractor(抽出器)は、mask_rcnnクラス内で

extractor = VGG16(initialW=vgg_initialW)

のように定義されています。今回はchainercvのFaster-RCNNに倣い、VGG16の5回目のmax poolingの直前までをextractorとして使用します。他にResNet等を使用することもできます。抽出されたfeature mapのサイズは元画像の1/16になります。

次にRegion Proposal Networkを適用し、物体の存在する領域(Region of Interest, ROI)を抽出します。chainercvのregion_proposal_network.pyを変更なく用いています。

2.教師マスクデータ

次に抽出されたROIに対し、ground truth (教師データ)を設定します。 chainercvのproposal_target_creator.pyでは、抽出されたROIそれぞれとオーバーラップの大きいground truthオブジェクトを見つけ、gt_assignmentというインデックスで関連づけています。これを利用して、マスクデータの読み込みを追加します。

gt_roi_mask=[]
for i , idx in enumerate(gt_assignment[pos_index]):
    A=mask[idx, np.max((int(sample_roi[i,0]),0)):np.min((int(sample_roi[i,2]),h)),        
          np.max((int(sample_roi[i,1]),0)):np.min((int(sample_roi[i,3]),w))]
    gt_roi_mask.append(cv2.resize(A, (masksize,masksize)))

ground truthマスクは、図3のように、positiveとなったROIに相当する領域sample_roiで切り出されます。ここでROIの大きさはそれぞれ異なるのですが、正解データは全て(masksize,masksize)に固定します。masksizeは例えば14です。

rcnn_3.png

図3 ground truthマスクの切り出し

ROIの切り出し方法については、本論文では新しく導入されたROI alignという手法により精度良く切り出しを行っています。本稿では簡単のため、Faster R-CNNで用いられており、chainerにも実装されているROI poolingを用います。ROI alignとROI poolingの違いについては、[2]をご参照ください。

3.Headネットワーク

ROI poolingで切り出されたfeature mapのサイズは、128(候補数) x 512 (channel数) x 7 x 7 (ROI大きさ)となっています。これを、各head networkに入力していきます。

ネットワーク定義は

  • class and box head (Faster R-CNNと同じ)
#Faster-RCNN branch
self.fc6 = L.Linear(512*roi_size*roi_size, 4096, initialW=vgg_initialW)
self.fc7 = L.Linear(4096, 4096, initialW=vgg_initialW)
self.cls_loc = L.Linear(4096, n_class * 4, initialW=vgg_initialW)
self.score = L.Linear(4096, n_class, initialW=score_initialW)
  • mask head (今回追加。サイズは7 x 7 から 14 x 14 に拡大される)
#Mask-RCNN branch
self.convm1_1 = L.Convolution2D(512,512,3,1,pad=1, initialW=None)
self.convm1_2 = L.Convolution2D(512,512,3,1,pad=1, initialW=None)
self.deconvm1 = L.Deconvolution2D(512, 256, 2, 2, initialW=None)
self.convm2_1 = L.Convolution2D(256, 256, 3, 1, pad=1,initialW=None)
self.convm2_2 = L.Convolution2D(256, n_class, 3, 1, pad=1,initialW=None)

ネットワークのforward実行は

  • class and box head
      fc6 = F.relu(self.fc6(pool)) 
      fc7 = F.relu(self.fc7(fc6))
      roi_cls_locs = self.cls_loc(fc7) 
      roi_scores = self.score(fc7)
  • mask head
       h = F.relu(self.convm1_1(pool))
       h = F.relu(self.convm1_2(h))
       h = F.relu(self.deconvm1(h)) 
       h = F.relu(self.convm2_1(h))
       masks=self.convm2_2(h)

のように行います。

4.損失関数

mask headのLoss(損失)計算のため、mask headの出力であるroi_cls_mask : 128(候補数) x 81(クラス) x 14 x 14 (マスク大きさ)から、対象ROIに存在する正解ラベルに該当するroi_mask :128(候補数) x 14 x 14(マスク大きさ) を抽出します。

roi_mask = roi_cls_mask[self.xp.arange(n_sample), gt_roi_label]

そして、同じく候補領域のground truth maskであるgt_roi_maskと比較し、損失を求めます。

mask_loss = F.sigmoid_cross_entropy(roi_mask[0:gt_roi_mask.shape[0]], gt_roi_mask)

ここでground truthは0 or 1 のバイナリで、ネットワーク出力は正負の値を持つfloat値です。損失関数としては、sigmoid cross entropyを用います。 これでmask lossが定義できました。Faster R-CNNのlossに、mask_lossを加えてできあがりです。論文で記載されているloss式に倣い、各lossの重み付けは行っていません。

loss = rpn_loc_loss + rpn_cls_loss + roi_loc_loss + roi_cls_loss + mask_loss

学習

さて、いよいよ学習です。COCO datasetは大きいので、epochでなくiterationで管理します。図4のように、およそ40万iteration (それでも3 epoch!)程度でlossの値が安定します。train lossの内訳を見ると、各lossの絶対値は異なりますが、mask loss (roi_mask_loss)も比較的初期段階から下降していきます。 セグメンテーションマスクの学習は、前述のように、候補領域に存在するオブジェクトの正解ラベルと正解マスクを用いて行われます。したがって、正確にラベル予想ができるようになる前(roi_cls_lossが下がる前)でもセグメンテーションの学習が進んでいると考えられます。

rcnn_4.png

図4 train lossの推移

推論

推論の実装では、学習に用いたネットワークの出力に若干の「後処理」を加えています。 Non Maximum Supression (NMS)、およびセグメンテーションマスクの表示です。 NMS処理は、推定したBounding Boxのうち、信頼度の高いものだけを残して、それらにオーバーラップするものを排除する処理で、chainercvのNMS実装をそのまま用いています。

セグメンテーションマスクは、我々の実装では、簡単に

for my in range(mask_size):
    for mx in range(mask_size):
        mxy = (bb[1]+width/14*mx, bb[0]+height/14*my)
        Mcolor=np.clip((M[my,mx])*1,0,0.5)
        ax.add_patch(plot.Rectangle(mxy, int(width/14)+1,int(height/14)+1,
        fill=True, linewidth=0,facecolor=COLOR[i%len(COLOR)], alpha=Mcolor))

のように、Bounding Box('bb')内を(mask_size(=14), mask_size)に分割して、maskネットワークの出力'M'に応じて四角形をアルファブレンドしていきます。簡易な表示方法ですが、人物のセグメンテーションが個別に行えていることがわかります。色はパレットを作り、オブジェクト毎にランダムに選定しています。

rcnn_5.png

図5 セグメンテーションマスク推論結果の可視化

まとめ

今回はICCV'17 Best PaperであるMask R-CNNの機能を、chainercvに追加するかたちで再現してみました。 実装はこちらにて公開しています。ぜひお試しください!

参考文献

[1]K. He, G. Gkioxari, P. Dollar, and R. Girshick. Mask R-CNN. In ICCV, 2017.
[2]yu4u, 最新の物体検出手法Mask R-CNNのRoI AlignとFast(er) R-CNNのRoI Poolingの違いを正しく理解する. https://qiita.com/yu4u/items/5cbe9db166a5d72f9eb8

続きを読む
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

Amazon EC2 P3インスタンスにおけるPose Estimation速度向上検証

はじめに

皆さんこんにちは。AIシステム部・AI研究開発グループの李天琦(leetenki)です。

先日Amazon EC2 P3インスタンスがリリースされるに伴い、11月9日にアマゾン東京本社にて、「Amazon EC2 GPU インスタンス 祭り」というイベントが開かれました。それに先駆けて、弊社AIシステム部では特別に先行でP3インスタンスを使用させて頂き、速度性能の評価を行いました。また、イベントでのお客様企業による登壇セッションでもその内容について発表させて頂きました。本記事でその評価結果について紹介しようと思います。

AWS_AI1.png

Amazon EC2 P3インスタンスとは

Amazon EC2 P3は、NVIDIA Tesla V100世代のGPUを搭載した最新のインスタンスです。GPUベースの並列コンピューティング機能を兼ね備え、CUDAやOpenCLを使用するGPGPUコンピューティング用途向けに設計ています。特に高い浮動小数点演算処理能を必要とする機械学習、Deep Learning用途に最適化されています。

2017年11月時点において、Amazon EC2で提供されているオンデマンドタイプのGPUインスタンスのうち、P3シリーズのインスタンスは下記の3種類です。全てTesla V100モデルのVoltaアーキテクチャのGPUを搭載しています。GPUの数やGPUメモリサイズ、CPUの数やCPUメモリサイズ等の細かい違いがあります。

GPUs GPU Memory CPUs Main Memory
p3.2xlarge 1 16 8 61
p3.8xlarge 4 64 32 244
p3.16xlarge 8 128 64 488

検証環境

今回速度性能評価を行う上で、比較をシンプルにするために、以下の1GPUのみのp3.2xlargeタイプのインスタンス、及びこれに対応する1世代前のp2.xlargインスタンスを使用しました。

GPUs GPU Memory CPUs Main Memory
p2.xlarge 1 12 4 61
p3.2xlarge 1 16 8 61

また、OS及び各種ライブラリ環境はどちらも以下のように統一させました。

OS Ubuntu16.04
CUDA 9.0
cuDNN 7.0
chainer 3.0.0
cupy 2.0.0

検証用モデル

自分はAIシステム部内ではComputer Visionチームに所属しているという事もあり、今回は普段から業務で使っているCNN(Convlutional Neural Network)について速度検証させていただきました。具体的には、以下に述べるVGG19及び、Pose Estimationのネットワークを使用しました。

VGG19速度比較

Computer Visionのタスクを解く上で、よく使われるCNNモデルにVGG19というのがあります。これは元々、画像認識の世界的なコンペティションであるILSVRC2014において、Classification Taskの分野で世界一の精度を記録したモデルです。最近ではClassification Taskだけでなく、様々な高度なCNNモデルのベースの特徴抽出器としても使われています。そのモデル構造は非常にシンプルで、下図のように3×3のConvolution層及びPooling層のみから成り立っています。

AWS_AI2.png

Architecture of the two-branch multi-stage CNN (Cao, et al., 2017)

今回VGG19の計測を行うために、元々p2インスタンス上で動かしていたコードをそのままp3インスタンスに持ってきて速度比較を行いました。本来ならば、Tensorcoreを発動させるのにp3用にソースコードをFP32からFP16に書き換えるのが望ましいですが、今回はChainerの開発ブランチが上手く動作せず、そちらについては断念しました。

以下が、p2及びp3上におけるVGG19モデルの動作速度の比較になります。このグラフでは、VGG19を1回推論処理するのに必要な平均時間を示しています。 AWS_AI3.png

VGG19を1回推論処理するのに、p2インスタンスでは5.7[msec]かかっていたのが、p3インスタンスでは0.62[msec]と約9〜10倍高速化される結果となりました。 なぜTensorcoreを発動せずともこのように高速化できたのかについて、詳しく調べるためにNVIDIA Profilerを使ってプロファイリングしてみました。

まずp2インスタンスについて、下図のように、処理中はGPU使用時間の約70%をimplicit_convole_sgemmというcuda関数が占めています。これは簡単に言えば、cudaを使ったconvolution層の畳み込み演算を行う関数です。 AWS_AI4.png

一方で、p3インスタンスの処理結果を見てみると、同じようにconvolution処理を行なうのに、implicit_convole_sgemmではなく、winograd3 × 3Kernelというcuda関数が呼び出されています。 AWS_AI5.png

このwinogradが何かと言うと、convolutionのカーネルサイズが小さい時(3 × 3等)に、畳み込み演算を高速化するアルゴリズムです。VGG19のモデルでは全てのconvolution層のカーネルサイズが3 × 3となっているので、このwinogradアルゴリズムにより大幅に高速されたという訳です。しかし、このwinogradアルゴリズムは実はKepler世代より前のGPUには対応していないため、今回はp3インスタンス上でのみ発動し、このwinogradアルゴリズムの差、及び元々のGPUパワーの差が効いて、9倍高速されたと推測できます。

Pose Estimation速度比較

次にPose Estimationについて速度比較を行います。このPose Estimationという技術を簡単に説明すると、RGBの2次元動画像から、映っている人の細かいPoseを推測する技術です。下図のように、実際に我々が開発を進めているスマートショップというプロジェクトでもこの技術を活用しています。

movie_result.gif

アルゴリズムの詳細については元論文を参照して頂ければと思いますが、このアルゴリズムのモデル構造は非常にシンプルです。下図にあるように、ネットワーク構造は1 × 1、3 × 3、7 × 7のConvolution 及びPooling Layerのみで構成されています。

AWS_AI6.png

Architecture of the two-branch multi-stage CNN (Cao, et al., 2017)

入力画像を、まずはVGG19とほぼ同じ構造のCNNに通して、解像度を8分の1に圧縮した特徴マップを抽出します。その後段で2つのブランチに分岐し、1つはConfidence Mapsと呼ばれる、体の各key pointをheatmap形式で予測するネットワークです。下図のように、key pointの種類ごとに1channelの出力で予測します。

AWS_AI7.png

Part Confidence Maps (Cao, et al., 2017)

もう一つのブランチが、PAFs (Part Affinity Fields) と呼ばれる、各key point間の繋がりうる可能性を表すベクトルマップを予測するネットワークです。

AWS_AI8.png

出典: Part Affinity Fields (Cao, et al., 2017)

これら2つのブランチでConfidence Maps及びPAFsをそれぞれ予測した後、さらに予測した結果に最初のVGG19で抽出した特徴マップをconcatして、これを再度同じ構造のネットワークに繰り返し入力していきます。この繰り返しのネットワークをstageと言い、stageが進むほど精度があがる仕組みです。

このPose Estimationのモデルに関してはstageごとに推論速度の比較を行いました。以下が比較結果になります。 AWS_AI9.png

こちらの比較結果を見ると、最初のVGG19の処理部分では、p3インスタンスのほうが約8〜9倍高速化できている事がわかります。また、その次のstage1でも、p3インスタンスのほうが約7倍高速化されています。しかし、stage2以降では差が縮まり、約2.3倍しか高速化されない結果となりました。

これについてもプロファイリングしてみたところ、winogradアルゴリズムが関係している事がわかりました。先ほど説明した通り、winogradというのはconvolutionのカーネルサイズが小さい時(3 × 3等)に、畳み込み演算を高速化するアルゴリズムです。今回使用したPose Estimationのモデルでは、最初のVGG19及びstage1の部分では全てカーネルサイズが3 × 3のconvolution層で構築されているため、p3インスタンスのほうでwinogradが発動して7〜9倍高速化された訳です。しかし、stage2以降ではほとんどのconvolution層がカーネルサイズ7 × 7に置き換わるため、p3でwinogradを発動させる事ができず、GPUパワーの違いのみで、そこまで大きく速度差が開かなかったと考えられます。

Batch処理の速度比較

以上のpose estimationの推論速度の比較を行ったところ、winogradが発動しない場合はGPUパワーのみの違いで約2〜3倍しか差が開かない事がわかりました。しかし、GPU使用率を見てみると、p2インスタンスではGPU使用率100%といっぱいいっぱいなのに対し、p3インスタンスではGPU使用率が34%とまだかなり余裕があるように思えます。

そこで、Batch処理を行って、どちらもGPU使用率を100%まで使い切った状態で速度比較を行いました。下図が、batchサイズを増やした際のp2インスタンス及びp3インスタンスの推論処理時間になります。 AWS_AI10.png

batch size 1の時ではp3インスタンスのほうが処理速度3.7倍(stage 2までのトータル処理速度)だったのに対し、batch sizeを大きくしていけば行くほど処理速度の差が開いていく結果になりました。グラフにあるように、p2インスタンスではbatch sizeを32倍にすると処理速度もそれに比例して約30倍ほど遅くなるのに対し、p3インスタンスではbatch sizeを32倍にしても処理速度は約8〜9倍しか遅くならないという結果となりました。倍率で言うと、batch size 32で処理した場合はwinogradの発動しないstage2以降でも、p3インスタンスのほうが8倍以上高速化可能という事になります。

ちょうど、今までp2インスタンス上でリアルタイムのPose Estimationを行うのに約3〜4FPSとフレームレート的にカクカクだったので、これをp3インスタンスに置き換えれば30FPSと完全にリアルタイムで処理できるという事になります。

訓練速度比較

ここまで推論の話を書いてきたので、訓練についても速度比較を行ってみます。ここでは、Pose Estimationのモデルをフルスクラッチで訓練させ、1回の順伝搬及び逆伝搬にかかったイテレーション時間を計測します。なお、batch sizeはGPUメモリの都合上どちらも16とします。

以下が訓練における速度比較結果になります。p2インスタンスでは1回のイテレーションを行うのに9.8秒かかったのが、p3インスタンスでは1.3秒と約7.5倍高速化された結果となりました。ちょうど今までp2インスタンスでの訓練に1週間ほどかかっていたのが、1日で完了するので実用的にはかなり嬉しいですね。

速度
p2インスタンス 9.8[sec/iter]
p3インスタンス 1.3[sec/iter]

コストパフォーマンス比較

今回速度比較に用いたp2.xlarge及びp3.2xlargeインスタンスについて、東京リージョンの価格を比較してみます。

価格
p2.xlarge $1.542/hour
p3.2xlarge $5.243/hour

このように、コスト面ではp3.2xlargeのほうが約3.4倍高くなっています。しかしこれまで説明した通り、p2インスタンス上で動いていたコードに特に変更を加えなくとも、そのままp3インスタンスに持って行けば約7〜9倍高速化できるので、値段の割にコスパはかなり良いと思います。そして今回は残念ながら触れられませんでしたが、Volta世帯のGPUの目玉機能であるTensorcoreが発動するようコードを修正すれば、更に10倍速以上の高速化が期待できますので、機会があればそちらにもチャレンジしてみようと思います。

おまけ

おまけですが、今回p2及びp3インスタンスの速度比較に使用したPose Estimationのソースコードについて、こちらでオープンソース公開していますので、皆さんもし良かったら試してみてください。

参考文献

・Zhe Cao and Tomas Simon and Shih-En Wei and Yaser Sheikh. Realtime Multi-Person 2D Pose Estimation using Part Affinity Fields. In CVPR, 2017. arXiv:1611.08050 [cs.CV].

続きを読む
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

Chainerを用いたRealtime Multi-Person Pose Estimation実装

はじめに

皆さんこんにちは。DeNAのAI研究開発エンジニアの李天琦(leetenki)です。今日はChainer Advent Calendar 2017の初日エントリという事で、Realtime Multi-Person Pose Estimationの実装について解説させて頂きます。

movie_result.gif

pose estimationの実行結果

背景

Realtime Multi-Person Pose Estimationとは、CVPR2017でCMUが発表した、RGBの2次元画像のみから複数人のPose情報を検出するアルゴリズム (Cao, et al., 2017) です。特徴は、1枚の画像から複数人のPoseを検出するために、それまで主流であったBounding Boxを検出した後に各Boxに対してPose検出するというトップダウン方式を取らずに、ボトムアップかつワンショットに複数人のPoseを推定してしまう点です。画像に映ってる人数に関わらず1回の推論でPose推定を行うので、Realtimeに処理できるほど高速という訳です。また、1回の推論でPoseまで検出できるので、Bounding Boxから検出するトップダウン方式に比べると誤差の蓄積がなく、精度も著しく向上しています。事実こちらのアルゴリズムは2016 MSCOCO Keypoints Challengeで優勝し、この時点においてのstate-of-the-artを記録しています。

CMUのオリジナル実装はCaffeをベースにしたopenposeというライブラリで公開されています。TensorFlowやPyTorchによる再現実装も有志で行われているようですが、Chainer実装で公開されているものはなかったので、今回はこれをChainer化していこうと思います。コードはこちらを参照してください。

モデル解説

実装の話に入る前に、まずはモデルの構造を簡単に説明しておきます。

詳細は元論文を参照して頂ければと思いますが、このアルゴリズムのアーキテクチャ自体は非常にシンプルです。以下のモデル図にあるように、ネットワーク構造は1 × 1、3 × 3、7 × 7のConvolution 及びPooling Layerのみで構成されています。

Chainer-1.png

Architecture of the two-branch multi-stage CNN (Cao, et al., 2017)

入力画像を、まずはVGG19とほぼ同じ構造のCNNに通して、解像度を8分の1に圧縮した特徴マップを抽出します。その後段は2つのブランチに分岐しており、1つはConfidence Mapsと呼ばれる、体の各key pointをheatmap形式で予測するネットワークです。下図のように、key pointの種類ごとに1channelの出力で予測します。

Chainer-2.png

Part Confidence Maps (Cao, et al., 2017)

もう一つのブランチが、PAFs (Part Affinity Fields) と呼ばれる、各key point間の繋がりうる可能性を表すベクトルマップを予測するネットワークです。繋がりが定義されているkey point間を結ぶ線分上(正確には一定の幅を持つ領域)の全てのピクセルにおいて、一定の長さを持つ方向ベクトルが定義されます。このベクトルはxとyの2枚チャンネルのheatmapによって表現されます。下図の例では、オレンジ色となっている部分が、肩から腕にかけての方向ベクトルのマップです。

Chainer-3.png

出典: Part Affinity Fields (Cao, et al., 2017)

これら2つのブランチでConfidence Maps及びPAFsをそれぞれ予測した後、さらに予測した結果に最初のVGG19で抽出した特徴マップをconcatして、これを再度同じ構造のネットワークに繰り返し入力していきます。この繰り返しのネットワークをstageと言い、stageが進むほど精度があがる仕組みです。

モデルの実装

では実装の解説に入っていきましょう。MSCOCO Keypoints Challenge 2016で訓練済みの重みパラメータファイルがこちらで公開されていますので、今回まずこれをChainer用に変換して、推論の処理を実装して行きます。

先ほど説明したように、このアルゴリズムのネットワーク構造自体は非常にシンプルで、1 × 1、3 × 3、及び7 × 7のConvolution Layerのみで構成されています。ゆえに、chainer.links.caffe.CaffeFunctionを使えば簡単にcaffemodelを読み込む事ができます。ただし、CaffeFunctionを使ったcaffemodelの読み込みは非常に時間がかかるので、毎回使い回す事を考えて、一旦自前でChainerのLayer定義を書いて、これに重みパラメータを代入した状態でnpzファイルに書き出します。

ChainerのLayer定義ファイルはこちらです。以下のconv11からconv44_CPMの部分が最初のVGG19を使った特徴抽出器です。VGG19と同じ構造で、全て3 × 3のConvolution Layerとなっています。これによって画像サイズが8分の1に圧縮されたFeature mapが出力されます。

# cnn to make feature map
conv1_1=L.Convolution2D(in_channels=3, out_channels=64, ksize=3, stride=1, pad=1),
conv1_2=L.Convolution2D(in_channels=64, out_channels=64, ksize=3, stride=1, pad=1),
conv2_1=L.Convolution2D(in_channels=64, out_channels=128, ksize=3, stride=1, pad=1),
conv2_2=L.Convolution2D(in_channels=128, out_channels=128, ksize=3, stride=1, pad=1),
conv3_1=L.Convolution2D(in_channels=128, out_channels=256, ksize=3, stride=1, pad=1),
conv3_2=L.Convolution2D(in_channels=256, out_channels=256, ksize=3, stride=1, pad=1),
conv3_3=L.Convolution2D(in_channels=256, out_channels=256, ksize=3, stride=1, pad=1),
conv3_4=L.Convolution2D(in_channels=256, out_channels=256, ksize=3, stride=1, pad=1),
conv4_1=L.Convolution2D(in_channels=256, out_channels=512, ksize=3, stride=1, pad=1),
conv4_2=L.Convolution2D(in_channels=512, out_channels=512, ksize=3, stride=1, pad=1),
conv4_3_CPM=L.Convolution2D(in_channels=512, out_channels=256, ksize=3, stride=1, pad=1),
conv4_4_CPM=L.Convolution2D(in_channels=256, out_channels=128, ksize=3, stride=1, pad=1),

その後に続く以下のような2分岐されたConvolution Layerが、各StageにおけるPAFs及びConfidence Mapsの計算部分になります。ここではL1とついてるのがPAFsで、L2がConfidence Mapsになります。そして、stage1ではカーネルサイズ3 × 3のConvolution Layerで構成されていますが、stage2以降ではreceptive fieldを広げるために7 × 7のConvolutionに置き換わっています。stage3以降のネットワークも全てstage2と同じ構造となっています。

# stage1
conv5_1_CPM_L1=L.Convolution2D(in_channels=128, out_channels=128, ksize=3, stride=1, pad=1),
conv5_2_CPM_L1=L.Convolution2D(in_channels=128, out_channels=128, ksize=3, stride=1, pad=1),
conv5_3_CPM_L1=L.Convolution2D(in_channels=128, out_channels=128, ksize=3, stride=1, pad=1),
conv5_4_CPM_L1=L.Convolution2D(in_channels=128, out_channels=512, ksize=1, stride=1, pad=0),
conv5_5_CPM_L1=L.Convolution2D(in_channels=512, out_channels=38, ksize=1, stride=1, pad=0),
conv5_1_CPM_L2=L.Convolution2D(in_channels=128, out_channels=128, ksize=3, stride=1, pad=1),
conv5_2_CPM_L2=L.Convolution2D(in_channels=128, out_channels=128, ksize=3, stride=1, pad=1),
conv5_3_CPM_L2=L.Convolution2D(in_channels=128, out_channels=128, ksize=3, stride=1, pad=1),
conv5_4_CPM_L2=L.Convolution2D(in_channels=128, out_channels=512, ksize=1, stride=1, pad=0),
conv5_5_CPM_L2=L.Convolution2D(in_channels=512, out_channels=19, ksize=1, stride=1, pad=0),
# stage2
Mconv1_stage2_L1=L.Convolution2D(in_channels=185, out_channels=128, ksize=7, stride=1, pad=3),
Mconv2_stage2_L1=L.Convolution2D(in_channels=128, out_channels=128, ksize=7, stride=1, pad=3),
Mconv3_stage2_L1=L.Convolution2D(in_channels=128, out_channels=128, ksize=7, stride=1, pad=3),
Mconv4_stage2_L1=L.Convolution2D(in_channels=128, out_channels=128, ksize=7, stride=1, pad=3),
Mconv5_stage2_L1=L.Convolution2D(in_channels=128, out_channels=128, ksize=7, stride=1, pad=3),
Mconv6_stage2_L1=L.Convolution2D(in_channels=128, out_channels=128, ksize=1, stride=1, pad=0),
Mconv7_stage2_L1=L.Convolution2D(in_channels=128, out_channels=38, ksize=1, stride=1, pad=0),
Mconv1_stage2_L2=L.Convolution2D(in_channels=185, out_channels=128, ksize=7, stride=1, pad=3),
Mconv2_stage2_L2=L.Convolution2D(in_channels=128, out_channels=128, ksize=7, stride=1, pad=3),
Mconv3_stage2_L2=L.Convolution2D(in_channels=128, out_channels=128, ksize=7, stride=1, pad=3),
Mconv4_stage2_L2=L.Convolution2D(in_channels=128, out_channels=128, ksize=7, stride=1, pad=3),
Mconv5_stage2_L2=L.Convolution2D(in_channels=128, out_channels=128, ksize=7, stride=1, pad=3),
Mconv6_stage2_L2=L.Convolution2D(in_channels=128, out_channels=128, ksize=1, stride=1, pad=0),
Mconv7_stage2_L2=L.Convolution2D(in_channels=128, out_channels=19, ksize=1, stride=1, pad=0),

次に、caffemodelをChainer用に変換します。変換用コードはこちらです。重みパラメータの代入部分は以下のようになります。

exec("chainer_model.%s.W.data = caffe_model['%s'].W.data" % (layer_name, layer_name))
exec("chainer_model.%s.b.data = caffe_model['%s'].b.data" % (layer_name, layer_name))

Convolution Layerの場合、W.dataとb.dataのみ代入すれば済みますので、これを全てのLayerに対して繰り返すだけです。

推論の実装

ネットワークの推論の実装はこちらです。実際にCNNの処理を行っている部分はこれだけです。

h1s, h2s = self.model(x_data)

RGB画像をCNNに通して、PAFsとConfidence Mapsの出力を得るだけですね。ただ、このアルゴリズムのミソはその後処理部分で、得られたPAFsとConfidence Mapsからスケルトン情報を再構築する部分が最も複雑です。では順を追って説明していきます。

① PAFsとConfidence Mapsのサイズ拡大
ネットワークから出力されるfeature mapは幅も高さも8分の1に圧縮されているので、まずはこれをresizeしてオリジナルの画像サイズに引き伸ばします。Chainer2.0からはchainer.functions.resize_imagesというFunctionが定義されたので、これを使うとVariableのまま計算できます。

② Confidence Mapsをガウシアン平滑化
8倍サイズに引き伸ばした直後のConfidence Mapsは、peak周りがデコボコしていて、山がハッキリしないので、これにガウシアンフィルタをかけてpeakを一定に平滑化します。scipy.ndimage.filters.gaussian_filterを使えば簡単に実装できるのでオススメです。以下がガウシアン平滑化の計算部分になります。

heatmap = gaussian_filter(heatmaps[i], sigma=params['gaussian_sigma'])

下図の左がガウシアンフィルタをかける前で、右がかけた後です。 Chainer-4.png

ちなみに、これをVariableのままGPUを使って計算したい場合、chainer.functions.convolution_2dを使って、ガウシアンカーネルを手動で定義してあげれば実装できます。

③ Confidence Mapsからkey point座標を求める
ガウシアンフィルタをかけた後のConfidence Mapsは下図(右)のようになります。ここから、peakの(x, y)座標を求めます。実はこのConfidence Mapsからpeakの座標値を求める処理が意外に計算コストが高いのです。 Chainer-5.png

実際にConfidence Mapsからpeak座標を求める処理は以下の部分になります。

map_left = xp.zeros(heatmap.shape)
map_right = xp.zeros(heatmap.shape)
map_top = xp.zeros(heatmap.shape)
map_bottom = xp.zeros(heatmap.shape)
map_left[1:, :] = heatmap[:-1, :]
map_right[:-1, :] = heatmap[1:, :]
map_top[:, 1:] = heatmap[:, :-1]
map_bottom[:, :-1] = heatmap[:, 1:]

peaks_binary = xp.logical_and.reduce((
    heatmap >= map_left,
    heatmap >= map_right,
    heatmap >= map_top,
    heatmap >= map_bottom,
    heatmap > params['heatmap_peak_thresh']
))

ここでは効率良く計算するために、Confidence Mapsを上下左右に1ピクセルずつずらしたheatmapを4枚用意します、オリジナルのConfidence Mapsと上下左右のheatmapを比較して、その全てより値が大きいピクセルをkey pointとして座標抽出するようにしています。

④ key point間のPAFsを積分
key pointが全て求まった後、関係あるkey pointだけをグルーピングして人のスケルトンを構築する必要があります。論文では、2種類のkey point間の考え得る全てのconnectionの組合せを実際に繋げてみて、その間のPAFsの積分値で同じグループか否かを判別します。ちなみに、そもそもなぜこのPAFsの積分を行うのかと言うと、訓練時に、関係あるkey pointの間には一定の方向ベクトルが定義され、関係ないkey point間ではゼロベクトルが定義されるので、推論する時にはこれを手掛りにkey point間のベクトルの方向及び大きさの合計を見れば、2つのkey pointが関係あるか否か判別できるのです。

PAFsの積分は元論文に書いてある通り、2点間を結ぶ線分上の各ピクセルにおいて、その水平方向ベクトルと実際の推論で求まったベクトル値の内積をとって、全部足し合わせるという手法です。

Chainer-6.png

single limb with groundtruth positions (Cao, et al., 2017)

これを実際に実装しているのが以下の部分になります。params[‘nintegpoints’]というのは、2点間を何分割するかというハイパーパラメータで、今回は10に設定しています。

vec_unit = vec / vec_len
integ_points = zip(
    np.linspace(joint_a[0], joint_b[0], num=params['n_integ_points']),
    np.linspace(joint_a[1], joint_b[1], num=params['n_integ_points'])
)
paf_in_edge = self.extract_paf_in_points(paf, integ_points)
inner_products = np.dot(paf_in_edge, vec_unit)

⑤ connectionの選択
以上の④までで、各点間の候補となるconnectionはPAFsによって重み付けられた積分値を得る事ができました。最後はこれを使って有効なconnectionを選択していきます。本来であれば2種類のkey point間で考え得る全パターンの組合せを作り、そのトータルのPAFs積分値が最大となる組合せを選択すべきですが、これを愚直に実装すると人数が増えるにつれて計算量がO(n^2)で増えていきます。なので、今回はgreedy法を採用し、PAFs積分値を大きい順にソートして上から順に選択していきます。そしてそれ以上選べるkey pointがなくなった時点で打ち切るようにしています。以上の処理はcompute_connectionsという関数で実装しています。

推論処理の実装は以上です。モデル訓練の話はData AugmentationやPAFs生成と長くなりそうなので、また次回のパートⅡで書こうと思います。

実行結果

ではてきとうな画像を使って推論を試してみましょう。

Chainer-8.png 完璧にPose認識できていますね。

Chainer-7.png

人が増えても、遠くにいても問題ないですね。 ※ちなみに推論処理のスケールについて、entity.pyというファイル内で以下のように定義しているハイパーパラメータがあります。

'inference_scales': [0.5, 1.0, 1.5]

これは画像を0.5倍、1.0倍、1.5倍のスケールでそれぞれ推論し、その結果を平均するという意味です。速度と精度のトレードオフだと思いますが、この値を調整すればいろんなスケールに対して高精度にPose検出する事ができます。

今回、chainerで実装したRealtime Multi-Person Pose Estimationのコードは全てこちらで公開していますので、皆さん興味があればぜひご自分の環境で動かしてみてください。

参考文献

・Zhe Cao and Tomas Simon and Shih-En Wei and Yaser Sheikh. Realtime Multi-Person 2D Pose Estimation using Part Affinity Fields. In CVPR, 2017. arXiv:1611.08050 [cs.CV].

続きを読む
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

KDD2017に参加してきました

はじめに

こんにちは。AIシステム部研究開発グループの春日です。当グループではCV/NLP/RLといった技術領域を中心に研究開発を行い、実際のサービスへの活用を行っております。近年では会社として次の柱とすべくオートモーティブ事業へも注力しており、ここで活用される機械学習技術も当グループで開発を担っています。そこで、KDDというデータマイニング分野でのトップカンファレンスを聴講しにいき、オートモーティブ事業関連で活用されている技術についてキャッチアップしてきました。今回はその内容についてお伝えしていきたいと思います。

KDDとは

KDDの正式名称は「International Conference on Knowledge Discovery and Data Mining」です。今回は23回目の開催であり、1990年代にデータマイニングという研究分野が明確に確立されてから現在も盛んに研究発表がなされています。開催期間は8/13-17の5日間でした。初日はTutorial Day、2日目がWorkshop Dayという特定のテーマに沿った発表です。3-5日目がMain KDD Conferenceで、採択率約10%で採択された優秀な論文が発表されます。

開催場所

開催場所は、カナダ・ハリファックス (Halifax, Nova Scotia - Canada) です。日本からだと直行便がなく、最短で約17時間はかかる場所です。小さい町ですが港町として栄えており、非常に過ごしやすい場所でした。

kdd-image7.png

[ 会場のHalifax World Trade and Convention Centre]

さすが、港町というだけあって平然とロブスターが大量に叩き売りされています。

kdd-image8.png

[ロブスターの陳列]

近年のデータサイエンスブームの波を受けたこともあり、過去最多の1143本が投稿され、Main Conferenceに採択されたのは100本、Posterに採択されたのは116本でした。

セッションの様子

投稿された論文のうちMain Conferenceに採択されると口頭での発表ができます。カテゴリごとに複数の会場があり、各会場とも300人程度のキャパシティがあります。人気なところは立ち見になることもあります。Google社の講演 TFX: A TensorFlow-Based Production-Scale Machine Learning Platform (Denis Baylor et al.) は大変盛況でした。

kdd-image19.jpg

[Main Conferenceでの発表の様子(KDD2017での講演より)]

一方で、Posterに採択されると、19:00-22:00の夜の時間帯で会場に自身の研究内容をポスターで展示し、参加者からの質疑応答に応える形式で発表がされます。

kdd-image12.jpg

[Poster発表会場の様子(KDD2017でのポスター展示より)]

注目の論文

今回KDDに参加した中で、オートモーティブドメインにおいて注目すべき論文を取り上げて紹介します。

  • The Simpler The Better: A Unified Approach to Predicting Original Taxi Demands on Large-Scale Online Platforms (DiDi Chuxing)

こちらは中国の配車最大手「DiDi Chuning」による論文 The Simpler The Better: A Unified Approach to Predicting Original Taxi Demands on Large-Scale Online Platforms (Yongxin Tong et al.) です。DiDiはUber Chinaを350億ドルで買収したことで一大ニュースとなった有力企業です。そのDiDiが主力事業としているタクシー配車におけるタクシー需要のオンライン予測システムに関する論文です。UOTD(Unit Original Taxi Demand)とは、下図で示すようにそれぞれのPOIや時間ごとのタクシーの需要を意味します。ここでは1時間ごとのZhongguancun Software Parkにおけるタクシー需要の予測値を示しています。

kdd-image18.png

[タクシー需要のオンライン予測 [1]]

特徴的なのが、DeepLearningを代表とする複雑なネットワークモデルを用いて予測するのではなく、以下の式で示すような単純な線形回帰モデルで予測している点です。これにシンプルな正則化項を加えただけのモデルです。

kdd-image9.png

[需要予測に用いているモデル [1]]

ただし、特徴量は合計で2億次元以上という非常に大規模なものを用いています。これには、時間や天気、POIといった様々な特徴を組み合わせたものも含みます。

kdd-image10.png

[大規模な特徴量構成 [1]]

このようなモデルを用いている背景にはビジネス観点があります。それは法規制等の環境の変化に伴って、新たな特徴が加わるごとに、モデル自体を見直すのは非常に高コストであるからという考えです。DeepLearningのようなモデルは、入力が変化する度にハイパーパラメーターチューニングに非常に時間やリソースがかかってしまうため、モデルは線形回帰と固定して特徴量だけ再設計することで、新たな予測をするということです。サービスから得られた実データを用いた実験では、NNやGBRTといった手法より高精度で予測できています。 近年では、AI = DeepLearning という認識が広まりつつあるのですが、ビジネスへの活用という観点ではこのような古典的かつシンプルな線形回帰で十分なバリューを発揮するという意味で非常に面白い論文です。

[1] The Simpler The Better: A Unified Approach to Predicting Original Taxi Demands on Large-Scale Online Platforms (Yongxin Tong et al.)

  • A Taxi Order Dispatch Model based On Combinatorial Optimization (DiDi Chuxing)

同じくDiDiによる論文ですが、こちらはタクシー配車におけるDispatchを扱ったものです A Taxi Order Dispatch Model based On Combinatorial Optimization [Lingyu Zhang et al.] 。Dispatchとはタクシードライバーと顧客の配車オーダーの割当を意味し、これをどのように最適化するかという問題です。まず前提として、顧客が配車オーダーを出した段階で、ドライバーにリクエストが送信されます。ドライバーはそれを承諾するか拒否するかという行動をとることができます。よって、どのオーダーをどのドライバーに割り当てれば承諾の成功確率(=SR)を最も高くできるかを考えなくてはなりません。単純には、配車オーダーがあった地点から最も近い地点のドライバーを割り当てるといった方法が考えられます。

kdd-image15.png

[オーダーとドライバーの位置関係の例 [2]]

DiDiの提案手法では、まずドライバーの承諾確率をモデル化します:pij=p(y=1|oi,dj) oiはオーダーに関連するETAやPOIのカテゴリーといった特徴量、djはドライバーに関連する過去の承諾率や営業エリアといった特徴量です。さらに曜日や時間といった特徴も加えて、承諾確率pijをモデル化します。ここではLogistic Regressionが用いられています。 この承諾確率を用いてSRの平均を最大化するオーダーとドライバーの割当の組み合わせを以下に式に従って最適化します。

kdd-image16.png

[Order Dispatch Problem [2]]

この際、Hill-climbing Algorithmを用いて最適解を求めます。北京市内の実データに適用実験した結果、SRがベースラインモデルの80%から84%に向上したということです。

kdd-image17.png

[実験結果 [2]]

DiDiは自社にどんどん蓄積される豊富なデータを用いて、より効率的なモデルの独自開発を行っており、今後も注目すべき企業だといえます。 [2] A Taxi Order Dispatch Model based On Combinatorial Optimization [Lingyu Zhang et al.]

  • Planning Bike Paths based on Sharing-Bikes' Trajectories (Microsoft Research)

こちらは最近日本進出でも話題となったMobikeのデータを用いた自転車専用レーンの設計計画に関するMicrosoft Researchの論文 Planning Bike Paths based on Sharing-Bikes' Trajectories [Jie Bao et al.]

kdd-image14.png

[Mobikeユーザーの走行軌跡データ(KDD2017での講演より)]

中国では大気汚染や交通渋滞の解消のためにシェアバイクが急速に普及しています。しかし、自転車専用レーンが整備されていないため、安全性が不十分という問題があります。そこで、予算という制約のもとで、いかに効率的に専用レーンを建設すべきかが今回の目的です。 各ユーザーの走行軌跡に対して建設した専用レーンのスコアをscore(,)=ssegs()s.ls.lと定義します。これを合計したスコアTscore(,)を最大化するように専用レーンを建設する計画を立てます。 方法はシンプルで、①開始点を抽出する ②Greedy Network Expansionによって道路リンクを繋いでいく というステップで最終的に建設する道路ネットワークを抽出・可視化します。 ①の開始点の抽出ですが、単純には最も頻繁に使われる上位数点を用いるといったことが考えられます。そうすると、頻繁に通る道はたいてい近い場所にあることが多いので、かなり近い範囲で開始点が定まってしまうことが問題です。そこでSpatial Clusteringを行うことで、空間的な広がりも考慮しながら開始点を定めるというところが本手法のコアです。これによって、下図で示すように、地図上で広がりのある道路ネットワークを可視化できていることがわかります。 ②のGreedy Network Expansionでは、①で決めた開始点を繋ぐように貪欲に道路リンクを探索していきます。もちろん予算という制約があるので、出来る限りの開始点を繋げるように道路リンクを広げていきます。

kdd-image11.png

[Spatial Clusteringを用いた結果 [3]]

[3] Planning Bike Paths based on Sharing-Bikes' Trajectories [Jie Bao et al.]

KDD Cup 2017

最後に KDD Cup というデータ分析コンテストについて共有します。KDD Cup では提供されたデータセットに対して課題が設定され、その課題におけるモデルの精度を競うコンペティションです。世界的にも権威と歴史がある大会で、トップクラスのデータサイエンティストが競い合います。今回のテーマは、''Highway Tollgates Traffic Flow Prediction" でした。課題設定は2つあり、①Travel Time Prediction ②Volume Prediction です。ここでは、①Travel Time Predictionについて取り上げます。

kdd-image13.png

[Highway Tollgates Traffic Flow Prediction [5]]

このタスクは交差点から料金所の旅行時間を予測するというものです。例えば上図でいうと、IntersectionAからTollgate2の区間での車両の通過時間を意味します。用いるデータセットは各区間の車両軌跡データ・該当エリアの天気・道路ネットワークです。評価指標は移動時間予測タスクにおける一般的な指標であるMAPE(Mean Absolute Precentage Error) です。優勝チームであるTeam Convolutionは、MAPE=0.1748でした。このチームが優勝したポイントはモデル・特徴・データという3つのレベルでのアンサンブル学習にあります。モデルレベルではXGBoostやMultilayer Perceptron等のモデルを用いたアンサンブル学習とします。特徴レベルでは異なる減衰係数やスムージング係数等を用いて算出した特徴量を組み合わせたものをアンサンブル学習させます。データレベルでは異なる滑走窓の値や分割数でのデータによりアンサンブル学習させます。このように3つのレベルでたくさんアンサンブル学習させることにより汎化性能を上げ、MAPE = 0.1748という精度を得られています。かなりテクニカルではありますが、基本的には複雑なモデルを用いずに、BoostingやMLPといった古き良き古典的なモデルを用いている点が面白いです。実際のビジネスの場でも最新の複雑なモデルではなく、広く一般的に使われているモデルを用いる場面も多々あります。

[5] KDD Cup 2017

全体の感想

KDDという学会は扱う分野がかなり幅広いのですが、今回は主にオートモーティブ事業関連について取り上げました。他にもClusteringやGraphなどの理論寄りに関する研究から、Medical DataやRecommendationといった実務寄りの研究まで多様な研究が発表されていました。ご興味ある方はこちらのAccepted Paperからご覧下さい ( http://www.kdd.org/kdd2017/accepted-papers ) 今回の学会参加を通して、最先端のオートモーティブ事業で取り組まれている技術についてキャッチアップできたことはもちろん、参加者の方々とのネットワーキングができたことも大変刺激的で良い勉強になりました。 DeNAでは国際学会派遣制度というものがあり、私のような新卒1年目でも積極的に学会に参加することができます。こういった制度を活用してスキルアップできる環境は素晴らしいと思います。一緒に働いてみたいと思われた方は是非ご一報下さい!

続きを読む
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

Google機械学習活用勉強会レポート

はじめに

AIシステム部・AI研究開発グループの森と申します。この4月にDeNAに転職し、現在は主に画像や音声に関するDeep Learningの研究開発に従事しています。

DeNAでは、機械学習・人工知能(AI)技術を積極的に事業活用していく方針が全社的に打ち出されており、その一環として、エンジニアを対象にしたGoogle社様による勉強会が定期的に開催されています。

8月に行われた1回目の勉強会では、

  • Googleの機械学習プロジェクト
  • 機械学習をビジネスに応用する際のポイント
  • Google Cloud Platformで提供されている機械学習APIの概要

などをGoogle Cloud ソリューションアーキテクトの中井悦司さんに講義していただきました。

リンク:Google機械学習系API勉強会レポート https://engineer.dena.jp/2017/08/googleapi.html

2回目である今回の勉強会では、前回同様に中井悦司さんにお越しいただき、Google Cloud Platform (GCP) が提供する機械学習サービスをより実践的な面から講義していただきました。本勉強会には、DeNAのエンジニアを中心に約80名が参加しました。

IMGP2658.JPG

勉強会の様子

GCPが提供する機械学習サービス

1回目の勉強会では、Cloud Vision API、Cloud Speech API、Cloud Natural Language APIなど学習済みモデルのWeb APIが中心的な話題でした。

google_ai_api5.pngのサムネール画像

講演資料より

今回は、学習済みモデルのAPIではなく、TensorFlowとCloud Machine Learning (ML) Engineを用いて、データからオリジナルモデルを学習し、新しいAPIをデプロイするまでの流れを一通り解説していただきました。以後、演習で使用した各サービスを簡単にレポートします。

End_to_End_Process_of_Machine_Learning_with_Structured_Data.png

講演資料より

データ

BigQueryで公開されているOpen Natality Datasetを使いました。母親のさまざまな属性(人種、年齢など)と生まれた赤ちゃんの体重に関連する表形式のデータです。このデータを用いて母親の属性から赤ちゃんの体重を予測する回帰モデルをGCPのサービスを組み合わせて実現するのが目的です。

Cloud Datalab

Cloud Datalabは、データの探索、分析、可視化、機械学習モデル構築を行うためのインタラクティブツールです。Pythonのデータ分析環境として有名なJupyter Notebookと同じユーザインタフェースでGCP上のさまざまなサービスと連携することができます。今回は、BigQueryからのデータ収集、可視化による統計分析、データ前処理、機械学習モデル構築まですべてCloud Datalab上で実行しました。

datalab.png

演習に用いたノートブック

BigQuery

BigQueryは、ペタバイト級のデータを格納できるデータウェアハウスサービスです。講義ではOpen Natality Datasetの公開データベースからSQLを使って500万件のデータを収集しました。BigQueryの検索結果は、Pythonのデータ解析ライブラリであるpandasのDataFrame形式に変換できるため高度な統計分析や可視化が簡単にできます。

Cloud Dataflow

Cloud Dataflowは、パイプライン処理によってデータ前処理ができるサービスです。今回は、BigQueryから収集したデータに対して、(1) 属性の変換 (2) 訓練データとテストデータへの分割 (3) CSV形式でCloud Storageに格納という一連のパイプラインを実行しました。

dataflow.png

講演資料より

Cloud Dataflowは、処理するデータ量によって自動的にインスタンスが立ち上がるオートスケールに対応しており、何も意識することなく高速にデータ処理ができます。実際に背後でGoogle Compute Engineのインスタンスが自動的に立ち上がる様子も確認できました。

TensorFlow

TensorFlowは、Googleが提供している機械学習ライブラリです。DeNAのAI開発部でも多くのエンジニアが日常的に活用しています。

今回の勉強会では、カテゴリ変数(母親の人種など)と量的変数(母親の年齢など)を組み合わせたモデルを作るために tf.contrib.learn.DNNLinearCombinedRegressor (Wide & Deep Model) を使いました。このような複雑なモデルもTensorFlowのhigh-level APIを活用すると簡単に書けます。

tensorflow.png

講演資料より

Cloud Machine Learning Engine

Cloud DataLab上では小規模データによるテストまで行い、本番の大規模データによるモデル学習は、Cloud ML Engineを使いました。

Cloud ML Engineは、TensorFlowで構築したモデルの訓練、訓練したモデルのデプロイ、APIの提供までGCP上でシームレスに実行できるサービスです。Experiment APIを用いてモデル・訓練データ・テストデータ・評価指標を設定することで分散環境で高速にモデル学習ができます。

学習経過のログはCloud Storageに保存されるため、Cloud DataLabからTensorboardを呼び出すことで学習経過を可視化することもできます。

tensorboard.png

Tensorboardの出力例

学習済みモデルも同様にCloud Storageに保存されます。この学習済みモデルはCloud ML EngineのWebインターフェイスまたはgcloudコマンドを使うことで簡単にデプロイできます。デプロイしたモデルは、Web APIとして提供されるのでアプリケーションからjson形式のリクエストを送ることで利用できます。Cloud ML Engine上ではリクエストの頻度などAPIの使用状況も確認できます。

Google App Engine

Google App Engineを使うことで、デプロイしたWeb APIを利用するWebアプリケーションが構築できます。今回は、母親の情報から赤ちゃんの体重を予測するアプリケーションを作成しました。

application.png

完成したWebアプリケーション

ハンズオン

後半のハンズオンでは各参加者にGCPプロジェクトのアカウントが配布され、前半の講義で習った内容を実際に手を動かして体験することができました。弊社のインフラ基盤チームとGoogleエンジニアによるサポートやSlackでの情報交換により演習を円滑に進めることができました。

まとめ

今回の勉強会では、Google Cloud Platform上で、機械学習アプリケーションを構築する流れを一通り体験することができました。

これまでオンプレミス環境でWebサーバを立てて、モデルをアップロードして、アプリケーションを書いてという流れは一通り経験していましたが、これらをすべてクラウド上でかつ簡単な操作で実現できることに驚かされました。

現在、AIシステム部では、さまざまな機械学習・AI案件に取り組んでおり、迅速なサービス開発・デプロイが求められることが多くなっています。今後は、Google Cloud PlatformとCloud ML Engineを積極的に活用して効率的にサービス展開していきたいと考えています。

より深く理解するために

講師の中井さんからGCPをより深く理解するためのリソースをご紹介いただきました。

GoogleCloudPlatform / training-data-analyst https://github.com/GoogleCloudPlatform/training-data-analyst
今回の演習で使ったGithubのリポジトリです。今回の演習では blogs/babyweight を使いました。

データサイエンスに関する初心者向けの参考書 http://enakai00.hatenablog.com/entry/2017/02/20/124112
中井さんのブログ記事です。

Data Engineering on Google Cloud Platform https://www.coursera.org/specializations/gcp-data-machine-learning
Courseraが提供している有料のコースです。今回の勉強会の内容をすべて含んでいます。

続きを読む
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

第1回 SHIBUYA SYNAPSE が開催されました

はじめに

AIシステム部の西野剛平です。AIシステム部ではAI研究開発グループに所属しており、Computer Visionの技術を中心に研究開発を行っています。

8/30にAI技術に関するイベントSHIBUYA SYNAPSEの第1回目を弊社内にあるSakuraCafeにて開催し、そこで現在私が関わっている「スマートショップ実現に向けた取り組み」に関してご紹介させて頂きました。 今回は、エンジニアブログという事もあり、イベントで発表した内容のうち、特に技術的な内容について紹介したいと思います。

IMG1.JPG

IMG2.JPG

SHIBUYA SYNAPSEとは

昨今のAI技術は深層学習を中心に目まぐるしく進化しており、それとともにビジネスへの適用も着実に行われてきております。SHIBUYA SYNAPSEは、このような環境において、企業×大学や、プランナー×エンジニアといった異なるバックグラウンドを持つ参加者の有機的なつながりにより、価値あるサービスの共創の場を提供することを目的に設立されました。より詳細な情報に関してはSHIBUYA SYNAPSEのホームページをご覧いただければと思います。

今回は、SHIBUYA SYNAPSEの記念すべき第1回目で、東京大学の山崎俊彦准教授をメインスピーカーにお招きし、山崎先生からは「魅力」の予測や解析に関してのご紹介をして頂きました。また、イベントの最後には懇親会もあり、AIに対して様々な携わり方をしている方同士での意見交換が広く行われるなど、大盛況のうちにイベントを終わる事ができたのではないかと思います。

IMG3.JPG

IMG4.JPG

スマートショップの実現に向けた研究

インターネット上でのサービスにおいては、お客様に合った最適なコンテンツの配信、ログ情報からお客様の行動を解析して迷わない導線に改善するなど、日々サービスを快適にご利用頂く工夫が行われております。しかし、リアルな店舗においてはそのような最適化はあまり行われていないため、快適なサービスを提供するという点では、まだまだ改善の余地があるのではないかと考えております。 私たちは、AI技術を活用することで、リアルの店舗においても一人一人のお客様の状況に合わせた接客やリアルタイムの商品推奨など、今までにないショップ体験の提供ができないかを考え、将来のスマートショップの実現を見据えた研究開発を行っています。

IMG5.png

姿勢推定技術を活用した同一人物の再認識

スマートショップの実現のためには、店内でのお客様の状況を把握する技術の確立が不可欠です。その第一ステップとして、定点カメラからの映像を元に、深層学習ベースの姿勢推定技術を活用した、同一人物の再認識技術の開発を行いました。

本手法は、人物の検出と検出された人物の同定を繰り返し行っていくというのが大枠の流れとなっており、この人物の検出タスク部分に姿勢推定技術を利用したのは、高精度であるというのが一番の理由ですが、その他にも将来性を考慮したいという意図があります。姿勢推定では一般的な検出器で検出される人の矩形情報を得られるだけでなく、各体のパーツを表す器官点情報までも同時に検出することができます。これらの情報は非常に有用で、今後別のタスクを解く必要が発生した場合でも、有益な情報として利用できる可能性は高いと考えています。今回紹介する人物同定の技術においても、この器官点情報を利用する事により、高精度でリアルタイムに同一人物の再認識を実現しています。

一般的なトラッキングにおける問題点

例えば、粒子フィルタをベースとしたような一般的な物体追跡においては、フレーム間の画像変化を基に追跡を行うため、フレーム間隔が長い場合(フレームレートが小さい場合)はフレーム間の画像変化量が大きくなってしまい、追跡は極めて困難になってしまいます。

IMG6.png

また、正確な検出器を前提とした場合は、ある時刻tで検出された人と次のフレーム時刻t+1で検出された人の対応付けを行う事により同一人物判定をする事ができます。 例えば、簡易にトラキングを実現する方法として、Intersection over Union(IoU)の結果を利用する方法が考えられ、それぞれのフレームで検出された人の矩形(BoundingBox)同士、各々の組みでIoUを求め、その値が大きいもの同士を同一の人物とします。

IMG7.png

IMG8.png

ただし、この場合もフレーム間での人の移動量が大きい場合には、IoUの値が0となってしまい追跡が破綻してしまいます。

実サービスを見据えた場合、コスト対効果を意識しなければいけないため、限られた計算リソースで実行する事を想定する必要があります。その上で、リアルタイムに処理するとなると、フレームレートが低くなってしまうというのは、ある程度は前提事項として許容しなければいけない事でないかと考えています。(実際、紹介しているリアルタイムデモ映像のフレームレートは1.7fps程度となっています。)したがって、前述したようなフレームレートが低い場合に発生してしまう問題に対応できるような人物追跡手法を設計する必要があります。

今回紹介する手法は、こういった低いフレームレートやオクルージョンが発生するケースを特に意識しており、姿勢推定によって得られた器官点情報を上手く利用することで、そのような状況下においてもロバストに同一人物の再認識を行えるなるような手法を考案しました。

デモ映像

弊社SakuraCafe内で行ったリアルタイムデモ映像になります。

姿勢推定技術によって検出した人物を矩形で囲っています。その上に表示されている番号はその人物を識別するためのIDで、同じ番号の場合は同一人物と認識されています。また、今回技術の詳細は紹介しませんが入店と退店のタイミングや、年齢および性別の推定もリアルタイムに行っております。赤色の線が入店、青色の線が退店を表し、顔が正面を向いた際に表示される矩形に年齢と性別の推定値を表示しています。

全体の構成

本手法は下記の要素で構成されています。

  1. フレーム画像から人物の器官点の検出
  2. 1つ前のフレームで検出された人物と今回検出された人物の同じ器官点同士で色の照合
  3. 1つ前のフレームで検出された人物と今回検出された人物の位置の照合
  4. 2と3の結果から総合的に判断し、人物の同定

1から4の手順を動画の各フレームに対して逐次行っていくことで、連続的に同一人物の再認識を実現しています。

姿勢推定技術に関して

まずは、姿勢推定技術を使って、フレーム画像中から人物、および器官点の検出を行います。器官点は複数人数の器官点を同時に検出し、検出されたそれぞれの器官点はどの人物のどの体の部分に対応しているかを認識します。下の写真は検出された、鼻、首、左肩、左手、右肩、右手、左腰、左足、右腰、右足の10個の器官点になります。

IMG9.png

色差の計測

各器官点の色を取得します。各器官点を中心とした局所領域からピクセルのRGB値を取得し、それをL*a*b*色空間に変換した後、CIE2000で色差を計測します。色差は1つ前のフレームで検出された人物と今回検出された人物の同じ器官点同士での計測になります。

IMG10.png

色差を類似度に変換

色差を色の類似度として扱いたいので、色差dを1.0 〜 0 の定義域に射影する下記の関数を導入し、それを類似度S(d)とします。

IMG11.png

この関数自体はただのシグモイド関数で、係数αやバイアスΒのパラメータ値は、おおよそ下記の要件に合うように調整しています。

IMG12.png

色の類似度の計算

色差の計算方法、およびそれを類似度に変換する式を説明しましたが、もう少し具体的な例で説明したいと思います。時刻tのフレームでPersonAという人を検出、時刻t+1でPersonBという人を検出したと仮定し、これらに対し「色の類似度」を求める手順を示します。

IMG13.png

各器官点毎にL*a*b*色空間に変換した後、CIE2000色差を計算し、類似度を求めます。各器官点毎の類似度が全て求まったら、それらの平均を取り、最終的にその値をPersonAとPersonBの「色の類似度」とします。上記はその計算過程をイメージした表になります。見切れや隠れなどにより検出されなかった器官点がどちらか一方にでもある場合は、類似度50%となるようにしています。(これは、その器官点を使用しない場合に比べ、器官点1つあたりの類似度への寄与率が高くなり過ぎないようにするための措置です。)

位置の尤度

追跡中の人物は最初の検出フレームからその移動の軌跡をすべて保持しています。したがって、これまでの移動情報を基にその人物が次のフレームにいる位置をガウス分布でモデル化する事ができます。これを尤度関数とし、実際に次のフレームで人が検出されたら、その位置情報をそれぞれの尤度関数にあてはめることにより、尤もらしさを求める事ができます。ちなみに、実際のデモ映像では人に対して相対的にブレが少ない首の器官点位置を利用しています。

IMG14.png

上記は、追跡中の3人の軌跡情報を基にガウス分布でモデル化したイメージ図になります。次のフレームでの各人の予測位置は赤色で書かれている部分で、これまでの移動量が大きいほど次フレームでの予測位置は遠くに、分散は大きくなります。

総合尤度の算出

色の類似度、および位置の尤度から総合尤度を計算し、その値から同一人物の判定を行っていきます。例えば、前のフレームでPersonAとPersonBの2人を追跡しており、現在のフレームでPersonCとPersonDとPersonEの3人を検出した場合について考えてみます。

IMG15.png

前のフレームと現在のフレームで検出された全ての人の組み合わせに対し、色の類似度および位置の尤度を計算し、その積を総合尤度とします。この例では下記のようになります。

IMG16.png

これを総合尤度の高い順で並べ替え、ある閾値以下(ここでは0.02を利用)のものを除外すると下記のようになります。

IMG17.png

これを上から順に人物同定していきます。「前フレーム」欄か「現在のフレーム」欄のどちらかに既出の人物が含まれる場合、その行は無視します。これを最後の行まで行い最終的な結論を出します。この例においては下記のような結果となります。

PersonA と PersonDは同一人物である

PersonB と PersonEは同一人物である

PersonCは新たに検出された人である

これを動画の各フレームに対して連続的に行っていく事で、高精度な同一人物の再認識を実現しています。

最後に

SHIBUYA SYNAPSEの開催当日は、このブログに書かせて頂いた内容をご紹介しつつ、会場内でリアルタイムにそれを体験できるデジタルサイネージのブースも用意しました。

IMG18.JPG

発表している内容をその場で実際に体験できるという事で、参加された方々にも興味を持っていただき、非常に良い試みだったと思っています。 SHIBUYA SYNAPSEは今後も2回3回と続いていく予定なので、このブログを読んで興味を持って頂ければ幸いです。是非、次回のご参加を検討して頂ければと思います!

続きを読む
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

CVPR2017に参加してきました

はじめに

みなさんこんにちは、AIシステム部AI研究開発グループの李天琦 (@TianqiLi)です。普段は主にComputer Visionの研究開発を行っています。

DeNAのAIシステム部では、カメラの映像解析をはじめとする多くのプロジェクトでDeep Learningの技術を活用しています。Deep Learningの世界は変化が激しく、毎日追い続けても追いきれないほど日々新しい技術論文が発表されています。そこで、最新の技術トレンドをキャッチアップするため、今年(2017年)7月にハワイで開催されたConputer Visionに関するトップカンファレンスの一つである「(CVPR2017」)に参加してきました。その内容について紹介したいと思います。

cvpr2017_1.jpg

CVPRとは

CVPRの正式名称は「Computer Vision and Pattern Recognition」です。Compuer Visionというのはロボット(コンピュータ)の視覚を指し、広義では画像処理、映像処理の技術分野全般を意味しています。そのComputer Visionの分野において世界で最も権威ある学会の一つがこのCVPRです。そして近年ではDeep Learningを始めとするAI技術の飛躍的な進歩により、あらゆるComputer Vision分野でDeep Learningを使う事が当たり前になってきているので、CVPRはDeep Learningに関するトップカンファレンスの一つだとも言われるようになりました。

cvpr2017_2.png

今年の開催期間は7/21〜7/26の6日間です。初日と最終日は特定のテーマに絞って集中的に行うTutorial & Workshopが開かれました。他の4日間が、幅広い分野のセッションが行われるMain Confernceです。また、Main Conferenceの4日間では、Expoと呼ばれるスポンサー企業の展示会も並行して行われ、世界トップのIT企業たちが最新の研究成果や製品などを展示しました。

開催場所

今年の開催地はハワイのオアフ島です。海と自然に囲まれた最高のリゾート地でした。

cvpr2017_3.jpg

[ 会場のHawaii Convention Center ]

近年のDeep Learning人気の影響を受けて、CVPRの参加者は年々増加し、今年は採択論文数も参加者も過去最高でした。統計によれば、今年の投稿論文は2680本で、採択は783本でした。そして今回のCVPRの参加人数は6000人以上にものぼっています。

cvpr2017_4.jpg

[ オープニングセレモニーの様子 ]

cvpr2017_5.jpg

[ 採択論文の統計 ]

セッションの様子

CVPRに採択された論文のうち、評価の高かったものはOralやSpotlightと呼ばれるプレゼンテーション形式のセッションで発表されます。その場で大掛かりなデモを行うものもあります。それ以外は、Posterと呼ばれるセッションで展示され、質問すると論文の作者が直々に解説してくれます。

cvpr2017_6.jpg

[ Oral セッションの様子 ]

cvpr2017_7.jpg

[ Poster セッションの様子 ]

Expoの様子

Main Conferenceと並行して行われるExpoでは、各企業が独自の技術Demoを展示しています。今年最も多かったのはやはり自動運転で、TOYOTA、Tesla等の大手車メーカー以外にも、多数の自動運転ベンチャーが展示していました。

cvpr2017_8.jpg

[ Googleのリアルタイムポーズ推定のデモ ]

cvpr2017_9.jpg

[ 完全無人運転のDemo ]

cvpr2017_10.jpg

[ 無人運転の映像解析Demo ]

展示企業によっては最新の製品の販売も行っていて、今回の目玉商品はIntelが新たに販売する予定の「Movidius Neural Compute Stick」でした。これは簡単に言えばDeep Learning専用の外付け小型計算機です。これまで、Deep Learningは非常に計算コストが高いため、GPUを積んだ大型マシンが必要というのが常識でしたが、それを小型のエッジデバイス上で実現させたのがこのIntelのStickです。日本での発売予定日はまだ三ヶ月以上先ですが、今回の学会で一部の研究者向けに先行販売を行うとの事でしたので、DeNAでも研究開発用にと一部確保してきました。CVPRでも数百個しか販売されていなく半日で売り切れたので、かなり貴重です。

cvpr2017_11.jpg

[ Movidius Neural Compute Stick ]

懇親会への参加

カンファレンス期間中、毎晩のようにビーチやナイトクラブで懇親会が行われていました。そのほとんどがクローズドなもので、特定の企業のメンバーもしくは招待状を受けとった人しか参加できないようになっています。ACCV(アジア地域で開催されるComputer Visionの国際学会)のメンバーの懇親会では、AIの世界的な権威者であるTakeo Kanade先生やFei-Fei Li先生のスピーチに会場が沸きました。

cvpr2017_12.jpg

[ ACCV懇親会でのTakeo Kanade先生のスピーチ ]

注目の論文

今回CVPRで発表された論文の中で、特筆すべきものをいくつか紹介します。

- DenseNet

まず、今年のBest Paperに選ばれた2本の論文のうち、1つがこちらのDensely Connected Convolutional Networks (Gao Huang et al.)です。

cvpr2017_13.png

[ Dense blockの構成 ]

この論文が最初に発表されたのは2016年の8月頃で、当時Image-Classificationタスク(画像に映った物体の種類を分類する問題)におけるState-Of-The-ArtだったResNetのSkip Connection構造を取り入れた密な結合構造「Dense Block」を提案しています。各層の入力に、それより以前の全ての層の出力を結合した結果を使うというシンプルなネットワークアーキテクチャです。汎化性能が高く、パラメータ数の少なさと精度においてResNetを上回る性能を示しています。

- SimGAN

2本のBest Paperのうち、もう1本がこちらのLearning from Simulated and Unsupervised Images through Adversarial Training(Ashish Shrivastava et al.)です。

cvpr2017_14.jpg

[ SimGANの展示ポスター ]

こちらは、GAN(Generative Adversarial Nets)の手法を用いて、シミュレータから生成されたCGデータを現実画像に見えるように変換して、現実の画像と見分けづらくさせる手法です。そもそもなぜこれが重要かと言うと、Deep Learningの世界では訓練データの多さがそのまま計算結果の精度に直結するため、データが多くあればあるほど有利です。しかしリアルのデータを集めて、それにラベルを付けていく事は非常に大変なので、これをシミュレータから無限に生成できないかというアプローチです。シミュレータから生成された画像は通常、リアルの画像と比べてどうしても不自然さが生じますが、その不自然さをなくす事に成功したのがこちらの論文です。

Loss Functionの設計が特徴的で、シミュレータのデータにリアリズムを付与するAdversarial Lossと、元々のアノテーション情報を失わないようにするためのSelf-regularization Lossという2つのLossを定義しています。この仕組によって、一部のUnsupervisedなリアルデータさえあれば、シミュレータから無限に教師データを生成できる画期的な手法です。

- YOLO9000

今回のCVPRではBest Paperとは別に、Best Honorable mention awardという特別賞のPaperも2本ありました。そのうちの1本がこちらのYOLO9000: Better, Faster, Stronger(Joseph Redmon et al.)です。

cvpr2017_15.png

[ YOLO9000のポスターセッション ]

YOLO9000は、画像内から特定の物体の位置と種類を含めて検出する「一般物体検出」の手法に関する論文です。従来の手法よりも遥かに高速、高精度かつ多種の物体を検出できるようにしたフレームワークを提案しています。 YOLO9000自体の技術Demoも凄いですが、それ以上に今回展示されたポスターが独特すぎると話題を呼びました。通常であれば学会に出すポスターは論文の解説ポスターと相場が決まっているところを、原則を完全無視して広告的な意味でのデザインポスターを展示してくるあたり、さすがすぎるとツイッター等のSNSで一時期話題となりました。 ちなみにこちらのYOLO900の論文は、自分のほうで部分的に再現実装したYOLOv2 Chainerバージョンというリポジトリをオープンソースで公開しています。皆さん興味あればぜひ使ってみてください。

- Polygon RNN

2本の特別賞のPaperのうち、もう一本がこちらのAnnotating Object Instances with a Polygon-RNN(Lluis Castrejon et al.)です。

cvpr2017_16.png

[ Polygon-RNNのツール画面 ]

こちらの論文では、Semantic Segmentationの教師データを作る際のアノテーションコスト削減の仕組みを提案しています。通常であれば、セグメンテーション用の教師データを作るのに、物体のピクセル領域全域を細かく塗りつぶす必要があったところを、こちらの論文では複数の頂点によって構成された多角形の頂点推測問題に置き換えています。アノテーターは物体の外接矩形であるBounding Boxを与えてあげれば、RNNの仕組みで内部のオブジェクトに対して自動的に頂点候補を生成してくれます。生成された頂点がズレている場合は、アノテーターは最低限の頂点修正作業のみ行えば済みます。これによって従来の4〜7倍もの作業効率を実現できるという画期的なフレームワークです。 ちなみにアノテーション効率化に関するPaperは、このPolygon-RNN以外にもTraining object class detectors with click supervision(Dim P. Papadopoulos et al.)というのがありました。こちらは、Bounding Boxのアノテーション作業をワンクリックで行えるようにしたという画期的な手法を提案しています。

全体の感想

今年のCVPRはやはりというべきか、CNNをベースとした論文がほとんどでした。また、その多くが、計算のパイプラインを複雑化する事で高い精度を達成できたという、手法的な新規性に関するものでした。私たちの研究チームでもこれから学会に技術論文を発表していく予定なので、良い参考にはなったと思います。 今回のCVPRで発表されたOralやSpotlightのプレゼンは基本的に、こちらのYouTubeですべて動画で見られますが、実際に行ってみると論文の気になる点を作者に直に聞けたり、あとネットワーキングもできる等のメリットがあります。自分は今回がCVPR初参加でしたが、技術的な収穫はもちろん、ネットワークも広がって凄く良い刺激になりました。

cvpr2017_17.jpg

[ おまけ:Fei-Fei Liとの写真 ]

続きを読む
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

Google機械学習系API勉強会レポート

AIシステム部の奥村(@pacocat)です。AIシステム部では、AI研究開発グループに所属しており、主に強化学習を用いたゲームAIの研究開発を行っています。 DeNAでは、様々な事業ドメインのデータを実際に使いながら機械学習を使ったサービス開発を推進しており、中でもゲームは豊富なデータ・シミュレーターがあるため、最先端のアルゴリズムを動かすための環境を自前で持っているのが特徴です。

全社的にも機械学習サービスのニーズが高まっている背景の中、7/5にGoogle様による機械学習系API勉強会が当社セミナールームにて開催されました。今回は、勉強会の内容をブログでレポートしたいと思います。

Googleといえば、先日開催されたGoogle I/O 2017でも"AI first"というメッセージが改めて強調されていましたが、実際にGoogle LensやGoogle Homeなど機械学習を活用したサービス・プロダクトが次々と登場し、注目が集まっています。

[最近話題になっていた"Democratizing AI(AIの民主化)"についてなど、AI関連の取り組みについてはこちらのGoogle Cloud Next'17の動画をご覧ください]

このセミナーでは、Google Cloud, ソリューションアーキテクトの中井悦司さんにお越しいただき、

  • Googleでどのようにディープラーニングを活用しているのか
  • Google Cloud Platform(GCP)が提供する機械学習サービス
  • 機械学習のビジネス適用における考え方

といったテーマについてお話いただきました。

昨今「人工知能」を利用したビジネス期待が急激に高まっていますが、中井さんはそうした期待値と実際の機械学習ソリューション開発のギャップを適切に埋めるため、機械学習の啓蒙やGCPを使った技術支援全般を行っています。

google_ai_api2.png

セミナーの様子(100名程度の社内エンジニアが参加していました)

※以下、主にディープラーニングに関連した学習技術を含め「機械学習」という用語を使いますが、「機械学習」と「ディープラーニング」の区別が必要な場合は明示的に「ディープラーニング」と記載します。

Googleでなぜ機械学習を活用するか

そもそも、Googleではどのように機械学習が取り入れられているのでしょうか。 「1クリックで世界の情報へアクセス可能にする」という企業ミッションを耳にすることもありましたが、モバイル市場の拡大に伴い、情報へのアクセス手段もクリックに限らなくなってきました(※参考:Searching without a query)。

そうした背景のもと、音声や画像入力に対応するため、サービスを支える機械学習技術が強くなっていったのは必然的な変化だったのでしょう。実際、Googleでは様々な機械学習(特にディープラーニングを使った)技術が開発されています。セミナーでは、そうした技術の中でもホットなものを紹介していただきました。

Wavenet(DeepMind社による音声合成技術)

Wavenetは、ニューラルネットワークを使って音声のデジタルデータを直接出力するモデルです。従来の、音素に分解してつなぎ合わせるパラメトリックな手法に比べて音声生成精度が飛躍的に向上しました。いずれは、人間の発話と区別がつかなくなってくるようになるかもしれません。 また、人間の音声に限らず、楽器の音を集めてトレーニングすることで、自動作曲が出来ることも話題になりました。

google_ai_api3.png

DeepMind Technologies Limited, "Wavenet",
https://deepmind.com/blog/wavenet-generative-model-raw-audio/
(accessed: 2017-07-13)

Gmail Smart Reply

自然言語処理の分野でも新しいサービスが提供されています。現在は英語モードのGmailのみが対象となっていますが、スマホでGmailを開くとメールの文脈を理解して、返答文の候補を生成してくれるサービスです。ここにも文脈理解のためのディープラーニング技術が活用されています。
※現在はモバイルGmailアプリからの返信の20%程度で、この機能が利用されているそうです。

google_ai_api4.png

Google, "Save time with Smart Reply in Gmail",
https://www.blog.google/products/gmail/save-time-with-smart-reply-in-gmail/
(accessed: 2017-07-13)

データセンターの冷却効率改善(DeepMind社によるソリューション)

Google社内向けのソリューションも開発されています。DeepMind社は昨年、ディープラーニングと強化学習を組み合わせた技術でデータセンターの電力消費効率を最大40%削減することに成功しました。(※参考:DeepMind AI reduces energy used for cooling Google data centers by 40%
※この事例における技術の詳細は公開されていませんが、こちらに中井さんによる機械学習を使ったエネルギー効率予測についての解説があります。

他にも、Google Photosの一般物体画像認識技術など、様々な機械学習サービスが生み出されており、Google社内では機械学習のバックグラウンドを持っていないサービスエンジニアも社内トレーニングコースなどを活用して、機械学習モデルを使いこなしているそうです。

GCPが提供する機械学習サービス

さて、Googleでは一般ユーザーがこうした機械学習技術を活用できるためのサービスを提供しており、目的別に以下の二つの方向性に大別されます。

  • 学習済みモデルのAPIサービスを使う
    ⇒ ディープラーニング技術を今すぐに活用してみたい人向け
  • TensorFlowやCloud Machine Learning Engineのような環境を使って開発を行う
    ⇒ 独自モデルを作りたい人向け

google_ai_api5.png

Google社講演資料より

①学習済みモデルのAPIサービスを使う

Cloud Vision API

google_ai_api6.png

Google, "CLOUD VIDEO API",
https://cloud.google.com/vision/?hl=ja
(accessed: 2017-07-13)

Cloud Vison APIは、画像を渡すことで様々なラベル情報を取得することが出来ます。 上の例では、顔の検出だけでなく、顔が向いている方向・感情分析の結果が返ってくるAPIとなっています。

Cloud Natural Language API

Cloud Natural Language APIは、自然言語を分析するサービスです。文章の感情分析を行うことも可能で、お問い合わせメールの自動分類でカスタマーサポート業務を効率化するなど、導入事例が増えてきているそうです。

Cloud Video Intelligence API(β版)

google_ai_api7.png

Google, "CLOUD VIDEO INTELLIGENCE API",
https://cloud.google.com/video-intelligence/?hl=ja
(accessed: 2017-07-13)

現在はβ版が提供されていますが、Cloud Video Intelligence APIは、動画解析・検索が出来るサービスです。 動画のフレームを解析し、場面の切れ目を検知したり、場面ごとに何が映っているかを検出することが可能です。
※上の例では、"Elephant", "Elephants", "Animal", "African elephant"とったラベルが検出されています。

他にも様々なAPIが公開され、導入事例も増えてきているそうなので、気になる方はこちらをご覧ください。

②独自にモデルを1から作成する

上述のAPIは、既に学習が済んでいるモデルをそのまま使うパターンになりますが、自社のデータを使って独自にモデルを開発したい場合もあります。その場合は、TensorFlowのような機械学習フレームワークとCloud Machine Learning Engineのような(TensorFlowのGPU・分散学習機能に対応している)計算リソースを利用する方法があります。

③学習済みの公開モデルを利用して独自モデルを作成する

①と②を折衷したパターンです。独自モデルを作る場合、既存で提供されているAPIレベルのものを1から作るのは大変です。そこで、公開されているフレームワークや学習済みデータを活用することで独自モデルを作成する方法もあります。これは転移学習と呼ばれている手法で、既に学習されたネットワークを独自にチューニング・カスタマイズすることで、1から学習をするよりも効率的に開発が行えるメリットがあります。 セミナーでは、TensorFlow Object Detection APIを使った簡単なアプリのデモが行われていました。(※デモアプリの作成方法は、こちらの記事で公開されています。)

google_ai_api8.png

https://github.com/tensorflow/models/tree/master/object_detection
(accessed: 2017-07-13)

機械学習のビジネス適用における考え方

セミナーの後半では、機械学習を実ビジネスに適用する際、どのような点に気をつけないといけないか、リアルなプロジェクト視点で講演を行っていただきました。

まず、ディープラーニングは非構造化データ(画像・動画・音声・自然言語)に高い性能を発揮する特性がある一方で、適応領域はまだ限定的です。データが不十分だったり、まだ実証されていない事を実現する場合のハードルは高いと考えたほうがいいという話がありました。 ディープラーニングはあくまでツールの一つでしかなく、それだけで凄いサービスが作れるかというとそうではありません。あくまでビジネスの中でディープラーニングが上手くハマるところを見つけていく、という関わり方が大事という話が印象的でした。

続いて、(ディープラーニング以外の)従来の機械学習をサービスに導入する際には、データアナリストによるデータとビジネスに対する知見が必要、というポイントが紹介されました。従来の一般的な機械学習では、構造化データによる予測処理がサービス適用の中心となります。そうした予測は、一般的な統計分析(いわゆるBI)が出発点になるため、あらかじめデータを整備しサービス分析が出来ていることが前提になる、というニュアンスです。

ここで、データ分析に対する考え方を整理しましょう。データ分析のプロセスについて、次のような理解をされることがあるそうです(下図の矢印のサイクル)

  • 手元にデータが存在しており、データアナリストはそこからインサイトを得るために様々な集計や機械学習モデルの実験を繰り返す
  • そうして作られた機械学習モデルによって、未知のデータに対する予測が出来るようになる
  • データ予測がビジネスに使えないか検討する

google_ai_api9.png

Google社講演資料より

しかし、本来のゴールである「ビジネス判断」を考えると、このループを逆にたどる必要があります。

  • まず、ビジネスゴールを明確にする(一番大事な出発点)
  • ビジネスゴールを実現するために、何を予測すべきかを決める
  • 予測に必要な機械学習モデルやデータを洗い出す
  • そうしたデータを集め、分析するためにはどのような活動をしないといけないのか

当たり前じゃないかと思われる方がほとんどだと思いますが、改めて大事な視点だと感じました。

話はさらに機械学習エンジニアとビジネスのコミュニケーションにも踏み込んでいきました。 機械学習はやってみないとどれくらいの精度が出るか分からない、という不確実な要素が強い領域です。ただ、だからといって素直に「やってみないと分からない」とコミュニケーションするだけでは何も進められないのも現実です。

機械学習は実験的な要素を含んでいるんだとエンジニアとビジネスサイドで共通認識を持った上で、影響範囲を適切に見極めながら実際にサービスに機械学習を組み込んでみて、リアルに実験をしていくのが重要だというのが中井さんの主張です。そうして知見が溜まることで、機械学習をビジネスで使う勘所をサービスメンバー全体で持てるようになるのではないでしょうか。

google_ai_api10.png

Google社講演資料より

まとめ

最新の機械学習系APIの紹介から、ビジネス適用まで、様々な観点から機械学習サービスについてのエッセンスをまとめていただきました。特に後半の機械学習サービス開発の注意点については、なかなかこうした形でまとめて聞く機会も少ないので、改めて機械学習を使ったサービスについて考えるきっかけになったのではないでしょうか。AIシステム部では、様々なAI案件でビジネスメンバーと一緒にサービスをデザインして組み立てていくことが多く、機械学習に対する共通認識や社内文化の作り方など、参考になる観点が多かったように思います。

今回カバーしきれなかった内容を扱った第二回も検討されているそうなので、楽しみです!

続きを読む
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

ICLR2017読み会を開催しました

はじめに

こんにちは、AIシステム部の内田(@yu4u)です。 大分時間が経ってしまいましたが、先日、深層学習に関する論文が多数発表された国際学術会議、International Conference on Learning Representations (ICLR'17) の論文読み会をSakuraカフェにて開催したのでその報告です。 ICLRは、オープンレビューを採用しているので、リジェクトされたものも含め全ての論文およびレビューを読むことができるので、こういう読み会には丁度良いかもしれません。

ICLR'17ウェブサイト

オープンレビューサイト

読み会のConnpass

読み会のTogetter

当日の様子

IMG_3694.JPG

懇親会の様子

IMG_3708.JPG

背景

私自身はコンピュータビジョンが専門ですが、その中で利用するニューラルネットのモデルやその学習方法、モデル圧縮等に興味があり、ICLRの論文は良く読んでいました(ICLRの論文を読むというよりは、気になる論文を読んでいたらそれがICLRの論文であるケースがあるという方が正確)。

そんな折、同僚がICLRに参加するらしいということでふと調べてみると、ICLRに関しては過去国内で読み会が開催されていない (to the best of my knowledge) ことに気づき、使命感(?)から開催を企画する運びとなりました。 Twitterで発表者を募ったところ、Connpassでは発表者の募集ができないくらい多くの方に手を上げて頂けたので、当初15時くらいから開催しようかと思っていたのですが、半日フル開催というボリュームにすることができました。

感想とか

こういう勉強会の企画・運営は初めてだったのですが、会場はもとより、コーヒーブレークや懇親会まで会社的にフルバックアップしてもらえたので、スムーズに開催することができました。あとConnpassは良いサービスですね!

発表者の方々がその道のプロばっかりだったので、発表内容のクオリティが高かったのが凄かったです。当日はずっと司会だったのですが、内容がかなり学術的であることもあり、たまに質問が途切れると専門ではない内容でも質問をしなければという使命感から、学会の座長をしている気分でした。おかげで、実はコンピュータビジョンとか個別の分野よりも、こういうより抽象的なレイヤーの研究のほうが面白いのではないかと思い始めてきました。

機会があれば、またこういう勉強会は企画してみようと思います。あと、来年のICLR読み会も開催したいと思います。

当日の発表内容

以降の内容は当日の各発表の解説です。当日何となく理解したつもりになった発表も、厳密に分かっていないところもあるので、結局元の論文を読み返したりしてしまいました。専門ではない内容も多いため、間違いがあればご指摘ください!

ICLR2017紹介

[ICLR2017読み会 @ DeNA] ICLR2017紹介 from Takeru Miyato

最初の発表では、PFNの宮戸さんにICLR2017を俯瞰できるようなご講演をして頂きました。 実は大学の研究室の先輩であるPFNの @sla さんから、宮戸さんがICLRで発表されるということを聞き、ICLRという会議自体を俯瞰できるようなご講演をお願いしたところ、ご快諾頂きました。 現場の盛り上がりを感じられる内容で、ポスター会場の混み具合はもとより、夜は企業がパーティーみたいな場を設けているということで、もはやお祭りですね。 本会議の採録率は39%らしく(去年は28%)、間口を広げる方向にシフトしているのかもしれません。来年は是非発表者として参加してみたいですね。

医療データ解析界隈から見たICLR2017

医療データ解析界隈から見たICLR2017 from RIKEN, Medical Sciences Innovation Hub Program (MIH)

次に、理化学研究所の川上さんに、医療データ解析をされている立場からICLRという会議を振り返って頂きました。 川上さんは医師免許を持っておられるお医者さんでもあり、同僚の @pacocat がICLRの現地でお会いした際に読み会に興味を持って頂けたとのことで、なかなか聞けない切り口でご講演頂けるのではと思いお願いさせて頂きました。 弊社もヘルスケア事業にも力を入れており、医療領域における機械学習の活用は非常に興味があります。個人的にはパーソナライズドな医療に期待しています。 論文の実験の再現性が低いという話があり、再現しなかったからと言って直ちに間違っているということも言えないので、なかなか新しい手法が出てきて一気に変化が起こるような領域ではないのだろうと考えさせられました。 自分の分野だと、話題の手法はあっという間に再実装や追試がされていくので、対照的だと感じました。最近だと、例えばSELUs (scaled exponential linear units) という手法が話題になって、あっという間に追試された結果が色々Twitterに流れてきたのは印象的でした。

Data Noising as Smoothing in Neural Network Language Models

ICLR2017読み会 Data Noising as Smoothing in Neural Network Language Models @Dena from Takanori Nakai

@Quasi_quant2010 さんのご発表。 これまでn-gramを用いた言語モデル (language modeling) では、Kneser-Neyに代表されるスムージングが非常に重要な役割を果たしていた。他方、RNNによる言語モデルでは、単語(列)の頻度を明示的に扱っているわけではないので、そのようなスムージングを直接的に行うことはできなかった。 そこで、n-gramから導出される確率を利用して、RNN言語モデルを学習する訓練データに対し、単語を置き換えたりするノイズを加えることで、スムージングと同様の正則化を実現することを提案し、経験的にperplexityが低下することを示した。

レビューでも経験的と言われていますが、アイディアは面白いですね。画像でいうと、ちょっと賢いData Augmentationをしているようなイメージでしょうか。 ちなみにKneserの発音は「k N AI z uh r」らしいです。

http://d.hatena.ne.jp/tkng/20100426/1272266900

On Large-Batch Training for Deep Learning: Generalization Gap and Sharp Minima

170614 iclr reading-public from Katsuhiko Ishiguro

石黒さん(みらい翻訳/NTTドコモ)のご発表。 DNNは多数のlocal minimumがあり、それらの局所解はどれもglobal minimumと遜色ないと言われている。この論文では、そのlocal minimumにはsharp minimumとflat minimumがあり、大きなバッチサイズを使うとsharp minimumに、小さなバッチサイズを使うとflat minimumに収束すると主張している。 Flat minimumは、局所解から多少パラメータを変動させても、ロスがあまり増加しないような局所解であり、訓練データとテストデータの分布の違いによりロス関数がずれたとしても、あまり精度が変わらない汎化された理想的な局所解と定義される。

大きいバッチサイズと小さいバッチサイズそれぞれで得られたパラメータを結ぶ直線上にあるパラメータを内挿・外挿により求め、ロスを算出することで、sharp minimumとflat minimumを可視化しているのが面白く、説得力があります。 ちなみにその後、バッチサイズの大小ではなく、SGDのパラメータ更新回数こそが重要であるという主張の論文が出ています。

論文:https://arxiv.org/abs/1705.0874

解説:https://www.slideshare.net/JiroNishitoba/20170629

Q-Prop: Sample-Efficient Policy Gradient with An Off-Policy Critic

Q prop from Reiji Hatsugai

@Reiji_Hatsu さんのご発表。 強化学習において最適な方策を見つける手法は、直接方策をモデル化する方策ベースの手法と、状態の価値をモデル化する価値ベースの手法に大別できる。 方策ベースの手法は、現在推定している方策と学習に利用しているサンプルが同じである方策オン型であり、安定した学習が可能である一方、方策がアップデートされるとこれまでの学習サンプルが利用できないためサンプル効率が悪い。 価値ベースの手法(Q学習)は、常に価値が最大となる方策を選択するため、サンプルの方策とは異なる方策に基づく方策オフ型である。このため、任意の方策でサンプリングされたデータで学習できる一方、学習が安定しない、複数ステップ法への拡張が難しいという問題がある。 この論文では、これらの手法のいいとこ取りをするというのがポイントである。具体的には、方策勾配の関数に、criticのTaylor展開したものを加えて数式コネコネすると、actor-criticの手法に似たアップデートの式が出てきて、criticが方策オフ型で学習できるようになる。

何となく雰囲気は分かるが、導出がトリッキーなので、時間があるときにAppendix Aの数式を追ってみたいです。上記のいいとこ取りという観点では、同じくICLR'17に下記のような論文もあります。 PGQ: Combining Policy Gradient And Q-learning

論文:https://arxiv.org/abs/1611.01626

解説:https://www.slideshare.net/sotetsukoyamada/pgq-combining-policy-gradient-and-qlearning

Tying Word Vectors and Word Classifiers: A Loss Framework for Language Modeling

言葉のもつ広がりを、モデルの学習に活かそう -one-hot to distribution in language modeling- from Takahiro Kubo

@icoxfog417 さんのご発表。 機械学習である単語を表現する場合には、その単語のIDに該当する次元が1でそれ以外が0となるone-hotなベクトルが利用される。学習時のロスもこのone-hotなベクトルをベースに計算されるので、推論結果が、正解の単語とほぼ同じような単語であろうと全く違う単語であろうと同じロスが発生する。 本論文では、これに対し、単語間の類似度に基づき、正解をone-hotではなく広がりのある分布として表現し、その分布を用いてロスを計算することを提案している。 具体的には、元々のone-hotのベクトルと、単語の埋め込みベクトル間の内積により算出される類似度をsoftmax通すことで作られるベクトルの重み付き和により、この広がりのある分布を定義している。 また、one-hotのベクトルをdenseなベクトルにする埋め込み行列Lについても、出力時の射影Wと本質的に対応しているべきであり、それらを個別に学習しないような手法を提案している。具体的には、LがWの転置であるという制約を導入している。

読み会では、LとWの対応について逆行列で求めているのかという質問がありましたが、フルランクではないのでどのようにしているのかと思いましたが、論文を読むと上記のように転置であるという制約を入れているようです。

Stochastic Neural Networks for Hierarchical Reinforcement Learning

ICLR読み会 奥村純 20170617 from Jun Okumura

奥村さん(DeNA)のご発表。 迷路を解くような問題では、報酬がゴールにたどり着いた時にしか発生しない(報酬がsparse)。このようなケースでは、探索時にゴールに全く辿り着かずに学習が進まないという問題がある。これに対し、中間的なタスクを設定し、そこで汎用的なスキルを身に付けさせることで、報酬がsparseである問題を解決しつつ、身につけた汎用的なスキルを他の問題にも適用できるようにできれば嬉しいよねという問題提起。 本論文では、迷路を解く問題に対し、取り敢えず移動するというタスク(蛇のような関節モデルを想定しており、移動すらランダムだと難しい)を設定し、更に様々な方向に移動する多様性もあるように学習させるために、確率的ニューラルネットの利用と、色々な動きをした際に報酬にボーナスを与える相互情報量ボーナスを導入している。

やっていることは理解できるのですが、背景でなるべく中間タスクはhandcraftedにならないようにと言っている割に、えらくタスクに依存する手法となっているのがちょっとモヤモヤします。

Optimization as a Model for Few-Shot Learning

Optimization as a Model for Few-Shot Learning - ICLR 2017 reading seminar from Hokuto Kagaya

@_hokkun_さんのご発表。 Deep learningは大量の訓練データが存在する場合には威力を発揮するが、例えば鳥というクラスの中で細かい鳥の種類を分類するようなfine-grainedなタスクなどにおいて、各クラスに十分な訓練データが準備できないケース(few-shot learning)がある。そのようなケースでも高精度な認識をするための手法。 SGDの更新式ってLSTMのセルの更新式に似ているよねという発想から、SGDのパラメータの更新の方法をLSTMで学習するというメタ学習を提案している。

枠組みとしては通常の学習でも活用できそうな気がしますが、自動的にドメイン特化した更新式を獲得する枠組みがポイントなので、ドメインが決まっている通常の学習では単に学習率とかを色々単純に試したほうが良いかもしれません。 つまり、問題設定として、メタ学習データでメタ学習を行い、メタテストデータで先ほど獲得した学習方法を利用して学習を行う(ややこしいがメタテストデータに学習データとテストデータがさらに存在する)という前提があり、そもそも学習データで学習率を調整できない(ドメインが変わるので意味がない)のでこのようなアプローチが重要になるのだと思います。

Autoencoding Variational Inference for Topic Models

@nzw0301 さんのご発表。 Latent Dirichlet Allocation (LDA) をNeural Variational Inference (NVI) で行う(明示的にDirichlet分布は利用していないのでLDAと言うのは語弊がある?)。VAEではガウス分布のパラメータをニューラルネットが出力し、そのガウス分布からサンプルを生成する。この際、backpropができるような計算グラフを構築するreparameterization trickを利用する。LDAでは、ディリクレ分布のパラメータを生成し、多項分布(トピック分布)を生成したいが、そのままでは上記のtrickは利用できない。そこで、事後分布をガウス分布で近似するLaplace近似を利用し、ガウス分布からのサンプルにsoftmax(σ())を適用することで、多項分布をサンプルすることを可能とする。 上記のトピック分布θとトピック毎の単語生成確率行列σ(β)との積によって、最終的な文書の単語分布が得られる。ここで、σ(β)は、トピック毎の多項分布であり、最終的な単語分布はそれらのθによる重み付き和となる。このようなケースでは、生成される単語分布は、トピック毎の単語分布よりシャープにならず、幾つかのトピックにおいて主観品質の悪い結果をもたらすことがある。これに対し、本論文では、得られる単語分布をσ(βθ)とするProdLDAを提案している。この場合、βは多項分布であるような正規化がされていないため、上記の問題を解決できるとしている。また、学習方法もBNとDropoutを利用するなど工夫しているらしい。

とても勉強になりました。σ(βθ)としてしまうのは乱暴なようだけど、この定式化でもσ(β)はちゃんとトピック毎の単語性生成行列になるのですね。下記の論文のように、reparameterization trickにもいろいろな種類があって面白いです。

https://arxiv.org/abs/1611.00712

Variational Lossy AutoEncoder

@crcrpar さんのご発表。 VAEでは、潜在変数の事前分布p(z)を正規分布に、事後分布p(z|x)をガウス分布とすることが多い。このような単純な分布は表現能力が低く、真の事後分布にうまくfitしない問題が発生する。この問題に対し、Normalizing Flow、Inverse Autoregressive Flow (IAF) といった、より複雑な事後分布を生成できる手法が提案されている。これらの手法では、単純な分布を徐々に複雑な分布にする可逆変換を利用している。本論文では、IAFで事後分布を複雑な分布にするのではなく、Autoregressive Flow (AF) を用いて事前分布を複雑な分布にすることを提案し、AF事前確率とIAF事後確率のエンコーダ処理は同一であることを示した。

AFを事前確率に入れるほうがIAFを事後確率に入れるより表現能力が高いという主張が良く分かりませんでした。事前知識が足りず、normalizing flow辺りの論文から理解しないといけないですね。

Semi-Supervised Classification with Graph Convolutional Networks

Semi-Supervised Classification with Graph Convolutional Networks @ICLR2017読み会 from 英爾 関谷

関谷さん(DeNA)のご発表。 隣接行列で表現される重み付き無向グラフが与えられ、各ノードには特徴信号が紐付いている。一部ノードにはクラスラベルも付いており、残りのノードにはクラスラベルは付いていない。このような前提で、クラスラベルの付いていないノードのクラス分類を行う、graph-based semi-supervised learningの問題をグラフ畳み込みネットワークで解く手法。 グラフに対する畳み込みは、各ノードの特徴信号を並べたベクトルに対し、グラフラプラシアンの固有ベクトル行列を利用してグラフフーリエ変換を行うことでフーリエドメインに変換し、そこで畳み込みカーネルとの要素積を行い、最後に逆フーリエ変換する処理として定義される。 上記の処理は行列演算と固有値分解の計算量が大きいため、畳み込みカーネルをグラフラプラシアンの固有値の関数と定義し、1次までのチェビシェフ近似を用いることでノード数に線形なグラフ畳み込みを行うことを提案している。

チェビシェフ近似の辺りから、何でそれで良いのか理解が難しいです。ちなみに特徴ベクトルは独立に周波数ドメインに変換されて畳み込みが行われるようですが、次元間の関係をうまく捉えるような拡張とかできないかな、と思いました。

続きを読む
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

DeNA TechCon 2017 開催レポート【2】

こんにちは。ゲーム事業本部開発基盤部の池田です。

去る2月10日、DeNAは技術カンファレンス「DeNA TechCon2017」を開催しました。
公開可能な資料については、公式サイトのスケジュール画面からリンクしておりますので、まだチェックしていないという方は是非ご覧ください。
追って、各セッションの動画もアップ予定です。

本記事は、この「DeNA TechCon2017」振り返り記事の第2弾となります。

今回は特に、DeNAの新たなチャレンジ領域である AI 分野について、Aステージで筆者が聴講した以下の3講演について取り上げます:

  • 基調講演:「実世界の人工知能」株式会社Preferred Networks岡野原大輔様
  • 「強化学習を利用した自律型GameAIの取り組み〜高速自動プレイによるステージ設計支援〜」MASHIKO RYOSUKE, SEKIYA EIJI
  • 「DeNA AIシステム部におけるクラウドを活用した機械学習基盤の構築」SEO NAOTOSHI

基調講演―実世界の人工知能

基調講演では、株式会社Preferred Networks岡野原大輔氏が登壇しました。

DSC_6045.jpg

講演の前半では、畳み込みニューラルネットワークが近年の研究でどのように複雑に進化し、ディープラーニング(深層学習)と呼ばれるようになったかを解説しました。
深層学習で使われる畳み込みニューラルネットワークでは、ネットワークの層数やニューロン数が、それまでのものより桁違いに多くなっています。

この深層ニューラルネットワークが、現在、様々な分野で応用されつつあります。

講演では、応用分野として「自動車」「ロボット」「異常検知」「バイオ・ヘルスケア」「コミュニケーション」「クリエーター」といった分野における取り組みについて取り上げられました。

特に、「クリエーター」分野においては、線画にいい感じに着色する PaintsChainer が最近インターネットなどで話題になったことは、記憶に新しいのではないでしょうか。

結びとしては、深層学習・教科学習の進化は著しく、研究段階から実用化・ビジネス化チームが付き添うことが大事と締め括られました。

強化学習を利用した自律型GameAIの取り組み〜高速自動プレイによるステージ設計支援〜

こちらのセッションは前半・後半の2部構成でした。

前半では、強化学習そのものについてAIシステム部SEKIYA EIJIが発表しました。
まず、強化学習の仕組みについて簡単な解説をした後、2014年に登場した新手法であるDeep Q-Networksの概要を示しました。
次に、強化学習に関する最新の動向として、NIPS 2016で発表されたDeepMind LabやOpenAI Universeなどについて取り上げました。

後半では、強化学習の利用例として、FINAL FANTASY Record Keeperにおける自律型GameAIの活用事例について、同じくAIシステム部のMASHIKO RYOSUKEが発表しました。

DSC_6525.jpg

FINAL FANTASY Record Keeperでは、ボスのパラメータ調整を行うため、バトルを自動プレイするAIに対するニーズがありました。

このバトルAIの行動決定アルゴリズムとして、探索的アプローチであるMonte Carlo Tree Searchと、ニューラルネットを用いたアプローチであるNEAT, Q-learningを適用した結果が比較解説されました。
結果として、ニューラルネットを用いた方法において、学習時間が掛かるなど課題はあるものの、人がプレイする場合と遜色ないレベルでの勝率を達成することができました。

講演の最後では、ゲームへのAI活用のポイントとして、ゲームシステムの設計段階でどこまでAIを利用するか考慮し、シミュレータやデータ形式を用意しておくことの重要性が挙げられました。

DeNA AIシステム部におけるクラウドを活用した機械学習基盤の構築

AIシステム部のSEO NAOTOSHIは、DeNAにおけるクラウドを活用した機械学習システム基盤の構築について発表しました。

DSC_6743.jpg

DeNAの機械学習システムのインフラ面においては、「潤沢なGPU」「隔離された環境」「素早い構築」「運用が楽」「自由度を高く」「ミスが起きにくい」という6つの要素が求められていました。
本発表では、これらの要素一つひとつを達成するために、AWSやGCPを活用したインフラ環境の構築方法について示しました。
例えば、「素早い構築」については、TerraformやItamaeといったツールを活用し、AWS, GCPの両方に対応した環境構築をコード化していることが語られました。

発表の後半には、GPU学習環境をオンデマンドでスケールさせるために整備したツールや、APIサービス環境の構成が取り上げられました。
GPU環境をスケールさせるための内製ツール「ec2-scale-run」の中ではDockerが活用されています。このツールでは、使われなくなったインスタンスを再利用し、また不要になったら確実にシャットダウンする仕組みがあることが説明されました。

結びに

本記事を通して、DeNAがAI分野においてどのようなチャレンジ・取り組みをしているか、少しでも伝われば幸いに思います。

余談ですが、Aステージの講演では社員によるグラフィックレコーディングがリアルタイムに行われ、完成したものは展示スペースに貼り出されました。

下の写真は、基調講演のグラフィックレコードとなります。

CR9A7145.jpg

次回の記事でも引き続き、発表されたセッションの模様を紹介していく予定です。
お楽しみに!

続きを読む
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る