Desplegando aprendizaje automático para seguridad de voz

Nuestra misión es conectar a mil millones de personas con optimismo y civismo, lo cual requerirá que ayudemos a que las personas se sientan en verdad unidas entre sí. Para los mundos inmersivos en 3D, al igual que en el mundo físico, hay pocas cosas más auténticas o poderosas que la voz humana para crear amistades y conexiones duraderas. ¿Pero cómo escalamos la inmersión y riqueza de la comunicación por voz en Roblox a la vez que mantenemos nuestra comunidad segura y tranquila?

En este blog, compartiremos cómo le dimos vida la seguridad en tiempo real, un modelo de aprendizaje automático integral para máquinas, el cual opera a una escala de millones de minutos de actividad de voz por día, que detecta violaciones a la política en comunicación de voz de forma más precisa que la moderación humana. Los resultados de este sistema se agregan a otro modelo que determina las consecuencias apropiadas. El modelo de consecuencia activa notificaciones para las personas que violaron nuestras políticas, inicialmente con advertencias, y luego con acciones más drásticas si el comportamiento persiste.

Este sistema de seguridad en tiempo real fue un objetivo audaz, ya que somos unos de los primeros en la industria en proporcionar medidas de seguridad para voz multilingüe a los usuarios casi en tiempo real. La clasificación de voz depende del estilo de audio, incluyendo volumen y tono, y contenido, incluyendo las palabras habladas. Nos emociona compartir cómo desarrollamos este sistema básicamente sin datos de automatización previa, casi sin datos etiquetados y sin modelos; yendo de cero a 60 para lograr seguridad de voz en tiempo real.

Y finalmente, nos emociona compartir nuestro primer modelo de código abierto, el cual es uno de nuestros modelos de seguridad de voz. Al permitir el acceso al código de este modelo y al ponerlo a disposición para uso comercial, esperamos proporcionar una base a la industria para detección de violación de políticas que pueda acelerar el desarrollo de nuevos modelos de aprendizaje automático para seguridad de voz. Este modelo de código abierto es nuestra primera versión y, desde entonces, logramos mejoras significativas que actualmente estamos probando.

Superando la falta de datos

Comenzamos nuestros esfuerzos de aprendizaje automático como lo hacen tantas compañías: evaluando la calidad de datos disponibles para capacitar y evaluar nuestros modelos. El set de datos ideal incluiría expresiones de voz junto con una categorización de seguridad con etiquetas de alta calidad para esas expresiones. Sin embargo, cuando comenzamos, casi no teníamos datos reales a gran escala con etiquetado por humanos. Para entrenar un modelo de detección de seguridad de voz de alta calidad con un enfoque supervisado, necesitábamos miles de horas de audio de datos etiquetados para cada idioma con el que somos compatibles, el cual habría tomado años reunir y habría requerido una cantidad de recursos y tiempo prohibitivo.

En lugar de depender de miles de horas de datos etiquetados a mano, desarrollamos varios métodos más eficientes:

• Datos etiquetados a máquina para entrenamiento. En lugar de atorarnos buscando la perfección de datos etiquetados a mano para entrenamiento, optamos por un gran volumen de datos de expresiones de voz con etiquetado por máquina para entrenamiento. Con grandes cantidades de datos etiquetados por máquina con poca supervisión, se generaron modelos de entrenamiento que eran resistentes a algo de ruido en las etiquetas. La clave para que este método funcionara fue acceder a grandes librerías de voz a texto de código abierto y a años de experiencia en aprendizaje automático para detectar violaciones a las Normas de la comunidad en las comunicaciones textuales de las personas. Este proceso de etiquetado por máquina nos permitió etiquetar el volumen de datos de entrenamiento que necesitábamos para nuestros modelos en semanas, en lugar de años.

• Datos etiquetados por humanos para evaluación. Aunque los datos etiquetados por máquina, de alta calidad pero imperfectos, eran suficientes para entrenar un modelo de alto rendimiento, no confiamos en las etiquetas por máquina para realizar la validación final del modelo resultante. La siguiente pregunta, entonces, era dónde podríamos obtener suficientes datos etiquetados por humanos para su evaluación. Por suerte, aunque era imposible juntar suficientes datos etiquetados por humanos para el entrenamiento a tiempo, era posible juntar suficientes datos para evaluar nuestro modelo, al usar nuestros moderadores internos, quienes ya estaban clasificando reportes de abuso de personas en Roblox para emitir consecuencias de forma manual. Esto nos permitió disfrutar lo mejor de ambos mundos: datos para entrenamiento etiquetados por máquina que eran suficientemente vastos y buenos para producir un modelo de alto rendimiento, y datos de evaluación etiquetados por humanos de menor volumen pero suficientes para darnos la confianza de que el modelo en verdad funcionaba.

Otra área en la que nos enfrentamos a la escasez de datos fue en las categorías de violación de políticas donde tenemos muy poco predominio, como referencias a drogas, alcohol o autolesión. Para abordar este problema, combinamos varias categorías de bajo predominio en una categoría: "otros". Como resultado, nuestro modelo eventual podía identificar las categorías de profanidad, acoso, discriminación, citas y \"otros\". Para poder entender estas categorías de \"otros\", con el fin de proteger mejor a nuestra comunidad y asegurar un discurso seguro y civil en Roblox, seguiremos monitoreando estas para buscar más ejemplos. Con el tiempo, las subcategorías en "otros" también se volverán categorías nombradas a medida que el número de ejemplos de entrenamiento en esas subcategorías alcance una masa crítica.

Proceso de etiquetado automático para datos de entrenamiento

Diseñamos un proceso de etiquetado por máquina totalmente automática para extraer etiquetas de gran calidad a partir de secuencias de chat con voz. Nuestro proceso consiste de tres etapas:

1. Separación de fragmentos de audio. La primera etapa del proceso involucra separar el audio en fragmentos, o segmentos más cortos, donde sea que detectemos periodos de silencio entre oraciones. Esto nos permite identificar y etiquetar contenido que viole las políticas de forma más eficiente.

2. Transcripción de audio. La segunda etapa del proceso consiste en transcribir estos fragmentos de audio a texto con un modelo de reconocimiento automático de voz (ASR, por sus siglas en inglés). Usamos modelos ASR de código abierto disponibles al público.

3. Clasificación de texto. La etapa final del proceso involucra clasificar el texto trascrito con nuestro filtro de texto interno. Este filtro está diseñado para detectar y bloquear contenido inapropiado en comunicaciones de texto. Adaptamos el filtro para trabajar con los datos de audio transcritos, lo que nos permitió etiquetar los fragmentos de audio con las clases y palabras clave que violen la política. El filtro del texto es un modelo de conjunto entrenado con datos de texto de violaciones de políticas etiquetados por humanos, que comprenden un modelo DistilBERT extendido y reglas de expresiones normales.

Es importante resaltar que este proceso se usó solo para generar datos de entrenamiento para nuestro modelo de producción final. Sin embargo, tal vez te preguntes: ¿por qué entrenar un modelo, si ya hay un proceso que genera las etiquetas que buscamos? La respuesta es eficiencia. Necesitamos ser increíblemente precisos, en mucho menos tiempo. A escala Roblox, invocar el ASR para transcribir todas las comunicaciones de voz habría requerido una cantidad prohibitiva de recursos y tiempo. Sin embargo, un modelo compacto de aprendizaje automático entrenado a partir de estos datos, diseñado específicamente para detectar violaciones de políticas en comunicaciones de voz sin hacer una transcripción completa, es igual de preciso, pero significativamente más rápido y se puede usar a escala de Roblox.

Escalando el proceso de etiquetado por máquina

Con la mayoría de las grandes iniciativas de IA, el mecanismo para obtener datos de entrenamiento de calidad es en sí un sistema de aprendizaje automático, el cual necesita crearse desde cero. Para este proyecto, necesitábamos desarrollar nuestra línea de etiquetado por máquina como un sistema de producción de primera clase, activo 24/7 y con la habilidad para escalar a miles de CPU simultáneos, o números equivalentes de GPU. Implementamos un conjunto de datos de entrenamiento con miles de núcleos de CPU que procesan automáticamente los flujos de audio entrantes en paralelo para generar etiquetas por máquina. Este sistema tenía que funcionar a la perfección para obtener el máximo rendimiento, y cualquier error o tiempo de inactividad suponía la pérdida de días o semanas en la generación de datos de entrenamiento.

A continuación, presentamos un resumen general de la arquitectura que apoyaba la escala necesaria para etiquetar por máquina decenas de miles de horas de audio en tan solo algunas semanas. Lo más importante es que invertir en colas en puntos clave en nuestro proceso nos permitió eliminar cuellos de botella al escalar horizontalmente los subprocesos de los trabajadores en muchas máquinas. Estos subprocesos de trabajo realizaron los pasos de separación de fragmentos de audio, transcripción de audio y clasificación de texto mencionados en la sección anterior.

Arquitectura de aprendizaje automático

Un requisito central para nuestro modelo era la baja latencia, es decir, velocidades cercanas al tiempo real para inferencia de modelo, lo que nos llevó a arquitecturas que operan directamente en audio sin procesar y devuelven un puntaje. Usamos arquitecturas basadas en Transformadores, las cuales funcionan muy bien para el resumen de secuencias y tienen mucho éxito en la industria para procesamiento de lenguaje natural (NLP, por sus siglas en inglés) y el modelado de audio. Nuestro desafío fue encontrar un buen punto de balance entre la complejidad y la inferencia de latencia baja; es decir, manejar múltiples idiomas y acentos, robustez ante el ruido de fondo y la calidad de audio, mientras se satisfacen nuestras restricciones de latencia de producto.

Selección de modelo

Una pregunta de diseño inmediata fue determinar el tamaño de la ventana de contexto necesaria para entrenar los modelos de Transformador. Revisamos el histograma de longitud de habla en los datos de chat con voz a lo largo de varios días de uso, y se determinó que una ventana de 15 segundos proporcionaba el balance entre latencia y el contexto suficiente necesario para clasificación. Usamos "no violación" como una categoría para detectar la ausencia de violaciones de política. Dado que un solo clip de audio puede contener múltiples tipos de violaciones, la tarea inherentemente se convierte en un etiquetado múltiple, más que un problema de clasificación multiclase convencional. Ajustamos toda la red, incluyendo las capas principales para esta tarea, con pérdida de entropía cruzada binaria (BCE). 

Leyenda: Histograma de habla de datos de chat que muestra que 75 % del habla dura menos de 15 segundos.

Evaluamos muchos modelos de populares de codificadores de código abierto de la comunidad de investigación de audio y acotamos nuestras opciones a WavLM y Whisper. Nuestro primer experimento fue ajustar la WavLM base+ preentrenada con 2300 horas de datos de voz de Roblox etiquetadas por máquina y evaluar los resultados de clasificación en dos conjuntos de datos de evaluación del mundo real. Obtuvimos muy buenos resultados de clasificación (ver Evaluación de modelo, a continuación), pero descubrimos que la latencia superaba nuestros umbrales para la implementación en producción. Como seguimiento, implementamos una versión personalizada de la arquitectura de WavLM con menos capas de Transformador y entrenamos un modelo completo desde cero en 7000 horas de datos de voz de Roblox etiquetados por máquina. Este modelo produce clasificaciones robustas en contextos de conversación y era más compacto en comparación con el modelo ajustado. Nuestro candidato de modelo final usó un ajuste de destilación estudiante-maestro, con un codificador Whisper como red maestra y la arquitectura final WavLM como la red de estudiante. Cuando la entrenamos en 4000 horas de audio, observamos precisiones de clasificación similares al modelo ajustado, pero con una mejora sustancial en latencia y reducción en el tamaño de modelo. La imagen a continuación resume los parámetros del modelo para los tres experimentos descritos arriba. Seguimos repitiendo las estrategias de muestreo de datos, las estrategias de evaluación y los hiperparámetros de modelos a medida que extendemos los modelos para clasificación segura de voces multilingües.

Optimización de modelo 

Empleamos métodos estándar de la industria, incluida la cuantización de determinadas capas de Transformador, para lograr una aceleración superior al 25 % sin comprometer la calidad. Cambiar de la etapa de extracción de características a entradas MFCC combinadas con redes neuronales convolucionales (CNN) en lugar de sólo CNN también se tradujo en una aceleración superior al 40 % durante la inferencia. Además, introducir un modelo de detección de actividad de voz (VAD) como preproceso aumentó significativamente la robustez de la línea general, especialmente para usuarios con micrófonos ruidosos. VAD nos permitió filtrar ruido y aplicar nuestro proceso de seguridad solo cuando detectamos habla humana en el audio, lo cual redujo el volumen general de inferencia en aproximadamente 10 % y proporcionó entradas de mayor calidad a nuestro sistema. 

Evaluación de modelo

Aunque usamos muchos conjuntos de datos y métricas para evaluación diferentes, podemos compartir cómo nuestro clasificador de voz se comportó en un conjunto de datos en inglés con gran prevalencia de violación a las políticas (como encontraríamos en los reportes de abuso de voz de usuarios). Este conjunto de datos fue 100 % etiquetado al por humanos, nuestros moderadores. Cuando combinamos todos los tipos de violación (profanidad, acoso, citas, etc.) en una sola categoría binaria, encontramos un puntaje PR-AUC (área bajo la curva de precisión-recuperación) de más de 0.95, como se muestra a continuación. Esto significa que en este conjunto de datos de evaluación, usualmente el clasificador puede captar una gran mayoría de violaciones sin resaltar demasiados falsos positivos.

Sin embargo, los buenos resultados de la evaluación anterior no necesariamente se traducen a todos los casos de uso. Por ejemplo, en el caso de nuestras notificaciones sobre violaciones a la política en el habla, el clasificador evalúa todos los chats con voz de Roblox y encuentra una menor prevalencia de violaciones, y hay una mayor probabilidad de falsos positivos. En el caso de reportes de abuso, el clasificador solo evalúa el habla que se resaltó para violaciones potenciales, así que la prevalencia es mayor. Aun así, los resultados anteriores fueron lo suficientemente buenos para que iniciáramos experimentos con el clasificador en producción (a umbrales conservadores) para notificar a los usuarios sobre el lenguaje que viola la política. Los resultados de estos experimentos exceden por mucho nuestras expectativas.

¿Qué sigue?

Al aprovechar nuestra propia infraestructura de CPU y diseñar cuidadosamente el proceso para gran escala, pudimos desplegar con éxito este modelo a escala de Roblox. Durante las horas pico, el modelo atiende con éxito más de 2000 solicitudes por segundo (la mayoría de las cuales no contienen violaciones). También observamos una reducción significativa de los comportamientos que violan las políticas en la plataforma debido al uso del modelo para notificar a la gente sobre el lenguaje que viola la política. En específico, desde nuestra implementación inicial, observamos una reducción del 15.3 % en los reportes de voz por abusos severos y una disminución del 11.4 % en las infracciones de voz por minuto.

Estamos ampliando nuestros modelos con datos de entrenamiento multilingües, lo que nos permite desplegar un único modelo de clasificación en toda la plataforma para manejar varios idiomas, y la mezcla de idiomas. También exploramos nuevas arquitecturas de multitareas para identificar palabras clave además del objetivo de clasificación sin recurrir a ASR completo. La detección de estas palabras clave además de las etiquetas de violación mejoran la calidad de la clasificación y proporcionan una oportunidad para darle contexto a las personas mientras emitimos consecuencias.

La investigación descrita aquí fue un esfuerzo conjunto entre muchos equipos en Roblox. Esta fue una gran muestra del respeto a la comunidad que forma nuestro valor central, así como una gran colaboración entre múltiples disciplinas.