A Crise de Dados em IA: Testamos Simula, Euphan e Hermes

A Crise de Dados em IA: Testamos Simula, Euphan e Hermes

O artigo que me fez parar tudo o que estava fazendo na semana passada não tratava de um novo modelo de fronteira. Não era um vazamento de benchmark. Tecnicamente, nem sequer foi um anúncio — foi uma publicação de pesquisa do Google com um título tão seco que a maioria das pessoas simplesmente rolou a página. "Orquestrando Conjuntos de Dados Sintéticos com Raciocínio." Eu quase rolei também.

Então li a frase que ficou na minha mente por três dias: modelos treinados com dados sintéticos às vezes superaram aqueles treinados com conjuntos de dados do mundo real. Não foi empate. Superaram. Em domínios especializados — segurança cibernética, raciocínio jurídico, medicina — onde os dados "reais" estão trancados por leis de privacidade ou são caros demais para coletar, uma equipe do Google construiu um sistema que deduziu seu caminho para um conjunto de treinamento melhor que o próprio dado real.

Esse artigo — que apresentou uma estrutura chamada Simula — é metade do que quero destrinchar neste post. A outra metade é o que a OpenAI vem entregando nesse mesmo período: uma superfície de interpretação de logs que insiders chamam insistentemente de "Euphan", e uma plataforma de agentes persistentes codinome Hermes, que está silenciosamente embutida nos módulos front-end pré-carregados do ChatGPT à espera de um sinal de liberação.

Três ferramentas. Uma mudança subjacente. E essa mudança — que vou defender ser a coisa mais importante acontecendo em IA neste momento — é que o gargalo mudou. Não é mais a computação. Nem mesmo o tamanho do modelo. É a linha de dados alimentando o modelo, a camada de observabilidade monitorando o agente, e o runtime sustentando o agente vivo entre sessões. Todas as três estão quebradas. Todas as três estão sendo consertadas, simultaneamente, pelos dois laboratórios que têm mais a perder caso não estejam.

Veja o que descobri ao examinar cada uma — o que é concreto, o que é vaporware e o que a combinação significa para quem estiver desenvolvendo sobre esses modelos em 2026.

Por Que a Crise de Dados é Pior do Que a Maioria dos Desenvolvedores Percebe

A narrativa convencional sobre o progresso da IA é uma narrativa de escala. Modelos maiores, mais parâmetros, mais poder computacional, melhores resultados. Essa história funcionou até cerca de um ano atrás. Então algo mudou, e ninguém na imprensa de consumo realmente percebeu.

As equipes que treinam modelos de fronteira ficaram sem internet de qualidade. Não pela quantidade — ainda há muito texto na internet. Mas a relação sinal-ruído do que restou para ser coletado entrou em colapso. O texto de alta qualidade foi consumido em execuções de treinamento anteriores. O que sobrou é duplicado, gerado por máquinas, ou superficial demais para ensinar algo novo ao modelo.

Para modelos de chat de uso geral como GPT, Gemini e Claude, isso aparece como retornos decrescentes na escala. Cada duplicação de tokens de treinamento gera uma melhora menor que a anterior. A curva está se inclinando.

Para domínios especializados, o problema é estruturalmente diferente e muito pior. Se você quer treinar um modelo realmente bom em raciocínio de cibersegurança, precisa de dados que representem a taxonomia real de ataques, atores de ameaça, classes de vulnerabilidades e estratégias de mitigação. Esses dados existem — mas estão fragmentados em feeds proprietários de inteligência de ameaças, relatórios de incidentes fechados e no conhecimento tácito de analistas seniores que nunca vão documentar isso.

Raciocínio jurídico? Selado sob sigilo, trancado atrás de paywalls, ou sepultado em jurisprudência específica de cada jurisdição, que nenhuma fonte única compilou de forma limpa.

Medicina? A HIPAA existe por bons motivos. Os dados nos quais você gostaria de treinar são exatamente os dados que não pode usar em larga escala, por questões legais.

Senti isso pessoalmente. Quando tentei fazer modelos populares raciocinarem cuidadosamente sobre vulnerabilidades de segurança em frameworks específicos, eles produzem respostas com tom confiante que não resistem à auditoria. Não porque os modelos sejam ruins — mas porque os dados nos quais foram treinados não cobrem o terreno real. Eles aprenderam a versão Wikipédia da cibersegurança, não a versão em que um pentester realmente trabalha.

Este é o muro. E o caminho para contorná-lo — o que todos os laboratórios sérios de IA vêm buscando há dois anos — é dados sintéticos. Não a versão de 2023 de dados sintéticos, que basicamente era “pedir para o GPT-4 gerar mais exemplos de treinamento e torcer para dar certo”. A versão de 2026, que é o que Simula representa.

Simula: Como se Apresenta a Geração de Dados com Enfoque em Raciocínio

Admito que, quando li rapidamente o artigo da Simula, pensei que seria só mais uma variação do padrão “LLM gera exemplos sintéticos, depois um LLM filtra”. Esse padrão existe desde 2023 e seu modo de falha é amplamente conhecido — o gerador converge para uma distribuição estreita de exemplos que parecem diversos, mas, na verdade, cobrem apenas uma pequena fatia do espaço de possibilidades. O termo técnico para isso é mode collapse (colapso de modos), e é o motivo pelo qual a maior parte dos pipelines de dados sintéticos tem desempenho inferior aos dados reais, mesmo gerando milhões de exemplos.

A Simula não segue esse padrão. Sua arquitetura é genuinamente diferente, e é justamente aí que surgem os ganhos de desempenho mais interessantes. Abaixo está o funcionamento real do mecanismo, na ordem em que o framework o executa.

Passo um: mapeamento estrutural do domínio. Antes de gerar qualquer dado, a Simula constrói uma taxonomia hierárquica do domínio-alvo. Em cibersegurança, essa taxonomia inclui tipos de ataque (phishing, injection, supply chain, engenharia social etc.), categorias de agentes de ameaça (nação-estado, crime organizado, hacktivista, infiltrado), classes de vulnerabilidade (buffer overflow, falha lógica, race condition, erro de configuração), e estratégias de mitigação. Cada ramo possui sub-ramos. A taxonomia é o mapa do que representa boa cobertura do domínio.

Só este passo já oferece mais estrutura do que a maioria dos pipelines de dados sintéticos. A maior parte deles assume que o modelo gerador naturalmente produzirá exemplos diversos. Não produzirá. Ele tende a produzir exemplos tendenciosos em relação ao que estava mais presente em seus próprios dados de treino.

Passo dois: amostragem controlada. Em vez de deixar o gerador escolher tópicos ao acaso, a Simula realiza amostragens deliberadas na taxonomia. Se em cibersegurança existem 400 nós, o amostrador garante que cada nó seja devidamente representado — inclusive os casos raros e complexos que um amostrador aleatório só atingiria uma vez a cada dez mil exemplos. Esta é a antítese do mode collapse. Não há como o processo colapsar para uma distribuição estreita se o amostrador força, explicitamente, a cobertura de todo o espaço.

Passo três: geração de metaprompts. Aqui a Simula começa a se destacar. O sistema não gera diretamente exemplos de treino. Ele gera prompts que irão gerar exemplos de treino. Esses metaprompts contêm restrições de formato, dificuldade, abordagem e profundidade de raciocínio. Esta camada de metaprompts traz uma variação que um sistema de geração direta não consegue igualar, pois os próprios metaprompts já são diversos entre si.

Reflita sobre a diferença. Geração direta: “Escreva uma pergunta e resposta sobre segurança cibernética focada em SQL injection.” Você recebe mil variações essencialmente da mesma resposta. Geração via metaprompts: “Escreva vinte modelos diferentes de prompt que levem a exemplos de treino de alta qualidade sobre SQL injection — sendo um do ponto de vista de um analista de incidentes, outro como revisão de código, outro como auditoria de compliance, outro como relatório de red team, outro como a primeira experiência de um engenheiro júnior, etc.” Agora, o gerador produz diferentes ângulos por design, não por acaso.

Passo quatro: parametrização da complexidade. A Simula trata complexidade como um eixo independente da diversidade. Você pode gerar exemplos simples em toda a taxonomia, ou exemplos complexos em toda a taxonomia, ou uma mistura deliberada de ambos. Pesquisadores do Google relataram que aumentar o parâmetro de complexidade gerou ganhos de até 10% em benchmarks de raciocínio matemático — desde que o modelo gerador fosse forte o suficiente para lidar com essa complexidade. Geradores fracos com complexidade elevada produziram grandes volumes de exemplos plausíveis, porém incorretos, o que prejudicou o modelo estudante.

É um alerta crucial: complexidade é um multiplicador, não uma solução mágica. Ela multiplica a qualidade do gerador — para melhor ou para pior.

Passo cinco: controle de qualidade por dupla crítica. Todo exemplo gerado passa por dois avaliadores. O primeiro pergunta: “isso está correto?” O segundo, separadamente, questione: “isso está incorreto?” A formulação aqui faz diferença. Perguntar duas vezes “isso está correto?” para o mesmo crítico produz respostas correlacionadas. Formular a segunda avaliação como uma contradição força um raciocínio independente. As duas respostas são combinadas em uma pontuação de validação. Exemplos que passam pelos dois filtros sobrevivem. Aqueles em que um crítico considera correto e o outro incorreto são sinalizados para revisão. Essa estrutura de duas perguntas é o que permite capturar as respostas plausíveis, porém erradas, que sistemas com um único crítico deixam passar.

A equipe testou este pipeline usando Gemini 2.5 Flash como modelo professor e Gemma-3 4B como estudante, gerou até 512.000 pontos de dados por domínio e avaliou em cinco domínios. O resultado de destaque — de que os dados sintéticos igualaram ou superaram os dados reais em domínios especializados — manteve-se em diferentes avaliações.

O artigo traz uma ressalva honesta, que ninguém no Twitter mencionou: não existe uma configuração única e ideal. A relação entre dados sintéticos “bons” e desempenho do modelo avaliado é, como os pesquisadores definiram, profundamente idiossincrática. Domínios diferentes exigem misturas de complexidade variadas, profundidades de taxonomia distintas, pesos de críticos diferentes. A Simula oferece os controles — não indica onde ajustá-los.

Mas a questão não é que a Simula seja uma solução milagrosa. A questão é que houve uma mudança de paradigma. Antes, a pergunta era “quanto dado você consegue coletar?” Agora, a pergunta é “quão bem você consegue desenhar os dados?” E os vencedores da próxima onda de AIs especializadas não serão os laboratórios com mais robôs de coleta. Serão os laboratórios com os melhores taxonomistas.

Euphan: Por Que a OpenAI Silenciosamente Criou um Visualizador de Logs

Deixe-me fazer uma pausa aqui, porque a segunda ferramenta desta história requer um contexto que a primeira não exigiu.

Se você nunca construiu um sistema de IA do tipo agente, o conceito de “log” provavelmente soa como algo que você encontraria em um dashboard de datacenter. Algo entediante. Algo que só preocupa o pessoal de operações. Deixe-me corrigir essa impressão, porque ela está errada de uma maneira que está custando tempo real para quem constrói.

Um agente executando até mesmo uma tarefa moderadamente complexa — digamos, pesquisar um tema, extrair dados estruturados, redigir um rascunho e publicá-lo em algum lugar — gera um log que não se parece em nada com um log tradicional de servidor. É uma árvore aninhada de chamadas de ferramentas, respostas de modelos, rastreamentos de raciocínio, saídas intermediárias, tentativas de repetição, concessão de permissões e transições de estado. Uma execução pode produzir milhares de linhas de JSON. A maior parte é ruído. Uma pequena porcentagem é, de fato, a história do que o agente fez e por quê.

Quando esse agente se comporta mal — e todos se comportam mal eventualmente — seu trabalho como desenvolvedor é encontrar o ponto no log onde o raciocínio falhou. Em um log bem estruturado, é tedioso. Em um dump bruto de JSON, são horas rolando a tela. Já passei noites inteiras vasculhando logs de agentes tentando entender por que uma chamada de ferramenta que deveria ter ocorrido não aconteceu, ou por que um modelo alucinou um parâmetro que não estava no prompt.

É esse espaço-problema que a OpenAI vem preenchendo silenciosamente. O nome interno que circula é Euphan, embora publicamente a empresa tenha disponibilizado a maior parte dessa funcionalidade no painel de rastreamento do Agents SDK e na nova interface workspace-agents do ChatGPT. Chame o sistema subjacente como quiser, a missão é específica e importante: transformar os logs brutos de agentes em algo que um humano consiga ler rapidamente.

Na prática, isso significa:

• Linhas do tempo estruturadas e limpas. Em vez de JSON aninhado, você recebe uma sequência linear de etapas, cada uma com uma etiqueta de papel claro (planejador, recuperador, chamador de ferramenta, respondedor), um carimbo de data e hora, e um resumo em uma linha. Clique em qualquer etapa para expandir todos os detalhes. Percorra a linha do tempo para encontrar o ponto de inflexão.
• Inspeção de papéis e ferramentas. Cada chamada de ferramenta mostra qual agente a invocou, quais parâmetros foram passados, o que retornou e quanto tempo levou. Se uma ferramenta retornou um erro 429 de limite de taxa quarenta minutos após o início da execução, isso aparece na linha do tempo sem você precisar caçar.
• Visibilidade do raciocínio de decisões. Agentes modernos emitem rastreamentos de raciocínio — a justificativa interna do modelo para escolher uma ação e não outra. Uma interface de log legível mostra esses rastreamentos como anotações em linha na linha do tempo, para que você veja não só o que o agente fez, mas por que achou que era a decisão certa.
• Edição direta de logs. Este é o recurso que mais me surpreendeu. Você pode editar uma entrada do log, salvar o estado modificado e reproduzir a execução a partir daquele ponto. É como um git rebase do histórico do agente. Não vi isso ser feito com qualidade em nenhum outro lugar.
• Filtros, pesquisa e consultas de metadados. Quando você está lidando com execuções que duram horas e possuem milhares de etapas, grep não basta. Você precisa de consultas estruturadas. “Mostre todas as chamadas de ferramenta com status != 200.” “Mostre rastreamentos de raciocínio onde a confiança caiu abaixo de 0.6.” Essa camada está disponível.

O motivo de eu continuar recorrendo a esta ferramenta, mesmo que não seja tão glamourosa quanto um novo modelo de fronteira, é que ela resolve um problema real que enfrentamos toda semana. Quando montei uma stack pessoal de agentes usando o Anthropic Agent SDK, a parte mais difícil não foi escrever o agente. Foi depurar o agente quando ele se comportava mal. Acabei montando um visualizador de logs improvisado em um banco de dados no Notion porque não aguentava mais ler JSON bruto. Se eu tivesse algo como o Euphan — ou uma interface equivalente para logs do Anthropic — teria lançado meu projeto uma semana antes.

Isso é infraestrutura para desenvolvedor. Não é um recurso para o consumidor. Não vai receber demo em keynote. Mas as equipes que colocam agentes em produção vão olhar para essas ferramentas de interpretação de logs como o momento em que o fluxo de trabalho inteiro se tornou viável.

Agora, a terceira peça.

Hermes: A Transição de Chatbot para Companheiro Sempre Ativo

Hermes é o codinome que vazou das builds internas da OpenAI nas últimas semanas, e preciso ser cuidadoso aqui porque há confusão de nomes no mercado. A comunidade open-source já tem uma ferramenta chamada Hermes Agent da Nous Research — já escrevi sobre como usá-lo com OpenClaw em um fluxo de trabalho de dois agentes. O Hermes da OpenAI é uma coisa totalmente diferente. Mesmo nome, empresa diferente, arquitetura diferente. O contexto importa.

O Hermes da OpenAI — ao menos com base nos recursos de frontend vazados e nos módulos pré-carregados no app web do ChatGPT — é uma plataforma para agentes persistentes. Não executores de tarefas pontuais. Não apenas "execute esta tarefa e retorne". Agentes que você define uma vez e que continuam existindo entre sessões, executando trabalhos agendados, respondendo a gatilhos, mantendo-se conectados a ferramentas externas e relatando de volta quando algo relevante acontece.

Se isso soa familiar, é porque segue a mesma direção arquitetônica adotada pela Anthropic com sua interface de agentes gerenciados, e o mesmo caminho que uma dúzia de empresas menores (incluindo o Hermes Agent da Nous Research que acabei de mencionar) vêm trilhando. Agentes persistentes não são uma ideia de um só fornecedor. Eles são o próximo passo de consenso.

O que diferencia a OpenAI é a distribuição. O ChatGPT tem centenas de milhões de usuários. Quando os agentes persistentes forem lançados dentro desse produto — não como uma ferramenta separada para desenvolvedores, mas como um recurso que qualquer usuário Plus pode ativar — o comportamento padrão de "conversar com uma IA" mudará de uma forma que parecerá comum em retrospecto, mas radical neste momento.

O que espero do Hermes quando for lançado, com base nos recursos vazados e no padrão seguido por todas as outras plataformas de agentes persistentes:

• Definições de agente que persistem entre conversas. Você cria um agente uma vez — define um papel ("meu assistente de pesquisa"), um conjunto de habilidades, uma lista de tarefas, talvez algumas permissões de acesso. O agente torna-se acessível a partir de qualquer conversa. Você não precisa reconfigurá-lo toda vez.
• Execução agendada e por gatilho. O agente opera de acordo com um cronograma (todas as manhãs às 7h, resumir as notícias da noite) ou por gatilhos (quando uma nova entrada aparece no meu banco de dados do Notion, redigir uma resposta). Essa é a mudança do modo reativo para proativo.
• Conexões de ferramentas que permanecem ativas. Agentes mantêm conexões autenticadas com serviços externos — Gmail, Calendar, GitHub, Slack, seja qual for o modelo de permissão. A ferramenta não precisa se reautenticar a cada execução. Ela já está conectada.
• Memória de longa duração. Agentes lembram execuções anteriores, saídas anteriores, feedbacks anteriores. Se você disse ao agente na semana passada que prefere resumos em três tópicos em vez de resumos em parágrafos, o agente deve se lembrar disso para sempre, a menos que você redefina explicitamente.

Não há data de lançamento. O recurso ainda está em testes internos, visível apenas por inspeção de recursos do frontend. Dito isso, a OpenAI tem avançado nesse sentido publicamente — agentes de workspace foram lançados em abril de 2026 para os planos Business, Enterprise e Edu, que compartilham a maioria das premissas arquitetônicas sobre as quais o Hermes deve ser construído. O padrão é claro. A dúvida é quando, não se.

Mas há algo a que sempre retorno. Agentes persistentes não funcionam sem as duas primeiras peças.

Agentes persistentes precisam de capacidade especializada — um agente que opera continuamente em um domínio específico (pesquisa jurídica, monitoramento de segurança, análise financeira) precisa de um modelo treinado com dados desse domínio. Modelos generalistas falham em tarefas especializadas de maneiras que se agravam quando o agente roda sem supervisão. Esse é o problema do Simula.

Agentes persistentes precisam de observabilidade — um agente rodando 24/7 gera ordens de magnitude mais logs do que um agente baseado em sessões. Sem uma ferramenta como Euphan, depurar um agente persistente em produção significa horas vasculhando logs toda vez que algo foge do esperado. Esse é o problema do Euphan.

Agentes persistentes precisam de um runtime — que é justamente o que o Hermes fornece.

Não dá para lançar apenas a terceira peça. Todas as três precisam funcionar em conjunto ou toda a pilha desaba sob seu próprio peso. E é esse o principal ponto que quero que você extraia deste artigo.

O Que Essa Combinação Realmente Significa para Builders

Dê um zoom out por um segundo. O que estamos presenciando, em tempo real, é a reconstrução completa do pipeline de desenvolvimento de IA, partindo da camada de dados para cima.

A camada de dados está sendo remodelada com sistemas como o Simula, onde a geração sintética com raciocínio e amostragem baseada em taxonomia produz dados de treinamento melhores do que qualquer coisa que possa ser coletada.

A camada de observabilidade está sendo reinventada com ferramentas de interpretação de logs como o Euphan, onde vestígios bagunçados de múltiplos agentes se transformam em linhas do tempo legíveis que você realmente pode depurar.

A camada de runtime está sendo redefinida com plataformas de agentes persistentes como o Hermes, onde agentes deixam de ser tarefas pontuais e passam a ser colegas de longa duração.

Cada um desses avanços é individualmente significativo. Mas é a combinação deles que realmente importa.

Se você está construindo qualquer coisa séria em cima desses modelos em 2026 — um produto SaaS, uma ferramenta interna, um pipeline de conteúdo, uma automação — aqui está a implicação prática. Você deve parar de assumir que o gargalo é o modelo. Reavalie suas premissas com essas três perguntas:

1. Meu caso de uso é especializado o suficiente para que um modelo de uso geral esteja apresentando desempenho abaixo do esperado? Se sim, a solução não é migrar para o modelo de fronteira mais novo. A solução é ou aguardar um modelo especializado treinado com dados no estilo Simula, ou construir você mesmo um modelo com geração sintética baseada em sua própria taxonomia.
2. Quando meu agente se comporta de forma inesperada, quanto tempo levo para entender o motivo? Se a resposta é "horas" ou "normalmente apenas reinicio e torço", o que você precisa é de melhor observabilidade, não de um agente melhor. Comece a adotar ferramentas de interpretação de logs agora, mesmo que ainda sejam rudimentares, porque seu impacto é cumulativo.
3. Estou reconstruindo o estado a cada sessão? Se você ainda executa agentes em conversas únicas de chat, está no lado errado da curva. Comece a projetar para persistência mesmo antes de o Hermes ser lançado — desacople o estado do seu agente da interface do chat, armazene-o em algum local durável, e o custo de migração, quando as plataformas de agentes persistentes chegarem, será praticamente nulo.

Nada disso é fácil. Venho trabalhando exatamente nessas questões na minha própria stack — algumas das quais descrevi no post treine agentes de IA para aprenderem habilidades de forma autônoma — e as respostas continuam me levando para mais infraestrutura e menos mágica. Mais taxonomia, mais logging, mais gestão de estado. Menos "jogue no modelo e veja o que acontece."

O que, pensando bem, é a mesma lição que qualquer disciplina séria de engenharia eventualmente aprende. A mágica está nas partes chatas.

Falando a Verdade: Onde Eu Acho Que Isso Quebra

Não quero que você termine achando que essas três ferramentas são a solução completa, porque não são. Eis o que eu sinalizaria como limitações reais e problemas em aberto.

Simula funciona porque os modelos subjacentes são suficientemente robustos. No momento em que se tenta aplicar o mesmo pipeline com um gerador mais fraco, a parametrização da complexidade amplifica erros em vez de qualidade. A maioria das equipes não tem acesso ao Gemini 2.5 Flash como modelo professor. Como pipelines equivalentes ao Simula funcionam em cenários de orçamento mais restrito ainda está sem resposta.

A interpretação de logs no estilo Euphan só é tão boa quanto a estrutura dos logs subjacentes. Se o framework de agente que você está usando emite logs bagunçados e não estruturados — e muitos ainda fazem isso — nenhuma camada de interpretação vai gerar clareza a partir de uma entrada ruim. O formato do log precisa ser pensado para observabilidade desde o início.

Agentes persistentes levantam uma questão de segurança para a qual ninguém tem uma boa resposta ainda. Um agente que roda 24/7 com conexões autenticadas ao seu Gmail, seu GitHub, seu calendário, é uma grande superfície de ataque. Se o raciocínio do agente pode ser manipulado — seja por injeção de prompt em um e-mail recebido ou por um resultado de busca envenenado — o raio de impacto atinge todo o grafo autenticado. Todas as plataformas de agentes persistentes que vi reconhecem esse problema e nenhuma resolveu completamente. É por isso que ferramentas de segurança para agentes de IA vão se tornar uma categoria enorme, e por isso continuo voltando a esse tema.

O resumo honesto é que essas três ferramentas são a direção, não o destino. Os próximos dezoito meses de desenvolvimento em IA vão ser dedicados a descobrir como fazer esse stack realmente funcionar, ponta a ponta, em produção, para casos de uso que não sejam apenas “gerar um post de blog” ou “resumir um documento”. Trabalho real. Consequências reais. Requisitos reais de uptime.

E é exatamente esse tipo de problema que quero trabalhar.

O Que Estou Observando a Seguir

Três pontos específicos que estou acompanhando no próximo trimestre.

Primeiro, replicações open-source do Simula. O artigo é detalhado o suficiente para que uma equipe motivada possa reconstruir o pipeline fora da infraestrutura do Google. Espero ver a primeira implementação open-source séria em até 60 dias, e quem entregar isso de forma limpa se tornará a ferramenta padrão para dados sintéticos de domínio especializado no mundo open-source.

Segundo, padrões de interpretação de logs. Atualmente, cada framework de agentes tem seu próprio formato de log. O da OpenAI é diferente do da Anthropic, que é diferente do da LangChain, que é diferente do da Nous Research. Essa fragmentação inevitavelmente vai forçar algum tipo de padrão comum para rastreamento — provavelmente algo baseado em convenções do OpenTelemetry — e o primeiro framework que oferecer boa interoperabilidade vai conquistar muita boa vontade dos desenvolvedores.

Terceiro, janela de lançamento do Hermes. Dou 60% de probabilidade de que seja lançado publicamente antes do fim do terceiro trimestre de 2026, considerando quão avançada já está a integração do frontend. Se for lançado, o padrão de "agente sempre ativo" deixará de ser algo restrito a desenvolvedores de nicho e se tornará o padrão para centenas de milhões de usuários do ChatGPT em poucas semanas. Isso define uma categoria.

Fique atento aos três. Um deles provavelmente será a maior história de IA do verão.

Aquele artigo que mencionei no início — o artigo do Simula, que quase deixei passar — é o motivo pelo qual agora acredito que o trabalho mais importante em IA em 2026 não está acontecendo na camada de modelo. Está acontecendo em design de dados, observabilidade e tempo de execução. Chato. Com cara de infraestrutura. Enormemente significativo.

Se for para ler apenas uma coisa deste post, leia essa frase duas vezes. Depois, olhe para sua própria stack e pergunte qual das três camadas é a mais fraca. Corrija essa primeiro. Todo o resto é consequência.

Perguntas Frequentes

O que é geração de dados sintéticos no treinamento de IA?

A geração de dados sintéticos é o processo de usar modelos de IA para produzir exemplos de treinamento que não existiam no conjunto de dados original. Sistemas modernos como o Simula, do Google, utilizam taxonomias orientadas por raciocínio e validação dual-critic, de modo que os dados gerados possam igualar ou superar os dados reais em domínios especializados. Para entender o mecanismo completo, consulte a seção sobre o Simula acima.

Por que dados sintéticos são melhores do que dados reais em domínios especializados de IA?

Dados reais em áreas como cibersegurança, jurídico e saúde geralmente estão protegidos por leis de privacidade, estão fragmentados entre fontes proprietárias ou simplesmente não existem em volume suficiente para o treinamento. Dados sintéticos bem projetados podem cobrir toda a taxonomia do domínio — incluindo casos raros — com qualidade controlada. Nos benchmarks do Simula, do Google, modelos treinados com dados sintéticos, em alguns casos, superaram modelos treinados com dados reais em tarefas especializadas.

O que é mode collapse em dados sintéticos e como evitá-lo?

Mode collapse ocorre quando um modelo gerador produz exemplos repetitivos e estreitos que parecem diversos à primeira vista, mas cobrem apenas uma faixa limitada da distribuição real. O Simula previne isso ao amostrar dados por toda uma taxonomia estruturada e ao usar metaprompts — prompts que geram prompts — para forçar variação genuína em ângulo, formato e profundidade do raciocínio.

Quando será lançado o recurso de agente persistente Hermes da OpenAI?

A OpenAI ainda não anunciou uma data de lançamento para o recurso de agente persistente Hermes. Recursos de frontend e módulos pré-carregados observados no app web do ChatGPT sugerem desenvolvimento ativo, e funcionalidades relacionadas, como agentes de workspace, já foram lançadas em abril de 2026 para os planos Business, Enterprise e Edu. Com base nesse padrão, um lançamento público do Hermes durante 2026 parece provável.

O que é um interpretador de logs de agentes de IA e por que os desenvolvedores precisam de um?

Um interpretador de logs de agentes de IA é uma ferramenta que converte logs brutos e aninhados de agentes — chamadas de ferramentas, rastros de raciocínio, novas tentativas, transições de estado — em linhas do tempo estruturadas e legíveis. A interface no estilo Euphan da OpenAI e o painel de rastreamento do Agents SDK exibem cada etapa, o papel que a executou, as ferramentas chamadas e o raciocínio por trás de cada decisão. Sem essa camada, depurar um agente com mau funcionamento significa rolar por milhares de linhas de JSON bruto.

Vamos Trabalhar Juntos

Quer construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Quero ajudar você.

• Fiverr (projetos e integrações sob medida): fiverr.com/s/EgxYmWD
• Portfólio: mejba.me
• Ramlit Limited (soluções corporativas): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io