Format de fichier .lu

S’APPLIQUE À : SDK v4

Un fichier .lu décrit un modèle de compréhension du langage. Un fichier .lu contient des définitions basées sur le texte simples et semblables à du Markdown pour les concepts de compréhension du langage. Vous pouvez utiliser un ou plusieurs fichiers .lu pour entraîner un modèle de langage pour le service ou le moteur NLU (compréhension du langage naturel) utilisé par votre bot, tel que Compréhension du langage (LUIS) ou Orchestrator. Le moteur NLU que vous choisissez peut uniquement être en mesure d’interpréter le sous-ensemble des éléments qu’un fichier .lu peut décrire.

Un moteur NLU s’appuie sur un modèle de langage pour comprendre ce qu’indique un utilisateur. Le moteur crée un modèle de langage à partir d’ensembles d’exemples d’apprentissage, comme n’importe quel algorithme d’apprentissage automatique. Une fois formé, le moteur utilise le modèle pour prévoir l’intention d’un énoncé, généralement sous la forme d’une ou plusieurs intentions qui représentent une tâche ou une action que l’utilisateur souhaite effectuer et zéro ou plusieurs entités qui représentent des éléments pertinents pour l’intention.

Vous pouvez utiliser LUIS ou Orchestrator avec n’importe quel bot développé à l’aide du kit de développement logiciel (SDK) Bot Framework ou Composer.

Cet article est une référence pour représenter des éléments de modèle de langage au format de fichier .lu. Pour plus d’informations sur l’utilisation de la compréhension du langage dans les bots, consultez Compréhension du langage ou Traitement du langage naturel dans Composer.

Définition d’intentions à l’aide d’exemples d’énoncés

Une intention représente une tâche ou une action que l'utilisateur veut effectuer telle qu’énoncée par l’utilisateur. Vous ajoutez des intentions à votre bot pour lui permettre d’identifier des groupes de questions ou de commandes qui représentent la même intention de l’utilisateur.

Voici quelques exemples d’intentions que vous pouvez définir pour un bot de voyage, avec les exemples d’énoncés dont ils sont définis :

Intentionnel	Exemples d’énoncés
RéserverVol	« Réserve-moi un vol pour Maui la semaine prochaine » « Emmène-moi à Maui le 17 » « J’ai besoin d’un billet d’avion vendredi prochain pour Maui »
Salutations	« Salut » « Hello » « Bonjour »
BulletinMétéo	« Quel temps fait-il à Maui la semaine prochaine ? »
Aucun	« J’aime les cookies » « Des grenouilles-taureaux peuvent effectuer des sauts d’une longueur de 2 mètres »

Outre les intentions que vous définissez, Aucun est une intention de secours qui provoque le déclenchement de l’événement unknownIntent lorsqu’aucune intention ne peut être déterminée à partir de l’énoncé des utilisateurs. Lorsque vous utilisez LUIS, l’intention Aucun est une intention requise que vous devez créer avec des énoncés qui se trouvent en dehors de votre domaine. Les énoncés associés à votre intention Aucun doivent comporter environ 10 % des énoncés totaux dans votre fichier .lu.

Les intentions avec leurs exemples d’énoncés sont déclarées de la manière suivante :

# <intent-name>
    - <utterance1>
    - <utterance2>

# <intent-name> décrit une nouvelle section de définition d’intention. Chaque ligne située après la définition de l’intention est un exemple d’énoncé décrivant cette intention à l’aide du format - <utterance>.

Voici un exemple de fichier .lu illustrant ces intentions et exemples d’énoncés qui capturent les façons dont les utilisateurs peuvent exprimer l’intention :

> Use ">" to create a comment in your .lu files.
> Use multiple comment ">" characters to define outlining
> sections in the file to help you organize the content.

>> Primary intents
# BookFlight
- Book me a flight to Maui next week
- Fly me to Maui on the 17th
- I need a plane ticket next Friday to Maui

# Greeting
- Hi
- Hello
- Good afternoon

>> Secondary intents
# CheckWeather
- What's the weather like in Maui next week?

Pour plus d’informations sur les intentions et les énoncés, consultez Intentions dans votre application LUIS et Comprendre les bons énoncés pour votre application LUIS dans la documentation LUIS.

Entités

Une entité fait partie d’un énoncé qui peut être considéré comme un paramètre pouvant être utilisé dans l’interprétation d’une intention. Par exemple, dans l’énoncé Réserve-moi un billet d’avion pour Maui, Maui est une entité DestinationVol.

Exemple d’énoncé d’un utilisateur	Intention prédite	Entités extraites	Explication
Bonjour, comment ça va ?	Greeting	-	Aucune entité à extraire.
« Réserver un vol pour Maui »	RéserverVol	« Maui »	L’entité « DestinationVol » est extraite en tant que « Maui ».
« Quel temps fait-il à Maui la semaine prochaine ? »	BulletinMétéo	« Maui », « semaine prochaine »	L’entité « LocalisationMétéo » est extraite en tant qu’entité « Maui » et « Date » est extraite en tant que « semaine prochaine ».
« Je veux commander une petite pizza »	CommanderPizza	« petite »	L’entité « taille » est extraite avec la valeur « petite ».
« Planifier une réunion à 13 h avec Bob de la distribution »	PlanifierRéunion	« 13 h », « Bob »	L’entité « HeureRéunion » est extraite en tant qu’entité « 13 h » et « Participants », en tant que « Bob ».

Définitions d’entités

Une définition d’entité définit comment reconnaître une étendue dans un énoncé en tant qu’entité que vous pouvez ensuite utiliser dans votre bot. Il existe de nombreux types d’entités différents, notamment : apprentissage automatique, prédéfini, listes, expressions régulières et modèles.

Les définitions d’entité dans les fichiers .lu démarrent l’entrée avec le signe (@) suivi du type d’entité et de nom d’entité :

@ <entity-type> <entity-name>

Si vous le souhaitez, chaque entité peut également avoir des rôles qui identifient différentes utilisations de la même entité. Vous pouvez également ajouter des fonctionnalités pour améliorer la reconnaissance des entités. La syntaxe générale se présente comme suit :

@ <entity-type> <entity-name> [[hasRole[s]] <comma-separated-list-of-roles>] [hasFeature[s] <comma-separated-list-of-features>]

Les entités qui nécessitent une définition, comme les entités de liste et d’expressions régulières, sont représentées à l’aide de la notation suivante :

@ <entity-type> <entity1-name> = <definition>

Des exemples supplémentaires de déclarations d’entité sont présentés dans les sections suivantes, ainsi que les types d’entités auxquels ils s’appliquent.

À l’exception des entités prédéfinies, les noms d’entités peuvent contenir plusieurs mots avec des espaces. Tous les noms d’entités contenant des espaces peuvent être entourés de guillemets :

@ ml "this is a simple entity" role1, role2 = definition
@ ml 'another simple entity' hasRole role1 hasFeatures feature1, feature2

Types d’entités

Il existe plusieurs types d’entités dans LUIS. Dans les sections suivantes, vous allez découvrir ces types d’entités et des concepts connexes, tels que les rôles et caractéristiques, ainsi que des exemples de création de modèles de LU qui les utilisent.

Entité issue de l’apprentissage automatique

Les entités issues de l’apprentissage automatique sont des entités qui vous permettent de fournir des exemples où vous les étiquetez dans les exemples d’énoncés. Cela leur donne le contexte nécessaire duquel apprendre. L’entité issue de l’apprentissage automatique est idéale lors de l’identification des données qui ne sont pas toujours bien mises en forme, mais qui ont la même signification.

L’exemple suivant illustre une entité issue de l’apprentissage automatique nommée « city » (@ ml city) et une intention bookFlight avec des exemples d’énoncés avec vos entités étiquetées :

> Define the city machine-learned entity
@ ml city

> Define the bookFlight intent with sample utterances that contain the machine-learned entities
# bookFlight
- Book a flight from {@city = Cairo} to {@city = Seattle}
- Get me 2 tickets for a flight to {@city = Bengaluru}
- Purchase ticket from {@city = Washington} to {@city = Tampa Bay}

Lorsqu’un utilisateur dit quelque chose comme « J’ai besoin de réserver un vol Londres-Madrid », LUIS détecte l’intention « bookFlight » et extrait à la fois Londres et Madrid en tant qu’entités « city».

Les rôles sont essentiellement une couche supplémentaire d’informations contextuelles que vous pouvez ajouter à vos entités issues de l’apprentissage automatique, qui apprennent également du contexte. L’exemple d’énoncé suivant montre les rôles de départ et de destination associés à l’entité « city » :

- Book a flight from {@city:departure = Cairo} to {@city:destination = Seattle}

Les entités issues de l’apprentissage automatique peuvent également être complexes lorsqu’elles ont une hiérarchie d’entités liées les unes aux autres. Par exemple, vous pouvez avoir quelque chose comme une entité pizzaOrder qui a les entités enfants suivantes : quantité, taille, croûte, garnitures, et ainsi de suite.

Vous définissez une entité enfant en ajoutant en préfixe un tiret (-) au signe arobase (@) et en ajoutant un retrait, comme l’illustre l’exemple suivant :

@ prebuilt number
@ list sizeList
@ list crustList
@ list toppingList

@ ml pizzaOrder
    - @ number Quantity
    - @ sizeList Size
    - @ crustList Crust
    - @ toppingList Topping

Dans l’exemple ci-dessus, l’entité numérique est une entité prédéfinie. Les entités restantes sont toutes les entités de liste.

L’exemple suivant montre une définition d’une entité address issue de l’apprentissage automatique, avec fromAddress et toAddress en tant que deux rôles, ainsi que des enfants.

@ list cityList
@ prebuilt number
@ prebuilt geographyV2
@ regex regexZipcode = /[0-9]{5}/
@ ml address hasRoles fromAddress, toAddress
@ address =
    - @ number 'door number'
    - @ ml streetName
    - @ ml location usesFeature geographyV2
        - @ cityList city
        - @ regexZipcode zipcode

Entités prédéfinies

Les entités LUIS prédéfinies sont définies par le système. Cela vous épargne du travail car elles sont de haute qualité et fournissent des valeurs normalisées qui sont plus faciles à utiliser dans les programmes. Par exemple, l’expression « mille deux » devient le nombre 1002. Les types d’entités [entité prédéfinie][prebuilt-entity] LUIS suivants sont pris en charge :

• age
• datetimeV2
• dimension
• e-mail
• geographyV2
• keyPhrase
• devise
• number
• ordinal
• ordinalV2
• pourcentage
• personName
• phonenumber
• température
• url
• DATETIME

Voici quelques exemples de la manière de définir des entités prédéfinies :

@ prebuilt number 
@ prebuilt datetimeV2
@ prebuilt age

Entité de liste

[Les entités de liste][list-entity] représentent un ensemble fixe, fermé de mots associés, ainsi que leurs synonymes. La valeur normalisée est rendue lorsque l’un des synonymes correspondants est reconnu. Ils respectent la casse et sont extraits en fonction d’une correspondance de texte exacte.

L’exemple suivant montre la syntaxe de définition d’une entité de liste :

@ list <entityName>  =
    - <normalized-value> :
        - <synonym1>
        - <synonym2>
        - ...
    - <normalized-value> :
        - <synonym1>, <synonym2>, ...

Extension de l’exemple pizzaOrder à partir de la section d’entité issue de l’apprentissage automatique, voici un exemple de listes pour la taille et la croûte des entités enfants :

@ list sizeList = 
    - Extra Large :
        - extra large
        - XL
        - xl
        - huge
        - massive
    - Large:
        - large
        - big
    - Medium :
        - medium
        - regular
    - Small :
        - small
        - smallest
        - individual

@ list crustList = 
    - Stuffed Crust :
        - stuffed crust
        - stufffed crust
    - Thin :
        - thin
        - thin crust
    - Thick :
        - thick
        - thick crust
        - Deep Dish
        - deep dish

Lorsque vous utilisez des entités de liste, vous devez inclure une valeur de la liste directement dans l’énoncé, mais vous n’avez pas besoin d’étiqueter les entités de liste, même si vous pouvez toujours les utiliser comme espaces réservés dans un modèle. L’exemple suivant montre un énoncé avec des valeurs de la liste :

- I'd like to order a large pepperoni stuffed crust pizza.

Entité d’expression régulière

Une [entité d’expression régulière][regular-expression-entity] extrait une entité en fonction du modèle d’un caractère d’expression régulière que vous fournissez. Les expressions régulières sont idéales pour du texte structuré ou pour une séquence prédéfinie de valeurs alphanumériques qui sont attendues dans un certain format. Par exemple :

Entité	Expression régulière	Exemple
Numéro de vol	vol [A-Z]{2} [0-9]{4}	vol AS 1234
Numéro de carte de crédit	[0-9]{16}	5478789865437632

Voici un exemple de définitions d’entité d’expression régulière :

> Flight Number regular expression entity definition
@ regex flightNumber = /flight [A-Z]{2} [0-9]{4}/

> Credit Card Number regular expression entity definition
@ regex creditCardNumber = /[0-9]{16}/

Rôles

Un rôle est un alias nommé pour une entité basé sur le contexte dans un énoncé. Un rôle peut être utilisé avec un type d’entité prédéfini ou personnalisé, à la fois dans les exemples d’énoncés et de modèles.

Dans l’exemple ci-dessous, l’entité Emplacement a deux rôles, origin et destination :

Entité	Rôle	Objectif
Emplacement	origin	D’où l’avion décolle
Emplacement	destination	Où l’avion atterrit

Les rôles dans le format de fichier .lu peuvent être définis explicitement ou implicitement. La définition de rôle explicite suit la notation :

@ <entityType> <entityName> [hasRole[s]] role1, role2, ...

Vous trouverez ci-dessous les différentes façons de définir explicitement des entités et leurs rôles :

> # ml entity definition with roles
> the following are 4 different approaches to define roles:

@ ml name role1, role2

@ ml name hasRoles role1, role2

@ ml name
@ name hasRoles role1, role2

@ ml name
@ name hasRole role1
@ name hasRole role2

Vous pouvez également définir implicitement des rôles directement dans des patterns et des énoncés étiquetés à l’aide du format suivant :

{@<entityName>:<roleName>}

Vous pouvez voir dans l’exemple ci-dessous comment les rôles userName:firstName et userName:lastName sont définis implicitement :

# getUserName
- My first name is {@userName:firstName=vishwac}
- My full name is {@userName:firstName=vishwac} {@userName:lastName=kannan}
- Hello, I'm {@userName:firstName=vishwac}
- {@userName=vishwac} is my name

@ ml userName

Dans les modèles, vous pouvez utiliser des rôles à l’aide de la notation {<entityName>:<roleName>}. Voici un exemple :

# getUserName
- call me {name:userName}
- I'm {name:userName}
- my name is {name:userName}

Vous pouvez également définir plusieurs rôles pour une entité dans les modèles comme ci-dessous :

> Roles can be specified for list entity types as well - in this case fromCity and toCity are added as roles to the 'city' list entity defined further below

# BookFlight
- book flight from {city:fromCity} to {city:toCity}
- [can you] get me a flight from {city:fromCity} to {city:toCity}
- get me a flight to {city:toCity}
- I need to fly from {city:fromCity}

$city:Seattle=
- Seattle
- Tacoma
- SeaTac
- SEA

$city:Portland=
- Portland
- PDX

Modèles

[Les modèles][] vous permettent de couvrir un grand nombre d’exemples qui doivent être mis en correspondance en créant un énoncé avec des éléments de substitution pour l’emplacement où les entités doivent être trouvées. Les modèles sont une expression régulière au niveau du jeton avec des espaces réservés pour les entités. Si un énoncé a des espaces réservés d’entité ou une syntaxe de modèle, il est interprété comme un modèle. Sinon, il est interprété comme un énoncé pour la formation de l’apprentissage automatique.

Les éléments de substitution d’entité peuvent correspondre aux entités de n’importe quel type ou ils peuvent être définis par le modèle lui-même, par exemple lorsqu’une section du modèle est une entité identifiée en examinant les mots environnants.

Syntaxe du modèle

Le format de fichier .lu prend en charge la [syntaxe du modèle][]. La syntaxe du modèle est un modèle incorporé dans un énoncé. Le modèle doit contenir à la fois les mots et entités que vous souhaitez faire correspondre et les mots et la ponctuation que vous souhaitez ignorer. Le modèle n’est pas une expression régulière.

Les entités des modèles sont placées entre accolades, {}. Les modèles peuvent inclure des entités et des entités avec rôles. [Pattern.any][pattern-any] est une entité qui n’est utilisée que dans les modèles.

Fonction	Syntaxe	Niveau d’imbrication	Exemple
Entité	{} - accolades	2	Where is form {entity-name}?
facultatifs	[] - crochets Les niveaux d’imbrication de la syntaxe facultative et de la syntaxe de regroupement sont limités à trois, pour toutes les combinaisons possibles	2	The question mark is optional [?]
regroupement	() – parenthèses	2	is (a \| b)
or	| - barres verticales (bâtons) Les barres verticales (Ou) sont limitées à deux par groupe	-	Where is form ({form-name-short} \| {form-name-long} \| {form-number})
Début ou fin de l’énoncé	^ – accent circonflexe (caret)	-	^begin the utterance the utterance is done^ ^strict literal match of entire utterance with {number} entity^

Pour plus d’informations, consultez l’article [Syntaxe du modèle][] dans la documentation LUIS.

L’exemple suivant montre une définition qui serait traitée comme un modèle avec une entité alarmTime définie par le modèle :

# DeleteAlarm
- delete the {alarmTime} alarm

L’énoncé « supprimer l’alarme de 7 h » correspondrait au modèle et reconnaîtrait une entité alarmTime de « 7 h ».

En revanche, l’exemple suivant est un énoncé étiqueté où alarmTime est une entité issue de l’apprentissage automatique, car elle a une valeur étiquetée 7 h :

# DeleteAlarm
- delete the {alarmTime=7AM} alarm

Vous ne pouvez pas combiner les étiquettes d’entité et les espaces réservés d’entité dans le même énoncé, mais vous pouvez utiliser des espaces réservés correspondant aux entités issues de l’apprentissage automatique.

Liste d’expressions

Une [liste d’expressions][phrase-list] est une liste de mots ou d’expressions qui aident à trouver le concept que vous essayez d’identifier. La liste ne respecte pas la casse. Les listes d’expressions ont deux objectifs différents :

• Alimenter le dictionnaire : il s’agit de la valeur par défaut lorsque vous définissez une liste d’expressions et qu’elle est appelée non interchangeable. Les expressions à plusieurs mots deviennent une fonctionnalité pour l’apprentissage automatique qui nécessite moins d’exemples à apprendre. Dans cette utilisation, il n’existe aucune relation entre les membres de la liste d’expressions.
• Définir des synonymes : les listes d’expressions interchangeables sont utilisées pour définir des synonymes qui signifient la même chose. Cette utilisation permet de généraliser avec moins d’exemples. Toute expression de la liste génère la même fonctionnalité que l’apprentissage automatique. Pour l’utiliser, vous devez spécifier interchangeable dans votre définition de liste d’expressions (@ phraselist <Name>(interchangeable))

Pour plus d’informations sur le moment et la façon d’utiliser des listes d’expressions, notamment des scénarios classiques pour lesquels elles sont utilisées, consultez [Créer une liste d’expressions pour un concept][phrase-list].

Vous définissez les listes d’expressions à l’aide de la notation suivante :

@ phraselist <Name>
    - <phrase1>
    - <phrase2>

Voici un exemple de liste d’expressions utilisée pour alimenter le dictionnaire :

@ phraseList newTerms=
- surf the sky
- jump on the beam
- blue sky pajamas

Les listes d’expressions peuvent également être utilisées pour définir des synonymes en les marquant comme interchangeables.

@ phraseList Want(interchangeable) =
    - require, need, desire, know

> You can also break up the phrase list values into a bulleted list
@ phraseList Want(interchangeable) =
    - require
    - need
    - desire
    - know

Par défaut, les listes d’expressions sont disponibles pour toutes les intentions et entités apprises. Il existe trois états de disponibilité :

État de disponibilité	Description
enabledForAllModels	(par défaut) Lorsqu’une liste d’expressions est marquée comme enabledForAllModels, elle est disponible pour tous les modèles, que vous le listiez spécifiquement en tant que caractéristique ou non.
disabledForAllModels	Lorsqu’une liste d’expressions est marquée comme disabledForAllModels, elle est utilisée uniquement dans un modèle si elle est spécifiquement répertoriée comme caractéristique.
disabled	Lorsqu’une liste d’expressions est marquée comme disabled, elle n’est utilisée nulle part, y compris dans aucun modèle si elle est spécifiquement répertoriée comme caractéristique. Cela permet de désactiver facilement une liste d’expressions pour voir si les choses fonctionnent bien sans elle.

Les listes d’expressions sont disponibles globalement par défaut et peuvent également être définies spécifiquement à l’aide du mot clé enabledForAllModels :

@ phraselist abc enabledForAllModels

Deux exemples de définition d’une liste d’expressions sur disabledForAllModels :

@ phraselist abc disabledForAllModels

> You can also use this approach
@ phraselist question(interchangeable) =
    - are you
    - you are

@ question disabledForAllModels

Lors de la définition d’une liste d’expressions sur disabled, elle ne sera pas utilisée, même lorsqu’elle est spécifiquement répertoriée en tant que caractéristique :

> phrase list definition, temporarily set to disabled to measure its impact

@ phraselist yourPhraseList disabled

> phrase list as feature to intent, won't be used

@ intent yourIntent usesFeature yourPhraseList

Les listes d’expressions peuvent être utilisées comme caractéristiques pour des intentions et des entités spécifiques, comme décrit dans la section suivante.

Ajout de caractéristiques aux intentions et entités

L’apprentissage automatique fonctionne en prenant des caractéristiques et en apprenant comment elles sont liées à l’intention ou à l’entité souhaitée à partir d’exemples d’énoncés. Par défaut, les caractéristiques sont simplement les mots qui composent des énoncés. Les listes d’expressions fournissent un moyen de regrouper plusieurs mots dans une nouvelle caractéristique ; cela améliore la généralisation de l’apprentissage automatique à partir de moins d’exemples. Par défaut, les listes d’expressions sont globales et s’appliquent à tous les modèles Machine Learning, mais vous pouvez également les lier à des intentions ou entités spécifiques. Vous pouvez également utiliser des intentions ou des entités en tant que caractéristiques pour détecter d’autres intentions en tant qu’entités. Cela fournit une modularité pour vous permettre de créer des concepts plus complexes à partir de blocs élémentaires plus simples.

Les caractéristiques peuvent être ajoutées à n’importe quelle intention ou entité apprise à l’aide du mot clé usesFeature.

Ajouter une liste d’expressions en tant que caractéristique

Les listes d’expressions peuvent être ajoutées en tant que caractéristique d’intentions ou d’entités. Cela permet à ces intentions ou entités spécifiques sans affecter d’autres intentions et entités. Voici un exemple qui illustre comment définir une liste d’expressions en tant que caractéristique d’un autre modèle :

> phrase list definition

@ phraseList PLCity(interchangeable) =
    - seattle
    - space needle
    - SEATAC
    - SEA

> phrase list as feature to intent 

@ intent getUserProfileIntent usesFeature PLCity

> phrase list as a feature to an ml entity

@ ml myCity usesFeature PLCity

@ regex regexZipcode = /[0-9]{5}/

> a phrase list is used as a feature in a hierarchal entity

@ ml address fromAddress, toAddress
@ address =
    - @ number 'door number'
    - @ ml streetName
    - @ ml location
        - @ ml city usesFeature PLCity
        - @ regexZipcode zipcode

Ajouter une entité ou une intention en tant que caractéristique

Vous trouverez ci-dessous des exemples d’ajout d’intentions et d’entités en tant que caractéristique avec usesFeature :

> entity definition - @ <entityType> <entityName> [<roles>]

@ prebuilt personName
@ prebuilt age

> entity definition with roles

@ ml userName hasRoles fistName, lastName

> add an entity as a feature to another entity

@ userName usesFeature personName

> add an entity as feature to an intent

@ intent getUserNameIntent usesFeature personName

> Intent definition

# getUserNameIntent
- utterances

> multiple entities as a feature to a model

@ intent getUserNameIntent usesFeature age, personName

> intent as a feature to another intent

@ intent getUserProfileIntent usesFeature getUserNameIntent

# getUserProfileIntent
- utterances

Métadonnées

Vous pouvez inclure des métadonnées liées à votre application LUIS ou à la base de connaissances QnA Maker dans le fichier .lu. Cela aidera l’analyseur à gérer correctement le contenu Language Understanding. Les métadonnées sont généralement ajoutées au début du fichier .lu.

Voici comment définir les informations de configuration à l’aide de > !# :

> !# @<property> = <value>
> !# @<scope>.<property> = <value>
> !# @<scope>.<property> = <semicolon-delimited-key-value-pairs>

Notez que toutes les informations transmises explicitement par le biais d’arguments CLI remplacent les informations contenues dans le fichier .lu.

> LUIS application information
> !# @app.name = my luis application
> !# @app.desc = description of my luis application
> !# @app.versionId = 1.0
> !# @app.culture = en-us
> !# @app.luis_schema_version = 7.0.0
> !# @app.settings.NormalizePunctuation = true
> !# @app.settings.NormalizeWordForm = true
> !# @app.settings.UseAllTrainingData = true
> !# @app.tokenizerVersion = 1.0.0

Consultez le tableau ci-dessous pour obtenir une description des valeurs de métadonnées d’application utilisées dans l’exemple ci-dessus. Pour plus d’informations sur app.settings dans LUIS, consultez [Paramètres d’application et de version][luis-metadata] dans la documentation LUIS.

Métadonnées	Description
Nom	Nom de votre application
VersionId	Nom de cette version spécifique
culture	Langue utilisée par votre application
Version du schéma	Le schéma LUIS est mis à jour chaque fois qu’une nouvelle caractéristique ou un nouveau paramètre est ajouté dans LUIS. Utilisez le numéro de version du schéma que vous avez utilisé lors de la création ou de la mise à jour de votre modèle LUIS.

Références externes

Les sections ci-dessous détaillent comment faire des références de fichier local et d’URI.

Références de fichier local

Référence le fichier .lu. Suivez la syntaxe du lien de Markdown. Les références prises en charge sont les suivantes :

• Référence à un autre fichier .lu par le biais de [link name](<.lu file name>). La référence peut être un chemin absolu ou un chemin relatif par rapport au fichier .lu contenant.
• La référence à un dossier contenant d’autres fichiers .lu est prise en charge par le biais de :
  • [link name](<.lu file path>*) : recherche les fichiers .lu sous le chemin absolu ou relatif spécifié
  • [link name](<.lu file path>**) : recherche de manière récursive les fichiers .lu sous le chemin absolu ou relatif spécifié, y compris les sous-dossiers.
• Vous pouvez également ajouter des références à des énoncés définis dans un fichier spécifique sous une section d’intention ou en tant que paires QnA.
  • [link name](<.lu file path>#<INTENT-NAME>) : recherche tous les énoncés sous <INTENT-NAME> dans le fichier .lu et les ajoute à la liste des énoncés où la référence est spécifiée.
  • [link name](<.lu file path>#<INTENT-NAME>*utterances*) : recherche tous les énoncés (pas les patterns) sous <INTENT-NAME> dans le fichier .lu et les ajoute à la liste des énoncés où la référence est spécifiée.
  • [link name](<.lu file path>#<INTENT-NAME>*patterns*) : recherche tous les patterns (pas les énoncés) sous <INTENT-NAME> dans le fichier .lu et les ajoute à la liste des patterns où la référence est spécifiée.
  • [link name](<.lu file path>#*utterances*) : recherche tous les énoncés dans le fichier .lu et les ajoute à la liste des énoncés où la référence est spécifiée.
  • [link name](<.lu file path>#*patterns*) : recherche tous les patterns dans le fichier .lu et les ajoute à la liste des énoncés où la référence est spécifiée.
  • [link name](<.lu file path>#*utterancesAndPatterns*) : recherche tous les énoncés et patterns dans le fichier .lu et les ajoute à la liste des énoncés où la référence est spécifiée.
  • [link name](<.qna file path>#$name?) : recherche toutes les modifications à partir de la définition de modification spécifique dans le contenu .qna, et les ajoute à la liste des énoncés où la référence est spécifiée.
  • [link name](<.qna file path>#*alterations*?) : recherche toutes les modifications à partir du contenu .qna, et les ajoute à la liste des énoncés où la référence est spécifiée.
  • [link name](<.qna file path>#?question-to-find?) : recherche toutes les variantes de question à partir de la question spécifique, et les ajoute à la liste des énoncés où la référence est spécifiée. Notez que tous les espaces dans votre question devront être remplacés par le caractère -.
  • [link name](<.qna file path>#*answers*?) : recherche toutes les réponses et les ajoute à la liste des énoncés où la référence est spécifiée.

Voici un exemple des références mentionnées ci-dessus :

> You can include references to other .lu files

[All LU files](./all.lu)

> References to other files can have wildcards in them

[en-us](./en-us/*)

> References to other lu files can include subfolders as well.
> /** indicates to the parser to recursively look for .lu files in all subfolders as well.

[all LU files](../**)

> You can include deep references to intents defined in a .lu file in utterances

# None
- [None uttearnces](./all.lu#Help)

> With the above statement, the parser will parse all.lu and extract out all utterances associated with the 'Help' intent and add them under 'None' intent as defined in this file.

> NOTE: This **only** works for utterances as entities that are referenced by the uttearnces in the 'Help' intent won't be brought forward to this .lu file.

# All utterances
> you can use the *utterances* wild card to include all utterances from a lu file. This includes utterances across all intents defined in that .lu file.
- [all.lu](./all.lu#*utterances*)
> you can use the *patterns* wild card to include all patterns from a lu file.
> - [all.lu](./all.lu#*patterns*)
> you can use the *utterancesAndPatterns* wild card to include all utterances and patterns from a lu file.
> - [all.lu](./all.lu#*utterancesAndPatterns*)

> You can include wild cards with deep references to QnA maker questions defined in a .qna file in utterances

# None
- [QnA questions](./*#?)

> With the above statement, the parser will parse **all** .lu files under ./, extract out all questions from QnA pairs in those files and add them under 'None' intent as defined in this file.

> You can include deep references to QnA maker questions defined in a .qna file in utterances

# None
- [QnA questions](./qna1.qna#?)

> With the above statement, the parser will parse qna1.lu and extract out all questions from QnA pairs in that file and add them under 'None' intent as defined in this file.

Références URI

Vous trouverez ci-dessous des exemples de références URI :

> URI to LU resource
[import](http://.../foo.lu)

# intent1
> Ability to pull in specific utterances from an intent
- [import](http://.../foo.lu#None)

# intent2
> Ability to pull in utterances or patterns or both from a specific intent 'None'
- [import](http://..../foo.lu#None*utterances*)
- [import](http://..../bar.lu#None*patterns*)
- [import](http://..../taz.lu#None*utterancesandpatterns*)

# intent3
> Ability to pull in all utterances or patterns or both across all intents
- [import](http://..../foo.lu#*utterances*)
- [import](http://..../bar.lu#*patterns*)
- [import](http://..../taz.lu#*utterancesandpatterns*)

Informations supplémentaires

• Pour plus d’informations sur les fichiers .qna, consultez Format de fichier .qna.