いっしきまさひこBLOG

AI・機械学習関連、Web制作関連、プログラミング関連、旅行記録などなど。一色政彦。

AIと機械学習を成功させる「DataRobot」無料ハンズオン!! #NSStudy 15 聴講ノート

※これはセミナー聴講時の個人的なノートをそのまま公開したものです。誤字誤植や勘違いがある可能性があるのでご了承ください。

AIと機械学習を成功させる「DataRobot」無料ハンズオン!! #NSStudy 15 - connpass

19:05~19:35 (1) DataRobotプラットフォーム概要紹介(DataRobot Japan株式会社 中山 晴之 氏)

データサイエンティスト不足には、AIの民主化しかない

  • 「年25万人、政府戦略」というニュース記事が2019年3月に配信された
    • 年25万人?! 4年制大学の理工系12万人しかいない。それ以外の文系42万人なども含めて、データサイエンティストという話だが非現実的
  • データサイエンティストってどんな人?
    • ドメイン知識、IT技術、数学・統計学、といっ知識・スキルが必要
      • 例えば、Python関連、R言語の勉強など
      • どうやって出店場所を決めているかなどのドメイン知識も不可欠
    • 統計学、プログラミング、アルゴリズム、ドメイン知識(実務知識や実践経験)を学ぶ必要があり、途中で脱落していく
  • データサイエンティストはどれくらい需要があるか?
    • ありとあらゆる業種・分野でAIは使われている
    • 需要は増えているのに、人材供給をすぐには伸ばせない。需給にギャップがある
  • だからAIの民主化しかない
    • 方法1: 既存のデータサイエンティストの生産性を大幅に増やす
    • 方法2: 普通の人がデータサイエンティスト並みの能力を発揮できるようにする
  • AIは「ブラックボックス」だから、怖くて使えない?!
  • そこでDataRobot
    • グレーボックス化技術がある
    • Kaggler上位入賞者がDataRobotを開発している
    • 今ではあらゆる分野で使われており事例がたくさんある
    • (売れすぎてDataRobotに人が足りない)

19:45~20:30 (2) DataRobotハンズオン (DataRobot Japan株式会社 中山 晴之 氏)

後半はとても眠くてあまりちゃんと書けてないです。

f:id:misshiki:20190704231806p:plain
貸し倒れ確率

  • ドラッグ&ドロップでデータを投入すると、探索的データ解析が自動的に行われ、終わると「ターゲットを選択」と表示される

f:id:misshiki:20190704231853p:plain
ドラッグ&ドロップでデータを投入

  • 「LCData_JP_train.xlsxを精査」をクリックするか、スクロールダウンすると、分析済みの内容一覧が表示される

f:id:misshiki:20190704231936p:plain
「LCData_JP_train.xlsxを精査」をクリック

f:id:misshiki:20190704232025p:plain
分析済みの内容一覧が表示される

  • 例えば「ローン額」をクリックするとヒストグラムが表示される
  • 「ID」や「メンバーID」には「リファレンスID」と表示されており、これは特徴として使えないことが認識されている
  • 他には「申し込みタイプ」は「値が少ない」と表示され、これも特徴としては自動的に使われないことを示している
  • 「ターゲットを選択」をクリックすると、「何を予測しますか?」欄に入力できるようになる。今回は「貸し倒れ(率)」を予測する

f:id:misshiki:20190704232204p:plain
「何を予測しますか?」欄に入力

  • 「開始」ボタンを実行すると、モデルの作成が始まる

f:id:misshiki:20190704232528p:plain
モデルの作成が始まる

  • DataRobotには2000ぐらいのアルゴリズムがあるが、その中から適切なものを選びだして、30~70個ぐらいのモデルを自動的に作る
  • 30個ぐらい作るのは、事前にどれがよいか分からないので、テストで精度が最も良いものを選びだす
  • Kaggleで良い成績を出しているアンサンブル学習=「Blender」と書かれているモデル。これも自動的にやってくれる
  • 右上のワーカーを増やして処理を速めることもできる

f:id:misshiki:20190704232616p:plain
モデルの作成が完了

  • 「モデル」タブで、作成済みのモデルが精度順に並ぶので、一番上のものを使うには、まず★(お気に入り)を付ける

f:id:misshiki:20190704232726p:plain
★(お気に入り)をフォルターできる

  • モデルの説明や解釈を見る: 「解釈」→「特徴量のインパクトを計算」→「特徴量ごとの作用」→「特徴量ごとの作用を計算する」

f:id:misshiki:20190704233157p:plain
特徴量ごとの作用を計算する

f:id:misshiki:20190704233228p:plain
特徴量ごとの作用(1)

f:id:misshiki:20190704233249p:plain
特徴量ごとの作用(2)

f:id:misshiki:20190704233305p:plain
特徴量ごとの作用(3)

  • アルゴリズムによって、必要があればOne-hotエンコーディングも自動的に行う
  • 特徴量はいくつでも受け入れるが、特徴量を絞った方が良い結果が出ることが多い
  • △が出ている特徴量は削った方がいい。それには「特徴量セットを作成」を実行

f:id:misshiki:20190704233413p:plain
特徴量のインパクトを計算

f:id:misshiki:20190704233450p:plain
特徴量のインパクト

f:id:misshiki:20190704233505p:plain
△が出ている特徴量は削った方がいい

f:id:misshiki:20190704233528p:plain
特徴量セットを作成

  • インサイト、ワードクラウド、=どういう文字があると貸倒しやすいかなどを明示

f:id:misshiki:20190704233025p:plain
インサイト

f:id:misshiki:20190704233042p:plain
ワードクラウド

  • モデル、速度対精度、=アンサンブル学習は精度がよいが時間はかかる

f:id:misshiki:20190704232901p:plain
速度対精度

  • モデル、学習曲線、=16%ぐらいで予選、32%ぐらいで再予選、、64%ぐらいで決勝戦
  • 予測タブ、LCData_JP_10rowsデータ(貸し倒れの項目が空)を投入。『予測を計算』、ダウンロード

  • デプロイ

f:id:misshiki:20190704233700p:plain
新規デプロイを追加

f:id:misshiki:20190704233732p:plain
モデルをデプロイ

  • バッチ予測

f:id:misshiki:20190704233840p:plain
バッチ予測

  • 予測の説明

f:id:misshiki:20190704234024p:plain
予測の説明(1)

f:id:misshiki:20190704234040p:plain
予測の説明(2)

  • 説明:ブループリント

f:id:misshiki:20190704234219p:plain
説明:ブループリント

Amazon SageMaker 事例祭り(2019 年 4 月 17 日開催) 聴講ノート

※これはセミナー聴講時の個人的なノートをそのまま公開したものです。誤字誤植や勘違いがある可能性があるのでご了承ください。

Amazon SageMaker 事例祭り(2019 年 4 月 17 日開催)

13:45~14:30 Amazon SageMaker の基礎 (アマゾン ウェブサービス ジャパン株式会社 ソリューションアーキテクト 鮫島 正樹)

  • 典型的には「開発と学習(データサイエンティスト)」「推論(エンジニア)」というプロセスがある
  • 「開発と学習」の課題:
    • 環境構築が大変
    • 複数の学習ジョブを並列で実行するのが大変
    • 複数マシンを使った分散学習を実現するのが大変
    • 学習結果を管理するのが大変
  • 「推論」の課題:
    • 推論用のAPIサーバー構築とメンテが大変
    • エッジデバイスへのデプロイが大変
    • バッチ推論の仕組みを作るのが大変
  • そこでSageMaker:
    • 数分で開発環境を起動できる
    • 学習・推論環境は柔軟にスケール
    • 多数のAPIを提供
    • 東京を含む13リージョン
    • SDKはオープンソース
  • SageMakerのメリット:
    • 開発・学習・推論は個別に利用可能
    • 開発: ノートブックインスタンスは数分で起動できる。主要ライブラリはインストール済み
    • 学習: 開発と学習は分離。複数ジョブを同時実行。分散学習可能
    • 推論:APIを叩くだけ。オートスケーリングやA/Bテスト機能もある
    • インフラ管理を気にせずに、すぐに機械学習を始められる
    • さまざまなワークフローを加速させられる
    • オープンソースなので、オンプレミスで利用することも一部だけ利用することも可能
  • 開発: マネージドなノートブックインスタンス
    • 上記の特徴
    • 異なるインスタンスを組み合わせられる
    • 複数人の開発でもコードの管理が簡単
  • 学習: 分散学習と複数ジョブ同時実行
    • 上記の特徴
    • 学習が完了すると自動でインスタンスが止まる
  • 推論:APIエンドポイントやバッチ推論
    • 上記の特徴
    • 推論の負荷に合わせてGPUを適用できる機能「Elastic Inference」もある
  • SageMakerの事例:
    • 事例:Delyの料理レシピ動画のリコメンデーション
    • 事例;SmartNewsのニュースキュレーション
    • 事例;GE Healthcareの医師診断支援
  • SageMakerで必要なもの:
    • 学習データ:
      • 「Amazon S3」に置く
    • 機械学習のコード:
      • 「SageMeker」特有の書き方があるわけではなく通常どおりでよい
      • 気を付けるのは、S3とのファイル入出力とコンテナイメージに合わせた動作定義が必要
    • 実行環境(コンテナ):
      • 「Amazon ECR」にコンテナイメージを置く
  • インスタンスは3種類がある:
    • ノートブックインスタンス(開発用。学習データはS3から読み込む):
      • 16TBまでのディスクをアタッチ可能
      • Pandas標準インスタンス
      • EMRを呼び出すことも可能
    • 学習用インスタンス(自動的に停止して削除される。モデルはS3に格納される):
      • ビルトインアルゴリズム(画像、数値・系列解析、自然言語処理、レコメンデーション、汎用系)を使用可能
      • AWS Marketplace for Machine Learning(AWS Marketplace: Search Results
    • 推論用インスタンス(エンドポイント経由でS3にあるモデルを使う):
      • リアルタイム推論: deploy()関数を呼ぶだけでエンドポイントを構築できる
      • バッチ変換ジョブ(バッチ推論): リアルタイムではないが常時立ち上げなくてよいのでコスパがよい
  • SageMakerのデモ
  • SageMaker Example Notebooks:
  • SageMaker SDK:
  • SageMaker公式ドキュメント:

14:30~15:15 Amazon SageMaker Ground Truth の使い方(アマゾン ウェブサービス ジャパン株式会社 ソリューションアーキテクト 針原 佳貴)

  • データにラベル(Ground Truth)を付けるためのアノテーション支援ツール
  • Amazon SageMaker Ground Truth | AWS
  • 教師あり学習:
    • 予測値とラベル(Ground Truth)の比較
    • アノテーション(ラベル付け)が必要
  • ラベル付けの難しさ: 大規模データセットが必要。人間が行う。精度が必要。時間もお金もかかる。ツールの準備(ユーザーを集めて認証、UI、進捗管理)
  • そこでAmazon SageMaker Ground Truth:
    • 一般的なワークフローをサポート
      • AWS Lambdaを使うなどのカスタムラベルのワークフロー
    • 4種類のラベリングツールを提供
      • 画像分離、物体検出、セマンティックセグメンテーション、文章分類、さらにカスタムジョブも可能
    • アノテーションをするワーカー(人、以下の3種類)との連携・管理機能を提供
      • パブリックワーカー: Amazon Mechanial Turkで24時間365日、50万人の労働力(※日本人ではない)
      • プライベートワーカー: 社員などを登録。データは組織内にとどまる。ワーカー管理はCognitoを利用
      • ベンダーワーカー: AWS Marketplace登録済みのサードパーティベンダーに依頼
    • 大規模データセットに対して自動ラベリング(通常は70%のコストカットにつながる)
      • アクティブラーニングと自動データラベリング: 信頼度が低いデータは人間がアノテーションする。人がラベル付けしたデータからアクティブラーニングのモデルを作成
        • アクティブラーニング=人によりラベル付けされるべきデータと機械がラベル付けできるデータを特定する手法(機械学習のテクニック)
  • Amazon SageMaker Ground Truth の事例は多岐に渡る
  • 価格: 利用料$0.08/個
  • 提供リージョン: 東京あり
  • 4つの利用ステップ:
    • データセットの準備: S3バスケットを用意。アノテーション対象の画像やText/CSVファイルを格納。入力用のマニフェストファイル(input.manifest)で"source-ref"にS3のパスを指定(もしくは"source"に直接テキストを書くこともできる)
      • ジョブ名、入力データセットの場所(入力用のマニフェストファイルを指定)、出力データセットの場所(ディレクトリパスを指定)、IAMロールなどを設定する
        • 出力ディレクトリに生成されるマニフェストファイル(拡張マニフェストファイル:output.manifest)
    • タスクの定義: 画像分離、物体検出、セマンティックセグメンテーション、文章分類のいずれかを選択。もしくはカスタムジョブ
    • ワーカーの選択: パブリック、プライベート、ベンダーのいずれかを選択
    • ラベリングツールの設定: アノテーションの指示書を書く。良い例・悪い例を記載。ラベルを設定
  • object_detection_tutorial.ipynbファイルにAmazon SageMaker Ground Truth で鳥のラベル付けのデモがある:
  • SageMaker Ground Truth公式ドキュメント:

15:45~17:15 Amazon SageMaker 事例発表

「Diversity Insight for Retail」でのSageMaker導入と今後(GMOクラウド株式会社 プロダクトマネージャー 山下久知 様)

  • GMO Cloudには「IoTの窓口」というAI・IoT事業がある
  • SageMakerを利用したSaaSプロダクト「Diversity Insight for Retail」の紹介:
  • SageMakerを導入した理由:
    • 3つのメリット: 簡単にエンドポイントを立てられる、マネージドサービスが良い、スケーラビリティとコストのバランスが良い
  • SageMakerを導入後の課題:
    • もっとコストを下げたい: → 解決策:軽量モデル化によってコストダウン(PyTorchを使って高速化)
    • 推論コストが積み上げって、高負荷になりタイムアウト: → 解決策:インスタンスをスケールアップさせる
      • メモリ不足、コア不足、レイテンシの課題: 推論リクエスト件数の多さ(1画面あたり100万件の推論実行)
      • 見える化(グラフ描画)するコスト
      • など
    • Pythonが遅い: → 解決案:C++やJuliaなど高速な言語に対応したい
  • 軽量化・高速化:
    • バッチトランスフォーム化: バッチ推論する方式に変更
    • エッジの比重を増やす: Jetson Nanoを使うことでエッジ推論の性能や比重を上げたい
  • 非Python化:
    • Julia/C++/MKL-DNNなどで高速推論化していきたい。Pythonと比べると数十倍の差が出ている状況
  • まとめ:
    • SageMakerを利用することで、APIをスピーディに開発できるが、性能チューニングやアーキテクチャ選別などの工夫は結構な工数が必要

「えっ、なぜSageMakerなの?」(株式会社オークネット・アイビーエス ジェネラルマネージャー 黒柳 為之 様)

  • 2017年「KONPEKI」、2018「EDIS」が、書籍でケーススタディとして紹介された
  • 「AUCNET IBS」における画像認識AIの取り組み事例:
    • EDIS
    • SODAI Vision API
    • Andy Photo Book
    • KONPEKI
  • SODAI Vision API:
    • 粗大ごみかどうかを判定して返すAI(LINEで試せる)
    • AWS Lambda、SageMaker、など
      • いかに管理コストを下げ、スピードを上げるか、という理由から使った
  • Andy Photo Book:
    • 大量の写真から笑顔をピックアップするAI
    • 卒業アルバム制作大手の株式会社イシクラと連携して開発
    • AWS Lambda、SageMaker、Rekognition、など
      • SageMakerを使うことでRekognitionのコストを下げた(1/200まで下げられた)
  • サービス用プラットフォーム「Hanzo」:
    • Hanzoはサービスのゲートウェイとなっている
    • EDIS、Photo Book、KOPEKIといったサービスにアクセスできる
  • これまでのAI開発の歴史:
    • 2016年: 仮想マシン+TensorFlow
      • APIなど自前でいろんなことをする必要があり、コストと時間がかかった
    • 2017年: EC2インスタンス+TensorFlow+Keras
      • インスタンスを自前で管理していたので、大変だった(運用コスト)
    • 2018年: SageMaker+Keras
      • 自前ではなくて、利用しやすいAPIを使うだけになった。インスタンス管理も自動。コストと時間を大幅に節約できた
      • アプリケーション化が容易になった。試行回数が増えて、モデルの精度向上につながった
  • SageMakerの欠点:
    • デフォルトで用意されている組み込みアルゴリズムをより汎用的にしてほしい(例えば、画像分類用はResNetだけ、画像の増加パラメーターが指定できなかったなど)
    • インスタンスの起動やデータのダウンロード進捗状況が詳細に欲しい(いつ終わるかは時間を見るくらいしかできない)

「不適切コンテンツ検出」の機械化と安定運用(株式会社 ミクシィ Vantageスタジオ mixi事業部 岩瀬靖彦 様)

  • 「機械学習による不適切コンテンツ検出」の実装と成果 – mixi developers – Medium をベースにした話
  • 「健全性の維持」のために:
    • 不適切投稿の一例「お金ちょうだい」など: 犯罪行為など社会に大きな影響を与えかねない事例があるため、監視する必要がある
    • 機械化による負荷軽減。危険度を判定するモデルを作成する
  • 成果:
    • 監視対象の80%以上の判断を機械に任せられるようになった。残った20%は人間が目視によって判断する
  • 危険度判定モデル(言語処理の例):
    • 短文/長文/画像といった投稿種類に合わせたモデル(二値分類)を作成
    • Amazon S3、ECS、ECR、SageMakerなどを使用。SageMakerによって一元管理されている
    • 前処理: 生データとなる文章群を加工成形してS3に格納
    • 学習: S3からデータセットを取り出してモデルを作成
    • 推論: エンドポイントを生成。API GatewayとLambdaを経由させてREST APIとする
    • 運用フローへの組み込み: 既存の投壺監視フローに先ほどのAPIを導入した
  • 細かな部分のアーキテクチャ解説:
    • カスタムアルゴリズム: 例えばコンテナ内で日本語処理したい場合(N-gramならカスタマイズ不要だが形態素解析なら必要)は独自コンテナが必要になる
    • 定期実行タスク: 新しいデータを加えて定期的に更新したい需要がある。cron起動させたいが、スポット利用でよい。
      • → ECS Scheduled Task を使用。AWS Batch & CloudWatch Eventsなどの組み合わせも選択肢になる

PyData.Tokyo Meetup #19 SysML 聴講ノート

※これはセミナー聴講時の個人的なノートをそのまま公開したものです。誤字誤植や勘違いがある可能性があるのでご了承ください。

PyData.Tokyo Meetup #19 SysML - connpass

19:20 - 19:30 「PyData.Tokyoについて」 PyData.Tokyo オーガナイザー

  • Python+Dataをテーマにしたコミュニティ
  • 世界のPyDataコミュニティにつながることを目指している

19:30 - 20:10 データサイエンティストが力を発揮できるアジャイルデータ活用基盤 @suganuma-koji, @tmshn

  • 基盤を作ったり運用したりがメインの仕事
  • リクルートのビジネスモデル「リボンモデル」 =クライアントとユーザーを結び付けるマッチングプラットフォーム
  • ユーザーにリアルタイムで宿をレコメンドするデモ:
    • 閲覧しているページに基づいてレコメントする宿を表示する
  • 機械学習部分:
    • Embedding: Item Embedding by word2vecで処理
  • データプロダクトのライフサイクル:
    • 知見を溜めるため、コンパクトにイテレーションを回すことが必要
    • それには幅広い技能が必要
    • コミュニケーションコストや工数の問題でイテレーションが遅くなる
  • そこで、さまざまなデータ活用案件に柔軟に応用可能なプラットフォームを用意
    • エンジニアによる都度開発を最小限に抑えて、スムーズなイテレーションを実現する
  • APIの世界:
    • Hacci API: ユーザー行動ログをブラウザからリアルタイムに取得し連携するAPI
    • 汎用API: 任意のキーバリューを設定できるAPI。Pandasから容易に呼び出すなどの機能もある
    • cetflow API: 機械学習のオンライン予測を提供するAPI
    • 集約API: CETのAPIエコシステムはマイクロサービス的に複数のシステムを組み合わせて利用できる。PythonファイルをGitHubにpushするだけで作れる仕組みになっている
  • オブザーバビリティは基盤側で担保:
    • APIのログはStackdriver/BigQueryに連携されている、など
  • リアルタイム処理システム
  • バッチの世界:
  • SQL Farm: BigQueryのSQLとYAMLファイルを書くだけでクエリを定期実行し、汎用APIに自動でロードしてくれる仕組み
  • ジョブ基盤:
    • Airflowでスケジュール・ワークフローを管理し、GKE上でジョブを実行
    • Papermill(Jupyter Notebookをバッチ実行するためのツール)が使える
  • JupyterHub:
    • ローカルではなく、クラウド環境で実行できる(つまり強力)
    • Jupyter NotebookはPythonファイルにコンバートしたうえでプルリクしている(Diff取りやすい)
  • ポイント:
    • データサイエンティストとエンジニアの関心をうまく分離して、データサイエンティストだけで施策をどんどん実行できる環境を作ろう
  • Q:さまざまなコンポーネントがあるが、どうやって技術選択したのか?
    • 関心の分離が大事で、データサイエンティストが使っている言語やツールに合わせた。自動化も優先した

20:20 - 20:50 マシンラーニング、マイクロサービス、マネジメント Shibui Yusuke

  • iOSアプルで「写真検索」機能をリリースした
    • 写真の中から欲しいモノを選択して絞り込み、検索できる

メルカリの機械学習

  • 2017年3月頃から機械学習を導入し始めた
  • 出品検知、写真検索など

SysML

  • MLエンジニア: TensorFlowなどのツールを使ってモデルを開発する
  • SysML: MlOpsとも呼ばれる。機械学習のモデルをシステムで動かす
    • ミッション: 機械学習モデルを歩版で動かす(プラットフォーム開発とインテグレーション)
    • リュケイオン: ワークフローをカバーする独自のプラットフォーム
  • ビジネスで考える:
    • 機械学習の価値は、ビジネスへの還元だと考えている。実用化こそが、SysMLのミッション
  • システムで考える:
    • マイクロサービス化するアーキテクチャにするという結論に至った
  • 出品検知: 特定種類のものを検知する。1システムで複数の機械学習モデルを稼働
    • 第1版: モノリシックで簡単なもの。特定の検知。sk-learn
    • 第1.1版: 特定の検知を2値分類にして強化。モデル追加優先。多クラス分類+2値分類。sk-learn
    • 第1.2版: ディープラーニングとlstio(A/Bテスト)の投入。アーキテクチャ改善優先。docker。TensorFlow+sk-learn
    • 第2版: QAを入れる(ユニットテストはできないからマニュアルテストを)。Kubernetes。1リリースが10分になった

20:50 - 21:00 スポンサーLT

新設ポジション・データエンジニア@Business Intelligenceの紹介 株式会社メルカリ

  • BIエンジニア: BIチーム(仮説検証、インパクトシミュレーション、効果検証)。データ基盤。データエンジニア

DLLAB 製造・流通分科会アップデート 聴講ノート

※これはセミナー聴講時の個人的なノートをそのまま公開したものです。誤字誤植や勘違いがある可能性があるのでご了承ください。

DLLAB 製造・流通分科会アップデート - connpass

15:00-16:30 DLLAB 製造分科会 技術検証取り組み紹介

  • 2つの課題設定に対する、各社の検証結果を共有する
  • ユーザー企業については、課題をオープンにして、社内データを提供していただいたことに感謝
  • パートナー企業については、高難易度で短納期でチャレンジしていたいたことに感謝
  • より多くの企業に参加していただいて、課題と技術のマッチングを今後もしていきたい

ミスミグループ本社様「不定形フォーマットカタログからの製品情報抽出」

「課題設定」株式会社ミスミグループ本社 宋美沙氏

  • リテラシーや経験がない。でも何かしなきゃ。期待値主導のPoC
  • 知識・経験不足で、エヴァンジェリストとして機能しない。とにかく足りないところを埋めるということで、DLLABの分科会に参加
  • 問題 誌面が複雑。専門用語や詰め込みすぎで認識ミスが多そう
  • 分科会でのお題: データ構造化は無視して、テキスト抽出に絞った

「検証結果」株式会社3AS 山元博生氏

  • 取り組みのスコープとアプローチ: 過去のペーパーカタログから文字領域と表領域を識別し、ページ認識情報のアノテーションを作成
  • 表領域からの文字抽出まではできていないが、文字領域からの抽出はできた
  • 使ったモデルは SENets: [1709.01507] Squeeze-and-Excitation Networks
  • 抽出委した文字領域から、文字の輪郭を基に1文字ずつ文字を抽出して文字認識する
  • そこそこ良い結果が出ている

「総評」ミスミグループ 宋美沙氏

  • 適切な課題設定の粒度は何か?
  • 場数を踏むだけではなく知識が必要
  • アプローチがユースケースにフィットしているか?
  • アルゴリズムの議論をするには、ユーザー企業側にも理解できる人が必要
  • 結果として別のゴールが見付かってもそれでよしでいいと思う

トヨタ紡織様「CAD図面からの物体自動学習」

「課題設定」トヨタ紡織株式会社 田尻泰彦氏

  • AIを使って工場内の部品(フレーム、フロントバックのカバーなどなど)の動きを捉えていく
  • 全部品・全製品へのアノテーションが必要だが、非現実(1シートで300点もある)
  • 3Dスナップショット(今回はフロントクッション)から形状を学習してみる

「検証結果」株式会社3AS 山元博生氏

  • アノテーションをどうするかに着目
  • 3Dデータから2Dに落とすか: 多方向から撮影
  • カラー画像、グレースケール画像、ネガポジ画像で検証
  • カラーからグレースケールへの変換でエッジ抽出してから物体検出: 検出できなかった
  • グレースケール+ネガポジ変換で物体検出: 白っぽいと検出できた
  • 色が付いていないと検出率は高くない
  • 光源は精度に影響しやすいので、今後は光源を変えてやってみる

「検証結果」SCSK株式会社 帯津勉氏

  • CADデータをいかにアノテーションなしで学習させるかに着目
  • さまざまな角度のCG画像を作成
  • (1)作業CG画像からシート全体を検出し、(2)次に精度の良いFC(実写)検出を行う、という2段階
  • 独自のAI検出ツール「」を使った
  • (1)ではバックに他の画像を重ねる: 機械的に行った
  • 結果: 再現率は53.1%、適合率は94.4%
  • 考察:学習件数250件では、十分な精度に至ってない
  • 追加検証:特徴不足の補完(実写に近いデータを混ぜたが精度は逆に下がった)、画像数の補完(3750枚に増やすと特徴を細かく判定するようになった)
  • 十分な検出精度は出なかった

「検証結果」BLUE TAG株式会社 小川兼司氏

  • 色やテクスチャは極力使わないアプローチを考えた
  • まず、セグメンテーションは自動で行う。輪郭がシートでないものは除外する
  • 3Dデータを使ってさまざまな角度の画像を作成
  • 次に、深度推定の学習済みモデルを用意
  • 深度が正しく反映されていない: 複雑な図形だとAIも混乱するのかも
  • エッジ検出: 2値化(マスク)で行う
  • Hu Momentは台形変換に対して不変ではないので、それほど当てにならない
  • エッジ検出画像をオートエンコーダーでも検証
  • R-CNNの学習済みモデル
  • いずれもそれほど良い精度が出せていない

「総評」トヨタ紡織株式会社 田尻泰彦氏

  • 3AS: グレースケールよりカラー画像の方がよいのは意外
  • SCSK: 先に大きなものと捉えて、次に小さいものは有効
  • BLUE TAG: 画像がダメだった
  • 最初のトライができて良かった
  • やりたいことは汎用的なので、誰か作ってもらえると転移学習できるのではないか

16:45-17:45 AI カメラによるデジタルマーケティング 株式会社TRIAL CTO 松下伸行氏

  • 九州のスーパーマーケット「TRIAL」
  • 犬猫画像の判定精度はこの10年で大幅に飛躍した
  • スマートフォンでも認識できる(Xperia Z4の料理認識エンジン)
  • しかし小売りは人間が見ている。ここにAIカメラを入れる
  • Retail AI, inc. - Cyber Store Platform
  • 棚が分かるAI、最適に切り替えるAI
  • AIカメラ(AIエンジン+カメラ)「RAICA」を深センで作っている
    • まず600台、今は2000台を作った、次は3万台の予定
  • 普通のカメラは汎用的だが高い。RAICAはリテールに特化して安くしている
  • RAICA-Z1:名刺サイズ=値札につけるため
    • 1300万画素(800万画素で人は十分だけどオートフォーカスをするため。商品の図柄を見るためには1000万画素は必要)
    • Android/CPU /GPU
    • WiFi、バッテリー、USBチャージ、HDMI
  • リアル店舗であれば、非計画購買(衝動買い、ついで買い)をできる。棚全部を売り出したいコーラーだけにするなど
  • 人認識、商品認識
  • 何段か組み合わせることによってできるようになった
  • 1年くらいやるとようやく実用可能なモデルが完成する
  • どっちの棚がどれくらい売れたかが分かる
  • 店舗ごとに陳列方法や棚なの色が違うなど。OpenCVだとブランチが増えてしまう。ディープラーニングなら追加学習してどんどん賢くなる
  • 性別や年齢を識別してインタラクティブにサイネージ(広告)が切り替わる
  • Retail Iot(カメラ+サイネージ)
  • エッジ+クラウド: 最初にクラウド側で学習していき、精度が出るようになってからエッジ側に持っていく
  • 汎用的なノウハウは共有する

17:50-18:20 小売業におけるAIの活用とDLLABとの連携 Retail AI 研究会 代表理事 田中雄策氏

  • リテールAI研究会: 正会員59社、賛助会員91社、流通会員19社
  • 情報共有、実験、普及・PR、人材育成
  • 人材育成としてR検定を作る予定
  • 技術は出そろったが、どう使うか? コストに見合うか? 落とし穴はないのか?
  • TRIALの事例:アイランドシティ店(AIカメラの導入など)、大野城店(キャッシュカードでチャージ、夜間無人化など)、新宮店(2019年4月オープン)
  • リテールメディア: スマホにクーポン、サイネージ広告などを、店舗に入る前、歩くとき、出るときと適切なタイミングでプッシュする

Recap of TensorFlow Dev Summit 2019 聴講ノート

※これはセミナー聴講時の個人的なノートをそのまま公開したものです。誤字誤植や勘違いがある可能性があるのでご了承ください。

Recap of TensorFlow Dev Summit 2019 - connpass

19:05-19:40 An Introduction to TensorFlow 2.0: Updates from the TF Summit? Laurence さん(Google LLC)

19:45-20:10 TF Probability, TF-Agents and TFX (BrainPad Inc. ohtaman)

TF Probability

  • 確率的プログラミング:世の中を確率的な事象と捉える
    • 点で表現すると不確実さ(ばらつきなど)を表現できない
  • 不確実さとは:
    • データのばらつき具合(Eleatoric uncertainty)
    • パラメータの推定値の分布(Epistemic uncertainty)
  • TensorFlow Probablityを使うと、確率的プログラミングで簡単に書ける
    • Keras Layersと組み合わせて使う
  • TensorFlow Probability  |  TensorFlow

TF-Agents

TFX (TensorFlow Extended)

その他

  • TensorFlow.js v.1.0のリリース: iPhone Xでは9.4倍
  • 教育への取り組み(オンライン学習コースなど)
  • 2018年に比べて、2019年は具体的な実用例が増えた

20:15-20:25 Demonstration: Edge TPU and Sparkfun Edge (BrainPad Inc. ohtaman)

Sparkfun Edge

f:id:misshiki:20190320201415j:plain
Sparkfun Edge

Edge TPU

f:id:misshiki:20190320201534j:plain
Edge TPU
- Edge TPU Devices - Coral | Home - Edge TPU - Run Inference at the Edge  |  Edge TPU  |  Google Cloud

20:30-20:45 LT1:Federated Learningと差分プライバシー TomMoriyama さん

TensorFlow Federated (TFF)

  • TensorFlow Federated: Federated Learningを実装したフレームワーク
  • Federated Learning: 分散した訓練データを協調的に学習する手法
  • AndroidスマートフォンのGoogle Keyboradで入力候補を提示するモデルを学習する事例(※概念検証中)
  • 従来の機械学習では、データをサーバー1箇所に集めて学習していた。しかしセンシティブなプライベートなデータがあったり、レスポンスが遅いなどの問題
  • 端末上の機械学習では、データが少ななったり、クライアント間で成果を共有できなかったりという問題がある
  • そこでFederated Learning。クライアントで学習したデータをサーバーに集約し(=重みの差分を集計してグローバルモデルを作り)、そのグローバルモデルを各クライアントに配布する、というサイクルを繰り返す
  • ライブラリには2つのAPI: Federated Learning API(上位)とFederated Core API(下位)
  • TensorFlow Federated  |  TensorFlow Federated  |  TensorFlow

20:45-21:00 LT2:tf.keras等のhigh-level APIsについて MasaoTaketani さん

  • 従来のtf.kerasは、小さなモデル構築用で、大規模なモデル構築には向かなかった
  • tf.estimatorは、スケーラビリティを意識したAPIで、分散学習も容易に行えた
  • 新しいtf.kerasは、これまでと同じ書き方で分散学習までをカバーできるようになった
  • データセットのパイプラインはnumpy配列のように扱えるようになった
  • RNNレイヤーの変更: 従来はGPUだとCudnnLSTMクラスを使っていたが、2.0はLSTMクラスだけで使いわけなし
  • tf.feature_columnがtf.kerasにも投入できる
  • tf.kerasでTensorBoardを使うのも1行
  • tf.distribute.Strategy APIでKerasの利便性を保ちながら分散学習できる
  • SavedModel形式でモデルのセーブとロードができる(現在のアルファ版では実験段階)
  • マルチノードで同期:tf.distribute.experimental.MultiWorkerMirroredStrategy
  • TPUでの分散学習: tf.distribute.experimental.TPUStrategy
  • 今後実装される: tf.distribute.experimental.ParameterServerStrategy
  • Distributed Training in TensorFlow  |  TensorFlow  |  TensorFlow

Google Developers ML Summit Tokyo 2019 聴講ノート

※これはセミナー聴講時の個人的なノートをそのまま公開したものです。誤字誤植や勘違いがある可能性があるのでご了承ください。

Google Developers ML Summit Tokyo 2019 - カンファレンス

10:45 AM - 11:15 AM 機械学習の概要

  • 機械学習とディープラーニングに関する基本的な説明(Playground利用)

11:15 AM - 11:45 AM TensorFlow 2.0: Machine Learning Made Easy

  • 機械学習などの現状説明、TensorFlowの現状説明、TensorFlow 2.0の説明

11:45 AM - 12:15 PM Cloud ML API 入門

  • 製造業、小売業、ヘルスケア業界、メディア&エンターテイメントなど、幅広い分野で機械学習の活用が増えてきている
  • しかし機械学習モデルを構築できる専門家は少ない
  • そこで掲げているミッションが “AIの民主化”
  • (より汎用的)Machine Learning API/Cloud AutoML/Cloud AI Platform(より専門的)
  • Machine Learning API: 視覚(画像分析・動画分析)、言語(機械翻訳・テキスト分析)、会話(音声認識・音声合成)
  • 利用方法: Google Cloudクライアントライブラリ(各言語ごとに最適化して作られている)、Google Cloud API(クライアントライブラリが未対応の最新機能を使いたいときはこちらを)
  • Google Cloud API: gRPC形式とREST形式の2種類がある
  • デモ

12:15 PM - 12:35 AM ML Kit 事例紹介

  • 機械学習の関心は高いが、モバイルアプリに実装するのはハードルが高い
  • ML Kit: そのハードルを下げる
  • ZOZOテクノロジーでの事例: ファッションチェックアプリ、ML Kit使用
  • オンデバイス推論をサポート(TensorFlow Lite)。アプリには強力な武器となる

12:35 PM - 1:00 PM Actions on Google 事例紹介

  • Google HomeのGoogle Assistant×クロネコヤマトの活用事例

2:00PM - 5:00 PM TensorFlow コードラボ

Advanced version

『ここが変だよ、日本のAIプロジェクト』 聴講ノート

※これはセミナー聴講時の個人的なノートをそのまま公開したものです。誤字誤植や勘違いがある可能性があるのでご了承ください。

【緊急開催】キカガク&マスクド・アナライズ共催イベント『ここが変だよ、日本のAIプロジェクト』 - connpass

19:00~19:30 『AIを一つください、という前に』 杉山 阿聖氏(SENSY株式会社 SAILSリサーチャー)

地味で泥臭い

  • 手作業で分類した結果をダブルチェック
  • PythonやSQLのデータの加工
  • などなど
  • 手を汚して少しずつ進めるというのが現実的

各フェーズにおける課題と解決方法

19:35~20:35 『AIベンチャーガチンコトークバトル』 マスクド・アナライズ氏(イキリデータサイエンティスト) & 吉崎 良介氏(株式会社キカガク 代表取締役社長)

AIが、選択肢になる日。

  • 以下、敬称略。
  • マスク:今日はAI導入活用の成功率が多少上がるかもしれない方法について話す。AIベンチャー勤務。お客さんとの窓口として活躍している。
  • 吉崎:エンジニアサイド、ビジネスサイズに分けられる。エンジニアサイドに焦点を当てます。2018年はAzure MLやAutoMLなどがホットになってきた。AutoMLがしたことが、特徴量選択、アルゴリズム選択、ハイパーパラメーターの自動チューニングなど。
  • 吉崎:2018年までのAI事情はどうですか?
  • マスク:うまくいったところはほとんどなかった。良い事例があっても、その裏にはかなりの数の失敗事例がある。
  • 吉崎:成功しているという発表でも、実は局所的だったり裏がある場合も多い。
  • マスク:あとAIやりたいのでお願いします。という丸投げが多かった。
  • 吉崎:契約段階で、発注者との成果物の想定の違いが昔あった。
  • マスク:前処理に時間がかかると試行錯誤する時間が短くなる。説明責任として、もらったお金に対してどういう作業をしたかを示すとよい。
  • 吉崎:法律周りはどうか。
  • マスク:受け取ったデータをどうまで公開するかの契約周りは気にする必要がある。
  • 吉崎:実際に企業でAIは活用されているのか?
  • マスク:あるデータでは、2017年が4.1%、2018年は12.5%。体感ではもっと少ない。理由は単純に予算の問題。
  • 吉崎:活用できていないボトルネックは?
  • マスク:データが部署ごと、部門ごと、データ形式がバラバラといった問題がある。データを集めるための交通整理。AIが役立つかの交通整理が必要。
  • 吉崎:データの整備ができていない。それはどういうことか? まずは教師データと入力変数があるかどうかを明確にすればよい。
  • 吉崎:PoC。期間とか費用とか。
  • マスク:PoCは数百万円ぐらいから始める。
  • 吉崎:ベンチャーだとそれくらい。もっと大きいと桁が1つ違う。
  • 吉崎:人材。まずは社内で育てた方がいい。
  • マスク:採用活動を行ってもこない。
  • 吉崎:AI導入にはROIを測らないといけない。AIをしないとROIは出せない。ニワトリ卵。トップダウンで導入できるならプロトタイプ作成が有効。
  • 吉崎:PDCAサイクルはダメなのか?
  • マスク:製造業の現場などでの改善にはいいけど、AI導入検討ではPDCAの悪いところばかり反映している。DGWA(Do:試す、Go for Broke:当たってくだける、Warm Mind:失敗を許容する暖かい心、ReAction:反応・反響を起こしながら感謝の気持ちを持つ)サイクルがいい。
  • 吉崎:ポジティブループにするにはDGWAはいい。最初の契約の段階でDGWAを共通認識にしておくのが大事。
  • 吉崎:新規事業の場合は、精度のゴールが見えにくい。既存事業の場合は、ゴールが明確になりやすい。ヒューマンインザループ。
  • マスク:偉い人にはヒューマンインザループ。現場の人にはDGWAサイクル。
  • 吉崎:SI開発とAI開発の違いは?
  • マスク:私もギャップに悩んだ。スキルも開発方法も違う。どうやって勉強すれば?
  • 吉崎:社内勉強会をするとよい。キカガクの講座などもトリガーにしてほしい。
  • 吉崎:違いは、精度100%にならないのでテストができないこと。アジャイル的にならざるを得ない。

20:45~21:15 『IoT/AIの利活用におけるデータ取り扱いについて』 小川 貴之氏(弁護士)

  • ビッグデータに関する国の動き:
    • 2017年、未来投資戦略
    • データ契約ガイドライン
    • AIシステム共同開発支援事業(助成金)
  • データに関する法律:
    • データベース著作権
    • 特許を受けた発明
    • 営業秘密(不正競争防止法)
    • 限定提供データ
    • 不法行為
    • 契約(契約不履行)
  • 今後はデータのM&Aが流行する?
    • データ会社と解析会社のジョイントベンチャーを新たに立ち上げる
  • 2013年、JR東日本のSUICAのビッグデータの問題:
    • JR東日本から日立製作所にデータ(※個人の特定はできないもの)を提供。バッシングが起きた
      • 加工が不十分で、特定できるおそれがある
      • 事前の周知がなくて、利用者への配慮に欠けていた
    • 現在の法律に照らすなら:
      • 個人情報保護法に従って、匿名データに加工する。しかしどこまで加工すればよいのか
      • 匿名加工情報用のサーバーを、個人情報用サーバーとは別に用意する必要がある
      • 匿名加工情報をビジネスに使うというプライバシーポリシーをあらかじめ公表しておく