Condividi tramite

Test per DevOps LUIS

  • Articolo

Importante

LUIS verrà ritirato il 1 ottobre 2025 e a partire dal 1 aprile 2023 non è più possibile creare nuove risorse LUIS. È consigliabile eseguire la migrazione delle applicazioni LUIS a comprensione del linguaggio conversazionale per beneficiare del supporto continuo del prodotto e delle 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 Agile Software Development, i test svolgono un ruolo fondamentale nella creazione di software di qualità. Ogni modifica significativa apportata a un'app LUIS deve essere accompagnata da test progettati per verificare le nuove funzionalità che lo sviluppatore crea nell'app. Questi test vengono inseriti nel repository del codice sorgente insieme al sorgente .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 di CI/CD. Quando le modifiche apportate a un'applicazione LUIS vengono proposte in una richiesta pull (PR) o dopo che le modifiche sono state unite nel ramo principale, i flussi di lavoro CI devono eseguire i test per verificare che gli aggiornamenti non abbiano causato regressioni.

Come eseguire i test unitari e i 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 le funzionalità chiave dell'app LUIS. Un unit test viene superato quando la finalità 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 in batch: il test in batch è un test completo sul modello con training corrente per misurare le prestazioni. A differenza degli unit test, il test in batch non è un test di tipo superato|non superato. L'aspettativa con i test in batch non è che ogni test restituisca la finalità e le entità previste. Un test in batch consente invece di visualizzare l'accuratezza di ogni finalità ed entità nell'app e consente di confrontare nel tempo i miglioramenti apportati.
    Questo tipo di test è uguale al Test in batch che è possibile eseguire in modo interattivo nel portale LUIS.

È possibile usare il testing unità dall'inizio del progetto. Il test in batch è davvero utile solo quando si è sviluppato lo schema della propria app LUIS e si sta lavorando per migliorarne l'accuratezza.

Sia per gli unit test che per i test in batch, assicurarsi che le espressioni di test vengano mantenuti separati da quelle di training. Se si esegue il test sugli stessi dati su cui si esegue il training, si avrà la falsa impressione che l'app abbia stia funzionando correttamente, mentre si tratta solo dell'overfitting dei dati di test. I test devono essere non visti 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 supportano anche i file di test in formato LUDown.

Progettazione di unit test

Gli unit test devono essere progettati per verificare la funzionalità di base dell'app LUIS. In ogni iterazione o sprint dello sviluppo della propria app, è necessario scrivere un numero sufficiente di test per verificare che la funzionalità chiave da implementare 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 vostra soluzione.
  • Verificare che il punteggio di previsione per le finalità e le entità sia superiore a una soglia definita dall'utente. Ad esempio, è possibile decidere di considerare superato un test solo se il punteggio di previsione per la finalità e per le entità chiave è superiore a 0,75.

Negli unit test è consigliabile verificare che le entità chiave siano state restituite nella risposta di previsione, ma ignorare eventuali falsi positivi. I falsi positivi sono entità che vengono trovate nella risposta di previsione, ma che non sono definite nei risultati previsti per il test. Ignorando i falsi positivi, si rende meno onerosa la creazione di unit test, consentendo al contempo di concentrarsi sul test che i dati chiave per la soluzione vengano restituiti in una risposta di previsione.

Suggerimento

Lo strumento NLU.DevOps supporta tutte le esigenze di test LUIS. Il comando compare se usato in modalità unit test asserisce che tutti i test vengono superati e ignorerà i risultati falsi positivi per le entità che non sono etichettate nei risultati previsti.

Progettazione di Test in batch

I set di test in batch devono contenere un numero elevato di test case, progettati per testare tutte le finalità e tutte le entità dell'app LUIS. Per informazioni sulla definizione di un set di test in batch, vedere Test in 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. Il successo del test viene verificato tramite un'ispezione visiva.

  • Il test in batch usa un file di test in batch come input per convalidare la versione con training attiva e misurarne l'accuratezza di previsione. Un test batch consente di visualizzare l'accuratezza di ogni finalità ed entità nella versione attiva, mostrando i risultati con un grafico.

Esecuzione di test in un flusso di compilazione automatizzato

Le funzioni di test interattivo del portale LUIS sono utili, ma per DevOps il test automatizzato eseguito in un flusso di lavoro CI/CD comporta 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 poter essere eseguiti nella riga di comando.
  • Gli strumenti di test devono essere in grado di eseguire un gruppo di test su un endpoint e di verificare automaticamente i risultati previsti rispetto a quelli effettivi.
  • Se i test hanno esito negativo, gli strumenti di test devono restituire un codice di stato per arrestare il flusso di lavoro e la "non riuscita della compilazione".

LUIS non offre uno strumento a riga di comando o un'API di alto livello che offra queste funzionalità. È consigliabile usare lo strumento NLU.DevOps per eseguire i 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 di LUIS. Quando si implementa il test in un flusso di lavoro di compilazione automatizzato, è necessario pubblicare la versione dell'app LUIS da testare su un endpoint, in modo che gli strumenti di test come NLU.DevOps possano inviare richieste di previsione come parte del test.

Suggerimento

  • Se si implementa una propria soluzione di test 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 di transazioni consentita è limitata a 5TPS. Limitare la frequenza di invio o usare invece una chiave di previsione.
  • Quando si inviano query di test a un endpoint, ricordarsi di usare log=false nella stringa di query della richiesta di previsione. In questo modo si evita che le espressioni di test vengano registrate da LUIS e finiscano nell'elenco di revisione degli enunciati dell'endpoint presentato dalla funzione di apprendimento attivo di LUIS e, di conseguenza, vengano accidentalmente aggiunti alle espressioni di training dell'app.

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

È possibile usare il pacchetto NLU.DevOps per eseguire i test nella riga di comando:

  • Usare il comando test di NLU.DevOps per inviare i test da un file di test a un endpoint e per acquisire i risultati effettivi della previsione in un file.
  • Usare il comando confronta di NLU.DevOps per confrontare i risultati effettivi con i risultati previsti definiti nel file di test di input. Il comando compare genera l'output di test NUnit e, se usato in modalità unit test tramite il flag --unit-test, asserirà che tutti i test sono stati superati.

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

È anche possibile usare il pacchetto NLU.DevOps per eseguire test in batch nella riga di comando.

  • Usare il comando test di NLU.DevOps test per inviare i test da un file di test a un endpoint e per acquisire i risultati effettivi della previsione in un file, come per gli unit test.
  • Usare il comando confronta di NLU.DevOps in modalità di 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 al rilascio principale o alla versione corrente. In modalità test delle prestazioni, il comando compare genera l'output del test NUnit e i risultati dei test in batch in formato JSON.

Il training non deterministico LUIS e l'effetto sui test

Quando LUIS esegue il training di un modello, ad esempio una finalità, richiede sia di dati positivi, ovvero le espressioni di training etichettate fornite dall'utente per eseguire il training dell'app per il modello e i dati negativi, dati che non sono esempi validi dell'uso di tale modello. Durante il training, LUIS compila i dati negativi di un modello a partire da tutti i dati positivi forniti dall'utente per gli altri modelli, ma in alcuni casi ciò può 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 più equilibrato, migliorare le prestazioni del modello e accelerare i tempi di training.

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

Per disabilitare il training non deterministico per le versioni dell'app LUIS che si creano a scopo di test, usare l'API per le impostazioni della versione con l'impostazioneUseAllTrainingData su true.

Passaggi successivi