Einsatz von maschinellem Lernen (ML) für mehr Sicherheit im Sprachchat

Unsere Mission ist es, eine Milliarde Menschen miteinander in Verbindung zu bringen – mit Optimismus und Respekt. Um das zu erreichen, müssen wir dafür sorgen, dass die Menschen einen tatsächlichen Zusammenhalt untereinander spüren. In immersiven 3D-Welten gibt es, ähnlich wie in der physischen Welt, kaum etwas Authentischeres oder Wirkungsvolleres als die menschliche Stimme, um langwährende Freundschaften und Verbindungen aufzubauen. Aber wie können wir die Kraft und den großen Wirkungsbereich gesprochener Sprache auf Roblox ausbauen und gleichzeitig die Sicherheit und den respektvollen Umgang in unserer Community gewährleisten?

In diesem Blogartikel erzählen wir, wie wir “Real-time Safety“ entwickelt haben – ein umfassendes Modell für maschinelles Lernen (ML), das täglich Millionen von Minuten an Sprachaktivität überwacht und Richtlinienverstöße in der Sprachkommunikation sogar noch genauer erkennt als ein Mensch. Die Outputs dieses Systems werden in ein weiteres Modell eingespeist, das angemessene Konsequenzen festlegt. Das Konsequenzmodell löst Benachrichtigungen für Personen aus, die gegen unsere Richtlinien verstoßen haben – zunächst mit Warnungen und bei anhaltendem Fehlverhalten mit strengeren Maßnahmen.

Dieses umfassende Real-time-Safety-System war ein ehrgeiziges Ziel, da wir zu den Ersten in der Branche gehören, die mehrsprachige und nahezu in Echtzeit arbeitende Sicherheitsfunktionen für Sprachkommunikation bereitstellen. Die Klassifizierung der Sprache hängt sowohl vom Audiostil – wie Lautstärke und Tonfall – als auch vom Inhalt, also den gesprochenen Wörtern, ab. Wir freuen uns, zu zeigen, wie wir das System entwickelt haben. Zuvor gab es nahezu keine Automatisierung, also auch keine gelabelten Daten oder Modelle. Nun haben wir eine effiziente Echtzeit-Sicherheitslösung für die Sprachkommunikation.

Abschließend freuen wir uns, unser erstes Open-Source-Modell vorstellen zu können: eines unserer Sprachsicherheitsmodelle. Indem wir dieses Modell als Open Source zur Verfügung stellen und für die kommerzielle Nutzung freigeben, möchten wir einen Branchenstandard für die Erkennung von Richtlinienverstößen schaffen, der die Entwicklung neuer ML-Modelle zur Sprachsicherheit beschleunigen kann. Dieses Open-Source-Modell ist unsere erste Version. Daran haben wir seit Einführung umfangreiche Verbesserungen vorgenommen und testen diese im Moment.

So konnten wir die Datenknappheit überwinden

Wir begannen unsere Reise mit maschinellem Lernen, wie viele Unternehmen es tun: mit der Bewertung der Qualität der verfügbaren Daten. So konnten wir unsere Modelle trainieren und evaluieren. Der ideale Datensatz enthält Sprachäußerungen zusammen mit einer hochwertig gelabelten Sicherheitskategorisierung für einzelne Äußerungen. Als wir anfingen, standen uns allerdings kaum weitreichende, manuell gelabelte Daten aus der echten Welt zur Verfügung. Um ein qualitativ hochwertiges Modell zur Erkennung von Sprachsicherheitsverstößen unter Verwendung eines überwachten Ansatzes zu trainieren, hätten wir Tausende Stunden gelabelte Audiodaten für jede unterstützte Sprache benötigt. Das Sammeln dieser Daten hätte Jahre gedauert und wäre extrem ressourcen- und zeitintensiv gewesen.

Anstatt uns auf viele Stunden manuell gelabelter Daten zu verlassen, haben wir mehrere effizientere Methoden entwickelt:

• Maschinell gelabelte Trainingsdaten: Anstatt uns auf die mühsame Beschaffung perfekt manuell gelabelter Daten zu konzentrieren, entschieden wir uns für ein großes Volumen an Trainingsdaten, die anhand von maschinellem Labeling von Sprachäußerungen erstellt wurden. Der Einsatz großer Mengen maschinell gelabelter Daten mit geringer Überwachung führte zu Trainingsmodellen, die gegenüber einem gewissen Maß an “Rauschen“ in den Labels resistent waren. Der Schlüssel zum Erfolg war der Zugriff auf hochwertige Open-Source-Spracherkennungsbibliotheken sowie jahrelange Erfahrung im Einsatz von ML zur Erkennung von Verstößen gegen Community-Standards in der textbasierten Kommunikation. Durch diesen maschinellen Labeling-Ansatz konnten wir das benötigte Volumen an Trainingsdaten für unsere Modelle innerhalb von Wochen statt Jahren bereitstellen.

• Von Menschen gelabelte Daten zur Evaluierung: Obwohl hochwertige, aber nicht perfekte maschinell gelabelte Daten ausgereicht hätten, um ein leistungsstarkes Modell zu trainieren, wollten wir uns für die abschließende Validierung des resultierenden Modells nicht auf die maschinellen Labels verlassen. Die nächste Frage war also, woher wir genügend menschlich gelabelte Daten für die Evaluierung bekommen könnten. Es war zwar nicht möglich, rechtzeitig genügend solcher Daten für das Training zu sammeln, wir konnten aber immerhin ausreichend Daten für die Evaluierung unseres Modells erhalten. Unsere internen Moderatoren, die bereits Missbrauchsmeldungen auf Roblox prüften und manuell Konsequenzen verhängten, konnten diese Daten bereitstellen. So konnten wir beides kombinieren: viele maschinell gelabelte Trainingsdaten für ein leistungsstarkes Modell und ausreichend menschlich gelabelte Evaluierungsdaten, um sicherzustellen, dass das Modell zuverlässig funktioniert.

Ein weiteres Problem mit Datenknappheit hatten wir bei Kategorien von Richtlinienverstößen, die nur selten vorkommen, wie Hinweise auf Drogen und Alkohol oder Selbstverletzung. Um dieses Problem zu lösen, fassten wir mehrere seltene Kategorien zu einer “Sonstige“-Kategorie zusammen. Unser finales Modell konnte schließlich die Kategorien Kraftausdrücke, Mobbing, Diskriminierung, Dating und Sonstige erkennen. Um diese “sonstigen“ Inhalte besser zu verstehen, werden wir sie weiterhin beobachten, um mehr Beispiele zu sammeln. So können wir unsere Community besser schützen und für eine sichere und respektvolle Kommunikation auf Roblox sorgen. Mit der Zeit werden die Unterkategorien in “Sonstige“ ebenfalls Namen erhalten, und zwar sobald die Trainingsbeispiele in diesen Unterkategorien eine bestimmte Anzahl erreichen.

Maschinelle Labeling-Pipeline für Trainingsdaten

Wir haben eine vollautomatische maschinelle Labeling-Pipeline entwickelt, um hochwertige Labels aus Sprachchat-Sequenzen zu extrahieren. Unsere Pipeline besteht aus drei Stufen:

1. Audio-Chunk-Splitting. Im ersten Schritt der Pipeline wird das Audio in Chunks, also kürzere Abschnitte, unterteilt, sobald wir stille Phasen zwischen Sätzen erkennen. Das ermöglicht es uns, Richtlinienverstöße effizienter zu identifizieren und zu labeln.

2. Audio-Transkription. Im zweiten Schritt der Pipeline werden diese Audio-Chunks mithilfe eines automatischen Spracherkennungsmodells (ASR) in Text transkribiert. Wir nutzen öffentlich verfügbare Open-Source-ASR-Modelle.

3. Textklassifizierung. Im letzten Schritt der Pipeline wird der transkribierte Text mit unserem eigenen Textfilter klassifiziert. Dieser Filter wurde entwickelt, um unangemessene Inhalte in textbasierten Kommunikationen zu erkennen und zu blockieren. Wir haben den Filter an die transkribierten Audiodaten angepasst, sodass wir die Audio-Chunks mit Klassen und Schlüsselwörtern für Richtlinienverstöße labeln können. Der Textfilter ist ein Ensemble-Modell, das auf menschlich gelabelten Daten zu Richtlinienverstößen basiert und eine erweiterte DistilBERT-Variante sowie reguläre Ausdrucksregeln umfasst.

Es ist wichtig zu betonen, dass diese Pipeline ausschließlich zur Erstellung von Trainingsdaten für unser endgültiges Produktionsmodell verwendet wurde. Warum trainieren wir aber überhaupt ein Modell, wenn es bereits eine Pipeline gibt, die die gewünschten Labels erzeugt? Die Antwort liegt in der Effizienz: Wir müssen äußerst präzise sein und das in viel kürzerer Zeit. Bei der Größenordnung von Roblox würde es zu lange dauern und zu viele Ressourcen verbrauchen, alle Sprachkommunikationen mit ASR zu transkribieren. Ein kompaktes ML-Modell, das mit diesen Daten trainiert wurde und speziell darauf ausgelegt ist, Richtlinienverstöße in Sprachkommunikationen zu erkennen, ohne eine vollständige Transkription vorzunehmen, ist ebenso genau, jedoch deutlich schneller und kann auch in umfangreichen Anwendungsfällen, wie etwa bei Roblox, eingesetzt werden.

Skalierung der maschinellen Labeling-Pipeline

Bei den meisten groß angelegten KI-Projekten ist der Mechanismus zur Gewinnung hochwertiger Trainingsdaten selbst ein Produktions-ML-System, das von Grund auf neu erstellt werden muss. Für dieses Projekt mussten wir unsere maschinelle Labeling-Pipeline als erstklassiges Produktionssystem entwickeln, das rund um die Uhr verfügbar ist und sich auf Tausende paralleler CPUs oder eine entsprechende Anzahl von GPUs skalieren lässt. Wir haben einen Trainingsdaten-Cluster mit Tausenden von CPU-Kernen eingesetzt, der eingehende Audiostreams automatisch parallel verarbeitet, um maschinelle Labels zu generieren. Das System musste einwandfrei laufen, um maximalen Durchsatz zu gewährleisten, da durch Fehler oder Ausfallzeiten bei der Generierung von Trainingsdaten Tage oder Wochen verloren gehen könnten.

Nachfolgend ein Überblick über die Architektur, die es uns ermöglichte, in nur wenigen Wochen zehntausende Stunden Audiodaten maschinell zu labeln. Die zentrale Erkenntnis war, dass der gezielte Einsatz von Warteschlangen an entscheidenden Stellen unserer Verarbeitung es uns ermöglichte, Engpässe zu beseitigen, indem wir Worker-Threads horizontal auf viele Maschinen skalierten. Diese Worker-Threads übernahmen die im vorherigen Abschnitt beschriebenen Schritte der Audio-Chunk-Aufteilung, Audio-Transkription und Textklassifizierung.

ML-Architektur

Eine zentrale Anforderung bei der Suche nach einem geeigneten Modell war eine geringe Latenz, also nahezu Echtzeitgeschwindigkeit bei der Modellinferenz. Dies führte uns zu Architekturen, die direkt mit Roh-Audiodateien arbeiten und eine Bewertung zurückgeben. Wir setzen Transformer-basierte Architekturen ein, die sich hervorragend für die Sequenzzusammenfassung eignen und in der Branche für natürliche Sprachverarbeitung (NLP) und Audiomodellierung sehr erfolgreich sind. Die Herausforderung bestand darin, einen optimalen Kompromiss zu finden: ein Modell, das einerseits komplex genug ist, um mehrere Sprachen und Akzente, Robustheit gegenüber Hintergrundgeräuschen und unterschiedliche Audioqualität zu bewältigen, andererseits aber auch die niedrigen Latenzanforderungen unseres Produkts erfüllt.

Modellauswahl

Eine der ersten Designentscheidungen war es, die Größe des Kontextfensters festzulegen, das für das Training der Transformer-Modelle erforderlich ist. Wir betrachteten das Histogramm der Äußerungslängen in Sprachchats über mehrere Tage hinweg und kamen zu dem Schluss, dass ein 15-Sekunden-Fenster den besten Kompromiss zwischen Latenz und ausreichend Kontext für die Klassifizierung bietet. Wir verwenden “keine Verstöße“ als Kategorie, um zu erkennen, wenn es keine Richtlinienverstößen gibt. Da ein einzelner Audioclip mehrere Arten von Verstößen enthalten kann, wird die Aufgabe von einem herkömmlichen Multiklassen-Klassifizierungsproblem zwangsläufig zu einem Multilabel-Problem. Wir haben das gesamte Netzwerk einschließlich der Kopflagen für diese Aufgabe mit Binary Cross-Entropy (BCE) Loss abgerundet.

Bildunterschrift: Histogramm der Sprachäußerungen aus Chat-Daten, das zeigt, dass 75% der Äußerungen weniger als 15 Sekunden dauern.

Wir haben mehrere beliebte Open-Source-Encoder-Modelle aus der Audioforschung evaluiert und unsere Auswahl auf WavLM und Whisper eingegrenzt. Unser erster Versuch bestand darin, das vortrainierte WavLM base+ mit 2.300 Stunden maschinell gelabelter Roblox-Sprachdaten anzupassen und die Klassifikationsergebnisse auf zwei realen Evaluierungsdatensätzen zu testen. Wir erzielten sehr vielversprechende Klassifikationsergebnisse (siehe Modellbewertung unten), stellten jedoch fest, dass die Latenz größer war als unsere Schwellenwerte für den Einsatz in der Produktion. Daraufhin implementierten wir eine angepasste Version der WavLM-Architektur mit weniger Transformer-Lagen und trainierten ein End-to-End-Modell von Grund auf mit 7.000 Stunden maschinell gelabelter Roblox-Sprachdaten. Dieses Modell liefert in Gesprächssituationen robuste Klassifikationen und ist kompakter als das angepasste Modell. Unser finales Modell verwendete ein Student-Teacher-Distillation-Setup, wobei ein Whisper-Encoder als Teacher-Netzwerk und die WavLM-End-to-End-Architektur als Student-Netzwerk diente. Als wir es mit 4.000 Stunden Audiodaten trainiert hatten, erzielten wir eine Genauigkeit bei der Klassifikation, die der des angepassten Modells ähnelte, jedoch mit deutlich geringerer Latenz und einer kleineren Modellgröße. Das Bild unten fasst die Modellparameter für die drei oben beschriebenen Experimente zusammen. Wir arbeiten weiterhin daran, die Datensampling- sowie Evaluierungsstrategien und Modell-Hyperparameter zu verbessern. Gleichzeitig bauen wir die Modelle für die mehrsprachige Sicherheitsklassifikation aus.

Modelloptimierung

Wir verwendeten branchenübliche Methoden, darunter die Quantisierung ausgewählter Transformer-Lagen, um eine Geschwindigkeitssteigerung von mehr als 25% zu erreichen, ohne dabei die Qualität zu beeinträchtigen. Der Wechsel des Merkmalsextraktionsschritts zu MFCC-Eingaben in Kombination mit Faltungsnetzwerken (Convolutional Neural Network, CNNs) anstelle von nur CNNs führte ebenfalls zu mehr als 40% schnelleren Inferenzzeiten. Zudem verbesserte der Einsatz eines Sprachaktivitätserkennungsmodells (Voice Activity Detection, VAD) als Vorverarbeitungsschritt die Robustheit der gesamten Pipeline erheblich, insbesondere für Benutzer mit lauten Mikrofonen. Das VAD erlaubte es uns, Störgeräusche herauszufiltern und unsere Sicherheits-Pipeline nur dann anzuwenden, wenn menschliche Sprache in der Audiodatei erkannt wurde. Dies reduzierte die Gesamtmenge der Inferenz um etwa 10% und lieferte hochwertigere Eingaben für unser System.

Modellbewertung

Obwohl wir viele verschiedene Datensätze und Metriken für die Evaluierung verwendet haben, können wir hier zeigen, wie unser Sprachklassifikator auf einem englischsprachigen Datensatz mit einer großen Häufigkeit von Richtlinienverstößen abgeschnitten hat (ähnlich dem, was wir in Sprachmissbrauchsmeldungen von Benutzern finden würden). Dieser Datensatz wurde von unseren Moderatoren vollständig manuell gelabelt. Als wir alle Verstoßtypen (Kraftausdrücke, Mobbing, Dating usw.) zu einer einzigen binären Kategorie zusammenfassten, erzielten wir einen PR-AUC-Wert (Fläche unter der Präzisions-Recall-Kurve) von über 0,95, wie unten dargestellt. Das bedeutet, dass der Klassifikator in diesem Evaluierungsdatensatz typischerweise einen Großteil der Verstöße erkennt, ohne dabei zu viele unproblematische Inhalte fälschlicherweise zu markieren.

Die starken Evaluierungsergebnisse oben lassen sich jedoch nicht unbedingt direkt auf alle Anwendungsfälle übertragen. Zum Beispiel bewertet der Klassifikator bei unseren Benachrichtigungen über richtlinienwidrige Sprache alle Roblox-Sprachchats. Da dabei weniger Verstöße vorkommen, besteht eine größere Wahrscheinlichkeit für falsch-positive Ergebnisse. Bei Sprachmissbrauchsmeldungen bewertet der Klassifikator nur Sprache, die bereits wegen potenzieller Verstöße markiert wurde, wodurch die Häufigkeit solcher Verstöße höher ist. Trotzdem waren die oben genannten Ergebnisse ermutigend genug, um Experimente mit dem Klassifikator in der Produktion (mit konservativen Schwellenwerten) zu starten, um Benutzer auf ihre richtlinienwidrige Sprache hinzuweisen. Die Ergebnisse dieser Experimente haben unsere Erwartungen bei weitem übertroffen.

Wie geht es weiter?

Durch den Einsatz unserer eigenen CPU-Infrastruktur und eine sorgfältige Gestaltung der Pipeline für große Datenmengen konnten wir dieses Modell erfolgreich auf Roblox-Größe skalieren. Während der Stoßzeiten verarbeitet das Modell erfolgreich über 2.000 Anfragen pro Sekunde (von denen die Mehrheit keine Verstöße enthält). Wir haben zudem festgestellt, dass das richtlinienwidrige Verhalten auf der Plattform deutlich zurückgegangen ist, seitdem das Modell genutzt wird, um Benutzer über richtlinienwidrige Sprache zu informieren. Seit unserem ersten Roll-out sehen wir einen Rückgang der schwerwiegenden Sprachmissbrauchsmeldungen um 15,3% sowie eine Reduktion der Verstöße pro Sprachminute um 11,4%.

Wir erweitern unsere Modelle mit mehrsprachigen Trainingsdaten, wodurch wir plattformweit ein einziges Klassifikationsmodell einsetzen können, das mehrere Sprachen sowie Mischungen aus Sprachen verarbeiten kann. Wir untersuchen auch neue Multitasking-Architekturen, um bestimmte Schlüsselwörter zusätzlich zum Klassifikationsziel zu identifizieren, ohne auf eine vollständige ASR zurückgreifen zu müssen. Die Erkennung dieser Schlüsselwörter zusätzlich zu den Verstoßlabels verbessert die Qualität der Klassifikation und bietet die Möglichkeit, Benutzern Kontext zu Konsequenzen zu liefern.

Die hier beschriebene Forschungsarbeit war ein gemeinsames Projekt vieler verschiedener Teams bei Roblox. Sie ist ein großartiges Beispiel für unser wichtigstes Prinzip – die Community zu respektieren – und eine beeindruckende Zusammenarbeit über mehrere Fachbereiche hinweg.