Ir para o conteúdo
Conteúdo

IA e Dados

Sistema probabilístico não se testa como software tradicional

Leandro Bryk · 12 de agosto de 2026 · 2 minutos de leitura

Revisado em 3 de setembro de 2026

O time de qualidade aplicou ao assistente de IA o mesmo regime do software tradicional: rodou os testes, todos passaram, sistema liberado. Na semana seguinte, o mesmo conjunto de perguntas produziu respostas diferentes — e ninguém sabia dizer se aquilo era falha ou comportamento esperado. A tese deste artigo: software convencional devolve a mesma saída para a mesma entrada; sistema com modelo de linguagem não. Isso exige um regime de avaliação próprio, com portfólio de métricas em vez de uma nota única.

Comece pelo conjunto de casos da sua empresa

Selecionar de trinta a cem casos reais, com a resposta correta definida por quem entende do assunto. Não são perguntas genéricas de benchmark: são os casos que a operação efetivamente enfrenta, incluindo os difíceis, os ambíguos e os que já deram problema.

Esse conjunto é o ativo mais valioso do projeto. É ele que permite comparar versões ao longo do tempo, decidir entre modelos com evidência própria e detectar degradação — e é o primeiro item que desaparece quando o projeto troca de time sem transferência formal.

Métricas por tipo de tarefa

Tarefa com alvo definido — extração de campo, classificação, roteamento: medir acerto e validade do formato estruturado. São métricas rápidas, baratas e confiáveis, executáveis automaticamente a cada mudança.

Tarefa aberta — resumo, resposta a cliente, análise: medir aderência ao contexto recuperado (groundedness), relevância à pergunta e conformidade com política interna. Nenhuma dessas três sozinha basta: uma resposta pode ser relevante e inventada, ou ancorada e irrelevante.

A separação por tipo de tarefa evita um erro comum de governança: aplicar à tarefa aberta a régua da tarefa fechada, ou vice-versa. Quem exige acerto binário de um resumo termina reprovando boas respostas; quem avalia uma extração de campo por 'qualidade percebida' deixa passar erro que uma métrica simples pegaria.

Modelo avaliando modelo, com ressalva

Usar um segundo modelo como avaliador é prático e escala: permite avaliar milhares de saídas sem esgotar o time humano. Também herda os vieses do avaliador — tendência a premiar fluência, a perdoar erro plausível bem escrito, a reproduzir os mesmos pontos cegos.

O avaliador automático serve como sinal, não como decisor final. Em domínios críticos, ele precisa de verificação humana por amostragem para confirmar que o sinal continua calibrado.

Antes de publicar e durante a operação

Avaliação antes do deploy responde "está bom o suficiente para entrar". Telemetria contínua responde "continua bom". São perguntas diferentes, e o regime que só faz a primeira descobre a degradação pela reclamação do cliente.

Sistemas degradam com mudança de modelo, de base e de comportamento do usuário — e a degradação não avisa. O fornecedor atualiza o modelo, a base acumula versões, os usuários aprendem a perguntar diferente; nenhum desses eventos dispara alerta por conta própria.

O regime completo, então, tem dois relógios: o da publicação, que roda a cada mudança de versão, instrução ou base, e o da operação, que roda continuamente sobre uma amostra do tráfego real. Empresas que mantêm apenas o primeiro descobrem a degradação pela reclamação; as que mantêm os dois a descobrem pelo painel.

A armadilha da métrica que vira meta

Quando a equipe otimiza para o indicador, o indicador deixa de medir o que media: o sistema aprende a produzir respostas que pontuam bem no avaliador, não respostas melhores.

A defesa é manter uma parte do conjunto de avaliação fora do ciclo de ajuste — casos reservados, usados só para medir, nunca para calibrar. É o equivalente a guardar uma amostra que o processo de melhoria nunca toca.

Cinco elementos de um regime de avaliação

Conjunto de casos próprio, com resposta correta validada
Métricas separadas por tipo de tarefa
Avaliador automático, com a ressalva dos vieses
Amostragem humana em domínios críticos
Telemetria contínua em produção

Case relacionado

Projeto Horizonte 180

Fontes e referências

  • NIST AI Risk Management Framework 1.0 (2023)

    Acessar a fonte
  • ISO/IEC 42001:2023 — Sistema de gestão de IA

    Acessar a fonte
  • Literatura de avaliação de sistemas generativos: métricas de groundedness e relevância contextual (NIST AI 600-1)

    Acessar a fonte

Solução ÍON relacionada

Estratégia & Gestão Empresarial

Dúvidas frequentes

Como testar um sistema com IA?
Com um conjunto de casos reais da sua operação — trinta a cem, com resposta correta definida por especialista — aplicado a cada versão antes de publicar e monitorado continuamente em produção. Diferente do software tradicional, o sistema é probabilístico: o teste mede taxa de acerto sobre o conjunto, não passa/não passa por caso isolado.
Quantos casos de teste são necessários?
De trinta a cem casos reais cobrem a maioria das aplicações corporativas, desde que incluam os casos difíceis e ambíguos, não apenas os triviais. Conjunto pequeno demais não distingue versões; conjunto só com casos fáceis esconde exatamente os erros que importam.
O que é groundedness?
É a métrica que verifica o quanto da resposta está apoiada no conteúdo recuperado da base, e não na memória do modelo. Resposta com groundedness baixo pode ser fluente e até correta por acaso, mas não é auditável — parte dela foi inventada. É uma das métricas centrais para tarefas abertas.
Um modelo pode avaliar outro?
Pode, e é prática comum porque escala. A ressalva é que o avaliador herda vieses: premia fluência, perdoa erro plausível bem escrito e compartilha pontos cegos com o avaliado. Use como sinal contínuo, com verificação humana por amostragem para manter a calibragem — nunca como decisor final em domínio crítico.
Com que frequência reavaliar?
A cada mudança de modelo, de instrução ou de base — e periodicamente mesmo sem mudança conhecida, porque o fornecedor atualiza o modelo e os usuários mudam de comportamento sem avisar. A cadência típica é mensal ou trimestral por sistema, com gatilhos extraordinários para incidentes e reclamações recorrentes.

Autor

Leandro Bryk

Consultor responsável pela ÍON Soluções, atuando em inteligência comercial, estratégia, gestão financeira, marketing e imagem corporativa.

LinkedIn

Da leitura à prática

Onde a leitura vira solução aplicada.

Indicadores apurados nos projetos da ÍON — o mesmo raciocínio deste artigo, medido em operação.

Aumento de conversão comercial
+42%
Redução do prazo médio de recebimento
31 dias
Redução do ciclo de venda
-27%

7

cases publicados com resultado apurado

Evolução agregada dos indicadores nos projetos documentados.

Indicadores consolidados dos sete cases publicados. Cada projeto tem resultados próprios, descritos individualmente em /cases. Estes valores não representam promessa de desempenho.