Como medir qualidade, latência e custo

As três perguntas que ficaram em aberto

Nos últimos artigos eu tomei decisão de arquitetura em cima de número: a conta de quando cachear compensa, no artigo sobre RAG e CAG; a constatação de que teste automatizado não substitui observação em produção, no artigo sobre observabilidade de agente. As duas dependem de medir direito qualidade, latência e custo, e eu passei ao largo de como medir cada uma sem inflar confiança que os dados não sustentam. Esse é o assunto deste artigo.

Qualidade: quanto eval você realmente precisa

Rodar um eval de 50 ou 100 exemplos e reportar “85% de acerto” parece rigoroso. Estatisticamente não é. Para estimar uma proporção com margem de erro conhecida, a fórmula padrão é:

Com z = 1,96 (95% de confiança) e uma métrica esperada em torno de 80%, já são necessários 246 exemplos só pra garantir margem de erro de 5 pontos. Com 100 exemplos e 80% de acerto, o erro padrão fica perto de 0,04, o que dá um intervalo de confiança de 95% de aproximadamente ±8 pontos: a taxa de acerto real pode estar em qualquer lugar entre 72% e 88%.

Isso piora quando o objetivo é comparar dois modelos, não medir um sozinho. Pra detectar que um modelo é 2 pontos percentuais melhor que outro (78% contra 80%) com 95% de confiança e 80% de poder estatístico, o cálculo de comparação de duas proporções pede algo perto de 6.300 exemplos por lado.

Na prática, isso significa que a maioria dos evals que times rodam pra decidir “trocar de modelo A pra B” só tem poder estatístico pra enxergar diferença grande. Ganho pequeno e real passa despercebido, e ganho pequeno e ilusório (ruído de amostra) passa como se fosse real. O artigo anterior sobre observabilidade já mostrou o outro lado desse problema: mesmo um juiz automático rodando em 100% do tráfego tem ponto cego estrutural pra erro que só aparece entre turnos. Aqui o ponto é anterior a isso: mesmo a métrica agregada, sozinha, carrega incerteza que raramente aparece reportada.

Latência: por que a cauda de um agente é pior do que qualquer chamada isolada

Duas métricas definem a experiência de latência em geração via streaming: TTFT (tempo até o primeiro token, que inclui rede, fila e o processamento do prompt inteiro) e ITL (intervalo entre tokens durante a geração, limitado pela largura de banda de memória pra ler o KV-cache a cada token). Latência total importa pouco quando a resposta é consumida em streaming; o que o usuário sente é o atraso antes de começar (TTFT) e a fluidez durante (ITL).

As duas só fazem sentido como percentil, nunca como média. Benchmarks de 2026 medindo TTFT em produção mostram razão p95/p50 média de 2,1 vezes, chegando a 3,2 vezes nos piores casos: metade dos usuários tem uma experiência, e o p95 já é o dobro ou o triplo disso.

Isso fica pior num agente, porque um turno raramente é uma chamada só. Se cada chamada individual tem 5% de chance de ultrapassar o próprio p95 (por definição), e um turno de agente faz N chamadas independentes em sequência, a chance de pelo menos uma delas estourar o próprio p95 é:

Com α = 0,05: 3 chamadas em cadeia já dão 14,3% de chance de pelo menos uma delas ser lenta; 5 chamadas sobem pra 22,6%; 10 chamadas passam de 40%. O p95 de um turno inteiro de agente não é o p95 de uma chamada, é sistematicamente pior, porque basta uma etapa lenta entre várias pra travar o turno todo. Isso pressupõe independência entre chamadas, o que nem sempre é verdade (uma chamada lenta pode indicar sobrecarga que afeta a próxima também), mas mesmo essa aproximação otimista já mostra que medir só a latência de uma chamada isolada subestima a cauda real de um agente.

Custo: preço por token não é preço por tarefa

A forma mais comum de acompanhar custo é somar tokens de entrada e saída e multiplicar pelo preço por milhão. Isso mede gasto, não mede eficiência. Um modelo mais barato por token que precisa de mais uma rodada de tool call, ou de um retry porque errou o formato de saída, pode custar mais no fim do que um modelo mais caro que resolve de primeira. A própria documentação de otimização de custo da Anthropic recomenda medir custo por tarefa concluída, não por requisição, exatamente por isso.

Duas armadilhas práticas de medição valem menção. Primeiro, contar token com uma biblioteca genérica (tiktoken, por exemplo) em vez do endpoint oficial de contagem do provedor gera número errado, porque tokenizadores diferem entre modelos, e eu já mostrei em outro artigo o quanto a escolha de tokenizador muda a contagem final. Segundo, gasto com cache. A conta de cache que derivei no artigo sobre RAG e CAG (escrita custa 1,25 vez o preço normal, leitura custa 0,1 vez) significa que dois times rodando o mesmo volume de chamadas podem ter custo por token efetivo bem diferente dependendo só da taxa de acerto de cache, sem mudar de modelo nem de prompt.

Existe ainda uma alavanca de custo simples e fácil de esquecer: a Batch API roda a mesma chamada de forma assíncrona por metade do preço, e serve qualquer fluxo que não precise de resposta em tempo real, como reprocessar um lote de documentos ou rodar um eval inteiro durante a madrugada.

A fronteira eficiente: nem todo modelo mais caro compra alguma coisa

Juntando qualidade, latência e custo num gráfico, a pergunta de decisão certa não é “qual modelo é melhor”, é “qual modelo não é dominado”: existe um outro modelo estritamente melhor ou igual nos três eixos ao mesmo tempo, por um preço igual ou menor. Um levantamento de 20 modelos de fronteira rodando no OpenRouter no segundo trimestre de 2026 encontrou só 6 na fronteira eficiente de custo, qualidade e velocidade juntos: os outros 14 são dominados em todo eixo por algum modelo mais barato ou mais rápido, e mesmo assim boa parte deles continua recebendo tráfego real de produção.

O motivo mais comum pra isso não é falta de dado, é inércia: o modelo foi escolhido uma vez, passou no teste manual de alguém, e ninguém voltou a checar se ele ainda compensa contra o que existe hoje. A pergunta que vale fazer periodicamente não é “preciso trocar de modelo”, é mais estreita: “o que eu uso hoje está na fronteira, ou existe algo estritamente melhor no meu caso pelo mesmo preço ou menos”.

Como eu meço isso na prática

No Article Copilot eu desenhei o painel de custo antes de escrever o primeiro agente de verdade: o marco M8 do plano do projeto prevê consulta agregada de custo, tokens e latência por sessão, por agente e por modelo, um guard de orçamento que bloqueia acima de um teto configurável por sessão, por dia ou global, um painel específico de taxa de cache lido contra escrito, e uma trilha de auditoria que desce de sessão pra execução de agente pra chamada de LLM individual. Ainda não construí esse marco, ele depende de duas fases anteriores que também não terminei, mas desenhar a métrica antes do agente evita a armadilha mais comum: só perguntar quanto custou depois que a fatura já assustou alguém.

A prática mais simples que já aplico hoje é mais modesta que isso: qualquer chamada de agente registrada numa tabela de auditoria carrega tokens de entrada, tokens de saída e latência da chamada junto com o resultado. Não é um painel, é uma coluna a mais numa tabela que eu já ia criar de qualquer forma pela razão descrita no artigo sobre observabilidade. Quase toda a medição séria começa assim: gravar o número desde o primeiro dia custa quase nada; reconstruir ele depois de um incidente ou de uma fatura alta custa muito mais.

O que eu tiro disso

As três métricas deste artigo têm o mesmo problema em comum: parecem simples de ler (uma porcentagem, um número de milissegundos, um valor em dólar) e escondem uma quantidade grande de estatística e de contexto atrás de cada uma. Um eval pequeno demais não prova diferença que ele afirma provar. Uma latência média esconde a cauda que realmente incomoda o usuário, e essa cauda piora conforme o agente encadeia mais chamadas. Um custo por token não diz se a tarefa foi concluída com eficiência ou só ficou barata por chamada e cara no total.

O fio que conecta os quatro artigos que escrevi até aqui é o mesmo: perguntar “qual é o número real por trás dessa afirmação” antes de aceitar a conclusão de qualquer um deles, incluindo as minhas.