Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Depois de fazer a triagem de falhas individuais dos casos de teste, você pode aplicar correções e ainda assim ver pouca ou nenhuma melhora no desempenho geral do agente. Esse resultado geralmente indica um problema sistêmico, não um conjunto de falhas não relacionadas.
A análise de padrões permite identificar sinais recorrentes e causas raiz comuns em múltiplos casos de teste com falha. Use a análise de padrões para priorizar alterações que abordem grupos de falhas de uma só vez, em vez de corrigir cada falha isoladamente.
Importante
Siga estas orientações após concluir triagem de falhas e aplicar alterações de correção. A análise de padrão é mais útil depois que você faz a triagem de pelo menos cinco falhas.
Quando usar a análise de padrões
A análise de padrões é mais útil quando você observa uma ou mais das seguintes condições:
- Muitas falhas no mesmo conjunto de avaliação.
- Falhas recorrentes com sintomas semelhantes.
- Melhorias em casos de teste individuais que não alteram as pontuações gerais.
- Melhorias em uma área que causam regressões em outra.
Corrigir falhas uma a uma é ineficiente nessas situações. A análise de padrões permite identificar o que as falhas têm em comum, possibilitando resolver a causa raiz.
Análise de concentração
Depois de classificar falhas individuais, procure padrões em todo o conjunto.
| Padrão | O que isso indica | Ação recomendada |
|---|---|---|
| Falhas de 80% ou mais são problemas de configuração de avaliação | O conjunto de avaliação precisa de calibração, não de alterações no agente | Pausar a iteração do agente. Audite e ajuste a qualidade da avaliação primeiro, depois execute novamente para garantir um sinal limpo. |
| 80% ou mais das falhas são problemas de configuração do agente em uma área (por exemplo, relacionados ao conhecimento) | Lacuna sistêmica na configuração do agente | Concentre-se na correção dessa área. Esse problema geralmente é uma questão arquitetônica (por exemplo, estrutura da fonte de conhecimento), não correções individuais de casos de teste. |
| 80% ou mais das falhas se devem a limitações da plataforma | O agente alcança os limites da plataforma | Reavalie o escopo do agente. Encaminhe para a equipe de plataforma. Ajuste os limites ou trate os itens impactados como limitações conhecidas, quando apropriado. |
| As falhas estão igualmente distribuídas entre os tipos de causa raiz | Nenhum problema sistêmico isolado | Continue a correção caso a caso usando mapeamento de correção. |
Como fazer análise de concentração
Contabilize suas falhas classificadas por tipo de causa raiz:
- Problemas de configuração de avaliação
- Problemas de configuração de agentes
- Limitações da plataforma
- Não classificado
Calcule a porcentagem para cada tipo.
Se algum tipo atingir 80% ou mais, indicando um problema sistêmico, corrija a categoria, não os casos individuais.
Se os problemas de configuração do agente se concentrarem em um único sinal de qualidade (por exemplo, cinco de seis são fundamentação de conhecimento), esse padrão aponta para uma causa raiz arquitetônica.
Padrões de sinal cruzado
Quando falhas abrangem múltiplos conjuntos de avaliação, elas frequentemente apontam para uma causa raiz compartilhada. Procure os seguintes padrões:
| Padrão | O que isso provavelmente indica | O que investigar |
|---|---|---|
| Falha simultânea em precisão factual e fundamentação do conhecimento | Problema com a fonte do conhecimento (errado, ausente, inacessível ou ultrapassado) | Configuração do conhecimento, status de indexação e atualização do conteúdo |
| Invocação de ferramenta e roteamento de gatilho apresentando falhas | Configuração de orquestração, tópicos e ferramentas não estão devidamente conectados | Revise como os tópicos são direcionados para as ferramentas. Verifique fluxos desconectados ou configurados incorretamente. |
| Tom reprovado, mas precisão aprovada | O agente recebe a resposta certa, mas a entrega de forma inadequada | Concentre-se nas instruções de estilo de prompt; a infraestrutura de precisão é sólida. |
| Segurança aprovada, mas precisão reprovada | O agente pode estar excessivamente limitado, cauteloso demais, se recusa a responder quando deveria | Revise as instruções de segurança para restrições excessivamente amplas que bloqueiam respostas legítimas. |
| Tudo está sendo aprovado, exceto casos extremos | O comportamento principal é consistente | Concentre-se em expandir a robustez nos pontos extremos; este padrão é um bom sinal. |
| A precisão está melhorando, mas o tom está se deteriorando | Conflito de instruções, novas instruções de precisão podem estar substituindo a orientação de tom | Examine as alterações de prompt recentes e tenha em mente o "orçamento de instrução". |
| Vários conjuntos de avaliação estão se degradando simultaneamente | Provavelmente uma causa raiz única com amplo impacto | Verifique mudanças recentes em prompt do sistema, atualizações das fontes de conhecimento ou atualizações no modelo da plataforma. |
O que fazer com padrões de sinal cruzado
- Identifique a causa raiz comum: se dois sinais falharem juntos, provavelmente compartilham uma dependência, como uma fonte de conhecimento, seção do prompt ou configuração de ferramenta.
- Corrija a dependência compartilhada: não corrija cada sinal individualmente.
- Reexecute ambos os conjuntos de avaliação: após a correção, confirme se ambos apresentam melhoria.
- Se apenas um melhorar, os sinais não compartilham uma causa raiz. Faça a triagem das falhas restantes de forma independente.
Análise de tendências ao longo das iterações
Acompanhe como as pontuações mudam ao longo dos seus ciclos de iteração para entender se sua estratégia de correção está funcionando.
| Tendência | Interpretação | Para |
|---|---|---|
| As pontuações melhoram ao longo das iterações | A correção está funcionando | Continue até que os limites sejam atingidos. |
| As pontuações permanecem inalteradas apesar das alterações | A correção não está abordando a causa raiz | Refaça a triagem; a classificação da causa raiz pode estar errada. |
| Pontuações degradando após uma alteração | Regressão – a alteração causou uma falha | Reverter a alteração. Investigue o que regrediu e o motivo. |
| Um conjunto de avaliação melhorando, outro piorando | Compensação – corrigir uma dimensão prejudica a outra | Investigue o acoplamento, geralmente causado por conflito de instrução (consulte a Jornada 3). |
| Variações nas pontuações entre execuções (mais de +/-10% de variação) | Instabilidade de avaliador ou não determinismo de agente | Primeiro, valide a confiabilidade do classificador (consulte a seção Validação do classificador). Execute pelo menos três vezes em cada iteração. |
Criando uma exibição de tendência
Após cada iteração, registre:
- Data
- Alteração realizada
- Conjunto de avaliação
- Pontuação antes
- Pontuação após
- Delta
Essa informação ajudará você a:
- Confirme se você está convergindo para os limites
- Identificar regressões rapidamente
- Detectar platôs precocemente (Jornada 2)
Documentar falhas
Registros estruturados de falhas criam conhecimento institucional ao longo dos ciclos de iteração. Sem documentação, as equipes frequentemente repetem o mesmo trabalho de investigação.
Por que documentar falhas
- Acelere a triagem futura: você reconhece imediatamente padrões de falha conhecidos.
- Forneça evidências para escalonamento: acumule registros de limitações da plataforma para apresentar justificativas mais robustas à equipe da plataforma.
- Facilite o aprendizado da equipe: o registro ajuda a evitar investigações duplicadas quando várias pessoas trabalham no mesmo agente.
- Acompanhe lacunas conhecidas: não se esqueça de registrar falhas classificadas como "não será corrigido" ou "limitação conhecida".
Use o modelo do log de falhas
Use o modelo de log de falhas para registrar falhas em um formato simplificado ou detalhado, dependendo do tamanho da equipe e da maturidade do processo.
O que registrar
No mínimo, registre as seguintes informações para cada falha de triagem:
- Que caso de teste falhou.
- Qual tipo de causa raiz você classificou.
- O que deu errado especificamente.
- O que você mudou para corrigir.
- Se a solução funcionou.
Para falhas não resolvidas, também registre:
- O que você tentou até agora.
- Por que isso permanece sem solução.
- Quando reavaliar (por exemplo, "após a atualização da plataforma X").
Fluxo de trabalho de melhoria contínua
Use esta lista de verificação após cada ciclo de triagem e correção para confirmar que você registrou os resultados e as próximas etapas.
Lista de verificação pós-Iteração
| Pronto? | Tarefa |
|---|---|
| ✓ | Registre todas as falhas de triagem no log de falhas. |
| ✓ | Identificar e anotar concentrações de causa raiz. |
| ✓ | Verifique padrões de sinais cruzados. |
| ✓ | Registrar as pontuações para acompanhamento de tendências. |
| ✓ | Documentar limitações conhecidas com soluções de contorno. |
| ✓ | Identificar as prioridades da próxima iteração com base nas falhas restantes. |
| ✓ | Defina o agendamento de repetição (quais conjuntos de avaliação, quando). |
Quando parar de iterar
Parar a iteração quando:
- Todos os conjuntos de avaliação estão acima dos limites.
- Você documentou lacunas conhecidas.
- As pontuações são consistentes (< com até 5% de variação).
- Não há problemas de configuração de agente pendentes relacionados a sinais de bloqueio.
Não parar de iterar quando:
- Você não investigou falhas persistentes.
- Você removeu casos de teste difíceis para alcançar limites.
- Você não documentou as limitações da plataforma.
Saiba mais em Determinar quando a iteração está concluída.
Próximas etapas
- Reveja exemplos práticos que demonstram como as camadas do framework trabalham juntas em cenários do mundo real.
- Use o modelo de registro de falhas para registrar suas descobertas.