2019-02-20 DeNA TechCon 2019 にいってきた https://techcon.dena.com/2019/ TL;DR 毎年開催されているDeNA単独の技術カンファレンス。今年は機械学習の応用とクラウド化とQAの話が多かった。 以下、各講演についてひとことコメント 車載カメラの画像を使用した３次元点群復元と物体認識技術における深層学習の活用 LIDAR等の高価な機器を使わず、車載カメラから撮った映像から3次元マップを作成する試み。SfMを用いると画像だけで3D構造を推定できるのが興味深かった。自分でもSfM試してみたいと思った。 キーワード SfM, Faster R-CNN, LaneNet 『モビリティ・インテリジェンス』の社会実装〜タクシー運行最適化を実現する機械学習システム〜 タクシーの最適な流しルートをナビゲーションで指示するシステムを作る試み。タクシーを流すのは初心者と経験者で売り上げに2倍以上の差があるそうで、このナビに従うことで初心者でも平均的な売り上げをあげられる。モデルづくりの話とシステム構成(ほぼ全部GoogleCloud)の話の二本立て。個人的には フロントエンド～DWH～API までをすべてGoogleCloudで構成しているのが興味深かった。 キーワード マルコフ決定過程, DQN DeNAの品質を支えるQAの取り組み 〜標準化から実践まで〜 満席のため諦めた。代わりに↓の講演を見た 運用中のゲームにAIを導入するには〜プロジェクト推進・ユースケース・運用〜 既存事業に対してAI施策をどう導入して回していくか、MLOps的な話だった。こういう話は少しずつ地道に進めるのが重要。 キーワード CloudMLEngine, Experiment as Code パネルディスカッション：データサイエンスの競技者、Kagglerたちが活躍する職場とは データサイエンティストが社内でどのように活躍しているかの話。日本に40人ほどいるKaggle Masterのうち10人がDeNAにいるそう。最近入社した人ばかり。これからもデータサイエンティストを積極採用していく意欲を感じた。事業付きエンジニアやデータエンジニアでは限界を感じていた問題も彼らデータサイエンティストが解決して行っている。餅は餅屋だと思った。 DeNA と Google Cloud Platform GoogleのカスタマーエンジニアとDeNAの開発責任者との対談。DeNAは未だに大規模なオンプレミス基盤を自前で運用していて、それを2020年までにすべてクラウド化する予定。システム運用者の観点からの話。クラウドを導入する際の説得方法、DockerとCloudFunctionの使い分けをどうするかなど。 StackDriver（ログ監視コンソール）が便利という話をしていた。機会があれば使ってみたい。 【対談：DeNA ☓ AWS】クラウドジャーニーのこれまでとこれから （前の講演と連続して）次はAmazon技術統括本部本部長とDeNAインフラ部門責任者の対談。GCPだけでなくAWSも大規模に使っていくらしい。お得意様のための特別なサービスの話が興味深かった。AWS本部長の押しが強い。声が大きくてうるさかった。 Lightning Talks (A-STAGE) バーチャルキャラクターの話 お手洗いに行ってて聞き逃した GAE SE製ウェブサービスを無障害リリースするための負荷試験 クラウド活用してお手軽に負荷試験ができる話 MastdonとActivityPubの話 Mastdonのプロトコルの歴史話 ISUCON8予選問題においてPerl実装で25万点を突破する方法 出題者がチューニングしたら25万点突破したという話 超早口で発表してたがスライド半分も行かずにタイムアップ https://engineer.dena.jp/2018/12/isucon8q-one-of-answer.html 車載カメラの画像を使用した３次元点群復元と物体認識技術における深層学習の活用 講演者 Kosuke Kuzuoka 元 建設 × IT Venture 勤務 上記Ventureでは建設業界で使われる設計図をコンピュータビジョンで読み取る研究を行っていた DeNAでの現在のミッション 高精度地図を低コストで作成する カメラ等の安いデバイスだけで作る Lidarとかは使わない 高精度地図とは？ ここでいう高精度地図とは車や機械のためのもの 自動運転で自己位置推定によく使われる 地図と現地がずれていると事故の元 精度は数センチ〜数十センチが求められる 経路探索にも用いられる 今回使った重要技術 深層学習とSfM(Structure from Motion) 深層学習 深層学習についておさらい 昔（1950年代）からある 昔はパーセプトロンと呼ばれていた 線形分離不可能な課題＞層を深くすることで解決 深層学習がなぜ今盛り上がっているのか 膨大なデータセット(ImageNet)の蓄積 高度な計算資源を得られるようになった SfM (Structure from Motion) 画像から3次元形状を復元する技術 Web上の画像（15万枚）だけでローマのコロッセオを３Ｄ再現する（２１時間で）という有名な研究がある どのように復元するのか？ 対象を様々なアングルから撮影した画像を用意 特徴抽出 特徴点を関連付け さらに多数の点で関連付けすることで誤差を少なくする SfMを使ってみなとみらいエリアの3次元点群を復元 走行エリアの画像を収集 SfMで３D点を復元 標識や車線レーン、レーンの矢印まで詳細まで復元できてる カメラで見えない部分は復元できない 3次元点群から物体を認識する 道路標識、レーン、路面標示 を認識したい 道路標識の検出 Faster R-CNN(2016) を使用 畳み込みネットワーク 精度は高いが実時間で使うには遅い→今回はリアルタイムで動作する必要はない 検証の結果、ほとんどの標識、信号は検出できたが、見えにくいものは検出できないこともあった レーンの検出 LaneNet(2018) を応用した https://www.groundai.com/project/lanenet-real-time-lane-detection-networks-for-autonomous-driving/ 画像を上から見た画像に変換して検出 検証の結果、レーンを検出できた。曲線のレーンも検出できた 路面標示の認識 路面標示とは、路面にペイントで描かれた矢印や停止線、横断歩道などのこと なかなか研究がない分野 下記のような新しいアルゴリズムを作成 画像を上から見た画像に変換 変換画像をFaster R-CNNを用いて検出 検出結果を元の画像の座標に戻す 実際の画像や動画に適用した結果 路面標示（レーン矢印、停止線、横断歩道）が認識できている これまでの情報を３次元情報にマッピングする 特徴点＝認識点 になっていないと ３Dにマッピングできない 特徴点から認識できたところだけをフィルタする みなとみらいの２交差点間でテスト レーン、矢印、標識のみを抽出した高精度地図を作成できた 今回の技術を今後どのように応用するか オートモーティブ事業向け高精度地図の自動作成 カーナビ情報、地図のアップデートの効率化 地図データと最新情報との差分を自動的に生成するなど 『モビリティ・インテリジェンス』の社会実装〜タクシー運行最適化を実現する機械学習システム〜 DeNAのオートモーティブ事業がやっていること タクシー配車アプリ カーシェアリングサービス 自動運転技術の開発 など 今回の講演テーマ - タクシー交通システムの最適化 講演の前半：運行最適化アルゴリズムを作る 講演者：織田 拓磨 以前は鉄道会社で運行制御システムを開発 シリコンバレーの交通系スタートアップでインターン タクシー運行を最適化するとは？ 日本ではアプリ配車アプリの利用率が海外に比べて著しく低い そのため最適化には配車アプリ以外の部分（つまり流しの部分）で工夫する必要がある タクシーの流し（探客スキル）は乗務員に大きく依存する 初心者と熟練者で2倍の成績差がある タクシーが空車になったときに、現在位置を与えるとそこからの最適な探客経路を与えてくれるAPIがあればよい 探客経路APIをつくるには ダイクストラ法では解けない 目的地がない コストを最小化するという問題で定義できない APIを作る上で４つのチャレンジ チャレンジ１：道路レベルの需要供給予測 チャレンジ２：リクエストに応じてすぐに経路を返すため 探索を効率化したい チャレンジ３：複数の車両で利用した場合に全体最適になる チャレンジ４：乗務員にとって走りやすい経路を提示する チャレンジ１：道路レベルの需要供給予測 を行う 待ち客の位置を直接観測することはできない→既存のデータから推測するしかない 既存のタクシー乗降情報を利用する 流し需要の分析 乗降データの座標を道路に紐づけて分析 道路、時間帯ごとの需要予測モデルを作成した チャレンジ２：リクエストに応じてすぐに経路を返すため 探索を効率化したい 最適な行動系列を探索する一般的な方法＞木探索 MCTS(モンテカルロ木探索) 木探索をそのまま使ってオンデマンドで 適切なコストで 探索を行うのは難しい アルファ碁などで使われた方策の概念を導入する （注 方策勾配法：粗い探索をヒューリスティックに解けるモデルを強化学習などを用いて予め生成しておく手法） 方策 ＞ MDP(マルコフ決定過程)でモデル化する 環境（状態）の中でエージェント が利用可能な行動を取る 環境はランダムに遷移して、エージェントは環境に応じた報酬を受け取る MDPの問題設定：累計報酬を最大化する方策＝行動選択の確率分布を 求めること 探客問題をMDPでモデル化する 状態：現在位置 行動：移動方向 報酬：売上 方策＝ある場所から報酬の確率分布を最大化する移動方向を算出する関数 MDPを解く 強化学習によってMDPを解く 強化学習の一種である Deep Q-Network を使う 実際のAPIでは方策を使って答えを返すので高速 チャレンジ３：複数の車両で利用した場合に全体最適になる リアルタイムの需給予測結果を方策に反映している 需要が高い場所でも、供給が多ければ他のタクシーはそちらには行かないようになる チャレンジ４：乗務員にとって走りやすい経路を提示する 最適な経路とは何か？ 頻繁に右左折しないなど、乗務員にとって走りやすい経路 安全な経路であることも重要 MDPの報酬関数は自明ではない 報酬が正しいか検証するのも難しい 報酬関数をどのように定義したら良いのか？ → データから推定する手法がある IRL(逆強化学習)による報酬関数の推定を行う エキスパートの軌跡（デモンストレーション）から報酬関数を推定する つまり模範データから報酬関数を推定する タクシーでは、売上の高い乗務員の軌跡をIRLに入力して報酬関数を推定する 実証実験の結果 対象エリアの乗務員全体と同程度の成績 つまり、経験の浅い乗務員には有効 このアプリはプロダクト化に向けて実証実験中 講演の後半：タクシー配車サービス MOV の機械学習基盤 講演者：益子 遼介 12年新卒 MLエンジニア 基盤の構成 サービスの基盤は GCP で作っている Data Service, ML Service, API Service の3つのサービスで構成 データサービス 車両から送信されてくるデータや各種APIログをPubSubに集約 Dataflow StreamingでPubSubから集約したデータをBigQueryにインサート データ処理の一例 ノイズの多い生のGPSデータを地図上の道路にマッチ（補正）させる DWHのはなし BigQuery 選定の基準 列志向（分析向き） 低コストのストレージ 分散処理性能が高い 運用レス 普通の使い方とちょっと違う リアルタイムのパイプラインに組み込む BigQueryGIS（地理統計関数） ある場所で起きたログを集約したりすることができる パーティショニング データが膨大すぎるので、予めパーティショニングしている パーティション単位：時刻と地域で分割している パーティション軸は重要なので、分析者とよく話し合うことが重要 セキュリティー プロダクト側とは独立したGCPプロジェクトにしている プロダクト側からは書き込みのみ許可 データを暗号化 etc 機械学習サービス MLモデル開発フロー データサイエンティストがJupyterNotebookが入ったDockerImage上で開発する DockerImageにデータ処理が全部入っている DockerImageを実際の推論パイプラインにデプロイすることでモデルを適用する ML推論パイプライン CloudComposer（Managed Airflow）を利用している ジョブの成功・失敗が一目で分かる ガントチャートを見てネックとなるタスクを見つけることができる プロダクトの運用 ありがちなこと１ どうやってモデルを学習したのか当時の担当者しか知らない（再現性の喪失） データサイエンティストから渡されたコードが実行できない（コミュニケーションギャップ） 解決１ Dockerに処理を全部乗せてやり取りする ありがちなこと２ モデル精度が経年劣化しているのに気づかない（モデルの経年劣化） 解決２ モデル推論の精度を自動監視 MLの精度に依存しないサービス設計をするのも重要 精度が悪い場合は自動でフォールバックするなど 運用中のゲームにAIを導入するには〜プロジェクト推進・ユースケース・運用〜 奥村 純 岡田 健 今回のテーマ AIプロジェクトのライフサイクル 前半の講演：機械学習の概念検証(Proof of Concept) 後半の講演：本格的な仕様検討、実装、運用 最後のまとめ：AI施策を運用に乗せるためのMLOps 前半の講演 講演者：奥村 純 理学博士(宇宙物理学) データアナリスト 強化学習チームリーダー 前半の内容は去年の講演とほぼ同じ https://www.slideshare.net/juneokumura/cedec2018ai AI施策をどのように作ってきたか 課題の背景 逆転オセロニア 戦略対戦ゲーム 解決したい課題 ネガティブ体験を無くしたい 初心者がデッキ編成を覚えるのが大変 デッキの編成や戦い方の学習をサポートしてくれる機能がほしい 解決 デッキのおすすめ編成機能を作った 大量のデッキ編成ログを使用して、キャラクター同士の関係性を評価する 関係性評価のためにアソシエーション分析を行った 支持度・信頼度・リフトの３つの指標 初心者の勝率が上がった 上級者は自分でデッキ編成した方が勝率が高い 戦略の学習をサポートする機能 気軽に対戦の練習相手が欲しいというニーズに応える 対戦相手AIを作った（未リリース） 対戦AIの作り方 DNN（深層学習）を採用した 盤面、手駒情報を数値化 5000程度の特徴量を使う AIのモデルに入力して、どこに打つべきかを算出する 上位プレーヤーの行動に一致するようににモデルを作っていった 後半の講演 AI施策を実現するための技術 講演者：岡田 健 理学修士(数論) DeNAエンジニア 逆転オセロニアでAI導入担当 機械学習のPoC(コンセプト検証)が終わると、サービスにどう組み込んでいくかのフェーズになる ML Codeは機械学習を利用するシステム全体から見ると小さい システム設計 - 企画をどうシステムに落とし込むか オススメ編成 学習サイド BigQuery内のデッキ編成ログ → アソシエーション分析 → アソシエーションルール算出、GCSに保存 サービスサイド ユーザーがレコメンドAPIを叩く → デッキ編成を返す 対戦AI 学習サイド BigQuery内のPvPマッチ棋譜 → AIモデルのトレーニング → モデルをGCSに保存 サービスサイド 打ち手の棋譜の特徴量抽出 → AIモデルによる推論 高付加に耐えられる仕組み - Cloud ML Engineをどう利用しているのか スケーラビリティーについて 社内に知見がなかったのでスケールアウトの検証をした 負荷要件：サービスでイベントが開始された瞬間から10分間程度、高負荷が続く 検証結果 スケールはすばやくしてくれる レイテンシは3秒以下 ただし、一定割合でタイムアウトする（インスタンス数が増加するタイミングで起きる） ここで、推論APIに求められる仕様を確認 推論APIは10秒程度で帰ってこれば良い →バックアップを用意し、5秒待って帰ってこなければバックアップサーバーが処理 バックアップを利用するとエラーはほぼなくなった 運用を楽にする仕組み - 特に、モデルや特徴量抽出器をどう管理しているのか MLモデルの依存要素 学習データ 隠れ層のユニット数、活性化関数、学習率、バッチサイズ 等 表現ベクトル 以前は依存要素をエクセルで管理していた 依存要素が一致していないと使えない → ごちゃごちゃになる 解決策：Experiment as code を徹底 依存要素を設定ファイル化した 学習やデプロイの手順が明確になり、再実験・共有が容易に まとめの講演 講演者：奥村 純 プロジェクトの振り返りと今後 以下の記事にもまとまってます。 http://www.itmedia.co.jp/news/articles/1902/06/news128.html スモールスタート 課題は不確実性 小さな検証を積み上げていく 期待値を合意 不確実性があること（一喜一憂しない）、不確実性の度合い について認識形成する ３つの見通しを用意する 最低ライン 現実ライン 理想ライン 一番すり合わせが重要なのは最低ライン 役割を分散 全部できるスーパーマンはいない 想像以上にプロジェクトの生態系は複雑 大きく４つの役割 ケースの設計 データ設計・収集 モデル構築・評価 実装・運用 目的を見失わない AIのためのAI開発をしない 目的はゲームを面白くすること。AIが黒子に徹するくらいがちょうどいい 最後に社外とのつながり AIが複雑化して、単独の会社だけでは話が進まない GameAIについて会社の垣根を超えたコミュニティ活動をすすめてゆきたい パネルディスカッション：データサイエンスの競技者、Kagglerたちが活躍する職場とは Kagglerについて Kaggle : 機械学習モデルを構築するコンペティションのプラットフォーム Kaggler : Kaggleコンペに精力的に取り組む人のこと Kaggle Master : Kaggle のコンペで上位入賞実績がある人に与えられる称号 DeNAとKaggler 日本に40人ほどいる Kaggle Master のうち、10名（アルバイト含む）が DeNA に在籍 社内Kaggle制度がある Kaggle上位者は入社してからも業務のN%をKaggleに当てて良い Nの値はKaggleの実績に応じたクラス分けによって決まる 最高ランクのSSだと、業務時間の100％をKaggleに使って良い 先日Kaggleコンペで準優勝したチームにDeNAの2名が含まれている 小野寺和樹 加納龍一 Kagglerが関わった案件の例 関西電力とDeNAが、石炭火力発電所の燃料運用最適化を行うAIソリューションを共同開発 Kagglerがいる場所 DeNAには全社横断のシステム本部があり、その中にAIシステム部がある KagglerはデータサイエンティストとしてAIシステム部で働く AIシステム部には他に、MLエンジニアやAI研究開発エンジニアも働いている その他にも、事業部付きのデータサイエンティストもいる。 データサイエンティストに求められるスキルセット http://www.datascientist.or.jp/news/2014/pdf/1210.pdf ビジネス データサイエンス データエンジニアリング パネリストについて 原田慧 司会 アナリスト Kagglerのマネージャー的な人 小野寺和樹 加納龍一 データサイエンティスト バリバリKaggler 鈴木翔太 MLエンジニア 山川要一 事業部付きのデータサイエンティスト Kaggler グラフィックレコーディング パネルディスカッションのステージ上では、わなみん氏によるディスカッション内容のリアルタイムでのグラフィックレコーティングが披露された パネルディスカッション 事業の中でどのように働いているか 山川さん データアナリスト的なことをしている ビジネス課題をデータサイエンス モデル化する きれいな課題ではない時にどうするか？ 主体性をもってみんなで問題設定 KPI目標設定がないと評価できない しっかりと打ち合わせする 小野寺さん Kaggleのほうが面白いｗ （社内の課題は0.1%の改善を競っているKagglerにとってはあまり面白くないらしい） （Kaggleの問題っぽく社内の課題を解ける社内基盤「DeNAggle」がある） 鈴木さん MLエンジニア Automobile系のプロジェクトでKagglerと協業 モデルづくり以外の全部を行う Kagglerはエンジニアではない Kagglerはgitとか使えないので教えた 加納さん MLエンジニアと協業 エンジニアにプルリクとか教えてもらった 小野寺さん 一人で完結する仕事が多い ここ1年くらいKagglerが来て会社がどう変わったか？ 山川さん データはあるがどう活用すれば良いか分からなかった いままでできなかったことができる ユーザー残存率予測 これまでできなかったことができた 鈴木さん 実はDeNA出戻り 昔はデータサイエンスできる人少なかったが今は変わった 関西電力との協業 昔ならできるとは考えられなかった 加納さん バックグラウンドが違う色々な人が協業している 色々な強みを吸収できる （皆背景はバラバラだが、Kaggleが好きという軸があるので部署としてはぶれてない） 小野寺さん 勤務時間がゆるい。ヤフーにいたときは10時しゅっｓｙ…（司会からストップがかかる） DeNAは割と出社自由なのが良い 10時半がデフォ 原田さん 出勤時間は管理したくないので各自のプロ意識に任せている DeNAがすでに持っている多様性が魅力 これから先どうなっていきたいか 加納さん Kaggleで実績を残し続ける 社内で発生する様々な技術要求にフレキシブルに貢献する 小野寺さん コンペで優勝（世界大会に3度準優勝してるので） 鈴木さん Kagglerが社内でデータサイエンスについて啓発してほしい Kagglerが活躍できるようMLOpsをしっかり整備していきたい クラウド活用のレシピ（SageMakerとか）を提供できるようにしていきたい 山川さん 事業責任者とデータサイエンティストの間をつなぐことができるようになりたい
