Partager via

BrainScript via des règles d’analyse de ligne de commande

  • Article

Ci-dessous, nous décrivons les règles d’analyse de ligne de commande CNTK. CNTK se compose d’un certain nombre de composants pour effectuer une tâche. La plupart de ces composants ont besoin d’informations de configuration disponibles pour fonctionner, et ces paramètres de configuration sont fournis par le biais de fichiers de configuration dans CNTK.

Les fichiers de configuration sont des collections de paires nom-valeur. Les données de configuration peuvent être l’un des types suivants :

  • Simple : une seule valeur est attribuée au paramètre de configuration. Par exemple : deviceId = "Auto".
  • Tableau : un paramètre de configuration est affecté à un tableau de valeurs qui n’ont pas besoin d’être d’un type uniforme. : est le séparateur par défaut pour les tableaux. Le séparateur peut être modifié en englobant les valeurs de tableau entre parenthèses et en plaçant le nouveau caractère de séparateur immédiatement après la parenthèse ouverte. Le * caractère permet de répéter plusieurs fois une valeur particulière dans le tableau. Par exemple, minibatchSize = 256:512:512:512:1024 est égal à minibatchSize = 256:512*3:1024.
  • Jeu : les ensembles de paramètres contiennent des ensembles de paramètres de configuration de n’importe quel type. Les jeux de paramètres peuvent être imbriqués. Le séparateur par défaut pour les jeux de paramètres est ; si plusieurs éléments sont inclus sur une seule ligne. Les séparateurs de lignes servent également de séparateurs pour les éléments. Par exemple :

block1 = [id=1;size=256]

block2 = [
    subblock = [string="hi";num=5]
    value = 1e-10
    array = 10:"this is a test":1.25
]

Dans CNTK, les fichiers de configuration sont organisés de manière hiérarchique. Les valeurs de données réelles ne sont pas évaluées tant qu’un composant CNTK demande la valeur. Lorsqu’une valeur est demandée par un composant, CNTK recherchera d’abord dans le bloc de composant. Si la valeur n’est pas trouvée, elle continue à rechercher dans le paramètre parent et grand-parent défini jusqu’à ce que le paramètre soit trouvé, ou le niveau supérieur de la hiérarchie de configuration est atteint sans correspondance. Cela permet de faciliter le partage des mêmes valeurs de paramètre sur différents blocs. Comme nous l’avons mentionné précédemment, pour exécuter CNTK vous devez spécifier le fichier de configuration dans la ligne de commande, car cntk configFile=yourExp.cntk cela charge le fichier de configuration demandé et exécute tout bloc de commande répertorié dans les paramètres de commande dans le fichier de configuration.

Commandes et actions

Il doit y avoir un paramètre de commande de niveau supérieur, qui définit les commandes (séparées par :) qui seront exécutées dans le fichier de configuration. Chaque commande référence un bloc de commandes dans le fichier, qui doit contenir un paramètre d’action définissant l’opération que le bloc effectuera. Par exemple, la commande suivante exécute le mnistTrain bloc, qui exécute l’action d’apprentissage, suivie du mnistTest bloc, qui évalue le modèle.

command = mnistTrain:mnistTest

mnistTrain = [
    action = "train"
    ...
]

mnistTest = [
    action = "eval"
    ...
]

Surcharges de configuration dans la ligne de commande

Il est courant de disposer d’une configuration qui peut être utilisée comme configuration de base et de modifier seulement quelques paramètres pour chaque exécution expérimentale. Cela peut être effectué de plusieurs manières différentes, l’une d’entre elles consiste à remplacer les paramètres sur la ligne de commande. Par exemple, pour remplacer le chemin du fichier modèle, il est possible de modifier simplement la ligne de commande comme suit :

cntk configFile=yourExp.cntk stderr="c:\temp\newpath"

Cela remplace le paramètre actuel pour stderr, qui est défini au niveau racine du fichier de configuration, avec la nouvelle valeur. Si un paramètre à l’intérieur d’un bloc de commandes doit être modifié, le bloc doit également être spécifié. Par exemple, on peut modifier l’expérience minibatchSize d’une expérience dans la ligne de commande en tant que

cntk configFile=yourExp.cntk mnistTrain=[minibatchSize=256]

ou modifiez le fichier de données utilisé pour une expérience en tant que

cntk configFile=yourExp.cntk mnistTrain=[reader=[file="mynewfile.txt"]]

Fichiers de configuration en couches

Au lieu de remplacer certaines parties d’un fichier de configuration à l’aide de paramètres de ligne de commande, il peut également spécifier plusieurs fichiers de configuration, où les derniers fichiers remplacent les fichiers précédents. Cela permet à un utilisateur d’avoir un fichier de configuration maître, puis de spécifier, dans un fichier de configuration distinct, les paramètres du maître qu’il souhaite remplacer pour une exécution donnée de CNTK. Cela peut être accompli en spécifiant une liste séparée « + » des fichiers de configuration ou en utilisant la configFile= balise plusieurs fois. Les lignes de code suivantes sont équivalentes.

cntk configFile=yourExp1.cntk+yourExp2.cntk

cntk configFile=yourExp1.cntk configFile=yourExp2.cntk

Si yourExp2.cntk seule contient la chaîne mnistTrain=[reader=[file=mynewfile.txt]], les deux commandes sont équivalentes à :

cntk configFile=yourExp1.cntk mnistTrain=[reader=[file="mynewfile.txt"]]

Notez que la valeur d’une variable est toujours déterminée par la dernière fois qu’elle est affectée. Il est également possible de combiner des paramètres de ligne de commande et des fichiers de configuration en couches, dans des combinaisons arbitraires. Par exemple,

cntk configFile=yourExp1.cntk+yourExp2.cntk var1=value configFile=yourExp3.cntk

traiter ces paramètres de configuration dans l’ordre dans lequel ils apparaissent sur la ligne de commande et quelle que soit la valeur affectée en dernier est la valeur utilisée.

En plus de pouvoir spécifier plusieurs fichiers de configuration sur la ligne de commande, un utilisateur peut inclure un fichier de configuration dans un autre. Par exemple, si la première ligne d’a yourExp2.cntk été

include=yourExp1.cntk

puis simplement en cours d’exécution

cntk configFile=yourExp2.cntk

serait équivalent à l’exécution

cntk configFile=yourExp1.cntk+yourExp2.cntk

où dans ce dernier cas, yourExp2.cntk ne contient pas l’instruction include. Notez que ces instructions incluent peuvent apparaître n’importe où à l’intérieur d’un fichier de configuration ; où l’instruction include s’affiche, c’est-à-dire où le fichier de configuration spécifié sera inclus. L’inclusion d’un fichier de configuration équivaut à coller le contenu de ce fichier à l’emplacement de l’instruction include. Les instructions Include sont résolues de manière récursive (à l’aide d’une recherche en profondeur), ce qui signifie que si yourExpA.cntk elle inclut yourExpB.cntk, et yourExpB.cntk inclut yourExpC.cntk, la chaîne complète sera résolue et yourExpC.cntk sera effectivement incluse dans yourExpA.cntk. Si un fichier de configuration est inclus plusieurs fois (par exemple, « A » inclut « B » et « C » et « B » inclut également « C »), il ne sera effectivement inclus que la première fois qu’il est rencontré.

Stringize Variables

Bien que les fichiers de configuration en couches permettent aux utilisateurs de réutiliser les fichiers de configuration entre les expériences, cela peut toujours être un processus fastidieux. Pour chaque expérience, un utilisateur peut avoir à remplacer plusieurs paramètres, dont certains peuvent être de longs chemins de fichier (par exemple, stderr, , modelPathfile). La fonctionnalité « stringize » peut rendre ce processus beaucoup plus facile. Il permet à un utilisateur de spécifier la configuration comme suit :

command = SpeechTrain
stderr = "$Root$\$RunName$.log"
speechTrain = [
    modelPath = "$Root$\$RunName$.cn"
    SGD = [
        reader = [
            features = [
                type = "real"
                dim = "$DataSet1_Dim$"
                file = "$DataSet1_Features$"
            ]
        ]
    ]
]

Ici, ,RootRunName, DataSet1_Dimet DataSet1_Features sont des variables spécifiées ailleurs dans la configuration (à une étendue visible à partir du point où elles sont utilisées). Lors de l’interprétation de ce fichier de configuration, l’analyseur remplace chaque chaîne du formulaire $VarName$ par la chaîne VarValue, où VarValue représente la valeur de la variable appelée VarName. Le processus de résolution des variables est récursif ; par exemple, si A=$B$, B=$C$et C=HelloWorld.txt, A sera résolu comme « HelloWorld.txt ». Assurez-vous qu’il n’existe aucune boucle de référence dans votre fichier de configuration. Sinon, l’analyseur va entrer dans une boucle infinie à ce moment-là.

Notez que, étant donné qu’il est équivalent pour un utilisateur de spécifier la valeur d’une variable dans un fichier de configuration par rapport à la ligne de commande, les valeurs de ces variables peuvent être spécifiées à l’un ou l’autre emplacement. Rappelez-vous que la valeur d’une variable est déterminée par la dernière fois qu’elle est affectée, que ce soit dans un fichier de configuration ou sur la ligne de commande. Par conséquent, si Root elle est définie dans config1.txt, mais remplacée à la ligne de commande, la valeur spécifiée dans la ligne de commande serait celle utilisée pour résoudre les instances de $Root$ configFile1.txt. Une fonctionnalité utile est que si stderr ou modelPath pointez vers des répertoires qui n’existent pas, ces répertoires seront créés par CNTK; cela vous permet de spécifier quelque chose comme stderr = $Root$\$RunName$\$RunName$.log, même si le répertoire $Root$\$RunName$ n’existe pas.

Valeurs par défaut, valeurs répétées et commentaires

La plupart des paramètres des fichiers de configuration ont une valeur par défaut qui sera utilisée si aucune valeur de configuration n’est spécifiée. S’il n’existe aucune valeur par défaut et que la valeur ne se trouve pas dans une recherche, une exception s’affiche et le programme se termine. Si un nom de paramètre est spécifié plusieurs fois, la dernière valeur définie sur cette valeur est celle qui sera conservée. La seule exception à ceci est dans les jeux de paramètres, qui sont entourés d’accolades [ carrées ], dans ces cas les valeurs à l’intérieur des accolades sont considérées comme un jeu de paramètres et seront ajoutées au jeu de paramètres actuellement existant. Par exemple :

params=[a=1;b=2;c=3]
params=[c=5;d=6;e=7]

est effectivement égal à :

params=[a=1;b=2;c=5;d=6;e=7]

Notez que ce traitement d’ajout n’est pas utilisé pour les éléments de tableau et que l’ensemble du tableau est remplacé s’il est défini plusieurs fois. Le # caractère signifie le début d’un commentaire, tout ce qui se produit après l’ignorer # . L’espace # doit être précédé de l’espace blanc ou être au début de la ligne à interpréter comme un commentaire. Voici un commentaire valide

stderr="c:\cntk\log\cntk" # "_mnistTrain_mnistTest.log"

Voici un exemple de valeur qui ne sera pas interprétée comme un commentaire. Il définit un paramètre var à l’infini comme l’in #1#INF n’est pas un marqueur de commentaire

var=1#INF