LU-Dateiformat

GILT FÜR: SDK v4

Eine .lu-Datei beschreibt ein Sprachverständnismodell. Eine .lu-Datei enthält für LUIS-Konzepte einfache textbasierte (Markdown-ähnliche) Definitionen. Sie können eine oder mehrere .lu-Dateien verwenden, um ein Sprachmodell für den NLU-Dienst (Natural Language Understanding) oder das Modul zu trainieren, das Ihr Bot verwendet, z. B. Language Understanding (LUIS) oder Orchestrator. Die ausgewählte NLU-Engine kann möglicherweise nur eine Teilmenge der Elemente interpretieren, die eine .lu-Datei beschreiben kann.

Eine NLU-Engine basiert auf einem Sprachmodell, um zu verstehen, was ein Benutzer sagt. Die Engine erstellt ein Sprachmodell aus Sätzen von Trainingsbeispielen, genau wie jeder machine Learning-Algorithmus. Nach dem Training verwendet die Engine das Modell, um die Absicht einer Äußerung vorherzusagen, im Allgemeinen in Form einer oder mehrerer Absichten, die eine Aufgabe oder Aktion darstellen, die der Benutzer ausführen möchte, und null oder mehr Entitäten, die Elemente darstellen, die für die Absicht relevant sind.

Sie können LUIS oder Orchestrator mit jedem Bot verwenden, der mit dem Bot Framework SDK oder Composer entwickelt wurde.

Hinweis

Language Understanding (LUIS) wird am 1. Oktober 2025 eingestellt. Ab dem 1. April 2023 können Sie keine neuen LUIS-Ressourcen erstellen. Eine neuere Version von Language Understanding ist jetzt als Teil von Azure KI Language verfügbar.

Conversational Language Understanding (CLU), ein Feature von Azure KI Language, ist die aktualisierte Version von LUIS. Weitere Informationen zu Language Understanding im Bot Framework-SDK finden Sie unter Natürliches Sprachverständnis.

Dieser Artikel ist eine Referenz zum Darstellen von Sprachmodell-Elementen im .lu-Dateiformat. Informationen dazu, wie Sprachverständnis in Bots verwendet wird, finden Sie unter Language Understanding oder linguistische Datenverarbeitung in Composer.

Definieren von Absichten mithilfe von Beispiel-Äußerungen

Eine Absicht stellt eine Aufgabe oder Aktion dar, die der Benutzer ausführen möchte und die in einer Äußerung des Benutzers ausgedrückt wird. Sie fügen Ihrem Bot Absichten hinzu, damit er Gruppen von Fragen oder Befehlen identifizieren kann, die dieselbe Benutzerabsicht darstellen.

Einige Beispiele für Absichten, die Sie für einen Reise-Bot definieren können, mit den Beispiel-Äußerungen, aus denen sie abgeleitet sind:

Intent	Beispiele für Äußerungen
FlugBuchen	„Buche mir einen Flug nach Maui in der nächsten Woche“ „Fliege mich am 24. nach Maui“ „Ich brauche ein Flugticket am nächsten Freitag nach Maui“
Begrüßung	„Hallo“ „Hallo“ „Guten Tag“
CheckWeather	„Wie sieht das Wetter in Maui nächste Woche aus?“
Keine	„Ich mag Kekse“ „Ochsenfrösche wurden dabei aufgezeichnet, wie sie über 7 Fuß springen“

Zusätzlich zu den von Ihnen definierten Absichten handelt es sich bei None um eine Rückfall-Absicht, die bewirkt, dass das Ereignis unknownIntent ausgelöst wird, wenn aus der Äußerung des Benutzers keine Absichten abgeleitet werden können. Bei Verwendung von LUIS ist die None-Absicht eine erforderliche Absicht, die Sie mit Äußerungen erstellen müssen, die sich außerhalb Ihrer Domäne befinden. Die Äußerungen, die Ihrer None-Absicht zugeordnet sind, sollten ungefähr 10 % der gesamten Äußerungen in Ihrer .lu-Datei umfassen.

Absichten mit ihren Beispiel-Äußerungen werden wie folgt deklariert:

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

# <intent-name> beschreibt einen neuen Absichtsdefinitionsabschnitt. Jede Zeile nach der Absichtsdefinition ist eine Beispieläußerung im Format - <utterance>, die diese Absicht beschreibt.

Hier ist ein Beispiel für eine .lu-Datei, die diese Absichten und Beispiel-Äußerungen veranschaulicht, mit denen erfasst wird, wie Benutzer die Absicht ausdrücken können:

> 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?

Hinweis

Zum Kennzeichnen von Listen können Sie die Zeichen -, + oder * verwenden. Nummerierte Listen werden nicht unterstützt.

Verwenden Sie >, um einen Kommentar zu erstellen.

Mehrere Kommentarzeichen („>„) können auch zum Definieren von Abschnitten in der .lu-Datei verwendet werden, um den Inhalt zu organisieren. Composer ermöglicht es Ihnen, beim Bearbeiten von .lu-Dateien die Vorteile der Gliederung zu nutzen.

Weitere Informationen zu Absichten und Äußerungen finden Sie unter Absichten in Ihrer LUIS-App und verstehen, was gute Äußerungen für Ihre LUIS-App sind in der LUIS-Dokumentation gelten.

Entitäten

Eine Entität ist Teil einer Äußerung, die als Parameter betrachtet werden kann, der bei der Interpretation einer Absicht verwendet werden kann. Beispielsweise enthält die Äußerung Buche ein Ticket nach Maui eine FlightDestination-Entität.

Beispieläußerung eines Benutzers	Vorhergesagte Absicht	Extrahierte Entitäten	Erklärung
Hallo, wie geht es dir?	Greeting (Begrüßung)	-	Es werden keine Entitäten extrahiert.
„Buche einen Flug nach Maui“	FlugBuchen	„Maui“	Die Entität "FlightDestination" wird als "Maui" extrahiert.
„Wie sieht das Wetter in Maui nächste Woche aus?“	CheckWeather	„Maui“, „nächste Woche“	Die Entität „WeatherLocation“ wird als „Maui“ und die Entität „DateRange“ als "nächste Woche" extrahiert.
„Ich möchte eine kleine Pizza bestellen“	orderPizza	„klein“	Die Entität „Size“ wird als „klein“ extrahiert.
„Eine Besprechung mit Robert im Vertrieb um 13 Uhr planen“	BesprechungPlanen	„13 Uhr“, „Robert“	Die Entität „MeetingTime“ wird als „13 Uhr“ extrahiert, und „Attendees“ wird als „Robert“ extrahiert.

Tipp

Weitere Informationen zur Verwendung von Entitäten in LUIS finden Sie in der LUIS-Dokumentation unter Entitäten in LUIS .

Entitätsdefinitionen

Eine Entitätsdefinition definiert, wie eine Spanne in einer Äußerung als Entität erkannt wird, die Sie dann in Ihrem Bot verwenden können. Es gibt viele verschiedene Arten von Entitäten, darunter: maschinell gelernt, vorab erstellt, Listen, regulärer Ausdrücke, und Muster.

Entitätsdefinitionen in .lu-Dateien beginnen den Eintrag mit dem @-Zeichen (@) gefolgt vom Typ der Entität und des Namens:

@ <entity-type> <entity-name>

Optional kann jede Entität auch über Rollen verfügen, die unterschiedliche Verwendungen derselben Entität identifizieren. Sie können auch Features hinzufügen, um die Erkennung von Entitäten zu verbessern. Die allgemeine Syntax sieht so aus:

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

Entitäten, die eine Definition erfordern, wie Listen- und reguläre Ausdrücke-Entitäten, werden mit der folgenden Notation dargestellt:

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

Weitere Beispiele für Entitätsdeklarationen werden in den folgenden Abschnitten zusammen mit den Entitätstypen veranschaulicht, auf die sie angewendet werden.

Mit Ausnahme vordefinierter Entitäten können Entitätsnamen mehrere Wörter mit Leerzeichen enthalten. Alle Entitätsnamen mit einem Leerzeichen müssen in Anführungszeichen gesetzt werden.

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

Entitätstypen

Es gibt mehrere Arten von Entitäten in LUIS. In den folgenden Abschnitten erfahren Sie mehr über diese Entitätstypen und verwandte Konzepte, z. B. Rollen und Features sowie Beispiele zum Erstellen von LU-Vorlagen, die diese verwenden.

Durch maschinelles Lernen erworbene Entität

Maschinell gelernte Entitäten sind Entitäten, die es Ihnen ermöglichen, Beispiele zu geben, indem Sie sie in den Beispiel-Ausdrücken markieren. Dies gibt ihnen den Kontext, aus dem sie lernen müssen. Die vom maschinell gelernte Entität ist ideal, wenn Daten identifiziert werden, die nicht immer gut formatiert sind, aber die gleiche Bedeutung haben.

Im folgenden Beispiel wird eine maschinell gelernte Entität namens city (@ ml city) und eine bookFlight Absicht mit Beispiel-Ausdrücken mit Ihren Entitäten veranschaulicht:

> 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}

Wenn ein Benutzer etwas ähnliches sagt wie Ich möchte einen Flug von London nach Madrid gebucht haben, erkennt LUIS die „bookFlight“-Absicht und extrahiert sowohl London als auch Madrid als Stadt-Entitäten.

Rollen sind im Wesentlichen eine zusätzliche Ebene kontextbezogener Informationen, die Sie Ihren maschinell gelernten Entitäten hinzufügen können, die auch aus dem Kontext lernen. Im folgenden Beispiel werden die mit der Stadtentität verknüpften Abflug- und Zielrollen angezeigt:

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

Maschinell gelernte Entitäten können auch komplex sein, wenn Sie eine Hierarchie von einander zugeordneten Entitäten enthalten. Sie können z. B. eine pizzaOrder Entität mit den folgenden untergeordneten Entitäten enthalten: Menge, Größe, Kruste, Toppings usw.

Sie definieren eine untergeordnete Entität, indem dem @-Zeichen einen Gedankenstrich (-) vorangestellt und sie eingezogen wird, wie im folgenden Beispiel veranschaulicht wird:

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

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

Im obigen Beispiel ist die Zahlenentität eine vordefinierte Entität. Die verbleibenden Entitäten sind alle Listenentitäten.

Das nächste Beispiel zeigt eine Definition einer address maschinell gelernten Entität mit fromAddress und toAddress als zwei Rollen sowie untergeordneten Elementen.

@ 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

Vordefinierte Entitäten

Vordefinierte LUIS-Entitäten werden vom System definiert. Dadurch sparen Sie Arbeit, da sie von hoher Qualität sind und normalisierte Werte bereitstellen, die in Programmen einfacher zu verwenden sind. Beispielsweise würde der Ausdruck „eintausend und zwei“ zur Zahl 1002 werden. Die folgenden LUIS [vordefinierte Entität][vordefinierte Entität]-Typen werden unterstützt:

• age
• datetimeV2
• Dimension
• E-Mail
• geographyV2
• keyPhrase
• money
• Zahl
• ordinal
• ordinalV2
• Prozentwert
• personName
• phonenumber
• Temperatur
• url
• datetime

Im Folgenden sehen Sie Beispiele, wie Sie vordefinierte Entitäten definieren:

@ prebuilt number 
@ prebuilt datetimeV2
@ prebuilt age

Entität vom Typ „List“

[Listenentitäten][Listenentität] stellen einen festen, abgeschlossenen Satz verwandter Wörter zusammen mit ihren Synonymen dar. Der normalisierte Wert wird zurückgegeben, wenn eines der entsprechenden Synonyme erkannt wird. Sie werden nach Groß- und Kleinschreibung unterschieden und auf Grundlage einer genauen Textübereinstimmung extrahiert.

Das folgende Beispiel zeigt die Syntax zum Definieren einer Listenentität:

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

Wenn Sie das pizzaOrder Beispiel aus dem Abschnitt maschinell gelernte Entität erweitern, finden Sie hier ein Beispiel für Listen für die Größe und die untergeordneten Entitäten von Crust:

@ 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

Tipp

Da für eine Listenentität eine genaue Übereinstimmung extrahiert werden muss, können ihre Ergebnisse durch Hinzufügen allgemeiner Rechtschreibfehler verbessert werden. Eine häufige Ursache von Rechtschreibfehlern ist das Ergebnis von Eingabefehlern, z. B. Doppelbuchstaben, die im obigen Beispiel als "gefülllte Kruste" verdreifacht wurden.

Wenn Sie Listenentitäten verwenden, sollten Sie einen Wert aus der Liste direkt in die Äußerung aufnehmen. Sie müssen keine Listenentitäten bezeichnen, obwohl Sie sie weiterhin als Platzhalter in einem Muster verwenden können. Das folgende Beispiel zeigt eine Äußerung mit Werten aus der Liste:

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

Entität vom Typ „RegEx“

Eine RegEx-Entität extrahiert eine Entität anhand eines regulären Ausdrucksmusters, das Sie bereitstellen. Reguläre Ausdrücke eignen sich am besten für strukturierten Text oder eine vordefinierte Sequenz alphanumerischer Werte, die in einem bestimmten Format erwartet werden. Beispiel:

Entität	Regulärer Ausdruck	Beispiel
Flugnummer	Flug [A-Z]{2} [0-9]{4}	Flug AS 1234
Credit Card Number (Kreditkartennummer)	[0-9]{16}	5478789865437632

Es folgt ein Beispiel für eine einfache Definition einer Entität als regulärer Ausdruck.

> 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}/

Rollen

Eine Rolle ist ein benannter Alias für eine Entität, der auf dem Kontext innerhalb einer Äußerung basiert. Eine Rolle kann mit allen vordefinierten oder benutzerdefinierten Entitätstypen und sowohl in Beispieläußerungen als auch in Mustern verwendet werden.

Im folgenden Beispiel hat die Entität Location die beiden Rollen origin und destination:

Entity	Rolle	Zweck
Standort	origin	Wo das Flugzeug abfliegt
Standort	destination	Wo das Flugzeug landet

Rollen im LU-Dateiformat können explizit oder implizit definiert werden. Die Definition expliziter Rollen hat die folgende Notation:

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

Nachstehend sehen Sie die verschiedenen Möglichkeiten, wie Sie Entitäten und ihre Rollen explizit definieren können:

> # 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

Sie können in Mustern und bezeichneten Äußerungen mithilfe des folgenden Formats direkt implizit definierte Rollen definieren:

{@<entityName>:<roleName>}

Im folgenden Beispiel sehen Sie, wie die Rollen userName:firstName und userName:lastName implizit definiert werden:

# 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

In Mustern können Sie Rollen mit der Notation {<entityName>:<roleName>} verwenden. Ein Beispiel:

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

Sie können in Mustern auch mehrere Rollen für eine Entität definieren, siehe unten:

> 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

Muster

[Muster][] ermöglichen es Ihnen, eine große Anzahl von Beispielen abzudecken, die durch Erstellen einer Äußerung mit Platzhaltern für den Ort, an dem Entitäten gefunden werden sollen, übereinstimmen sollten. Die Muster sind ein regulärer Ausdruck auf Token-Ebene mit Platzhaltern für Entitäten. Wenn eine Äußerung über Entitäts-Platzhalter oder Muster-Syntax verfügt, wird sie als Muster interpretiert. Andernfalls wird sie als Äußerung für die Schulung des maschinellen Lernens interpretiert.

Die Entitäts-Platzhalter können Entitäten eines beliebigen Typs entsprechen oder durch das Muster selbst definiert werden, z. B. wenn ein Abschnitt im Muster eine Entität ist, die durch die Betrachtung der umgebenden Wörter identifiziert wird.

Muster-Syntax

Das .lu-Dateiformat unterstützt die LUIS [Muster-Syntax][]. Die Muster-Syntax ist eine Vorlage, die in einer Äußerung eingebettet ist. Die Vorlage sollte sowohl abzugleichende Wörter und Entitäten als auch zu ignorierende Wörter und Interpunktion enthalten. Die Vorlage ist kein regulärer Ausdruck.

Entitäten in Mustern sind in geschweifte Klammern, eingeschlossen, {}. Muster können Entitäten und Entitäten mit Rollen enthalten. [Pattern.any] ist eine Entität, die ausschließlich in Mustern verwendet wird.

Funktion	Syntax	Schachtelungsebene	Beispiel
Entität	{} - Klammern	2	Where is form {entity-name}?
optional	[] - eckige Klammern Schachtelungsebenen jeder beliebigen Kombination von optionaler und Gruppierungssyntax sind auf 3 begrenzt.	2	The question mark is optional [?]
Gruppierung	() – Klammern	2	is (a \| b)
oder	| senkrechter Strich (Pipe) Pro Gruppe sind senkrechte Striche (oder) auf 2 begrenzt	-	Where is form ({form-name-short} \| {form-name-long} \| {form-number})
Anfang und/oder Ende der Äußerung	^ – Caretzeichen	-	^begin the utterance the utterance is done^ ^strict literal match of entire utterance with {number} entity^

Weitere Informationen finden Sie im Artikel [Mustersyntax][] in der LUIS-Dokumentation.

Das folgende Beispiel zeigt eine Definition, die als Muster mit einer durch das Muster definierten alarmTime Entität behandelt wird:

# DeleteAlarm
- delete the {alarmTime} alarm

Die Äußerung „Wecker um 7 Uhr löschen“ würde dem Muster entsprechen und eine alarmTime Entität von „7 Uhr“ erkennen.

Im Gegensatz dazu ist das folgende Beispiel eine bezeichnete Äußerung, bei der alarmTime eine maschinell gelernte Entität ist, da sie über einen bezeichneten Wert von 7 Uhr verfügt:

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

Sie können Entitätsbezeichnungen und Entitätsplatzhalter nicht in derselben Äußerung kombinieren, aber Sie können Platzhalter verwenden, die maschinell gelernten Entitäten entsprechen.

Tipp

Sie sollten verstehen, wie sich die App verhält, bevor Sie Muster hinzufügen, da Muster stärker gewichtet werden als Beispieläußerungen und die Konfidenz verzerren. Es schadet nicht, sie am Anfang der Modellentwicklung hinzuzufügen, aber es ist einfacher, festzustellen, welchen Einfluss jedes Muster auf das Modell hat, nachdem das Modell mit Äußerungen getestet wurde.

Ausdrucksliste

Eine [Begriffsliste] ist eine Liste mit Wörtern oder Ausdrücken, die bei der Erkennung des Konzepts helfen, das Sie zu identifizieren versuchen. Die Liste unterscheidet nicht zwischen Groß- und Kleinschreibung. Begriffslisten haben zwei unterschiedliche Zwecke:

• Erweitern des Wörterbuchs: Dies ist die Standardeinstellung, wenn Sie eine Begriffsliste definieren und sie als nicht austauschbar bezeichnet wird. Mehrwort-Ausdrücke werden zu einem Feature für maschinelles Lernen, das weniger Beispiele erfordert, um zu lernen. In dieser Verwendung gibt es keine Beziehung zwischen den Mitgliedern der Begriffsliste.
• Definieren von Synonymen: Austauschbare Begriffslisten werden verwendet, um Synonyme zu definieren, die dasselbe bedeuten. Diese Verwendung trägt dazu bei, mit weniger Beispielen zu verallgemeinern. Jeder Ausdruck in der Liste führt zum gleichen Feature beim maschinellen Lernen. Um dies zu verwenden, müssen Sie interchangeable in der Begriffslisten-Definition angeben (@ phraselist <Name>(interchangeable))

Hinweis

Ein Feature kann eine Begriffsliste oder Entität sein, die Sie einer Absicht oder Entität zuordnen, um die Wichtigkeit dieses Features hervorzuheben, um die Bedeutung dieses Features bei der genauen Erkennung von Benutzerabsichten hervorzuheben. Weitere Informationen finden Sie unter Hinzufügen einer Begriffsliste als Feature .

Weitere Informationen zum Zeitpunkt und zur Verwendung von Begriffslisten, einschließlich typischer Szenarien, für die sie verwendet werden, finden Sie unter [Erstellen einer Begriffsliste für ein Konzept][Begriffsliste].

Sie definieren Begriffsliste mit der folgenden Notation:

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

Hier ist ein Beispiel für eine Begriffsliste, die zum Erweitern des Wörterbuchs verwendet wird:

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

Begriffslisten können auch verwendet werden, um Synonyme zu definieren, indem sie als austauschbar gekennzeichnet werden.

@ 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

Standardmäßig sind Begriffslisten für alle gelernten Absichten und Entitäten verfügbar. Es gibt drei Verfügbarkeitszustände:

Verfügbarkeitszustand	Beschreibung
enabledForAllModels	(Standard) Wenn eine Begriffsliste als enabledForAllModels gekennzeichnet ist, ist sie für alle Modelle verfügbar, unabhängig davon, ob Sie sie speziell als Feature auflisten.
disabledForAllModels	Wenn eine Begriffsliste als disabledForAllModels gekennzeichnet ist, wird sie nur in einem Modell verwendet, wenn sie speziell als Feature aufgeführt ist.
deaktiviert	Wenn eine Begriffsliste als disabled gekennzeichnet ist, wird sie nirgendwo verwendet, auch nicht in Modellen, in denen sie speziell als Feature aufgeführt ist. Dies bietet die einfache Möglichkeit, eine Begriffsliste zu deaktivieren, um zu sehen, wie gut es ohne sie funktioniert.

Begriffslisten sind standardmäßig global verfügbar und können auch mithilfe des enabledForAllModels Schlüsselwort speziell festgelegt werden:

@ phraselist abc enabledForAllModels

Zwei Beispiele für das Festlegen einer Begriffsliste auf disabledForAllModels:

@ phraselist abc disabledForAllModels

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

@ question disabledForAllModels

Wenn Sie eine Begriffsliste auf disabled festlegen, wird sie nicht verwendet, auch wenn sie speziell als Feature aufgeführt wird:

> 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

Begriffslisten können als Features für bestimmte Absichten und Entitäten verwendet werden, wie im nächsten Abschnitt beschrieben.

Hinzufügen von Features zu Absichten und Entitäten

Maschinelles Lernen funktioniert, indem Features verwendet und gelernt wird, wie sie sich auf die gewünschte Absicht oder Entität aus Beispiel-Äußerungen beziehen. Standardmäßig sind Features einfach die Wörter, aus denen Äußerungen bestehen. Begriffslisten bieten eine Möglichkeit, mehrere Wörter in ein neues Feature zu gruppieren; dadurch wird das maschinelle Lernen von weniger Beispielen besser generalisiert. Phrasenlisten sind standardmäßig global und gelten für alle maschinell gelernten Modelle, sie können jedoch auch mit bestimmten Absichten oder Entitäten verbunden werden. Sie können auch Absichten oder Entitäten als Features verwenden, um andere Absichten als Entitäten zu erkennen. Dies bietet Modularität, sodass Sie komplexere Konzepte aus einfacheren Bausteinen aufbauen können.

Hinweis

Beim maschinellen Lernen ist ein Feature ein eindeutiges Merkmal oder Attribut der Daten, die Ihr System untersucht oder von denen es lernt. Begriffslisten, Absichten und Entitäten können wie in diesem und den folgenden Abschnitten erläutert als Features verwendet werden.

Features können jeder gelernten Absicht oder Entität mithilfe des usesFeature Schlüsselworts hinzugefügt werden.

Hinzufügen einer Begriffsliste als Feature

Begriffslisten können als Feature zu Absichten oder Entitäten hinzugefügt werden Dies hilft diesen spezifischen Absichten oder Entitäten ohne Auswirkungen auf andere Absichten und Entitäten. Hier ist ein Beispiel dafür, wie eine Begriffsliste als Feature eines anderen Modells definiert werden kann:

> 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

Hinzufügen einer Entität oder Absicht als Feature

Es folgen Beispiele dafür, wie Absichten und Entitäten als Feature mit usesFeature hinzugefügt werden können:

> 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

Metadaten

Sie können Metadaten für Ihre LUIS-Anwendung oder QnA Maker-Wissensdatenbank in die .lu-Datei einbinden. Dadurch wird der Parser angewiesen, den LU-Inhalt ordnungsgemäß zu verarbeiten. Metadaten werden in der Regel am Anfang der .lu-Datei hinzugefügt.

So werden Konfigurations-Daten mit > !# definiert:

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

Beachten Sie, dass alle Informationen, die explizit über CLI-Argumente übergeben werden, die Informationen in der LU-Datei überschreiben.

> 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

Eine Beschreibung der im obigen Beispiel verwendeten Anwendungs-Metadatenwerte finden Sie in der folgenden Tabelle. Informationen zu app.settings in LUIS finden Sie unter [App- und Versionseinstellungen][luis-metadata] in der LUIS-Dokumentation.

Metadaten	Beschreibung
Name	Ihr Anwendungsname
VersionId	Der Name dieser bestimmten Version
Kultur	Die von Ihrer Anwendung verwendete Sprache
Schemaversion	Das LUIS-Schema wird jederzeit aktualisiert, wenn ein neues Feature oder eine neue Einstellung in LUIS hinzugefügt wird. Verwenden Sie die Schema-Versionsnummer, die Sie beim Erstellen oder Aktualisieren ihres LUIS-Modells verwendet haben.

Externe Referenzen

In den folgenden Abschnitten wird erläutert, wie Sie Referenzen auf lokale Dateien und URI erstellen.

Verweise auf lokale Dateien

Hinweis

Azure KI QnA Maker wird am 31. März 2025 eingestellt. Ab dem 01. Oktober 2022 können Sie keine neuen QnA Maker-Ressourcen oder Wissensdatenbanken mehr erstellen. Eine neuere Version der Funktionalität „Fragen und Antworten“ ist jetzt als Teil von Azure KI Language verfügbar.

Benutzerdefiniertes Fragen und Antworten, eine Azure KI Language-Funktion, ist die aktualisierte Version des QnA Maker-Diensts. Weitere Informationen zur Unterstützung von Fragen und Antworten im Bot Framework SDK finden Sie unter Natürliches Sprachverständnis.

Verweist auf die .lu-Datei. Folgen Sie der Markdown-Link-Syntax. Unterstützte Verweise:

• Verweis auf eine andere LU-Datei über [link name](<.lu file name>). Ein Verweis kann ein absoluter oder relativer Pfad aus der enthaltenden LU-Datei sein.
• Ein Verweis auf einen Ordner mit anderen .lu-Dateien wird wie folgt unterstützt:
  • [link name](<.lu file path>*): sucht nach .lu-Dateien unter dem angegebenen absoluten oder relativen Pfad
  • [link name](<.lu file path>**): sucht rekursiv nach .lu-Dateien unter dem angegebenen absoluten oder relativen Pfad einschließlich Unterordnern.
• Sie können auch Verweise zu Äußerungen hinzufügen, die in einer bestimmten Datei unter einem INTENT-Abschnitt oder als QnA-Paare definiert sind.
  • [link name](<.lu file path>#<INTENT-NAME>): findet alle Äußerungen unter <INTENT-NAME> in der .lu-Datei und fügt sie der Liste der Äußerungen hinzu, in der der Verweis angegeben ist.
  • [link name](<.lu file path>#<INTENT-NAME>*utterances*): findet alle Äußerungen (keine Muster) unter <INTENT-NAME> in der .lu-Datei und fügt sie der Liste der Äußerungen hinzu, in der der Verweis angegeben ist.
  • [link name](<.lu file path>#<INTENT-NAME>*patterns*): findet alle Muster (keine Äußerungen) unter <INTENT-NAME> in der .lu-Datei und fügt sie der Liste der Muster hinzu, in der der Verweis angegeben ist.
  • [link name](<.lu file path>#*utterances*): findet alle Äußerungen in der .lu-Datei und fügt sie der Liste der Äußerungen hinzu, in der der Verweis angegeben ist.
  • [link name](<.lu file path>#*patterns*): findet alle Muster in der .lu-Datei und fügt sie der Liste der Äußerungen hinzu, in der der Verweis angegeben ist.
  • [link name](<.lu file path>#*utterancesAndPatterns*): findet alle Äußerungen und Muster in der .lu-Datei und fügt sie der Liste der Äußerungen hinzu, in der der Verweis angegeben ist.
  • [link name](<.qna file path>#$name?): findet alle Änderungen gegenüber der spezifischen Änderungsdefinition im .qna-Inhalt und fügt sie der Liste der Äußerungen hinzu, in der der Verweis angegeben ist.
  • [link name](<.qna file path>#*alterations*?): findet alle Änderungen am .qna-Inhalt und fügt sie der Liste der Äußerungen hinzu, in der der Verweis angegeben ist.
  • [link name](<.qna file path>#?question-to-find?): findet alle Variationsfragen zur spezifischen Frage und fügt sie der Liste der Äußerungen hinzu, in der der Verweis angegeben ist. Beachten Sie, dass alle Leerzeichen in Ihrer Frage durch das Zeichen - ersetzt werden müssen.
  • [link name](<.qna file path>#*answers*?): findet alle Antworten und fügt sie der Liste der Äußerungen hinzu, in der der Verweis angegeben ist.

Im Folgenden finden Sie ein Beispiel der zuvor erwähnten Verweise:

> 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.

URI-Verweise

Im Folgenden finden Sie Beispiele für das Erstellen von URI-Verweisen:

> 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*)

Zusätzliche Informationen

• Weitere Informationen zu QNA-Dateien finden Sie unter Dateiformat „.qna“.