Camada 4: Analisar padrões e melhorar continuamente o seu agente

Após a triagem das falhas em casos de teste individuais, podem ser aplicadas correções e ainda assim observar-se pouca ou nenhuma melhoria no desempenho geral do agente. Este resultado indica frequentemente um problema sistémico, não um conjunto de falhas não relacionadas.

A análise de padrões ajuda-o a olhar para vários casos de teste com falhas, de forma a identificar sinais recorrentes e causas raiz partilhadas. Utilize a análise de padrões para se concentrar nas alterações que resolvam grupos de falhas de uma só vez, em vez de corrigir cada falha isoladamente.

Importante

Utilize esta orientação depois de concluir a triagem de falhas e aplicar as medidas de remediação. A análise de padrões é mais útil após a triagem de pelo menos cinco falhas.

Quando utilizar a análise de padrões

A análise de padrões torna-se especialmente útil quando forem observadas uma ou mais das seguintes condições:

  • Muitas falhas no mesmo conjunto de avaliação.
  • Falhas repetidas com sintomas semelhantes.
  • Melhorias em casos de teste individuais que não alteram as classificações globais.
  • Melhorias numa área que causam regressões noutra.

Corrigir falhas uma a uma é ineficiente nestas situações. A análise de padrões permite identificar o que as falhas têm em comum, para que possa abordar a causa subjacente.

Análise de concentração

Após a classificação das falhas individuais, identifique padrões em todo o conjunto.

Padrão O que isso indica Ação recomendada
80% ou mais das falhas são problemas de configuração da avaliação O conjunto de avaliação precisa de calibração, não de alterações no agente Pausar iteração do agente. Faça uma auditoria e corrija a qualidade da avaliação primeiro e, em seguida, execute novamente o teste para obter um sinal limpo.
80% ou mais das falhas correspondem a problemas de configuração do agente numa área (por exemplo, todas relacionadas com conhecimento) Lacuna de configuração do agente sistémico Concentre a remediação nessa área. Este problema é frequentemente um problema arquitetónico (por exemplo, estrutura da fonte de conhecimento), e não correções isoladas de casos de teste.
80% ou mais das falhas devem-se a limitações da plataforma O agente atinge os limites da plataforma Reavalie o âmbito do agente. Escalar para a equipa da plataforma. Ajuste os limiares ou trate os itens afetados como limitações conhecidas, quando apropriado.
As falhas distribuem-se de forma uniforme entre tipos de causa raiz Nenhum problema sistémico isolado Continue a remediação caso a caso usando mapeamento de remediação.

Como fazer análise de concentração

  1. Contabilize as falhas classificadas por tipo de causa raiz:

    • Problemas de configuração da avaliação
    • Problemas de configuração do agente
    • Limitações da plataforma
    • Sem classificação

  2. Calcular a percentagem para cada tipo.

  3. Se algum dos tipos atingir 80% ou mais — indicando um problema sistémico — corrija a categoria, não os casos individuais.

  4. Se os problemas de configuração do agente se concentrarem num sinal de qualidade (por exemplo, cinco de seis são fundamentos de conhecimento), esse padrão aponta para uma causa raiz de arquitetura.

Padrões entre sinais

Quando as falhas abrangem múltiplos conjuntos de avaliação, geralmente apontam para uma causa raiz partilhada. Procure os seguintes padrões:

Padrão O que provavelmente indica O que investigar
A precisão factual e a fundamentação do conhecimento falham ambas Problema na fonte de conhecimento (errada, em falta, inacessível ou obsoleta) Configuração do conhecimento, estado de indexação e atualização do conteúdo
Falha da invocação de ferramentas e do encaminhamento de acionador Problema de configuração de orquestração - tópicos e ferramentas não estão devidamente ligados Revê como os tópicos encaminham para as ferramentas. Verifique se há fluxos desligados ou mal configurados.
Falha de tom mas passagem de precisão O agente apresenta a resposta certa, mas de forma inadequada Foque-se em instruções de estilo de pedido; a infraestrutura de precisão é sólida.
Passagem de segurança mas falha de precisão O agente pode estar sujeito a restrições excessivas — ser demasiado cauteloso, recusar-se a responder quando deveria Reveja as instruções de segurança quanto a restrições demasiado amplas que bloqueiam respostas legítimas.
Tudo passa, exceto em casos extremos O comportamento central é sólido Concentre-se em aumentar a robustez nas margens; este padrão é um bom sinal.
Melhoria da precisão acompanhada de degradação do tom Conflito de instruções — novas instruções de precisão podem estar a sobrepor-se às orientações de tom Reveja as alterações recentes nos pedidos e tenha em mente o "orçamento de instruções".
Múltiplos conjuntos de avaliação degradam-se simultaneamente Provavelmente uma única causa raiz com impacto amplo Verifique alterações recentes nos pedidos do sistema, atualizações das fontes de conhecimento ou atualizações do modelo da plataforma.

O que fazer com padrões de sinais cruzados

  1. Identifique a causa raiz partilhada: Se dois sinais falharem em simultâneo, provavelmente partilham uma dependência, como uma fonte de conhecimento, uma secção de pedido ou uma configuração de ferramenta.
  2. Corrija a dependência partilhada: Não corrija cada sinal individualmente.
  3. Execute novamente ambos os conjuntos de avaliação: Após a correção, confirme que ambos apresentam melhorias.
  4. Se apenas um melhorar, os sinais não partilham realmente uma causa raiz. Faça a triagem das falhas restantes de forma independente.

Análise de tendências ao longo das iterações

Monitorize como as classificações mudam ao longo dos seus ciclos de iteração para compreender se a sua estratégia de remediação está a funcionar.

Tendência Interpretação Ação
As pontuações melhoram ao longo das iterações A remediação está a funcionar Continuar até que os limiares sejam atingidos.
Classificações inalteradas, apesar das mudanças A remediação não está a abordar a verdadeira causa raiz Re-triagem; a classificação da causa raiz pode estar errada.
Pontuações degradam-se após uma alteração Regressão: a mudança quebrou algo Reverter a alteração. Investigar o que regrediu e porquê.
Um conjunto de avaliação a melhorar, outro a degradar-se Compensação — ao corrigir uma dimensão prejudica outra Investigue o acoplamento, frequentemente causado por conflito de instruções (consulte Percurso 3).
Pontuações que oscilam entre execuções (mais de +/-10% variância) Instabilidade do avaliador ou não-determinismo do agente Valide primeiro a fiabilidade do avaliador (consulte Validação do avaliador). Execute pelo menos três vezes por iteração.

Criar uma visão de tendências

Após cada iteração, registe:

  • Data
  • Alteração efetuada
  • Conjunto de avaliação
  • Pontuação antes
  • Pontuação depois
  • Delta

Estas informações ajudam-no a:

  • Confirme que está a convergir para os limiares
  • Identificar regressões rapidamente
  • Detetar plateaus precocemente (Percurso 2)

Documentar falhas

Registos estruturados de falhas criam conhecimento institucional ao longo dos ciclos de iteração. Sem documentação, as equipas repetem frequentemente o mesmo trabalho de investigação.

Porquê documentar falhas

  • Acelerar a triagem futura: Reconhece imediatamente padrões de falhas conhecidos.
  • Criar evidência de escalamento: Acumule registos de limitações da plataforma para fundamentar melhor os argumentos junto da equipa da plataforma.
  • Ativar a aprendizagem da equipa: O registo ajuda a evitar investigações duplicadas quando várias pessoas trabalham no mesmo agente.
  • Monitorize lacunas conhecidas: Não se esqueça de monitorizar falhas classificadas como "não serão corrigidas" ou "limitação conhecida".

Utilizar o modelo do registo de falhas

Use o modelo do registo de falhas para capturar falhas num formato leve ou detalhado, dependendo do tamanho da equipa e da maturidade do processo.

O que registar

No mínimo, capture a seguinte informação para cada falha triada:

  1. Que caso de teste falhou.
  2. Em que tipo de causa raiz é que o classificou.
  3. O que correu mal especificamente.
  4. O que alterou para corrigir.
  5. Se a correção resultou.

Para falhas não resolvidas, registe também:

  • O que já foi tentado até agora.
  • Porque continua por resolver.
  • Quando reavaliar (por exemplo, "após a atualização da plataforma X").

Fluxo de trabalho de melhoria contínua

Utilize esta lista de verificação após cada ciclo de triagem e remediação para confirmar que capturou os resultados e os próximos passos.

Lista de verificação pós-iteração

Concluída? Tarefa
✓ Registe todas as falhas triadas no registo de falhas.
✓ Identifique e registe as concentrações de causas raiz.
✓ Verifique os padrões de sinais cruzados.
✓ Registe as classificações para monitorizar tendências.
✓ Documente limitações conhecidas com soluções.
✓ Identifique as prioridades da próxima iteração com base nas falhas restantes.
✓ Defina o calendário de repetições de execuções (que conjuntos de avaliação e quando).

Quando parar de iterar

Parar de iterar quando:

  • Todos os conjuntos de avaliação estão acima dos limiares.
  • Documentou lacunas conhecidas.
  • As classificações são consistentes (< 5% de variância).
  • Não existem problemas de configuração de agentes em aberto que bloqueiem sinais.

Não pare de iterar quando:

  • Não investigou falhas persistentes.
  • Removeu casos de teste difíceis para alcançar os limiares.
  • Não documentou as limitações da plataforma.

Saiba mais em Determinar quando a iteração estiver concluída.

Passos seguintes

  • Last updated on