Detecção De Erros Em IA

A pergunta prática para levar desta seção é: qual erro específico uma métrica atual consegue detectar, e qual erro ela esconde?

O Modelo do Primeiro Sinal

O Modelo do Primeiro Sinal começa com uma regra operacional: não escreva uma métrica antes de observar exemplos reais. Leia rastreamentos, respostas e entradas que representam o uso do produto. Um rastreamento é o registro completo de uma interação, incluindo a solicitação, o contexto enviado ao modelo, a resposta e, quando disponível, o resultado da ação executada.

Considere um assistente que responde perguntas sobre políticas internas. A equipe poderia começar medindo “qualidade da resposta”. Essa expressão não define nada. Em vez disso, a leitura dos dados pode revelar quatro sinais diferentes: a resposta cita uma política inexistente, usa uma política antiga, responde parcialmente à pergunta ou apresenta uma conclusão correta sem indicar a fonte. Cada sinal exige um critério próprio, porque a correção de um problema não garante a correção dos demais.

Use o modelo na seguinte ordem:

1. Reúna rastreamentos reais. Separe exemplos de diferentes tipos de usuário, intenção, idioma, tamanho de entrada e nível de risco. O objetivo é evitar que a métrica represente apenas o caminho mais comum. 2. Marque o primeiro sinal de falha. Registre o comportamento observável que indica o problema. Escreva “a resposta afirma uma regra que não aparece nos documentos” em vez de “a resposta é ruim”. 3. Agrupe sinais semelhantes. Junte falhas que exigem a mesma correção. Alucinação factual, documento desatualizado e resposta incompleta podem parecer próximos, mas não devem formar um único grupo se pedirem ações diferentes. 4. Defina o critério de aceitação. Descreva o que uma resposta precisa fazer para passar. Para uma pergunta sobre política, por exemplo: “a resposta deve usar apenas informações presentes nos documentos válidos e indicar a fonte correspondente”. 5. Escolha a métrica depois. Só agora decida se a equipe precisa de uma verificação de presença, uma avaliação por julgamento, uma comparação com referência ou revisão humana. A métrica deve refletir o critério, não substituí-lo. 6. Congele exemplos de referência. Guarde casos aprovados, casos reprovados e casos limítrofes. Eles reduzem a deriva de critérios, porque permitem comparar decisões novas com decisões anteriores.

A deriva de critérios acontece quando a definição de “bom” muda sem registro. Para reduzi-la, mantenha uma versão do critério, a data da alteração, o motivo da mudança e exemplos afetados. Se a equipe decidir aceitar respostas sem citação para perguntas de baixo risco, registre essa exceção explicitamente. Não altere a regra apenas porque uma rodada de avaliação apresentou resultado inconveniente.

Pergunte à equipe: duas pessoas treinadas aplicariam o mesmo critério aos mesmos três exemplos? Se a resposta for não, ainda falta definir o erro antes de calcular uma taxa.

Aplicação prática: do rastreamento à avaliação estável

Considere um sistema que responde a dúvidas de suporte técnico usando uma base de documentos. A equipe recebe 240 rastreamentos de uma semana e quer evitar uma métrica genérica de “resposta útil”.

1. Separe os rastreamentos por risco. Classifique 120 perguntas simples, 80 perguntas que exigem consulta a documentos e 40 perguntas sobre configurações que podem causar perda de dados. O resultado esperado é uma amostra que não misture erros de gravidade muito diferente. 2. Leia 30 rastreamentos de cada grupo. Registre o primeiro sinal observável em uma tabela com as colunas “entrada”, “resposta”, “documento usado”, “falha”, “gravidade” e “decisão”. A equipe deve terminar essa leitura com uma lista de falhas baseada em evidência, não em impressão geral. 3. Crie grupos de erro. Suponha que a leitura encontre 18 respostas com documento errado, 11 com instrução incompleta, 7 com informação inventada e 5 com resposta correta, mas sem fonte. O total pode ultrapassar 30 se um rastreamento contiver mais de uma falha, mas a equipe deve marcar qual falha veio primeiro e qual causou o risco principal. 4. Escreva critérios independentes. Para “informação inventada”, use: “a resposta não pode afirmar fatos ausentes dos documentos recuperados”. Para “instrução incompleta”, use: “a resposta deve incluir todas as etapas necessárias para concluir a tarefa descrita”. A separação permite saber qual mudança produziu efeito. 5. Monte um conjunto de referência com 40 casos. Inclua 20 casos aprovados, 15 casos reprovados e 5 casos limítrofes. Cada caso precisa conter a decisão e uma justificativa curta. O conjunto servirá para testar alterações no prompt, no recuperador e no avaliador. 6. Escolha verificações proporcionais ao erro. Use uma verificação de correspondência entre afirmações e documentos para detectar conteúdo sem suporte; use uma avaliação estruturada para completude; encaminhe casos limítrofes para revisão humana. O resultado esperado não é uma nota única, mas uma visão separada por modo de falha. 7. Compare versões com o mesmo conjunto. Rode a versão atual e a nova versão sobre os 40 casos. Uma melhora válida ocorre quando a nova versão reduz uma falha sem criar outra. Se a taxa de informação inventada cair, mas as respostas incompletas aumentarem, a equipe precisa tratar o trade-off antes de declarar sucesso. 8. Revise os critérios em uma reunião curta. Use apenas os casos em que houve discordância. Altere a regra somente quando a equipe identificar uma ambiguidade real. Registre a nova versão e não reescreva decisões antigas sem preservar o histórico.

O conjunto de referência deve permanecer pequeno o bastante para receber manutenção e amplo o bastante para representar os erros importantes. Quando o produto mudar de domínio, adicionar uma fonte ou alterar o formato de resposta, acrescente casos que cubram o novo comportamento. Não substitua silenciosamente os casos antigos: eles mostram se o sistema preservou a qualidade já conquistada.

Lista de verificação rápida

• [ ] Separei rastreamentos reais por tipo de tarefa e risco. - [ ] Descrevi falhas como comportamentos observáveis. - [ ] Identifiquei o primeiro sinal de cada falha. - [ ] Separei erros que exigem correções diferentes. - [ ] Escrevi critérios de aprovação antes de escolher métricas. - [ ] Mantive exemplos aprovados, reprovados e limítrofes. - [ ] Registrei versões e motivos para mudanças nos critérios. - [ ] Comparei versões usando o mesmo conjunto de referência. - [ ] Verifiquei se uma melhoria criou outro modo de falha.

Se a lista parar no item “qualidade geral”, volte aos rastreamentos. O produto ainda não tem uma avaliação específica o bastante para orientar a próxima decisão.

Onde as equipes perdem o controle

Confundir média alta com ausência de falhas

Uma avaliação agregada pode esconder um erro raro e grave. Um assistente pode responder bem a perguntas comuns e ainda fornecer instruções perigosas em uma configuração específica.

Faça isto: calcule resultados por modo de falha e por nível de risco. Defina quais erros bloqueiam uma versão, mesmo quando o resultado geral parece bom.

Não faça isto: use uma média única como autorização automática para publicar.

Escrever o critério depois de ver o resultado

Quando a equipe cria a regra depois de observar a pontuação, ela pode ajustar a definição para justificar o resultado. Isso produz critérios instáveis e dificulta a comparação entre versões.

Faça isto: escreva o comportamento esperado, os casos de reprovação e as exceções antes da rodada de avaliação. Registre a versão do critério.

Não faça isto: mudar “resposta correta” para “resposta aceitável” apenas porque muitos casos falharam.

Automatizar uma distinção que os revisores ainda não conseguem fazer

Um avaliador automático não corrige uma definição ambígua. Se duas pessoas discordam sobre o que significa “completo”, o sistema automatizado apenas repetirá essa inconsistência em maior escala.

Faça isto: use revisão humana para resolver casos limítrofes, registre exemplos e teste o avaliador contra decisões já confirmadas. Automatize quando o critério estiver claro e os erros importantes tiverem exemplos representativos.

Não faça isto: transformar toda avaliação em uma nota gerada automaticamente sem verificar se ela detecta as falhas prioritárias.

A detecção de erros vem antes porque cada métrica carrega uma definição de qualidade. Quando a equipe identifica o primeiro sinal, documenta o critério e preserva exemplos de referência, ela reduz a deriva e cria uma base confiável para as avaliações seguintes. O próximo passo não é adicionar mais números: é transformar os sinais observados em verificações que a equipe consegue repetir, comparar e melhorar.

End of chapter one. 7 more chapters in the full book.