BrainScript minibatchSize in CNTK

Nota: per gli utenti di BrainScript, il parametro per le dimensioni del minibatch è minibatchSize, per gli utenti Python, è minibatch_size_in_samples. Per gli utenti Python, vedere qui.

CNTK ha una definizione molto specifica del minibatchSize parametro: indica il numero di campioni tra gli aggiornamenti del modello. Un esempio qui è definito come un vettore o un tensore che scorre attraverso il sistema. Ad esempio, in un'attività di riconoscimento delle immagini, un'immagine è un esempio.

Dimensioni del minibatch per ogni periodo, specificate in campioni (tensori lungo un asse dinamico). Il valore predefinito è 256. È possibile usare valori diversi per periodi diversi, ad esempio 128*2:1024 (in BrainScript) o 128*2 + 1024 (in Python) significa usare dimensioni minibatch pari a 128 per i primi due periodi e quindi 1024 per il resto. Si noti che "Dimensioni minibatch" in CNTK indica il numero di campioni elaborati tra gli aggiornamenti del modello. Questa definizione contiene anche quando si esegue la parallelizzazione tra i ruoli di lavoro, ad esempio per K i ruoli di lavoro, il numero di campioni che ogni ruolo di lavoro elabora è minibatchSize/K. In caso di input a lunghezza variabile, minibatchSize fa riferimento al numero di elementi in queste sequenze, non al numero di sequenze. SGD tenterà di adattarsi al maggior numero possibile di sequenze nel minibatch che non supera i minibatchSize campioni totali. Se vengono forniti più input, i tensori vengono aggiunti al minibatch corrente fino a quando uno degli input supera il minibatchSize.

In particolare, per i dati sequenziali, un esempio è un singolo elemento di una sequenza. Di conseguenza, CNTK nonminibatchSize fa riferimento al numero di sequenze nel minibatch, ma al numero aggregato di elementi/token di sequenza tra le sequenze che costituiscono il minibatch. CNTK ha il supporto nativo per le sequenze a lunghezza variabile, ovvero può contenere sequenze di lunghezze altamente variabili all'interno dello stesso minibatch, senza la necessità di soluzioni alternative come il bucketing. Insieme alla nozione di CNTK di specificare la frequenza di apprendimento per campione (invece di una media minibatch), ogni elemento di sequenze di qualsiasi lunghezza contribuisce allo stesso livello della sfumatura, causando una convergenza coerente. Molti altri toolkit definiscono le dimensioni del minibatch per i dati sequenziali come numero di sequenze nel minibatch. Ciò è problematico, soprattutto se le sfumature sono definite anche come medie di minibatch anziché CNTK somme di minibatch, perché il contributo alla sfumatura da ogni token o passaggio in una sequenza sarebbe inversamente proporzionale alla lunghezza della sequenza. CNTK'approccio evita questo problema.

Quando si usano più s Input{}, è possibile che non tutti gli input abbiano la stessa lunghezza di sequenza. Ad esempio, nella classificazione della sequenza l'etichetta di ogni sequenza è un singolo token. In questo caso, l'input con il maggior numero di campioni controlla le dimensioni del minibatch. È possibile modificare questo comportamento specificando definesMbSize=True per un input, quindi le dimensioni del minibatch verranno conteggiate in base alle sequenze di questo particolare input. Quando si specificano più input, è possibile impostare definesMbSizeTruesu .)

Nonostante la nostra chiara definizione di minibatchSize numero di campioni tra gli aggiornamenti del modello, ci sono due occasioni in cui è necessario ridurre la definizione:

• dati sequenziali: le sequenze a lunghezza variabile in genere non sommano esattamente le dimensioni del minibatch richiesto. In questo caso, il maggior numero possibile di sequenze viene compresso in un minibatch senza superare le dimensioni del minibatch richiesto (con un'eccezione: se la sequenza successiva nel corpus casuale supera la lunghezza delle dimensioni del minibatch, le dimensioni del minibatch saranno costituite da questa sequenza).
• parallelismo dei dati: in questo caso, le dimensioni del minibatch sono approssimative, perché l'algoritmo di randomizzazione basato su blocchi non può garantire che ogni ruolo di lavoro riceva esattamente lo stesso numero di campioni.

Tutte le considerazioni precedenti si applicano anche a epochSize, ma epochSize presenta alcune differenze, vedere qui.