Engenharia do comportamento agêntico

Grandes modelos de linguagem (LLMs) são por natureza não determinísticos. A mesma entrada pode nem sempre produzir a mesma saída. Os métodos tradicionais de teste têm dificuldade em compensar esta variabilidade. Como pode adaptar o seu processo de desenvolvimento para ter confiança de que o seu sistema funcionará consistentemente como esperado?

A transformação da IA empresarial levanta mais questões: Como proteger e governar o conhecimento proprietário? Como é que se concebe um comportamento fiável? Como é que se usa a evidência de execução para melhorar o sistema ao longo do tempo?

A engenharia do comportamento agential (ABE), conforme proposto neste artigo, é uma metodologia independente da plataforma para especificar, fundamentar, controlar, verificar e observar o comportamento de agentes de IA. A metodologia ajuda-o a clarificar as necessidades do utilizador e do sistema, definir os resultados esperados, impor limites de execução e verificar alterações em cenários representativos. Os testes tradicionais podem confirmar que uma implementação específica funciona como esperado, mas muitas vezes falham em detetar totalmente a deriva comportamental causada por alterações em modelos, prompts, ferramentas ou fontes de dados. A ABE aborda este desafio tornando o comportamento desejado explícito e continuamente verificável, permitindo às equipas evoluir sistemas agentivos sem perder a confiança nos seus resultados.

Conceitos-chave

O artefacto chave no ABE é o contrato de comportamento. O contrato define o comportamento exigido separadamente da implementação, de modo a que as expectativas permaneçam explícitas e verificáveis à medida que o sistema muda. Em sistemas agênticos, modelos, prompts, implementações de ferramentas, fontes de conhecimento, memória, políticas, orquestração e acesso do utilizador podem todos mudar ao longo do tempo. Use behavior contracts para avaliar o efeito dessas alterações no comportamento necessário, identificando a deriva e tratando-a.

Behavior contract

Um contrato de comportamento define o que um agente deve e não deve fazer numa situação delimitada. Especifica:

• A situação, os intervenientes e o âmbito em que o contrato se aplica.
• Desfechos aceitáveis e características dos resultados exigidas.
• Conclusões, divulgações de informação, ações e efeitos secundários que são proibidos.
• Prova necessária antes de o agente poder concluir ou agir.
• Comportamento quando a evidência é insuficiente ou as dependências falham.
• Escalonamento, aprovação e condições de paragem.

O contrato torna explícitos os requisitos de segurança e IA responsável aplicáveis. Defina estes requisitos durante o design para que a sua equipa os possa incorporar na implementação e verificação desde o início. Para orientações sobre a definição de responsabilidades e políticas específicas de cada carga de trabalho, consulte Responsible AI in Azure workloads.

Um contrato de comportamento partilha um princípio com o design by contract: tornar explícitas as obrigações do software. Define o comportamento necessário sem prescrever uma implementação, para que os requisitos possam manter-se estáveis à medida que a implementação muda.

Use um contrato para uma situação delimitada e múltiplos cenários para as suas variações. Crie outro contrato quando os intervenientes, autoridade, provas exigidas ou resultados aceitáveis mudarem materialmente.

As equipas de produto e engenharia mantêm conjuntamente o contrato de comportamento como um ativo versionado. O product owner, apoiado por especialistas do domínio, aprova o comportamento pretendido e os resultados esperados. A equipa de Engenharia define em conjunto as restrições técnicas e os requisitos de evidência, mantendo definições de cenários testáveis, cobertura, versionamento e verificação.

Revê as alterações às expectativas comportamentais em conjunto e realiza uma revisão de segurança e risco quando necessário. A manutenção técnica que preserva essas expectativas deve seguir o processo de revisão de engenharia da equipa. Para orientações relacionadas, consulte propriedade da especificação funcional e responsabilidades da estratégia de teste.

Exemplo: Aprovar avaliações de produtos de baixo risco

Um site de retalho exige que a sua equipa de normas verifique as avaliações de produtos dos clientes em relação a uma política de utilização aceitável antes da publicação. A equipa de workload quer que um agente aprove submissões de baixo risco e envie casos de maior risco ou incertos para a equipa de padrões. O objetivo é reduzir a revisão manual mantendo os padrões de publicação do site.

A tabela seguinte apresenta um contrato de comportamento versionado para este agente.

Pode guardar o contrato em JSON, YAML, Markdown, um documento Word ou PDF. Escolha um formato que os seus product owners, especialistas de domínio e engenheiros possam rever e controlar versões em conjunto. JSON ou YAML podem facilitar a leitura de campos individuais por parte das ferramentas. Qualquer que seja o formato que escolheres, mantém uma versão autoritativa e liga os cenários e resultados das avaliações a ela.

Neste exemplo, a política permite feedback negativo do produto e exige a revisão humana das submissões que contenham informações pessoais. Um cliente envia:

A bateria durou apenas uma hora. Eu não o compraria outra vez.

A decisão esperada é aprovar a submissão. O registo da decisão cita a regra de política aplicável e explica que o texto descreve uma experiência de produto e não contém conteúdo que exija revisão humana ao abrigo desta política.

Se a submissão incluir informações pessoais, a decisão esperada é enviá-la para revisão humana e mantê-la não publicada. Se a política atual não puder ser recuperada, a submissão também permanece por publicar.

A aplicação faz cumprir as permissões e verifica a submissão antes de publicar uma avaliação aprovada. Para avaliar a decisão do agente, compare-a com a decisão esperada da equipa de normas para essa submissão.

Cenários

A biblioteca de cenários transforma o contrato de comportamento em cenários concretos de utilizador. Cada cenário define uma consulta ou tarefa, condições de evidência e dependência, e um resultado esperado. Aplica o contrato comportamental sem alterar os requisitos do contrato.

Especialistas em produto e domínio validam cenários e resultados esperados. A engenharia mantém as definições e a cobertura do contrato.

A tabela seguinte mostra como a biblioteca de cenários aplica o contrato de comportamento a situações representativas para o agente de análise de produto:

Comece a testar com casos sintéticos: envios fictícios e respostas simuladas de policy-service. A recolha de dados de referência pode impedir a equipa de engenharia de concluir a implementação das funcionalidades. Os casos sintéticos expõem lacunas no contrato ou na implementação e dão tempo aos especialistas de domínio para concluir a curadoria dos dados de referência.

Utilize casos sintéticos para orientar peritos na matéria (SMEs) na recolha de casos reais de carga de trabalho para um conjunto de dados de referência separado. O conjunto de dados dourado expande os cenários usando a mesma estrutura: consultas reais, evidências correspondentes e resultados esperados validados pelos SME. Um cenário pode ter muitos casos dourados.

No cenário de revisão negativa, a equipa de normas recolhe submissões reais que criticam um produto mas cumprem a política de publicação. Eles preservam as entradas de teste aprovadas e a versão da política aplicável, estabelecendo depois a decisão esperada. Coleção de guias sobre casos sintéticos. Não são promovidos para o conjunto de dados dourado.

A verdade de referência é um resultado esperado validado pelo domínio ou uma evidência de apoio onde a correção pode ser estabelecida, não a saída registada de um agente. Veja Utilizar os dados corretos para avaliação.

Utilize os cenários durante uma prova de conceito para comparar implementações com o mesmo contrato e limites de custo e latência. No agente de revisão de produto, testarias as decisões de aprovação e os encaminhamentos em relação aos resultados esperados pela equipa de normas. Registar o design e os compromissos num registo de decisão de arquitetura, e guardar os cenários para testes de regressão.

Liga cada caso ao seu cenário e versão contratual, e regista se é sintético ou se provém de dados reais de carga de trabalho. Mantenha os cenários independentes dos prompts para que o comportamento necessário permaneça testável à medida que a implementação muda.

Adicionar casos de fronteira e falhas de produção revistas. Se os limites de segurança estiverem dentro do âmbito, inclua cenários de injeção de prompts, uso indevido e exfiltração através do red teaming da IA e modelação de ameaças.

Mantenha os conjuntos de desenvolvimento, regressão e de versões protegidas separados. Reserve alguns casos de teste para verificação da versão e não os use para desenvolver ou ajustar a implementação. Restringir o acesso a estes casos e aos seus resultados esperados. Se um caso orientar uma alteração de implementação, move-o para o conjunto de regressão e substitui-o por outro caso validado por especialistas do domínio.

Limites de funcionamento

Os limites operacionais cobrem um subconjunto dos requisitos não funcionais da carga de trabalho. Define os limites de recursos e execução, como latência, custo, utilização de tokens, tentativas, chamadas de ferramentas e tempo de espera por aprovação.

O contrato define o comportamento correto. O invólucro define os limites operacionais dentro dos quais o sistema deve operar. Um contrato pode referenciar uma versão de envelope operacional quando esses limites fazem parte dos seus critérios de aceitação. Versionar o envelope de forma independente para que os limites operacionais possam mudar sem redefinir requisitos comportamentais que não mudaram. Os contratos comportamentais e os limites de funcionamento não exigem uma relação um para um.

Repetição

Estrutura para reprodução

O Replay, como o nome indica, reexecuta os passos de inferência do seu sistema fornecendo respostas recolhidas de ferramentas e APIs ou resultados RAG. Esta abordagem ajuda-o a ajustar o seu prompt e a identificar quaisquer provas em falta. Evita chamadas repetidas para APIs ativas ou ferramentas do Model Context Protocol (MCP), que podem ser dispendiosas, limitadas por taxa ou devolver dados que mudam ao longo do tempo.

Recolhe dados de replay em produção. Remover ou mascarar dados sensíveis de acordo com a política antes da análise ou revisão por SME. Preservar os payloads de resposta e os seus argumentos do pedido sem alterar o significado da caixa. Se a tarja remover as provas necessárias, utilize um dispositivo aprovado e documente a limitação.

Peça a um especialista no assunto para rever e selecionar os dados derivados da produção antes de os adicionar ao conjunto de dados de referência ou de os usar para criar dublês de teste. Os dublês de teste podem simular respostas, pelo que o replay pode suportar cenários novos e existentes sem exigir dados de produção. Consulte Respostas simuladas com o Dev Proxy e Conjuntos de dados de avaliação no Microsoft Foundry.

Configurar e executar a reprodução

Controle as versões dos conjuntos de dados de replay que usas para avaliação e testes de regressão. Para comparar uma atualização com a linha base, execute ambas as implementações contra a mesma versão do conjunto de dados, usando os mesmos casos e versões do avaliador. Mantém as outras condições de teste consistentes, exceto pela alteração que estás a testar. Quando adicionar ou rever casos, crie uma nova versão do conjunto de dados e execute ambas as implementações.

Durante o desenvolvimento, podes repetir um conjunto menor de casos para verificar o comportamento que estás a mudar. Se ainda não tiver respostas gravadas para um novo cenário, use respostas simuladas e rotule-as no conjunto de dados.

Escolha o propósito da execução:

A configuração de execução vai além do conjunto de dados e dos avaliadores. Inclui também prompt, modelo, servidores API/MCP, bibliotecas de suporte e muito mais. Ao realizar avaliações, é necessário ter uma hipótese clara e alterações correlacionadas para garantir que cada execução altera apenas um conjunto mínimo. Isto permite-lhe avaliar corretamente o impacto e evitar repetir a mesma atualização várias vezes devido a falhas na manutenção de registos.

Replay não substitui os testes unitários ou de integração. Cada teste verifica um aspeto diferente do sistema de software, e todos são igualmente importantes. Consulte Testar e avaliar cargas de trabalho de IA.

O diagrama seguinte mostra o processo de shared replay.

Exemplo: Verificar uma alteração de agente de avaliação de produtos

Suponha que a versão 42 do agente de revisão de produto aprova uma submissão que deveria ter ido para a equipa de normas porque contém informações pessoais. A equipa prepara o caso utilizando as salvaguardas de dados de replay e utiliza um teste de desenvolvimento focado enquanto revê a implementação do candidato 43.

1. Configure uma execução de avaliação para o candidato 43. O conjunto de dados de avaliação deve incluir casos normais, bem como avaliações negativas em conformidade, envios incertos e falhas de dependência. Atualize-a com casos de teste que validem a funcionalidade (regra de informações pessoais). A atualização cria uma nova versão do conjunto de dados. Executar a avaliação e a baseline no novo conjunto de dados. Reproduza o conjunto de dados completo para medir a precisão, custo e latência das decisões por cenário.

2. Atualize o conjunto de dados de verificação de lançamentos com o novo caso de uso e obtenha uma versão atualizada. Consulte a versão expandida do conjunto de dados e defina limiares de aceitação. Reproduzir o candidato 43 e a linha de base 42 com o mesmo conjunto expandido e as evidências registadas.

3. Verifique os casos existentes e novos em relação às expectativas analisadas. Pode esperar approve para feedback negativo conforme e human_review para submissões que contenham informações pessoais. Confirme que as submissões que aguardam revisão humana permanecem não publicadas.

4. Guardar resultados e rastreios por caso com a sua versão de configuração. Calcule métricas para cada cenário. Utilize os resultados da avaliação para melhorar a implementação e divulgue os resultados da verificação da versão para decidir se o candidato pode ser lançado. Uma melhoria geral não anula um requisito obrigatório falhado.

Architecture

Para usar a metodologia ABE para desenhar as funcionalidades da sua carga de trabalho, comece pela descoberta de problemas e capture o comportamento esperado num contrato. De seguida, decida se a carga de trabalho necessita de execução dirigida pelo agente. Trabalhe com o responsável pelo negócio e a equipa de engenharia para clarificar as necessidades e pressupostos dos utilizadores. Deriva cenários a partir dos contratos de comportamento, identifica o conhecimento e as evidências que o sistema necessita e decide quais os controlos que o sistema circundante deve aplicar.

O contrato comportamental e a biblioteca de cenários ligam o sistema de dois ciclos e orientam a implementação e melhoria. O developer inner loop verifica as alterações antes do lançamento. O ciclo externo de produção recolhe evidências de execução e feedback para identificar falhas ou requisitos alterados.

O ABE organiza este trabalho em cinco responsabilidades de engenharia: especificar, fundamentar, controlar, verificar e observar. Estas responsabilidades são lógicas, não cinco serviços obrigatórios ou passos sequenciais de execução. Trabalhar numa única funcionalidade pode abranger várias responsabilidades.

A IA responsável e a segurança são preocupações transversais em todas as cinco responsabilidades do sistema. A responsabilidade de especificar torna explícitas as expectativas de IA responsável e os requisitos de segurança nos contratos de comportamento. A responsabilidade de controlo implementa as regras de acesso e salvaguardas de execução que suportam esses requisitos.

Especificar e fundamentar proporcionam verificações iniciais sobre a prontidão e a viabilidade do projeto. Especificação estabelece o problema e o que significa sucesso. Ground avalia se a informação exigida está disponível e é utilizável ao abrigo dos requisitos de acesso aplicáveis. Utilize estes resultados para identificar lacunas antes de se comprometer com a implementação e depois valide as suposições restantes numa prova de conceito. Para mais informações, consulte Alinhar a estratégia técnica com os requisitos de negócio.

Utilize o contrato de comportamento e a biblioteca de cenários para comparar conceções viáveis. Uma implementação determinística ou um fluxo de trabalho fixo com passos assistidos por modelo pode satisfazer os requisitos. Escolha uma abordagem agêntica quando a avaliação demonstrar benefícios que justificam o seu custo adicional, latência e complexidade operacional. Para orientações sobre a escolha de uma abordagem de execução, veja fluxos de trabalho fixos versus sistemas dirigidos por agentes.

Especificar

Utilize o design thinking para compreender a necessidade real do utilizador antes de escolher o que e como automatizar. Trabalhe com utilizadores, responsáveis do negócio e especialistas no assunto para concordar sobre resultados aceitáveis, restrições e comportamentos de falha.

Capture estes requisitos num contrato de comportamento versionado e derive cenários de teste para criar a biblioteca de cenários. As equipas de produto e engenharia analisam as alterações ao comportamento esperado em conjunto. Para abordar preocupações com IA responsável e segurança, envolva especialistas em domínio, especialistas em risco e especialistas em segurança. Controle as versões tanto do contrato de comportamento como da biblioteca de cenários. As notas de atualização devem identificar o contrato suportado e publicado e a versão suportada e publicada da biblioteca de cenários.

Analise as alterações aos requisitos juntamente com o roteiro do produto e reavalie a implementação em relação a elas. Para cargas de trabalho multi-agente, defina um contrato de ponta a ponta e adicione contratos de passagem onde as responsabilidades, requisitos de prova ou permissões mudem.

Para o agente de avaliação de produto, concorde com a equipa de normas sobre quais submissões qualificam para aprovação automática, quando é necessária uma revisão humana e como lidar com uma política ou fila de revisão indisponível.

O diagrama seguinte mostra como o contrato de comportamento e a biblioteca de cenários orientam a implementação e verificação. Utilize a biblioteca de cenários para orientar a curadoria de conjuntos de dados dourados e definir critérios de avaliação. Apresente os resultados por cenário, incluindo o número de casos testados, para que uma pontuação global não esconda as lacunas. As constatações revistas da avaliação e produção podem levar a atualizações na biblioteca de cenários ou no contrato comportamental.

Para técnicas de descoberta, consulte Conduzir investigação com utilizadores e partilhar as conclusões.

Terreno

Fundamenta o conhecimento e a evidência que fornece ao seu agente, incluindo informações recuperadas, respostas à ferramenta, regras de negócio e memória. Prepara informação relevante e autorizada para cada tarefa, preservando a sua fonte e autoridade. Procedência, atualidade e sensibilidade são alguns atributos-chave que precisam de ser devidamente representados.

Para preparar informação governada para o agente:

• Selecione fontes fidedignas e designe os proprietários para as manter.
• Identificar os requisitos de acesso e preservar os metadados de permissão e sensibilidade para a responsabilidade de controlo.
• Prepare as informações de forma que o agente as possa utilizar sem perder o seu significado de negócio, fonte ou versão.

Durante a conceção, certifique-se de que as fontes conseguem fornecer as evidências que o contrato comportamental exige. Para o agente de avaliação de produto, ligue cada avaliação ao texto completo da submissão, à sua revisão e à versão aplicável da política. Se a evidência necessária estiver em falta ou inacessível, resolva a questão dos dados ou do acesso, restrinja o âmbito ou adie a funcionalidade afetada.

Em tempo de execução, a camada de recuperação reporta se uma consulta devolveu dados, não encontrou correspondências ou falhou. A aplicação utiliza esse estatuto, juntamente com os metadados das provas, para determinar se deve avançar ou seguir a resposta definida no contrato em caso de prova insuficiente.

Mantém as definições e regras de negócio em assets versionados e pertencentes à carga de trabalho, independentes de prompts e modelos. Utilize um contrato de dados ou modelo semântico para definir a estrutura e o significado da informação trocada com outros agentes e sistemas.

A tabela seguinte distingue definições empresariais de evidências para um pedido específico. Uma plataforma de ontologia ou modelo semântico pode ajudar a organizar estas definições quando agentes e sistemas precisam de conceitos e relações de negócio partilhadas.

Para exemplos de implementação, veja Fabric ontology data binding (preview) e modelos semânticos do Power BI.

Pode estabelecer um motor de regras ou fluxo de trabalho para aplicar regras de negócio em código determinístico antes de passar os resultados ao agente. Teste estas regras repetidamente contra casos revistos por especialistas do domínio para verificar se a implementação corresponde à política pretendida e reduzir a incerteza da implementação.

Ao reunir o contexto, identifique a fonte e a autoridade da orientação empresarial, a evidência atual e a informação armazenada. Defina o que o agente pode escrever na memória e durante quanto tempo a reter. A memória não deve sobrepor-se a registos autoritativos e não pode ser tratada da mesma forma que prompts ou instruções.

O diagrama seguinte mostra como preparar e combinar conhecimento, evidência e memória para o agente.

Controlo

O controlo protege a carga de trabalho através da autenticação, autorização e governação em tempo de execução. Estabelece quem pode aceder ao sistema, o que cada autor da chamada e agente pode fazer, e quais as ações que requerem aprovação. Faça cumprir estas decisões no código da aplicação e nos serviços ligados, não no modelo.

Siga as melhores práticas de segurança e realize modelação de ameaças para decidir quais as salvaguardas em tempo de execução a implementar. Um diagrama de fluxo de dados (DFD) mostra como a informação se move entre chamadores, agentes, ferramentas e depósitos de dados, incluindo onde cruza fronteiras de confiança. Utilize essa análise para determinar onde aplicar verificações de acesso, restringir a partilha de dados e exigir aprovações.

Estes limites de confiança fazem parte da sua defesa contra ataques. Por exemplo, conteúdos recuperados ou respostas de ferramentas podem conter instruções maliciosas. As verificações de acesso e as etapas de aprovação devem continuar a aplicar-se se o modelo seguir essas instruções. Siga os princípios de defesa em profundidade e Confiança Zero. Combine estes controlos com outras defesas contra a injeção de prompts, em vez de considerar uma única salvaguarda como suficiente.

Autentique as identidades do chamador e do agente, e depois autorize cada acesso a dados e ação da ferramenta para a sua tarefa e recurso alvo. Aplicar o privilégio mínimo e impor os requisitos de acesso identificados na responsabilidade terrestre. Ao delegar trabalho, preserve o contexto de autorização do interlocutor e as referências de evidência, e verifique novamente as permissões em cada transferência. A delegação não deve expandir a autoridade. Se o acesso for negado, siga o caminho definido de paragem ou de escalamento em vez de contornar a recusa através de outra ferramenta ou agente.

A governação em tempo de execução também aplica as aprovações exigidas, passos obrigatórios do fluxo de trabalho e limites do envelope operacional, como orçamentos e limites de taxa. Repita apenas operações que sejam seguras para repetir. Quando um limite é atingido, siga o comportamento de paragem ou de contingência do contrato. Estes controlos complementam o design mais amplo de resiliência da carga de trabalho.

No exemplo do agente de avaliação de produto, o acesso está limitado à submissão atribuída, política aplicável e ações de moderação. O fluxo de trabalho de publicação verifica as permissões, a revisão da submissão e a versão da política antes de publicar uma revisão aprovada. Mantenha as alterações de políticas e as ações da conta do cliente fora das permissões do agente.

O diagrama seguinte mostra como as ações propostas são avaliadas e registadas.

Para um exemplo de recuperação de informação, veja Conceber uma solução segura de inferência RAG multitenant. Para orientações sobre identidade e proteção em camadas, veja Identidade, acesso, menor privilégio e princípios de design de segurança.

Para exemplos de controlos de execução implementados através da orquestração de fluxos de trabalho, veja Padrões multiagente orientados para fluxos de trabalho.

Verificar

O Verify combina verificações de caso único com avaliação ao nível do conjunto de dados no ciclo interno do programador.

Verifica um único caso

Durante a implementação, execute ou reproduza um caso de teste usando respostas gravadas ou simuladas. Inspecionar o rastreio de execução para comparar as evidências, chamadas de ferramentas, decisões de controlo e resultado com o contrato de comportamento e o cenário. Utilize os resultados para depurar e refinar a implementação.

Evaluations

Execute avaliações num conjunto de dados versionado para medir o comportamento nos cenários suportados. Defina métricas e limiares de aceitação a partir do contrato de comportamento. A tabela seguinte descreve cenários e medidas associadas para o agente de revisão de produtos.

Compare o candidato e a referência usando o mesmo conjunto de dados e as mesmas versões do avaliador. Para mais informações, consulte Configurar e executar a reprodução.

Reporte os resultados por cenário para que as pontuações agregadas não escondam regressões. Repita os casos de teste para verificar a consistência. Defina o número de execuções e critérios de aceitação antes da avaliação. Registar o contrato de comportamento, o conjunto de dados, o avaliador e as versões do limiar com os resultados.

Testar casos de longa duração e comportamentos de falha nos limites de operação. Defina contagens de passos e chamadas de ferramenta, mas exija um caminho exato apenas quando o contrato o especifica. Para cargas de trabalho multi-agente, teste as transferências, bem como os resultados de ponta a ponta.

Faz estas verificações juntamente com testes unitários e de integração. Bloquear lançamentos que não cumpram os limiares exigidos dos cenários. Para orientações sobre o lançamento, consulte a lista de verificação do percurso de adoção.

Observar

Observe analisa as execuções de produção para identificar comportamentos bem-sucedidos, falhas e as suas causas. O sistema deve recolher feedback dos utilizadores para facilitar a análise. Comece a análise com a classificação de cenários:

1. Classificar as execuções gravadas usando o contexto da tarefa e da execução. Associe cada execução ao cenário e às versões contratuais aplicáveis. Assinale casos pouco claros ou ambíguos para revisão.

2. Compare o resultado com o comportamento esperado do cenário e combine essa informação com o feedback dos utilizadores para avaliar o sucesso ou o fracasso. Deixar os casos por avaliar quando as provas são insuficientes.

3. Investigue falhas utilizando rastreios e feedback dos revisores. Agrupe os achados por causa, como lacunas de conhecimento, falhas de implementação ou de dependência, ou requisitos pouco claros.

4. Peça aos product owners, especialistas de domínio e engenheiros para reverem as conclusões e decidirem o que mudar. Valide os resultados esperados antes de adicionar casos de teste preparados à cobertura de regressão. Regista o motivo de cada alteração e verifica-o antes do lançamento.

No exemplo do agente de avaliação de produto, encaminhar uma submissão que contém informação pessoal para revisão humana, mantendo-a não publicada, é um comportamento bem-sucedido. Aprová-lo é um exemplo de falhança. Um pedido para apoiar revisões de imagens identifica, em vez disso, uma possível alteração de âmbito.

Capturar a entrada da tarefa, pedidos e respostas à ferramenta, conteúdo recuperado fornecido ao modelo e saída. Preservar as versões fonte, controlar decisões e falhas. Liga o feedback dos utilizadores e dos críticos à execução e ao lançamento. Minimize os dados capturados, aplique limites de acesso e retenção, e siga as orientações de preparação de dados de reprodução antes da análise ou curadoria do conjunto de dados.

Para um exemplo de ligação dos resultados de produção à avaliação, veja o ciclo de qualidade de observabilidade do agente.

Lista de verificação do percurso de adoção

Começa com uma implementação mínima viável em torno de um comportamento com impacto relevante na tua carga de trabalho.

A menor implementação útil de ABE não é uma plataforma. É um comportamento que é explícito, reproduzível, avaliado e condicionado. O primeiro ciclo de funcionamento consiste em especificar e verificar. Evite construir uma plataforma abrangente antes que a equipa possa usar um contrato para prevenir, detetar ou diagnosticar um problema comportamental real.

1. Selecione uma situação limitada e com impacto, identifique os seus responsáveis de produto e de engenharia, envolvendo especialistas do domínio.
2. Escreva um contrato de comportamento validado, incluindo evidências e estados de falha.
3. Defina cenários para casos normais, de limite, de evidência insuficiente e de falha de dependência. Gera casos sintéticos a partir destes cenários para começar os testes.
4. Utilize os casos sintéticos para orientar os especialistas no assunto na recolha e curadoria de casos reais de carga de trabalho para um conjunto de dados de referência separado.
5. Capturar ou simular respostas estáveis de ferramentas e conhecimento para reprodução.
6. Adicione verificações determinísticas e apenas os avaliadores baseados em julgamento exigidos pelo contrato.
7. Execute os cenários em integração contínua e bloqueie lançamentos em caso de falhas críticas.
8. Registar informação suficiente das execuções de produção para identificar o contrato, implementação, caminho da evidência e resultado.
9. Transformar as descobertas de produção analisadas em cenários de regressão.

Alterações nos prompts, definições do modelo e código da aplicação podem alterar o comportamento do agente. Valide estas alterações antes de as usar em produção. Regista as versões que testaste, a configuração da avaliação e os resultados. Siga práticas de implementação segura para introduzir mudanças gradualmente e planeie como recuperar a situação caso causem problemas. Inclua alterações de configuração no plano de recuperação.

Aproveita este primeiro ciclo à medida que vais aprendendo o que a tua carga de trabalho precisa. Quando agentes e sistemas precisam de definições e relações de negócio partilhadas, um modelo semântico de dados pode fornecer essa base. Quando as decisões seguem regras de negócio explícitas, um motor de regras pode aplicar essas regras fora do modelo. Mantém os controlos de acesso e as provas de execução que a tua carga de trabalho exige desde o início, e depois expande a monitorização e automação conforme os riscos e as conclusões de produção o justificam.

Implementar ABE no Azure

O ABE é independente da plataforma. O Azure fornece serviços que pode utilizar para apoiar as cinco responsabilidades de engenharia do Azure.

O diagrama seguinte mapeia cada responsabilidade ABE para os serviços do Azure a considerar para a sua carga de trabalho.

Para cada responsabilidade de engenharia, combine as capacidades do Azure com os contratos, controlos e processos de revisão que a sua equipa mantém.

Antes de escolher qualquer serviço Azure, verifique se as suas funcionalidades, regiões e APIs se encaixam na sua carga de trabalho. Prefira serviços de disponibilidade geral (GA) e controlos próprios da aplicação para verificações obrigatórias de imposição e de lançamento. Algumas das funcionalidades mencionadas nas secções seguintes são funcionalidades de pré-visualização e podem não ser adequadas para a sua carga de trabalho.

Especifique no Azure

Guarde contratos, cenários, envelopes operativos e configurações de replay no seu repositório Git existente, por exemplo, Repositórios do Azure ou GitHub. Cumpra as responsabilidades de revisão partilhada quando uma alteração afeta o comportamento esperado. Use a análise de engenharia para manutenção técnica.

Ground no Azure

Ligue o agente às fontes autorizadas que identificou para a responsabilidade no terreno . Para o agente de avaliação de produto, começa-se com as APIs de aplicação existentes do site para recuperar submissões e a política atualmente aprovada.

Quando precisar de recuperação entre fontes de conhecimento, considere a agentic retrieval do Pesquisa de IA do Azure. Pode devolver conteúdo de grounding com referências opcionais de origem e um registo de atividade. Meça o custo e a latência da abordagem de recuperação que escolher.

Se os dados do seu negócio já estiverem no Microsoft Fabric, a ferramenta Fabric IQ pode ligar agentes da Microsoft Foundry a modelos semânticos e itens de ontologia. A capacidade de integração e a capacidade de ontologia estão em pré-visualização. Verifique como a ligação se autentica, a que dados pode aceder e se os dados podem sair do limite de conformidade do Azure.

Versione as definições semânticas separadamente da implementação do agente e registe as suas versões com a evidência de teste. A integração do Fabric Git suporta itens de ontologia em pré-visualização.

Controlo e execute no Azure

Pode executar agentes de prompt e agentes hospedados personalizados no Foundry Agent Service. Para outros requisitos de runtime ou deployment, considere AKS, Azure Container Apps ou Serviço de Aplicações do Azure. Consulte Escolher um serviço de computação do Azure para comparar opções. Implemente as suas regras de autorização, aprovação e execução na aplicação e nos serviços relacionados.

Para agentes Foundry, use identidades de agentes Microsoft Entra para ligações MCP suportadas e ligações de agente para agente. Quando o agente atua em nome de um utilizador, verifique tanto a autoridade do utilizador como a autoridade do agente. Antes do lançamento, verifique a identidade e as permissões que o agente irá usar em tempo de execução.

O API Management do Azure pode governar endpoints MCP partilhados através de políticas de autenticação, limites de taxa e quotas. Utilize o middleware do Agent Framework para adicionar verificações próprias da aplicação para ferramentas de função que o framework executa. Para ferramentas que funcionam fora deste limite, aplique autorização e política obrigatórias num gateway ou serviço a jusante.

Quando uma ação necessita de confirmação humana, utilize function-tool approval. Se as aprovações de workflow tiverem de sobreviver a um reinício, configure o armazenamento persistente de checkpoint e restaure o estado de aprovação pendente antes de permitir a execução. Para ferramentas que mudam de estado, valide as entradas e adicione salvaguardas de idempotência no executor de ação. Orquestração de versões e definições de controlo da implementação.

O Prompt Shields no Segurança de conteúdo de IA do Azure pode detetar tentativas de injeção de prompts em prompts de utilizador e documentos de grounding. Combine estas verificações com a autorização. Defina como a carga de trabalho responde ao conteúdo bloqueado no contrato de comportamento e teste essa resposta.

Para o agente de revisão de produto, é concedido acesso à leitura às submissões atribuídas e à política atual. O acesso por escrita é restrito às operações de moderação que aprovam uma submissão ou a encaminham para revisão humana. As verificações de submissão e de versão da política são aplicadas no fluxo de trabalho de publicação.

Validar no Azure

Pode armazenar casos de reprodução preparados e resultados de testes no Armazenamento de Blobs do Azure. Faça referência a versões específicas do conjunto de dados nas suas configurações de replay e ligue casos derivados da produção às suas execuções de origem. Restringir o acesso a casos reservados protegidos e a provas de produção preservadas. Siga as orientações da arquitetura do Armazenamento de Blobs para acesso baseado em identidade, proteção de dados e retenção.

Ao utilizar conjuntos de dados de avaliação do Foundry, pode pontuar respostas concluídas ou enviar inputs a um agente para gerar e avaliar novas respostas. Para uma reprodução controlada, configure os adaptadores de dependência antes de invocar o agente. Publique conjuntos de dados como cópias de execução da sua biblioteca de cenários governados e aplique as mesmas restrições de acesso de holdout.

Utilize verificações determinísticas para critérios com valores de referência explícitos ou regras, e utilize avaliadores baseados em modelos para critérios baseados em julgamento. Os avaliadores personalizados da Foundry suportam ambas as abordagens, bem como endpoints externos de pontuação.

Para o agente de revisão de produto, uma verificação baseada em código pode comparar a decisão estruturada com a decisão esperada da equipa de normas. Um avaliador baseado em modelos pode avaliar se a explicação e a regra de política citada apoiam essa decisão, tendo em conta o texto submetido. Avaliadores de rubricas e avaliadores personalizados estão em pré-visualização.

Verifique a compatibilidade da ferramenta de avaliação antes de usar as pontuações num gate. Para conversas que contenham chamadas de agentes de dados Pesquisa de IA do Azure ou Fabric, não use os resultados de tool_call_accuracy, tool_input_accuracy, tool_output_utilization, tool_call_success ou groundedness. Utilize asserções contratuais determinísticas ou outro método de avaliação suportado.

Guardar resultados e trilhas por caso com a configuração que os produziu. Aplicar limiares de lançamento no pipeline e bloquear o lançamento se um cenário necessário falhar. Utilize os mesmos casos e versões do avaliador ao comparar implementações. Se treinar modelos personalizados no Azure Machine Learning, inclua as suas versões na configuração.

Observe no Azure

O Foundry Tracing utiliza o recurso Azure Monitor Application Insights que está ligado ao projeto. Adicione instrumentação à ferramenta e ao código de recuperação da sua aplicação para recolher qualquer prova adicional de que precise.

Decida que conteúdo pretende gravar. A integração de rastreamento do lado do cliente da Foundry inclui definições para gravar o conteúdo das mensagens. Verifique se a sua instrumentação capta as respostas da ferramenta necessárias e o conteúdo recuperado, juntamente com os nomes das operações e os tempos. Minimize ou oculte payloads sensíveis antes da exportação de telemetria e mantenha apenas a evidência permitida pela sua política de dados.

Considere utilizar a avaliação de traces (pré-visualização) para avaliar os vestígios de Application Insights retidos que cumpram os requisitos de saneamento. Avalia as interações existentes sem repetir pedidos, incluindo rastreios OpenTelemetry suportados de agentes fora do Foundry. Utilize estas pontuações para investigar o comportamento de produção e depois verifique quaisquer alterações resultantes na implementação através de reprodução e avaliação antes do lançamento. Esta funcionalidade está em pré-visualização pública, não tem acordo de nível de serviço e não é recomendada para cargas de trabalho em produção. Não dependas dele para monitorização de produção ou decisões de publicação.

Use consultas do Log Analytics e alertas do Azure Monitor para investigar falhas comportamentais e violações do envelope operacional. A vista de detalhes do Application Insights Agent, atualmente em pré-visualização, pode ajudá-lo a investigar execuções individuais. Introduza as conclusões revistas e os casos preparados no próximo ciclo de alteração e repetição.

Contributors

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Principais autores:

• Yang Song | Engenheiro Principal de Software

Outros contribuidores:

• Chad Kittel | Engenheiro de Software Principal
• Bryan Ostdiek | Principal Cientistas de Dados
• Peter Parker | Engenheiro Principal de Soluções, Azure AI Cloud Estratega e Arquiteto
• Rama Pyarasani | Gestor de Engenharia Multidisciplinar em Implementação no Terreno
• Ronnie Yates | Diretor-Geral, Forward Deployed Engineering

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Passos seguintes

• Agentes no Microsoft Foundry
• Avalie os seus agentes de IA
• Recuperação baseada em agentes em Pesquisa de IA do Azure
• Monitorize agentes de IA com Insights de Aplicação
• Contratos Comportamentais de Agentes (artigo de investigação)

Recursos relacionados

• Padrões de design de agentes de IA
• Geração aumentada por recuperação agêntica
• Operações de aprendizado de máquina