Warum wir Daten horten: Von gescrapten Katalogen zu intelligenteren Sprach- und Sprachmodellen

Wir schreiben viel darüber, wie wir Daten extrahieren – das Recon-Tooling, die Anti-Bot-Transporte, die typisierten Clients für Musik-Metadaten. Eine berechtigte Frage ist warum. Wir sind ein Unternehmen für Sprach-KI; was tun wir da, Scraper für Musikenzyklopädien und Radioverzeichnisse zu pflegen?

Die Antwort lautet: Daten stehen allem vorgelagert, was wir ausliefern. Ein Sprachassistent ist nur so gut wie die Wörter, die er zu hören erwartet, die Entitäten, die er erkennen kann, und die Aussprachen, die er kennt. Nichts davon stammt aus Architekturdiagrammen. Es stammt aus Daten – und die interessanten Daten liegen selten in einem gebrauchsfertigen Datensatz bereit. Sie sind über das öffentliche Web verstreut, in Katalogen, die Menschen über Jahrzehnte kuratiert haben.

Hier ist, was mit diesen Daten geschieht, nachdem wir sie erhoben haben.

Entitäten: das Vokabular, von dem ein Sprachassistent lebt

Sagen Sie einem Assistenten “spiele Sultans of Swing von Dire Straits”. Bevor irgendein Modell darauf reagieren kann, muss etwas wissen, dass Sultans of Swing ein Track und Dire Straits ein Künstler ist. Multiplizieren Sie das mit jedem Künstler, Album, Sender, Podcast und Genre, das ein Nutzer benennen könnte, und Sie haben das tatsächliche Vokabular eines Medienassistenten – Hunderttausende benannter Entitäten, von denen keine in einem herkömmlichen NLP-Trainingskorpus auftaucht.

Unsere Medien-Clients geben genau dies aus: typisierte Datensätze mit kanonischen IDs, normalisiert in das mediavocab-Schema. Diese Entitätskataloge fließen direkt in Folgendes ein:

Schlüsselwortbasiertes Intent-Matching – Entitätslisten werden zu den Gazetteers, die Medienabfragen in OpenVoiceOS verankern.
Intent-Klassifikatoren – unsere Media-Intent-Datensätze kombinieren echte gescrapte Entitäten mit vorlagen- und LLM-gestützter Satzsynthese und erzeugen so Äußerungen, wie sie echte Nutzer machen, bestückt mit Entitäten, die tatsächlich existieren. So trainierte Modelle treffen die Entscheidung “ist dies eine Wiedergabeanfrage, und wofür?” in der Medien-Pipeline von OpenVoiceOS.
Synthetische NER-Korpora – dasselbe Rezept lässt sich verallgemeinern: nehmen Sie einen Katalog echter Entitäten, generieren Sie natürliche Sätze um sie herum, und Sie haben einen etikettierten Named-Entity-Datensatz für eine Domäne, die kein akademisches Korpus abdeckt. Die Entitäten sind echt, also ist die Verteilung ehrlich; die Sätze sind synthetisch, also ist das Volumen so groß, wie Sie es brauchen.

Spracherkennung auf die Wörter ausrichten, die zählen

Allzweck-ASR wird auf allgemeiner Sprache trainiert und transkribiert Dire Straits daher als “dire straights” und verstümmelt jeden portugiesischen Dorfnamen. Die Lösung besteht nicht darin, von Grund auf neu zu trainieren – sie heißt Biasing: dem Erkenner das Vokabular Ihrer Domäne geben.

Gescrapte Kataloge sind dieses Vokabular. Konkret:

Sprachmodell-Biasing – n-Gramm- oder Shallow-Fusion-LMs, die auf entitätenreichem Text trainiert werden, lenken den Decoder in Richtung domänenspezifischer Wörter. Das LM eines Medienassistenten sollte auf Tracktiteln und Künstlernamen trainiert werden, und unseres kann das, weil wir sie haben – typisiert, dedupliziert, mit sauberer Provenienz.
Prompt-konditionierte Erkennung – neuere Architekturen akzeptieren zur Inferenzzeit einen Text-Prompt oder eine Kontextliste. Die tatsächliche Bibliothek des Nutzers – die Entitäten, die unsere Clients extrahiert haben – in den Kontext des Erkenners einzuspeisen, verwandelt einen “unerkennbaren Eigennamen” in ein “bekanntes Vokabularelement”.
Fine-Tuning-Daten – wo Biasing nicht ausreicht, erzeugen Entitätskataloge zusammen mit unseren TTS-Stimmen synthetische Sprache für genau die Phrasen, die ein Deployment nicht falsch verstehen darf. Dies ist der Dienst zur Datensatzerstellung, den wir kommerziell anbieten, und er baut auf derselben offenen Pipeline auf.

Aussprache: von gecrawlten Wörterbüchern zu G2P und TTS

Einige unserer wertvollsten Crawls sind keine Entitätskataloge, sondern Lexika. Das Crawlen des Infopédia-Wörterbuchs ergab infopedia-pt-ipa, über 100.000 Wort→IPA-Paare des europäischen Portugiesisch. Dieser Datensatz:

benchmarkt und optimiert unseren regelbasierten G2P-Stack für Portugiesisch,
verankert die Aussprache für TTS-Stimmen, damit sie Wörter so sagen, wie Sprecher es tatsächlich tun,
und dient als Ausgangspunkt für bedeutungsetikettierte Ressourcen wie unsere Arbeit zu portugiesischen Heterophonen, bei der dieselbe Schreibweise je nach Bedeutung auf unterschiedliche Laute abbildet.

Schreibung-zu-Laut-Daten sind die am wenigsten glanzvolle Ecke der Sprachtechnologie und diejenige, die am meisten darüber entscheidet, ob eine Stimme muttersprachlich klingt. Niemand reicht Ihnen diese Daten. Sie crawlen sie, säubern sie und veröffentlichen sie – damit das nächste Team es nicht mehr tun muss.

Ehrlicher Treibstoff für LLMs

Alles Obige gilt auch für große Sprachmodelle, mit einer zusätzlichen Wendung: Provenienz zählt inzwischen mehr als Volumen. Das offene Web ist zunehmend mit modellgeneriertem Text kontaminiert; darauf zu trainieren oder zu evaluieren, recycelt stillschweigend die Ausgaben der Modelle von gestern. Deshalb legen wir Wert auf Quellen mit sauberer menschlicher Provenienz – Jahrzehnte an Usenet-Archiven, kuratierte Enzyklopädien, offizielle Wörterbücher – und deshalb gibt jeder Datensatz, den wir veröffentlichen, an, woher jeder Datensatzeintrag stammt.

Strukturierte Kataloge speisen LLMs auch zur Inferenzzeit: ein typisierter, deduplizierter Entitätsspeicher ist genau das, was eine Retrieval-Schicht oder die Tool-API eines Agenten braucht, um ihre Antworten zu verankern. Saubere APIs über unordentlichen Quellen sind nicht nur eine Scraping-Bequemlichkeit – sie sind die Art und Weise, wie man ein Sprachmodell an Fakten gebunden hält.

Die Pipeline, von Anfang bis Ende

Das Gesamtbild sieht also so aus:

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)

Jede Stufe ist Open Source, jeder Datensatz wird veröffentlicht, wo die Lizenzierung es erlaubt, und dieselbe Pipeline, die den Bedarf unserer eigenen Modelle deckt, steht als Auftrag für Ihre zur Verfügung. Die Scraper sind keine Nebenquest. Sie sind der Steinbruch, aus dem der gesamte Stack gebaut ist.