Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo illustra le procedure consigliate e le limitazioni quando si usano agenti operativi in Real-Time Intelligence.
Procedure consigliate
Gli agenti operativi consentono alle organizzazioni di rendere operativi obiettivi aziendali chiari monitorando continuamente i dati in tempo reale, valutando soglie esplicite e consigliando azioni quando vengono soddisfatte le condizioni definite. Ad esempio, gli agenti operativi consentono di rispondere in modo proattivo quando la disponibilità dell'inventario scende a un livello critico. Usare le procedure consigliate seguenti per gli agenti operativi.
Tabelle Eventhouse: Se le tabelle Eventhouse contengono colonne nidificate, ad esempio JSON, appiattire le tabelle prima di configurare l'agente. Le tabelle flat con nomi di colonna descrittivi migliorano la capacità dell'agente di analizzare e valutare i dati.
Descrizioni delle colonne eventhouse: se lo scopo di una colonna non è chiaro dal nome, aggiungere una descrizione in linguaggio normale usando il campo descrizione nello schema della tabella KQL. Questa descrizione consente all'agente di interpretare correttamente i valori dei dati.
Colonna ora di inserimento: l'agente operazioni usa per impostazione predefinita l'ora di inserimento della tabella per identificare quando arrivano i record. L'agente usa questo valore quando esegue una query per i dati più recenti e per calcolare le modifiche apportate ai dati nel tempo. Assicurarsi che il tempo di inserimento sia popolato.
Identificazione dell'oggetto business: se l'agente deve monitorare un oggetto business specifico, ad esempio una stazione, un sensore o un record del personale, identificare la colonna che identifica in modo univoco l'oggetto , ad esempio
StationIDoSensorID. Se si usa un'origine di database KQL, specificare la tabella a cui appartiene. Se si usa un'origine di ontologia, specificare l'entità che deve essere usata dall'agente.Citazione del nome del campo: se una regola fa riferimento a nomi di colonna o proprietà che contengono caratteri speciali, come caratteri di sottolineatura o trattini, racchiudere il nome della colonna tra virgolette (""). Questa procedura garantisce che l'agente lo identifichi correttamente.
Condizioni quantificabili: se una regola usa un linguaggio qualitativo, ad esempio "disponibilità bassa" o "temperatura elevata", sostituirlo con una soglia numerica specifica.
- Ad esempio, usare una frase come "meno di 3 biciclette disponibili" o "temperatura superiore a 80". L'agente usa la conoscenza LLM predefinita per suggerire soglie per termini comuni, ad esempio "condizioni acide" significa pH <7.
Separazione delle regole: Se si definiscono più regole, descrivere ogni regola in una linea o un punto elenco separato. Non combinare condizioni da regole diverse nella stessa frase.
Ordine delle regole: se l'agente deve assegnare priorità a determinate regole, elencare prima le regole con priorità più alta. I llms possono interpretare le informazioni in modo diverso in base alla relativa posizione nel prompt.
Tenere traccia delle query dell'agente e dell'accesso ai dati: Esaminare le origini dati e le query usate dall'agente controllando l'eventhouse o il database KQL monitorato. Usa la scheda Query Insights per visualizzare le query eseguite e verificare il KQL generato.
Istruzioni di esempio
Di seguito è riportato un esempio di come è possibile definire le istruzioni per l'agente per chiarire le regole operative e le informazioni semantiche sui campi nei dati.
*** Operational Instructions ***
1. Alert me when a trip has high occupancy level.
2. Alert me when a trip has high departure delay.
*** Semantic Instructions ***
1. Information about a trip can be found in 'TripUpdateFlattened' table, each identified by the 'trip_id' column.
2. Information about a vehicle can be found in 'VehiclePositionsFlat' table, each identified the 'vehicle_id' column.
3. A trip is a associated with multiple vehicles via shared trip ID.
4. Occupancy status of a trip is calculated as the latest occupancy status from the vehicle the trip is associated with. The value 'HIGH' means high occupancy level.
5. The departure delay is measured in number of seconds. Higher than 300 seconds of delay is considered significant.
Limitazioni
Gli agenti operativi presentano limitazioni funzionali, della piattaforma e del comportamento che è consigliabile prendere in considerazione durante la progettazione di regole e scenari di monitoraggio.
Limitazioni dell'origine dati
- Attualmente, gli agenti operativi supportano solo il monitoraggio dei dati nelle normali tabelle Eventhouse. Le tabelle di scelta rapida, le funzioni e le viste materializzate non sono supportate.
- Quando si usa un'ontologia Fabric come origine dei dati dell'agente:
- L'ontologia deve trovarsi nella stessa area di lavoro dell'agente operativo.
- Le entità di ontologia da monitorare devono avere almeno una proprietà statica da usare come identificatore per le entità. Le proprietà timeseries devono essere associate ai campi eventhouse.
Limitazioni di monitoraggio e regole
- Il monitoraggio dell'ontologia supporta solo i valori di proprietà di base. Le aggregazioni, ad esempio un valore medio, minimo o massimo, non sono supportate.
- Le regole che richiedono condizioni "AND" non sono supportate (ad esempio, l'indice di frenata per una pista è superiore a 0,8 e la temperatura della superficie è < 40).
Limitazioni del comportamento del linguaggio e del modello
- Gli agenti operativi si basano su un modello LLM (Large Language Model). Gli output sono probabilistici e possono non essere corretti, è importante esaminare attentamente i risultati e le raccomandazioni forniti. Per altre informazioni, vedere Privacy, sicurezza e uso responsabile di Copilot per Real-Time Intelligence.
- Attualmente, gli agenti operativi supportano solo la lingua inglese per istruzioni e obiettivi aziendali.
Limitazioni di runtime
- L'agente esegue delle query ogni cinque minuti quando è attivo.
- Le operazioni scadono se non viene eseguita alcuna azione entro tre giorni. Dopo la scadenza, le azioni non possono più essere approvate.
Autorizzazioni e limitazioni di accesso
- L'agente opera usando l'identità delegata e le autorizzazioni del creatore. Ciò significa:
- Le query e le azioni utilizzano le credenziali del creatore.
- Per impostazione predefinita, l'autore riceve i messaggi di raccomandazione. La modifica del destinatario non modifica le credenziali usate per le query e le azioni.
Limiti di messaggistica e di limitazione della velocità
- Un uso intensivo può causare una limitazione dei messaggi. In questi casi, i messaggi non generati dall'LLM semplificati potrebbero essere inviati in Microsoft Teams.
Limitazioni regionali e dello spazio di lavoro
- L'agente Operations è disponibile nelle aree Microsoft Fabric del cloud pubblico di Azure, ad eccezione di South Central US e East US.
- L'agente operativo non è attualmente disponibile nei cloud sovrani, tra cui GCC-High e Bleu.
- L'agente Operations non è attualmente supportato nelle aree di lavoro crittografate con chiavi gestite dal cliente per le aree di lavoro Fabric.