Camada 2: Triagem de falhas de agentes

Depois de interpretar as pontuações da avaliação e identificar as áreas prioritárias, determine por que motivo cada caso de teste falhou e quem deve intervir.

Este artigo fornece orientações estruturadas para diagnosticar falhas ao nível de casos de teste. Ajuda a classificar a causa raiz, a distinguir entre problemas de agentes, de avaliação e de infraestrutura, e a escolher a ação adequada seguinte.

Antes de começar

Antes de começar a triagem de falhas:

1. Conclua a avaliação de interpretação da pontuação e prontidão e identifique os conjuntos de avaliação que requerem atenção.
2. Concentre-se nas falhas de maior prioridade, com base na preparação e no risco.

Verificação pré-triagem: Verificar o estado de funcionamento da infraestrutura

Antes de diagnosticar falhas individuais, confirme que as dependências estavam em bom estado de funcionamento durante a execução da avaliação. Os problemas de infraestrutura podem produzir falhas que parecem problemas relacionados com os agentes ou com a avaliação, mas que não estão relacionados com nenhum deles.

Verificar as seguintes condições:

• As fontes de conhecimento estão acessíveis e totalmente indexadas.
• Os back-ends ou conectores de API não devolvem erros, tempos limite ou respostas com limite de taxa.
• Os tokens de autenticação são válidos durante toda a execução.
• O ambiente de avaliação corresponde à configuração pretendida do agente.

Se uma dependência estiver em mau estado de funcionamento, corrija o problema e volte a executar a avaliação antes de continuar. A triagem de resultados de uma execução em mau estado de funcionamento pode levar a conclusões erradas.

Passo 0: Priorizar as falhas

Antes de efetuar a triagem de casos de teste individuais, decida onde deve concentrar-se primeiro.

Priorize as falhas por esta ordem:

Se tiver muitas falhas (por exemplo, mais de 15), não faça a triagem de cada falha individualmente. Comece pelo conjunto de avaliação com a pontuação mais baixa e reveja manualmente algumas falhas. Se partilharem uma causa raiz, corrigi-la pode resolver várias falhas de uma só vez.

Identificar o sinal de qualidade de um caso de teste com falhas

Se um resultado de avaliação mostrar um caso de teste com falhas mas não identificar claramente o sinal de qualidade, utilize o conjunto de avaliação e o método de classificação para inferir o sinal.

Por exemplo:

• O conjunto de avaliação indica a área de capacidade, como segurança, fundamentação ou utilização de ferramentas.
• O método de classificação, como a correspondência de palavras-chave ou a pontuação com base num guia de avaliação, fornece contexto adicional.

Identificar o sinal de qualidade pretendido ajuda a escolher as perguntas de diagnóstico mais relevantes.

Passo 1: Verificar a configuração da avaliação

Para cada falha, reveja manualmente a resposta real do agente juntamente com o valor esperado e o método de classificação.

Trabalhe as seguintes perguntas por ordem. Pare quando chegar a um resultado.

1. A resposta do agente é aceitável? Um utilizador real ficaria satisfeito com esta resposta, mesmo que tenha sido reprovada na avaliação?

   • Se Sim, a configuração da avaliação tem um problema: o avaliador ou o valor esperado está errado.
   • Se Não, avance para a próxima pergunta.

2. A resposta esperada está atualizada e correta em relação à fonte?

   • Se Sim, avance para a próxima pergunta.
   • Se Não, há um problema na configuração da avaliação: a resposta esperada está desatualizada ou incorreta.

3. O caso de teste reflete uma entrada de utilizador realista?

   • Se Sim, avance para a próxima pergunta.
   • Se não, a configuração da avaliação tem um problema: o caso de teste é irrealista.

4. Poderia uma resposta alternativa razoável também estar correta, mas o avaliador não a permitir?

   • Se Sim, a configuração da avaliação tem um problema: o avaliador é demasiado rígido e não tem em conta variações válidas.
   • Se Não, avance para a próxima pergunta.

5. O método de avaliação é adequado para o que está a testar?

   • Se Sim, a avaliação é válida. Prossiga para o Passo 2: Diagnosticar o agente.
   • Se Não, a configuração da avaliação tem um problema: o método de avaliação não é adequado para este sinal de qualidade.

Determinar a aceitabilidade da resposta

Use os seguintes sinais para ajudar a determinar se a resposta do agente é aceitável:

• Os mesmos factos essenciais, redação diferente → Geralmente é aceitável (o avaliador pode ser demasiado rígido).
• Informações críticas em falta presentes na fonte → Geralmente não é aceitável.
• Limiar ambíguo para "suficientemente bom" → Os critérios de aceitação podem não ser claros (sinalizar para o passo 4).

Se não tiver a certeza, compare o conteúdo com a fonte original, e não apenas com a resposta esperada.

Estes sinais informam o seu juízo, mas não o substituem.

Tipos comuns de falhas de configuração de avaliação

Validação do avaliador

A fiabilidade do avaliador é um pré-requisito para uma triagem fidedigna. Se o próprio avaliador não for fiável, irá diagnosticar incorretamente todas as falhas que encontrar.

Para validar a fiabilidade do avaliador:

1. Selecione 5-10 casos de teste onde sabe o resultado correto de aprovação/reprovação através da revisão manual.
2. Execute a avaliação e compare o resultado do avaliador com o veredicto manual.
3. Se o avaliador discordar em mais de 20% dos casos, recalibre o avaliador antes de depurar o agente.

Sinais de que um avaliador precisa de atenção:

• O mesmo caso de teste produz diferentes veredictos entre execuções.
• As falhas concentram‑se em conjuntos de avaliação que utilizam classificação baseada em modelos, enquanto os métodos deterministas são aprovados.
• O avaliador assinala problemas que não consegue reproduzir ao rever a resposta do agente.

Opções de recalibração do avaliador:

• Utilize métodos deterministas sempre que possível.
• Adicione exemplos explícitos de respostas "aceitáveis" e "não aceitáveis" ao guia de avaliação.
• Alargue os conjuntos de palavras-chave para incluir sinónimos e reformulações válidas.
• Utilize Comparar significado em vez de Correspondência de palavras-chave (Tudo) para verificações de equivalência semântica.

Passo 2: Diagnosticar o agente

Neste ponto, a avaliação é válida e o agente produziu uma resposta incorreta. Diagnostique o que correu mal na configuração do agente.

Verificar falhas de precisão factual e de fundamentação do conhecimento

Verificar se existem falhas na invocação de ferramentas

Verificar falhas no encaminhamento de acionadores

Verificar falhas de tom e qualidade de resposta

Verificar a segurança e falhas nos limites

Verificar se há escalamento e falha gradual

Após o diagnóstico, mapeie os padrões de falha para estratégias de remediação de acordo com a causa raiz.

Passo 3: Identificar limitações da plataforma

Se a avaliação estiver correta e alterações razoáveis na configuração não melhorarem os resultados, o problema pode ser uma limitação da plataforma.

Indicadores de limitação da plataforma

Caminho de ação para limitações de plataforma

1. Documentar claramente a limitação (o que falha, o que foi tentado e as provas de que não está relacionada com a configuração).
2. Aplicar uma solução alternativa sempre que possível (por exemplo, reestruturar o documento de origem para melhorar a obtenção).
3. Marcar o caso de teste como uma limitação conhecida ou ajustar os limiares para que não bloqueiem o progresso não relacionado.
4. Escale com provas para a equipa da plataforma.
5. Monitorizar o item no registo de falhas para reavaliação quando as capacidades da plataforma forem atualizadas.

Após a classificação, reveja as orientações alternativas e de escalamento para responder às limitações da plataforma.

Quando uma falha não se enquadra na estrutura

Algumas falhas não são facilmente mapeadas para um único tipo de causa raiz. Exemplos comuns incluem:

• Problemas de qualidade dos dados de back-end: O conteúdo da fonte de conhecimento é tecnicamente correto, mas está escrito de forma ambígua, pelo que nem o agente nem a avaliação estão errados.
• Problemas intermitentes de infraestrutura: Tempos limite de rede, limitação de taxa de API e problemas de conectores que não se reproduzem de forma consistente.
• Alterações na versão do modelo: O comportamento do agente mudou após uma atualização do modelo da plataforma que não foi iniciada por si.
• Casos de teste ambíguos: O cenário é ambíguo, e pessoas razoáveis discordam quanto à resposta correta.

Abordagem sugerida: Documente o que observou (a falha, a resposta do agente, o que verificou). Registe o item como "não classificado" no registo de falhas. Se a falha se repetir, torna-se frequentemente classificável com base em provas adicionais.

Processamento de causas compostas

Uma única falha pode ter várias causas raiz associadas. Por exemplo:

• Uma falha de precisão factual em que a resposta esperada está ligeiramente desatualizada (configuração de avaliação) e a fonte de conhecimento também está incompleta (configuração do agente).
• Uma falha de invocação de ferramenta em que a descrição da ferramenta é ambígua (configuração do agente) e a orquestração não suporta chamadas condicionais de ferramenta (limitação de plataforma).

Abordagem sugerida: Conclua a triagem completa para cada falha. Se se aplicarem vários tipos de causas raiz, aborde-os por ordem de prioridade:

1. Corrija primeiro a avaliação para obter um sinal claro sobre se a mudança de agente realmente ajuda.
2. Corrija a configuração do agente para determinar se a falha restante é realmente um problema da plataforma.
3. Documente a limitação da plataforma apenas depois de terem sido abordados os pontos 1 e 2.

Volte a executar os casos de teste afetados após cada alteração antes de avançar.

Tratamento de falhas em conversações multiturno

Em cenários com vários turnos, as falhas só surgem ao longo dos turnos.

Quando suspeitar de um problema multiturno

• O agente responde corretamente nos primeiros turnos, mas contradiz-se mais tarde.
• O agente perde o contexto de uma chamada de ferramenta anterior ou de uma obtenção de conhecimento num turno posterior.
• O tempo do escalamento só faz sentido tendo em conta o histórico completo das conversações.
• O tom do agente degrada-se progressivamente à medida que a conversação se prolonga.
• O agente pede informações que o utilizador já forneceu.

Perguntas de diagnóstico adicionais

Orientação de remediação para problemas multiturno

• Perda de contexto: Verifique a configuração do estado da conversação. Certifique-se de que os resultados das ferramentas e os factos principais persistem entre turnos.
• Contradições: Adicione uma instrução de consistência, como: "Mantém a consistência com as tuas respostas anteriores nesta conversação."
• Repetição de perguntas: verifique a configuração da memória de conversação da plataforma.
• Degradação de conversações longas: Considere estratégias de resumo de conversas ou de eliminação de contexto.

Validação de casos de teste com aprovações (verificação de falsos positivos)

Esta estrutura concentra-se em casos de teste falhados. No entanto, um caso de teste aprovado incorretamente pode criar lacunas de qualidade ocultas.

Prática recomendada: Reveja manualmente 5-10% dos casos de teste aprovados por execução de avaliação, especialmente para:

• Classificação baseada em modelos (maior risco de falsos positivos)
• Sinais subjetivos (tom, utilidade)
• Testes que anteriormente eram reprovados e que agora são aprovados após uma alteração

Se encontrar falsos positivos, recalibre o avaliador.

Passos seguintes

Após concluir a triagem de falhas:

• Use a Camada 3: mapeie padrões de falhas para estratégias de remediação.
• Utilize Camada 4: Analise padrões para identificar problemas sistémicos.
• Reveja exemplos práticos que demonstrem como as camadas da estrutura funcionam em conjunto em cenários reais.