Operations agents bedste praksis og begrænsninger

Denne artikel skitserer bedste praksis og begrænsninger, når du bruger operationsagenter i Real-Time Intelligence.

Bedste praksis

Driftsagenter hjælper organisationer med at operationalisere klare forretningsmål ved kontinuerligt at overvåge realtidsdata, evaluere eksplicitte tærskler og anbefale handlinger, når definerede betingelser er opfyldt. For eksempel hjælper driftsagenter dig proaktivt, når lagertilgængeligheden falder til et kritisk niveau. Brug følgende bedste praksis for operationsagenter.

  • Eventhouse-tabeller: Hvis eventhouse-tabeller indeholder indlejrede kolonner som JSON, så flad tabellerne ud, før du konfigurerer agenten. Flade tabeller med beskrivende kolonnenavne forbedrer agentens evne til at analysere og evaluere data.

  • Eventhouse-kolonnebeskrivelser: Hvis formålet med en kolonne er uklart ud fra navnet, tilføj en klarsproget beskrivelse ved at bruge beskrivelsesfeltet i dit KQL-tabelskema. Denne beskrivelse hjælper agenten med at fortolke dataværdierne korrekt.

  • Indtagelsestidskolonne: Operationsagenten bruger som standard tabellen til at identificere, hvornår poster ankom. Agenten bruger denne værdi, når den forespørger efter de nyeste data og til at beregne ændringer i dataene over tid. Sørg for, at indtagningstiden er fyldt ind.

  • Identifikation af forretningsobjekter: Hvis agenten skal overvåge et specifikt forretningsobjekt såsom en station, sensor eller personalepost, skal den kolonne identificeres, der entydigt identificerer objektet (for eksempel StationID eller SensorID). Hvis du bruger en KQL-databasekilde, skal du angive, hvilken tabel den tilhører. Hvis du bruger en ontologikilde, skal du angive den enhed, agenten skal bruge.

  • Feltnavnscitat: Hvis en regel refererer til kolonne- eller egenskabsnavne, der indeholder specialtegn, såsom understrøg eller bindestreg, skal kolonnenavnet indgydes med anførselstegn (""). Denne praksis sikrer, at agenten identificerer den korrekt.

  • Kvantificerbare betingelser: Hvis en regel bruger kvalitativt sprog som "lav tilgængelighed" eller "høj temperatur", skal det erstattes med en specifik numerisk tærskel.

    • For eksempel kan du bruge en sætning som "færre end 3 cykler tilgængelige" eller "temperaturen overstiger 80". Agenten bruger standardviden om LLM til at foreslå tærskler for almindelige termer, såsom at "sure forhold" betyder pH <7.
  • Regeladskillelse: Hvis du definerer flere regler, beskriv hver regel på en separat linje eller punktliste. Kombiner ikke betingelser fra forskellige regler i samme sætning.

  • Regelrækkefølge: Hvis agenten skal prioritere bestemte regler, skal du først liste regler med højere prioritet. LLM'er kan fortolke information forskelligt afhængigt af dens placering i prompten.

  • Følg agentforespørgsler og dataadgang: Gennemgå datakilderne og forespørgsler, som agenten bruger, ved at tjekke den overvågede Eventhouse- eller KQL-database. Brug fanen Forespørgselsindsigter til at se udførte forespørgsler og validere den genererede KQL.

    Skærmbillede af fanen Forespørgsel indsigter i KQL-databasen.

Eksempel på instruktion

Her er et eksempel på, hvordan du kan lægge dine instruktioner frem for agenten for at være klar over dens driftsregler og de semantiske oplysninger om felterne i dine data.

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

Begrænsninger

Operationsagenter har funktionelle, platform- og adfærdsmæssige begrænsninger, som du bør tage højde for, når du designer regler og overvåger scenarier.

Begrænsninger i datakilde

  • I øjeblikket understøtter operationsagenter kun overvågningsdata i almindelige Eventhouse-tabeller. Genvejstabeller, funktioner og materialiserede visninger understøttes ikke.
  • Når man bruger en Fabric Ontology som agentens datakilde:
    • Ontologien skal være i samme arbejdsområde som operationsagenten.
    • Ontologienheder, som du vil have agenten til at overvåge, skal have mindst én statisk egenskab, som kan bruges som identifikator for entiteter. Tidsserie-ejendomme bør være bundet til eventhouse-felter.

Overvågning og regelbegrænsninger

  • Ontologiovervågning understøtter kun grundlæggende ejendomsværdier. Aggregationer som en gennemsnitlig, minimums- eller maksimumsværdi understøttes ikke.
  • Regler, der kræver 'OG'-betingelser, understøttes ikke (for eksempel er bremseindekset for en landingsbane over 0,8 og overfladetemperaturen er < 40).

Sprog- og modeladfærdsbegrænsninger

  • Operationsagenter er afhængige af en stor sprogmodel (LLM). Resultaterne er probabilistiske og kan være forkerte, det er vigtigt nøje at gennemgå de resultater og anbefalinger, de giver. For mere information, se Privatliv, sikkerhed og ansvarlig brug af Copilot for Real-Time Intelligence.
  • I øjeblikket understøtter operationsagenter kun engelsk sprog til instruktioner og forretningsmål.

Begrænsninger i kørselstid

  • Agenten kører forespørgsler hvert femte minut, når den er aktiv.
  • Operationer udløber, hvis der ikke tages handling inden for tre dage. Efter udløb kan handlinger ikke længere godkendes.

Tilladelser og adgangsbegrænsninger

  • Agenten opererer ved at bruge den delegerede identitet og tilladelser fra sin skaber. Det betyder:
    • Forespørgsler og handlinger bruger skaberens legitimationsoplysninger.
    • Som standard modtager skaberen anbefalingsbeskeder. At ændre modtageren ændrer ikke de legitimationsoplysninger, der bruges til forespørgsler og handlinger.

Begrænsninger for beskeder og throttling

  • Tung brug kan resultere i besked-throttling. I disse tilfælde kan forenklede, ikke-LLM-genererede beskeder sendes i Microsoft Teams.

Regionale og arbejdsområdebegrænsninger

  • Operations agent er tilgængelig i Azure public cloud Microsoft Fabric-regioner, undtagen South Central US og East US.
  • Operations agent er i øjeblikket ikke tilgængelig i suveræne clouds, herunder GCC-High og Bleu.
  • Operations Agent understøttes i øjeblikket ikke i arbejdsområder krypteret med Kundeadministrerede nøgler til Fabric arbejdsområder.