LINE Developer Meetup in Kyoto #56 に行ってきた話しLINE Developer Meetup in Kyoto #56 に行ってきた話し

<< | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク

【京都】LINE Developer Meetup #56 - connpass

ここ最近技術系のイベントいっても記事に起こさない事が多いので何の為にメモとってんだろうな となりつつあったし、

今まとまった時間とりやすいので、久し振りに書いておきます。

こないだ『サーバーサイドエンジニアオールスターズ in 関西』にも行ったので、何か書けばよかったな。


後ろの方の畳スペースは段々になってたんだけど、前の椅子スペースの後ろの方に座ったら、

ディスプレイの位置的に割と見づらくなってしまったので失敗した。

左右の画面つかないのかなぁ。

お香

畳スペースにいたヒヨコ けっこう固くてしっかりしていた

スライドは多分そのうち上がるので、感想的なものが中心。

音声認識におけるサーバーサイド開発 市村さん

クローバのサーバーサイドで行っている音声処理とその下地になる音声解析のモデル作成(機械学習)の話し。

○音声認識

まず最初に引数として 音声と単語列を突っ込んでる式が示されてて、最初の段階で単語列なんて定まってるもんなの? っと思ったんだけど、

「単語列」って言葉から想像するような規模感のものではなくて、想定される単語全部の莫大なリストっぽい。

入力された音声は、音響モデルを使って 個々人の個性を削ぎ落した特徴量のデータに変換され、そこからアルファベット1音ずつの音素に分解され、

前後の音と組合せた tri-phone というデータにして言語モデルに渡す。

最終的にその言語モデルが、「日本語らしいもの」を導き出すのだが、これを機械学習で学ばせていくのが音声認識揮発の主体になるようだ。


音響モデルのほうは、マイクとか背景音がかわらなければアップデートされないし年に2度程度。1回の生成には1週間以上かかる。

一方、言語モデルは新語なんかも取り込むので毎週アップデートされていく。

言語モデルの中身は数千万オーダーの単語列。

1工程に1日とかかるし、分散処理がしずらいのでhadoopを使えない部分もある。

評価用のテストデータもめちゃくちゃ多くて、並列化しててもそこだけで1~2日かかる。

結果として1週間に1度更新するスケジュールはかなりカツカツらしい。

○デコーダー

機械学習は莫大な時間をかけて莫大なデータを処理するが、実際にスマートスピーカーに音声が投げられた時に処理するのがデコーダー。

こちらはユーザーにすぐ反応を返さないといけない為、最長数百msecオーダーの音声認識を低レイテンシで返す。

性能と速度はトレードオフな部分があるので、速度を優先して精度を下げる事もあるみたい。

・性能改善

モデル再学習で副作用が大きい物は別処理する。

→ドメイン(専門用語)モデルなんかは別でやったものをマージする。

(特にスマートスピーカーは音楽関連の機能豊富だから、アーティスト名なんかの芸能関係の名詞はゴリゴリにやってそうよね

間違えやすい単語や発話に対する処理(デコーダー側でスコアをみて切り分ける

ノーマライゼーション(乃木坂フォーティーエイト→乃木坂48のような表示のノーマライズ

誤認識をどこの問題か切り分けてフィードバックする などなど

○質疑応答

Q. 吃音症とかもひろえるの?

A. 特徴的な人や子供の表現が難しい

モデル化されてる元データが平均的な男性のボイスを元にしているので、そこから大幅にズレるものは精度が落ちる。

(これ元のセット複数持って、初動であてるモデル切り替えたりみたいなのできたらいいんだろうけど、現状でもリソースやばいの考えると何個もモデル持つのはきつそうだなぁ

っと思ってたらその質問出てきた

まず初動で子供どうか とか知るのが結構大変っぽい(ステップ増やすとレイテンシに影響でるだろうしな

特徴量にする前に捨ててる情報をつかえばできるかもしれないとの事。

(声紋みたいな認識あるけど、あれって速度どうなんやろな。

(個人的にはスマートスピーカーって不特定多数の人が使うシーンよりも、同じ端末からは特定のグループの人しか話しかけない気がするので、そこでパーソナリティ絞るみたいなのはできるんじゃないか?(抜本的な話しではある)

(実際 google アシスタントとか、本人以外の声からの命令は無視する機能とかあった気がするし、ドアの開錠とかセンシティブな機能を提供する時には必要よねぇ

「サーバーサイド」って銘でいきなりアカデミックなサイドの話しになったなぁと感じたが、

確かにクライアントでやらない事は全てサーバーサイドなんだよな......という意味ではくくりが難しいのかもしれない。

infra@line クリス・ピッケルさん

途中は英語でやるっぽいので、みよたさんが翻訳しながら。

基本的にはクリスさんが何故サーバーサイドが好きなのかと、LINE のサーバーインフラが何で構成されているか のお話し。

別のイベントでお聞きしたことがあったので、メモは取らず。

docker はいいぞ!みたいな感じ

Kubernetes の話しもっと聞いてみたくはあるけど、技術的に興味あっても個人的に触る事はなかろうな と思うので難しい。

liffのバックエンド アダムさん

クリエーターズマーケットとかやられてたらしいのでお世話になっている。

箱ペンギン - LINE スタンプ | LINE STORE (宣伝)

今はLIFF(LINE Front-end Framework)のバックグラウンドをやれらてるそうです。

フロントエンドフレームのバックグラウンドという表現の複雑さ。

まったく知らないでもないので、あまりメモらなかったけど LIFF は LINE 上で動く web アプリのプラットフォームで、

LINE の画面にオーバーレイして動く小さなブラウザみたいな感じで、HTLM と JS と CSS で動く。

普段クライアントは talk サーバーの通信してるけど、その間で LIFF のサーバーが動く感じ(?)で、LIFF サーバーがトークン取得したりメッセージ投げたりの API を叩くっぽい。

(これLIFFサーバーにアクセスしてるけど、開発がアップしてんのは静的なファイルだから js が動くのはクライアントよな、悪意があるスクリプトとか動かないのかな

(そもそも動いてるjsのバージョンがどんなもんで、どんくらいサンドボックスかされてんだろうか

→懇親会で聞いてみたけど、普通に WebView で動いてるっぽいので、JS のバージョンは端末に依存するし、破壊的な事されても View だけの事っぽいかな。

LIFFに許可可能な権限はユーザー情報の取得とメッセージの送信の2つだけ

(友達とかは追加できないんだな(悪用されたら怖いが「最大n名の友達を追加する許可」みたいなのできればおもしろそう。 その人数追加しきった所で権限失効する感じで

・Kotlin

ここから kotlin の話し

スライドあったけど null 安全最高!みたいな話し以外はほぼ全部はしょられた

kotlinのコードについていろいろしゃべりたかったが 全部はしょられたけど、軽く Coroutine にもふれた

ロギングの話しにちょっと触れたあと LIFF の v2 の話し。

まずブラウザで動かす事ができるようになったので、開発が凄い楽になる模様。

権限的に許可している人のリストから個人やグループにメッセージ投げれるデモ映像が出ててすごかった。

また、今までモバイルクライアントでしか動いてなかったけど、これだと PC 版でも使えそうとの事。

11月くらいに公開予定

全体の感想

サーバーサイド広いな......

あと、懇親感で色んな人と話した感じ、サーバーサイド専門って人ばっかりじゃなくて けっこう広範囲の人が来てるっぽかった

まぁそもそもインフラやってる人もアプリケーションやってる人もサーバーサイドなわけだし広いわなぁ

今後は9月にオフィスが移動するとして、8月はインターンとかあって お忙しいそうなので、次に何かやるとしても 旧オフィスさよなら会じゃなくて、新オフィス お披露目会になるかも?との事。

ちょうどインターンで8月から来られる という方ともお話したけど、オフィスの移動のタイミングでジョインするの大変そうだなぁ。

トラックバック(0)

トラックバックURL: http://exe.tyo.ro/mt/mt-tb.cgi/1974

コメントする

2022年1月

            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

月別 アーカイブ

2019年
2018年
2016年
2014年
2013年
2012年
2011年
2010年
2009年
2008年
2007年