Operatiivisten agenttien parhaat käytännöt ja rajoitukset

Tässä artikkelissa esitellään parhaat käytännöt ja rajoitukset, kun käytät operaatioagentteja Real-Time tiedustelussa.

Parhaat käytännöt

Operatiiviset agentit auttavat organisaatioita toteuttamaan selkeät liiketoimintatavoitteet seuraamalla jatkuvasti reaaliaikaista dataa, arvioimalla selkeät kynnysarvot ja suosittelemalla toimia, kun määritellyt ehdot täyttyvät. Esimerkiksi operatiiviset agentit auttavat sinua reagoimaan ennakoivasti, kun varaston saatavuus laskee kriittiselle tasolle. Suosittelemme seuraavia parhaita käytäntöjä operatiivisille agenteille.

• Eventhouse-taulukot: Jos eventhouse-taulukoissa on sisäkkäisiä sarakkeita, kuten JSON, litistä taulukot ennen agentin konfigurointia. Litteät taulukot, joissa on kuvailevat sarakkeennimet, parantavat agentin kykyä jäsentää ja arvioida dataa.

• Eventhouse-sarakkeiden kuvaukset: Jos sarakkeen tarkoitus ei ole selvä nimestä, lisää selkokielinen kuvaus käyttämällä kuvauskenttää KQL-taulukon skeemassa. Tämä auttaa agenttia tulkitsemaan datan arvot oikein.

• Liiketoimintaobjektin tunnistus: Jos agentin täytyy seurata tiettyä liiketoimintaobjektia, kuten asemaa, sensoria tai henkilöstötietuetta, tunnista sarakke, joka yksilöi kyseisen kohteen (esimerkiksi "StationID" tai "SensorID"). Jos käytät KQL-tietokantalähdettä, määritä, mihin tauluun se kuuluu. Jos käytät ontologian lähdettä, määritä entiteetti, jota agentin tulisi käyttää.

• Kentän nimen lainaus: Jos sääntö viittaa sarakkeen tai ominaisuuksien nimiin, joissa on erityisiä merkkejä, kuten alleviivaa tai yhdysviivaa, lisää sarakkeen nimi lainausmerkkeihin (""). Tämä käytäntö varmistaa, että agentti tunnistaa sen oikein.

• Mitattavat ehdot: Jos sääntö käyttää laadullista kieltä, kuten "matala saatavuus" tai "korkea lämpötila", korvaa se tietyllä numeerisella kynnyksellä. Esimerkiksi käytä ilmaisua kuten "alle 3 pyörää saatavilla" tai "lämpötila ylittää 80".

• Sääntöjen erottelu: Jos määrittelet useita sääntöjä, kuvaa jokainen sääntö erillisellä rivillä tai luettelokohdalla. Älä yhdistä eri sääntöjen ehtoja samaan lauseeseen.

• Sääntöjärjestys: Jos agentin täytyy priorisoida tiettyjä sääntöjä, listaa ensin korkeamman prioriteetin säännöt. Suuret kielimallit (LLM:t) saattavat tulkita tietoa eri tavoin sen sijainnin perusteella kehotteessa.

Esimerkkiohjeet

Tässä on esimerkki siitä, miten voit esittää ohjeesi agentille, jotta sen toimintasäännöt ja kenttien semanttinen tieto datassasi ovat selkeät.

*** 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.

Limitations

• Operatiiviset agentit luottavat LLM:ään luodakseen pelikirjan ja säännöt, joita agentti noudattaa, sekä perustellakseen ja tuottaakseen viestejä toimista ja suosituksista. Koska LLM-pohjaiset tekoälypalvelut ovat todennäköisyyspohjaisia ja voivat olla erehtyviä, on tärkeää tarkastella huolellisesti niiden tuottamat tulokset ja suositukset. Lisätietoja löytyy kohdasta Yksityisyys, turvallisuus ja Copilotin vastuullinen käyttö Real-Time tiedustelulle.

  Seurataksesi, mitä kyselyitä ja tietoja agentti käyttää, voit katsoa tapahtumataloa ja KQL:n tietokantaa, jota se valvoo. Query insights -välilehdellä näet ne kyselyt, joita se ajaa, ja voit validoida käyttämänsä KQL:n.

  

• Tällä hetkellä tuetaan vain tavallisia Eventhouse-pöytiä. Oikokuvake-taulukot, funktiot ja materialisoidut näkymät eivät ole tuettuja.

• Jos käytät Fabric Ontologya agentin tietolähteeksi, sen täytyy sijaita samassa työtilassa kuin operaatioagentti.

• Ontologiaen, joita haluat agentin valvovan, täytyy olla vähintään yksi staattinen ominaisuus, jotta niitä voidaan käyttää entiteettien tunnisteena. Aikasarjakiinteistöt tulisi sitoa tapahtumatalojen kenttiin.

• Ontologian seuranta rajoittuu vain perusominaisuusarvoihin. Mikään aggregaatio, kuten keskiarvo, minimiarvo tai maksimiarvo, ei ole tuettu. Seuranta, joka vaatii 'JA'-ehdon (esim. kiitotien jarrutusindeksi yli 0,8 ja pintalämpötila < 40), ei ole tuettua.

• Järjestelmän suojakaiteiden ollessa käytössä voimakas käyttö voi johtaa rajoitukseen, mikä rajoittaa agentin lähettämien viestien määrää. Tällaisissa tapauksissa saatat saada yksinkertaistettuja, ei-LLM-luomia viestejä Microsoft Teamsin kautta.

• Tällä hetkellä agentti ja LLM tukevat vain englanninkielisiä ohjeita ja tavoitteita.

• Agentti toimii käyttämällä luojansa delegoitua identiteettiä ja oikeuksia. Tämä tarkoittaa sitä, että

  • Kyselyt, tietojen käyttö ja toiminnot toimivat tekijän tunnistetietojen perusteella.

  • Oletuksena tekijä vastaanottaa suositusviestejä. Vastaanottajan vaihtaminen ei muuta kyselyihin ja toimintoihin käytettyjä tunnuksia.

• Agentti suorittaa datakyselyt viiden minuutin välein, kun se on aktiivinen.

• Kun agentti havaitsee sääntöjään vastaavan dataa, se seuraa suositeltuja toimintoja ja käyttäjän vastetta operaationa. Jos käyttäjä ei vastaa (hyväksy tai hylkää) kolmen päivän kuluessa, operaatio peruutetaan automaattisesti. Tämän ajan jälkeen et voi olla vuorovaikutuksessa tai hyväksyä toimenpidettä.

• Operations Agent on saatavilla Microsoft Fabric -alueilla, lukuun ottamatta Etelä-Keski-Yhdysvaltoja ja Itä-Yhdysvaltoja.

• Jos Fabric-vuokralainen ja kapasiteetti ovat eri alueilla, Power Automate -toimintojen konfiguroinnissa saattaa ilmetä virheitä. Kunnes korjaus on saatavilla, käytä operaatioagenttia, varmista, että työtilan kapasiteetti on samalla alueella kuin Fabric-vuokralainen.