Categoria: Inteligência Artificial

Qual é a taxa de uso do dashboard que sua equipe de BI entregou no último trimestre? Se a resposta é “não sei”, o problema já começou: sem medir o uso, não há como distinguir um painel que decide coisas de um painel que apenas existe. Em muitas empresas, o acervo de dashboards cresce a cada pedido, enquanto as pessoas continuam a tomar decisões numa planilha paralela. O sintoma é conhecido, mas a causa raramente é técnica. Quase sempre está na forma como o painel foi pedido e desenhado.

O que segue é um framework de cinco passos para diagnosticar e corrigir um dashboard abandonado. Ele não depende de ferramenta, serve para Power BI, Looker, Metabase ou planilha, e foi organizado para que cada passo produza algo verificável.

Passo 1: medir o uso antes de culpar o painel

A primeira etapa é descobrir quanto ele realmente é aberto, por quem e com que frequência. A maioria das plataformas de BI registra acessos por usuário e por relatório, em um log ou em um painel administrativo. Extraia os últimos 90 dias e separe três números: usuários únicos que abriram o painel, número de aberturas por usuário e quantos desses usuários são o público que o painel foi feito para atender.

Esse número é uma estimativa de adoção, não de qualidade. Um painel pode ser aberto toda semana e mesmo assim não mudar nenhuma decisão. Mas se ninguém abre, a discussão sobre cores e filtros é prematura.

Vale cruzar o uso com o calendário. Se o painel é aberto no primeiro dia útil do mês e nunca mais, ele provavelmente serve a um fechamento, e não a uma gestão contínua. Isso muda a pergunta: em vez de “como aumentar o uso”, a questão passa a ser “o painel faz o que precisa fazer naquele dia?”. Também observe quem abre. Quando quase todos os acessos vêm do time de dados que construiu o painel, o dado de uso está contaminado, e o número de usuários reais do público-alvo é menor do que parece.

Por fim, anote quanto tempo cada acesso dura. Sessões de alguns segundos, repetidas, normalmente indicam que a pessoa abriu, não encontrou o que procurava e saiu. Já sessões longas e frequentes de poucas pessoas indicam um painel útil para um grupo pequeno, o que pode ser exatamente o desejado ou sinal de que o desenho só serve a quem já conhece os dados.

Passo 2: identificar qual decisão o painel deveria sustentar

Dashboards abandonados costumam ter um traço em comum: foram pedidos como “quero visibilidade do comercial”, e não como “preciso decidir se contrato mais um vendedor”. O primeiro pedido gera dezenas de métricas razoáveis e nenhuma ação. O segundo gera três ou quatro números e uma regra de leitura.

Para cada painel, escreva uma frase no formato: “Quando ___ acontece, a pessoa ___ faz ___”. Se não for possível preencher, o painel é informativo, não decisório. Isso é legítimo, mas precisa ser tratado como tal, com expectativas diferentes de manutenção e de revisão.

O exercício mais produtivo é fazê-lo com o usuário, não para ele. Sente com duas ou três pessoas do público-alvo e pergunte qual foi a última decisão que tomaram com base em dados e onde foram buscar a informação. Se a resposta é uma planilha pessoal, um e-mail do analista ou uma conversa no corredor, o painel perdeu para uma alternativa mais rápida, e vale entender por quê. Frequentemente o motivo é prosaico: o filtro necessário não existia, o dado chegava um dia depois ou o número não tinha o recorte por região que a pessoa precisava.

Anote essas respostas literalmente. Elas viram os critérios de aceitação da nova versão e evitam o erro de redesenhar o painel com base na opinião de quem o construiu.

Passo 3: auditar as métricas por pergunta, não por disponibilidade

A tentação de colocar no painel tudo o que o banco de dados permite é a segunda causa mais comum de abandono. Para cada indicador, verifique:

1. Existe uma ação associada? Se a métrica sobe ou desce, alguém sabe o que fazer.
2. A definição está documentada? Receita bruta, líquida e recorrente costumam coexistir com o mesmo nome em áreas diferentes.
3. O dado está atualizado na frequência da decisão? Painel diário com dado semanal gera desconfiança.
4. Há um valor de referência? Sem meta, histórico ou comparativo, o número isolado não diz se está bom ou ruim.
5. Quem é o dono do número? Quando uma métrica não tem dono, ninguém a corrige.

Remova ou mova para uma página de apoio o que não passar em pelo menos três desses critérios. Um painel com cinco métricas que passam nos cinco costuma ser mais usado que um com trinta.

Atenção a um problema sutil: métricas de vaidade podem passar em quase todos os critérios, porque têm dono, têm meta e são atualizadas, e mesmo assim não mudam nenhuma decisão. Exemplo clássico, número de visitantes de um site sem ligação com a receita. O teste final é perguntar o que aconteceria se aquela métrica sumisse do painel amanhã. Se a resposta é “ninguém notaria”, ela não pertence a um painel de decisão. Se a resposta é “a reunião de segunda ficaria cega”, ela deve ficar.

Passo 4: testar a confiança nos dados

Parte do abandono vem de uma pequena divergência: o número do painel não bate com o da planilha do financeiro, e a pessoa desiste de investigar. Confronte três a cinco indicadores centrais com a fonte oficial da área e documente as diferenças e as causas, que costumam ser filtro de data, regra de cancelamento, moeda ou fuso horário.

O resultado desse passo é uma lista curta de discrepâncias explicadas. Mesmo quando o painel está certo, mostrar a reconciliação aumenta a confiança. Quando está errado, melhor descobrir antes que o diretor descubra.

Passo 5: redesenhar para uma leitura de trinta segundos

Só depois dos quatro passos anteriores faz sentido mexer no visual. O princípio é que o usuário precise de poucos segundos para saber se está tudo bem ou se algo exige ação. Isso significa colocar o indicador principal no topo, com comparação contra meta ou período anterior, seguido de no máximo dois ou três gráficos de apoio. Detalhes e filtros avançados ficam em páginas secundárias.

Evite gráficos que exigem interpretação longa, como pizza com muitas fatias ou eixo duplo sem rótulo. Rótulos diretos, ordenação por valor e cores usadas com critério (por exemplo, uma cor de destaque para o que exige atenção) reduzem o esforço de leitura. Teste com duas pessoas do público-alvo: peça que descrevam em voz alta o que entendem em meio minuto. As dúvidas delas indicam o que ajustar.

Atenção também ao contexto de leitura. Um painel consultado no celular, a caminho de uma reunião, precisa de poucos elementos e fontes legíveis. Um painel projetado numa sala suporta mais detalhe, mas exige contraste alto e números grandes. Pergunte onde e quando o painel é aberto antes de decidir o layout, e não deixe essa decisão para o tamanho da tela de quem o construiu.

Mantenha uma nota de leitura curta, de uma ou duas frases, indicando de onde vem o dado, quando foi atualizado e como interpretar o indicador principal. Esse texto, pequeno, responde a metade das dúvidas que viram chamados ao time de BI e reduz a dependência de quem criou o painel.

Como saber se funcionou

Volte ao passo 1 após 60 a 90 dias e compare a razão de uso do público-alvo. Registre também se houve mudança em ações concretas: reunião que passou a usar o painel como pauta, decisão que citou o número, planilha paralela que foi desativada. Esses sinais qualitativos valem tanto quanto o acesso, porque mostram que o painel entrou no processo.

Se mesmo assim ninguém usa, considere a possibilidade de que o painel não deva existir. Desativar um relatório que não sustenta decisão é uma entrega legítima, e reduz o custo de manutenção e a confusão de quem busca o número certo.

Perguntas frequentes

Qual a quantidade ideal de métricas em um dashboard?

Não existe número exato. Como regra prática, um painel de decisão funciona com poucas métricas principais, e as demais ficam em páginas de apoio. O critério é a ação associada a cada número, não a quantidade.

Preciso trocar de ferramenta de BI?

Na maioria dos casos, não. O abandono costuma vir de pedido mal definido, métricas sem dono e falta de confiança nos dados, problemas que acompanham qualquer ferramenta.

Como medir o uso se minha plataforma não registra acessos?

Alguns recursos de log podem estar desativados por padrão. Se a plataforma realmente não oferece, uma alternativa é pedir ao público-alvo um breve levantamento sobre frequência de uso, sabendo que a estimativa será menos precisa.

Dashboard operacional e executivo seguem o mesmo método?

Sim, mas com frequências diferentes. O operacional precisa de dado mais atualizado e mais detalhe; o executivo, de síntese e comparação com meta.

Cinquenta perguntas feitas a um assistente de IA, doze respostas citando a sua marca: 24% de presença. O número cabe bem num slide e convence uma diretoria. O problema é que, com esse tamanho de amostra, o valor verdadeiro pode estar em qualquer ponto de uma faixa de aproximadamente 12 pontos percentuais para mais ou para menos. Uma queda de 24% para 18% na semana seguinte pode ser puro ruído.

Este texto propõe um método para medir presença de marca em respostas de IA com disciplina estatística básica. Os números de exemplo são ilustrativos; os de qualquer medição real dependem do seu conjunto de perguntas, dos assistentes testados e do momento da coleta.

Defina a métrica antes de coletar

“Presença” pode significar coisas diferentes, e misturar definições é a primeira fonte de erro. Escolha uma e escreva:

1. Taxa de menção: percentual de respostas que citam a marca pelo nome. É a mais simples e a mais fácil de auditar.
2. Taxa de recomendação: percentual de respostas em que a marca aparece como opção sugerida, não apenas citada de passagem. Exige critério de classificação por escrito.
3. Posição média: em respostas com lista, em que posição a marca aparece. Útil, mas só faz sentido com amostra suficiente de listas.
4. Participação relativa: menções da sua marca divididas pelo total de menções a marcas do mesmo grupo. Mostra o seu espaço frente aos concorrentes.

Monte o conjunto de perguntas como se fosse uma pesquisa

As perguntas precisam representar o que o seu cliente de fato pergunta, não o que o time de marketing gostaria que ele perguntasse. Uma boa fonte é o que o suporte e o time comercial ouvem, somado aos termos de busca que já trazem tráfego. Divida em grupos: perguntas de descoberta (“qual ferramenta usar para…”), de comparação (“A ou B para…”) e de decisão (“vale a pena contratar…”).

Dois cuidados evitam viés. O primeiro é não incluir o nome da sua marca nas perguntas de descoberta, porque isso garante a menção e infla o número. O segundo é variar a redação: a mesma intenção escrita de quatro formas diferentes revela se a presença depende de uma frase específica.

Calcule o tamanho da amostra e a margem de erro

A margem de erro aproximada para uma proporção p com n respostas é 1,96 × raiz de p(1−p)/n. Para p = 24% e n = 50, o resultado é cerca de 12 pontos percentuais. Para n = 200, cai para cerca de 6 pontos. Para n = 800, algo próximo de 3.

Isso é uma aproximação, e vale com duas ressalvas. Respostas repetidas do mesmo assistente para a mesma pergunta não são amostras independentes, então a margem real tende a ser maior do que a calculada. E se a taxa é muito próxima de 0% ou de 100%, a fórmula perde precisão. Trate esses valores como ordem de grandeza.

Repita a coleta, porque a resposta muda

Assistentes de IA geram respostas com variação interna. A mesma pergunta, feita duas vezes seguidas, pode devolver listas diferentes. Por isso, rode cada pergunta mais de uma vez, em dias diferentes, e registre a data, o assistente e a versão informada, quando houver. Misturar coletas de modelos distintos num único percentual esconde diferenças relevantes: separe por assistente.

Uma regra prática é só chamar de tendência uma variação que se sustenta por pelo menos três coletas seguidas e que supera a margem de erro. Uma queda isolada de seis pontos com n = 50 não conta como evidência de nada.

Onde a medição engana

Há quatro armadilhas recorrentes. A primeira é o viés de formulação: perguntas escritas pelo time de marca favorecem a marca. A segunda é a mudança silenciosa do modelo: uma atualização do assistente muda os resultados sem que nada tenha mudado no seu site. A terceira é a confusão entre menção e impacto: ser citado não é o mesmo que gerar clique ou venda, e ligar uma coisa à outra exige dados de tráfego e de conversão que a medição de menções sozinha não fornece. A quarta é a personalização: respostas variam conforme o histórico e a localização de quem pergunta, então uma coleta feita em uma única conta pode não refletir o que o público vê.

Um exemplo completo, com números ilustrativos

Suponha uma empresa de software de gestão que monta um conjunto de 120 perguntas, divididas em três grupos de 40: descoberta, comparação e decisão. Cada pergunta é feita duas vezes por semana a dois assistentes, durante três semanas. Isso gera 120 × 2 × 2 × 3 = 1.440 respostas no total, ou 720 por assistente.

Na primeira semana, o assistente A cita a marca em 22% das respostas e, na terceira, em 27%. A diferença é de cinco pontos percentuais. Com 240 respostas por semana por assistente, a margem de erro de cada medida fica em torno de 5 a 6 pontos. Ou seja: a diferença está dentro do ruído, e afirmar que a marca “cresceu” seria precipitado. O que se pode dizer é que a medida está estável ou que há um sinal fraco de alta que precisa de mais coletas para ser confirmado.

No assistente B, a taxa vai de 10% para 24% ao longo das mesmas três semanas. Aqui a diferença é de 14 pontos, maior do que a soma das margens, e se repete em coletas consecutivas. Essa variação merece investigação: a empresa publicou conteúdo novo no período? O assistente mudou de versão? O concorrente principal perdeu presença? Sem registrar esses eventos junto da série, o número vira curiosidade.

Por fim, o grupo de perguntas importa. Se a presença no grupo de comparação é de 40% e no de descoberta é de 8%, o problema da marca é de visibilidade em quem ainda não a conhece, e a estratégia de conteúdo deve mirar nesse grupo. Médias gerais escondem esse padrão e levam a decisões erradas.

Como documentar a metodologia para que ela seja auditável

Uma medição só é útil se outra pessoa conseguir refazê-la e chegar ao mesmo resultado. Mantenha um documento de método com cinco itens: a lista completa de perguntas e a data da última revisão; a definição de cada métrica; a lista de assistentes e as versões, quando informadas; o procedimento de coleta, incluindo conta, idioma e localização; e as regras de classificação das respostas, com exemplos de casos duvidosos.

A classificação merece atenção especial. Quando duas pessoas classificam as mesmas 100 respostas de forma independente, a concordância entre elas indica se a regra está clara. Se discordam em muitos casos, a regra precisa ser reescrita antes de a série histórica ser comparada. Sem isso, a oscilação do número pode refletir mudança de quem classifica, e não mudança do assistente.

Guarde também as respostas brutas, com data e pergunta, em vez de guardar só o resultado agregado. Se a diretoria questionar um número daqui a seis meses, será possível voltar ao texto original. E se o critério mudar, é possível reclassificar todo o histórico, evitando uma quebra na série que inviabilize a comparação.

Por fim, estabeleça um calendário. Coletas semanais com o mesmo conjunto de perguntas por pelo menos oito a doze semanas formam uma linha de base suficiente para distinguir a variação normal de uma mudança real. Antes disso, qualquer interpretação deve ser apresentada como hipótese de trabalho.

Como levar isso para a reunião

Em vez de apresentar um percentual único, apresente três coisas: a taxa com a margem de erro, a comparação com os concorrentes no mesmo conjunto de perguntas e a variação ao longo de ao menos três coletas. Se a diretoria perguntar se vale investir em conteúdo para melhorar essa presença, a resposta honesta é que existem hipóteses plausíveis, mas poucas evidências causais publicadas, então o investimento deve ser tratado como experimento com métrica definida e prazo para reavaliar.

Resumindo o método em uma frase: defina a métrica, represente o público nas perguntas, calcule a margem de erro, repita a coleta e só chame de tendência o que sobrevive a três rodadas seguidas.

Perguntas frequentes

Quantas perguntas eu preciso, no mínimo?

Para comparar períodos com alguma confiança, procure algo na casa das centenas de respostas por assistente. Com menos de cinquenta, use o resultado apenas como exploração.

Posso automatizar a coleta?

Pode, desde que respeite os termos de uso de cada serviço. Automatizar ajuda a repetir a coleta, mas a classificação das respostas precisa de uma amostra revisada por humanos para checar erros.

Menção negativa conta?

Registre separadamente. Uma menção que recomenda não ficar com a sua marca tem valor oposto ao de uma recomendação, e somar as duas distorce o resultado.

Como saber se a mudança foi causada pelo meu conteúdo?

Em geral, não dá para saber só com esse tipo de medição. Para sustentar causalidade, compare páginas ou temas que receberam conteúdo novo com temas parecidos que não receberam, no mesmo período, e registre a data de cada publicação. Mesmo assim, o resultado é indício, não prova: assistentes mudam de versão, e concorrentes também publicam.

Vale medir também as fontes citadas pelo assistente?

Vale, quando o assistente informa fontes. Registrar quais domínios aparecem mostra de onde a resposta se alimenta e ajuda a priorizar onde ter presença. Trate a lista como um retrato da coleta, sujeito às mesmas margens de erro e à mesma variação entre execuções que a taxa de menção.

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.

Uma plataforma de automação de marketing com IA fecha o mês reportando que os fluxos automatizados geraram R$ 180 mil em receita atribuída. Na reunião seguinte, quase ninguém faz a pergunta que decide o orçamento do ano: quanto dessa receita não teria acontecido de qualquer maneira? Receita atribuída e ganho incremental são coisas diferentes, e a distância entre as duas costuma ser grande justamente nos fluxos que parecem melhores.

Este texto é sobre desenho de medição, não sobre escolha de ferramenta. O problema descrito aqui aparece igual em qualquer plataforma, porque ele não está no produto — está na forma como o número é calculado.

O que o painel mede e o que ele deixa de fora

A esmagadora maioria dos relatórios de automação usa atribuição por último toque dentro de uma janela — o clique ou a abertura mais recente antes da conversão, normalmente com janela de alguns dias. A regra é razoável para organizar o relatório. O problema é que ela responde a uma pergunta descritiva (“qual foi o último contato antes da compra?”) e é lida como se respondesse a uma pergunta causal (“essa mensagem causou a compra?”).

A distorção não é aleatória, e é aí que ela machuca. Fluxos automatizados são disparados por sinal de intenção: carrinho abandonado, visita repetida à página de preço, fim de trial, aniversário de contrato. São exatamente os usuários com maior probabilidade de comprar sem estímulo nenhum. A automação chega por último numa fila que já estava andando e leva o crédito da fila inteira.

Camadas de IA agravam o efeito em vez de corrigi-lo. Um modelo de propensão que escolhe quem receber a mensagem é treinado para identificar quem tem maior chance de converter — ou seja, é otimizado para selecionar pessoas cuja conversão seria mais provável de qualquer forma. Quanto melhor o modelo de propensão, mais inflada fica a receita atribuída e menor tende a ser a parcela realmente incremental. É um caso em que a métrica melhora enquanto o argumento piora.

Por que a sazonalidade contamina a comparação antes e depois

O segundo desenho mais comum é a comparação temporal: liga-se a automação em determinado mês e compara-se o trimestre seguinte com o anterior. O desenho parece limpo porque a base é a mesma. Não é.

Entre os dois períodos mudaram, no mínimo: o calendário comercial, o volume de mídia paga, o mix de canais de aquisição, a composição da base (quem entrou nos últimos noventa dias tem comportamento diferente de quem está há dois anos) e, com frequência, o preço. Em varejo, a diferença entre novembro e setembro basta para produzir sozinha uma variação de dois dígitos. Em B2B com ciclo trimestral, o último mês do trimestre carrega uma concentração de fechamentos que nada tem a ver com o fluxo de e-mail.

Há um agravante prático: automação quase nunca é ligada em momento neutro. Ela costuma ser ligada quando o time decidiu investir em crescimento — junto com mais verba de mídia, campanha nova e às vezes promoção. O antes e depois mede o pacote inteiro e credita o resultado ao componente mais fácil de instrumentar.

O desenho que isola o efeito: holdout aleatório

O único desenho que responde à pergunta causal sem depender de suposição forte é reservar aleatoriamente uma parte da base que não recebe a automação, e comparar os dois grupos no mesmo intervalo de tempo. Como os dois grupos atravessam a mesma Black Friday, a mesma greve dos Correios e o mesmo reajuste de preço, tudo que é sazonal se cancela.

O procedimento mínimo tem cinco etapas:

1. Definir a unidade de aleatorização. Normalmente o usuário; em operações com contas multiusuário, a conta, para evitar que duas pessoas da mesma empresa caiam em grupos diferentes.
2. Sortear antes de qualquer filtro de elegibilidade. O sorteio precisa acontecer sobre toda a base que poderia entrar no fluxo, não sobre quem o modelo já selecionou — caso contrário o viés de seleção volta pela porta dos fundos.
3. Congelar o grupo de controle por um período inteiro. Trocar quem está no holdout a cada campanha destrói a comparação, porque contamina o controle com exposição parcial.
4. Definir a métrica primária antes de olhar o resultado. Uma só: receita por usuário no período, ou taxa de conversão, ou retenção. As demais entram como secundárias e não decidem nada sozinhas.
5. Fixar a data de leitura. Olhar todo dia e parar quando dá significância é a forma mais rápida de transformar ruído em decisão.

Quanto de base reservar sem travar a operação

A pergunta que trava o projeto na prática costuma ser comercial: ninguém quer abrir mão de receita para medir. A resposta depende do tamanho do efeito que se quer detectar, e essa relação é pouco intuitiva — detectar um efeito pela metade do tamanho exige aproximadamente quatro vezes mais gente em cada grupo, não o dobro.

Isso tem uma consequência prática direta. Se a expectativa honesta de ganho é da ordem de poucos pontos percentuais sobre a taxa de conversão atual, o experimento precisa de dezenas de milhares de usuários por grupo para distinguir o efeito do ruído. Bases pequenas simplesmente não conseguem medir efeitos pequenos, e insistir produz um resultado inconclusivo caro. Os números exatos variam com a taxa de conversão de partida e com a variância do ticket — em receita por usuário, onde uma minoria de compradores grandes domina a média, a variância é alta e a amostra necessária cresce bastante.

Duas saídas honestas quando a base é pequena: rodar o holdout por mais tempo, acumulando volume, ou aceitar que só efeitos grandes serão detectáveis e declarar isso antes de começar. A saída desonesta é rodar com amostra insuficiente e apresentar a diferença observada como se fosse resultado.

Sobre o tamanho do holdout: reservar 10% da base costuma ser o ponto onde o custo de oportunidade é tolerável para o time comercial. Se a base for pequena, dividir meio a meio é estatisticamente muito mais eficiente e vale a negociação interna — a perda de receita durante um trimestre é menor do que o custo de manter por anos um fluxo que não funciona.

A conta do ganho incremental

Com o holdout rodando, a conta é subtração. O exemplo abaixo usa números redondos apenas para mostrar a mecânica; não é benchmark de nenhum setor.

O ganho incremental por usuário é R$ 1,20 — a diferença entre R$ 18,00 e R$ 16,80. Aplicado aos 90 mil expostos, dá cerca de R$ 108 mil de receita que não existiria sem a automação. O painel da ferramenta, nesse mesmo cenário, reportaria como receita atribuída algo próximo dos R$ 400 mil que passaram por algum toque do fluxo. A diferença entre os dois números não é erro da ferramenta: são perguntas diferentes.

Só o segundo número entra na conta de retorno. Contra ele se coloca o custo total: licença da plataforma, custo de inferência do modelo, horas de operação e de dados. Se o incremental não cobrir esse total com folga, o projeto está se pagando com receita que já era da casa.

Quando o holdout não é possível

Há casos legítimos em que reservar usuários não funciona: base muito pequena, canal que não permite exclusão individual, ou efeito de rede entre usuários que contamina o controle. As alternativas resolvem parcialmente e cada uma cobra um preço.

Havendo escolha, o holdout aleatório vence com folga e não é perto. A segunda melhor opção, na prática, é o rollout escalonado, porque ele costuma já estar no plano de implantação e só exige que se registre com precisão a data de entrada de cada grupo. Diferenças em diferenças serve para recuperar uma estimativa quando a chance de experimentar foi perdida, e deve ser apresentada com esse nome — estimativa retrospectiva, não medição.

Perguntas frequentes

Dá para medir incrementalidade sem prejudicar quem está no holdout?

O grupo de controle continua recebendo tudo que já recebia antes da automação — comunicação padrão, atendimento, campanhas gerais. Ele não fica sem contato; fica sem o fluxo específico que está em teste. Essa distinção costuma resolver a objeção comercial.

Por quanto tempo o holdout precisa ficar no ar?

No mínimo um ciclo completo de compra do negócio, para não cortar conversões que ainda estavam em curso. Em varejo de recompra rápida isso pode ser algumas semanas; em B2B com ciclo longo, um trimestre inteiro é o piso.

E se o resultado der diferença negativa?

Acontece com mais frequência do que se admite, sobretudo em fluxos de alta frequência que aceleram descadastro. Diferença negativa com amostra adequada é informação de altíssimo valor: significa que o fluxo está custando dinheiro em dois lugares ao mesmo tempo.

O modelo de atribuição multi-toque resolve o problema?

Não. Modelos multi-toque distribuem crédito de forma mais elegante entre os pontos de contato, mas continuam repartindo conversões observadas. Nenhum deles observa o que teria acontecido sem o contato, que é justamente a informação que falta.

Vale reaproveitar o holdout para medir outros fluxos?

Só se o grupo estiver excluído de todos eles. Um holdout que não recebe o fluxo A mas recebe o B mede a diferença entre A e B, não o efeito de A. Operações maduras mantêm um holdout global pequeno e permanente, separado dos testes pontuais.

Qual porcentagem do tráfego do seu site já vem de respostas geradas por IA? Se a resposta honesta for “não sei separar isso no relatório”, esse é o verdadeiro ponto de partida — e é também a razão pela qual o debate sobre “otimizar para IA” anda girando em falso desde o ano passado.

A tese que circula em praticamente toda apresentação comercial de ferramenta é simples: o SEO acabou, agora existe uma disciplina nova, com regras próprias, e quem não migrar some. A tese oposta, defendida por parte dos times técnicos, é igualmente simples: não mudou nada, continue fazendo bem feito o que já fazia. Nenhuma das duas sobrevive a uma medição cuidadosa. O que muda é real, mas está em um lugar diferente de onde o discurso aponta.

O que a evidência disponível permite afirmar hoje

Os sistemas de resposta generativa — tanto os assistentes independentes quanto os resumos que aparecem no topo da busca — funcionam em duas camadas separadas. A primeira recupera documentos; a segunda redige uma resposta a partir deles. Essa separação não é um detalhe de arquitetura: é o eixo de tudo o que vem a seguir.

A camada de recuperação depende de o conteúdo existir, estar acessível a um rastreador e ser recuperável por uma consulta. Isso é, em essência, o mesmo conjunto de exigências que a busca tradicional impõe há duas décadas. Página que o rastreador não alcança não entra em índice nenhum — nem no da busca, nem no da base que alimenta o gerador.

A camada de geração é onde a diferença mora. Ela não escolhe uma página para exibir: ela escolhe trechos para costurar. Um documento pode ser recuperado, ter uma frase aproveitada e nunca gerar clique. Do ponto de vista da recuperação, foi um sucesso. Do ponto de vista do relatório de sessões, não aconteceu nada.

Onde a narrativa do “SEO acabou” quebra

O argumento comercial costuma sustentar que existe uma técnica nova de escrita que faz o modelo escolher o seu conteúdo. Na prática, o que se observa nos testes que dá para reproduzir em casa é bem menos glamouroso: o que aumenta a chance de ser recuperado continua sendo cobertura de tema, clareza de definição, dado verificável e estrutura que permita extrair uma afirmação isolada do parágrafo.

Isso descreve conteúdo bom. Descrevia conteúdo bom antes também. A diferença é que a busca tradicional tolerava razoavelmente bem uma página que respondia mal mas tinha autoridade acumulada, enquanto o gerador precisa de uma frase que se sustente sozinha, fora do contexto do artigo. Página que só faz sentido lida inteira tende a ser ignorada na hora de montar a resposta.

Há um segundo ponto que raramente aparece nas apresentações: o comportamento varia muito entre assistentes. Alguns priorizam fontes com histórico consolidado; outros priorizam frescor; outros ainda dependem fortemente do índice de um buscador terceiro. Otimizar “para IA” no singular é uma abstração — o comportamento é plural e instável entre versões.

O que muda de verdade: a unidade de resultado

A mudança concreta não é de técnica de conteúdo. É de unidade de medida. O SEO clássico organizava tudo em torno de uma cadeia previsível: impressão gera clique, clique gera sessão, sessão gera conversão. Essa cadeia continua existindo, mas passou a conviver com um caminho paralelo em que a impressão acontece dentro de uma resposta que o usuário lê sem sair de onde está.

Para quem vende produto de ticket baixo e decisão rápida, isso é perda direta. Para quem vende produto de ciclo longo, é mais ambíguo: a marca aparece na fase de pesquisa, o usuário não clica ali, e volta duas semanas depois por busca direta pelo nome. Esse retorno aparece no relatório como tráfego direto ou de marca, sem qualquer vínculo com a citação que o originou. É por isso que muita queda de tráfego orgânico atribuída a “IA” vem acompanhada de alta em busca por marca — e ninguém conecta as duas linhas.

Vale nomear o efeito colateral dessa mudança de unidade: a taxa de clique deixou de ser um indicador limpo de qualidade da página. Antes, título fraco derrubava a taxa de clique e título forte a recuperava, e a leitura era direta. Hoje, a mesma consulta pode ter perdido metade do clique porque ganhou um resumo no topo, sem que nada na sua página tenha piorado. Times que continuam otimizando título contra uma linha de taxa de clique em queda estão perseguindo uma variável que saiu do controle deles — e queimando ciclos de teste em cima de ruído. O teste de sanidade é simples: se a queda de clique é homogênea entre todas as posições e todas as páginas de um mesmo tipo de consulta, a causa é do formato do resultado, não da sua redação.

SEO clássico e otimização para resposta gerada, lado a lado

A leitura da tabela é o argumento central deste texto: cinco das seis linhas descrevem diferenças de medição e exibição, não de produção de conteúdo. Quem trata isso como uma disciplina nova está reorganizando o time em torno de um problema de instrumentação.

Como medir sem inventar métrica nova

A instrumentação mínima cabe em quatro movimentos, e nenhum deles exige ferramenta que não esteja na sua casa.

1. Separe o tráfego de referência vindo de assistentes. Os domínios de origem desses produtos são poucos e conhecidos; um segmento fixo no seu analytics isola essa fatia e passa a mostrar volume e conversão dela em vez de diluí-la no “direto”.
2. Acompanhe a série de busca por marca. Se o orgânico não-marca cai e o de marca sobe no mesmo período, o mais provável é deslocamento de etapa, não perda de demanda.
3. Monte um painel de consultas de referência. Escolha entre vinte e cinquenta perguntas que descrevem a decisão do seu cliente, rode manualmente uma vez por mês nos assistentes que importam para o seu público, e registre apenas duas colunas: houve citação, e de quem. É trabalho braçal, e é o único dado confiável que existe hoje sobre esse canal.
4. Compare taxa de clique por tipo de consulta. Consultas de definição e de “o que é” tendem a perder clique com resumo no topo; consultas transacionais e de comparação de preço tendem a resistir. Se a queda estiver concentrada no primeiro grupo, o diagnóstico já está pronto.

Sobre ordens de grandeza: a fatia de sessões vinda diretamente de assistentes ainda é pequena na maioria dos sites brasileiros que dá para observar — tipicamente de um a poucos por cento do orgânico, com enorme variação por setor. O efeito relevante hoje não é o tráfego que chega por ali; é o clique que deixa de acontecer na busca. Esse segundo número é maior e muito mais difícil de isolar, porque só aparece como taxa de clique caindo com impressão estável.

A decisão prática, com o custo na mesa

Diante do quadro acima, a posição defensável é esta: não monte um time separado de “otimização para IA”. Trate o assunto como uma extensão da operação de conteúdo existente, com três ajustes.

O primeiro é editorial: cada peça precisa conter afirmações que se sustentem fora do parágrafo. Definição fechada, número com a origem colada nele, critério de escolha explícito. Isso melhora o conteúdo para o leitor humano também, o que torna o custo do ajuste próximo de zero.

O segundo é de portfólio: aceitar que páginas puramente definicionais vão perder clique de forma estrutural e parar de investir nelas como se fossem porta de entrada. Elas continuam úteis para cobertura de tema, mas o retorno delas migrou de sessão para presença.

O terceiro é de relatório: mudar a meta do time. Enquanto o indicador principal for sessão orgânica, qualquer conteúdo que gere citação sem clique aparece como fracasso, e o time vai naturalmente parar de produzi-lo. Se você acredita que presença em resposta gerada importa, ela precisa existir como linha no painel — mesmo medida à mão, mesmo com amostra pequena.

O erro caro aqui não é ignorar o canal. É reorganizar orçamento e equipe com base em uma métrica que ninguém no mercado consegue auditar, vendida por quem também vende a ferramenta que promete otimizá-la.

Perguntas frequentes

Dados estruturados aumentam a chance de o meu conteúdo ser citado?

Ajudam a delimitar qual é a afirmação da página e facilitam a extração, mas não há garantia observável de que a presença do marcador aumente a citação. Vale manter pela função original — exibição no resultado de busca — e tratar qualquer ganho na resposta gerada como efeito colateral, não como objetivo.

Bloquear rastreadores de IA protege o meu conteúdo?

Protege do uso, e ao mesmo tempo elimina a chance de citação. É uma decisão de negócio, não técnica: faz sentido para quem monetiza acesso ao conteúdo em si, e costuma ser prejudicial para quem usa conteúdo para gerar demanda. Decida pela fonte de receita, não pelo princípio.

Dá para saber quantas vezes minha marca foi citada sem rodar consulta manual?

Existem ferramentas que se propõem a isso, e todas trabalham por amostragem de consultas — nenhuma tem acesso ao volume real. São úteis para tendência, e não para número absoluto. Cobre de qualquer fornecedor a metodologia de amostragem antes de aceitar o número.

Publicar mais conteúdo aumenta a presença em respostas geradas?

Aumenta a superfície de recuperação, o que ajuda até certo ponto. Mas volume sem profundidade tende a produzir páginas que não têm nenhuma afirmação forte o suficiente para ser aproveitada. Entre dobrar o número de textos e melhorar a densidade dos que já existem, o segundo caminho tem se mostrado mais eficiente para esse fim específico.

Uma pergunta antes de qualquer ajuste: qual porcentagem das perguntas reais chega ao modelo já com o trecho correto dentro do contexto? Quem não tem esse número não está otimizando um assistente — está ajustando prompt no escuro e esperando que a média suba.

É o cenário mais comum em projetos de RAG que passam da prova de conceito. O time monta um conjunto de trinta perguntas, roda, vê acerto alto, libera para a área de negócio. Duas semanas depois chega o relato de que o assistente inventa procedimento, cita política revogada e responde com segurança sobre coisas que não existem. E a discussão vira sobre trocar de modelo, quando o problema quase nunca está ali.

Uma métrica agregada esconde duas falhas com causas opostas

Acurácia de resposta é uma métrica de saída. Ela mistura, num número só, duas etapas que falham por motivos diferentes e se corrigem com intervenções diferentes.

A primeira é a recuperação: dada a pergunta, o sistema encontrou e colocou no contexto o trecho que continha a informação. A segunda é a geração: tendo o trecho em mãos, o modelo produziu uma resposta fiel ao que estava escrito.

Quando as duas etapas são medidas juntas, cada queda de acurácia comporta pelo menos quatro histórias distintas — o trecho não existe no acervo, existe mas não foi recuperado, foi recuperado mas ficou soterrado entre passagens irrelevantes, ou chegou íntegro e o modelo respondeu outra coisa. As quatro exigem times, prazos e orçamentos diferentes. Tratar todas com engenharia de prompt é o desperdício mais frequente nesse tipo de projeto.

O teto de recuperação, e por que ele define o resto

Existe um número que limita todos os outros. Se o trecho correto entra no contexto em, digamos, 70% das perguntas, então 70% é o teto de acurácia final do sistema. Nas outras 30% o modelo está sendo convidado a responder sem a informação — e o comportamento esperado ali é recusar, não acertar.

Esse raciocínio inverte a ordem natural das tentativas. A maioria dos times começa pela camada mais visível — o prompt — porque é a mais barata de mexer. Só que a camada mais barata de mexer é também a que tem menos margem quando o teto está baixo. Vale medir o teto primeiro e só depois decidir onde investir.

O teste do oráculo: quinze minutos que localizam a falha

Há um experimento simples que separa as duas etapas sem instrumentação sofisticada. Pegue as perguntas que o sistema errou. Para cada uma, localize manualmente o trecho correto na documentação e cole esse trecho no contexto, ignorando a busca. Rode a geração de novo.

A leitura do resultado é direta:

1. O modelo passa a acertar com o trecho colado. A falha é de recuperação. Prompt não é o problema, e mexer nele vai consumir semanas sem mover o indicador.
2. O modelo continua errando mesmo com o trecho correto no contexto. A falha é de geração — instrução ambígua, contexto longo demais, conflito entre o que o documento diz e o que o modelo já sabia, ou pergunta que exige combinar duas fontes.
3. O trecho correto não existe no acervo. Não é um problema de IA. É um problema de documentação, e nenhuma camada técnica resolve.

Esse terceiro caso costuma responder por uma fatia maior do que os times esperam quando o acervo veio de wiki interna acumulada por anos. Vale conferir antes de abrir qualquer ticket de engenharia.

Duas variações do teste rendem informação adicional por pouco esforço. A primeira é repetir a geração com o trecho correto sozinho no contexto e depois com o trecho correto misturado às passagens que a busca havia trazido. Se o acerto aparece no primeiro caso e some no segundo, o problema não é nem busca nem modelo — é ruído de contexto, e a correção passa por reordenação. A segunda é rodar a mesma pergunta reescrita com as palavras que a documentação usa, em vez das palavras que o usuário usou. Quando isso resolve, o desencontro é de vocabulário, e reescrita de consulta ou busca por termo entram na lista de intervenções antes de qualquer coisa mais cara.

As quatro métricas que substituem a média única

Para acompanhar o sistema ao longo do tempo, quatro indicadores dão conta e se calculam sem ferramenta paga:

1. Recall@k — em que porcentagem das perguntas o trecho-âncora anotado aparece entre os k documentos recuperados. É o teto descrito acima.
2. Precisão do contexto — que fração do que entrou no contexto era de fato relevante. Precisão baixa com recall alto significa que o trecho certo está lá, cercado de ruído, e o problema é de ordenação, não de busca.
3. Fidelidade ao contexto — que fração das afirmações da resposta é sustentada por alguma passagem recuperada. É a métrica que captura alucinação de forma auditável, porque cada afirmação pode ser rastreada até um trecho ou até a ausência dele.
4. Taxa de recusa apropriada — com que frequência o sistema diz que não sabe quando o contexto realmente não continha a resposta. Esse indicador costuma ser esquecido, e é o que separa um assistente confiável de um que responde bonito sobre qualquer coisa.

Um conjunto de avaliação de algumas dezenas a poucas centenas de perguntas reais, cada uma com o trecho-âncora anotado por alguém da área, já entrega leitura estável. O que muda o resultado não é o tamanho do conjunto — é a origem das perguntas. Conjunto escrito pelo time de engenharia mede o sistema contra a linguagem da engenharia, que não é a linguagem de quem usa.

Sintoma, etapa provável e teste correspondente

Na prática, a leitura desses quatro indicadores fica mais rápida quando o ponto de partida é o sintoma relatado pelo usuário. A tabela abaixo faz esse caminho inverso — do que se ouve na reclamação até a medição que confirma ou descarta a hipótese.

Duas crenças que consomem orçamento sem mover indicador

A primeira é a de que ampliar a janela de contexto resolve recuperação ruim. Enfiar cinquenta passagens no contexto porque a busca não é confiável aumenta o custo por chamada, aumenta a latência e piora a precisão do contexto. Modelos tendem a dar menos peso ao que está no meio de contextos longos, então a passagem correta pode estar presente e ainda assim ser ignorada. Reordenar bem dez passagens costuma render mais do que despejar cinquenta.

A segunda é a de que trocar o modelo de geração é a alavanca principal. Modelo melhor ajuda quando a falha é de geração — raciocínio sobre duas fontes, síntese, obediência a formato. Quando a falha é de recuperação, o modelo mais caro do mercado continua respondendo sobre um contexto que não tem a informação, e o ganho fica na margem de erro da medição.

Há ainda uma terceira crença, mais discreta: a de que ajuste fino do modelo ensina o conhecimento da empresa e dispensa a recuperação. Ajuste fino é eficiente para formato, tom e obediência a instrução, e ineficiente como forma de armazenar fato que muda. Acervo corporativo é revisado, revogado e substituído — e cada revisão exigiria treinar de novo, com custo recorrente e sem rastreabilidade. Quando alguém pergunta de onde saiu determinada resposta, um sistema baseado em recuperação aponta o documento; um modelo ajustado aponta para si mesmo. Em contexto sujeito a auditoria, essa diferença costuma valer mais do que qualquer ponto percentual de acurácia.

Ordem de intervenção, do mais barato ao mais caro

Havendo teto de recuperação baixo, a sequência que costuma render mais por hora investida é esta. Primeiro, higiene do acervo: eliminar duplicata, marcar vigência, retirar o que está revogado. É trabalho de conteúdo, não de engenharia, e frequentemente é o que devolve mais pontos de recall.

Depois, revisar fragmentação e metadados — respeitar limite de seção, manter tabela inteira em um mesmo bloco, carimbar área, produto e data em cada trecho para permitir filtro antes da busca. Em seguida, busca híbrida, combinando busca vetorial com busca por termo. Vocabulário interno, sigla e código de produto costumam ser mal representados em embedding genérico, e é justamente isso que o usuário digita.

Só então entram reordenador dedicado e ajuste de prompt com exigência de citação de trecho. Ajuste fino do modelo fica por último, e na maioria dos casos corporativos não chega a ser necessário — quando chega, é para formato e tom, raramente para conhecimento.

Se fosse preciso escolher uma única mudança para um assistente interno que já está em produção e decepciona, a escolha seria a busca híbrida com filtro por metadado de vigência. É a intervenção que ataca ao mesmo tempo o vocabulário interno e o problema de documento velho, que juntos explicam boa parte dos erros relatados pelo usuário final.

Perguntas frequentes

Quantas perguntas o conjunto de avaliação precisa ter?

Algumas dezenas já revelam padrão; algumas centenas dão estabilidade para comparar versões. Prioridade absoluta para perguntas extraídas de log real, não escritas pelo time técnico.

Dá para medir fidelidade sem revisão manual?

Dá, usando um modelo como avaliador que verifica cada afirmação contra o contexto. Vale calibrar o avaliador contra uma amostra revisada por pessoa antes de confiar no número em série.

Qual valor de k usar na recuperação?

Depende do tamanho do bloco e do custo aceitável. O método é medir recall@k para valores crescentes e parar onde a curva achata — aumentar k depois desse ponto adiciona ruído sem adicionar informação.

Busca vetorial pura nunca basta?

Basta quando o vocabulário do usuário se parece com o do documento e não há sigla nem código proprietário. Em base corporativa isso é raro, e o teste de recall com perguntas reais mostra a diferença em poucas horas.

Com que frequência reavaliar?

A cada alteração relevante no acervo e a cada troca de componente do pipeline. Acervo vivo degrada recuperação em silêncio, e sem reavaliação periódica a queda só aparece na reclamação do usuário.

Uma pergunta resolve mais projeto de inteligência artificial do que a escolha da arquitetura do modelo: quantos registros da base têm, ao mesmo tempo, o rótulo correto, as variáveis preenchidas e a garantia de que essas variáveis já existiam no instante em que a decisão precisava ser tomada? Em auditorias de base feitas antes de projetos de classificação, esse número costuma ficar bem abaixo do total que aparece no relatório do banco. Quedas de metade ou mais são comuns quando os três filtros são aplicados juntos — a magnitude varia bastante por setor e por maturidade de coleta, então trate isso como padrão observado, não como percentual fechado.

O framework abaixo é uma sequência de cinco verificações, cada uma com um número de saída. A ordem importa: cada etapa reduz a base que a seguinte examina, e parar na etapa 2 com uma base já inviável economiza semanas de engenharia de features sobre dados que não sustentariam o resultado.

Etapa 1 — Cobertura efetiva: quantas linhas o modelo vai realmente ver

A primeira medição separa registros existentes de registros utilizáveis. Um pedido de crédito arquivado há seis anos existe na tabela, mas se o formulário mudou de campos em 2024, ele não contribui com as mesmas variáveis dos pedidos recentes. O procedimento é simples e quase sempre revelador:

1. Conte o total bruto de registros no período que interessa. Defina o período pela estabilidade do processo, não pela disponibilidade do dado — se a regra de negócio mudou, o corte é ali.
2. Aplique o filtro de completude por variável obrigatória. Para cada campo que o modelo vai usar, meça o percentual de preenchimento; qualquer variável abaixo de 70% de preenchimento é candidata a ser cortada ou tratada como categoria própria.
3. Meça a interseção, não a média. Este é o erro mais frequente da etapa. Cinco variáveis com 90% de preenchimento cada não produzem uma base 90% completa: se as ausências forem independentes, sobram cerca de 59% dos registros com todas as cinco preenchidas. Na prática as ausências são correlacionadas e o número real fica em algum ponto entre 59% e 90%, mas quase nunca perto do topo.

O mercado tende a tratar dado faltante como problema de imputação. Em boa parte dos casos, ausência não é ruído — é sinal. Um campo de renda vazio pode significar que o analista não perguntou porque já tinha decidido negar. Imputar a mediana ali destrói informação e infla artificialmente a performance de treino.

Etapa 2 — Procedência do rótulo: quem decidiu que aquilo é verdade

Modelo supervisionado aprende a reproduzir um rótulo. Se o rótulo foi gerado por um processo enviesado, o modelo aprende o viés com eficiência exemplar. A auditoria de rótulo responde três perguntas antes de qualquer treino.

Quem produziu o rótulo? Rótulo automático (o cliente cancelou ou não cancelou) tem procedência diferente de rótulo humano (o analista marcou como fraude). O segundo carrega a subjetividade e a carga de trabalho de quem marcou. Se três analistas rotularam a base e um deles marcou 40% mais casos positivos que os outros dois, existe uma variável oculta chamada “quem analisou” que o modelo vai capturar.

O rótulo é observável para todos os registros? Aqui mora o viés de seleção mais caro de projetos de crédito e de triagem. Só se sabe se um cliente pagaria se ele recebeu o crédito. A base de treino contém apenas quem passou pelo filtro anterior — e o modelo treinado nela extrapola para uma população que nunca observou. Não há solução puramente estatística; a mitigação envolve reservar uma fatia de decisões aleatórias para gerar rótulo em toda a distribuição, com o custo que isso implica.

Qual a taxa de concordância entre rotuladores? Onde houver julgamento humano, rotule uma amostra em duplicata. Concordância abaixo de 80% em tarefa binária significa que o teto de acurácia do modelo já está definido pela inconsistência do rótulo, e nenhuma arquitetura vai passar disso.

Etapa 3 — Vazamento temporal: o dado existia no momento da decisão?

Esta é a etapa que mais frequentemente explica o modelo que acerta 94% em validação e desaba em produção. A verificação é conceitualmente trivial e operacionalmente trabalhosa: para cada variável, determine o carimbo de tempo em que aquele valor ficou disponível e compare com o carimbo do momento da inferência.

Os vazamentos mais comuns não são grosseiros. Ninguém coloca a variável alvo entre as features por descuido. O que acontece é mais sutil:

• Campo atualizado no lugar de versionado. A tabela de cadastro guarda o status atual do cliente, não o status na data do pedido. Se o campo “situação cadastral” foi sobrescrito depois do evento, ele já contém o desfecho.
• Agregado com janela mal fechada. “Média de compras nos últimos 90 dias” calculada com corte na data de extração, e não na data de cada evento, contamina todos os registros antigos com informação futura.
• Dado de terceiro com atraso de entrega. Um score externo pode existir na base com data de referência de segunda-feira, mas só chegar ao sistema na quinta. Em produção ele não estará lá no momento da decisão.

O teste prático que revela quase todos: treine o modelo, ordene as features por importância e examine as três primeiras. Se alguma delas explica muito mais do que o especialista de negócio esperava, o cenário mais provável não é que o modelo descobriu algo — é vazamento.

Etapa 4 — Aderência à distribuição de produção

A base histórica descreve o passado do processo. O modelo vai operar sobre o presente. Quanto essas duas distribuições diferem determina quanto da performance medida em validação vai sobreviver.

A verificação mínima compara, variável a variável, a distribuição da base de treino com a de uma janela recente de produção — os últimos 30 a 60 dias, tipicamente. Para variáveis numéricas, compare os quartis; para categóricas, compare a frequência relativa das dez categorias mais comuns. Diferenças grandes em variáveis de alta importância exigem decisão explícita: reponderar a base, encurtar o período de treino ou aceitar que o modelo precisará de retreino frequente.

Vale medir também a estabilidade do próprio processo. Se a política comercial mudou em março, dados de janeiro descrevem outro fenômeno. Uma base de três anos que atravessa duas mudanças de política costuma render menos que uma base de dez meses sob regra estável — e essa é uma troca que o time de dados precisa fazer conscientemente, não por acidente.

Etapa 5 — Custo assimétrico do erro e a métrica que decorre dele

A última etapa não olha o dado, olha a decisão. Antes de escolher a métrica de avaliação, é preciso estimar o custo de um falso positivo e o de um falso negativo em unidade comparável — reais, horas de analista, chamados abertos. Sem isso, a discussão sobre limiar de corte vira preferência estética.

Quando os custos são assimétricos — e quase sempre são —, acurácia deixa de significar qualquer coisa. Num problema com 2% de eventos positivos, um modelo que responde “não” para tudo entrega 98% de acurácia e valor zero. A métrica útil nesse cenário é precisão em uma taxa de recall fixada pela capacidade operacional: se a equipe consegue analisar 200 casos por dia, o que importa é a precisão nos 200 casos de maior score, não a área sob a curva.

A recomendação, quando há discordância no time: fixe a métrica pela restrição operacional antes de treinar. Escolher a métrica depois de ver os resultados é o caminho mais curto para justificar um modelo que não resolve o problema.

Como pontuar as cinco etapas e decidir

Cada etapa produz um veredito. A tabela abaixo resume o critério de corte que costuma funcionar como ponto de partida — os limiares devem ser calibrados por contexto, mas servem para tirar a decisão do campo da opinião.

A etapa 3 é a única que funciona como bloqueio absoluto. As outras quatro admitem projeto com ressalva documentada. Vazamento temporal, não: um modelo com vazamento produz um número de performance que não descreve nada e cria expectativa que a operação vai cobrar depois.

Atualmente, com o custo de treinar modelos caindo e a barreira técnica diminuindo, o gargalo dos projetos migrou de forma bem clara da modelagem para a base. Rodar essas cinco verificações consome tipicamente de uma a três semanas de trabalho de um analista com acesso ao dado e a um especialista de negócio. É o investimento com melhor retorno em um projeto de IA aplicada, porque é o único que impede que os meses seguintes sejam gastos otimizando uma métrica que não descreve o problema real.

Perguntas frequentes

Qual o volume mínimo de dados para treinar um modelo? Não existe número universal, e a pergunta melhor formulada é sobre a classe minoritária. Para classificação binária tabular, o gargalo costuma ser a quantidade de exemplos positivos, não o total de linhas. Poucas centenas de casos positivos já permitem um modelo simples com validação honesta; alguns milhares abrem espaço para modelos mais expressivos. Abaixo disso, uma regra de negócio bem calibrada tende a competir de igual para igual — e é mais fácil de auditar.

Dá para pular a auditoria e testar direto em produção com uma fatia pequena? Testar em produção é útil, mas não substitui as etapas 2 e 3. Um teste A/B com rótulo enviesado ou com vazamento vai medir a coisa errada com mais precisão. A auditoria e o teste controlado são complementares: a primeira garante que a métrica significa algo, o segundo mede o efeito real.

Como convencer a diretoria de que a base não está pronta? Com o número da etapa 1. A frase “os dados precisam melhorar” não move orçamento; “temos 41 mil pedidos na base, mas 6,8 mil com todas as variáveis preenchidas na data da decisão, e destes 380 são casos positivos” muda a conversa, porque transforma um julgamento técnico em uma restrição contável.

Modelos de linguagem grandes dispensam esse tipo de auditoria? Dispensam a etapa de rotulagem em massa quando usados sem ajuste fino, mas herdam versões próprias das outras quatro. Cobertura vira qualidade e completude dos documentos recuperados; vazamento vira contaminação do conjunto de avaliação; aderência de distribuição vira diferença entre as perguntas testadas e as perguntas reais dos usuários; e o custo assimétrico do erro continua sendo a decisão que define qual limiar de confiança justifica responder em vez de encaminhar para um humano.

A pergunta que sustenta quase todo projeto de assistente de IA em atendimento é simples de enunciar e difícil de responder: quanto custava atender um cliente antes e quanto custa agora. O indicador que a maioria das empresas leva para a reunião de resultado é a taxa de contenção — o percentual de conversas que o assistente encerrou sem transbordar para um humano. Uma contenção de 60% soa como economia de 60%. Quase nunca é.

A contenção mede desvio de volume, não custo. Ela ignora o que acontece depois: o cliente que volta duas horas mais tarde pelo mesmo motivo, a conversa que chegou ao humano já degradada e demorou mais para resolver, o custo de inferência que subiu quando o time trocou o modelo por um mais capaz. Um assistente pode conter 60% das conversas e deixar o custo por resolução exatamente onde estava. Este texto descreve como montar a medição que separa um caso do outro.

Por que a taxa de contenção engana com tanta frequência

Contenção costuma ser definida como conversas encerradas no assistente sobre conversas totais. O problema mora nos dois lados da fração.

No numerador, “encerrada” quase sempre significa “o cliente parou de responder”. Abandono e resolução produzem exatamente o mesmo evento no log. Quem desiste e vai para o telefone, para o e-mail ou para a loja física entra na conta como sucesso. Em operações que já mediram isso com rastreamento de reincidência, a fatia de conversas contidas que reaparece em outro canal em até 72 horas costuma ficar na casa de dois dígitos — o número varia muito por setor e por qualidade do roteamento, mas raramente é desprezível o bastante para ser ignorado.

No denominador, o assistente muda o próprio volume que está medindo. Quando o atendimento fica instantâneo e disponível de madrugada, o cliente pergunta mais. Contatos que antes não aconteciam passam a acontecer. Isso é bom para experiência e péssimo para comparação: a base de conversas do mês 6 não é a mesma base do mês 1, e dividir custo pelo total de conversas produz uma queda artificial que não corresponde a nenhum real a menos na despesa.

A correção é trocar a unidade de análise. Não conte conversas. Conte problemas resolvidos.

Defina a unidade de custo antes de comparar qualquer coisa

Uma resolução é um problema do cliente que foi encerrado e não voltou dentro de uma janela definida. Os três parâmetros dessa definição precisam ser fixados por escrito antes da primeira medição, porque mexer neles depois permite provar qualquer coisa:

1. A janela de reincidência. Sete dias funciona bem para a maioria dos casos de suporte transacional. Para cobrança, faturamento e qualquer assunto com ciclo mensal, use trinta dias — reincidência de fatura não aparece em sete.
2. A chave de agrupamento. Duas conversas do mesmo cliente sobre o mesmo assunto dentro da janela são uma resolução, não duas. Sem essa regra, o assistente que devolve o cliente três vezes aparece nos números como três atendimentos bem-sucedidos.
3. O escopo de canal. Se o cliente que desiste do chat liga no dia seguinte, essa ligação pertence à mesma resolução. Medir só dentro do canal onde o assistente vive é o erro mais caro da lista, porque esconde exatamente o custo que o assistente está gerando.

Com a unidade definida, o cálculo fica direto: custo por resolução é a soma de todas as despesas de atendimento do período dividida pelo número de resoluções únicas do período. É esse número, e só ele, que precisa cair.

O custo que não aparece na fatura do modelo

A conta de inferência é a parte visível e normalmente a menor. Quando se soma o custo total, a fatura do provedor de modelo costuma responder por uma fração modesta do gasto do projeto — a maior parte está em trabalho humano que ninguém contabiliza como custo de IA. Os itens que precisam entrar na soma:

O quinto item merece atenção separada. Existe uma suposição confortável de que o assistente entrega ao humano uma conversa pré-qualificada, com contexto pronto, e portanto mais rápida de resolver. Acontece o contrário com frequência suficiente para justificar medição: o cliente chega ao humano já irritado, repetindo informação que julgava ter dado, e o atendente gasta os primeiros minutos desfazendo o que o assistente entendeu errado. Compare o tempo médio de atendimento das conversas transbordadas com o das conversas que entraram direto na fila humana. Se o transbordo demora mais, parte da economia de volume está sendo devolvida em minutos.

Como isolar o efeito do assistente do resto da operação

Comparar o mês anterior com o mês atual não prova nada. Atendimento tem sazonalidade forte, campanhas de marketing mudam o mix de contatos, uma falha de produto pode inflar o volume por duas semanas, e mudanças de política de reembolso alteram tempo de resolução sem que ninguém do time de IA saiba.

O desenho que resolve isso é o mais simples: mantenha uma fatia do tráfego fora do assistente. Um grupo de controle de 10% a 20% dos contatos, sorteado no momento da entrada e roteado direto para o fluxo humano, dá a linha de base contra a qual o restante é comparado. Rode por pelo menos quatro semanas — abaixo disso o ruído semanal domina o resultado.

Duas armadilhas de execução aparecem sempre. A primeira é sortear por cliente e não por conversa: se o mesmo cliente cai ora no controle, ora no tratamento, a atribuição de reincidência fica ambígua. Sorteie por cliente e mantenha a alocação estável durante todo o período. A segunda é deixar o grupo de controle ser atendido por um subconjunto diferente de atendentes — normalmente os mais experientes, porque a fila é menor. Isso contamina a comparação inteira.

Quando o controle aleatório não é viável — operações pequenas, ou casos em que negar o assistente a um grupo é politicamente impossível — a alternativa aceitável é o corte geográfico ou por linha de produto, com uma janela pré-lançamento longa o suficiente para caracterizar a diferença estrutural entre os grupos antes da intervenção. É pior que o sorteio, e o resultado deve ser apresentado como estimativa com margem, não como número fechado.

Sete campos que sustentam o cálculo inteiro

A medição não exige ferramenta nova. Exige que o log de cada conversa carregue os campos certos desde o primeiro dia, porque reconstruir isso depois é caro e frequentemente impossível. O mínimo viável:

1. ID do cliente — estável entre canais, não o ID da sessão. Sem isso não existe cálculo de reincidência.
2. Grupo experimental — controle ou tratamento, gravado na conversa e não inferido depois.
3. Intenção classificada — o assunto, em um vocabulário fechado. É a chave que agrupa conversas na mesma resolução.
4. Desfecho — resolvido pelo assistente, transbordado, ou abandonado, com abandono registrado como categoria própria e nunca somado a resolvido.
5. Tempo humano consumido — minutos de atendente, separando conversas transbordadas das nativas da fila.
6. Custo de inferência da conversa — tokens ou chamadas, atribuídos à conversa e não rateados no fim do mês.
7. Carimbo de tempo de entrada e de encerramento — necessário para aplicar a janela de reincidência sem ambiguidade.

Com esses sete campos, o custo por resolução de cada grupo sai de uma consulta. Sem eles, qualquer número apresentado é reconstrução aproximada, e vale dizer isso na reunião.

Que resultado esperar, e quando o projeto não se paga

Assistentes bem implantados entregam economia real, mas ela costuma vir de uma faixa estreita de assuntos: consultas repetitivas, de resposta determinística e verificável — status de pedido, segunda via, horário de funcionamento, elegibilidade simples. Nessa faixa, a queda de custo por resolução é consistente e defensável.

Fora dela, a economia some rápido. Assuntos com exceção contratual, negociação, ou qualquer coisa em que a resposta errada gera custo maior que o atendimento economizado — cobrança indevida, cancelamento, informação regulada — tendem a ficar no vermelho quando se soma o retrabalho. A decisão prática, havendo dúvida, é restringir o escopo do assistente aos assuntos de resposta verificável e transbordar cedo no resto, mesmo que a taxa de contenção caia. Um assistente com 35% de contenção e custo por resolução 20% menor vale mais do que um com 70% de contenção e custo estável.

Se depois de oito a doze semanas de medição com grupo de controle o custo por resolução do grupo tratado não estiver abaixo do controle por uma margem maior que a variação semanal observada, o projeto está entregando velocidade e disponibilidade — o que pode ser suficiente para justificá-lo — mas não está entregando economia. São coisas diferentes e merecem ser apresentadas como tal.

Perguntas frequentes

Quanto tempo de medição é suficiente para concluir alguma coisa?

Quatro semanas é o mínimo para ter sinal acima do ruído semanal; oito a doze semanas dá conforto para decidir investimento. Janelas mais curtas capturam efeito de novidade, tanto do cliente quanto do time, e superestimam o resultado.

Dá para medir sem grupo de controle?

Dá, com perda de confiança. A alternativa é comparar antes e depois controlando por mix de intenção e por volume, e apresentar o resultado como faixa. O risco é atribuir ao assistente uma queda que veio de mudança de produto, de política ou de sazonalidade.

O custo de inferência deve ser rateado ou atribuído por conversa?

Atribuído por conversa, sempre que a plataforma permitir. Rateio pelo total mensal esconde a distribuição: em operações típicas, uma minoria de conversas longas consome uma fatia desproporcional do gasto, e é essa cauda que costuma inviabilizar assuntos específicos.

Reincidência em outro canal realmente muda tanto o resultado?

Muda o suficiente para inverter conclusões em operações multicanal. Se o rastreamento entre canais não existe, a recomendação é declarar essa limitação junto com o número, em vez de apresentar o custo por resolução como se ele estivesse completo.

Qual métrica levar para a diretoria em uma linha só?

Custo por resolução do grupo tratado contra o do grupo de controle, no mesmo período, com o número de resoluções de cada lado. Contenção e satisfação entram como contexto, nunca como resposta à pergunta de custo.

Um classificador que acerta 94% das previsões parece pronto para produção. Ele pode ser o pior modelo do seu portfólio. A acurácia média é a métrica mais citada em apresentação de resultado de IA e uma das que menos ajuda a decidir alguma coisa — porque ela comprime, em um único número, um comportamento que quase nunca é uniforme entre os segmentos que importam.

O problema tratado aqui é específico: como saber se um modelo em produção está melhorando de verdade ou apenas parecendo melhor no slide. Vale para classificação de tickets de atendimento, score de propensão de compra, roteamento de chamados, detecção de fraude e para qualquer sistema em que a saída do modelo vira decisão automática sem revisão humana.

Por que a média sobe enquanto o sistema piora

A acurácia é uma média ponderada pelo volume de cada classe. Quando a distribuição da base é desequilibrada — e em problemas de negócio ela quase sempre é —, a classe majoritária domina o resultado. Em uma base com 95% de transações legítimas e 5% de fraude, um modelo que classifica tudo como legítimo entrega 95% de acurácia sem ter aprendido nada.

Esse caso é caricato e todo mundo reconhece. A versão perigosa é mais sutil: o modelo melhora na classe majoritária, piora na minoritária e a média sobe. O dashboard mostra evolução. A operação sente degradação. As duas leituras estão corretas, e só uma delas é sobre o que a empresa contratou o modelo para fazer.

Há um segundo efeito, menos discutido: mudança na composição da base entre um período e outro. Se o mix de canais, regiões ou produtos mudou, a acurácia agregada muda mesmo com o modelo congelado. Comparar 94% de junho com 91% de agosto sem verificar se a base é comparável é comparar duas coisas diferentes e chamar de série histórica.

Mito: “a métrica subiu, então o modelo melhorou”

Essa afirmação só se sustenta sob três condições que raramente são verificadas antes de repeti-la: a base de avaliação é a mesma nos dois períodos, o limiar de decisão não mudou, e a métrica escolhida penaliza o erro que custa dinheiro.

O limiar é o ponto cego mais comum. A maioria dos modelos de classificação devolve uma probabilidade, e alguém em algum momento decidiu que acima de 0,5 é positivo. Esse 0,5 é arbitrário. Mexer nele muda precisão e recall em direções opostas sem alterar uma linha do modelo. Times mudam limiar para resolver reclamação pontual, não registram a mudança, e três meses depois ninguém sabe explicar por que a série histórica tem um degrau.

A evidência que substitui a crença é simples de produzir: fixe a base de avaliação, fixe o limiar, e só então compare. Se algum dos dois precisar mudar, a comparação vira “antes e depois da mudança”, não “evolução do modelo”. Parece burocracia. É o que separa medição de narrativa.

Há uma terceira armadilha, específica de quem reavalia com dados recentes: vazamento temporal. Se a base de teste contém informação que só existiria depois do momento da decisão — um campo preenchido pelo atendente após a análise, um status atualizado retroativamente —, o modelo acerta na avaliação e erra em produção. O sintoma clássico é uma métrica excelente no teste que não se reproduz no primeiro mês real. Antes de comemorar salto grande de desempenho, a pergunta certa é qual variável nova entrou e em que instante ela ficaria disponível na vida real.

O que medir no lugar da média

Nenhuma métrica isolada resolve. O conjunto mínimo defensável para um classificador binário em produção tem quatro elementos, e cada um responde a uma pergunta diferente:

1. Precisão na classe de interesse — de tudo que o modelo apontou como positivo, quanto era mesmo. Responde ao custo do falso positivo: quantas vezes a operação foi acionada à toa.
2. Recall na classe de interesse — de tudo que era positivo, quanto o modelo pegou. Responde ao custo do falso negativo: quanto passou batido.
3. Calibração — quando o modelo diz 0,8, aproximadamente 80% daqueles casos são positivos. Um modelo pode ordenar bem e mentir na probabilidade, e isso quebra qualquer regra de negócio construída sobre faixas de score.
4. Desempenho no pior segmento — a mesma métrica, recalculada dentro de cada corte relevante. É o número que prevê reclamação.

Se for para escolher uma para o comitê que não vai ler o resto, escolha a quarta. A média agregada é a métrica que mais engana justamente porque é a mais fácil de reportar.

Fatiar a avaliação: onde o número muda de sinal

Recalcular a métrica por segmento é a intervenção de maior retorno em avaliação de modelo, e é barata. A tabela abaixo mostra o padrão típico de um score de propensão avaliado de forma agregada e depois fatiado — os valores são ilustrativos, mas a forma da distorção se repete em praticamente todo projeto:

Os cortes que valem a pena são sempre os mesmos quatro tipos: tempo de relacionamento, canal de origem, faixa de valor e recorte geográfico ou de produto. Não é necessário inventar segmentação nova — basta usar as dimensões que já existem no relatório gerencial, porque são elas que a área de negócio usa para cobrar resultado.

Uma regra prática: qualquer segmento com mais de 5% do volume merece métrica própria. Abaixo disso, o intervalo de confiança fica largo demais para sustentar decisão, e o correto é reportar a incerteza em vez de reportar o número.

Drift: o que o dashboard não mostra

Modelo em produção degrada mesmo sem ninguém tocar nele, porque o mundo que gerou os dados de treino muda. Há dois tipos e eles pedem respostas diferentes.

O primeiro é a mudança na distribuição das entradas — o perfil de quem chega mudou. É detectável sem nenhum rótulo, comparando a distribuição das variáveis de entrada da semana contra a janela de treino. É o alerta precoce, e o único que se consegue antes de o estrago aparecer no resultado.

O segundo é a mudança na relação entre entrada e saída — o mesmo perfil passou a se comportar de outro jeito. Esse só é detectável quando o rótulo verdadeiro chega, e o atraso até ele é a variável que define o quanto se está voando às cegas. Em fraude, o rótulo chega em dias. Em churn ou propensão de compra, pode levar meses. Quanto maior esse atraso, mais peso deve ter o monitoramento de entrada, porque é o único sinal disponível no intervalo.

Vale dizer o que é honesto: quase todo alerta de drift em produção é ruído sazonal. Fim de mês, campanha, feriado e mudança de layout no formulário produzem deslocamento de distribuição que não tem nada a ver com o modelo. Alerta de drift sem calendário de negócio ao lado gera fadiga de alarme e, em poucas semanas, ninguém olha mais.

Um protocolo de avaliação que sobrevive à auditoria

O que separa um time que mede de um time que apresenta número é a existência de um procedimento escrito antes do resultado. Seis passos bastam:

1. Congele uma base de referência. Um conjunto rotulado, fora do treino, que não muda entre avaliações. Toda comparação de versão roda contra ele.
2. Defina a métrica primária antes de rodar. Uma só, escolhida pelo custo do erro que dói mais. As outras entram como secundárias.
3. Registre o limiar junto com o resultado. Métrica sem limiar declarado é um número sem unidade.
4. Reporte por segmento, sempre. O agregado entra como contexto, não como conclusão.
5. Traduza para unidade de negócio. Quantos chamados a mais, quantas horas de análise economizadas, qual valor em risco. Um ganho de três pontos em recall que não muda nada operacionalmente é ruído estatístico com apresentação bonita.
6. Guarde a versão do modelo, dos dados e do código de avaliação. Resultado que não pode ser reproduzido em seis meses não é evidência.

Entre investir em um modelo mais sofisticado e investir nesse protocolo, a escolha aqui é o protocolo — e sem hesitação. Ganho de arquitetura tem retorno decrescente rápido; capacidade de saber se o ganho existiu é o que permite tomar qualquer decisão seguinte. Times que pulam essa etapa acabam trocando de modelo por intuição e chamando isso de iteração.

Perguntas frequentes

Acurácia nunca serve para nada?

Serve quando as classes são razoavelmente equilibradas e o custo do falso positivo e do falso negativo é parecido. Isso é raro em problema de negócio, mas acontece — em algumas tarefas de classificação de conteúdo, por exemplo. O erro não é usar acurácia, é usá-la sem verificar se essas duas condições valem.

Qual o tamanho mínimo da base de avaliação?

Depende da taxa da classe rara, não do total. O que importa é ter casos positivos suficientes para que a métrica não oscile com meia dúzia de exemplos. Uma referência de trabalho: algumas centenas de positivos por segmento que se pretende reportar. Com menos que isso, reporte o intervalo, não o ponto.

Com que frequência reavaliar um modelo em produção?

Monitoramento de distribuição de entrada, contínuo ou semanal. Reavaliação completa com rótulo verdadeiro, na cadência em que o rótulo chega — não faz sentido rodar avaliação mensal se o rótulo leva noventa dias para materializar. Ajuste a frequência ao dado, não ao calendário da reunião.

E para modelos de linguagem, vale o mesmo raciocínio?

A lógica vale, as métricas mudam. Não há classe positiva óbvia, então a avaliação passa por conjuntos de casos representativos com critério de aceitação declarado por tipo de tarefa. O princípio permanece: nota média agregada esconde a categoria de pergunta em que o sistema falha, e é essa categoria que vira reclamação.

A pergunta chega toda semana em alguma reunião de marketing: “Em que posição estamos nas respostas do ChatGPT?” A pergunta parece razoável, e é justamente por isso que merece desconfiança. Ela pressupõe que existe, para respostas geradas por IA, algo equivalente à posição no Google, um número estável, comparável entre datas e atribuível a uma ação sua. Hoje, essa premissa não se sustenta.

Este texto separa o que se consegue medir com método do que costuma ser vendido como métrica sem ter lastro, e propõe uma forma de acompanhar visibilidade em IA sem prometer mais precisão do que os dados oferecem.

O mito: existe um “ranking” em respostas de IA

Na busca tradicional, uma consulta devolve uma lista ordenada, e a posição de uma página é um fato observável naquele momento, com variação por localização e personalização. Em assistentes de IA, a resposta é gerada, não recuperada de uma lista fixa. A mesma pergunta, feita duas vezes, pode produzir textos diferentes, citar marcas diferentes ou não citar ninguém. Há variação por modelo, por versão, por configuração de busca na web e pelo histórico da conversa.

Isso significa que “estamos em terceiro lugar” é uma afirmação sem significado estatístico se vem de uma única consulta. O que se pode dizer, com amostra suficiente, é algo diferente: em tantas respostas a este conjunto de perguntas, nossa marca apareceu em tal proporção.

Evidência: por que uma resposta isolada engana

Imagine um teste hipotético, apenas para ilustrar a lógica. Você faz uma pergunta importante do seu mercado dez vezes, em dias diferentes. Sua marca aparece em três respostas. Qual é a visibilidade? Três em dez, ou 30%? Com uma amostra tão pequena, o intervalo de incerteza é grande: o valor real poderia estar bem abaixo ou bem acima disso. Se você repetir o teste cinquenta vezes e obtiver 14 menções, a estimativa fica em torno de 28%, mas com margem menor.

O ponto metodológico é conhecido de quem trabalha com pesquisa: a precisão depende do tamanho da amostra, e proporções calculadas sobre poucas observações oscilam muito. Qualquer ferramenta que entrega um índice de visibilidade deveria informar quantas consultas rodou, em quais modelos, em que período e com que variação entre repetições. Se não informa, trate o número como indicativo, não como medida.

Método: como montar uma medição defensável

1. Defina o conjunto de perguntas. Reúna de vinte a cinquenta perguntas reais do seu público, agrupadas por etapa: descoberta, comparação e decisão. Use as dúvidas que aparecem em atendimento, vendas e Search Console. O conjunto fica fixo por trimestre.
2. Escolha os assistentes que importam para o seu público. Não é preciso cobrir todos. Cubra aqueles em que seus clientes de fato pesquisam, e documente a versão e o modo de uso, com ou sem busca na web.
3. Repita cada pergunta várias vezes. Rode no mínimo cinco repetições por pergunta e por assistente, em momentos diferentes, para medir variação.
4. Registre o que importa de cada resposta. Marca citada ou não, contexto da menção (recomendação, comparação, alerta), fontes citadas e concorrentes mencionados.
5. Calcule taxas, não posições. Taxa de menção por assistente, por etapa e por concorrente, com a amplitude entre repetições.

Com esse registro, a pergunta “estamos aparecendo?” ganha resposta com data, amostra e margem. E você passa a ter base para ver se uma ação, como publicar um estudo ou atualizar uma página de comparação, coincide com mudança no padrão.

Comparação: o que cada fonte de dado entrega

Nenhuma delas basta sozinha. A combinação dá uma imagem mais confiável: o teste fixo mostra se você é citado, o analytics mostra se isso gera visita, e o campo “como nos conheceu” mostra se chega ao negócio.

Interpretação: o que fazer com o número

Quando a taxa de menção é baixa, o primeiro diagnóstico é de conteúdo, não de técnica: sua marca tem material claro e citável sobre as perguntas do conjunto? Páginas que respondem a pergunta de forma direta, com definição, critérios e dados com origem declarada, têm mais chance de servir como fonte do que páginas genéricas.

Quando você aparece, mas em contexto errado, por exemplo associada a uma categoria que não é a sua, o ajuste é de posicionamento: revise como o seu site, perfis públicos e menções de terceiros descrevem o que você faz. Modelos tendem a refletir o que está consistente na web.

Quando concorrentes dominam, olhe quais fontes eles têm que você não tem. Em muitos casos, a diferença está em ser citado por terceiros confiáveis do setor, não no próprio site.

Armadilhas que distorcem a medição

A primeira é escolher perguntas que já citam o nome da marca. Se você pergunta “o que é a empresa X?”, a menção é quase garantida e o teste não diz nada sobre descoberta. Use perguntas sobre o problema do cliente, sem nomear ninguém.

A segunda é misturar condições. Rodar parte das consultas com busca na web ativada e parte sem, ou alternar contas com histórico diferente, cria diferenças que parecem mudança de visibilidade e são só mudança de método. Documente as condições e mantenha-as.

A terceira é o viés de quem mede. Quem torce pelo resultado tende a repetir a pergunta até a marca aparecer. Defina o número de repetições antes e registre todas, inclusive as que não mencionam você.

A quarta é confundir menção com recomendação. Aparecer numa lista de “opções a evitar” conta como menção, mas não como visibilidade desejável. Por isso o registro do contexto da citação é parte do método, não um detalhe opcional.

Como montar a planilha de acompanhamento

Uma estrutura enxuta basta para começar. Cada linha é uma resposta observada, com as colunas: data, assistente e versão, pergunta, número da repetição, marca citada (sim ou não), contexto (recomendação, comparação, alerta ou neutro), concorrentes citados e fontes citadas. A partir daí, tabelas dinâmicas entregam taxa de menção por pergunta, por etapa e por assistente.

Acrescente uma coluna de observação livre para anotar mudanças no ambiente, como atualização de modelo, campanha em andamento ou publicação de conteúdo novo. Quando a taxa oscilar, você vai querer saber o que mudou naquela janela. Sem esse diário, qualquer explicação posterior vira palpite.

O que reportar à diretoria

Resista a transformar tudo em um índice único. Apresente três linhas: taxa de menção no conjunto fixo, com intervalo e tamanho da amostra; tráfego e conversões atribuíveis a assistentes no analytics; e menções declaradas por clientes. Mostre a tendência ao longo de trimestres, não a foto da semana. E diga explicitamente o que não é medido.

Esse cuidado protege você de uma situação comum: o gestor leva o “ranking” para uma reunião, o número muda na semana seguinte sem que nada tenha sido feito, e a credibilidade de toda a medição cai junto.

Como saber se uma mudança foi causada por sua ação

Esta é a pergunta que a diretoria sempre faz depois de ver o primeiro gráfico: “o que causou a subida?”. A resposta honesta exige cautela. Como as respostas de IA variam por natureza, uma alta de poucos pontos percentuais entre duas medições pode ser só ruído amostral.

Um critério prático é comparar a mudança com a oscilação normal observada nas repetições. Se a taxa de menção varia entre 20% e 30% de uma rodada a outra sem que nada tenha sido feito, uma alta de 28% para 32% não conta como evidência. Uma sequência de três ou mais rodadas acima da faixa anterior, depois de uma ação específica e datada, já merece atenção.

Quando possível, use um grupo de comparação interno: perguntas sobre temas em que você publicou conteúdo novo contra perguntas sobre temas em que não publicou nada. Se apenas o primeiro grupo sobe, a hipótese de causa ganha força. Se os dois sobem juntos, provavelmente houve mudança no modelo ou no ambiente, e não efeito da sua ação.

Documente cada ação com data e responsável numa linha do tempo compartilhada. Parece burocracia, mas é o que permite, meses depois, relacionar a publicação de um estudo ou a revisão de uma página com a variação da taxa de menção, sem depender da memória de ninguém.

Perguntas frequentes

Existe uma métrica padrão para visibilidade em IA?

Não há padrão consolidado. A taxa de menção sobre um conjunto fixo de perguntas é a base mais defensável, mas cada ferramenta define o seu índice de forma diferente.

Quantas repetições são suficientes?

Depende da variação que você observar. Cinco repetições por pergunta é um ponto de partida para enxergar oscilação; aumente se os resultados variarem muito.

Vale a pena investir em ferramenta paga agora?

Se o volume de perguntas justifica automação e o fornecedor explica a metodologia, pode valer. Sem essa transparência, o teste manual bem desenhado costuma ser mais confiável.

Isso substitui o acompanhamento de SEO?

Não. Os dois se complementam: boa parte das respostas com busca na web usa páginas que já se destacam em buscadores, então a base de SEO continua relevante.