.webp){kind=small}
Há uma etapa no processo de desenvolvimento de ferramentas assistidas por modelos de linguagem de grande porte (LLM, na sigla em inglês) que a maioria das equipes ignora por ser tediosa, demorada e não produzir resultados visíveis para os usuários finais: verificar se o que o modelo está dizendo está realmente correto. Não se trata de fluência, coerência ou relevância temática — mas sim de estar correto no sentido de identificar com precisão a resposta certa para o problema específico que a ferramenta foi criada para resolver. A diferença entre "essa saída me parece correta" e "essa saída é comprovadamente correta" é onde a maioria das ferramentas corporativas assistidas por LLM falha silenciosamente. Elas passam pela revisão interna porque a saída parece correta.
Elas falham em produção porque essas pessoas não estavam comparando a revisão com a verdade fundamental — estavam comparando com sua intuição sobre o que seria uma boa resposta. Essa distinção se torna ainda mais importante à medida que as ferramentas assistidas por LLM passam de acessórios de produtividade para componentes que influenciam decisões de negócios reais. Se a sua ferramenta com IA influencia a forma como um analista investiga um problema de qualidade de dados, como um revisor de conformidade decide se deve escalar um registro sinalizado ou como uma equipe de operações prioriza uma falha de validação, a precisão da sua saída tem consequências reais. "Parece razoável" não é um padrão de avaliação adequado para isso.
A abordagem padrão de avaliação para a saída do LLM em ferramentas corporativas é qualitativa: uma amostra de saídas é revisada por alguém com conhecimento do domínio, avaliada em relação a um modelo mental do que seria uma boa resposta, e o prompt é ajustado se muitas saídas parecerem incorretas. Isso detecta uma classe específica de problemas: saídas que estão obviamente erradas, mal formatadas ou fora do tópico. Esses são problemas reais que valem a pena detectar. Eles também são os mais fáceis. O que a avaliação qualitativa consistentemente deixa passar é a classe de saídas que estão erradas de maneiras difíceis de perceber sem verificar com algo externo. Uma explicação que identifica com segurança a causa raiz errada, em uma linguagem que soa autoritativa, baseada em um raciocínio que soa plausível — isso passa pela revisão qualitativa.
Ela falha no momento em que alguém com o contexto correto a verifica em relação ao que realmente aconteceu. Em um sistema cuja proposta de valor depende da precisão, "soar plausível" não é o mesmo que "correto". Os dois podem divergir significativamente, e a revisão qualitativa não lhe dirá quando isso acontecer. A alternativa é construir uma estrutura de avaliação que pontua a saída do modelo em relação à verdade fundamental rotulada — um conjunto de casos em que a resposta correta é conhecida, em relação aos quais você pode medir a precisão em vez da coerência. Eu construí isso enquanto desenvolvia um explicador de causa raiz para deriva de migração de dados: uma ferramenta que pega um evento de deriva detectado e gera uma explicação classificada do que provavelmente o causou. O primeiro protótipo produziu explicações fluentes e com tom específico que passaram pela revisão qualitativa.
Quando o testei em casos em que eu já conhecia a causa raiz, a explicação estava errada com frequência suficiente para importar. A estrutura de avaliação que desenvolvi funciona em três partes. Primeiro, um conjunto de dados sintéticos de referência: casos em que a resposta correta é conhecida por construção. Isso significava introduzir causas específicas e controladas em um pipeline de teste — alterações de esquema, bugs na lógica de transformação, mudanças comportamentais no sistema de origem — registrando exatamente o que eu introduzi e executando o modelo nos eventos de deriva resultantes. A resposta correta para cada caso era a causa que eu havia introduzido deliberadamente. Obter cenários sintéticos realistas o suficiente para serem úteis exigiu mais cuidado do que eu esperava.
As primeiras versões eram muito limpas — o sinal de deriva era óbvio de maneiras que os eventos de deriva reais em produção não são. A adição de ruído realista, sinais sobrepostos e casos em que múltiplas causas plausíveis estavam presentes simultaneamente foi o que tornou o conjunto sintético realmente preditivo do desempenho no mundo real. Em segundo lugar, uma função de pontuação que avalia a saída classificada. O binário correto/incorreto não é suficiente quando o modelo produz uma lista classificada de causas prováveis em vez de uma única resposta. Uma explicação que identifica corretamente a causa raiz como a terceira candidata mais provável é significativamente diferente de uma que a identifica como a mais provável. A função de pontuação avaliou duas dimensões: Presença — a resposta correta apareceu na saída?
— e classificação — quão proeminentemente ela foi apresentada em relação às candidatas incorretas. Estas foram combinadas em uma pontuação ponderada que recompensava tanto encontrar a resposta certa quanto classificá-la adequadamente. Em terceiro lugar, avaliação sistemática em todo o conjunto de dados sintéticos, em vez de verificação pontual. Executar o sistema em todo o conjunto revela padrões que a verificação pontual não detecta: quais categorias de problemas o modelo lida de forma confiável, quais ele erra consistentemente e quais combinações de sinais produzem a maior taxa de explicações incorretas confiáveis. Os resultados foram mais informativos do que qualquer análise qualitativa poderia ter sido.
Os cenários de mudança de esquema tiveram um bom desempenho — o modelo foi confiável na identificação de mudanças de esquema a montante quando as evidências estavam presentes e eram distintas. Os erros de lógica de transformação foram mais difíceis — o modelo identificou consistentemente a categoria geral correta, mas atribuiu erroneamente a mudança específica que causou o problema, principalmente quando várias mudanças foram feitas em sequência. Os cenários de sobreposição de sinais foram os mais difíceis — os casos em que duas causas diferentes ocorreram em um curto período de tempo produziram a maior taxa de explicações comprovadamente erradas. Essa última descoberta é algo que uma análise qualitativa jamais teria revelado. A confiança expressa pelo modelo não se correlacionou com sua precisão — ele demonstrou maior confiança nos casos em que estava mais errado.
Sem a ferramenta de avaliação comparando com a verdade fundamental, esse padrão teria permanecido invisível. Para equipes que implementam ferramentas assistidas por LLM em contextos empresariais — particularmente ferramentas que influenciam a forma como as pessoas investigam problemas, priorizam alertas ou tomam decisões de roteamento — a questão fundamental a ser respondida antes da implementação em produção é: Medimos a precisão em relação a casos em que conhecemos a resposta correta ou apenas verificamos se os resultados parecem razoáveis?
.jpg)
