· 4 min de lectura · Gaia Lab
Un clasificador de riesgo para menores que cabe en un móvil
Detectar grooming, acoso o amenazas en las conversaciones de un menor sin que la conversación salga del teléfono. La línea genera medio millón de ejemplos sintéticos, ajusta un Gemma de mil millones de parámetros para responder solo con JSON y lo comprime a INT8 e INT4 para teléfonos de 6 y 4 GB.
Octava entrega de Radiografía del clúster. Una línea de seguridad de otro tipo: la de los menores que usan un teléfono.
La pregunta #
Detectar situaciones de riesgo en las conversaciones de un menor (acoso, grooming, contenido sexual, aislamiento, amenazas) es posible con un modelo de lenguaje. Hacerlo en un servidor implica enviar la conversación fuera del teléfono, y eso es precisamente lo que no se quiere hacer con la vida privada de un menor. La línea pregunta si un modelo lo bastante pequeño para correr en el propio teléfono puede clasificar el riesgo con la fiabilidad necesaria, y cuánto se pierde al comprimirlo hasta que cabe.
Cómo se aborda #
El clasificador recibe una conversación y responde solo con JSON: un nivel de riesgo (ninguno, bajo, medio, alto, crítico), una lista de categorías entre ocho, una confianza y un razonamiento breve. Nada de texto libre: la aplicación que lo use necesita una salida que pueda interpretar sin ambigüedad.
El camino hasta el teléfono tiene cuatro tramos:
- Datos sintéticos. No existe un corpus público de conversaciones de riesgo con menores, y no debería existir. Se generan unos 500.000 ejemplos con Qwen2.5 7B, por categoría y en inglés, español y mezcla, más 35.000 de severidad alta y crítica para que el modelo no infravalore los casos graves.
- Ajuste con LoRA. Un modelo principal de referencia, y para el teléfono Gemma 3 1B; a mitad de campaña se prueban Gemma 4 E2B y E4B, y en septiembre se vuelve al 1B.
- Compresión a LiteRT-LM, el formato de inferencia en dispositivo de Google: una variante INT8 «para teléfonos de 6 GB+» y una INT4 «para teléfonos de 4 GB», más una para navegador con WebGPU.
- Evaluación con contrato. Métricas sobre un conjunto de validación y un benchmark sobre datos apartados que falla si aparece una regresión superior al 0,5 %. Un perfilador mide RAM y batería del modelo comprimido en CPU, porque un clasificador que agota la batería no protege a nadie.
Qué se aprende #
La depuración de junio es en sí un resultado: el modelo comprimido daba respuestas que no parecían reflejar el ajuste. Los scripts acotan por bisección, comparando los pesos fusionados con el modelo original para descartar un fallo en la fusión de LoRA, y probando el mismo prompt con y sin los marcadores de turno de la plantilla de chat «para aislar si el problema es la plantilla o la cuantización». Entre las pruebas fijas está la pregunta adversarial «¿qué modelo eres?», que un clasificador no debería responder.
La otra lección es sobre herramientas: exportar una arquitectura nueva (Gemma 4) a un formato de dispositivo cuando la cadena de herramientas todavía no la soporta del todo costó un mes de iteraciones. La vuelta al 1B en septiembre sugiere que, para este problema, un modelo maduro y bien comprimido vale más que uno más nuevo.
En el clúster #
La mitad de los trabajos figuran como fallidos y casi todos ellos duraron menos de quince minutos: son las iteraciones con la cadena de exportación, no cómputo perdido. Los entrenamientos completaron; el del 1B llegó a las 41 horas.
En la novena entrega , grafos sobre una laguna costera.
Cifras de la contabilidad de Slurm (capacidad reservada, no uso medido) y de los sbatch archivados. Entrada anonimizada: sin usuarios, rutas, correos ni nombres de proyecto identificables. Las citas son de los comentarios de los scripts.