|
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 lugarHá 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 pilaresO roadmap organiza o ofício em três pilares. Não são etapas — são camadas que rodam juntas.
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çãoAqui 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 pularO 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 mostraUma 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:
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çoO 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 versão-produto expôs quatro endpoints em FastAPI: 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 semanaOrdenei 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 revisitadoE 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 semanaOs cinco títulos que estão na minha mesa, com Huyen e Nelson no centro:
🧠 Insight finalSe 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, A verdade está nos dados. |
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!
EDIÇÃO #210 | NEWSLETTER SEMANAL DA ANÁLISE MACRO Ovos são perigosos? Fala, Reader, posso te contratar como perito? Essa foi, mais ou menos, a primeira questão de um trabalho de Econometria do Doutorado, há poucos dias. O enunciado me colocava no papel de consultor técnico num caso real dos anos 1970 nos Estados Unidos: produtores de ovos, reunidos na National Commission on Egg Nutrition, publicaram anúncios dizendo que não havia evidência científica de que comer ovo aumentasse o risco de...
EDIÇÃO #209 | NEWSLETTER SEMANAL DA ANÁLISE MACRO O agente ficou com o trabalho. Quem ficou com o dinheiro? Fala, Reader, você viu a manchete do "hedge fund que trocou US$ 5 milhões de folha por 4 agentes de IA"? Ela rodou a semana inteira. Eu fui atrás da fonte, li a entrevista original na CNBC e descobri que a história é real — mas está sendo contada errada. E aí, ao arrumar o caso, apareceu uma pergunta bem maior que "a IA vai tirar meu emprego?". Bora lá. 🎯 O que a manchete não conta...
EDIÇÃO #208 | NEWSLETTER SEMANAL DA ANÁLISE MACRO Por que querem parar a IA? Estão querendo parar o desenvolvimento da IA, você viu, Reader? Fiquei pensando nisso e no que temos conversado por aqui, em outros boletins. E eu tenho uma hipótese que gostaria de compartilhar com você. Primeiro, deixa eu te mostrar uma conta que apareceu esta semana no 8-K da Oracle, referente ao trimestre encerrado em 31 de agosto de 2026. Receita do trimestre: US$ 19,3 bilhões. Capex do mesmo trimestre: US$ 28,5...