Boas práticas e limitações dos agentes de operações

Este artigo descreve as melhores práticas e limitações ao utilizar agentes de operações em Inteligência em Tempo Real.

Melhores práticas

Os agentes de operações ajudam as organizações a operacionalizar objetivos de negócio claros, monitorizando continuamente dados em tempo real, avaliando limiares explícitos e recomendando ações quando condições definidas são cumpridas. Por exemplo, os agentes de operações ajudam-no a responder de forma proativa quando a disponibilidade de inventário cai para um nível crítico. Utilize as seguintes boas práticas para agentes de operações.

  • Tabelas Eventhouse: Se as tabelas Eventhouse contêm colunas aninhadas como JSON, achatem as tabelas antes de configurar o agente. Tabelas planas com nomes de colunas descritivas melhoram a capacidade do agente de analisar e avaliar dados.

  • Descrições das colunas Eventhouse: Se o propósito de uma coluna não estiver claro pelo nome, adicione uma descrição em linguagem simples usando o campo de descrição no seu esquema de tabela KQL. Esta descrição ajuda o agente a interpretar corretamente os valores dos dados.

  • Coluna do tempo de ingestão: O agente de operações utiliza por defeito o tempo de ingestão da tabela para identificar quando os registos chegaram. O agente utiliza este valor quando consulta dados mais recentes e para calcular alterações nos dados ao longo do tempo. Certifique-se de que o tempo de ingestão está preenchido.

  • Identificação de objeto de negócio: Se o agente precisar de monitorizar um objeto de negócio específico, como uma estação, sensor ou registo de pessoal, identifique a coluna que identifica de forma única o objeto (por exemplo, StationID ou SensorID). Se estiveres a usar uma fonte de base de dados KQL, especifica a que tabela pertence. Se estiver a usar uma fonte de ontologia, especifique a entidade que o agente deve usar.

  • Citação do nome do campo: Se uma regra faz referência a nomes de colunas ou propriedades que contenham caracteres especiais, como sublinhados ou hífens, inclua o nome da coluna entre aspas (""). Esta prática garante que o agente o identifica corretamente.

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

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

  • Separação de regras: Se definir múltiplas regras, descreva cada regra numa linha ou ponto separado. Não combines condições de regras diferentes na mesma frase.

  • Ordem das regras: Se o agente precisar de priorizar certas regras, liste primeiro as regras de prioridade superior. Os LLMs podem interpretar a informação de forma diferente consoante a sua posição no enunciado.

  • Acompanhar consultas de agentes e acesso a dados: Revise as fontes de dados e as consultas que o agente utiliza, verificando a base de dados monitorizada do Eventhouse ou KQL. Utilize o separador Informações de consulta para visualizar as consultas executadas e validar o KQL gerado.

    Captura de ecrã do separador de insights da consulta na base de dados KQL.

Instruções de exemplo

Aqui está um exemplo de como pode apresentar as suas instruções ao agente para ser claro quanto às suas regras operacionais e à informação semântica sobre os campos nos 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 deve considerar ao desenhar regras e monitorizar cenários.

Limitações da fonte de dados

  • Apenas uma fonte de dados é suportada de cada vez.
  • Quando utiliza um Eventhouse como fonte de dados:
    • Apenas as mesas regulares da Eventhouse são suportadas. As tabelas de atalho, as funções e as vistas materializadas não são suportadas.
  • Ao utilizar uma Ontologia do Fabric como origem de dados do agente:
    • A ontologia deve estar no mesmo espaço de trabalho que o agente de operações.
    • As entidades de ontologia que queres que o agente monitorize devem ter pelo menos uma propriedade estática para usar como identificador das entidades. As propriedades de séries temporais devem estar vinculadas a campos de casas de eventos.

Limitações das regras de monitorização de ontologias

  • Ao monitorizar uma Ontologia:
    • Apenas os valores básicos das propriedades são suportados. Agregações como um valor médio, mínimo ou máximo não são suportadas.
    • Regras que exigem condições de 'AND' não são suportadas (por exemplo, o índice de travagem para uma pista é superior a 0,8 e a temperatura da superfície é < 40).

Limitações de comportamento da linguagem e do modelo

  • Os agentes de operações dependem de um grande modelo de linguagem (LLM). Os resultados são probabilísticos e podem estar incorretos, por isso é importante rever cuidadosamente os resultados e recomendações que fornecem. Para mais informações, consulte Privacidade, segurança e uso responsável do Copilot para Real-Time Inteligência.
  • Atualmente, os agentes de operações apenas suportam a língua inglesa para instruções e objetivos empresariais.

Limitações de tempo de execução

  • O agente faz consultas a cada cinco minutos quando está ativo.
  • As operações expiram se nenhuma ação for tomada no prazo de três dias. Após a expiração, as ações já não podem ser aprovadas.

Permissões e limitações de acesso

  • O agente opera usando a identidade delegada e as permissões do seu criador. Isto significa:
    • As consultas e ações utilizam as credenciais do criador.
    • Por defeito, o criador recebe mensagens de recomendação. Mudar o destinatário não altera as credenciais usadas para consultas e ações.

Limitações das mensagens e do estrangulamento

  • O uso intensivo pode resultar em limitação das mensagens. Nestes casos, mensagens simplificadas não geradas por LLM podem ser enviadas no Microsoft Teams.

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

  • O agente de operações está disponível nas regiões Microsoft Fabric da cloud pública Azure, excluindo o Centro-Sul dos EUA e o Leste dos EUA.
  • O agente de operações não está atualmente disponível nas nuvens soberanas, incluindo GCC-High e Bleu.
  • O agente de operações não é atualmente suportado em áreas de trabalho encriptadas com chaves geridas pelo cliente para áreas de trabalho do Fabric.
  • Last updated on