まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:watson

IBM Cloud から提供されている AI サービス IBM Watson の中で「音声→テキスト変換」を行う Speech to Text APIにおいて、2022/05/05 時点ではまだベータ版機能として提供されている "Speaker Labels" 機能を使ってみました。その様子をサンプルソースコードと併せて紹介します。

なお以下で紹介している様子および内容は 2022/05/05 時点のベータ版のものです。今後 API の実行方法や出力フォーマット、価格、提供しているソースコード等も含めて変更になる可能性もあることをご了承ください。


【Speech to Text サービスにおける Speaker Labels 機能とは】
一般的な Speech to Text サービスから提供されている機能の多くは「一人が話している前提」がありました。要は一人の人が話しているという前提で、その音声データをテキスト化する、というものでした。

IBM Watson Speech to Text サービスにおける Speaker Labels 機能はこの点を改良して、「複数人が話している可能性を考慮」した上で音声データをテキスト化するものです。なお、この機能は 2022/05/05 時点においてはベータ版として提供されており、英語に加えてスペイン語、ドイツ語、チェコ語、韓国語、そして日本語に対応しています。詳しくはこちらを参照ください:
https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-speaker-labels


【サンプルとその使い方を紹介】
この Speaker Labels 機能を使った Node.js のサンプルアプリケーションを作って公開してみました。興味のある方はこちらから git clone するかダウンロードして使ってください:
https://github.com/dotnsf/s2t_betas


ソースコードを展開後の、アプリケーションの使い方を紹介します。まずアプリケーションを動かすためには Node.js v14 以上及び npm が必要なので、未導入の場合は自分のシステムにあったモジュールをインストールしておいてください:
https://nodejs.org/

また IBM Watson の Speech to Text サービスインスタンスの API Key およびサービス URL も必要です。無料のライトプラン※でも構わないので IBM Cloud 内に作成し、接続情報から API Key およびサービス URL (apikey の値と url の値)を取得しておいてください(すぐ後で使います):
2022050601

※無料のライトプランの場合、変換できるのは1か月間で 500 分ぶんのデータまで、という制約があります。


また実際に Speech to Text で変換する音声データファイルが必要です。特に今回は Speaker Labels 機能を使うため、二人以上で会話している際の音声データが必要です。自分で録音したものを使っても構いませんし、どこかでサンプルデータをダウンロードして用意していただいても構いません。以下の例では、こちらから提供されている日本語会話サンプルデータを使わせていただきました:
https://www.3anet.co.jp/np/resrcs/333020/

上述のページから提供されているサンプルデータをダウンロードし、使えそうな mp3 ファイルをソースコードの public/ フォルダ内にコピーしておいてください。とりあえず 007.mp3 というサンプルはいい感じに2名の男女が会話している様子のデータになっているので、以下はこのファイルをソースコード内の public/ フォルダにコピーできているものとして説明を進めることにします:
2022050602


会話の音声サンプルデータが public/ フォルダ以下に用意できたらアプリケーションを起動するための準備を(1回だけ)行います。まずソースコードフォルダ直下にある settings.js ファイルをテキストエディタで開き、取得した Speech to Text サービスの API Key とサービス URL をそれぞれ exports.s2t_apikey と exports.s2t_url の値として入力した上で保存します:
2022050603


そして依存ライブラリをインストールします。ソースコードフォルダ直下において、以下のコマンドを実行します:
$ npm install

これで起動の準備が整いました。最後にアプリケーションを起動します:
$ node app

成功すると 8080 番ポートでアプリケーションが起動します。実際に利用するにはウェブブラウザで http://localhost:8080/ にアクセスします。すると以下のような画面になります:
2022050601


左上にはソースコードの public/ フォルダにコピーした音声会話データのファイル名が一覧で表示されています。ここから 007.mp3 というファイルを選択してください(これが比較的わかりやすくていい感じの結果でした)。そして POST ボタンをクリックして Speech to Text を実行します:
2022050602


実行と同時に指定した音声ファイルの再生も開始します(つまり音が出ます)。並行して音声の解析が非同期に行われ、解析結果が少しずつ表示されていく様子を確認できます(ここまではベータ版の機能を使っていません):
2022050603


あるタイミングから確定した文節のテキスト内容が複数の色に分類されて表示されます。この色の分類が話している人の分類でもあります(下の結果では茶色の文字との文字になっているので、二人で会話している様子だと判断されていることになります):
2022050604


007.mp3 を最後まで解析し終えると以下のようになりました。(識別精度はともかく(苦笑))2つの文節の中で2人の人が会話している様子だった、と識別された様子がわかります:
2022050605


【サンプルソースコード内を紹介】
最後にこのアプリケーションのサンプルソースコードの内容を紹介しながら、どのように API を実行して、どのような結果を取得しているのか、という内容を紹介します。先に言っておくと、この Speaker Labels 機能を使う上で API の実行方法自体は(オプションを ON にする以外は)以前と全く同じです。実行結果に新しい情報が含まれるようになるので、その部分の対応が必要になります。 また該当部分はすべて app.js ファイル内にあるので、このファイルの内容と合わせて紹介します。

まず 27 行目で定義しているオブジェクトが Speech to Text 実行時のパラメータに相当するものです。この中で日本語変換モデル等を指定していますが、32 行目の speakerLabels: true によって、ベータ版機能である speakerLabels を有効に設定しています:
27: var s2t_params = {
28:   objectMode: true,
29:   contentType: 'audio/mp3',
30:   model: settings.s2t_model,
31:   smartFormatting: true,
32:   speakerLabels: true,
33:   inactivityTimeout: -1,
34:   interimResults: true,
35:   timestamps: true,
36:   maxAlternatives: 3
37: };

実際の音声→テキスト変換は 88 行目の processAudioFile() 関数で行っています。特にこの例では音声データファイルを一括変換する方法ではなく、WebSocket を使った非同期変換(少しずつ変換結果を受け取る方法)である recognizeUsingWebSocket() (90 行目)を使っています。そして SpeakerLabels を有効にしている場合、この実行結果(92行目)は2通り想定する必要があります。1つは「音声→テキスト変換結果」、もう1つは「どの部分を誰が話していたか、の判定結果」です(一括の同期変換を使った場合はこれらをまとめて取得できますが、今回は非同期変換を使っているためこれらの結果がバラバラに返ってくる可能性を考慮する必要があります):
90: var s2t_stream = my_s2t.s2t.recognizeUsingWebSocket( s2t_params );
91: fs.createReadStream( filepath ).pipe( s2t_stream );
92: s2t_stream.on( 'data', function( evt ){
        :



まず「音声→テキスト変換結果」が返ってきた場合です。この場合、92 行目の evt オブジェクト(=テキスト変換結果)は以下のような形で返されます:
        {
          result_index: 0,
          results: [
            { 
              final: true,
              alternatives: [
                {  //. 候補1
                  transcript: "音声メッセージが既存のウェブサイトを超えたコミュニケーションを実現",
                  confidence: 0.95,
                  timestamps: [
                    [ "音声", 0.36, 0.84 ],
                    [ "メッセージ", 0.84, 1.35 ],
                    [ "が", 1.35, 1.59 ],
                       :
                    [ "実現", 4.13, 4.7 ]
                  ]
                },
                {  //. 候補2
                  :
                }
              ]
            }
          ]
        }

まず変換結果をある程度の区切りでひとまとめにしています(ある程度の空白期間が生じるまでを1つの節とみなしています)。その区切りの番号が result_index 値です(上の例では 0 になっています)。そしてテキスト変換した結果が results 内に配列形式で格納されています。各配列要素の中に final というキーがあり、これが true の場合は節として変換結果が確定したことを意味します(false の場合は節が確定する前の、変換途中での結果が返されていることを意味します)。そして altervatives 内にその変換結果が可能性の高い順にやはり配列で格納されています。特にこの部分に注目してください:
                {  //. 候補1
                  transcript: "音声メッセージが既存のウェブサイトを超えたコミュニケーションを実現",
                  confidence: 0.95,
                  timestamps: [
                    [ "音声", 0.36, 0.84 ],
                    [ "メッセージ", 0.84, 1.35 ],
                    [ "が", 1.35, 1.59 ],
                       :
                    [ "実現", 4.13, 4.7 ]
                  ]
                },

文章としては「音声メッセージが既存のウェブサイトを超えたコミュニケーションを実現」というテキストに変換されていることに加え、その自信度が 0.95 であること、そして各単語が現れる音声開始からの通算秒数が timestamps という配列変数内に格納されています。この例だと音声スタートから 0.36 秒後から 0.84 秒後までの間に「音声」と話されていて、次に 0.84 秒後から 1.35 秒後までの間に「メッセージ」と話されていて、・・・といったように変換結果が分類されています(ここ、後で使います)。

次に変換結果として返される可能性のもう1つ、「誰がどの部分を話しているか」の結果が返される場合、evt 変数の内容は以下のようになります:
        {
          speaker_labels: [
            { 
              from: 0.36,
              to: 0.84,
              speaker: 0,
              confidence 0.67,
              final: false
            },
            {
              from: 0.84,
              to: 1.35,
              speaker: 0,
              confidence: 0.67,
              final: false
            },
              :
            {
              from: 4.13,
              to: 4.7,
              speaker: 1,
              confidence: 0.67,
              final: false
            }
          ]
        }

speaker_labels というキーが含まれている場合はこちらのケースと判断できます。そしてその中身は上の例であれば以下のような意味です:

・0.36 - 0.84 秒の間は 0 番目の人(自信度 0.67)
・0.84 - 1.35 秒の間は 0 番目の人(自信度 0.67) (この2つは同じ人)
   :
・4.13 - 4.7 秒の間は 1 番目の人(自信度 0.67)  (上とは別の人)

先程のテキスト変換結果の timestamps 値と合わせて、どの(何秒時点の)テキスト部分を何番目の人が話しているか、がわかるように speaker というラベルが付けられています。後はこれらをうまく組み合わせて、例えばテキストの色を分けて表示するようにしたものが提供しているサンプルアプリケーションです:
2022050600


なお、現時点での仕様としては以下のような制約があるようです:
・「2名で」話している前提で判断するよう最適化されている(実際には3名以上と判断される場合もあるが、あくまで2名の会話であることを想定した上で最適化されてラベルが付けられる)。
・speaker_labels の結果にも最終結果であることを示す final キーは存在しているが、final = true とならずに終わるケースが多い(なので、現状ここは無視してもよさそう)。


この辺りはあくまでベータ版での仕様なので、精度含めて今後の変更の可能性もあると思っています。ただ少なくともベータ版の現時点ではこの speaker_labels は無料で(無料のライトプランでも)使える機能のようで、今のうちから色々試してみたいと思いました。複数人の会話音声データから複数人の会話テキストを取り出せるようになると会議の議事録とかにも使えそうで、使い道の幅が大きく広がると期待しています。


IBM Watson から提供されている AI 系 API の中で、自然言語テキストを分類する機能を持った NLC(Natural Language Classifier) の提供が終了することがアナウンスされました。2021年9月9日までは新規インスタンスの作成が可能ですが、それ以降の新規作成はできません。また既存インスタンスは2022年8月8日まで利用できますが、それまでに移行先を決め、その移行作業を済ませておく必要があります:
https://cloud.ibm.com/docs/natural-language-classifier?topic=natural-language-classifier-migrating


NLC は個人的にも IBM Watson を使い始めるきっかけになった API で、思い入れの深いサービスだったりします。NLC を使って作った多くのデモアプリは WordCamp Tokyo や特定のお客様向けに作ったものを含めて多くの場で紹介させていただきました。感慨深いものがあります。


上記アナウンス内で、公式な移行先として同じ IBM Watson の NLU(Natural Language Understandings) が紹介されています。が、具体的な移行手順や方法に関する情報が少ないこともあり、実際に自分が NLC API を使って開発したアプリケーションをどのように NLU に移行すればよいかがわかりにくいように感じました。 自分自身の場合は普段 Node.js を使ってアプリケーションを開発しているのですが、Node.js の場合は具体的にどのようにすれば NLC から NLU へ移行できるか? という調査をしてみました。実際に Node.js でプログラムを書き、具体的にはまず NLC API を使って、
 ・認証
 ・日本語データ学習
 ・学習状況確認
 ・問い合わせ(分類)
 ・学習の削除
といった5種類のオペレーションを行えるようなアプリケーションを作りました。 そしてそのアプリケーションを NLC から NLU へ実際に移植する、といった作業を行ってみました。結論として上記5種類のオペレーションは NLU でも NLC 同様に行うことができました。ただ API には互換性はなく、ソースコードレベルではそれなりに変更が必要になるため、どの程度の変更が必要になるのか、という調査の意味も含めて作業した様子を以下に紹介します。

なお、NLC は IBM Cloud の(無料版の)ライトアカウント向けには提供されていない API である点に注意してください。ライトアカウントの状態で NLC の新規インスタンスを作成することは(9月9日以前であっても)できません。ベーシック以上の(有償の)アカウントであれば無料枠含めて提供されている API です。 一方の NLU はライトアカウントでも利用することが可能ですが、ライトアカウントの場合はライトプラン(無料)の NLU を1インスタンスのみ作成でき、1インスタンスにつき1モデルだけ学習で作成できます(要は複数の学習モデルを作成するにはベーシック以上のアカウントで、有料プランを選択する必要があります)。
2021082200



【サンプルコードのダウンロード】
以下で紹介する一連の手順を行うための Node.js 用サンプルコードを作って公開しました:
https://github.com/dotnsf/nlc2nlu

git clone するかコードをダウンロード&展開してください。以下の3つのフォルダが含まれています:
|- csvtool
|- nlc
|- nlu

csvtool は実際に NLC や NLU で使うサンプルの学習データを作成するツールです。NLC や NLU を既に使っていて、どのような学習データを用意すればよいかわかっている場合は、ご自身で学習データ(CSV ファイル)を用意いただいてもかまいませんが、そうでない人向けに Yahoo! ニュースの RSS(https://news.yahoo.co.jp/rss) を使って、その場で学習データを作成できるようにしたものです。

nlc と nlu は名前の通りで、学習データを学習させて、学習状況を確認しながら学習が完了したら、実際に適当な日本語テキストを送信して、学習データに基づくテキスト分類を実施します。また実施後に学習データを削除する、といった操作も可能です。これらの内容を NLC および NLU それぞれで行えるようにしたツールが含まれています。

ではそれぞれのフォルダの使い方を説明します。


【csvtool : 学習データの用意】
csvtool/csvgenerator.jsYahoo! ニュース RSS から学習データとしての CSV ファイルを作成します。NLC / NLU とも学習データは以下のフォーマットの CSV ファイルを用意します※:
テキスト,このテキストが属するカテゴリー
テキスト,このテキストが属するカテゴリー
テキスト,このテキストが属するカテゴリー
  :

※ NLU は JSON フォーマットでも学習データを準備して読み込むことが可能ですが、NLC からの移植を考えると NLC と同じ条件で学習データを用意するべきと考え、同じ CSV ファイルを学習データとして使うことにします。

このような(NLC 向けの)学習データを既にお持ちであればそれを使って後述の作業を続けていただいてもかまいませんが、多くの人はそのような学習データを持っていないと思うので、新たに用意することにします。その場合は csvtool/csvgenerator.js を使います。

実行方法は単純で、csvtool フォルダに移動し、まず普通に $ npm install を実行して依存ライブラリを導入します:
$ cd csvtool

$ npm install

その後、node コマンドでこのファイルを実行します。実行コマンドの最後に出力先 CSV ファイル名を指定します(以下の例だと同一フォルダ内の csvfile.csv):
$ node csvgenerator csvfile.csv

実行したタイミングで Yahoo! ニュースの RSS を参照して、その時点のニュースを取得して CSV ファイルに書き出します。なお、このツールでは「経済」、「IT」、「エンタメ」、「科学」、「スポーツ」の5つのカテゴリーのニュースを収集します。 ツールの実行が完了すると、指定した CSV ファイルが以下のような内容で生成されます:
RSS から取り出したニュース内容,このニュースのカテゴリー
RSS から取り出したニュース内容,このニュースのカテゴリー
RSS から取り出したニュース内容,このニュースのカテゴリー
   :

ここまでできれば学習データの準備は完了です。ではこのデータを NLC と NLU それぞれで学習させて問い合わせる、という作業をこれ以降で行っていきましょう。


【nlc : NLC で操作】
まずは NLC API を使って開発したアプリでこのデータを学習させ、NLC API を使って問い合わせを行ってみましょう。先ほどダウンロードしたソースコードの nlc フォルダ内にある nlc/nlc.js ファイルを使って操作します(このコードの内容については後述します)。まずは csvgenerator.js の時と同様に  $ npm install を実行して依存ライブラリを導入します:
$ cd nlc

$ npm install

その後、node コマンドでこのファイルを実行します。この nlc.js はコマンドラインアプリケーションで、その実行時パラメータによって「データ学習」、「学習状況確認」、「問い合わせ(分類)」、「学習データ削除」の4つを行うことができます:
$ node nlc create [csvfilename]  ・・・データ学習

$ node nlc status  ・・・学習状況確認

$ node nlc classify [日本語テキスト] [classifier_id]  ・・・問い合わせ(分類)

$ node nlc delete [classifier_id]  ・・・学習データ削除

では実際に nlc ツールを使いながら操作を確認してみましょう。まずは IBM Cloud にウェブブラウザでログインして、NLC インスタンスを作成し、「サービス資格情報」(を必要であれば作成して)の内容を確認します:
2021082201


この中に apikey 属性値と url 属性値が含まれているので、それらの値を nlc/settings.js ファイル内の exports.nlc_apiKey 値および exports.nlc_url 値にそれぞれコピーして保存します:
exports.nlc_apiKey = 'サービス資格情報内の apikey 属性値';
exports.nlc_url = 'サービス資格情報内の url 属性値';
exports.nlc_name = 'nlc2nlu';
exports.nlc_language = 'ja';

これで実行前の準備は完了しました。早速「データ学習」を実行してみます。「データ学習」は(前述の作業で用意した)学習データ CSV ファイルを指定して、$ node nlc create [csvfilename] を実行します。先ほどの手順で ../csvtool/csvfile.csv というファイルが作られている場合は以下のように指定して実行します:
$ node nlc create ../csvtool/csvfile.csv

これで指定した CSV ファイルを元にする学習が開始されます。この学習が完了すると問い合わせ(分類)ができるようになりますが、完了しているかどうかを確認するには以下のコマンドを実行します:
$ node nlc status

実行結果は以下のような JSON が表示されますが、この中の status 欄が "available" となっていれば学習は完了しています(データ量にもよりますが、自分が試した時はこうなるまでおよそ 10 分程度かかりました)。同時に表示されている classifier_id の値はこの後で使うので合わせてメモしておきましょう:
{
  "status": 200,
  "statusText": "OK",
  "headers": {
    "content-type": "application/json",
    "x-xss-protection": "1",
    "content-security-policy": "default-src 'none'",
    "x-content-type-options": "nosniff",
    "cache-control": "no-cache, no-store",
    "pragma": "no-cache",
    "expires": "0",
    "content-length": "428",
    "strict-transport-security": "max-age=31536000; includeSubDomains;",
    "x-dp-watson-tran-id": "e6168d25-5640-4790-a1f1-02ff089dd869",
    "x-request-id": "e6168d25-5640-4790-a1f1-02ff089dd869",
    "x-global-transaction-id": "e6168d25-5640-4790-a1f1-02ff089dd869",
    "server": "watson-gateway",
    "x-edgeconnect-midmile-rtt": "7",
    "x-edgeconnect-origin-mex-latency": "22",
    "date": "Tue, 24 Aug 2021 05:48:32 GMT",
    "connection": "close"
  },
  "result": {
    "classifier_id": "e87efex297-nlc-650",
    "name": "nlc2nlu",
    "language": "ja",
    "created": "2021-08-24T05:45:20.090Z",
    "url": "https://api.jp-tok.natural-language-classifier.watson.cloud.ibm.com/instances/f738a110-248b-419c-b771-8e6cbd45ee93/v1/classifiers/e87efex297-nlc-650",
    "status_description": "The classifier instance is now available and is ready to take classifier requests.",
    "status": "Available"
  }
}


学習が完了したら改めて日本語テキストを指定して、その内容がどのカテゴリーに属しているのかを分類してみましょう。日本語テキストと上述で確認した classifier_id 値を指定して、以下のようなコマンドを実行します:
$ node nlc classify [日本語テキスト] [classifier_id]

すると以下のような結果が表示されます。指定した日本語テキスト(「パッキャオがんばれ」)を学習データに含まれていたカテゴリー(今回作ったものだと「経済」、「IT」、「エンタメ」、「科学」、「スポーツ」)のどれに相当するものかを識別して、その可能性の高い順に結果を返しています。この例では「スポーツ」の可能性が 50% 強である、と判断されているようです:
$ node nlc classify パッキャオがんばれ e87efex297-nlc-650
{ "status": 200, "statusText": "OK", "headers": { "content-type": "application/json", "x-xss-protection": "1", "content-security-policy": "default-src 'none'", "x-content-type-options": "nosniff", "cache-control": "no-cache, no-store", "pragma": "no-cache", "expires": "0", "content-length": "679", "strict-transport-security": "max-age=31536000; includeSubDomains;", "x-dp-watson-tran-id": "102350df-e1d0-4568-ae10-6e72ba1b44b0", "x-request-id": "102350df-e1d0-4568-ae10-6e72ba1b44b0", "x-global-transaction-id": "102350df-e1d0-4568-ae10-6e72ba1b44b0", "server": "watson-gateway", "x-edgeconnect-midmile-rtt": "7", "x-edgeconnect-origin-mex-latency": "43", "date": "Tue, 24 Aug 2021 05:51:22 GMT", "connection": "close" }, "result": { "classifier_id": "e87efex297-nlc-650", "url": "https://api.jp-tok.natural-language-classifier.watson.cloud.ibm.com/instances/f738a110-248b-419c-b771-8e6cbd45ee93/v1/classifiers/e87efex297-nlc-650", "text": "パッキャオがんばれ", "top_class": "スポーツ", "classes": [ { "class_name": "スポーツ", "confidence": 0.5022989563107099 }, { "class_name": "エンタメ", "confidence": 0.20692538301831817 }, { "class_name": "経済", "confidence": 0.1200947580342344 }, { "class_name": "科学", "confidence": 0.11456564859743573 }, { "class_name": "IT", "confidence": 0.05611525403930185 } ] } }


作成した学習データを IBM Watson NLC から削除するには以下のコマンドを実行します:
$ node nlc delete [classifier_id]

ここまでのオペレーションで「データ学習」、「学習状況確認」、「問い合わせ(分類)」、「学習データ削除」の4つを NLC API を使って実現し、そのアプリケーションを実行する方法を紹介しました。


【nlu : NLU で操作】
では改めてこの nlc アプリケーションを NLU API で作り直し、同じ4つのオペレーションができることを確認してみます。先ほどダウンロードしたソースコードの nlu フォルダ内にある nlu/nlu.js ファイルを使って操作します(このコードの内容については後述します)。まずは csvgenerator.js の時と同様に  $ npm install を実行して依存ライブラリを導入します:
$ cd nlc

$ npm install

その後、node コマンドでこのファイルを実行します。この nlu.js もコマンドラインアプリケーションで、その実行時パラメータによって「データ学習」、「学習状況確認」、「問い合わせ(分類)」、「学習データ削除」の4つを行うことができます:
$ node nlu create [csvfilename]  ・・・データ学習

$ node nlu status  ・・・学習状況確認

$ node nlu analyze [日本語テキスト] [model_id]  ・・・問い合わせ(分類)

$ node nlu delete [model_id]  ・・・学習データ削除

※前述の NLC では問い合わせ時に "classify(分類)" という命令を指定していましたが、NLU では同じ作業を "analyze(解析)" と表現しているようです。またパラメータとして指定する ID も NLC では "classifier_id(分類ID)" だったのですが、NLU では "model_id(モデルID)" という表現になっていました。

では実際に nlu ツールを使いながら操作を確認してみましょう。まずは IBM Cloud にウェブブラウザでログインして、NLU インスタンスを作成し、「サービス資格情報」(を必要であれば作成して)の内容を確認します:
2021082401


この中に apikey 属性値と url 属性値が含まれているので、それらの値を nlu/settings.js ファイル内の exports.nlc_apiKey 値および exports.nlc_url 値にそれぞれコピーして保存します:
exports.nlu_apiKey = 'サービス資格情報内の apikey 属性値';
exports.nlu_url = 'サービス資格情報内の url 属性値';
exports.nlu_name = 'nlc2nlu';
exports.nlu_language = 'ja';

これで実行前の準備は完了しました。早速「データ学習」を実行してみます。「データ学習」は(前述の作業で用意した)学習データ CSV ファイルを指定して、$ node nlu create [csvfilename] を実行します。先ほどの手順で ../csvtool/csvfile.csv というファイルが作られている場合は以下のように指定して実行します:
$ node nlu create ../csvtool/csvfile.csv

これで指定した CSV ファイルを元にする学習が開始されます。この学習が完了すると問い合わせ(分類)ができるようになりますが、完了しているかどうかを確認するには以下のコマンドを実行します:
$ node nlu status

実行結果は以下のような JSON が表示されますが、この中の status 欄が "available" となっていれば学習は完了しています。同時に表示されている model_id の値はこの後で使うので合わせてメモしておきましょう。この辺りまでは前述の NLC の時とほぼ同様ですね:
{
  "status": 200,
  "statusText": "OK",
  "headers": {
    "x-powered-by": "Express",
    "content-type": "application/json; charset=utf-8",
    "content-length": "401",
    "etag": "W/\"191-CBnewThU0u/CjNzD01hil1wp9qo\"",
    "strict-transport-security": "max-age=31536000; includeSubDomains;",
    "x-dp-watson-tran-id": "15b238e1-d074-438d-8de5-44fcdfc163de",
    "x-request-id": "15b238e1-d074-438d-8de5-44fcdfc163de",
    "x-global-transaction-id": "15b238e1-d074-438d-8de5-44fcdfc163de",
    "server": "watson-gateway",
    "x-edgeconnect-midmile-rtt": "7",
    "x-edgeconnect-origin-mex-latency": "228",
    "date": "Tue, 24 Aug 2021 05:54:08 GMT",
    "connection": "close"
  },
  "result": {
    "models": [
      {
        "name": "nlc2nlu",
        "user_metadata": null,
        "language": "ja",
        "description": null,
        "model_version": "1.0.0",
        "version": "1.0.0",
        "workspace_id": null,
        "version_description": null,
        "status": "available",
        "notices": [],
        "model_id": "619ad785-0b0c-4981-8217-bd51064896a3",
        "features": [
          "classifications"
        ],
        "created": "2021-08-24T05:43:32Z",
        "last_trained": "2021-08-24T05:43:32Z",
        "last_deployed": "2021-08-24T05:50:10Z"
      }
    ]
  }
}

学習が完了したら改めて日本語テキストを指定して、その内容がどのカテゴリーに属しているのかを分類してみましょう。NLC では "classify" と指定していた部分は NLU では "analyze" となる点に注意してください。日本語テキストと上述で確認した model_id 値を指定して、以下のようなコマンドを実行します:
$ node nlu analyze [日本語テキスト] [model_id]

すると以下のような結果が表示されます。指定した日本語テキストを学習データに含まれていたカテゴリー(今回作ったものだと「経済」、「IT」、「エンタメ」、「科学」、「スポーツ」)のどれに相当するものかを識別して、その可能性の高い順に結果を返しています。同じ学習データで同じ問い合わせをして、こちらでも「スポーツ」の可能性が高いと判定されていますが、その確率や2位以下の結果には違いがあることがわかります:
$ node nlu analyze パッキャオがんばれ 619ad785-0b0c-4981-8217-bd51064896a3

{
  "status": 200,
  "statusText": "OK",
  "headers": {
    "server": "watson-gateway",
    "content-length": "499",
    "content-type": "application/json; charset=utf-8",
    "cache-control": "no-cache, no-store",
    "x-dp-watson-tran-id": "93978bcf-c49e-41e9-ad00-7f0000a34e15, 93978bcf-c49e-41e9-ad00-7f0000a34e15",
    "content-security-policy": "default-src 'none'",
    "pragma": "no-cache",
    "x-content-type-options": "nosniff",
    "x-frame-options": "DENY",
    "x-xss-protection": "1; mode=block",
    "strict-transport-security": "max-age=31536000; includeSubDomains;",
    "x-request-id": "93978bcf-c49e-41e9-ad00-7f0000a34e15",
    "x-global-transaction-id": "93978bcf-c49e-41e9-ad00-7f0000a34e15",
    "x-edgeconnect-midmile-rtt": "10",
    "x-edgeconnect-origin-mex-latency": "354",
    "date": "Tue, 24 Aug 2021 05:56:16 GMT",
    "connection": "close"
  },
  "result": {
    "usage": {
      "text_units": 1,
      "text_characters": 9,
      "features": 1
    },
    "language": "ja",
    "classifications": [
      {
        "confidence": 0.402721,
        "class_name": "スポーツ"
      },
      {
        "confidence": 0.326038,
        "class_name": "経済"
      },
      {
        "confidence": 0.314985,
        "class_name": "IT"
      },
      {
        "confidence": 0.255796,
        "class_name": "エンタメ"
      },
      {
        "confidence": 0.21978,
        "class_name": "科学"
      }
    ]
  }
}


作成した学習データを IBM Watson NLU から削除するには以下のコマンドを実行します:
$ node nlu delete [model_id]

ここまでのオペレーションで NLC 同様に NLU でも「データ学習」、「学習状況確認」、「問い合わせ(分類)」、「学習データ削除」の4つを API で実現し、そのアプリケーションを実行する方法を紹介しました。とりあえず、この4つのオペレーションについては NLC から NLU へ移行することはできそうだ、という感触が持てる結果になりました。


【API レベルの移行作業】
同じオペレーションを行う NLC のツールと NLU のツールを実際に Node.js + IBM Watson SDK で開発してわかったことを記載しておきます。

まず API に互換性はありません。IAM を使った認証部分についてはほぼ同じなのですが、今回行った4つのオペレーションを実現するためのそれぞれの API は NLC のものと NLU のものは全く異なります:
NLC の関数 オペレーションの種類 NLU の関数
IamAuthenticator() 認証 IamAuthenticator()
createClassifier() 分類器/モデルの作成 createClassificationModel()
listClassifiers() 作成した分類器/モデルの参照 listClassificationModels()
classify() 分類/解析 analyze()
deleteClassifier() 分類器/モデルの削除 deleteClassificationModel()


パラメータの指定方法など、詳しくはソースコード(nlc/nlc.js / nlu/nlu.js)を参照していただきたいのですが、大まかには上記表のような関数の違いがあります。特に Node.js + IBM Watson SDK を使っているアプリケーションにおいて NLC から NLU へ移植する場合は、表の左列にある関数を使っている箇所を右列の関数に置き換える、というのが大まかな流れになると思います(実際にはパラメータの指定方法だったり、返り値のフォーマットの違いもあったりするので、単なる文字列置換というわけにはいかないと思います)。また NLC では「分類器(Classifier)」と呼んでいたものが NLU だと「分類モデル(ClassficationModel)」と呼び名が変わっていたりもするので、資料を参照する場合の注意も必要だと思います。

加えて、上記のように NLC を使って問い合わせた結果と NLU に移植後に問い合わせた結果は必ずしも同じ結果とはいきません。このあたりの整合性についても移植の前後で意識しておく必要があります。

とはいえ、少なくとも API のレベルで NLC から NLU へアプリケーションを移植することは不可能ではなさそう、という感触も得ることができました。主要なオペレーションに関しては上述の表を使って関数を新しいものに置き換え、実行結果のフォーマットの違いをプログラミング内で吸収することができれば、ある程度の実現目途は立ちそうだと思っています。


今回の NLC のサービス終了自体は残念ではありますが、一方で見方を変えると、これまで有償サービスでしか提供されていなかった NLC の機能が、無料のライトプランで使える NLU でも利用できるようになった、とも言えます。API レベルでの互換性はありませんが、機能的には珍しくこれまでの機能の多くが移植されていて、「アプリケーションの作り変え」による対応が可能なレベルでマイグレーションができるようになっていると感じました。「料金的にも発展的なサービス統合」であると感じています。


Node.js 以外の開発言語での場合や、IBM Watson SDK の利用有無の違いをどこまで吸収できるかまでを調査したわけではないのですが、一部の言語については後述の参考資料の中でサンプルコードもあるようなので、別環境においてもぜひ挑戦していただき、情報が共有されていくことを願っています。



【参考資料】
https://cloud.ibm.com/docs/natural-language-classifier?topic=natural-language-classifier-migrating

https://cloud.ibm.com/apidocs/natural-language-understanding?code=node


(注 このブログを書いた時点では 2021/02/12 だった更新期限は 2021/05/25 に変更されました)


IBM Watson サービスのエンドポイント URL が更新され、2021年2月12日5月26日に旧URLが廃止される予定です:
IBM Watsonサービスのネットワーク分離機能拡張のためのIAMの更新


IBM Watson の各種サービス API を(以前から)使っていて、そのエンドポイント URL のホスト部分が *.watsonplatform.net というパターンになっている場合にアプリケーションが正しく動作しなくなるなどの影響を受けます。その場合は月の旧URL廃止前に後述の作業を行って、新しい URL に更新する必要があります。

以下、Watson NLC(Natural Language Classifier) を例に対応手順を含めて個人でまとめたので紹介します。NLC 以外のサービスでも概ね同様ですので参考にしてください。また詳しくは後述のリンク先も参照ください。


【現在使っている Watson API のエンドポイント URL を確認】
まず今回の作業は例えば Watson Assistant の画面を使って作業しているだけなど、外部アプリケーションから API を使って呼び出したりしていない場合は関係ありません。apiKey を指定してプログラミングで Watson API を外部から呼び出す形で利用しているケースが対象となります。

現在 Watson API を使ってアプリケーションを動かしている場合、まずはその API のエンドポイントが旧 URL を使っているのか新 URL を使っているのかを確認します(新 URL であれば後述の作業は不要です)。

例えば Watson NLC を使ったアプリケーションであれば、IBM Cloud にログインし、リソース画面のサービス一覧から利用している該当サービス(Watson NLC サービス)を選択します:
2020103001


選択したサービスの概要が表示される画面内に API Key と URL が表示されています(※)。この URL という部分に着目してください:
2020103002


上図の例では
  https://gateway-tok.watsonplatform.net/natural-language-classifier/api
と表示されている部分です。ここがこのように watsonplatform.net という文字を含んでいる場合は旧 URL を利用しています。一方、ここが api.*****.*****.watson.cloud.ibm.com というパターンになっている場合は新 URL を使っています。

※API Key と URL は「サービス資格情報」メニューからも確認できます。

ここで新 URL を使っていることが確認できた場合は後述の作業は不要です。旧 URL を使っている場合は続けて対処が必要です。


【変更先の Watson API 新エンドポイント URL を確認】
上述の作業で旧 URL を使っているアプリケーションは利用エンドポイント URL を新 URL に変更する必要があります。

まず新しい URL を確認するために新しいサービス資格情報を作成する必要があります。上述の作業に続けて画面左のメニューから「サービス資格情報(Service credentials)」を選択し、新しく資格情報を追加して作成します(その際に現在使っている資格情報と同じロールを指定して作成します):
2020103003


追加された資格情報の名前の左側にある小さな矢印をクリックして展開します:
2020103004


Watson サービスの種類によっても異なりますが、概ね以下のような JSON フォーマットの情報が含まれた内容になっています(一部 ***** でマスクしています):
{
  "apikey": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
  "iam_apikey_description": "Auto-generated for key *********************",
  "iam_apikey_name": "Service credentials-1",
  "iam_role_crn": "crn:v1:bluemix:public:iam::::serviceRole:Manager",
  "iam_serviceid_crn": "crn:v1:bluemix:public:iam-identity::********************::serviceid:ServiceId-*************************",
  "url": "https://api.jp-tok.natural-language-classifier.watson.cloud.ibm.com/instances/*************"
}

この JSON の中の url の値(上図では https://api.jp-tok.natural-language-classifier.watson.cloud.ibm.com/instances/************* )が新 URL です(実際の文字列パターンは使っている IBM Watson サービスの種類やロケーションによって異なります。また最後の ***** でマスクされている部分はインスタンス ID という個別の文字列となります)。アプリケーション内の旧 URL が使われている部分をこの新 URL に変更する必要があります。 また同時に旧アプリケーションで使われている apiKey も新しく作成したもの(上図の apikey で表示されている値 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX )に書き換える必要があります。


【変更作業】 
ここまでの作業で変更が必要な箇所と、変更後の値がわかりました。アプリケーションのソースコードを編集し、旧 URL (上述例では https://gateway-tok.watsonplatform.net/natural-language-classifier/api)が使われている部分を新 URL (上述例では https://api.jp-tok.natural-language-classifier.watson.cloud.ibm.com/instances/*************)に、また古い apiKey が使われている部分を新しい apiKey の値(上述例では XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX)に、それぞれ書き直して保存し、新しいコードで動作確認をしてください。

なお、NLC のように学習が必要な API も再学習の必要はありません。学習済みのデータへそのまま問い合わせが利用できるはずです。


以上、個人でまとめたものですが、背景や詳細な情報はソリューションブログや IBM Cloud Document に記載されています。以下情報も参考にしてください:
IBM Watsonサービスのネットワーク分離機能拡張のためのIAMの更新
Updating endpoint URLs from watsonplatform.net(英語)

以前にも似たようなものを何度か作ったことがあったのですが、その最新改良作品です。 ツイッターでのつぶやき内容を元に自分の性格を分析して、その内容が時間とともにどのように変化していくか、を視覚化するというものです。

実際に自分の3月21日時点でのツイートを元にためしてみた結果がこちらです。なお現時点でスマホで表示する場合はレイアイトが最適化されていないため画面を横にして御覧ください:
https://personality-transition.mybluemix.net/transition/6f24cd50fa6f528cdd3162aadb716b03

2020032101


画面は最上部にシェア用のアイコンが並んだ下に性格を分析した本人の twitter アイコンと名前が表示され、その下に IBM Watson Personality Insights API を使った分析結果の「性格分析」と「消費行動動向」が表示されます(「消費行動動向は初期状態では省略表示されているので、内容を表示するには三角形部分をクリック(タップ)してください)。

性格分析はビッグ5と呼ばれる5つの性格要素(知的好奇心、誠実性、外向性、協調性、感情起伏)に加え、ニーズ(共感を呼ぶ度合い)&価値(意思決定に影響を及ぼす要素)という7つのカテゴリを更に細分化した結果がレーダーチャートで表示されます:
2020032102


また消費行動動向はその性格から結びつく消費行動の度合いが表示されます(色の濃い方がその要素が高く、薄い方が低い、という意味です):
2020032103


画面最下部にはスライダーが表示されています。初期状態では一番右にセットされていて、これは時間的に一番新しい分析結果が表示されていることを意味します:
2020032104


このスライダーを左に移動していくと少しずつ前の(古い)性格分析結果や消費行動動向が表示されていきます。自分の性格が時間とともにどのように変化していったのか/変わらない要素は何か といった内容がわかるようになる、というものです:
2020032105


このページの画面右上のリンクから皆さんのツイートでも試すことができます。興味ある方はぜひ挑戦してみて、よろしければその結果を SNS でシェアしてみてください:
https://personality-transition.mybluemix.net/transition/6f24cd50fa6f528cdd3162aadb716b03



以下、このサービスを実現する上での技術要素の説明です。なおソースコードは公開していますので興味ある方はこちらも参照ください。なお IBM Cloud を使って動かす想定のコードとなっており、後述の IBM Watson やデータベース機能含めて無料のライトアカウントの範囲内でもデプロイ可能な内容となっています:
https://github.com/dotnsf/personality_transition


このサービスは Node.js で実装していますが、サービスを実現する上で利用しているライブラリは大きく3つです。1つ目は Twitter のログイン認可を実現するための OAuth 、2つ目は認可したユーザーのツイートを取得するための Twitter API 、そして3つ目は取得したツイート内容から性格分析を行う IBM Watson Personality Insights API です。

なお、ここで使っている IBM Watson Personality Insights は IBM Cloud から提供されている IBM Watson API の1つで、テキストの内容を使用単語レベルで分析し、そのテキストを記述した人の性格や、その性格毎の購買傾向を取得する、という便利な API です。日本語を含む5ヶ国語に対応しています。詳しくはこちらも参照ください:
https://www.ibm.com/watson/jp-ja/developercloud/personality-insights.html


おおまかな処理の流れとしては、まず OAuth2 で Twitter にログインしてもらうことで、そのユーザーの権限で Twitter が操作できるよう認可します。そして Twitter API でユーザーのタイムライン内容を取得します。 この時に直近の 200 ツイートを取得します。この 200 件のツイートを投稿時刻の順に 40 件ずつ5つのブロックにわけます。そして各ブロック毎のツイート内容をそれぞれまとめて IBM Watson Personality Insights API を使って性格分析を行います(つまり1回の処理で Twitter のタイムライン取得 API を1回、IBM Watson Personality Insights API を5回実行します)。このようにすることでツイートの内容を時間で区切って直近のものから少しずつ時間を遡りながら5回ぶんの性格分析を行い、その結果を上述のようにスライダーバーで時間ごとに表示/非表示を切り替えることで実現しています。

機能的にはこれだけでもできるのですが、このサービスでは「分析結果をシェア」できるようにしました。シェアするためには(シェアされた人はツイートを取得せずに分析結果を見ることができる必要があるため)分析した結果をデータベースに格納する必要があるため、データベースも併用しています(あくまで分析結果を保存するためのもので、ツイート内容は保存していません)。

また上述のような仕様であるため、仮に Twitter 上で非公開アカウントとしているアカウントに対しても(本人の権限でツイートを取得することになるので)性格分析を行ったり、その結果をシェアすることができます(公開許可されていない人や、そもそも Twitter アカウントを持っていない人でも分析結果を見ることができます)。ただしあくまで分析結果だけがシェアされるのであって、ツイート内容がシェアされるわけではない点はご安心を。


このデモサービスでは Twitter のツイートを元に性格分析を行っていますが、必ずしも分析元はツイートである必要はありません。1人の人が書いた文章であればよいので、メールなり、社内掲示板なりからテキストを取得することができるのであれば理論上は可能です。ただし1回の性格分析におけるテキストの単語数が少ないと充分な精度がでない結果となることも考えられます。ある程度の単語数が含まれるテキストを取得できる必要があります(このサービスでは上述のように 40 ツイートぶんのテキスト内容をひとまとめにして分析しています)。

また IBM Watson Personality Insights API の特徴でもあるのですが、単にテキスト内容とその単語傾向から性格を分析するだけでなく、購買行動への傾向と合わせた実行結果を得ることができます。つまりまだ何も買っていないユーザーに対してでも、その購買傾向を調べた上でレコメンドを出したり、特定興味分野の広告を出したりする、といった使い方にも応用ができるもので、特に今回のデモではその時間変化にも着目できるようにしています。応用の幅が非常に大きな API であると考えていて、その一部が伝わればいいと思っています。

 

本ブログエントリは IBM Cloud Advent Calendar 2019 に参加しています。12/03 ぶんのネタです。経緯を紹介する導入部分がちと長めですが、お付き合いください。

あまり公に宣伝したりしてなかったのですが、以前に「空耳アワー・マシーン」を作ったことがありました。「空耳アワー」はテレビ番組「タモリ倶楽部」の人気ミニコーナーのあれです。 「外国語で歌われた歌詞が日本語だとこう言っているように聞こえる・・・」という空耳にフィーチャーした紹介コーナーです。ちょっとググってみただけで多くの傑作作品動画が見つかります:
2019112100


この空耳は、曲に合わせて歌われる外国語の歌詞の中で、「日本語だとこう聞こえる」という特徴ある部分を見つけることで成立しています。ふと「・・・これって自動化できるんじゃないか?」と閃いたのが「空耳アワー・マシーン」誕生のきっかけでした。いわゆる "Speech to Text"(音声のテキスト化)機能を使い、外国語の歌唱部分を(その言語ではなく)強制的に日本語でテキスト化する、というロジックです。実装にあたっては IBM Cloud から提供されているWatson Speech to Text API を採用しました。ちなみに Watson Speech to Text はライトプランと呼ばれるプランで利用する場合であれば、各種カスタマイズを行うことはできませんが、毎月 500 分ぶんの音声データ変換までは無料で利用することができます(2019年11月現在)。

実装したソースコード(Node.js 用)はこちらで公開しています:
https://github.com/dotnsf/soramimi

2019112801


ソースコードを git clone するかダウンロードして、settings.js 内で Watson Speech to Text API 用の API キーを指定すると実際にウェブブラウザで動かすことができるようになります。


ウェブブラウザを起動してアプリケーションにアクセスすると、最初にブラウザがマイクの使用許可を求めてくるので「許可」します:
2019112101


画面を下の方にスクロールすると「どの言語でテキスト化するか」を選択するボックスがあります。「空耳アワー」の場合ここは日本語固定ですが、機能としてはここで指定する別言語でも認識→テキスト化を行うこともできるようになっています:
2019112102


言語を指定したらマイクを持った人のアイコン部分を1回クリックして、枠が赤になる(録音モードになる)ことを確認します。枠が赤になっている間に英語の歌をマイクから「歌ってください」(笑)。歌い終わったらもう一度人のアイコンをクリックします。枠は水色に戻り、録音モードも解除されます:
2019112103


録音モードからモードが解除されると同時に、録音された内容が Watson Speech to Text API に渡され、「日本語でどう聞こえたか?」の結果が表示されます:
2019112804



一応、動くには動いています(よね?)。このアプリではマイクを使ってその場で録音した音データを使って日本語テキスト化を行っていますが、理屈の上ではこの入力を外国曲の MP3 データなどに切り替えればいいはず・・・と考えていました。

・・・が、いざそのように使ってみると、仕組みとしては動くのですが、期待していたほどの精度では認識してくれませんでした。もともと Speech to Text 機能は「喋った内容のテキスト化」に最適化されたものであって、「歌った内容のテキスト化」ではないという違いに加えて、「BGMによるノイズ」の影響が多分にあるように感じられました。要するに曲の中で楽器で演奏される部分が Speech to Text 的にはノイズとなってしまい、思っていたほどの精度でテキスト化できなくなっているようだったのでした。 まあネタとしてはある程度使えるが、正しくテキスト化できる箇所が少なすぎて実用(?)にはほど遠い、というものになってしまったのでした。これも公開を控えていた理由の1つでもあります:
2019112802


さて、長い導入部分が終わりました。ここまでが「空耳アワー・マシーン」を「作ってみた」という話で、ここからが本エントリのタイトルでもある「改良してみた」部分です。最近、音楽ストリーミング事業を展開している Deezer 社から spleeter というものすっごいライブラリが公開されました:

無料で曲からボーカルが抜ける音楽素材分離エンジン「Spleeter」公開
2019112104


この spleeter は TensorFlow を用いた機械学習によって音源からボーカルやドラム、ベースといったパーツを抜き出して分離することができるようになる、というオープンソースなライブラリです。音楽ストリーミング事業を展開している Deezer 社の立場を最大限活用し、大量のサンプリングデータを所有している状態で機械学習を行うことができ、その成果をオープンソース化して公開していただいたことになります。ウェブ上のパフォーマンスや精度に関する評判もよいものばかりという印象です。

この spleeter を使うことで上述の空耳アワー・マシーンの BGM ノイズ問題を解決できるのではないか、と考えました。BGM が Speech to Text のノイズとなっていた問題に対して、spleeter で曲データからボーカルデータだけを抜き出しておいて、そのボーカルデータに対して Speech to Text を実行することでノイズのない音声データからのテキスト化が実現できるのではないか!? と考え、これも実装してみました:
2019112803


この機能を実装するためには、あらかじめサーバー上に spleeter を導入しておく必要があります。そして spleeter をインストールする際にはパッケージ管理ツールである conda が必要になります。というわけでまずは conda (今回は簡易版の miniconda)を導入します。このページから自分のシステム環境にあった miniconda のインストーラーを選択してダウンロードし、実行して導入します:
2019112101
(↑画面は Linux 版 Miniconda のダウンロードリンクを選択する箇所)

miniconda 導入後に spleeter を導入します。コードは github で公開されているので、以下の手順を実行します:
$ git clone https://github.com/deezer/spleeter

$ conda env create -f spleeter/conda/spleeter-cpu.yaml

これで spleeter の導入が完了しました。spleeter を利用するにはまず以下のコマンドで spleeter をアクティベートし、・・: 
$ conda activate spleeter-cpu

続けて spleeter をテスト実行します。spleeter フォルダの中にサンプルの mp3 ファイル(spleeter/audio_example.mp3)があるので、これを使って実行してみます。今回はボーカルとそれ以外(2stems)に分割し、実行結果を output フォルダ以下に作成する、というオプションを指定して実行してみました:
$ spleeter separate -i spleeter/audio_example.mp3 -p spleeter:2stems -o output

成功すると ./output/audio_example/ というフォルダ(フォルダ名はファイル名から生成される)が作成され、その中に vocals.wav と accompaniment.wav という2つのファイルが生成されています。vocals.wav がボーカルだけを抜き出したもの、accompaniment.wav がボーカルを抜き出した残りの音源です:
2019112102


実際に audio_example.mp3(元の曲)と、vocals.wav(ボーカルのみ) / accompaniment.wav(ボーカル以外)を聴き比べてみるとわかるのですが、信じられないくらいキレイにボーカルが分離されています。これが無料でできるとは驚き!

audio_example.mp3(元の曲)
vocals.wav(ボーカルのみ)
accompaniment.wav(ボーカル以外)



そしてこれを上述の空耳アワー・マシーンに組み込んでブラウザから実行できるように改良してみました。この拡張機能は上述のソースコードにも含まれているので、こちらの機能を試す場合はアプリケーション実行後に /spleeter.html にアクセスすると、mp3 の音楽ファイルを指定して実行することができます(結果は out/ フォルダ内に作成されます):


そして実行してみましたが・・・ 想定外だったのは処理時間でした。例えば5分程度の曲を対象にした場合、これまでは単に Watson Speech to Text を実行するだけで、その処理時間が1分を超えるようなことはなかったのですが、spleeter でのボーカル抜き出し処理だけで5分前後かかるようになりました(ちなみに自分の PC のスペックは i5-8350 の8コアCPUでメモリは 8GB)。これは処理内容を考えるとかなり高速な処理であるとは思いますが、これまでと比べると、1曲単位での処理にかなり長い時間がかかるようになった、という印象です。 またその長い処理の間、CPU やメモリはほぼフル稼働となります。仮にネット上から利用できるサービスとして作ろうとすると、かなり高いスペックのサーバーインスタンスを用意する必要があることに加え、タイムアウトとの戦いも意識して実装する必要がある、という印象を持っています。 といった背景もあって、現時点ではバッチでまとめて処理して後から結果を確認する、という方向での実装が中心です。


一方、この処理によって得られた結果は spleeter で分離する前とは比較にならないほど良質でした。Watson Speech to Text API は日本語としてある程度の確信度をもって認識出来なかった部分は結果に含まれない(つまり正しく認識できた部分のみが結果として得られる)のですが、分離前は「あー」とか「うー」とかいうコーラス部分を除くとほんの数箇所だけが識別できていたのですが、分離後の結果のサイズは数倍になりました。つまりボーカルだけを対象とすることで識別可能な音声が数倍になった、ということになります。なお上述の vocals.wav (ボーカルのみ抜き出したオーディオデータ)を Speech to Text で変換した結果は以下になりました:
{
  "status": true,
  "results": [
    {
      "alternatives": [
        {
          "timestamps": [
            [
              "令和",
              2.37,
              2.77
            ],
            [
              "OSS",
              2.77,
              3.77
            ],
            [
              "は",
              3.77,
              3.88
            ],
            [
              "萌え",
              5.96,
              6.25
            ]
          ],
          "confidence": 0.38,
          "transcript": "令和 OSS は 萌え "
        },
        {
          "transcript": "令和 OSS は 親 "
        },
        {
          "transcript": "映画 を SNS は 萌え "
        }
      ],
      "final": true
    }
  ]
}

↑確信度は 0.38 とあまり高くありませんが、データの 2.37 秒から 6.25 秒部分が赤字のように聞こえた、という結果です。


「本当に空耳アワーでそのまま即採用されるレベルの空耳が検出できるか?」という観点においては残念ながら難しそうな印象を持っています。特に Watson はエロネタは不得意っぽい(?)のか、結果にエロなワードは皆無でした。まあこのあたりは有料版の Watson Speech to Text でカスタマイズすると変わってくるのかもしれませんが・・・ ただそのまま採用されるようなレベルでの検出はできなかったとはいえ、ここで検出された結果をヒントにそれっぽいワードを混ぜて改良すればもしや・・・ という期待は充分に持てる結果になりました。一ヶ月に 500 分、1曲5分とすれば一ヶ月で約 100 曲ほど無料で空耳を調査できることになります。あのTシャツを狙って・・・はまだ遠い夢かもしれませんが、(個人的に欲しい)耳かきあたりは狙えるんじゃないか・・・と期待が膨らむ結果となりました。

このページのトップヘ