Pianificare l'app LUIS

Importante

LUIS verrà ritirato il 1 ottobre 2025 e a partire dal 1 aprile 2023 non è 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.

Uno schema dell'app LUIS (Language Understanding) contiene finalità ed entità pertinenti al dominio soggetto. Le finalità classificano le espressioni utente, mentre le entità estraggono i dati dalle espressioni utente. Finalità ed entità pertinenti al dominio soggetto. Le finalità classificano le espressioni utente.

La capacità di apprendimento e le prestazioni di un'app LUIS sono più efficienti quando viene sviluppata in modo iterativo. Ecco un tipico ciclo di iterazione:

1. Creare una nuova versione
2. Modificare lo schema dell'app LUIS. ad esempio:
   • Finalità con espressioni di esempio
   • Entità
   • Funzionalità
3. Training, test e pubblicazione
4. Testare l'apprendimento attivo esaminando le espressioni inviate all'endpoint di previsione
5. Raccogliere dati da query sugli endpoint

Identificare il dominio

Un'app LUIS è incentrata su un dominio soggetto. Ad esempio, si potrebbe avere un'app di viaggi che gestisce prenotazioni di biglietti, voli, hotel e auto a noleggio. Un'altra app potrebbe fornire contenuti relativi ad allenamento fisico, monitoraggio degli sforzi e impostazione degli obiettivi. Identificare il dominio consente di trovare parole o frasi rilevanti per il dominio.

Suggerimento

LUIS offre domini predefiniti per molti scenari comuni. Verificare se è possibile utilizzare un dominio predefinito come punto di partenza per l'app.

Identificare le finalità

Pensare alle finalità che sono importanti per l'attività dell'applicazione.

Si consideri l'esempio di un'app di viaggi con funzioni per la prenotazione di un volo e il controllo delle previsioni meteo relative alla destinazione dell'utente. Per queste azioni è possibile definire due finalità: BookFlight e GetWeather.

In un'app più complessa con più funzioni, si avranno probabilmente più finalità e sarà necessario definirle con attenzione in modo che non siano troppo specifiche. Ad esempio, BookFlight e BookHotel potrebbero essere finalità separate, ma BookInternationalFlight e BookDomesticFlight potrebbero essere troppo simili.

Nota

È consigliabile limitare il numero delle finalità solo a quelle necessarie per eseguire le funzioni dell'app. Se si definiscono troppe finalità, per LUIS sarà più difficile classificare correttamente le espressioni. Se invece se ne definiscono troppo poche, potrebbero risultare così generali da sovrapporsi.

Se non è necessario identificare l'intenzione generale dell'utente, aggiungere tutte le espressioni utente di esempio alla finalità None. Se l'app viene estesa e richiede più finalità, è possibile crearle in un secondo momento.

Creare espressioni di esempio per ogni finalità

In un primo momento, evitare di creare troppe espressioni per ogni finalità. Dopo aver determinato le finalità necessarie per l'app, creare da 15 a 30 espressioni di esempio per finalità. Ogni espressione deve essere diversa dalle espressioni precedenti. Includere quindi un'ampia gamma di numeri di parole, scelte di parole, tempi verbali e segni di punteggiatura.

Per altre informazioni, vedere l'articolo Comprendere quali sono le espressioni ottimali per l'app LUIS.

Identificare le entità

Nelle espressioni di esempio individuare le entità che si intende estrarre. Per prenotare un volo sono necessarie informazioni come destinazione, data, compagnia aerea, categoria del biglietto e classe di viaggio. Creare entità per questi tipi di dati e quindi contrassegnare le entità nelle espressioni di esempio. Le entità, infatti, sono importanti per conseguire una finalità.

Quando si determinano le entità da usare nell'app, tenere presente che esistono diversi tipi di entità per l'acquisizione di relazioni tra tipi di oggetti. Per ulteriori informazioni sui vari tipi disponibili, vedere Entità in LUIS.

Suggerimento

LUIS offre entità predefinite per scenari di conversazione comuni. Valutare la possibilità di usare un'entità predefinita come punto di partenza per lo sviluppo di un'applicazione.

Differenza tra finalità ed entità

La finalità è il risultato desiderato dell'intera espressione, mentre le entità sono porzioni di dati estratti dall'espressione. In genere, le finalità sono associate alle azioni che l'applicazione client deve eseguire. Le entità costituiscono le informazioni necessarie per eseguire queste azioni. A livello di programmazione, una finalità attiva una chiamata al metodo, mentre le entità vengono usate come parametri per effettuare la chiamata al metodo.

Questa espressione deve avere una finalità e può avere entità:

"Acquistare un biglietto aereo da Seattle al Cairo"

Questa espressione ha un'unica finalità:

• Acquisto di un biglietto aereo

Questa espressione può avere diverse entità:

• Località: Seattle (origine) e Cairo (destinazione)
• Quantità: un singolo biglietto

Risoluzione in espressioni con più funzioni o finalità

In molti casi, soprattutto quando si applicano conversazioni naturali, gli utenti forniscono un'espressione che può contenere più funzioni o finalità. Per risolvere questo problema è necessario in primo luogo capire che l'output può essere rappresentato sia da finalità che da entità. Questa rappresentazione deve essere quindi mappabile alle azioni dell'applicazione client e non deve essere limitata alle finalità.

Le azioni (generalmente interpretate come finalità) possono essere acquisite anche come entità nell'output dell'app e mappate ad azioni specifiche. La negazione, ad esempio, si basa solitamente su finalità ed entità per un'estrazione completa dei dati. Si considerino le due espressioni seguenti, simili nella scelta delle parole, ma con risultati diversi:

• "Pianificare il mio volo dal Cairo a Seattle"
• "Annullare il mio volo dal Cairo a Seattle"

Anziché definire due finalità separate, è consigliabile creare una singola finalità con un'entità di Machine Learning FlightAction. Questa entità dovrà estrarre i dettagli dell'azione correlata a entrambe le richieste di pianificazione e annullamento e la località di origine o di destinazione.

L'entità FlightAction dovrà quindi essere strutturata con l'entità di Machine Learning generica e le sottoentità seguenti:

• FlightAction
  • Azione
  • Origine
  • Destinazione

Per facilitare l'estrazione, è possibile aggiungere funzionalità alle sottoentità. È possibile scegliere le funzionalità da aggiungere in base al vocabolario che si prevede venga usato nelle espressioni utente e ai valori che si desidera vengano restituiti nella risposta di previsione.

Procedure consigliate

Progettare lo schema

Prima di iniziare a creare lo schema dell'app, è necessario identificare come e dove si prevede di usare l'app. Quanto più accurata e specifica è la pianificazione, tanto più saranno migliori le prestazioni dell'app.

• Cercare utenti di destinazione
• Definire utenti tipo end-to-end per rappresentare l'app: voce, avatar, gestione dei problemi (proattiva, reattiva)
• Identificare i canali di interazioni utente (ad esempio testo o voce), sfruttando soluzioni esistenti o creando una nuova soluzione per questa app
• Percorso utente end-to-end
  • Quali operazioni si prevede che l'app debba o non debba eseguire? Quali sono le priorità rispetto alle operazioni che deve eseguire?
  • Quali sono i casi d'uso principali?
• Raccogliere i dati: informazioni sulla raccolta e sulla preparazione dei dati

Non eseguire il training né pubblicare con ogni singola espressione di esempio

Aggiungere 10 o 15 espressioni prima di procedere con il training e la pubblicazione. In questo modo, si vedrà l'impatto sulla precisione della stima. L'aggiunta di una singola espressione potrebbe non avere un impatto visibile sul punteggio.

Non usare LUIS come piattaforma di training

LUIS è specifico di un dominio di modello di linguaggio. Non è progettato per l'uso come piattaforma di training in linguaggio naturale generale.

Creare l'app in modo iterativo definendo le versioni

Ogni ciclo di creazione deve trovarsi all'interno di una nuova versione, clonato da una versione esistente.

Non pubblicare troppo velocemente

La pubblicazione dell'app in tempi troppo brevi e senza una corretta pianificazione può causare diversi problemi, ad esempio:

• L'app non fornirà un livello accettabile di prestazioni nello scenario effettivo.
• Lo schema (finalità ed entità) potrebbe non essere appropriato e, se la logica dell'app client è stata sviluppata in base allo schema, potrebbe essere necessario eseguirlo nuovamente. Potrebbero quindi sorgere ritardi imprevisti e costi aggiuntivi per il progetto su cui si sta lavorando.
• Le espressioni aggiunte al modello possono causare distorsioni verso espressioni di esempio di cui può essere difficile l'identificazione e il debug. Una volta affidati a un determinato schema, inoltre, può essere difficile rimuovere eventuali ambiguità.

Non monitorare le prestazioni dell'app

Monitorare la precisione della stima usando un set di test batch.

Mantenere un set separato di espressioni che non vengono usate come espressioni di esempio o espressioni di endpoint. Continuare a migliorare l'app per il set di test. Adattare il set di test per riflettere espressioni utente reali. Usare questo set di test per valutare ogni iterazione o versione dell'app.

Non creare elenchi di frasi con tutti i valori possibili

Fornire alcuni esempi negli elenchi di frasi, ma non ogni parola o frase. LUIS generalizza e tiene conto del contesto.

Passaggi successivi

Finalità