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. Vi anbefaler 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.

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

• Forretningsobjektidentifikation: Hvis agenten skal overvåge et specifikt forretningsobjekt såsom en station, sensor eller personalepost, skal den kolonne identificeres entydigt (for eksempel "StationID" eller "SensorID"). Angiv, hvilken tabel den hører til.

• Feltnavnscitat: Hvis en regel refererer til kolonnenavne, der indeholder specialtegn, såsom understreger eller bindestreg, skal kolonnenavnet indkapsles i 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."

• 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. Store sprogmodeller (LLM'er) kan fortolke information forskelligt afhængigt af dens placering i prompten.

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 er afhængige af en LLM til at skabe playbook og regler, agenten følger, samt til at ræsonnere og generere beskeder til handlinger og anbefalinger. Da AI-tjenester baseret på LLM er probabilistiske og kan være fejlbarlige, er det 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.

  For at spore, hvilke forespørgsler og data agenten tilgår, kan du kigge i eventhouse- og KQL-databasen, den overvåger. På fanen Query insights ser du de forespørgsler, den kører, og kan validere den KQL, den bruger.

  

• Selvom systemets sikkerhedsforanstaltninger er på plads, kan tung brug resultere i throttling, hvilket begrænser antallet af beskeder, agenten kan sende. I sådanne tilfælde kan du modtage forenklede, ikke-LLM-genererede beskeder gennem Microsoft Teams.

• I øjeblikket understøtter agenten og LLM'en kun engelske instruktioner og mål.

• Agenten opererer ved at bruge den delegerede identitet og tilladelser fra sin skaber. Det betyder:

  • Forespørgsler, dataadgang og handlinger kører baseret på skaberens legitimationsoplysninger.

  • Som standard modtager skaberen anbefalingsbeskeder. At ændre modtageren ændrer ikke de legitimationsoplysninger, der bruges til forespørgsler og handlinger.

• Agenten kører dataforespørgsler hvert femte minut, når den er aktiv.

• Når agenten opdager data, der matcher dens regler, sporer den de anbefalede handlinger og brugerens svar som en operation. Hvis brugeren ikke svarer (godkender eller afviser) inden for tre dage, bliver operationen automatisk annulleret. Efter denne periode kan du ikke interagere med eller godkende handlingen.

• Operations agent er tilgængelig i Microsoft Fabric-regioner, undtagen South Central US og East US.

• Hvis din Fabric-lejer og kapacitet er i forskellige regioner, kan du få fejl, når du konfigurerer Power Automate-handlinger. Indtil en løsning er tilgængelig, skal du sikre dig, at din arbejdsområdekapacitet er i samme region som din Fabric-lejer, for at bruge operationsagenten.