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å. Bruk 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. Denne beskrivelsen hjelper agenten med å tolke dataverdiene korrekt.

• Kolonnen for inntastingstid: Operasjonsagenten bruker som standard inntastingstiden til tabellen for å identifisere når poster ankom. Agenten bruker denne verdien når den spør etter de nyeste dataene og for å beregne endringer i dataene over tid. Sørg for at inntakstiden er oppfylt.

• Identifikasjon av forretningsobjekter: Hvis agenten trenger å overvåke et spesifikt forretningsobjekt som en stasjon, sensor eller personalopptegnelse, 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». Agenten bruker standard LLM-kunnskap for å foreslå terskler for vanlige termer, som at «sure forhold» betyr pH <7.

• 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. LLM-er kan tolke informasjon forskjellig basert på plasseringen i prompten.

• Spor agentforespørsler og datatilgang: Gjennomgå datakildene og spørringene agenten bruker ved å sjekke den overvåkede Eventhouse- eller KQL-databasen. Bruk fanen Query insights for å se utførte forespørsler og validere den genererte KQL-en.

  

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

Driftsagenter har funksjonelle, plattform- og atferdsmessige begrensninger som du bør vurdere når du designer regler og overvåker scenarioer.

Begrensninger i datakilde

• Kun én datakilde støttes om gangen.
• Når du bruker et Eventhouse som datakilde:
  • Kun vanlige Eventhouse-bord støttes. Snarveitabeller, funksjoner og materialiserte visninger støttes ikke.
• Når man bruker en Fabric Ontology som agentens datakilde:
  • Ontologien må være 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.

Begrensninger for ontologiovervåkingsregler

• Når man overvåker en ontologi:
  • Kun grunnleggende eiendomsverdier støttes. Aggregeringer som gjennomsnittlig, minimum eller maksimumsverdi støttes ikke.
  • Regler som krever 'OG'-betingelser støttes ikke (for eksempel er bremseindeksen for en rullebane over 0,8 og overflatetemperaturen 40 < ).

Språk- og modellatferdsbegrensninger

• Operasjonsagenter er avhengige av en stor språkmodell (LLM). Resultatene er sannsynlighetsbaserte og kan være feil, det er 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 øyeblikket støtter driftsagenter kun engelsk språk for instruksjoner og forretningsmål.

Begrensninger i kjøretid

• Agenten kjører spørringer hvert femte minutt når den er aktiv.
• Operasjoner utløper hvis ingen tiltak iverksettes innen tre dager. Etter utløp kan handlingene ikke lenger godkjennes.

Tillatelser og tilgangsbegrensninger

• Agenten opererer ved å bruke den delegerte identiteten og tillatelsene til skaperen. Dette betyr:
  • Forespørsler og handlinger bruker skaperens legitimasjon.
  • Som standard mottar skaperen anbefalingsmeldinger. Å endre mottaker endrer ikke legitimasjonen som brukes for spørringer og handlinger.

Begrensninger for meldingsutveksling og throttling

• Tung bruk kan føre til at meldingene blir begrenset. I disse tilfellene kan forenklede meldinger uten LLM sendes i Microsoft Teams.

Regionale og arbeidsplassbegrensninger

• Operations agent er tilgjengelig i Azure offentlige sky-Microsoft Fabric-regioner, unntatt Sør-Sentral-USA og Øst-USA.
• Operations Agent er for øyeblikket ikke tilgjengelig i suverene skyer, inkludert GCC-High og Bleu.
• Operations Agent støttes for øyeblikket ikke i arbeidsområder kryptert med Customer-managed keys for Fabric workspaces.