Sem fonte primária, sem coluna de release: a semana em que a arquitetura vale mais que o press release

Nesta quarta, 2026-05-06, a coluna é sobre uma decisão editorial e técnica: não vou cobrir um “release dos últimos 7-10 dias” sem fonte primária verificável, número rastreável e benchmark reproduzível.

Isso parece menos glamouroso que comentar o modelo da semana. Também evita a doença mais comum do mercado de IA: transformar nota de lançamento em arquitetura de produção.

O que mudou esta semana

Mudou pouco no que interessa: a régua para adoção está subindo mais rápido que a qualidade média dos anúncios.

O setor aprendeu a empacotar qualquer coisa como “agente”, “raciocínio”, “memória” e “autonomia”. Na prática, boa parte desses lançamentos continua sendo:

1. um modelo maior ou mais barato;
2. uma camada de tool calling;
3. um roteador de prompts;
4. uma interface bonitinha;
5. um gráfico sem erro padrão;
6. uma demo escolhida a dedo.

Isso não é arquitetura. É material de vendas.

A régua correta continua sendo chata, e por isso funciona:

• tarefa definida;
• baseline antigo executado no mesmo ambiente;
• dataset com versão;
• prompt fixado;
• ferramentas permitidas descritas;
• orçamento de tokens medido;
• latência por percentil, não média cosmética;
• falhas classificadas;
• replay possível.

SWE-bench, HELM e MMLU não resolvem tudo, mas pelo menos colocam a conversa em trilho verificável. O paper do SWE-bench, por exemplo, ataca uma pergunta operacional: modelos resolvem issues reais de GitHub ou apenas completam código em vitrine? Esse é o tipo de pergunta que derruba metade dos anúncios de “agente desenvolvedor” antes do almoço.

HELM, por sua vez, tem mérito menos sexy e mais importante: força avaliação holística, com cenários, métricas e transparência. Não basta dizer “melhor em raciocínio”. Melhor onde? Contra quem? Em qual distribuição? Com qual prompt? Com quantas tentativas? Pagando quanto por resposta?

MMLU virou métrica batida, e com razão: foi explorada até perder parte da força como sinal isolado. Ainda assim, é melhor que banner de LinkedIn com “estado da arte” em fonte grande e metodologia em fonte invisível.

Olhando por dentro

Quando um fornecedor anuncia um modelo ou framework de agentes, eu procuro quatro camadas.

A primeira é a camada de modelo. Aqui entram arquitetura, contexto, tokenizer, política de tool use, janela útil real e comportamento sob pressão. Janela de contexto anunciada não é janela de contexto aproveitável. Quem já colocou RAG em produção sabe: depois de certo ponto, o modelo começa a tratar contexto como depósito de entulho. Recuperar 40 documentos ruins não melhora resposta; só aumenta custo e superfície de erro.

A segunda é a camada de orquestração. É onde moram LangGraph, filas, workers, estado, retries, checkpoints e rollback. Agente sem máquina de estados explícita vira novela: cada execução tem um capítulo diferente. Em produção, eu quero saber onde o fluxo parou, qual ferramenta chamou, com quais argumentos, qual foi a resposta, qual política decidiu continuar e como reproduzir o erro.

A terceira é a camada de ferramentas. Tool calling não é mágica; é RPC com modelo estocástico montando payload. O risco está no detalhe: schema permissivo demais, ferramenta com privilégio amplo, ausência de dry-run, prompt injection entrando por documento recuperado, segredo vazando em log, chamada idempotente tratada como se fosse idempotente quando não é.

A quarta é a camada de avaliação. Aqui muita empresa se denuncia. Se o release não mostra avaliação com baseline, ablação e custo, ele não está pronto para decisão técnica. Pode até ser promissor. Promessa não escala cluster, não paga GPU e não responde incidente às 3h17.

O erro recorrente é confundir “modelo acertou minha pergunta” com “sistema suporta meu processo”. Um agente que acerta cinco tickets na demo pode quebrar quando encontra ticket duplicado, branch desatualizada, teste flaky, dependência privada, permissão insuficiente ou issue mal escrita. Ou seja: quando encontra software de verdade.

O que isso significa em produção

Em produção, release recente entra como suspeito até provar o contrário.

Minha matriz de adoção tem cinco perguntas. Se uma delas falha, o sistema não passa para tráfego real.

1. Eu consigo repetir o resultado?
Sem versão fixa, seed quando aplicável, prompt versionado e dataset congelado, o número é decoração. Reprodutibilidade não é capricho acadêmico; é seguro contra fornecedor, entusiasmo interno e memória seletiva.

2. O custo foi medido no caminho inteiro?
Custo de inferência não é só preço por milhão de tokens. Tem embedding, reranking, chamadas de ferramenta, retry, cache miss, observabilidade, armazenamento de trace, tempo de GPU ou API externa, e custo humano de revisar erro. O release que mostra apenas preço nominal está contando meia história porque a história inteira estraga o slide.

3. A falha é contida?
Modelo que erra resposta é problema. Agente que erra ação é incidente. A diferença é brutal. Um chatbot pode inventar uma política interna; um agente com ferramenta pode cancelar pedido, abrir pull request ruim, sobrescrever dado, disparar e-mail ou consultar informação que não deveria.

4. Existe rollback de comportamento?
Rollback de container não resolve prompt alterado em painel, modelo atualizado por fornecedor, rota de ferramenta modificada ou índice RAG reconstruído sem versionamento. Arquitetura de IA precisa tratar prompt, índice, policy e modelo como artefatos implantáveis.

5. A métrica conversa com o negócio real?
MMLU alto não garante atendimento melhor. SWE-bench alto não garante merge seguro no seu monorepo. HELM ajuda a comparar cenários, mas o teste final precisa usar sua distribuição de erro. Sem avaliação local, você compra benchmark e recebe surpresa.

A arquitetura que eu adotaria hoje para qualquer release novo é conservadora:

• tráfego espelhado antes de tráfego real;
• canary por classe de tarefa;
• limite duro de ferramenta por escopo;
• allowlist de ações;
• logs estruturados de prompt, contexto, chamada e resposta;
• revisão humana nos primeiros lotes de ação irreversível;
• benchmark interno versionado;
• comparação contra baseline burro, não contra imaginação.

Baseline burro é subestimado. Um classificador simples, uma busca lexical bem feita ou um fluxo determinístico resolvem mais problema corporativo do que muito agente com nome de filme espacial.

O Brasil nisso

No Brasil, a ausência também fala.

Não há, nesta edição, release brasileiro recente que eu consiga registrar com fonte primária verificável dentro da janela pedida. Então não vou preencher o buraco com torcida por ecossistema local.

O ponto técnico para Maritaca, Tucano, universidades, startups do DF e times corporativos brasileiros é direto: o país não precisa de mais anúncio dizendo que “temos IA nacional”. Precisa de release com peso de engenharia:

• modelo com versão;
• licença clara;
• avaliação em português brasileiro real, não tradução apressada;
• benchmark com tarefas de domínio nacional;
• custo de inferência em hardware disponível por aqui;
• documentação de fine-tuning;
• script de reprodução;
• comparação contra modelos abertos e fechados;
• falhas publicadas.

Português brasileiro não é só trocar “você” por “tu” quando convém. Tem norma fiscal, petição, atendimento bancário, gíria regional, sigla de órgão público, contrato mal digitalizado, áudio ruim, OCR torto e documento com tabela quebrada. Quem mede só pergunta escolar mede pouco.

O mercado brasileiro também tem uma limitação material: GPU cara, dólar mandando no orçamento e equipe pequena operando sistema crítico. Isso favorece arquitetura enxuta. RAG bem feito, modelo menor com roteamento, cache agressivo, avaliação local e tool use restrito. A fantasia do “um modelo gigante para tudo” fica bonita até a primeira fatura ou o primeiro vazamento operacional.

Minha cobrança ao ecossistema local é simples: publiquem menos manifesto e mais artefato. Repositório, peso, card de modelo, benchmark, commit, script, tabela de custo. Quem quer ser levado a sério por engenheiro precisa aceitar auditoria de engenheiro.

Minha leitura

Eu não adotaria nenhum release recente de IA apenas com base em anúncio, demo ou benchmark sem trilha de reprodução. Ponto.

Adotaria um modelo ou framework novo somente em três condições:

1. fonte primária pública com versão identificável;
2. avaliação local contra baseline existente;
3. contenção operacional antes de qualquer ação irreversível.

Se o fornecedor não entrega isso, ele não está vendendo arquitetura; está vendendo esperança com API key.

A posição desta coluna é deliberadamente dura porque produção pune otimismo preguiçoso. Modelo bom é bem-vindo. Agente útil também. Mas sistema sem reprodutibilidade, sem observabilidade e sem limite de ação vira passivo técnico com log bonito.

Nesta semana, a melhor decisão técnica é não fingir certeza. Sem fonte primária, não há release. Sem benchmark reproduzível, não há evidência. Sem contenção, não há produção.

Ares Tekhton é Editor de Tecnologia do Mirante News, Diretor de Tecnologia da INTEIA e assina a coluna semanal Arquitetura Tech. Trabalha com sistemas distribuídos, agentes, RAG em produção e segurança de LLMs — com cicatrizes suficientes para desconfiar de demo perfeita.