Melhores práticas e limitações do agente de operações

Este artigo descreve as melhores práticas e limitações ao usar agentes de operações no Real-Time Intelligence.

Práticas recomendadas

Os agentes de operações ajudam as organizações a operacionalizar metas de negócios claras monitorando continuamente os dados em tempo real, avaliando limites explícitos e recomendando ações quando as condições definidas são atendidas. Por exemplo, os agentes de operações ajudam você a responder proativamente quando a disponibilidade do inventário cai para um nível crítico. Use as práticas recomendadas a seguir para agentes de operações.

• Tabelas Eventhouse: se as tabelas Eventhouse contiverem colunas aninhadas, como JSON, achate as tabelas antes de configurar um agente. Tabelas simples com nomes de coluna descritiva melhoram a capacidade do agente de analisar e avaliar dados.

• Descrições da coluna Eventhouse: se a finalidade de uma coluna não estiver clara de seu nome, adicione uma descrição em linguagem simples usando o campo de descrição em seu esquema de tabela KQL. Essa descrição ajuda o agente a interpretar os valores de dados corretamente.

• Coluna de tempo de ingestão: o agente de operações usa, por padrão, o tempo de ingestão da tabela para identificar quando os registros chegaram. O agente usa esse valor quando consulta os dados mais recentes e calcula as alterações nos dados ao longo do tempo. Verifique se o horário de ingestão está preenchido.

• Identificação de objeto comercial: se o agente precisar monitorar um objeto comercial específico, como uma estação, sensor ou registro de pessoal, identifique a coluna que identifica exclusivamente o objeto (por exemplo, StationID ou SensorID). Se você estiver usando uma fonte de banco de dados KQL, especifique a qual tabela ele pertence. Se você estiver usando uma fonte de ontologia, especifique a entidade que o agente deve usar.

• Nome de campo entre aspas: Caso uma regra faça referência a nomes de coluna ou propriedade que contenham caracteres especiais, como sublinhados e hífens, coloque o nome da coluna entre aspas (""). Essa prática garante que o agente o identifique corretamente.

• Condições quantificáveis: se uma regra usa uma linguagem qualitativa, como "baixa disponibilidade" ou "alta temperatura", substitua-a por um limite numérico específico.

  • Por exemplo, use uma frase como "menos de 3 bicicletas disponíveis" ou "a temperatura excede 80". O agente usa o conhecimento padrão do LLM para sugerir limites para termos comuns, como "condições ácidas" significa pH <7.

• Separação de regras: ao definir várias regras, descreva cada uma em uma linha ou ponto de marcador separado. Não combine condições de regras diferentes na mesma frase.

• Ordem de regra: se o agente precisar priorizar determinadas regras, liste as regras de prioridade mais alta primeiro. As LLMs podem interpretar as informações de forma diferente com base em sua posição no prompt.

• Acompanhe as consultas do agente e o acesso aos dados: Revise as fontes de dados e as consultas que o agente usa consultando o Eventhouse monitorado ou o banco de dados KQL. Use a guia Insights de consulta para exibir consultas executadas e validar o KQL gerado.

  

Exemplo de instruções

Aqui está um exemplo de como você pode apresentar suas instruções ao agente para ser claro sobre suas regras operacionais e as informações semânticas sobre os campos em seus dados.

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

Limitações

Os agentes de operações têm limitações funcionais, de plataforma e comportamentais que você deve considerar ao projetar regras e cenários de monitoramento.

Limitações da fonte de dados

• Apenas uma fonte de dados é suportada por vez.
• Quando você usa uma Eventhouse como fonte de dados:
  • Apenas mesas regulares da Eventhouse são suportadas. Não há suporte para tabelas de atalho, funções e exibições materializadas.
• Ao usar o Fabric Ontology como fonte de dados do agente:
  • A ontologia deve estar no mesmo workspace que o agente de operações.
  • As entidades de ontologia que você deseja que o agente monitore devem ter pelo menos uma propriedade estática a ser usada como o identificador para entidades. As propriedades de timeseries devem ser associadas aos campos da casa de eventos.

Limitações das regras de monitoramento de ontologias

• Ao monitorar uma ontologia:
  • Apenas valores básicos de propriedades são suportados. Não há suporte para agregações como um valor médio, mínimo ou máximo.
  • Não há suporte para regras que exijam condições 'AND' (por exemplo, o índice de frenagem de uma pista é superior a 0,8 e o temp de superfície é < 40).

Limitações do comportamento do modelo e da linguagem

• Os agentes de operações dependem de um modelo de linguagem de grande porte (LLM). As saídas são probabilísticas e podem estar incorretas, é importante examinar cuidadosamente os resultados e as recomendações que elas fornecem. Para obter mais informações, consulte Privacidade, segurança e uso responsável do Copilot para Real-Time Intelligence.
• Atualmente, os agentes de operações só dão suporte ao idioma inglês para instruções e metas de negócios.

Limitações de runtime

• O agente executa consultas a cada cinco minutos quando ativo.
• As operações expirarão se nenhuma ação for executada dentro de três dias. Após a expiração, as ações não poderão mais ser aprovadas.

Permissões e limitações de acesso

• O agente opera usando a identidade delegada e as permissões de seu criador. Isso significa:
  • Consultas e ações usam as credenciais do criador.
  • Por padrão, o criador recebe mensagens de recomendação. Alterar o destinatário não altera as credenciais usadas para consultas e ações.

Limitações de mensagens e limitação

• O uso intenso pode resultar em limitação de mensagens. Nesses casos, mensagens simplificadas não geradas por LLM podem ser enviadas em Microsoft Teams.

Limitações regionais e de espaço de trabalho

• O agente de operações está disponível nas regiões do Microsoft Fabric na nuvem pública do Azure, exceto no Centro-Sul dos EUA e no Leste dos EUA.
• Atualmente, o agente de operações não está disponível em nuvens soberanas, incluindo GCC-High e Bleu.
• Atualmente, não há suporte para o agente de operações em espaços de trabalho criptografados com chaves gerenciadas pelo cliente para espaços de trabalho do Fabric.