Dela via

Testning för LUIS DevOps

  • Artikel

Viktigt!

LUIS dras tillbaka den 1 oktober 2025 och från och med den 1 april 2023 kommer du inte att kunna skapa nya LUIS-resurser. Vi rekommenderar att du migrerar dina LUIS-program till förståelse för konversationsspråk för att dra nytta av fortsatt produktsupport och flerspråkiga funktioner.

Programvarutekniker som utvecklar en LUIS-app (Language Understanding) kan tillämpa DevOps-metoder kring källkontroll, automatiserade versioner, testning och versionshantering genom att följa dessa riktlinjer.

I agila metoder för programvaruutveckling spelar testning en viktig roll när det gäller att skapa programvara av hög kvalitet. Varje betydande ändring av en LUIS-app bör åtföljas av tester som utformats för att testa de nya funktioner som utvecklaren skapar i appen. Dessa tester checkas in på din källkodslagringsplats tillsammans med källan för .lu LUIS-appen. Implementeringen av ändringen slutförs när appen uppfyller testerna.

Tester är en viktig del av CI/CD-arbetsflöden. När ändringar i en LUIS-app föreslås i en pull-begäran (PR) eller efter att ändringarna har sammanfogats till din huvudgren, bör CI-arbetsflöden köra testerna för att kontrollera att uppdateringarna inte har orsakat några regressioner.

Så här gör du enhetstestning och Batch-testning

Det finns två olika typer av tester för en LUIS-app som du behöver utföra i arbetsflöden för kontinuerlig integrering:

  • Enhetstester – Relativt enkla tester som verifierar huvudfunktionerna i luis-appen. Ett enhetstest godkänns när den förväntade avsikten och de förväntade entiteterna returneras för ett givet testyttrande. Alla enhetstester måste godkännas för att testkörningen ska slutföras.
    Den här typen av testning liknar interaktiva tester som du kan göra i LUIS-portalen.

  • Batchtester – Batch-testning är ett omfattande test på din aktuella tränade modell för att mäta dess prestanda. Till skillnad från enhetstester godkänns inte batchtestning|misslyckas. Förväntningarna med batchtestning är inte att varje test returnerar den förväntade avsikten och förväntade entiteter. I stället hjälper ett batchtest dig att visa noggrannheten för varje avsikt och entitet i din app och hjälper dig att jämföra med tiden när du gör förbättringar.
    Den här typen av testning är samma som Batch-testningen som du kan utföra interaktivt i LUIS-portalen.

Du kan använda enhetstestning från början av projektet. Batchtestning är egentligen bara av värde när du har utvecklat schemat för luis-appen och du arbetar med att förbättra dess noggrannhet.

För både enhetstester och batchtester kontrollerar du att dina testyttranden hålls åtskilda från dina träningsyttranden. Om du testar samma data som du tränar på får du ett falskt intryck av att appen fungerar bra när den bara överanpassar testdata. Testerna måste vara osynliga av modellen för att testa hur väl den generaliserar.

Skriva tester

När du skriver en uppsättning tester måste du definiera följande för varje test:

  • Testyttrande
  • Förväntad avsikt
  • Förväntade entiteter.

Använd syntaxen för LUIS-batchfilen för att definiera en grupp tester i en JSON-formaterad fil. Till exempel:

[
  {
    "text": "example utterance goes here",
    "intent": "intent name goes here",
    "entities":
    [
        {
            "entity": "entity name 1 goes here",
            "startPos": 14,
            "endPos": 23
        },
        {
            "entity": "entity name 2 goes here",
            "startPos": 14,
            "endPos": 23
        }
    ]
  }
]

Vissa testverktyg, till exempel NLU. DevOps har också stöd för LUDown-formaterade testfiler.

Utforma enhetstester

Enhetstester bör utformas för att testa kärnfunktionerna i luis-appen. I varje iteration, eller sprint, av din apputveckling bör du skriva ett tillräckligt antal tester för att kontrollera att de viktiga funktioner som du implementerar i iterationen fungerar korrekt.

För ett givet testyttrande i varje enhetstest kan du:

  • Testa att rätt avsikt returneras
  • Testa att "nyckel"-entiteterna – de som är viktiga för din lösning – returneras.
  • Testa att förutsägelsepoängen för avsikt och entiteter överskrider ett tröskelvärde som du definierar. Du kan till exempel bestämma att du bara ska överväga att ett test har godkänts om förutsägelsepoängen för avsikten och för dina nyckelentiteter överskrider 0,75.

I enhetstester är det en bra idé att testa att dina nyckelentiteter har returnerats i förutsägelsesvaret, men att ignorera falska positiva identifieringar. Falska positiva identifieringar är entiteter som hittas i förutsägelsesvaret men som inte definieras i de förväntade resultaten för testet. Genom att ignorera falska positiva identifieringar blir det mindre betungande att skapa enhetstester samtidigt som du kan fokusera på att testa att de data som är nyckeln till lösningen returneras i ett förutsägelsesvar.

Dricks

NLU . DevOps-verktyget stöder alla dina LUIS-testbehov. Kommandot compare när det används i enhetstestläge kontrollerar att alla tester godkänns och ignorerar falska positiva resultat för entiteter som inte är märkta i det förväntade resultatet.

Utforma Batch-tester

Batch-testuppsättningar bör innehålla ett stort antal testfall som är utformade för att testa i alla avsikter och alla entiteter i LUIS-appen. Mer information om hur du definierar en batchtestuppsättning finns i Batch-testning i LUIS-portalen .

Köra tester

LUIS-portalen erbjuder funktioner som hjälper dig med interaktiv testning:

  • Med interaktiv testning kan du skicka ett exempelyttrande och få svar på LUIS-identifierade avsikter och entiteter. Du verifierar att testet har slutförts genom visuell kontroll.

  • Batch-testning använder en batchtestfil som indata för att verifiera din aktiva tränade version för att mäta dess förutsägelsenoggrannhet. Ett batchtest hjälper dig att visa noggrannheten för varje avsikt och entitet i din aktiva version och visa resultat med ett diagram.

Köra tester i ett automatiserat byggarbetsflöde

De interaktiva testfunktionerna i LUIS-portalen är användbara, men för DevOps medför automatiserad testning som utförs i ett CI/CD-arbetsflöde vissa krav:

  • Testverktyg måste köras i ett arbetsflödessteg på en byggserver. Det innebär att verktygen måste kunna köras på kommandoraden.
  • Testverktygen måste kunna köra en grupp tester mot en slutpunkt och automatiskt verifiera de förväntade resultaten mot de faktiska resultaten.
  • Om testerna misslyckas måste testverktygen returnera en statuskod för att stoppa arbetsflödet och "misslyckas med bygget".

LUIS erbjuder inte något kommandoradsverktyg eller ett högnivå-API som erbjuder dessa funktioner. Vi rekommenderar att du använder NLU. DevOps-verktyget för att köra tester och verifiera resultat, både på kommandoraden och under automatiserad testning i ett CI/CD-arbetsflöde.

De testfunktioner som är tillgängliga i LUIS-portalen kräver ingen publicerad slutpunkt och är en del av LUIS-redigeringsfunktionerna. När du implementerar testning i ett automatiserat byggarbetsflöde måste du publicera LUIS-appversionen som ska testas till en slutpunkt så att testverktyg som NLU. DevOps kan skicka förutsägelsebegäranden som en del av testningen.

Dricks

  • Om du implementerar din egen testlösning och skriver kod för att skicka testyttranden till en slutpunkt ska du komma ihåg att om du använder LUIS-redigeringsnyckeln är den tillåtna transaktionsfrekvensen begränsad till 5TPS. Begränsa antingen sändningshastigheten eller använd en förutsägelsenyckel i stället.
  • När du skickar testfrågor till en slutpunkt ska du komma ihåg att använda log=false i frågesträngen för din förutsägelsebegäran. Detta säkerställer att dina testyttranden inte loggas av LUIS och hamnar i granskningslistan för slutpunktsyttranden som presenteras av luis active learning-funktionen och därför oavsiktligt läggs till i appens träningsyttranden.

Köra enhetstester på kommandoraden och i CI/CD-arbetsflöden

Du kan använda NLU. DevOps-paket för att köra tester på kommandoraden:

  • Använd NLU. DevOps-testkommando för att skicka tester från en testfil till en slutpunkt och för att samla in de faktiska förutsägelseresultaten i en fil.
  • Använd NLU. DevOps jämför kommandot för att jämföra de faktiska resultaten med de förväntade resultaten som definierats i indatatestfilen. Kommandot compare genererar NUnit-testutdata, och när det används i enhetstestläge med hjälp av --unit-test flaggan kontrollerar du att alla tester godkänns.

Köra Batch-tester på kommandoraden och i CI/CD-arbetsflöden

Du kan också använda NLU. DevOps-paket för att köra batchtester på kommandoraden.

  • Använd NLU. DevOps-testkommando för att skicka tester från en testfil till en slutpunkt och för att samla in de faktiska förutsägelseresultaten i en fil, samma som med enhetstester.
  • Använd NLU. DevOps jämför kommandot i prestandatestläge för att mäta appens prestanda Du kan också jämföra appens prestanda med ett prestandamått för baslinje, till exempel resultatet från den senaste incheckningen till huvudversionen eller den aktuella versionen. I läget Prestandatest compare genererar kommandot NUnit-testutdata och batchtestresultat i JSON-format.

LUIS-icke-deterministisk träning och effekten på testning

När LUIS tränar en modell, till exempel en avsikt, behöver den både positiva data – de märkta träningsyttranden som du har angett för att träna appen för modellen – och negativa data – data som inte är giltiga exempel på användningen av modellen. Under träningen skapar LUIS negativa data för en modell från alla positiva data som du har angett för de andra modellerna, men i vissa fall kan det leda till obalans i data. För att undvika den här obalansen tar LUIS exempel på en delmängd av negativa data på ett icke-deterministiskt sätt för att optimera för en bättre balanserad träningsuppsättning, bättre modellprestanda och snabbare träningstid.

Resultatet av den här icke-deterministiska träningen är att du kan få ett något annorlunda förutsägelsesvar mellan olika utbildningssessioner, vanligtvis för avsikter och/eller entiteter där förutsägelsepoängen inte är hög.

Om du vill inaktivera icke-deterministisk träning för de LUIS-appversioner som du skapar i syfte att testa använder du API:et Versionsinställningar med UseAllTrainingData inställningen inställd på true.

Nästa steg