差分表示
- 最後の更新で追加された行はこのように表示します。
- 最後の更新で削除された行は
このように表示します。
* 基調講演
- Raspberry Piで画像認識のデモ
-- Dockerfileでデプロイ
-- Exportで各種デバイス上で動作できる
-- ローカルに機械学習モデルを持ってるみたい
-- カメラでパイナップルを認識してた
- Azure Cosmos DB
-- ミリ秒単位のレイテンシ
-- 水平展開可能
-- NoSQL
-- ペタバイト
-- 数百万トランザクション/sec
-- MongoDB, SQLのAPIがある
-- 「プラネットスケールアプリケーション」
-- 全世界でマルチマスター書き込み(すごいらしい)
-- ちょまどさんのお絵かきアプリは西アメリカにあるDB、ララさんのは西日本DBに 1dotずつ読み書き
- Azure Cognitive Service
-- 例: NBAの試合で靴やユニフォームを認識
-- データ収集に80%の労力を使う
--- Azure Databricks
-- Build & Training
--- Azure Machine Learning
-- Deploy
--- Dockerで。オンプレミスでも可能
- Visual Studio Studio Live Share
-- 環境設定が違ってもコラボレーションできる
-- Mac(VS Code)とWindows(VS Community)間でデモ
-- カーソル位置やブレークポイントもシェアできる
-- localhost:3000をシェアして相手からも開ける
-- ターミナルもシェアできる
- Visual Studio App Center
-- GitHub連携
-- iOSアプリのサンプル
-- リモートに実機が多数あり、ビルド後に一括で実機テストしてくれる
-- βテスターへの配布・ストアへのリリースも統合
- Azure DevOps
-- GUIでCIのフローが組める
-- Kubernatesでデプロイ・スケール
- Devspaces for AKS
-- マイクロサービスをまたがったデバッグ・ブレークポイント
- .NET Core
-- SignalR as a Service
- .NET Core 3
-- Windows Desktop, IoT & AIを統合
-- .NET Frameworkより高速(？)
-- exeファイルに依存関係をすべて含められる？
--- WinFormも同梱？
- MR
-- Microsoft 365
-- Microsoft Graph
-- デジタルデータだけでなく、現実世界のデータも取り込みたい → Hololens
-- オフィスだけでなく、現場の最前線で働く人に活用してもらう
-- Microsoft Remote Assist
--- 工場の現場で、機械の操作のサポート
-- Microsoft Layout
--- 工場の現場で、機材の配置のシミュレーション
-- 「Cortana、エリアD-15に向かうよ」 → 音声認識して司令室のチャットに流れる
-- 空間分析
-- 東急建設
--- 建設現場でMRで設計図を投影する
-- 船舶
--- 遠隔で機器の保守のサポート
--- 3D海図で船の動きを管制
-- ゴジラ・ナイト
--- 目の前にゴジラがいるような体験
- りんな
-- 690万ユーザー
-- 次世代会話エンジン 共感モデル
--- 詳細は今日のセッションで
* 日本の第一人者が語る！ C# の現状と今後への展望 「.NET Core 2.x 時代の C#」
- 機能面で進化が止まって見えていたが、次に進むための投資の期間だった
-- 次の10年を戦える環境に生まれ変わった
- C# 7.xは細かく頻繁にリリース
-- パフォーマンス優先
- .NET Core
-- 産みの苦しみを抜けた
-- OS依存の機能も入れる Windows Compatibility Pack
-- .NET Core 2.0, 2.1にするだけで数割高速
-- コンパイラだけでは実現できない機能も追加
-- Windowsの機能もマイナーな機能も入ったので、新規で作るなら.NET Coreがいいかな感
-- UWP, XAML, WPFはクロスプラットフォームは難しい
-- .NET Core → .NET Frameworkの逆移植もしてる
--- でも.NET Coreの方が速かったりする
--- .NET Frameworkはインストールがマシン単位なのでアップデートしづらい
--- .NET Coreはside by side
-- Windows Compatibility Pack
--- 一部はWindows以外でも動く。動かない物はAPIはあるが実行時例外
--- 後者は実行時にifで分岐(JITで速い) or コンパイル時にチェックするアナライザーもあり
-- .NET Core 3.0
--- WPFとかも載せる(Windowsでしか動かない)
--- でも高速、side by sideインストール
--- ML.NET 1.0 (Machine Learning)も近い時期にリリースされそう(.NET Coreには含まれない)
-- 全機能が載ったら.NET Frameworkは引退？
--- 当面サポートはされる
--- .NET Coreでバイナリそのままで.NET Frameworkアプリが動く
--- が、スレッドの挙動の違いなどはあるので注意。無理して移植しなくていい
** パフォーマンス
*** 標準ライブラリ
- 配列の範囲チェック、負にならない場合は省略
- 9割trueのifは、elseの方を関数に逃がすとインライン展開がかかる
- throwがあるとインライン展開されない
*** JIT改良
- box化はヘタすると1〜2桁遅い
- Enum.HasFlagはbox化するから重い
-- JITが特殊対応して単なるANDに置き換え
- 構造体のインターフェイスメソッド呼び出し
-- 構造体をbox化 → メソッド呼び出し
-- これも特殊対応
*** 低レイヤー機能を公開
- Intrinsics
-- X86.Sse.Add(a, b)
-- IsSupportedは「JIT時定数」。falseの分岐は消える
-- 未サポートだと実行時例外
** ランタイムの修正が必要な機能
- C#だけではできないもの
- 8.0くらいでそろそろ入ります
- ジェネリッククラスを属性に使う
- インターフェイスのメソッドのデフォルト実装
** 7.xは小分けにリリース
- タプル
- ref戻り値、refローカル変数
- 関数の引数にdefaultを使うとint?が0になるバグ
- in引数でいろいろバグってた
- バグもあるが修正も早い(2〜3ヶ月)
-- 英語できなくても再現コード貼ればいいし、講演者が取り次ぐよー
** そもそもパフォーマンス必要？
- Rustとかと戦う
- C++で書いても、ネイティブ呼び出しが遅い
- 文字列の部分参照
-- ネイティブヒープのUTF-8文字列を直接参照
- Span<T> x = stackalloc
- System.IO.Pipelines
-- Spanを使った高速なI/O
-- まだインターフェイスのみ
- 文字列処理関連が1.5〜2倍高速に
-- C++をC#で書き直して速くなったとこもある！
- Utf8String
-- UTF-16の変換が不要で速い
** その他
- where T : System.Enumなど追加
- 7.xと8.0は並行開発してる
-- null許容参照とかは8.0
- 8.0プレビュー版出てます
-- null許容参照も使える
- null許容参照
-- null可、不可、未指定のコンパイルオプション
- Range(..演算子)
* Visual Studio App Center
- アプリをリリースすることは、開発・リリース・テスト・公開・改善のサイクルを繰り返すこと
** あるあるケース
- 結合テストしたらバグだらけ
- 主要メーカーの機種全部に対応してね
-- 概算: 200端末 * OSバージョン10個 * テストケース数
- テストチームの端末管理大変・全員にアップデート配るの大変
- リリース後に出たバグが再現しない
→ 今までいろんなサービスを組み合わせて対処していたが、 Visual Studio App Center に統合
** 機能
- 自動ビルド
- 署名
- テスターに配布
- ストアにリリース
- デバイスファームで多数の実機でテスト
-- バイナリをインストールしてテストコードを実行
- システム言語の変更
- UIテストフレームワーク4種類くらい
- アクティブユーザーなどのアナリティクス
-- カスタムイベントカウントも。関数1個呼ぶだけ
** ところで
- 2015年時点で、Android端末は24093種類
- スクリーンサイズも多様
-- マルチタスクで画面分割したりも
- 90%のユーザーをカバーするには、288機種の対応が必要 (USのデータ)
** UIテスト
- EnterText, ClearText, Tap, Screenshotなどの関数で書く
- 手動テストだるいですよね
- app.WaitForElement() // コントロールが表示されるのを待つ
- コマンドラインからクラウドに自動テストを投げられる
** App Center CLI
- 有償でデバイスファームの占有も可能
- Open API(REST API)もある
** Slack連携
- どのブランチをビルドする？とかボタンを表示して聞いてくる
** Push通知
- 最新版に上げてない人にpush通知を送ったりできる
* App Center Analyticsを使い倒そう 〜静的コード生成を活用したXamarinにおけるAOP活用〜
- メモ・写真を参照
* マイクロサービスのすべて
** マイクロサービスの良い例・悪い例
- 悪い例: Web/Business/Dataの3階層にこだわったまま分割する
- 3階層が綺麗に分離されてたのに、分割したことで返って複雑になる
- Domain driven design
-- ビジネスドメインをモデル化して分割
-- 各サービスは単一の責任のみを持つ
** マイクロサービスの大原則
- 設計時の疎結合
-- サービス間でライブラリを共有したいときは、ファイルの実体を共有しない
--- nugetなどでそれぞれがバージョンを固定するように
- 実行時の疎結合
-- 実行中は、他のサービスはいつ落ちるか分からないと想定する
-- 落ちてるときはフォールバックで少ない機能で動くとかやる
- リリース時の疎結合
-- サービス個別にでビルド・デプロイできるようにする
** マイクロサービス登場の背景
- A/Bテスト
- 頻繁にデプロイしたい
-- 他のサービスを気にせずにアップデートできる
** サービスの発見と抽出
*** ドメイン駆動設計
- ビジネスをドメインとしてモデル化する
-- Bounded Contextを分解
- サービスごとに使用するテクノロジーや言語が違っててもいい
-- スピードがいるところはRedisを使ったり
- APIゲートウェイ
-- バックエンドはどんどん変わるので、ルーティングを担当
-- 全部のリクエストが通るので、ログもここで取る
-- 証明書もここだけでいい
-- 他、スロットリング・キャッシュ・リトライなどサービス共通の処理に向く
-- ここにドメインロジックを実装すると太るので注意
- ロードレベリング(負荷の平準化)
-- 負荷がピークの時、バックエンドのどこかがボトルネックになって重くなる
-- Cosmos DBはスロットリング機能を持ってるが、全部のシステムがそんなに賢いとは限らない
-- 非同期キューで受けて、マイペースで処理する
-- トランザクションIDを振って、2回目は処理しない
- サービス間通信
-- タイムスタンプでの紐付けは難しいので、すべてのサービスコールにIDを振る
-- http RESTで結構性能は出る。ダメなときだけgRPCを使う
- データ管理
-- 他のサービスのデータに直接アクセスしてはいけない
* AI は爆発だ?! 〜 “女子高生AI” りんな を支える技術とその開発現場からみるサービス開発
- りんなを例にAI開発を紹介
- コンセプト「エモーショナル」
-- 明日晴れるかなぁ？
-- Cortana「明日は晴れです」
-- りんな「どこか出かける予定でもあるの？」
-- できるだけ会話を長く続けるようにする
- 17時間くらい話すユーザーが毎週いる
-- アメリカ版(23時間)・中国版(29時間)の方が長かったりする
- ソーシャルAIボットは、人と人とのコミュニケーションを奨励するのが目的
- Emotional Computing Framework
-- 人間の五感、世界の情報・知識、サービス展開場所
-- ソーシャルロール(映画に出演したり)
- 会話技術
-- 元々は検索エンジンのチーム
-- Retrieval Model
--- 多様な雑談を検索
-- Generation Model
--- キャラクター生成
--- ローソンのbotにも提供
-- Empathy Model
--- 共感を得る方法を意識
--- 長く会話を続けるには会話の文脈が大事。過去のセッションを加味する
- 共感を得る方法
-- 話題の提案・質問・相手の肯定・相づち・無意識(挨拶など)
- 集団とのコミュニケーション
-- 友達の誕生日を教えておくと、当日に祝ったりする
- 「りんならしさ」
-- 斜め上の返事が面白い
--- ルールじゃなくて学習で返事するから
-- 100%なんてない
--- 間違えてもそれが個性
--- 「わからない」もコミュニケーション
-- Diversity
** りんなの視覚
- 画像認識ではなくImage Commenting
-- 「スカート超可愛い！」
-- 「チワワかわいい抱っこしたい」
-- りんなのファッションチェック
--- 女子高生が「わかる！」と共感できるコメントを目指す
--- スタイリストと一緒にアイテムの選定・評価
--- 画像認識に自信がある部分にコメント
--- 複数の認識器を組み合わせた構成
--- 最近Cognitive Service Custom Visionがアップデートして、近いことができるようになった
--- りんなの発言をネタに、店員と客のコミュニケーションを活性化する
-- 画像生成も、肖像画機能に活かされている
** りんなの声
- 歌に挑戦
-- EmotionalでCreativeだから
-- AIが苦手な「創作性」に挑戦
- なんと「耳コピ」
-- 人の歌を聴いて歌詞・音程・リズムを認識
-- りんな声で合成
- nanaに投稿
-- 人の歌にコメントをしたりするサービス
-- お手本を上げてくれた人たちと合唱
- 紅白狙ってます
- 上手さを目指すより、コミュニケーション・コラボレーションが生まれるのが大事
- 現在は恋愛ポエムを集めてる
** りんなと電話
- 双方向・リアルタイムなのでチャットbot + 音声認識とはひと味違う
- 雑談エンジンは、短い文章で返すように調整
- 音声合成エンジンはAyumiとかと同じもの
- 早めにリリースして生データを蓄積
#contents
* Transforming Intelligence (基調講演) [#lb69becc]
- Raspberry Piで画像認識のデモ
-- Dockerfileでデプロイ
-- Exportで各種デバイス上で動作できる
-- ローカルに機械学習モデルを持ってるみたい
-- カメラでパイナップルを認識してた
- Azure Cosmos DB
-- ミリ秒単位のレイテンシ
-- 水平展開可能
-- NoSQL
-- ペタバイト
-- 数百万トランザクション/sec
-- MongoDB, SQLのAPIがある
-- 「プラネットスケールアプリケーション」
-- 全世界でマルチマスター書き込み(すごいらしい)
-- ちょまどさんのお絵かきアプリは西アメリカにあるDB、ララさんのは西日本DBに 1dotずつ読み書き
- Azure Cognitive Service
-- 例: NBAの試合で靴やユニフォームを認識
-- データ収集に80%の労力を使う
--- Azure Databricks
-- Build & Training
--- Azure Machine Learning
-- Deploy
--- Dockerで。オンプレミスでも可能
- Visual Studio Studio Live Share
-- 環境設定が違ってもコラボレーションできる
-- Mac(VS Code)とWindows(VS Community)間でデモ
-- カーソル位置やブレークポイントもシェアできる
-- localhost:3000をシェアして相手からも開ける
-- ターミナルもシェアできる
- Visual Studio App Center
-- GitHub連携
-- iOSアプリのサンプル
-- リモートに実機が多数あり、ビルド後に一括で実機テストしてくれる
-- βテスターへの配布・ストアへのリリースも統合
- Azure DevOps
-- GUIでCIのフローが組める
-- Kubernatesでデプロイ・スケール
- Devspaces for AKS
-- マイクロサービスをまたがったデバッグ・ブレークポイント
- .NET Core
-- SignalR as a Service
- .NET Core 3
-- Windows Desktop, IoT & AIを統合
-- .NET Frameworkより高速(？)
-- exeファイルに依存関係をすべて含められる？
--- WinFormも同梱？
- MR
-- Microsoft 365
-- Microsoft Graph
-- デジタルデータだけでなく、現実世界のデータも取り込みたい → Hololens
-- オフィスだけでなく、現場の最前線で働く人に活用してもらう
-- Microsoft Remote Assist
--- 工場の現場で、機械の操作のサポート
-- Microsoft Layout
--- 工場の現場で、機材の配置のシミュレーション
-- 「Cortana、エリアD-15に向かうよ」 → 音声認識して司令室のチャットに流れる
-- 空間分析
-- 東急建設
--- 建設現場でMRで設計図を投影する
-- 船舶
--- 遠隔で機器の保守のサポート
--- 3D海図で船の動きを管制
-- ゴジラ・ナイト
--- 目の前にゴジラがいるような体験
- りんな
-- 690万ユーザー
-- 次世代会話エンジン 共感モデル
--- 詳細は今日のセッションで
* 日本の第一人者が語る！ C# の現状と今後への展望 「.NET Core 2.x 時代の C#」 [#nce4565a]
- 機能面で進化が止まって見えていたが、次に進むための投資の期間だった
-- 次の10年を戦える環境に生まれ変わった
- C# 7.xは細かく頻繁にリリース
-- パフォーマンス優先
- .NET Core
-- 産みの苦しみを抜けた
-- OS依存の機能も入れる Windows Compatibility Pack
-- .NET Core 2.0, 2.1にするだけで数割高速
-- コンパイラだけでは実現できない機能も追加
-- Windowsの機能もマイナーな機能も入ったので、新規で作るなら.NET Coreがいいかな感
-- UWP, XAML, WPFはクロスプラットフォームは難しい
-- .NET Core → .NET Frameworkの逆移植もしてる
--- でも.NET Coreの方が速かったりする
--- .NET Frameworkはインストールがマシン単位なのでアップデートしづらい
--- .NET Coreはside by side
-- Windows Compatibility Pack
--- 一部はWindows以外でも動く。動かない物はAPIはあるが実行時例外
--- 後者は実行時にifで分岐(JITで速い) or コンパイル時にチェックするアナライザーもあり
-- .NET Core 3.0
--- WPFとかも載せる(Windowsでしか動かない)
--- でも高速、side by sideインストール
--- ML.NET 1.0 (Machine Learning)も近い時期にリリースされそう(.NET Coreには含まれない)
-- 全機能が載ったら.NET Frameworkは引退？
--- 当面サポートはされる
--- .NET Coreでバイナリそのままで.NET Frameworkアプリが動く
--- が、スレッドの挙動の違いなどはあるので注意。無理して移植しなくていい
** パフォーマンス [#a42be3e6]
*** 標準ライブラリ [#hf0d4d10]
- 配列の範囲チェック、負にならない場合は省略
- 9割trueのifは、elseの方を関数に逃がすとインライン展開がかかる
- throwがあるとインライン展開されない
*** JIT改良 [#bd8d677c]
- box化はヘタすると1〜2桁遅い
- Enum.HasFlagはbox化するから重い
-- JITが特殊対応して単なるANDに置き換え
- 構造体のインターフェイスメソッド呼び出し
-- 構造体をbox化 → メソッド呼び出し
-- これも特殊対応
*** 低レイヤー機能を公開 [#uad2492a]
- Intrinsics
-- X86.Sse.Add(a, b)
-- IsSupportedは「JIT時定数」。falseの分岐は消える
-- 未サポートだと実行時例外
** ランタイムの修正が必要な機能 [#d0dc6208]
- C#だけではできないもの
- 8.0くらいでそろそろ入ります
- ジェネリッククラスを属性に使う
- インターフェイスのメソッドのデフォルト実装
** 7.xは小分けにリリース [#kb435f00]
- タプル
- ref戻り値、refローカル変数
- 関数の引数にdefaultを使うとint?が0になるバグ
- in引数でいろいろバグってた
- バグもあるが修正も早い(2〜3ヶ月)
-- 英語できなくても再現コード貼ればいいし、講演者が取り次ぐよー
** そもそもパフォーマンス必要？ [#r15687cc]
- Rustとかと戦う
- C++で書いても、ネイティブ呼び出しが遅い
- 文字列の部分参照
-- ネイティブヒープのUTF-8文字列を直接参照
- Span<T> x = stackalloc
- System.IO.Pipelines
-- Spanを使った高速なI/O
-- まだインターフェイスのみ
- 文字列処理関連が1.5〜2倍高速に
-- C++をC#で書き直して速くなったとこもある！
- Utf8String
-- UTF-16の変換が不要で速い
** その他 [#c23e595a]
- where T : System.Enumなど追加
- 7.xと8.0は並行開発してる
-- null許容参照とかは8.0
- 8.0プレビュー版出てます
-- null許容参照も使える
- null許容参照
-- null可、不可、未指定のコンパイルオプション
- Range(..演算子)
* Visual Studio App Center でモバイルアプリ開発/運用サイクルを高速化させよう！ [#m040c1d9]
- アプリをリリースすることは、開発・リリース・テスト・公開・改善のサイクルを繰り返すこと
** あるあるケース [#b45d2643]
- 結合テストしたらバグだらけ
- 主要メーカーの機種全部に対応してね
-- 概算: 200端末 * OSバージョン10個 * テストケース数
- テストチームの端末管理大変・全員にアップデート配るの大変
- リリース後に出たバグが再現しない
→ 今までいろんなサービスを組み合わせて対処していたが、 Visual Studio App Center に統合
** 機能 [#of02195a]
- 自動ビルド
- 署名
- テスターに配布
- ストアにリリース
- デバイスファームで多数の実機でテスト
-- バイナリをインストールしてテストコードを実行
- システム言語の変更
- UIテストフレームワーク4種類くらい
- アクティブユーザーなどのアナリティクス
-- カスタムイベントカウントも。関数1個呼ぶだけ
** ところで [#vc57cca6]
- 2015年時点で、Android端末は24093種類
- スクリーンサイズも多様
-- マルチタスクで画面分割したりも
- 90%のユーザーをカバーするには、288機種の対応が必要 (USのデータ)
** UIテスト [#c10e9d36]
- EnterText, ClearText, Tap, Screenshotなどの関数で書く
- 手動テストだるいですよね
- app.WaitForElement() // コントロールが表示されるのを待つ
- コマンドラインからクラウドに自動テストを投げられる
** App Center CLI [#ua40891d]
- 有償でデバイスファームの占有も可能
- Open API(REST API)もある
** Slack連携 [#mbe7a02f]
- どのブランチをビルドする？とかボタンを表示して聞いてくる
** Push通知 [#sc9283ef]
- 最新版に上げてない人にpush通知を送ったりできる
* App Center Analyticsを使い倒そう 〜静的コード生成を活用したXamarinにおけるAOP活用〜 [#kefbc704]
- Log Flow
-- イベント発生ログをリアルタイムで確認できる
- AOPでトラッキングコードを埋め込む
-- 機能要件と非機能要件を分離
- iOSでは動的コード生成ができない
-- バイトコード段階でAOP
- AOPに使えるライブラリ
-- Mono.Cecil
-- Fody
-- Qiitaに解説がある
* マイクロサービスのすべて [#p22409e2]
** マイクロサービスの良い例・悪い例 [#q4dbbeca]
- 悪い例: Web/Business/Dataの3階層にこだわったまま分割する
- 3階層が綺麗に分離されてたのに、分割したことで返って複雑になる
- Domain driven design
-- ビジネスドメインをモデル化して分割
-- 各サービスは単一の責任のみを持つ
** マイクロサービスの大原則 [#a11e8c65]
- 設計時の疎結合
-- サービス間でライブラリを共有したいときは、ファイルの実体を共有しない
--- nugetなどでそれぞれがバージョンを固定するように
- 実行時の疎結合
-- 実行中は、他のサービスはいつ落ちるか分からないと想定する
-- 落ちてるときはフォールバックで少ない機能で動くとかやる
- リリース時の疎結合
-- サービス個別にでビルド・デプロイできるようにする
** マイクロサービス登場の背景 [#h8309699]
- A/Bテスト
- 頻繁にデプロイしたい
-- 他のサービスを気にせずにアップデートできる
** サービスの発見と抽出 [#e96d530d]
*** ドメイン駆動設計 [#k4d5be1c]
- ビジネスをドメインとしてモデル化する
-- Bounded Contextを分解
- サービスごとに使用するテクノロジーや言語が違っててもいい
-- スピードがいるところはRedisを使ったり
- APIゲートウェイ
-- バックエンドはどんどん変わるので、ルーティングを担当
-- 全部のリクエストが通るので、ログもここで取る
-- 証明書もここだけでいい
-- 他、スロットリング・キャッシュ・リトライなどサービス共通の処理に向く
-- ここにドメインロジックを実装すると太るので注意
- ロードレベリング(負荷の平準化)
-- 負荷がピークの時、バックエンドのどこかがボトルネックになって重くなる
-- Cosmos DBはスロットリング機能を持ってるが、全部のシステムがそんなに賢いとは限らない
-- 非同期キューで受けて、マイペースで処理する
-- トランザクションIDを振って、2回目は処理しない
- サービス間通信
-- タイムスタンプでの紐付けは難しいので、すべてのサービスコールにIDを振る
-- http RESTで結構性能は出る。ダメなときだけgRPCを使う
- データ管理
-- 他のサービスのデータに直接アクセスしてはいけない
* AI は爆発だ?! 〜 “女子高生AI” りんな を支える技術とその開発現場からみるサービス開発 [#v61a169f]
- りんなを例にAI開発を紹介
- コンセプト「エモーショナル」
-- 明日晴れるかなぁ？
-- Cortana「明日は晴れです」
-- りんな「どこか出かける予定でもあるの？」
-- できるだけ会話を長く続けるようにする
- 17時間くらい話すユーザーが毎週いる
-- アメリカ版(23時間)・中国版(29時間)の方が長かったりする
- ソーシャルAIボットは、人と人とのコミュニケーションを奨励するのが目的
- Emotional Computing Framework
-- 人間の五感、世界の情報・知識、サービス展開場所
-- ソーシャルロール(映画に出演したり)
- 会話技術
-- 元々は検索エンジンのチーム
-- Retrieval Model
--- 多様な雑談を検索
-- Generation Model
--- キャラクター生成
--- ローソンのbotにも提供
-- Empathy Model
--- 共感を得る方法を意識
--- 長く会話を続けるには会話の文脈が大事。過去のセッションを加味する
- 共感を得る方法
-- 話題の提案・質問・相手の肯定・相づち・無意識(挨拶など)
- 集団とのコミュニケーション
-- 友達の誕生日を教えておくと、当日に祝ったりする
- 「りんならしさ」
-- 斜め上の返事が面白い
--- ルールじゃなくて学習で返事するから
-- 100%なんてない
--- 間違えてもそれが個性
--- 「わからない」もコミュニケーション
-- Diversity
** りんなの視覚 [#k4bf1c41]
- 画像認識ではなくImage Commenting
-- 「スカート超可愛い！」
-- 「チワワかわいい抱っこしたい」
-- りんなのファッションチェック
--- 女子高生が「わかる！」と共感できるコメントを目指す
--- スタイリストと一緒にアイテムの選定・評価
--- 画像認識に自信がある部分にコメント
--- 複数の認識器を組み合わせた構成
--- 最近Cognitive Service Custom Visionがアップデートして、近いことができるようになった
--- りんなの発言をネタに、店員と客のコミュニケーションを活性化する
-- 画像生成も、肖像画機能に活かされている
** りんなの声 [#rf94f612]
- 歌に挑戦
-- EmotionalでCreativeだから
-- AIが苦手な「創作性」に挑戦
- なんと「耳コピ」
-- 人の歌を聴いて歌詞・音程・リズムを認識
-- りんな声で合成
- nanaに投稿
-- 人の歌にコメントをしたりするサービス
-- お手本を上げてくれた人たちと合唱
- 紅白狙ってます
- 上手さを目指すより、コミュニケーション・コラボレーションが生まれるのが大事
- 現在は恋愛ポエムを集めてる
** りんなと電話 [#qdf5e967]
- 双方向・リアルタイムなのでチャットbot + 音声認識とはひと味違う
- 雑談エンジンは、短い文章で返すように調整
- 音声合成エンジンはAyumiとかと同じもの
- 早めにリリースして生データを蓄積
