DeNA TechCon2017に行ってきました！
日にちが経ってしまいましたが、去る2月10日にDeNAさん主催のDeNA TechCon 2017に参加してきました。
会場とそれぞれのトーク
去年に続き2回目の参加になります。
会場にはステージが5つありまして、それぞれ
となっておりました。
メインとなるAステージでは、トレンドであるAIに関する技術の発表が主となっており今の時代のトレンドであることを改めて強く認識できました。
去年はDeNAエンジニアの飛び込みのLTが行われていたのですが、今年はE-STAGEとしてスケジュールが組まれていました。
トークとトークの間の休憩時間は20分あり、かなり余裕のある感じで知り合いのエンジニアなどと近況を色々と話すこともできました。
トークも盛り沢山でクロージングが20時を過ぎるという感じでした。
聞いたものは3つ
私用の関係で聞けたトークは3つ。
- 深層学習による機械とのコミュニケーション
- Anyca(エニカ)のC2Cビジネスを支えるシステムと運用
- Unityネイティブプラグインマニアクス
自分は機械学習や深層学習といった分野は全く知らないのですが、深層学習のトークは聴いていてわからないなりにも興味が持てた。
年によってトレンドの移り変わりがあるようでそのキャッチアップは大変そうだけど面白さもあるでしょうね。
単語の表現ベクトルの話が特に印象深くて、単語の意味をベクトルで表現したときに例えば「Berlin」「German」「France」という単語をベクトル計算でvec(Berlin) - vec(German) + vec(France)としたときに、計算結果が「Paris」となったという話。
なんでそんなことになるのかは詳しい話は時間の関係で省略されたのですが、この結果もたまたまそうなったという部分が大きいらしく（？）聞いていてかなり興味深かったです。
カンファレンスのメモは以下↓
DeNA TechCon 2017
深層学習による機械とのコミュニケーション 株式会社Preferred Networks海野裕也様
深層学習のトレンド推移
- 年によってトレンドが変わる
- 深層学習は2012年は自然言語処理の中ではそれほどトレンドではなかった
- 2013年にWord2Vecの登場で注目され始めた
- 2014年LSTM, 符号化複合モデル
- 2015年は注意機構（Google翻訳の生後向上はこれがキーになっている（？））
- 2016年ｍ畳み込みネットワーク
深層学習の登場で何が変わったのか
- 表現ベクトルの学習が可能になった
- 一気通貫の学習が可能になった
- より応用よりの研究が増えている
表現ベクトルの学習が可能になった
- 各単語の「意味」を表現するベクトルの話
- vec(Berlin) - vec(German) + vec(France)と一番近い単語を探したらvec(Paris)だった
- ベクトルの計算でたまたまできた(?)
複数の情報を結びつける研究が出現
- convolutional neural network
- 言語と画像
- 言語と操作
- 言語と映像
マルチモーダルの研究がやりやすい
- ベクトル同士の比較の問題に定式化できる
一気通貫の学習が可能になった
自然言語処理のパイプライン 単語分割 瀕死タグつけ 構文解析 意味解析 構文解析で問題を細分化 先で間違った結果がエラーが積み重なっていき、うまくいかない
符号化復号化モデル 機械翻訳の例 英語→符号化ネットワーク→中間表現→復号化ネットワーク→日本語
一気通貫型の学習の何が憂いしのか
- 問題特価の工夫を入れやすい
- 試行錯誤の余地が広がって、たくさん手を動かす人が勝つようになってきた
適用が注目されている
- 機械翻訳
- 要約
- 対話
スマホ時代にブレークした技術
デバイスの変化と特質の変化
まとめ
Anyca(エニカ)のC2Cビジネスを支えるシステムと運用 蛭田慎也様
- カーシェアのサービスAnyca
C2Cならではの課題
- 利用までのハードルが高い
コミュニティ作り
- ユーザー参加型のイベント
- 運営とユーザーの関わり
- エントリーイベント
- Anyca若手グループ
- Anycaアンバサダー
トラブルを予防・解決するシステムと運用
- キズ確認機能
- 記録を残しておくことでトラブル防止に繋がった
- オーナー・ドライバー間で傷に対する価値観の相違が少なくなった
- 修理サポートセンター
- クルマ修理を有料修理工場でスムーズに行うことができる
- 万が一、シェア中の事故などにより車の修理が必要となった場合
修理サポートのバックエンド
- Opeツール
- webベースの管理ツールとして実装
- 運用上必要なオペレーションの大部分
- ユーザー情報の確認
- 修理サポートのチャット
- 見積もり結果の通知
- 案件登録〜納車まで完了した案件15件
- 最短で案件登録〜納車完了まで18日で完了
- 案件が登録される割合
- 一般的なB2Cレンタカーサービスの事故発生率よりも低い
健全なコミュニティ形成に向けた取り組み
- 重要なユーザーアクションの検知
- システム化できる部分とできない部分がある
- 全自動化が難しいオペレーションや運用方法を模索中
- レビューの確認、ペナルティ対応
- 修理サポートにおける修理業者との確認
- 事業推移とのバランス
- 運用をシステム化する工数・運用の手間を常に天秤にかけて判断
まとめ
- エンジニアとしてユーザーとの距離が近い
- 安心安全の向上に向けた取り組みは泥臭い部分が多い
- 運用をサポートするバックエンドのシステム化は面白い
Unityネイティブプラグインマニアクス 大竹悠人様・山内沙瑛様
ネイティブプラグインの作り方
- ネイティブ実装とそれを呼び出すためのインターフェースを用意することで相互に呼び出しを行うことができる
- 必要な実装
- ネイティブ 拡張機能のコア
- マネージドコートから呼び出すインターフェース
- ネイテイブコードとの連携実装
- 利用者向けの呼び出しフロントエンド実装
ネイテイブコードとの連携実装
- スライド参考
P/Invoke
CLIの機能でネイティブコードをマネージドコードのように呼び出すことができる 引数や返り値は必要に応じてマーシャリングという変換処理が行われる
ANdroidJavaObjectなど
AndroidのAPIやJARに含まれるコードを呼び出すことができるUnityのAPI。マネージドコードからクラス名を指定して呼び出すことができる。
UnitySendMessage
ネイティブコードからマネージドコードに文字列を渡すことができる。 指定したGameObjectの指定したメソッドに対して、stringを引数にして呼び出す。 ネイティブで一定処理を行った後に結果を返したい場合に利用する。 非同期のため、同一フレーム間でメッセージをやりとりできるわけではない。
利用者向けフロントエンド実装
C Linkage関数のインターフェースをC#で扱いやすくするためにラッパーを実装する。
ネイティブプラグイン作成時の注意点と対応策
書くプラットフォーム用のライブラリ対応
各プラットフォーム用に実装したライブラリを用意する必要がある。
各プラットフォームごとのネイティブコードの呼び出し実装
各プラットフォームようにP/Invoke宣言の対応も追加する。 ライブラリごとにDllImport指定が異なるため、プリプロセッサディレクティブで分岐させる。
ネイテイブプラグインのライフサイクル
- Android
- ロード順序が担保されない
- ライブラリは関数呼出し時にロードされるため、ライブラリをロードするための関数を用意し、依存関係順に呼び出しておく。
- Unity Editor
- ネイテイブプラグインがロードされるのは初回再生時の初回呼び出しのみ
- UnityEditorの再生停止モードには影響されない
- 初期化処理が複数回呼ばれる処理にする
ネイティブコードからマネージドコードを呼び出す実装の注意点
資料参考
フェイルセーフ性の担保
プレイヤーのユーザー体験を損なわないように。開発チームの開発効率を下げないようにする。 すべてのネイティブコード呼び出しは常に安全に実行でき、正しく失敗するようにする。 * マネージドからエラーをハンドリングできる仕組み * ネイティブプラグインで発生したエラーもUnityEditor上から把握できるように
プラットフォームごとのアラインメント問題の考慮
構造体を使用する場合、メモリ上の配置にアラインメントが発生する。 マーシャリング対象のため、アラインメントを意識し構造体を定義する。 * 8byteのフィールドは8の倍数の位置から配置される * その間はパディングとして未使用のフィールドになる
実機上での実行効率
実行効率を上げるためにメモリコピーを回避するようにする。 そのためには、ネイティブ層とマネージド層のそれぞれのヒープを意識する。 * マネージドヒープ * マネージドコードから扱われるヒープ.GCで消されたり移動する可能性がある * ネイティブヒープ
メモリコピーの回避
メモリコピーはマーシャリング時に発生する。 やり取りするデータが大きい・頻度が高い場合はマーシャリングを回避するようにする。 回避策として、Blittable型を使う。 マネージド/ネイティブでメモリレイアウトがおなじになる型のこと。 P/Invokeでマネージド/ネイティブへ受け渡す際にマーシャリングせずに参照渡しができる。 Blittable型を使った参照では、アドレスが保証されるのは関数呼び出し間のみのため、同期呼び出しにしか使用できない。
