MinibatchSize de BrainScript en CNTK

Nota: Para los usuarios de BrainScript, el parámetro para el tamaño de minibatch es minibatchSize, para los usuarios de Python, es minibatch_size_in_samples. Para los usuarios de Python, consulte aquí.

CNTK tiene una definición muy específica del minibatchSize parámetro: indica el número de muestras entre las actualizaciones del modelo. Aquí se define un ejemplo como un vector o tensor que fluye a través del sistema. Por ejemplo, en una tarea de reconocimiento de imágenes, una imagen es un ejemplo.

Tamaño de minibatch para cada época, dado en muestras (tensores a lo largo de un eje dinámico). El valor predeterminado es 256. Puede usar valores diferentes para diferentes épocas, por ejemplo, (en BrainScript) o 128*2 + 1024 (en Python) significa usar el tamaño de minibatch de 128 para las dos primeras épocas y, a continuación, 128*2:1024 1024 para el resto. Tenga en cuenta que "Tamaño de minibatch" en CNTK significa el número de muestras procesadas entre las actualizaciones del modelo. Esta definición también se mantiene al paralelizar entre los trabajos (por ejemplo, para K los trabajadores, el número de muestras que cada trabajo procesaría es minibatchSize/K). En el caso de entradas de longitud variable, minibatchSize hace referencia al número de elementos de estas secuencias, no al número de secuencias. SGD intentará ajustarse a tantas secuencias como sea posible en el minibatch que no supere las minibatchSize muestras totales. Si se proporcionan varias entradas, los tensores se agregan al minibatch actual hasta que una de las entradas supera el minibatchSize.

Importantemente, para los datos secuenciales, un ejemplo es un elemento individual de una secuencia. Por lo tanto, CNTK minibatchSizeno hace referencia al número de secuencias en el minibatch, sino al número agregado de elementos o tokens de secuencia en las secuencias que constituyen el minibatch. CNTK tiene compatibilidad nativa con secuencias de longitud variable, es decir, puede acomodar secuencias de longitudes muy variables dentro del mismo minibatch, sin necesidad de soluciones alternativas como depósitos. Junto con la noción de CNTK de especificar la velocidad de aprendizaje por muestra (en lugar de un promedio de minibatch), cada elemento de secuencias de cualquier longitud contribuye igual al degradado, lo que conduce a una convergencia coherente. (Muchos otros kits de herramientas definen el tamaño de minibatch para los datos secuenciales como el número de secuencias en el minibatch. Esto es problemático, especialmente si los degradados también se definen como promedios de minibatch en lugar de las sumas de minibatch de CNTK, ya que la contribución al degradado de cada token o paso de una secuencia sería inversamente proporcional a la longitud de la secuencia. CNTK enfoque evita esto).

Cuando se usan varios Input{}, es posible que no todas las entradas tengan la misma longitud de secuencia. Por ejemplo, en la clasificación de secuencia, la etiqueta de cada secuencia es un único token. En este caso, la entrada con el mayor número de muestras controla el tamaño del minibatch. (Puede cambiar este comportamiento especificando definesMbSize=True para alguna entrada y, a continuación, el tamaño de minibatch se contará en función de las secuencias de esta entrada determinada. Cuando se especifican varias entradas, solo una única puede haber definesMbSize establecido en True).

A pesar de nuestra clara definición de minibatchSize ser el número de muestras entre las actualizaciones del modelo, hay dos ocasiones en las que debemos relajar la definición:

• datos secuenciales: las secuencias de longitud variable no suelen sumarse exactamente al tamaño de minibatch solicitado. En este caso, tantas secuencias como sea posible se empaquetan en un minibatch sin superar el tamaño de minibatch solicitado (con una excepción: si la siguiente secuencia del corpus aleatorio supera la longitud del tamaño de minibatch, el tamaño del minibatch constará de esta secuencia).
• paralelismo de datos: aquí, el tamaño del minibatch es aproximado, ya que nuestro algoritmo de aleatoriedad basado en fragmentos no puede garantizar que cada trabajador reciba exactamente el mismo número de muestras.

Todas las consideraciones anteriores también se aplican a epochSize, pero epochSize tiene algunas diferencias, consulte aquí.