Driftsagentens beste praksis og begrensninger

Denne artikkelen skisserer beste praksis og begrensninger når du bruker operasjonsagenter i Real-Time Intelligence.

Anbefalte fremgangsmåter

Driftsagenter hjelper organisasjoner med å operasjonalisere klare forretningsmål ved kontinuerlig å overvåke sanntidsdata, evaluere eksplisitte terskler og anbefale tiltak når definerte betingelser er oppfylt. For eksempel hjelper driftsagenter deg proaktivt når lagertilgjengeligheten faller til et kritisk nivå. Vi anbefaler følgende beste praksis for driftsagenter.

• Eventhouse-tabeller: Hvis eventhouse-tabeller inneholder nestede kolonner som JSON, flat ut tabellene før du konfigurerer agenten. Flate tabeller med beskrivende kolonnenavn forbedrer agentens evne til å analysere og evaluere data.

• Eventhouse-kolonnebeskrivelser: Hvis formålet med en kolonne er uklart ut fra navnet, legg til en klarspråklig beskrivelse ved å bruke beskrivelsesfeltet i KQL-tabellskjemaet ditt. Dette hjelper agenten med å tolke dataverdiene korrekt.

• Identifikasjon av forretningsobjekter: Hvis agenten trenger å overvåke et spesifikt forretningsobjekt som en stasjon, sensor eller personalregister, identifiser kolonnen som entydig identifiserer objektet (for eksempel "StationID" eller "SensorID"). Hvis du bruker en KQL-databasekilde, spesifiser hvilken tabell den tilhører. Hvis du bruker en ontologikilde, spesifiser enheten agenten skal bruke.

• Feltnavn-sitatering: Hvis en regel refererer til kolonne- eller egenskapsnavn som inneholder spesialtegn, som understreker eller bindestreker, omslutt kolonnenavnet med anførselstegn (""). Denne praksisen sikrer at agenten identifiserer den korrekt.

• Kvantifiserbare betingelser: Hvis en regel bruker kvalitativt språk som «lav tilgjengelighet» eller «høy temperatur», erstatt det med en spesifikk numerisk terskel. For eksempel, bruk et uttrykk som «færre enn 3 sykler tilgjengelig» eller «temperaturen overstiger 80.»

• Regelseparasjon: Hvis du definerer flere regler, beskriv hver regel på en egen linje eller punktliste. Ikke kombiner betingelser fra forskjellige regler i samme setning.

• Regelrekkefølge: Hvis agenten må prioritere visse regler, list opp regler med høyere prioritet først. Store språkmodeller (LLM-er) kan tolke informasjon forskjellig basert på plasseringen i prompten.

Eksempelinstruksjoner

Her er et eksempel på hvordan du kan legge frem instruksjonene dine til agenten for å være tydelig på dens operative regler og den semantiske informasjonen om feltene i dataene dine.

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

Begrensninger

• Operasjonsagenter er avhengige av en LLM for å lage playbooken og reglene agenten følger, samt for å resonnere og generere meldinger for handlinger og anbefalinger. Siden AI-tjenester basert på LLM er sannsynlighetsbaserte og kan være feilbarlige, er det viktig å nøye gjennomgå resultatene og anbefalingene de gir. For mer informasjon, se Personvern, sikkerhet og ansvarlig bruk av Copilot for Real-Time Intelligence.

  For å spore hvilke spørringer og data agenten får tilgang til, kan du se på eventhouse- og KQL-databasen den overvåker. På fanen Query insights ser du spørringene den kjører og kan validere KQL-en den bruker.

  

• For øyeblikket støttes kun vanlige Eventhouse-bord. Snarveitabeller, funksjoner og materialiserte visninger støttes ikke.

• Hvis du bruker en Fabric Ontology for agentens datakilde, må den være plassert i samme arbeidsområde som operasjonsagenten.

• Ontologienheter som du vil at agenten skal overvåke, må ha minst én statisk egenskap som kan brukes som identifikator for entiteter. Tidsserie-eiendommer bør være bundet til eventhouse-felt.

• Ontologiovervåking er begrenset til kun grunnleggende eiendomsverdier. Enhver aggregering som en gjennomsnittlig, minimums- eller maksimumsverdi støttes ikke. Overvåking som krever en 'OG'-betingelse (f.eks. bremseindeksen for en rullebane er over 0,8 og overflatetemperaturen er < 40) støttes ikke.

• Selv om systemgarantier er på plass, kan tung bruk føre til throttling, noe som begrenser antall meldinger agenten kan sende. I slike tilfeller kan du motta forenklede, ikke-LLM-genererte meldinger gjennom Microsoft Teams.

• For øyeblikket støtter agenten og LLM-en kun engelske instruksjoner og mål.

• Agenten opererer ved å bruke den delegerte identiteten og tillatelsene til skaperen. Dette betyr:

  • Spørringer, datatilgang og handlinger kjøres basert på skaperens legitimasjon.

  • Som standard mottar skaperen anbefalingsmeldinger. Å endre mottaker endrer ikke legitimasjonen som brukes for spørringer og handlinger.

• Agenten kjører dataspørringer hvert femte minutt når den er aktiv.

• Når agenten oppdager data som samsvarer med reglene, sporer den de anbefalte handlingene og brukerens respons som en operasjon. Hvis brukeren ikke svarer (godkjenner eller avslår) innen tre dager, blir operasjonen automatisk kansellert. Etter denne perioden kan du ikke interagere med eller godkjenne handlingen.

• Driftsagenten er tilgjengelig i Microsoft Fabric-regionene, unntatt Sør-Sentral-USA og Øst-USA.

• Hvis Fabric-leietakeren og kapasiteten din er i forskjellige regioner, kan du få feil når du konfigurerer Power Automate-handlinger. Inntil en løsning er tilgjengelig, må du sørge for at arbeidsområdets kapasitet er i samme region som Fabric-leietakeren din for å bruke driftsagenten.