A las sondas de activaciones de Gemma-3-27B les bastan 80 diálogos sintéticos, pero no en todos los casos

¿Cuántos diálogos sintéticos hacen falta para entrenar una sonda que vigile el comportamiento de un modelo de lenguaje en producción? Los autores de un reciente trabajo en arXiv cs.LG lo han medido de forma directa y han obtenido una respuesta que depende de lo que rastree exactamente la sonda. En Gemma-3-27B-IT, las sondas para «situaciones de alto riesgo» y para respuestas dañinas para las personas quedan a pocas centésimas de su meseta con solo 80 ejemplos. Las sondas que detectan el incumplimiento de la instrucción del usuario requieren varias veces más.

Cómo se planteó el experimento

Una sonda de activaciones es un pequeño clasificador que se coloca sobre las representaciones internas del modelo. Suele entrenarse con conversaciones generadas por otra LLM y, hasta ahora, el presupuesto de esa generación se fijaba a ojo. Los investigadores construyeron curvas de aprendizaje con entre 10 y 590 muestras sintéticas para tres conceptos: alto riesgo, respuesta dañina para una persona y respuesta que no sigue la instrucción. Midieron la calidad en 14 distribuciones reservadas para evaluación. Por separado, variaron el modelo generador y el grado de detalle del prompt.

Parámetros clave del trabajo:

• tres conceptos de monitorización: high-stakes, harmful, instruction;
• cuatro modelos de sonda, de los cuales el principal es Gemma-3-27B-IT;
• 14 distribuciones de evaluación reservadas;
• de 10 a 590 muestras sintéticas por curva;
• el orden de los conceptos según su «apetito» de datos se mantiene en tres modelos más pequeños y en muestras reales del conjunto dev.

Cobertura en lugar de dificultad

Para comparar las curvas, los autores introdujeron una magnitud llamada half-gain size: el número de muestras con el que se logra la mitad de la mejora final de calidad. El concepto y la distribución explican juntos entre el 42 % y el 45 % de su varianza. El generador, el modelo de la sonda y el nivel de detalle del prompt aportan, todos juntos, menos del 10 %. Según estos datos, elegir un modelo generador más caro o un prompt más detallado influye mucho menos en la necesidad de datos que el propio objeto de la monitorización.

Los autores descartan la explicación intuitiva de que algunos conceptos son simplemente más difíciles. Si se toma cada «tipo» de datos por separado (uno por cada distribución de evaluación), el half-gain size mediano es de entre 7 y 11 muestras sintéticas propias, y es igual para los tres conceptos. La dificultad dentro de un mismo tipo es comparable en todos los casos.

Lo que cambia es otra cosa: cuánto ayudan las muestras de un tipo en el resto de tipos del mismo concepto. En high-stakes se transfieren casi por completo, en harmful peor y en instruction menos que en ninguno. Los autores atribuyen a este desequilibrio la mayor parte de la brecha entre conceptos, tanto en datos generados como en datos reales.

De ahí se desprende una conclusión sobre el debate entre amplitud y profundidad. La recomendación habitual de gastar el presupuesto de generación en diversificar los tipos de datos, y no en el volumen de cada tipo, solo es válida en parte. Para instruction hacen falta muchos tipos, porque ninguno cubre a otro. Para high-stakes son casi redundantes, porque un tipo cubre a los demás.

Qué hacer con el presupuesto de generación

Para un equipo que construye monitorización de despliegues, conviene empezar comprobando la transferencia entre tipos de datos, y no eligiendo generador. Si el concepto se parece a high-stakes, bastan unas pocas decenas de ejemplos bien seleccionados y el gasto adicional aporta poco. Si se parece a instruction, hay que incluir desde el principio diversidad de tipos y contar el volumen en cientos. Un modelo generador caro y un prompt ultradetallado ahorrarán menos de lo que parece: su aportación a la varianza de la necesidad de datos es inferior al 10 %.

Advertencia: todas las conclusiones se han obtenido con tres conceptos y cuatro sondas. Para otros conceptos habrá que volver a medir la necesidad de datos, y la comprobación de la transferencia entre tipos parece una herramienta útil para ello. Los autores han publicado los conjuntos de evaluación, los conjuntos dev y los datos generados, de modo que las curvas pueden reproducirse en el propio stack sin necesidad de etiquetado propio.