Test per DevOps LUIS

  • Articolo

Importante

LUIS verrà ritirato il 1 ottobre 2025 e a partire dal 1 aprile 2023 non sarà più possibile creare nuove risorse LUIS. Si consiglia di eseguire la migrazione delle applicazioni LUIS a comprensione del linguaggio di conversazione per sfruttare appieno il supporto continuativo per i prodotti e le funzionalità multilingue.

I tecnici software che sviluppano un'app LUIS (Language Understanding) possono applicare procedure DevOps per il controllo del codice sorgente, le compilazioni automatizzate, i test e la gestione delle versioni seguendo queste linee guida.

Nelle metodologie di sviluppo software Agile, il test svolge un ruolo fondamentale nella creazione di software di qualità. Ogni modifica significativa a un'app LUIS deve essere accompagnata da test progettati per testare la nuova funzionalità che lo sviluppatore sta compilando nell'app. Questi test vengono controllati nel repository del codice sorgente insieme all'origine .lu dell'app LUIS. L'implementazione della modifica viene completata quando l'app soddisfa i test.

I test sono una parte fondamentale dei flussi di lavoro CI/CD. Quando le modifiche apportate a un'app LUIS vengono proposte in una richiesta pull o dopo che le modifiche vengono unite nel ramo principale, i flussi di lavoro ci devono eseguire i test per verificare che gli aggiornamenti non hanno causato regressioni.

Come eseguire unit test e test batch

Esistono due tipi diversi di test per un'app LUIS che è necessario eseguire nei flussi di lavoro di integrazione continua:

  • Unit test : test relativamente semplici che verificano la funzionalità chiave dell'app LUIS. Uno unit test viene superato quando la finalità prevista e le entità previste vengono restituite per una determinata espressione di test. Per completare correttamente l'esecuzione del test, tutti gli unit test devono essere superati.
    Questo tipo di test è simile ai test interattivi che è possibile eseguire nel portale LUIS.

  • Test batch: il test batch è un test completo sul modello con training corrente per misurare le prestazioni. A differenza degli unit test, il test batch non viene superato|test non superato. L'aspettativa con i test batch non è che ogni test restituirà la finalità prevista e le entità previste. Un test batch consente invece di visualizzare l'accuratezza di ogni finalità ed entità nell'app e consente di confrontare nel tempo man mano che si apportano miglioramenti.
    Questo tipo di test è identico a quello dei test batch che è possibile eseguire in modo interattivo nel portale LUIS.

È possibile usare unit test dall'inizio del progetto. Il test batch è davvero di valore dopo aver sviluppato lo schema dell'app LUIS e si sta lavorando per migliorarne l'accuratezza.

Sia per gli unit test che per i test batch, assicurarsi che le espressioni di test vengano mantenute separate dalle espressioni di training. Se si esegue il test sugli stessi dati su cui si esegue il training, si otterrà l'impressione falsa che l'app stia funzionando correttamente quando si sta eseguendo l'overfitting ai dati di test. I test devono essere non visualizzati dal modello per verificare il livello di generalizzazione.

Scrittura di test

Quando si scrive un set di test, per ogni test è necessario definire:

  • Espressione di test
  • Finalità prevista
  • Entità previste.

Usare la sintassi del file batch LUIS per definire un gruppo di test in un file in formato JSON. Ad esempio:

[
  {
    "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
        }
    ]
  }
]

Alcuni strumenti di test, ad esempio NLU. DevOps supporta anche i file di test in formato LUDown.

Progettazione di unit test

Gli unit test devono essere progettati per testare le funzionalità di base dell'app LUIS. In ogni iterazione, o sprint, dello sviluppo di app, devi scrivere un numero sufficiente di test per verificare che la funzionalità chiave che stai implementando in tale iterazione funzioni correttamente.

In ogni unit test, per un'espressione di test specifica, è possibile:

  • Verificare che venga restituita la finalità corretta
  • Verificare che vengano restituite le entità 'chiave', quelle critiche per la soluzione.
  • Verificare che il punteggio di stima per finalità ed entità superi una soglia definita dall'utente. Ad esempio, è possibile decidere che si consideri solo che un test è stato superato se il punteggio di stima per la finalità e per le entità chiave supera 0,75.

Negli unit test è consigliabile verificare che le entità chiave siano state restituite nella risposta di stima, ma ignorare eventuali falsi positivi. I falsi positivi sono entità trovate nella risposta di stima, ma che non sono definite nei risultati previsti per il test. Ignorando i falsi positivi, ciò rende meno oneroso creare unit test, consentendo comunque di concentrarsi sul test che i dati chiave per la soluzione vengono restituiti in una risposta di stima.

Suggerimento

NLU . Lo strumento DevOps supporta tutte le esigenze di test LUIS. Se compare usato in modalità unit test, il comando asserisce che tutti i test superano e ignoreranno i risultati falsi positivi per le entità che non sono etichettate nei risultati previsti.

Progettazione di test batch

I set di test batch devono contenere un numero elevato di test case, progettati per testare tutte le finalità e tutte le entità nell'app LUIS. Per informazioni sulla definizione di un set di test batch, vedere Test batch nel portale LUIS.

Esecuzione di test

Il portale LUIS offre funzionalità utili per il test interattivo:

  • Il test interattivo consente di inviare un'espressione di esempio e ottenere una risposta di finalità ed entità riconosciute da LUIS. Verificare l'esito positivo del test tramite ispezione visiva.

  • Il test batch usa un file di test batch come input per convalidare la versione con training attiva per misurare l'accuratezza della stima. Un test batch consente di visualizzare l'accuratezza di ogni finalità ed entità nella versione attiva, visualizzando i risultati con un grafico.

Esecuzione di test in un flusso di lavoro di compilazione automatizzato

Le funzionalità di test interattive nel portale LUIS sono utili, ma per DevOps, i test automatizzati eseguiti in un flusso di lavoro CI/CD comportano determinati requisiti:

  • Gli strumenti di test devono essere eseguiti in un passaggio del flusso di lavoro in un server di compilazione. Ciò significa che gli strumenti devono essere in grado di essere eseguiti nella riga di comando.
  • Gli strumenti di test devono essere in grado di eseguire un gruppo di test su un endpoint e verificare automaticamente i risultati previsti rispetto ai risultati effettivi.
  • Se i test hanno esito negativo, gli strumenti di test devono restituire un codice di stato per arrestare il flusso di lavoro e "non riuscire la compilazione".

LUIS non offre uno strumento da riga di comando o un'API di alto livello che offre queste funzionalità. È consigliabile usare la NLU. Strumento DevOps per eseguire test e verificare i risultati, sia nella riga di comando che durante i test automatizzati all'interno di un flusso di lavoro CI/CD.

Le funzionalità di test disponibili nel portale LUIS non richiedono un endpoint pubblicato e fanno parte delle funzionalità di creazione LUIS. Quando si implementano test in un flusso di lavoro di compilazione automatizzato, è necessario pubblicare la versione dell'app LUIS da testare in un endpoint in modo che gli strumenti di test, ad esempio NLU. DevOps può inviare richieste di stima come parte del test.

Suggerimento

  • Se si implementa una soluzione di test personalizzata e si scrive codice per inviare espressioni di test a un endpoint, tenere presente che se si usa la chiave di creazione LUIS, la frequenza delle transazioni consentita è limitata a 5TPS. Limitare la frequenza di invio o usare invece una chiave di stima.
  • Quando si inviano query di test a un endpoint, ricordarsi di usare log=false nella stringa di query della richiesta di stima. In questo modo, le espressioni di test non vengono registrate da LUIS e finiscono nell'elenco di revisione delle espressioni endpoint presentate dalla funzionalità di apprendimento attivo LUIS e, di conseguenza, vengono aggiunte accidentalmente alle espressioni di training dell'app.

Esecuzione di unit test nella riga di comando e nei flussi di lavoro CI/CD

È possibile usare la NLU. Pacchetto DevOps per eseguire test nella riga di comando:

  • Usare la NLU. Comando di test DevOps per inviare test da un file di test a un endpoint e per acquisire i risultati effettivi della stima in un file.
  • Usare la NLU. Il comando DevOps compare per confrontare i risultati effettivi con i risultati previsti definiti nel file di test di input. Il compare comando genera l'output del test NUnit e, se usato in modalità unit test usando il --unit-test flag , asserisce che tutti i test superino.

Esecuzione di test batch nella riga di comando e nei flussi di lavoro CI/CD

È anche possibile usare l'NLU. Pacchetto DevOps per eseguire test batch nella riga di comando.

  • Usare la NLU. Comando di test DevOps per inviare test da un file di test a un endpoint e per acquisire i risultati effettivi della stima in un file, come con gli unit test.
  • Usare la NLU. Confronto del comando in modalità test delle prestazioni per misurare le prestazioni dell'app È anche possibile confrontare le prestazioni dell'app con un benchmark delle prestazioni di base, ad esempio i risultati del commit più recente a main o alla versione corrente. In modalità test prestazioni il compare comando genera l'output del test NUnit e i risultati dei test batch in formato JSON.

Training non deterministico LUIS e effetto sui test

Quando LUIS esegue il training di un modello, ad esempio una finalità, richiede dati positivi, ovvero le espressioni di training etichettate fornite per eseguire il training dell'app per il modello e i dati negativi, dati non validi dell'utilizzo di tale modello. Durante il training, LUIS compila i dati negativi di un modello da tutti i dati positivi forniti per gli altri modelli, ma in alcuni casi che possono produrre uno squilibrio dei dati. Per evitare questo squilibrio, LUIS esegue un sottoinsieme dei dati negativi in modo non deterministico per ottimizzare un set di training bilanciato migliore, migliorare le prestazioni del modello e tempi di training più rapidi.

Il risultato di questo training non deterministico è che è possibile ottenere una risposta di stima leggermente diversa tra sessioni di training diverse, in genere per finalità e/o entità in cui il punteggio di stima non è elevato.

Se si vuole disabilitare il training non deterministico per le versioni dell'app LUIS create allo scopo di testare, usare l'API Delle impostazioni della versione con l'impostazione UseAllTrainingData impostata su true.

Passaggi successivi