Open GENZITSU opened 2 years ago
GENZITSU
commented
2 years ago sudachipyび0.6.0-rc1バージョンがプレリリースされた。
rust実装に切り替わったことで30倍ほど高速化したとのこと。
Python
- Mostly compatible with SudachiPy 0.5.4
- We provide binary wheels for popular platforms
- ~30x faster than 0.5.4
30倍も早くなるのであれば、mecabの代替案としてかなり有用そうな気がする。
GENZITSU
commented
2 years ago パッケージ管理ツールのnpmで公開されている「UAParser.js」は、ユーザーエージェントの判定処理を実行するJavaScriptライブラリであり、Facebook・Microsoft・Amazon・Googleなどの超大手企業を含む1000以上のプロジェクトで採用されています。そんなUAParser.jsがハッカーによってハイジャックされ、LinuxおよびWindowsデバイスを対象に暗号資産採掘やパスワードの盗難を行うトロイの木馬が仕込まれていたことが判明しました。
alman氏はnpmアカウントのハッキングに気付いてから数時間後に、問題を修正したクリーンなUAParser.jsのバージョン(0.7.30、0.8.1、1.0.1)をリリースしました。記事作成時点では、欠陥のあるパッケージ「0.7.29、0.8.0、1.0.0」はnpmサポートを通じて非公開とされており、ダウンロードできない状態になっています。
有名ライブラリでもハッキングされてマルウェアを仕込まれることがあるんだな...
GENZITSU
commented
2 years ago DL1インスタンスは、汎用GPUと比較して低コストで高い計算効率を提供することで、機械学習モデルのトレーニングを加速するために特別に構築されたGaudiアクセラレータを最大8基使用
なお、DL1インスタンスは現時点で、米国東部（バージニア北部）、および米国西部（オレゴン）リージョンにて利用可能となっている。
GPUが搭載されているというわけではないのだろうか...?
特別なアクセラレータゆえに非GPUでも高速に学習できるということか？
GENZITSU
commented
2 years ago デジタル庁は10月26日、日本政府の共通クラウド基盤「ガバメントクラウド」として、「Amazon Web Services」と「Google Cloud Platform」を選んだと発表した。「公募に3社の応募があったが、セキュリティや業務継続性など350の項目を満たした2社を選定した」（同庁）という。
MSのAzureは落ちたようだ。
デジタル庁は今後、同庁のWebサービスなどをAWSとGCPで構成したマルチクラウド基盤に構築。他省庁の新システムなども、クラウド移行を行う場合はガバメントクラウドの活用を検討する。自治体のシステムの提供基盤も2025年度末までに共通化
おーaws, gcpはしばらく盤石か！？
GENZITSU
commented
2 years ago AWS, Azure, GCP, IBM Oracle, Alibaba各社のクラウドサービスが提供するサービスの対応関係がまとめられている。
メインで使っているサービスとは別のサービスを使う際に便利そうだ、
GENZITSU
commented
2 years ago コードレビューを円滑に行うためのtipsとコードレビューを通したチームビルディングのtipsがまとめられている、良スライド。
レビューで見るべきところ
ケーススタディ
コードレビューのスピード
コードレビューにはメンタリングの側面もある
チームのパフォーマンスを上げるには
コードレビューの文化がしっかり根付いた組織で働いたことがないので、とても参考になる。
特にコードレビューのレスポンスを早くするというのは、存外大事かもしれない。
実装ありがとう！とかでもいいっぽい。
GENZITSU
commented
2 years ago 商品名からキーワードを予測するタスクの紹介。抽出ではなく予測であることがミソ。
食品キーワードの種類は非常に多岐にわたりロングテールな分布となることで、予測モデルの性能悪化がみこまれたが、 食品キーワードの中には対応する言葉が存在するので、商品名とキーワードの類似度ベースの手法を考案したとのこと。
実際にデータを見てみると商品名の中には食材キーワードに対応する言葉が入っている場合がほとんどです．例えば，食材キーワードとして「にんじん」が設定された商品名をみると「にんじん」「人参」「キャロット」などの単語が入っていたり，「えび」がキーワードに設定されている商品名なら「エビ」「海老」あるいは「ブラックタイガー」のような単語が含まれています
それぞれのベクトルを作る際に、attentionを噛ませることで、キーワードに関連しない単語の重みを低くして平均を取ることが可能になるとのこと。
その結果予測モデルベースの手法と比べて、類似度比較ベースの手法がacc@5でかなりのゲインを発揮するという結果となった。
この手法の利点としては、
逆に欠点としては
白」が含まれる単語同士は互いに近くにあるらしく「白ワイン」に対する推薦結果に「白なす」や「白玉ねぎ」が含まれたりします．このように区別したい性質を超え て多くのデータ点と近いベクトルが現れることは「ハブネス問題」と呼ばれる
予測問題ではなく、類似度のマッチで見るアプローチが面白かった。
LSTM(重み共有)だけでも、acc@5が90を超えるので、推論が問題であればattention無しでも良い気がする。
(何なら簡易的なTFIDF重みをかけるとかでも良さそう？)
ちなみに、なぜこの手法がうまくいくかを考えたのだが、ラベル側の意味をモデルが考慮できるからということな気がする。
普通のNNであれば結局は最終Dense層の重みの各行がラベルベクトルに相当するので、行って仕舞えばそのベクトルとの類似度を測っているわけなのだが、今回の手法だとこのラベルベクトルを目標テキストからも学習できるから良いということなんだろうか。
GENZITSU
commented
2 years ago 文章やイラストなどを投稿できるコンテンツ配信サービス「note」。コロナ禍以降は巣ごもり需要にも後押しされてユーザー数が急増しており、2020年には月間アクティブユーザー数が前年同期比で3倍以上に増えたという。
noteのサービスを支えるシステムは、全てAWS（Amazon Web Services）のクラウドインフラ上で構築・運用しており、トラフィック急増でその利用コストは約10倍にまで膨れ上がった。
限られた人しかコスト感を把握できていなかった状況を誰もが参照できるように変えた
「もともと一部の担当者がAWSの管理コンソールを通じて利用コストをチェックしてはいたが、限られた範囲の情報しか取得できなかった」。 「そこでまずは、より詳細な情報を可視化できるようにして、かつそれを全社員が参照できる仕組みを構築することにした」（同）
ダッシュボートの開発には以下のような機能を使った。
AWSの使用状況をレポートする機能「AWS Cost Usage and Report」を使い、リソースの利用状況とコストに関するより詳細な情報をCSVデータとして取得するようにした。これをオンラインストレージ「Amazon S3」（Amazon Simple Storage Service）のバケットに保管した上で、データ分析PaaS「Amazon Athena」を通じてクエリを投げ、集計・分析。その結果をダッシュボードツール「Redash」上に表示する仕組みを構築した
無駄なコストの筆頭はログ周りだったとのこと
「AWSはログデータを保管しているだけでコストが発生するので、本来は不要なログが発生しないようサービスを設定したり、古いログを削除・上書きする設定を適切に行ったりする必要がある。しかし幾つかのサービスではそうした考慮がなされないまま、ずっとログが垂れ流しになっていた」
いつ誰がとったのか分からない古いスナップショットデータも数多く残っており、これらを保管するためのコストがかなり掛かっていた。
より詳細に把握するためにチームごとの利用コストが見えるように、チーム別のタグを作成
より細かな粒度でコストを分析するための仕組みも順次追加していった。特に重視したのが、チームごとの利用コストの可視化だ。 そこでAWSリソースを作成するときに、必ずチームを識別するタグを付けてもらうよう社内のチームに要請。
異常検知的な手法も取り入れて、無駄なコストの把握に励んでいる
イレギュラーな理由によるコスト増加の検知には、20年12月にリリースされた「AWS Cost Anomaly Detection」（コスト異常検出）という機能を活用。この機能は機械学習を使って、過去の傾向から外れた異常なAWS利用コストを自動検出し、ユーザーに通知してくれるものだ。
クラウドサービスは手軽に始められる一方で、ビジネスやチーム、プロジェクトが拡大していくと無駄が増えていくので、定期的な棚卸しが必要に思える。
GENZITSU
commented
2 years ago WebRTCの開発当初はどれくらいのスペックのサーバーがどれくらい必要なのか不明という環境から、awsを選択した。
しかし導入してみると、awsの費用がどんどん嵩む事態に陥る。
分析をしてみるとcentOS7は使用ソフトウェアとの噛み合わせが悪い事が判明し、centOS8に切り替えることでパフォーマンス向上を果たしたものの、それでも増えるという事態に。
より詳しく分析してみるとネットワーク通信量がコスト全体の75%を食っていたが判明
DMMはオンプレ基板と400gbpsのネットワークの契約帯域をもっていたため、awsからオンプレへの移行を決定。 費用比較としてはサーバー代はawsの方が安かったものの、ネットワーク費用が95%も安くなるという内訳だった。
もちろん変化に強いというクラウドの強みもあるものの、運用が安定してくるとオンプレの良さが際立ってくるということ。
awsのネットワーク通信料によってkaggleで数十万溶かした話を聞いたことがあるが、やはりawsの通信費用は結構高いんだなと。(今後下がっていくことになるのかな...?)
プロジェクトの成否や運用方法が不確実な時はawsを利用し、固まってきたところでオンプレに乗り換えるというのは技術的な負荷はかかるが良い戦略だと思う。
GENZITSU
commented
2 years ago ①本社の代わりに、世界中で採用して世界中で働く ②決められた労働時間よりも、柔軟な労働時間を ③口頭で説明するよりも、書面にして知識を記録 ④オンザジョブトレーニング（OJT）よりも、やり方を書面に ⑤知る必要があるときだけ教えるよりも、情報公開を ⑥ドキュメントをトップダウンで管理するよりも、誰でも編集できるように ⑦同期的なコミュニケーションよりも、非同期的なコミュニケーションを ⑧労働時間よりも、仕事の成果を ⑨非公式なコミュニケーションチャネルよりも、公式なコミュニケーションチャネルを
①オフィスや拠点での経験をリモートで再現しないこと ②対面式の会議をすべてバーチャルに移行してはいけない ③誰もが最適なワークスペースを利用できると思わないこと ④あれをする、これをしない ⑤リモートが一夜にして実現するとは思わないこと ⑥リモート管理が大幅に変わると思わないこと ⑦既存の価値観がそのままでいいと思わないこと
- ソーシャル・コール: 任意の通話でアジェンダを設定せず、ただオープンに話すことができます。
- コーヒー・チャット: 仕事以外のことでもお互いを知ることができる同僚との一対一のビデオチャット。
- コワーキングコール: 困難な作業を同僚と一緒に行ったり、別の作業をしながら談笑したりするスケジュールされたワーキングセッション。
- 共有する興味のためのチャットチャンネル: Slack（または他のチャットツール）で、思いつく限りの興味や趣味のチャンネルを開く。
- 何でも聞いてください(AMAS): チームメンバーがホストに好きな質問をすることができる、オープンアジェンダのコール。
- タレントショー＆トーナメント: 同僚同士の有意義なつながりを築くのに最適で、比較的簡単に開催できます。
- サンクスチャンネル: チームメンバーが他のメンバーへの感謝の気持ちを共有する専用の公開チャットチャンネル。
- メンタルヘルスに関するプロセスの文書化
- 偏見のない文化を作る
- 長時間労働を賞賛しない
- 休息と休暇は生産的である
- 健康的なリモートライフスタイルを奨励する
個人的に印象に残ったもの
GENZITSU
commented
2 years ago 自然言語処理にまつわるサービスを提供する際に、著作権法的に注意しなくてはならない要素が整理されている。
この手のサービスを提供する際は、学習フェーズと推論フェーズで別々の問題を検討する必要がある。
学習フェーズでは以下のような事項に注意する必要がある。
- 「モデルの学習のためにどのように適法にデータやデータセットを収集するか」 -「BERT等のOSSのライセンスの解釈の仕方」 -「学習済みモデルの知財の帰属」
特に「モデルの学習のためにどのように適法にデータやデータセットを収集するか」については著作権の適法な処理が問題となりますし、個人情報が含まれたテキストデータであれば個人情報保護法等の処理も必要となります。
推論フェーズでの問題としては以下のような事項に注意する必要がある
-「事業者がどのような点に注意してサービス設計をすべきか」の問題です。 -「自然言語系AIサービスにおいて出力されたデータについてどのような権利が発生し、当該出力データを誰がどのような形で利用できるか」
後者の問題は、当該出力データが著作物なのか、著作物だとして入力データと同一性・類似性を有するかによって結論が分かれます。
「入力→処理→出力」のプロセスのうち「処理」「学習」については、AIモデルを利用した処理やAIモデルの学習行為である限りにおいては、仮に無許諾の著作物が入力されたとしても、著作権侵害は問題となりません。
著作権法30条の4第2号・3号において以下のとおり一定の場合は著作権者の承諾なく著作物を利用することができると定められており、AIモデルを利用した情報処理やAIモデルの学習行為には、この条文が適用されるためです。
すなわち、AIモデルを利用した情報処理についてはバックエンドで人が全く対象データを知覚することなく行われているため、「著作物の表現についての人の知覚による認識を伴うことなく当該著作物を電子計算機による情報処理の過程における利用その他の利用（に供する）行為」（3号）に該当しますし、AIモデルの学習行為は、「情報解析」（2号）に該当します。
この「非著作物→処理→非著作物」のサービスの例は所在検索サービスです。 典型的にはウェブ検索サービスや書籍検索サービスです。それらの検索サービスにおいては、検索対象語句（通常は非著作物）を入力すると、該当サイトのURLや書籍の所在情報（非著作物）が出力されます。
googleなどのように検索結果にスニペットなどを表示するケースも適法とみなされることが多く、検索システム作るための情報収集も適法とみなされる。
所在検索サービスの提供に伴う著作物の利用は、それが「軽微」な利用である限り適法とされています（著作権法47条の5）。したがって、これらのスニペット表示や書籍の一部分の利用は適法です（詳細は後述します）。
サービス提供者が予め大量の著作物を収集してモデルを生成しておく必要がありますが、そのような著作物の利用行為が適法か、の問題は冒頭で紹介した「モデル構築フェーズの問題」です。そして、結論だけ言うと、当該蓄積（複製）行為は適法です（著作権法30条の4第2号、同47条の5第2項）。
① 著作物を蓄積して、それを出力するパターン
このパターンは著作物の複製にあたり、事前に許諾をとっていないとダメ。
事業者が予め収集・蓄積していた著作物をそのままユーザーに出力（送信）する場合、当該出力（＝複製・公衆送信）行為は事業者の行為となり、かつ当該出力行為は「情報解析」等（30条の4）にも該当しません。これは、検索語から適切な出力対象を選択する部分にAI技術が使われていたとしても同様です。 したがって、事業者によるユーザーへの著作物の出力（送信）が無許諾の行為であれば、普通に著作権侵害に該当します。
ただし、軽微利用の例外という条項があるのだそう。
所在検索サービスや情報解析サービスにおいて、一定の要件を満たしさえすれば、検索結果・解析結果を提供する際に、その結果だけでなく、著作物を「部分的に表示」（軽微利用）できる、
② 著作物を都度生成するケース。 (GPT-3のようなやつ)
自動生成された出力が、「偶然」既存の著作物に類似した場合に著作権侵害の問題が生じることになります。
AIが偶然に「穴子さん」を生み出した場合、サザエさんの著作権者に怒られるのか？（キャラクター生成ＡＩと著作権問題）という記事に詳説されているらしいが、端的に言えば、学習データに含まれていなければ偶然なのでOKだが、学習データにある場合は問題となる。
もっとも、元データがそのままモデル内に保持されているわけではなく、パラメータ化されている訳ですから、「偶然」といえば偶然のようにも思えます。この場合に依拠性が認められ、著作権侵害になるかについては様々な学説があり1、まだ結論が出ていません。
権利者が入力するのでもーまんたい
たとえば「ある文章を入力すると、その文章の『村上春樹度』を測定して点数を出力してくれる」サービスにおいて、ユーザーが自分が作成した文書を入力した場合
① 出力著作物が入力著作物由来である場合 翻訳や要約のようなケースで、これはOK
②出力著作物が入力著作物由来ではない場合 入力された文章と類似した誰かの文章を出力するケース。これは複製にあたるのでダメ。
この場合は、②と同様「出力対象となる著作物を事業者が予め蓄積し、入力に応じて出力している場合」に該当し、出力行為について著作権者の許諾がなければ著作権侵害になります。
これは入力している側の問題になるが、基本的には適法となる
サービス例
論文要約サービスにおいて、他人の論文を入力すると、AIモデルを用いて当該論文のポイントを抽出してくれるサービス（ただし元の論文を部分的にでも利用していたらNG）
著作権法上の利用行為としては「複製」行為をしていることになります。当該「複製」行為はユーザーが実施主体であり、したがってユーザーが個人である場合は、当該複製行為は私的利用目的の複製（30条1項）に該当し適法であると思われます。 ただ、このパターンの場合は出力が非著作物であるため、利用主体をいずれと考えたとしても著作物の非享受利用ということで30条の4第3号、同条柱書が適用され適法と考えられます（なお、47条の5と異なり30条の4については著作物の利用主体が限定されていません）。
ユーザーがネットに公開されている文章を無断でいれて、著作物を出力してしまうようなケース。 (一番シビア)
著作物が入力された著作物由来のものである場合は、入力側についてはユーザーが入力するのであれば基本的にはOKで、出力側についても基本的にOK。
入力側の論点① 誰が入力しているか。
ユーザーが入力しているのであればOKだが、事業者がやってる場合はアウト。
入力・処理・処理までの一連の過程が自動化されたクラウドサービスにおいて、ユーザー自身が著作物の入力行為を行っている場合は、当該著作物の複製主体は事業者ではなくユーザーと捉えることが合理的だと考えます4。この考えは、ユーザーは、クラウドサーバを用いて自ら複製をする一方で、事業者はそのための幇助行為をしているに過ぎないと整理するものです。
入力側の論点② 個人的に又は家庭内その他これに準ずる限られた範囲内」の要件を満たすか
クラウドサービスを利用しているからといってもこの要件は満たされると考えるのが普通
入力側の論点③ クラウドサーバが「公衆用設置自動複製機器（第３０条第１項第１号）」に該当しないか
この法律が制定された時にクラウドサーバーはなかったので、基本的に該当しない
出力側の論点 公衆送信にあたるか？
このケースではユーザーが入力しているのであれば、送信者は事業者ではなくユーザーとなり、適法とみなされる。
出力行為はユーザーが行っていることになり、公衆送信に該当せず著作権侵害は構成しないことになります。 なお、入力・出力共にユーザーが行為主体だという立場に立つと、入力された著作物の要約や翻訳という翻案行為をユーザー自身が行っていることになりますが、この点については著作権法47条の6第1項第1号、同30条1項により適法となります。
ただし、出力が入力著作物とは別の著作物由来のものであるならば、NGとなる。
この場合は、②と同様「出力対象となる著作物を事業者が予め蓄積し、入力に応じて出力している場合」に該当し、出力行為について著作権者の許諾がなければ著作権侵害になります。
入力をユーザーが行うという前提に立てば、事業者としては何をどう出力するかが問題になるようだ。
入力された著作物の要約や改変という範囲であればOKだが、別の著作物から持ってきたものを出力しようとするケースは問題となる。
GENZITSU
commented
2 years ago 近年提案されてきた様々なSOTAなモジュールのpytorch実装が一行ごとの説明とともにまとめられている。
数式がわからずとも実装であればわかる時があるので、そういった際に便利かも。
あと単純に勉強になる。
GENZITSU
commented
2 years ago Transformersがv4.8.0からflaxをサポートしたということで、colabのtpuでbertを学習させる方法が紹介されている。
以下のようにtrainとevalのフローの書き方に若干癖があるが、学習は3~4倍早くなる。
以下が学習速度の比較
ただし、どうも精度が少し悪いようで、TPUごとのバッチサイズが小さいことが原因と考察している。
(gradientの共有などがちゃんとできていない...?)
そろそろjaxの勉強しないとな。
GENZITSU
commented
2 years ago GENZITSU
commented
2 years ago GENZITSU
commented
2 years ago スマホのタップ音から何が入力されたかを分類することができるかを試した検証。
何も工夫せずにやると、あまり精度が出ないので、いくつか工夫を施した。
工夫①: 環境音のフィルタリング + タップ音の時間方向の伸長 精度がが52%→77%まで向上する
工夫②: タップ音のみを抽出する。
タップ音が一番大きな音になるという過程のスペクトログラムに前処理を加える。
抽出をおkを行わない場合と加えて、精度が+42%も上がる。
正味デバイス側のセキュリティ対応によっていかんとでもなりそうだが、取り組み自体は面白い。
[元記事]()
GENZITSU
commented
2 years ago ラベル間に順序があるような問題設定の際に、one-hot labelを分布に変換することで、順序を考慮した予測を可能にする手法を試してみた記事。
今回はone hotの値が中心となる正規分布に変換することで、実現。
distribution learningを用いることで、推定誤差が10%ほど向上していることがわかる。
(これ評価するデータがone hotなのかdistributionalなのかがきになる。)
訂正的に見ても、distributional learningによる学習は推定分布が滑らかになるのだそう。
one hot を雑に分布にするだけで順序を考慮した学習ができるのは面白い。
評価のところは評価ラベルが揃っていないと意味のある比較ではない気もするが、、。(真偽は不明)
GENZITSU
commented
2 years ago amazonの社員が送る商品のナレッジグラフをどのように構築し、実務に生かしていくかのチュートリアル。
メモ
GENZITSU
commented
2 years ago GENZITSU
commented
2 years ago iphoneでのカメラ撮影品質を向上させるために用いられているon deviceなpanoptic segmentationモデルの紹介。
DETRとHyperNetworksのあいの子のようなモデルHyperDETRというモデルを作成。
出力系列長が長くなるにつれてメモリ消費量やlatencyが上がるDETRと比べて高効率な推論が可能。
最終的なモデルは以下のように作成 特徴抽出器としてのMobileNetV3を400万枚1,500カテゴリの画像で学習
We used the large variant of the MobileNetV3 architecture, with a depth multiplier of 1.5, as the convolutional feature extractor. We pretrained this network on an internal dataset of ~4M images for a multilabel classification task, with roughly 1500 categorical labels.
目的タスクのsegementationをするのに、HyperDETRを加えて、5万枚、6カテゴリの画像で学習
Next, we removed the final fully-connected layer of the convolutional feature extractor and appended a standard Transformer encoder/decoder network for detection, and added a convolutional decoder for segmentation mask regression. Then, we trained it on another internal dataset of ~50k images that were annotated with extremely high-quality alpha-matte annotations of people, skin, hair, glasses, teeth, and sky.
学習の際のaugmentationは以下
we randomly resized, cropped, and resized again. Next, we randomly oriented, randomly rotated, and cropped the valid regions to simulate poorly-oriented captures. > Finally, we introduced color jitter by randomly varying brightness, contrast, saturation, and hue.
デバイスには量子化に加え、DTERの4/6のblockを削除した状態でデプロイしているのだそう。
どうもpruningはあまり意味がなかったらしい。
First, we applied 8-bit weight quantization to all the model parameters, which reduced the on-device network size from 84MB to ~21MB. We removed the last 4 layers of the 6-layer Transformer decoder module of our HyperDETR network, which resulted in ~4MB of additional savings, to reach a final size of 17MB.
iphoneのsmartHDR画像の裏側でsegmenation modelsが動いているのは意外だった。
GENZITSU
commented
2 years ago shopifyでMLをビジネスに活かすために用いられてる5段階フレーム枠の紹介
これを判断するには以下の2点を考慮する。
MLはプロダクトをより良くするものか？ 通常プロダクトの作成には多大な労力がかかる、特に初期の段階ではプロダクト自体が市場でもとめられているかや、データの獲得フローなどを整理するべきである。逆に、これらが整っているのであればMLは良い選択肢となる。
非ML手法の性能はどんなものか
ヒューリスティクな手法は実装も簡単で、問題への理解も深めることができ、意外と良いパフォーマンスを出す。
shopifyでは以下をお勧めしていた。
できるだけシンプルな手法から始めるべきで、シンプルなモデル、シンプルな特徴量、学習済み(既製品)のソリューションなどを使うことを検討するべき。
計測をするためには以下の点に気をつける。
平均的な性能は上がっているが、一部のグループでは性能が悪化していることがあったりする。
一つ一つは見覚えのある言説ではあるが、まとまっている文章は珍しい。
個人的には如何にに比較を楽にしていくが結構鍵だとは思っている。
GENZITSU
commented
2 years ago 時系列データをリカレンスプロットにより画像化しCNNで分類する手法の紹介。
リカレンスプロットはsklearnのpairwise distanceを派生させて以下のように作成することが可能。
リカレンスプロットによるCNN分類が良さげな理由。
CNNでは画像全体に共通のフィルタをかけてから学習します。そのため、画像（グラフ）の特定の一部のみに時系列の特徴が表れるスペクトルよりも、画像全体に時系列の特徴が表れるリカレンスプロットの方がCNNと相性が良い、ということだと思われます。
このリカレンスプロットは画像に応じて様々な形になりうる点で、時系列の特徴をよく表している可能性がある。
スマートフォンセンサーで計測した運動データの可視化が以下。 似ている運動形態は似たようなプロットになっていることがわかる。
これをCNNで分類することで、acc 95%程度のものができるようだ。
リカレンスプロットという手法は初めて知ったが、多変量時系列データも2次元に落とし込めるというのは嬉しい声質かもしれない。
今回は画像分類ということであったが、異常検知に使うことも可能なのだろうか？
その場合は異常の原因まではわからず、異常のあった時点しかわからないだろうが...
GENZITSU
commented
2 years ago yahoo! 新卒1年目が経験したiphone上で動作する音声認識モデルの開発記録。
音声認識ではCTC, RNN-T, Attention based Encoder-Decoderなどの系列があるが、今回は最も動作が軽く軽量なCTCベースのモデルから開発をスタートした。
採用したしたQuartsNetはNVIDIAが2020年公開したモデルで以下のようなCNNのみで構成されているのが特徴。
ここからの改良点が以下。
① ある時点の畳み込みをする際に、取り入れる未来情報を制限
左右非対称なパディングをすることで、取り込める未来情報に制約を加えた。これにある程度未来の発話まで取り込まずとも推論可能になりレイテンシーが下がる。
② 学習時のみTransformer Decoderを用いて学習。 これにより精度が23%向上するらしい。 マルチタスク学習的な効果があるのだろうか？ 手法としては斬新な気がする。
③ CNNのカーネルサイズとフィルタ数を減らす
学習データに短い発話しかなかったため、長い発話用のカーネルの重みが更新されないという問題があっった。
フィルター自体を工夫することで短い発話でも全重みを更新するようにした。
このように学習したモデルは、pytorch → torchscript → CoreMLでswiftに取り込むことができる。 TensorRTのように、一部対応していない操作などがあるが、以下のようなコードで変換できるとのこと。
# from https://techblog.yahoo.co.jp/entry/2021110130235935/
import torch
import coremltools as ct
# PyTorchのモデルを読み込む
model = pytorch_model_create()
# モデルへの入力の定義
inp = torch.rand(128, 128)
# TorchScriptの形式に変換する
traced_torch_model = torch.jit.trace(model, inp)
# Core MLへの変換
mlmodel = ct.convert(
traced_torch_model,
inputs=[ct.TensorType(name="x", shape=inp.shape)]
)
# model.mlmodelという名前で保存される
mlmodel.save("model.mlmodel")また、decodeはビームサーチではなくgreedy searchを使うことでさらにレイテンシーを下げる工夫をしている。
このような過程を経て、50MB, RTF 0.2以下となり軽量かつ高速なモデルの作成に成功したとのこと。
(精度自体はサーバーで推論するYJVOICEには叶わなかったらしい。)
エッジデバイス用のモデル開発ノウハウが知れる良記事。
GENZITSU
commented
2 years ago 医療系サービスでの検索性を向上するために、単語辞書に含まれる複合語の自動で分割する試みの紹介。
検索インデックスの作り方により、じんま疹というクエリではアレルギー性じんま疹を検索できないという問題がある。
Elasticsearchでkuromojiを利用してユーザー辞書としてComeJisyoを利用できますが、ComeJisyoをそのままの形で登録して使うと、その表現で必ずドキュメントが形態素解析されてしまいます。つまり「じんま疹」というクエリに対して、ComeJisyoに定義されている「アレルギー性じんま疹」を含むドキュメントがヒットしないという現象が発生します。
これの対処には、「アレルギー性じんま疹」をいくつかの単語に分割してindexを貼る必要があるのだが、無数にある医療単語に対して分割を手動で行うのは無理がある。
一方、粒度が細かい形態素解析で何でもかんでも分割して登録するといったアプローチを取ると、「受容 / 体」というワードが「体」という単語で反応してしまうなどの問題が生じる。
コロケーション抽出などに用いられる対数尤度比を用いたとのこと。
ある単語分割を与えたときの対数尤度比は以下のように書き下せる。
このスコアが高ければ高いほど、一緒に出現する可能性が高くなるということで、別々の単語にしないという方策が取れる。
記事には実装方法が書かれているが、ここでは省略。
単語辞書のみを用いた場合と、検索ログデータも含めた結果がある。 検索ログデータも含めたほうが結果は良さそうに見える。
ログデータ + 対数尤度比を用いてドメイン特化の単語分割が行えるのは面白い。 ドメイン別のOCRとかにも応用できるやもしれない。
GENZITSU
commented
2 years ago 米Meta（旧Facebook）は11月2日（現地時間）、Facebookで2010年から提供してきた顔認識機能をシャットダウンすると発表した。プライバシーを侵害する可能性があるメタバースへのシフトに際し、プライバシー保護に対するユーザーの信頼を高める狙いのようだ。
顔データを利用する本人認証など、顔認識技術の開発は続けるという。だが、「顔認識が役立つ可能性のある多くの事例は、この技術全体の使用に関する懸念の高まりと比較検討する必要がある」としている。
まじか
「警察によるAI使用禁止」を欧州議会が決議、顔認証技術や行動監視が対象
コメント
欧州では公的な目的で顔認識技術を使用することが禁止されている動きがあることを知らなかった。
出典
元記事
英語記事