Modelo é commodity, engenharia é diferencial


EDIÇÃO #202 | NEWSLETTER SEMANAL DA ANÁLISE MACRO

O modelo virou commodity. A engenharia é o diferencial.

Fala, Reader, tudo bem por aí?

Domingo à noite, e eu quero começar essa edição com o paradoxo da semana. O Qwen3.8-Max, da Alibaba, estreou no top 4 do ranking de código da Arena — acima do Claude Fable 5 — cobrando US$ 2 a 6 por milhão de tokens contra US$ 15 a 75 dos rivais americanos.

A OpenAI, no mesmo período, cortou o preço do GPT-5.6 Luna em 80%.

Então a pergunta se impõe: se o modelo ficou tão bom e tão barato, por que a produtividade agregada continua decepcionando?

Por que a Amazon queimou o fluxo de caixa livre com US$ 169 bi de capex e ainda não mostrou retorno proporcional?

Passei o ano estudando muito o tema da moda: engenharia de IA. E a resposta é chata para quem vende milagre: o gargalo nunca foi o modelo. É tudo o que se constrói em volta dele.

Nessa edição do Boletim AM, vamos entender um pouco mais sobre o tema mais quente do mundo: engenharia de inteligência artificial. Como usar modelos de IA dentro do seu própria ecossistema.

Além disso, tem livros, papers, modelo da semana e o resumo das newsletters que ando lendo.

De bandeja, um podcast feito em casa, com IA.

Boa leitura!

🎯 A tese: o gargalo mudou de lugar

Há dois anos, o diferencial era ter acesso ao melhor modelo.

Hoje, o melhor modelo abre uma aba do navegador e custa centavos.

O que separa quem entrega de quem só demonstra é outra coisa.

A definição que melhor captura isso está no roadmap do Caio Oliveira, e vale citar literalmente:

"Um AI Engineer é um Engenheiro de Software especializado em orquestrar modelos de IA não-determinísticos para construir sistemas confiáveis em produção."

"…transforma modelos probabilísticos em produtos determinísticos e confiáveis."

Repare no verbo: orquestrar. Não treinar. Não inventar arquitetura.

Orquestrar. O trabalho é pegar uma coisa probabilística — que às vezes alucina, às vezes atrasa, às vezes vaza — e transformar num serviço que uma pessoa aperta um botão e confia.

É engenharia. E engenharia tem manual.

🏛️ Os três pilares

O roadmap organiza o ofício em três pilares. Não são etapas — são camadas que rodam juntas.

  • Fluência em Foundation Models — saber o que o modelo faz bem, o que faz mal, quando trocar, quando não trocar. Contexto, tokenização, custos.
  • Arquitetura de Sistemas — RAG, agentes, roteadores, guardrails, caches. O mindset literal, que eu adoro: "Incerteza é uma feature, não um bug."
  • Engenharia de Produção — testes, logs, observabilidade, versionamento. Outro mindset, ainda mais afiado: "Se não está no Git, não existe. Se não tem teste, está quebrado. Se não tem log, não aconteceu."

Para quem vem da área de software, nada de novo. Mas para nós, meros mortais, é o um novo mundo se abrindo.

Na minha própria pós na PUC-Rio, na disciplina de Processamento de Linguagem Natural Avançada, eu registrei uma frase que sintetiza tudo — e que eu volto a ler toda semana:

"A maioria das falhas em produção é de design de sistema e de infraestrutura, não do modelo."

E ecoa uma citação do Netflix Tech Blog reproduzida no material do Caio: "Most ML failures are engineering failures, not model failures." Duas fontes independentes, mesma conclusão.

🔍 Por que avaliação é o coração

Aqui entra a referência mais forte que você vai ter do assunto.

O livro de Chip Huyen — o AI Engineering, da O'Reilly — é hoje a bíblia da área.

O livro tem 10 capítulos. E os capítulos 3 (Evaluation Methodology) e 4 (Evaluate AI Systems) são inteiramente sobre avaliação. São cerca de 95 páginas. Prompt engineering, que é o que quase toda formação online enfatiza, ganha o capítulo 5, com uns 40 páginas. Menos da metade.

Ou seja: o livro-referência do campo dedica mais que o dobro de espaço para "como saber se está funcionando" comparado a "como pedir para funcionar". Isso é uma escolha editorial, e ela grita.

Faz sentido. Sem avaliação, você não sabe se trocar o modelo melhorou ou piorou. Não sabe se o novo prompt está regredindo em 20% dos casos. Não sabe se o guardrail está pegando o que deve pegar. É voo cego.

E é aqui que entra o LLM-as-judge, que eu citei na #200 no contexto do COPOM_RAG_Service — usar um modelo forte para avaliar as respostas de um sistema em produção, contra um golden set fixo. Não é bala de prata. Tem viés. Mas é o único jeito que conheço de escalar avaliação num universo onde a saída é texto aberto.

📐 A matemática que não dá para pular

O segundo livro que quero puxar é o Essential Math for AI, da Hala Nelson (O'Reilly, 2023). 604 páginas, 14 capítulos, e o capítulo 1 se chama, literalmente, "Why Learn the Mathematics of AI?".

O livro cobre otimização, redes neurais, convolução, probabilidade, grafos, cadeias de Markov, pesquisa operacional, lógica matemática, equações diferenciais parciais e ética. Não é livro de código — é livro de fundamentos.

O argumento que eu tiro daí é impopular, mas honesto: quem só chama API tem teto. No degrau 1 e 2 da escada da #200, você consegue viver sem entender o que está por baixo. No degrau 3 e 4 — quando você precisa desenhar retrieval, escolher função de custo para fine-tuning, ou explicar por que a latência estourou —, a matemática vira ferramenta de trabalho.

💸 A conta que o demo não mostra

Uma coisa é rodar o notebook na sua máquina. Outra é botar aquilo para atender requisição de cliente. É aí que a engenharia aparece — porque a conta muda de escala.

Nas notas da DAI eu registrei alguns números que valem colar aqui:

Agente autônomo em workflow de pesquisa: US$ 5 a 50 por execução (múltiplas chamadas em loop).

Phi-3 Mini (3,8B) vs. GPT-4 — custo por 1M tokens: US$ 0,01–0,05 vs. US$ 10–30.

Memória de inferência: 8 GB vs. 800+ GB.

Latência: 10–20 ms/token vs. 50–100 ms/token.

Três ordens de grandeza de diferença em custo. Duas em memória. E, muitas vezes, para a tarefa que você precisa, o modelo pequeno resolve. A pergunta de engenharia deixa de ser "qual o melhor modelo?" e vira "qual o menor modelo que atende o SLA?".

Os quatro problemas reais que aparecem em produção — e que eu vi acontecer com meus próprios olhos:

  • Alucinação — quase sempre por gaps nos dados, não por "burrice" do modelo.
  • Latência — passos sequenciais que ninguém paralelizou.
  • Custo — múltiplas chamadas por request, sem cache.
  • Segurança — prompt injection, tool abuse. Isso agora é vetor de ataque real (a Casa Branca convocou os quatro grandes players essa semana justamente por causa disso).

E as métricas que substituem o velho "acurácia" também mudam de natureza: FLOPS por parâmetro, tokens por Joule, qualidade por dólar, time-to-first-token. É engenharia de sistema, não estatística pura.

🏗️ Do notebook ao serviço

O melhor exemplo dessa transição que eu vi este ano é o case Pré-Sal que trabalhei na DAI. Um pipeline de RAG sobre relatórios técnicos do pré-sal. O notebook funcionava. E, ainda assim, não era produto. Por três razões concretas:

  • A ingestão reprocessava o PDF inteiro a cada execução. Ineficiente e caro.
  • Código monolítico num .ipynb — impossível de testar por partes.
  • Não havia API. Nenhum outro sistema conseguia consumir aquilo.

A versão-produto expôs quatro endpoints em FastAPI: POST /ingest, POST /query, GET /source/{id}, GET /health. Cada um testável. Cada um com log. Cada um versionado.

Detalhe que diz tudo sobre a filosofia da disciplina: 15% da nota da entrega era só por "estrutura limpa, ou seja, não um notebook monolítico". A engenharia não é acessório da avaliação. É a avaliação.

Se você lembra da escada da #200 — conversar → executar → estender → delegar —, é exatamente o pulo do degrau 2 para o degrau 3. Sai do "roda na minha máquina" e vira "serviço que outro sistema chama".

📄 Papers da semana

Ordenei os cinco papers da semana por proximidade à tese desta edição. Todos amarrados a "sistema em volta do modelo", não a "modelo em si".

1. GDPevo: Evaluating Agent Self-Evolution on Real Business Tasks — benchmark que mede a capacidade de agentes de IA em evoluir sozinhos em tarefas reais (finanças, jurídico, saúde). É o que mais dialoga com a tese: métrica objetiva para o debate de produtividade agregada da IA aplicada a serviços profissionais. Sem avaliação séria, esse debate vira briga de anedota.

2. From Economic Agents to Agentic Economies — framework em que modelos de mundo econômico simulam interações entre agentes autônomos com preços, contratos e mercados. Antecipa como a difusão de agentes autônomos pode alterar microestrutura de mercados. É pauta que já bate à porta.

3. The Personalization Mirage — mostra que LLMs frequentemente fabricam perfis de usuários e que sistemas de automonitoramento subestimam esse viés. Relevante para quem usa IA em análise de dados financeiros ou de consumidor: reforça a cautela sobre "narrativas" geradas por LLMs em research econômica.

4. Time Travel on Professional Profiles — Bloom, Moore, Simon e Wilkie-Rogers usam dados longitudinais de perfis do LinkedIn para reconstruir trajetórias de carreira e testar hipóteses sobre mobilidade e adoção de novas tecnologias, incluindo IA. Evidência empírica sobre como a IA está redesenhando trajetórias ocupacionais.

5. Detecting Critical Junctures as They Unfold — Callen e coautores usam LLMs sobre 120 anos de jornalismo para identificar "junturas críticas" em tempo real. Metodologia aplicável a nowcasting macro e monitoramento de risco geopolítico.

📊 Modelo da semana — Solow revisitado

E aqui a tese fecha com macro, que é o meu lugar de origem.

No modelo de Solow, crescimento de longo prazo depende de progresso tecnológico. Mas — e é aqui que quase todo mundo passa batido — não é a tecnologia "disponível no ar" que gera crescimento. É a tecnologia incorporada ao processo produtivo. Máquina no chão de fábrica. Software rodando em produção. Trabalhador treinado.

Traduzindo para 2026: comprar o acesso ao GPT-5.6 Luna é ter a tecnologia disponível. Construir a engenharia em volta — o RAG, o guardrail, o roteador, o cache, a observabilidade — é incorporá-la.

Isso explica o paradoxo da abertura. O preço do token caiu 80%. O modelo chinês entrou no top 4 a 1/12 do preço. Mas a produtividade agregada ainda decepciona (como discuti na #199) porque a incorporação é lenta, cara e depende de gente que saiba fazer.

Amarra também com a decisão do Copom de 05/08: Selic a 14% a.a., quarto corte consecutivo, unânime. Restrição financeira afrouxando. Mas o investimento que puxa produtividade não é só função da taxa de juros — é função da capacidade de transformar capex em processo. Se a engenharia não existe, o dinheiro só compra hardware ocioso.

📘 Livros da semana

Os cinco títulos que estão na minha mesa, com Huyen e Nelson no centro:

  • AI Engineering — Chip Huyen (2024, O'Reilly). O manual do campo. 10 capítulos, 2 inteiros sobre avaliação. Se for ler um, é este.
  • Essential Math for AI — Hala Nelson (2023, O'Reilly). Os fundamentos que separam quem chama API de quem desenha sistema.
  • LLMs in Production — Christopher Brousseau, Matthew Sharp (2025, Manning). A ponte prática entre modelo e serviço.
  • Hands-On RAG for Production — Ofer Mendelevitch, Forrest Sheng Bao (2026, O'Reilly). RAG do zero ao SLA.
  • Practical LLM Evaluation for Production Systems — Mohanna, Kar, Ralte (2026, Packt). Complemento direto dos capítulos 3 e 4 do Huyen.

🧠 Insight final

Se você juntar os pontos desta edição, a foto que emerge é razoavelmente clara. O modelo virou commodity — o Qwen a US$ 2/mi, o Luna 80% mais barato, o DeepSeek empatando com o Gemini a US$ 0,03 por tarefa dizem exatamente isso. Preço despenca em bem que virou intercambiável.

O diferencial migrou para o sistema em volta: avaliação, arquitetura, produção. É por isso que a Amazon queima FCF com US$ 169 bi de capex sem retorno proporcional imediato — porque comprar GPU é o passo fácil. Incorporar isso ao processo produtivo, transformar em produto que fatura, é a parte lenta. É a parte de engenharia.

E é por isso, também, que a produtividade agregada decepciona mesmo com token barato. O gargalo nunca foi o modelo. Nunca vai ser.

📎 Material da semana

📄 Resumo da semana (PDF) — o digest completo das newsletters que embasou esta edição.

🎧 Ouça em podcast — esta edição em áudio.

Um abraço,
Vítor Wilher
Análise Macro

A verdade está nos dados.

Boletim AM

Receba todo domingo à noite em seu e-mail nossa newsletter com exercícios reais de análise de dados econômicos e financeiros, envolvendo muito estatística, econometria, machine learning e inteligência artificial em R e Python. Tudo o que você precisa saber para estar antenado no mundo dos dados!

Read more from Boletim AM

EDIÇÃO #203 | NEWSLETTER SEMANAL DA ANÁLISE MACRO Agentes de IA na Econometria Fala, Reader, tudo bem por aí? Saiu na semana passada um paper do NBER que fez uma coisa que muita gente do nosso meio faz todo dia sem medir: pedir para o modelo escrever código econométrico. Só que Galiani, López e Sosa mediram com rigor de experimento. 1.890 runs, 21 tarefas, 3 softwares, 3 níveis de agência. Fui ler o PDF inteiro. Não o abstract. E o resultado é interessante por dois motivos: por onde a IA...

EDIÇÃO #201 | NEWSLETTER SEMANAL DA ANÁLISE MACRO 58,1% dos empregos em risco? Fui atrás do número. Fala, Reader, tudo bem por aí? Essa semana esbarrei num site novo — o Profissões.org.br, um "atlas do trabalho brasileiro" — e logo na capa, o número que virou manchete no Brasil inteiro: 58,1% dos empregos no país correm alto risco de automação. Fui atrás. Porque quando um número se repete tanto, ele deixa de ser dado e vira slogan. Spoiler: o número existe, é sério, tem autor e DOI. Mas ele...

EDIÇÃO #200 | NEWSLETTER SEMANAL DA ANÁLISE MACRO Como tirar projeto do papel com IA (a escada de 4 degraus) Fala, Reader, tudo bem por aí? Edição 200. E, depois de duzentas edições escrevendo sobre análise de dados e IA, eu quero usar esta edição especial para te ajudar a tirar as coisas do papel. Tem uma coisa que eu venho notando há meses, conversando com alunos e leitores: quase todo mundo está travado no mesmo degrau. Abre o chat, faz pergunta, copia a resposta, cola no documento. Ganha...