私たちはデータを どのように 抽出するかについて多くを書いてきました — 偵察ツール、 アンチボット・トランスポート、 型付けされた音楽メタデータクライアント です。 もっともな問いは なぜ かということです。私たちは音声 AI の会社です。音楽百科事典やラジオ ディレクトリのためのスクレイパーを維持して、いったい何をしているのでしょうか？
その答えは、データは私たちが提供するすべての上流にある ということです。音声 アシスタントは、聞くと予期する言葉、認識できるエンティティ、知っている発音の質を 超えることはできません。それらはどれもアーキテクチャ図から生まれるものではありません。 それはデータから生まれます — そして興味深いデータが、出来合いのデータセットの中に 待っていることはめったにありません。それは公開ウェブ全体に散らばっており、人間が 数十年かけてキュレーションしてきたカタログの中にあります。
私たちがそのデータを収集した後、それに何が起こるのかをご紹介します。
エンティティ：音声アシスタントが生きる糧となる語彙
アシスタントに「Dire Straits の Sultans of Swing を再生して」と言ってみてください。 どんなモデルもそれに対して行動する前に、Sultans of Swing が楽曲であり、 Dire Straits がアーティストであることを何かが知っていなければなりません。それを、 ユーザーが名前を挙げうるあらゆるアーティスト、アルバム、放送局、ポッドキャスト、 ジャンルで掛け合わせれば、メディアアシスタントの真の語彙 — 数十万の名前付き エンティティ — が得られます。そのどれ一つとして、標準的な NLP 学習コーパスには 現れません。
当社のメディアクライアントはまさにこれを出力します。正規の id を持つ型付けされた レコードを、mediavocab スキーマに 正規化したものです。それらのエンティティカタログは、直接次のものに供給されます：
- キーワードベースの意図マッチング — エンティティのリストは、OpenVoiceOS で メディアクエリを基礎づける gazetteer になります。
- 意図分類器 — 当社のメディア意図データセットは、実際にスクレイピングされた エンティティを、テンプレートおよび LLM 支援による文の合成と組み合わせ、実際の ユーザーが作るような発話を、実際に存在するエンティティを詰め込んで生成します。 そのように学習されたモデルは、OpenVoiceOS のメディアパイプラインにおいて「これは 再生リクエストか、何のための？」という判断を処理します。
- 合成 NER コーパス — 同じレシピが一般化します。実際のエンティティのカタログを 取り、その周りに自然な文を生成すれば、どの学術コーパスもカバーしないドメインの ためのラベル付き名前付きエンティティデータセットが手に入ります。エンティティは 本物なので、分布は誠実です。文は合成なので、量は必要なだけ得られます。
音声認識を、重要な言葉へバイアスさせる
汎用の ASR は一般的な発話で学習されているため、Dire Straits を「dire straights」と 書き起こし、あらゆるポルトガルの村の名前を台無しにします。その修正はゼロからの 再学習ではありません — それは バイアシング です。すなわち、認識器にあなたの ドメインの語彙を与えることです。
スクレイピングされたカタログがその語彙です。具体的には：
- 言語モデルによるバイアシング — エンティティ豊富なテキストで学習された n-gram または shallow-fusion の LM は、デコーダーをドメイン内の言葉へと後押しします。 メディアアシスタントの LM は 楽曲名とアーティスト名 で学習されるべきであり、 当社のものはそうできます。なぜなら、それらを持っているからです — 型付けされ、 重複排除され、出所のきれいなものを。
- プロンプト条件付き認識 — より新しいアーキテクチャは、推論時にテキスト プロンプトやコンテキストリストを受け付けます。ユーザーの実際のライブラリ — 当社の クライアントが抽出したエンティティ — を認識器のコンテキストに与えることで、 「認識できない固有名詞」を「既知の語彙項目」へと変えます。
- ファインチューニング用データ — バイアシングでは不十分な場合、エンティティ カタログと当社の TTS 音声 が、 ある導入が絶対に間違えてはならない正確なフレーズのための合成音声を生成します。 これは当社が商業的に提供する データセット構築サービス であり、 同じオープンなパイプラインの上に構築されています。
発音：クロールした辞書から G2P と TTS へ
当社の最も価値あるクロールの一部は、エンティティカタログではなく 辞書 です。 Infopédia 辞書のクロールは、10 万を超えるヨーロッパポルトガル語の単語→IPA のペアである infopedia-pt-ipa を 生み出しました。そのデータセットは：
- 当社のルールベースの ポルトガル語 G2P スタック をベンチマークし、調整します。
- TTS 音声 の発音を 基礎づけ、話者が実際に発音するとおりに言葉を言えるようにします。
- そして、同じ綴りが意味に応じて異なる音に対応する当社の ポルトガル語同綴異音語の取り組み のような、 意味ラベル付きのリソースの種となります。
綴りから音へのデータは、音声技術の中で最も華やかさに欠ける片隅であり、声がネイティブ らしく聞こえるかどうかを最も大きく左右するものです。誰もこのデータを手渡してくれません。 あなたがそれをクロールし、きれいにし、公開するのです — 次のチームがそうしなくて 済むように。
LLM のための誠実な燃料
上記のすべては大規模言語モデルにも当てはまりますが、一つ余分なひねりがあります。 今や出所は量よりも重要です。 オープンウェブはモデルが生成したテキストで ますます汚染されており、その上で学習や評価をすることは、昨日のモデルの出力を ひそかに再利用することになります。だからこそ私たちは、きれいな人間の出所を持つ ソース — 数十年分の Usenet アーカイブ、 キュレーションされた百科事典、公式の辞書 — を大切にし、そして私たちが公開する すべてのデータセットが、各レコードがどこから来たのかを明記しているのです。
構造化されたカタログは、推論 時にも LLM に供給されます。型付けされ、重複排除された エンティティのストアは、retrieval レイヤーやエージェントのツール API が、その回答を 基礎づけるためにまさに求めるものです。乱雑なソースの上のきれいな API は、単なる スクレイピングの便宜ではありません — それは、言語モデルを事実につなぎ止めておく 方法なのです。
パイプライン、端から端まで
というわけで、全体像はこのようになります：
recon → resilient extraction → typed clients → normalised catalogues
→ gazetteers & intent data (NLP)
→ biasing LMs & fine-tune sets (ASR)
→ lexicons & phoneme labels (G2P / TTS)
→ provenance-clean corpora (LLMs, retrieval)各段階はオープンソースであり、各データセットはライセンスが許すところで公開され、 当社自身のモデルのニーズを満たすのと同じパイプラインが、あなたのために プロジェクトとして 利用可能です。スクレイパーはサイドクエストでは ありません。それは、スタック全体がそこから築かれる採石場なのです。