音声データを“意味理解”で扱いたかった話〜SBERT + LightGBMでうまくいかなかった理由〜

音声データって、かなり可能性があると思っています。

テキストよりも情報量が多くて、非構造化データの塊。
ちゃんと扱えれば、かなり価値のあるメタデータが取れるはず。

そう思って、まずはシンプルに
「音声 → テキスト → メタデータ生成」という流れを作ってみました。

やりたかったこと

やりたかったのは、音声の文字起こしからメタデータを生成することです。

入力は音声の文字起こしテキスト。
そこから、文章単位でカテゴリ（メタデータ）を付与する。

イメージとしてはこんな感じです。

入力：ユーザーの発話（文字起こし）
出力：その発話に対するカテゴリ（メタデータ）

音声データは“宝庫”だと思っているので、まずはここを開拓したいと思いました。

なぜSBERTを使ったのか

今回は、テキストをそのまま扱うのではなく、Embeddingに変換してから分類する構成にしました。

理由はシンプルで、

単語単位ではなく、文章全体の意味を扱いたかった
ある程度の精度が出ることが分かっている
Embeddingの次元数も大きすぎず扱いやすい

TF-IDFのような手法も考えましたが、
どうしても単語ベースになってしまうので、今回は見送りました。

Sentence-BERTを使えば、
「文章そのものに意味的な特徴を持たせられる」と期待しました。

なぜLightGBMと組み合わせたのか

モデル構成としては、

SBERTでEmbeddingを生成
LightGBMで分類

という形にしました。

いきなりBERTをfine-tuningすることも考えましたが、

モデルのパラメータが変わることで挙動が安定しなそう
学習コストが高い
運用時の再学習も重くなる

といった理由から、まずはシンプルな構成を選びました。

LightGBMを選んだのは、単純に分類モデルとして優秀だからです。
実務でもよく使われるので、まずはここから、という判断でした。

実際にやってみた結果

結論から言うと、精度はあまり出ませんでした。

理由はいくつかあります。

入力データのノイズが多い
分類カテゴリを作りすぎた

特に問題だったのは、入力データです。

今回使ったのは、音声の文字起こしテキストでした。
つまり、もともとノイズを含んでいるデータです。

一番の誤算だったこと

一番「思っていたのと違った」と感じたのは、

**「Embeddingが綺麗でも、入力データの質には勝てない」**ということでした。

SBERTで意味的に整理されたベクトルを作れても、
その元になるテキスト自体がノイジーだと、分類は普通に崩れます。

さらに、LightGBMはそのノイズの影響をそのまま受けます。

結果として、

なんとなくそれっぽい特徴は取れている
でも分類は安定しない

という状態になりました。

次にやるなら

もし次にやるなら、まずはここを見直します。

カテゴリ数を減らす
データの前処理をちゃんとやる
音声→テキストの段階でのノイズ対策

もしくは、最初からfine-tuning前提で設計するのもありかもしれません。

まとめ

音声データはやっぱり面白いです。

ただ、扱うのは思っていたよりもずっと難しい。

「良いモデルを使えば解決する」というよりは、
「データと設計の問題をどう扱うか」が本質だと感じました。

もう少しちゃんと向き合ってみたい領域です。