文字起こしの楽園を探して
547 Views
March 22, 25
スライド概要
ひまプロLT
https://teamhimapro.connpass.com/event/338895/
新技術に興味津々なエンジニア
関連スライド
Meta XR SDK(V66-74)でQuestアプリを開発
あうぜん
1M
各ページのテキスト
文字起こしの楽園を探して
自己紹介 小林将太(@yabakobayashi) ■ ■ ■ システム全般開発(インフラ、Webアプリ) オンプレとクラウドをいったりきたり PHPとGoをいったりきたり ○ PHPからGoへのマイグレーション 2
〜レッド・グリーン・ファクタリングのループを回しましょうってよく言われますが、これ 何かというとノリさんが以前のエピソードで お話しした通り、こうなるといいなみたい なテストケースを〜 #325 📩テストについてのリアルな悩みに回答！！スモールテストって知ってる？ 3
〜今ちょうど考えているところでま答えはないんですけど。で、そのうちの一つなん で。選択肢としては、ノリさんが以前言ってたリファクタリング してみるっていうところ がやっぱり効いてくるのかなとは思うんです。 #297 勉強している人も教えている人も知りたい「わかる」技術 4
文字で検索してラジオの内容を振り返りたい 5
文字起こしの選定基準 ● ● ● ● それなりに精度がある コストは安め APIがある 並列で出来るといい
初期構成 ● ● 音声ファイルをpythonで短く加工 ○ pydubを使用 OpenAPIに10分&24MB以内でリクエスト ○ 返却された値を後で結合
一々、分割して保存してOpenAPIに投げてる
やってみた感想 ● ● 文字起こし精度が割と高い ただし1リクエスト10分&24MBだけの制限があるので無駄がすごい OpenAPIのWhisperはユースケースとしてリアルタイム翻訳をターゲットにして るっぽい
phase2 ● OSS版whisperを使用 ○ GPU次第で精度も自由 ○ OpenAPI時にあった制限もなし
やってみた感想 ● ● ● 文字起こし精度がかなり高い OpenAPIへの料金や制限が発生しない ただしインスタンスに求めるスペックが高い ○ ○ ffmpegのインストール GPU コストを気にしないなら、これが一番早くて高精度だと思います
これって誰が言ったかも分かるかも 12
話者分割 13
Whisperでは話者分割はできない ● ● ● やるにはpyannoteなどのモデルが必要 さらにGPUも必要 労力を費やして出力されたものが大したことないものだと割とショック
AWS Transcribe ● ● ● ● 文字起こしのマネージドサービス 従量課金(無料枠あり) 話者分離可能 並列実行可能 15
Transcribeジョブの構成 ● ● S3をインプットとして文字起こし 出力はjson形式でS3に保存される
こんな感じで出力される ● ● transcriptが文字起こし全文 itemsの中が話者分割。。。だが
分割されすぎ！！！
内容確認 ● 中身を見る感じspeaker_labelで誰が 言ったかを単語レベルで判別してるっぽ い ○ ● 最初の番組紹介は 97%の確率でかいちさんな のでspk_0はかいちさんだと思われる なのでラベルレベルでくっつければ会話 になっているかな？
ラベル変わったら、切り替えるなど地味に面倒な処理
ちゃんと話者分割されて る！
やってみた感想 ● 文字起こし精度はまぁまぁ ○ ● 文字起こし速度はWhisperより早い ○ ● 日本語対応は 2019年からだけど当時から精度は上がっているのか？ まぁ使っているモデルにもよるでしょうけども 並列で実行できるのはかなりよい
おまけ Nottaでもやってみた
まとめ ● 精度 速度 コスト 話者分割 OpenAPI Whisper 高 中 中 不可能 OSS Whisper 最高 中〜高速 高 不可能 AWS Transcribe 中 高速 中 可能 Transcribeが自分の要件に合っていた ○ ● 他はインスタンスが必要なのが結構コスト的に精神負荷が高い ラジオレベルであれば精度はそれほど必要でない
皆さんもよいPodcastライフを 25
ご清聴ありがとうございました 26