Iterativ appdesign för LUIS

  • Artikel
  • 5 minuter för att läsa

En Language Understanding (LUIS)-app lär sig och fungerar mest effektivt med iteration. Här är en typisk iterationscykel:

  • Skapa ny version
  • Redigera LUIS-appschemat. Du måste bland annat:
    • Avsikter med exempelyttranden
    • Entiteter
    • Funktioner
  • Träna, testa och publicera
    • Testa vid förutsägelseslutpunkten för aktiv inlärning
  • Samla in data från slutpunktsfrågor

Redigeringscykel

Skapa ett LUIS-schema

Ett appschema definierar vad användaren frågar efter (avsikten eller avsikten ) och vilka delar av avsikten som tillhandahåller information (kallas entiteter ) som används för att fastställa svaret.

Appschemat måste vara specifikt för appdomänerna för att fastställa ord och fraser som är relevanta, samt för att fastställa typisk ordordning.

Exempelyttranden representerar användarindata, till exempel identifierat tal eller text, som appen förväntar sig vid körning.

Schemat kräver avsikter och bör ha entiteter.

Exempelschema för avsikter

Det vanligaste schemat är ett avsiktsschema ordnat med avsikter. Den här typen av schema använder LUIS för att fastställa en användares avsikt.

Avsiktsschematypen kan ha entiteter om det hjälper LUIS att fastställa användarens avsikt. Till exempel hjälper en leveransentitet (som en maskininlärningsfunktion till en avsikt) LUIS att fastställa en leverans avsikt.

Exempelschema för entiteter

Ett entitetsschema fokuserar på entiteter, vilket är de data som extraheras från användaryttranden. Om en användare till exempel skulle säga "I'd like to order three pizzas" (Jag vill beställa tre pizza). Det finns två entiteter som extraheras: tre och pizza. Dessa används för att uppfylla avsikten, som var att göra en beställning.

För ett entitetsschema är avsikten med yttranden mindre viktig för klientprogrammet.

Exempel på ett blandat schema

Det kraftfullaste och mognaste schemat är ett avsiktsschema med en fullständig mängd entiteter och funktioner. Det här schemat kan börja antingen som en avsikt eller ett entitetsschema och växa så att det omfattar begrepp för båda, eftersom klientprogrammet behöver dessa uppgifter.

Lägga till exempelyttranden i avsikter

LUIS behöver några exempelyttranden i varje avsikt. Exempelyttrandena behöver tillräckligt med variation av ordval och ordordning för att kunna avgöra vilken avsikt som yttrandena är avsedda för.

Varning

Lägg inte till exempelyttranden i grupp. Börja med 15 till 30 specifika och varierande exempel.

Varje exempelyttrande måste ha nödvändiga data för att extrahera utformade och märkta med entiteter .

Nyckelelement Syfte
Avsikt Klassificera användaryttranden i en enda avsikt eller åtgärd. Exempel är BookFlight och GetWeather .
Entitet Extrahera data från yttranden som krävs för att slutföra avsikten. Exempel är datum och tid för resan och plats.

En LUIS-app kan utformas för att ignorera yttranden som inte är relevanta för en appdomän genom att tilldela yttrandena till avsikten None.

Testa och träna din app

När du har 15 till 30 olika exempelyttranden i varje avsikt, med de entiteter som krävs märkta, måste du testa och träna LUIS-appen.

Publicera till en förutsägelseslutpunkt

LUIS-appen måste publiceras så att den är tillgänglig för dig i listan med regioner för förutsägelseslutpunkter.

Testa ditt publicerade program

Du kan testa din publicerade LUIS-app från HTTPS-slutpunkten för förutsägelse. När du testar från förutsägelseslutpunkten kan LUIS välja yttranden med låg konfidens för granskning.

Skapa en ny version för varje cykel

Varje version är en ögonblicksbild i tid för LUIS-appen. Innan du gör ändringar i appen skapar du en ny version. Det är enklare att gå tillbaka till en äldre version än att försöka ta bort avsikter och yttranden till ett tidigare tillstånd.

Versions-ID:t består av tecken, siffror eller "." och får inte vara längre än 10 tecken.

Den första versionen (0.1) är den aktiva standardversionen.

Börja med att klona en befintlig version

Klona en befintlig version som ska användas som startpunkt för varje ny version. När du har klonat en version blir den nya versionen den aktiva versionen.

Publiceringsplatser

Du kan publicera till antingen fasen och/eller produktionsplatserna. Varje fack kan ha olika versioner eller samma version. Detta är användbart för att verifiera ändringar innan du publicerar till produktion, vilket är tillgängligt för robotar eller andra LUIS-anropande appar.

Tränade versioner är inte automatiskt tillgängliga i LUIS-appens slutpunkt. Du måste publicera eller publicera om en version för att den ska vara tillgänglig på LUIS-appens slutpunkt. Du kan publicera till Mellanlagring och Produktion, vilket ger dig två versioner av appen som är tillgängliga på slutpunkten. Om fler versioner av appen måste vara tillgängliga på en slutpunkt bör du exportera versionen och importera den igen till en ny app. Den nya appen har ett annat app-ID.

Importera en version

En version kan importeras som en ny:

  • App, med ett nytt app-ID
  • Version av en befintlig app

Den versionen blir den aktiva versionen och använder versions-ID:t versionId i appfilens egenskap.

Exportera en version

En version kan exporteras från LUIS-portalen på appnivå eller versionsnivå:

  • Appnivå – välj app Mina appar sidan och välj sedan Exportera
  • Versionsnivå – välj applänken på Mina appar, välj Hantera, välj Versioner

Den enda skillnaden är att appnivån, den exporterade versionen är den aktiva versionen medan du på versionsnivå kan välja vilken version som helst som ska exporteras på Inställningar sidan.

Den exporterade filen innehåller inte:

  • maskininlärningsinformation eftersom appen tränas om efter att den har importerats
  • Deltagarinformation

Exportera en version från LUIS-portalen för att backa upp LUIS-appschemat.

Hantera deltagarändringar med versioner och deltagare

LUIS använder begreppet deltagare i en app genom att tillhandahålla behörigheter på Azure-resursnivå. Kombinera det här konceptet med versionshantering för att tillhandahålla riktat samarbete.

Använd följande metoder för att hantera bidragsgivares ändringar i din app.

Hantera flera versioner i samma app

Börja med att klona från en basversion för varje författare.

Varje författare gör ändringar i sin egen version av appen. När författaren är nöjd med modellen exporterar du de nya versionerna till JSON-filer.

Exporterade appar, .json eller .lu filer, kan jämföras för ändringar. Kombinera filerna för att skapa en enda fil med den nya versionen. Ändra egenskapen versionId för att beteckna den nya sammanfogade versionen. Importera den versionen till den ursprungliga appen.

Med den här metoden kan du ha en aktiv version, en fasversion och en publicerad version. Du kan jämföra resultaten från den aktiva versionen med en publicerad version (fas eller produktion) i det interaktiva testfönstret.

Hantera flera versioner som appar

Exportera basversionen. Varje författare importerar versionen. Den person som importerar appen är ägare till versionen. När de är klara med att ändra appen exporterar du versionen.

Exporterade appar är JSON-formaterade filer som kan jämföras med basexporten för ändringar. Kombinera filerna för att skapa en enda JSON-fil med den nya versionen. Ändra egenskapen versionId i JSON för att beteckna den nya sammanfogade versionen. Importera den versionen till den ursprungliga appen.

Läs mer om redigering av bidrag från medarbetare.

Granska slutpunktsyttranden för att påbörja den nya iterativa cykeln

När du är klar med en iterationscykel kan du upprepa processen. Börja med att granska LUIS-yttranden för förutsägelseslutpunkter markerade med låg konfidens. Kontrollera dessa yttranden för både korrekt förutsagd avsikt och korrekt och fullständig entitet som extraherats. När du har granskat och accepterat ändringarna bör granskningslistan vara tom.

Nästa steg

Lär dig begrepp om samarbete.