Najlepsze praktyki i ograniczenia agenta operacyjnego

W tym artykule opisano najlepsze rozwiązania i ograniczenia dotyczące używania agentów operacji w usłudze Real-Time Intelligence.

Najlepsze rozwiązania

Agenci operacji pomagają organizacjom operacjonalizować jasne cele biznesowe, stale monitorując dane w czasie rzeczywistym, oceniając jawne progi i zalecając akcje po spełnieniu zdefiniowanych warunków. Na przykład agenci operacyjni pomagają proaktywnie reagować, gdy dostępność zasobów spadnie do poziomu krytycznego. Skorzystaj z poniższych najlepszych rozwiązań dla agentów operacyjnych.

• Tabele Eventhouse: Jeśli tabele w Eventhouse zawierają zagnieżdżone kolumny, takie jak JSON, spłaszcz je przed skonfigurowaniem agenta. Płaskie tabele z opisowymi nazwami kolumn zwiększają zdolność agenta do analizowania i oceniania danych.

• Opisy kolumn usługi Eventhouse: jeśli cel kolumny jest niejasny z jego nazwy, dodaj opis w postaci zwykłego języka, używając pola opisu w schemacie tabeli KQL. Ten opis pomaga agentowi poprawnie interpretować wartości danych.

• Kolumna czasu pozyskiwania: agent operacji domyślnie używa czasu pozyskiwania tabeli do identyfikowania, kiedy dotarły rekordy. Agent używa tej wartości podczas wykonywania zapytań dotyczących najnowszych danych i obliczania zmian w danych w czasie. Upewnij się, że czas pozyskania danych jest uzupełniony.

• Identyfikacja obiektu biznesowego: jeśli agent musi monitorować określony obiekt biznesowy, taki jak stacja, czujnik lub rekord personelu, zidentyfikuj kolumnę, która jednoznacznie identyfikuje obiekt (na przykład StationID lub SensorID). Jeśli używasz źródła bazy danych KQL, określ tabelę, do której należy. Jeśli używasz źródła ontologii, określ jednostkę, której powinien używać agent.

• Nazwa pola w cudzysłowie: Jeśli reguła odwołuje się do nazw kolumn lub właściwości zawierających znaki specjalne, takie jak podkreślenia lub łączniki, należy ująć nazwę kolumny w cudzysłów (""). Dzięki temu agent prawidłowo go zidentyfikuje.

• Warunki kwantyfikowalne: jeśli reguła używa języka jakościowego, takiego jak "niska dostępność" lub "wysoka temperatura", zastąp ją określonym progiem liczbowym.

  • Na przykład użyj frazy takiej jak "mniej niż 3 dostępne rowery" lub "temperatura przekracza 80". Agent korzysta z domyślnej wiedzy modelu LLM, aby sugerować progi dla powszechnie używanych terminów, takich jak „warunki kwaśne”, które oznaczają pH <7.

• Separacja reguł: jeśli zdefiniujesz wiele reguł, opisz każdą regułę w osobnym wierszu lub punkcie punktorowym. Nie łącz warunków z różnych reguł w tym samym zdaniu.

• Kolejność reguł: jeśli agent musi określić priorytety określonych reguł, najpierw wyświetl listę reguł o wyższym priorytcie. LLM-y mogą interpretować informacje inaczej na podstawie jej pozycji w poleceniu.

• Śledzenie zapytań agentów i dostępu do danych: Przejrzyj źródła danych i zapytania używane przez agenta, sprawdzając monitorowaną bazę danych eventhouse lub KQL. Użyj karty Analiza zapytań, aby wyświetlić wykonane zapytania i sprawdzić poprawność wygenerowanego zapytania KQL.

  

Przykładowe instrukcje

Oto przykład sposobu, w jaki można określić instrukcje dla agenta, aby wyjaśnić jego reguły operacyjne i semantyczne informacje o polach w danych.

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

Ograniczenia

Agenci operacji mają ograniczenia funkcjonalne, platformowe i behawioralne, które należy wziąć pod uwagę podczas projektowania reguł i scenariuszy monitorowania.

Ograniczenia źródła danych

• Obsługiwane jest tylko jedno źródło danych w danym momencie.
• Kiedy używasz Eventhouse jako źródła danych:
  • Obsługiwane są tylko tabele Eventhouse lub tabele skrótów. Funkcje i zmaterializowane widoki nie są obsługiwane.
• W przypadku korzystania z Fabric Ontology jako źródła danych agenta:
  • Ontologia musi znajdować się w tym samym obszarze roboczym co agent operacji.
  • Jednostki ontologii, które mają być monitorowane przez agenta, muszą mieć co najmniej jedną właściwość statyczną do użycia jako identyfikator jednostek. Właściwości timeseries powinny być powiązane z polami magazynu zdarzeń.

Ograniczenia reguł monitorowania ontologii

• Podczas monitorowania ontologii:
  • Obsługiwane są tylko podstawowe wartości właściwości. Agregacje, takie jak średnia, minimalna lub maksymalna wartość, nie są obsługiwane.
  • Reguły wymagające warunków "AND" nie są obsługiwane (na przykład indeks hamowania dla pasa startowego wynosi ponad 0,8, a temperatura powierzchni wynosi < 40).

Ograniczenia języka i zachowania modelu

• Pracownicy operacyjni korzystają z dużego modelu językowego (LLM). Dane wyjściowe są probabilistyczne i mogą być niepoprawne. Ważne jest, aby dokładnie przejrzeć podane wyniki i zalecenia. Aby uzyskać więcej informacji, zobacz Prywatność, bezpieczeństwo i odpowiedzialne korzystanie z rozwiązania Copilot na potrzeby analizy Real-Time.
• Obecnie agenci operacji obsługują tylko język angielski na potrzeby instrukcji i celów biznesowych.

Ograniczenia środowiska uruchomieniowego

• Agent uruchamia zapytania co pięć minut, gdy jest aktywny.
• Agent wymaga znacznika czasu w danych, które odpytuje. Agent operacyjny rejestruje najpóźniejszy czas w pobieranych zapisach, a w kolejnych zapytaniach szuka danych po tym punkcie. Proces ten pozwala na dotarcie starszych danych poza ostatnie pięć minut, ale wymaga ich oznaczenia czasowego.
• Operacje wygasają, jeśli nie zostanie podjęta żadna akcja w ciągu trzech dni. Po wygaśnięciu akcje nie mogą być już zatwierdzone.

Uprawnienia i ograniczenia dostępu

• Agent działa przy użyciu delegowanej tożsamości i uprawnień jego twórcy. Oznacza to:
  • Zapytania i akcje używają poświadczeń twórcy.
  • Domyślnie twórca otrzymuje wiadomości rekomendacyjne. Zmiana adresata nie powoduje zmiany poświadczeń używanych dla zapytań i akcji.

Ograniczenia obsługi komunikatów i ograniczania przepustowości

• Intensywne korzystanie może skutkować ograniczeniem tempa wysyłania komunikatów. W takich przypadkach uproszczone komunikaty, które nie są generowane przez LLM, mogą być wysyłane w Microsoft Teams.

Ograniczenia regionalne i obszaru roboczego

• Agent operacyjny jest dostępny w regionach Microsoft Fabric w chmurze Azure, z wyłączeniem wschodnich Stanów Zjednoczonych.
• Agent operacyjny nie jest obecnie dostępny w suwerennych chmurach, w tym w GCC-High i Bleu.
• Agent operacyjny nie jest obecnie obsługiwany w obszarach roboczych szyfrowanych przy użyciu kluczy zarządzanych przez klienta dla obszarów roboczych Fabric.