この記事では、Real-Time インテリジェンスで運用エージェントを使用する場合のベスト プラクティスと制限事項について説明します。
ベスト プラクティス
運用エージェントは、リアルタイム データを継続的に監視し、明示的なしきい値を評価し、定義された条件が満たされたときにアクションを推奨することで、組織が明確なビジネス目標を運用化するのに役立ちます。 たとえば、運用エージェントは、インベントリの可用性が重要なレベルに低下した場合に、事前に対応するのに役立ちます。 運用エージェントには、次のベスト プラクティスをお勧めします。
Eventhouse テーブル: EVENTHOUSE テーブルに JSON などの入れ子になった列が含まれている場合は、エージェントを構成する前にテーブルをフラット化します。 わかりやすい列名を持つフラット テーブルにより、エージェントがデータを解析および評価する機能が向上します。
列の説明: 列の目的が名前から不明な場合は、KQL テーブル スキーマの description フィールドを使用して、プレーン言語の説明を追加します。 これは、エージェントがデータ値を正しく解釈するのに役立ちます。
ビジネス オブジェクトの識別: エージェントがステーション、センサー、人事レコードなどの特定のビジネス オブジェクトを監視する必要がある場合は、オブジェクトを一意に識別する列 ("StationID" や "SensorID" など) を特定します。 どのテーブルに属するかを指定します。
フィールド名の引用符: ルールが、アンダースコアやハイフンなどの特殊文字を含む列名を参照する場合は、列名を引用符 ("") で囲みます。 この方法により、エージェントによって正しく識別されます。
定量化可能な条件: ルールで "低可用" や "高温" などの定性言語を使用する場合は、それを特定の数値しきい値に置き換えます。 たとえば、"利用可能な自転車が 3 台未満" や "温度が 80 を超える" などの語句を使用します。
ルールの分離: 複数のルールを定義する場合は、各ルールを個別の行または箇条書きで記述します。 同じ文内の異なるルールの条件を組み合わせないでください。
ルールの順序: エージェントが特定のルールに優先順位を付ける必要がある場合は、優先順位の高いルールを最初に一覧表示します。 大規模言語モデル (LLM) は、プロンプトでの位置に基づいて情報を解釈する方法が異なる場合があります。
指示のサンプル
操作ルールとデータ内のフィールドに関するセマンティック情報を明確にするために、エージェントに指示をレイアウトする方法の例を次に示します。
*** 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.
制限事項
運用エージェントは LLM に依存して、エージェントが従うプレイブックとルールを作成し、アクションと推奨事項のメッセージを推論して生成します。 LLM ベースの AI サービスは確率論的であり、フォール可能な可能性があるため、提供される結果と推奨事項を慎重に確認することが重要です。 詳細については、 Real-Time インテリジェンスに対する Copilot のプライバシー、セキュリティ、責任ある使用に関するページを参照してください。
エージェントがアクセスするクエリとデータを追跡するには、監視対象の eventhouse および KQL のデータベースを確認することができます。 [ クエリ分析情報 ] タブには、実行されているクエリが表示され、使用する KQL を検証できます。
現在、通常の Eventhouse テーブルのみがサポートされています。 ショートカット テーブル、関数、具体化されたビューはサポートされていません。
システム ガードレールが配置されている間、使用率が高いと調整が発生し、エージェントが送信できるメッセージの数が制限される可能性があります。 このような場合は、Microsoft Teamsを介して、LLM で生成されていない簡略化されたメッセージを受け取る可能性があります。
現時点では、エージェントと LLM は英語の指示と目標のみをサポートしています。
エージェントは、その作成者の委任された ID とアクセス許可を使用して動作します。 これは、以下のようなことを意味します。
クエリ、データ アクセス、アクションは、作成者の資格情報に基づいて実行されます。
既定では、作成者はレコメンデーション メッセージを受信します。 受信者を変更しても、クエリとアクションに使用される資格情報は変更されません。
エージェントは、アクティブなときに 5 分ごとにデータ クエリを実行します。
エージェントは、ルールに一致するデータを検出すると、推奨されるアクションとユーザーの応答を 操作として追跡します。 ユーザーが 3 日以内に応答 (承認または拒否) しない場合、操作は自動的に取り消されます。 この期間を過ぎると、アクションを操作したり承認したりすることはできません。
オペレーション エージェントは、米国中南部と米国東部を除く Microsoft Fabric リージョンで使用できます。
Fabric テナントと容量が異なるリージョンにある場合は、Power Automate アクションを構成するときにエラーが発生する可能性があります。 修正プログラムが利用可能になるまで、オペレーション エージェントを使用するには、ワークスペースの容量が Fabric テナントと同じリージョンにあることを確認します。