AWS mostra como 100% de precisão na busca escondem a falha de um agente de IA

Seu agente responde com confiança às perguntas dos funcionários, anexa links e passa na verificação de busca. Dá para lançar? No exemplo da AWS, os trechos encontrados obtiveram 100% de precisão em uma das métricas, mas, para a pergunta sobre licença médica, nenhum deles continha a informação necessária. Depois de um ajuste no prompt, a resposta ficou ainda pior. A lição prática: antes da próxima mudança na instrução, vale verificar se a resposta existe nos documentos.

A AWS descreveu esse caso em um material sobre o Agent Development Lifecycle, ou Agent DLC. Trata-se de uma abordagem de desenvolvimento de agentes em que a equipe define antecipadamente as condições de aceitação, verifica cada mudança e devolve ao conjunto de verificações os problemas descobertos em produção. Para o desenvolvedor, o valor está em ter um método concreto para identificar qual componente precisa de correção.

Por que 100% no relatório não foram suficientes

Os autores montaram um agente de RH de consulta e o testaram com três perguntas. Entre as medições estavam o suporte das afirmações pelas fontes, a utilidade dos trechos encontrados e a existência de resposta para cada subpergunta do usuário.

Imagine um funcionário que pergunta quando é preciso entregar o atestado médico. A busca traz um documento geral sobre férias, em que as licenças médicas são mencionadas de passagem. O trecho é pertinente ao tema e recebe avaliação positiva. Mas o prazo de entrega do atestado não está nele. Era exatamente essa diferença que a métrica de precisão no nível de trechos inteiros escondia.

Para a pergunta problemática, essa precisão foi de 100%, a proporção de fatos úteis dentro do material encontrado foi de 9% e a cobertura das subperguntas, de 0%. Depois, os autores verificaram os documentos de origem: de fato, não havia no corpus uma política específica sobre licença médica.

A equipe alterou apenas o prompt do sistema: exigiu que o agente se baseasse estritamente nas fontes, ignorasse o supérfluo e respondesse de forma objetiva. Na pergunta sobre avaliação de funcionários, a proporção de afirmações comprovadas subiu de 83% para 87%. Na pergunta sobre licença médica, caiu de 39% para 31%. A instrução não tinha como acrescentar informações ausentes. O passo seguinte deveria ter sido ampliar a base e verificar a busca.

O que verificar antes do lançamento

No Agent DLC, o ponto de partida é um conjunto acordado de critérios, limites e exemplos de verificação. Por exemplo, para um agente de suporte, é preciso definir quais afirmações exigem link, quando se deve admitir a falta de dados e quais informações sobre o cliente podem ser usadas.

Em seguida, a equipe avalia a versão, analisa o caminho até o erro, muda um único componente e repete a verificação pelas mesmas regras. Essa ordem ajuda a relacionar o resultado a uma mudança específica. Se o prompt for reescrito, a base atualizada e os critérios alterados ao mesmo tempo, explicar a variação da nota será muito mais difícil.

Recomenda-se executar cada exemplo várias vezes: a mesma solicitação pode levar o agente a respostas e chamadas de ferramentas diferentes. Os próprios avaliadores também precisam ser verificados. Se as respostas são julgadas por outro modelo, suas notas devem ser comparadas com exemplos revisados por humanos, e sua dispersão deve ser medida.

Os critérios têm pesos diferentes. A violação da proibição de revelar dados de terceiros bloqueia o lançamento. Para a qualidade da resposta, é possível definir um limite de execuções bem-sucedidas. Alguns indicadores, no início, basta apenas observar, até que a equipe tenha certeza de que sabe medi-los de forma confiável.

Onde terminam as conclusões do experimento

Uma nota alta de suporte pelas fontes também não garante uma resposta aceitável. Em um dos casos, o agente afirmou saber a forma de contato preferida do usuário. Ele não tinha o perfil do usuário: o modelo combinou informações de documentos diferentes e as apresentou como um fato pessoal. A resposta recebeu 90% em suporte pelas fontes, portanto invenções desse tipo exigem verificação à parte.

O estudo tem escala modesta: três perguntas em uma implementação de demonstração. Não é um resultado de cliente nem prova de que a abordagem esteja pronta para qualquer implantação industrial. Os autores também alertam que as avaliações variam entre as execuções.

O passo prático para a equipe é pegar falhas reais do seu agente e adicioná-las ao conjunto de verificação. Para cada caso, descobrir se as fontes eram suficientes, se as ferramentas foram usadas corretamente e se surgiram informações inventadas. Depois, corrigir a causa identificada e repetir as execuções. As verificações também devem rodar de forma agendada: um modelo externo, uma API ou uma base de conhecimento podem mudar sem um único commit no seu repositório.