Benchmarks, não impressões: como o Jarvis escolhe os seus modelos

O roteiro do Jarvis não começa por uma wake word nem por uma interface de chat. Começa por um benchmark. A Fase 0 tinha um único trabalho: escolher o modelo que classifica cada pedido recebido na categoria certa antes de mais nada poder acontecer, e a régua era um número concreto, não uma impressão: pelo menos 90% de JSON válido, pelo menos 85% de precisão de classificação, latência p95 abaixo de 900ms, testado contra 45 casos reais. O próprio roteiro dizia, por escrito, antes de existir uma única linha do assistente em si: se nada passar essa fasquia, isso é um resultado real, e a fasquia não desce.

O primeiro resultado foi um teto de hardware

O próprio README do projeto assumia 16GB de memória unificada como mínimo. A máquina real, um MacBook Air M1, tem 8GB. Ninguém tinha confirmado essa conta antes de a Fase 0 correr o benchmark a sério, e o resultado não foi subtil: a inferência local com Ollama nesse hardware não corria só devagar, ficava instável, com timeouts e reinícios por falta de memória em ambos os modelos candidatos. Já um modelo maior a correr gratuitamente na NVIDIA NIM devolveu 100% de JSON válido, 709ms de latência mediana e 71.1% de precisão. A diferença entre os dois modelos não foi uma descida suave, foi mais um precipício: JSON perfeito de um lado, repetição degenerada do outro.

Fechar um hiato de 26 pontos com casos reais

71.1% ficava bem abaixo da fasquia de 85%. Em vez de baixar a régua ou fingir que o número era melhor, o Jarvis aceitou o resultado como real e foi à procura da causa concreta: frases de ligar/desligar a câmara nunca tinham sido ensinadas como exemplos da categoria certa no próprio prompt do benchmark. A correção, testada e confirmada, não assumida, valeu 93.3%. Meses de uso real depois, esse número subiu para 97.8%, outra vez por encontrar uma falha concreta (perguntar "como está o meu computador" a cair na categoria de visão em vez de conversa) e corrigir exatamente essa, confirmando depois que a correção não tinha estragado mais nada no resto do benchmark. Três números, 71.1%, 93.3%, 97.8%, cada um ganho ao encontrar uma falha real, não a polir o prompt em abstrato.

Quando uma correção passa no seu próprio teste e mesmo assim piora tudo

Um bug apelidado de "colisão dos amendoins" fazia com que um exemplo da lista de compras arrastasse pedidos completamente diferentes para a skill errada. Duas correções de texto foram tentadas. Uma delas resolvia o caso específico, mas ao correr contra o benchmark completo de 45 casos (não só o caso que motivou a correção), a precisão geral caiu de 97.8% para 91.1%, confirmado numa segunda corrida para excluir ruído. Foi revertida a favor de uma correção diferente, declarada diretamente na skill em vez de tentar contornar a colisão só com palavras. "Este caso específico agora funciona" não é a mesma afirmação que "isto não estragou mais nada", e só um benchmark que cobre o conjunto todo consegue distinguir as duas.

Uma fasquia fixa não chega

Duas regressões distintas passaram por uma fasquia fixa sem serem detetadas, porque uma fasquia só sabe o mínimo aceitável, não sabe como estava o sistema ontem. É como um relógio de fitness que só verifica se saíste de casa a correr, sem comparar o ritmo de hoje com o teu ritmo normal das últimas semanas: dá para piorar bastante e mesmo assim continuar "dentro do que é aceitável". A correção foi um gate de regressão permanente: cada corrida nova do benchmark é comparada com uma baseline gravada, e falha se o resultado descer mais do que uma margem pequena face a essa baseline, mesmo que ainda passe a fasquia absoluta. A baseline só é atualizada manualmente, nunca de forma automática numa corrida boa, porque isso deixaria uma regressão que ainda passa a fasquia tornar-se silenciosamente a nova "normalidade" da próxima vez que também calhasse ser a melhor corrida do dia.

A mesma disciplina em todo o lado

O hábito repete-se fora da classificação de pedidos. A memória tem um orçamento de 200ms para 95% dos casos, testado sobre 10 mil eventos sintéticos; o número real medido é 12.43ms, margem larga, mas mesmo assim medida, não assumida rápida só porque "SQLite com uma extensão vetorial devia ser rápido". A ferramenta que cria uma skill nova tem um alvo de 30 minutos desde o zero até um esqueleto a funcionar, descrito no próprio roteiro como "a justificação inteira desta fase": se demorar mais do que isso, é a plataforma que está errada, não o contrário. O número real, cronometrado, com dois bugs reais encontrados e corrigidos pelo caminho: cerca de 111 segundos.

Nenhum destes números é impressionante isolado. O que têm em comum é que cada um existe porque um alvo concreto foi definido antes do trabalho começar, e o número real foi medido, não estimado a olho. É a mesma disciplina que uso no trabalho que faço para clientes: um preço fixo e um prazo por escrito só depois de perceber o que o problema exige de facto, não antes.

Se gostaste, fica por aqui, vem mais a caminho.