Avaliação de assistente de IA interno: o framework de cinco camadas para saber se ele está respondendo certo

A pergunta que trava a maioria dos projetos de assistente interno não é qual modelo usar. É esta: qual número prova que ele está funcionando? Quando a resposta vem como “a equipe gostou” ou “parece que acerta uns 90%”, não existe avaliação — existe impressão. E impressão não sobrevive à primeira reunião em que alguém pergunta por que o assistente inventou um prazo de garantia que não existe em lugar nenhum da base.

Avaliar um assistente que responde sobre documentos internos é diferente de avaliar um classificador. Não há rótulo único e objetivo para “resposta certa”. Mas isso não significa que não dê para medir. Significa que a medição precisa ser decomposta em camadas, porque cada camada falha por um motivo distinto e exige uma correção distinta. Um framework de cinco camadas resolve o problema sem exigir time de machine learning dedicado.

Antes das camadas, um aviso sobre o número que costuma ser reportado: taxa de acerto agregada é um número inútil isolado. Suponha um assistente que responde dúvidas sobre política interna de RH e acerta 8 de cada 10 perguntas de teste. O número parece bom. Só que ele não diz nada sobre o que fazer a seguir, porque as duas falhas podem ter origens completamente diferentes.

Se o assistente errou porque o trecho correto do documento nunca chegou até o modelo, o problema é de recuperação — e trocar de modelo de linguagem não resolve nada. Se o trecho chegou e o modelo o contradisse, o problema é de geração. Se o trecho chegou, o modelo o reproduziu corretamente, mas a resposta não serve para a pessoa decidir nada, o problema é de utilidade. São três diagnósticos e três correções sem nenhuma sobreposição.

Uma taxa agregada mistura os três e apaga a informação que importa. O framework existe para separá-los antes de agregar qualquer coisa.

Camada 1: recuperação — o trecho certo chegou?

Esta é a camada mais barata de medir e a mais frequentemente ignorada. A pergunta é binária: entre os documentos que o sistema selecionou para responder, existe o trecho que de fato contém a informação?

Para medir, monte um conjunto de perguntas em que você já sabe qual documento e qual seção respondem. Rode a busca isoladamente, sem gerar resposta nenhuma, e verifique se o trecho esperado apareceu. Duas variantes valem a pena: apareceu em qualquer posição, e apareceu entre os três primeiros. A diferença entre esses dois números indica se o problema é de cobertura ou de ordenação.

Falha de cobertura costuma vir de fragmentação ruim — pedaços de documento cortados no meio de uma tabela, ou grandes demais para que a parte relevante tenha peso. Falha de ordenação costuma se resolver com uma etapa de reordenação dos candidatos, que hoje é barata o suficiente para ser padrão.

Camada 2: fidelidade — a resposta cabe no que foi recuperado?

Com o trecho certo em mãos, a próxima pergunta é se a resposta gerada se sustenta nele. Não se trata de estar certa no mundo: trata-se de estar contida no material fornecido. Uma resposta pode ser verdadeira e ainda assim ser um problema grave, se o modelo a produziu de memória em vez de ler a base da empresa — porque na próxima vez, com a política atualizada, ele vai repetir a versão antiga.

A forma prática de medir isso é exigir que cada afirmação da resposta venha com a referência ao trecho de origem, e então verificar, afirmação por afirmação, se o trecho realmente sustenta aquilo. Dá para fazer isso com revisão humana em amostra pequena, e dá para automatizar com um segundo modelo atuando como avaliador, desde que a amostra automatizada seja calibrada contra a humana de tempos em tempos.

O erro comum aqui é aceitar a citação como prova. O modelo cita o documento correto e, no meio da frase, acrescenta uma condição que o documento não menciona. Verificação de fidelidade que só confere se a citação existe não pega esse caso — ela precisa conferir se a citação sustenta o que foi dito.

Camada 3: comportamento fora de escopo — ele sabe dizer que não sabe?

Esta camada é a que mais separa um assistente utilizável de um passivo. Metade das perguntas reais de um assistente interno não tem resposta na base: são perguntas sobre exceções, sobre casos que ninguém documentou, ou sobre assuntos de outra área.

Monte um conjunto de perguntas propositalmente sem resposta na base e meça uma única coisa: em que porcentagem delas o assistente disse que não encontrou a informação, em vez de produzir algo plausível. Esse número costuma ser desconfortavelmente baixo na primeira medição, porque o comportamento padrão da maioria dos modelos é sempre responder.

Vale separar dois tipos de abstenção: a correta, quando a informação não existe mesmo, e a excessiva, quando a informação está na base e o assistente se recusa a responder. Otimizar só o primeiro número produz um assistente que não responde nada. Os dois precisam ser reportados juntos.

Camada 4: utilidade — a resposta resolve a tarefa?

Aqui a avaliação deixa de ser automatizável e passa a depender de quem usa. A resposta pode ser recuperada corretamente, fiel à fonte, e ainda assim inútil: longa demais para quem está no telefone com um cliente, ou genérica demais para quem precisa de um valor específico.

A medição prática é um julgamento de três níveis feito por quem trabalha na área: resolveu sozinha, resolveu mas exigiu conferência no documento, não resolveu. O segundo nível é o mais informativo, porque indica onde o assistente está entregando meia entrega — e meia entrega em volume alto às vezes custa mais tempo do que não ter assistente nenhum.

Camada 5: regressão — a mudança de ontem quebrou o que funcionava?

A quinta camada não mede qualidade: mede estabilidade. Todo ajuste de prompt, toda troca de versão de modelo e toda reindexação da base tem potencial de melhorar um conjunto de perguntas e piorar outro. Sem um conjunto fixo rodado antes e depois, essa troca acontece às cegas.

O conjunto de regressão precisa ser congelado e versionado como código. Quando uma pergunta é corrigida depois de uma falha real em produção, ela entra no conjunto e nunca mais sai. É assim que o conjunto ganha valor com o tempo, porque passa a conter exatamente os casos que já deram problema.

Como montar o conjunto de avaliação sem equipe dedicada

A objeção prática mais comum é que não há tempo para construir centenas de exemplos rotulados. Não precisa haver. Um conjunto inicial na casa de algumas dezenas de perguntas, escolhidas a dedo, entrega a maior parte do valor — e é infinitamente melhor do que nenhum.

1. Extraia as perguntas do histórico real. As dúvidas que as pessoas já mandavam por mensagem antes do assistente existir são o melhor material possível, porque refletem a distribuição real de perguntas, não a que você imagina.
2. Rotule só a fonte, não a resposta. Escrever a resposta ideal para cada pergunta consome tempo demais. Anotar qual documento e qual seção respondem é rápido e habilita as camadas 1 e 2 inteiras.
3. Inclua deliberadamente o que não tem resposta. Reserve em torno de um quinto do conjunto para perguntas sem resposta na base — é a única forma de medir a camada 3.
4. Estratifique por tipo de pergunta. Perguntas de valor exato, de procedimento e de exceção falham de formas diferentes. Uma média que junta os três esconde qual deles está quebrado.
5. Deixe a rodada automatizada em um comando. Se rodar a avaliação der trabalho, ela vai ser rodada uma vez e abandonada.

Se for necessário escolher por onde começar, comece pela camada 1 e pela camada 3. A primeira define o teto do sistema e é a mais barata de medir. A terceira é a que evita o incidente que derruba a confiança interna no projeto de uma vez só — e confiança interna, uma vez perdida, custa mais para recuperar do que qualquer ganho de acurácia.

Perguntas frequentes

Dá para usar um modelo de linguagem como avaliador das respostas?

Dá, e é a prática mais comum hoje para escalar a avaliação de fidelidade. A ressalva é que o avaliador também erra, e erra de forma correlacionada quando é o mesmo modelo que gerou a resposta. O caminho é calibrar: revise manualmente uma amostra do que o avaliador julgou, meça a concordância, e trate o número automatizado como estimativa com margem conhecida, não como verdade.

Com que frequência a avaliação deve ser rodada?

O conjunto de regressão, antes de cada mudança que entra em produção. As camadas de utilidade, que dependem de julgamento humano, em ciclos mais longos — mensal costuma ser suficiente para a maioria das operações, e semanal só faz sentido enquanto o sistema ainda está mudando muito.

Quantas perguntas o conjunto precisa ter para o número ser confiável?

Depende da diferença que se quer detectar. Para perceber uma variação grande, algumas dezenas bastam. Para afirmar com segurança que uma mudança melhorou o sistema em poucos pontos percentuais, o conjunto precisa ser bem maior — e nesse caso vale reconhecer que o experimento não tem poder estatístico para a afirmação, em vez de reportar a diferença como se fosse real.

Vale medir satisfação do usuário com polegar para cima e para baixo?

Vale como sinal de alerta, não como métrica de qualidade. A taxa de resposta desse tipo de botão é baixa e enviesada para os extremos: quem clica é quem ficou muito satisfeito ou muito irritado. Serve bem para encontrar casos ruins que deveriam entrar no conjunto de regressão, e mal para acompanhar tendência.