1) Por que benchmarks confundem

“Benchmark” virou um guarda-chuva para coisas bem diferentes. Em IA, dá para cair em pelo menos três confusões comuns:

• Performance vs. qualidade: um modelo pode ser “mais rápido” (ou mais barato) sem ser “melhor” nas tarefas que você precisa.
• Comparação injusta: mudar dados, prompt, regras de corte, hardware, ou até a definição de “qualidade mínima” muda o resultado.
• Rankings viram marketing: listas agregadas simplificam demais e escondem trade-offs (latência, custo, segurança, alucinação, etc.).

A solução não é ignorar benchmarks — é ler o que está sendo medido e replicar o básico no seu contexto.

2) MLPerf: quando a discussão é performance (e custo)

Se a sua dúvida é “quanto custa rodar isso em produção?” ou “qual infra aguenta?”, você está no território de benchmarks de performance de sistema. O exemplo mais conhecido é o MLPerf, mantido pela MLCommons.

O que o MLPerf Inference mede

No MLPerf Inference, há cenários e tarefas definidos (por exemplo, classificação de imagens, recomendação, speech-to-text e tarefas de linguagem) com metas de qualidade mínimas e limites de latência. A comparação fica mais “apples-to-apples” porque o benchmark define regras e métricas — e o foco vira throughput/latência por sistema, não “opinião” sobre respostas.

• Exemplos de tarefas listadas: ResNet, DLRM, Whisper e tarefas de LLM com requisitos de qualidade e tempos-alvo (TTFT/TPOT) em cenários definidos.
• Boa leitura para quem decide entre GPU vs. CPU, on-prem vs. nuvem, quantização, etc.

O que o MLPerf Training mede

Já o MLPerf Training olha para tempo para treinar modelos até uma meta de qualidade. A própria MLCommons destaca que há variância e descreve como os resultados são obtidos (múltiplas medições, descarte de extremos, média) e como as categorias (Closed/Open, Available/Preview/RDI) afetam comparabilidade.

Como usar isso no Brasil: mesmo que você não rode exatamente o benchmark, a utilidade prática é ter uma referência transparente para estimar: quanto de infra eu preciso para X? e qual o gargalo provável (memória, banda, software stack)?

3) Qualidade de LLM: Arena, HELM e harness (o que cada um mede)

Quando falamos de LLMs, “qualidade” é mais escorregadia. Por isso existem abordagens diferentes, com vantagens e limitações.

3.1 Chatbot Arena (LMSYS): “Elo” com votos humanos

O Chatbot Arena popularizou uma forma de comparar modelos em duelos anônimos e votos de usuários, gerando um ranking no estilo Elo. A sacada é capturar preferências humanas em perguntas abertas — algo que benchmarks acadêmicos nem sempre conseguem medir bem.

• Ponto forte: aproxima de uso real (prompts livres).
• Limitação: composição de usuários/pedidos pode enviesar resultados (língua, tipo de pergunta, momento do tempo).

3.2 HELM (Stanford CRFM): avaliação “holística”

O HELM (Holistic Evaluation of Language Models) é um esforço para avaliação mais ampla (não só um número), com múltiplas dimensões e tarefas. É útil como “mapa” do que considerar — especialmente quando seu time está montando uma matriz de decisão.

3.3 LM Evaluation Harness (EleutherAI): padronização e reprodutibilidade

O lm-evaluation-harness é um framework amplamente usado para rodar muitos benchmarks e manter comparabilidade. O próprio projeto ressalta mudanças recentes (CLI com subcomandos, config YAML, instalação mais leve) e o papel como base de leaderboards.

Regra de ouro: se alguém te der um “score final”, peça:

• Quais tarefas entraram?
• Qual versão do dataset?
• Qual prompt/template?
• Como trataram cadeia de raciocínio e pós-processamento?
• Qual intervalo de confiança / variância (quando aplicável)?

4) Evals no seu produto: como transformar “achismo” em teste

Mesmo com benchmarks públicos, a parte que mais move o ponteiro em produto é criar avaliações internas para o seu domínio (seu vocabulário, seus documentos, suas regras). Aqui entram frameworks como o OpenAI Evals (repositório open-source) e guias sobre como estruturar “critérios de teste” e datasets.

Um caminho prático (sem burocracia)

1. Defina o comportamento: “classificar tickets”, “extrair campos de NF”, “resumir contrato”, “gerar e-mail de cobrança”, etc.
2. Monte um conjunto pequeno e representativo: 50–200 casos reais (anonimizados) já dão sinal.
3. Escolha critérios claros: checagens de string, rubricas, ou avaliação por graders.
4. Compare versões: prompt A vs prompt B, modelo X vs Y, com o mesmo conjunto.
5. Trate regressão como bug: se piorou, não “vai no feeling”.

O repositório openai/evals descreve o objetivo do framework e como ele ajuda a entender impactos de versões de modelos e prompts. Já a documentação de “Working with evals” detalha uma estrutura típica: dados de teste + critérios (graders) + iteração.

5) Governança e regulação: por que o assunto entrou no backlog

Dois movimentos estão acontecendo em paralelo:

• Regulação: o EU AI Act virou referência global e popularizou a linguagem de “categorias de risco” e obrigações por tipo de sistema.
• Gestão de risco: frameworks como o NIST AI RMF ajudam a “operacionalizar” confiança: mapear riscos, medir, mitigar, monitorar.

O EU AI Act como “GPS” de compliance

Mesmo para quem não atua na Europa, o AI Act tende a influenciar padrões (como aconteceu com o GDPR). A página do EU Artificial Intelligence Act (site de referência com recursos e análises) resume a ideia central: categorias de risco e exigências para usos de alto risco, além de proibições para certos casos.

NIST AI RMF: um framework para times de produto

O NIST AI Risk Management Framework foi criado para uso voluntário e descreve como incorporar considerações de “confiabilidade” ao ciclo de vida de sistemas de IA. A página do NIST também referencia o documento oficial (AI RMF 1.0) e um perfil específico para IA generativa (Generative AI Profile), que ajuda a mapear riscos típicos desse tipo de sistema.

6) O que isso significa na prática

Checklist rápido para decidir entre modelos (e não se arrepender)

• Separar “velocidade” de “qualidade”: use referências tipo MLPerf para performance; use evals internas para qualidade no seu domínio.
• Definir uma métrica de negócio: tempo economizado, redução de retrabalho, taxa de resolução, conversão, etc.
• Criar um “conjunto de regressão”: seus 50–200 exemplos que todo modelo/prompt novo precisa passar.
• Medir custo total: não só tokens. Inclua reprocessamento, validação humana, fallback, armazenamento, observabilidade.
• Garantir governança mínima: logging (com privacidade), monitoramento de qualidade, e um processo para incidentes.

Para PMs e founders

Se o seu fornecedor te vender “somos #1 no ranking X”, a pergunta que corta o ruído é: “me mostre isso rodando nos meus dados, com meus critérios, com custo e latência reais”. Ferramentas e frameworks de evals existem exatamente para isso.

Para times técnicos

O melhor investimento “chato” do trimestre costuma ser: automatizar um pipeline de avaliação (mesmo simples) e registrar resultados. Isso evita que upgrades de modelo quebrem fluxos de cobrança, atendimento ou compliance.

7) Fique de olho amanhã

• Novas rodadas de benchmarks: resultados e mudanças de regra (quando existirem) costumam alterar comparações. Se você usa MLPerf como referência, acompanhe o changelog e versões.
• Leaderboards e metodologias: mudanças no “prompt padrão”, pós-processamento ou critérios de inclusão podem mexer no ranking sem o modelo ter “melhorado”.
• Movimento regulatório: guias e prazos de implementação (especialmente em torno do AI Act) podem impactar requisitos de documentação, transparência e gestão de risco.

Receba o post diário no seu e-mail

Se esse resumo te poupou tempo, assine a newsletter (MailPoet) aqui no blog para receber o post diário de IA. E, se você usa o site como referência, favorite o blog para voltar rápido amanhã.