O que mais me chama atenção nessa notícia (segundo o Tecnoblog.net, “IAs chinesas superam rivais humanos em olimpíada de matemática”) não é só o “100%”. É o fato de que modelos de IA passaram a encarar um tipo de prova com restrições muito parecidas com “ambiente de teste real”: sem intervenção humana, com questões liberadas apenas depois de resolvidas pelos estudantes e, principalmente, sem “atalhos” óbvios. Quando uma IA começa a acertar esse padrão, o debate sai do marketing e entra no que realmente importa para quem programa: pipelines de raciocínio, verificação automática, e como você mede confiabilidade sem se enganar.
O que aconteceu de verdade: IMO, 100% e por que isso importa
Segundo o Tecnoblog.net, dois sistemas chineses — Celia (Huawei) e dots-node-3.0 (Xiaohongshu) — teriam gabaritado a Olimpíada Internacional de Matemática (IMO) em um teste específico. O relato aponta que:
- É um dos primeiros registros em que uma IA alcança acerto máximo em um desafio do tipo.
- A Xiaohongshu afirma que é a primeira vez que o modelo foi testado com questões da IMO.
- As questões foram disponibilizadas para teste depois da conclusão entre estudantes reais.
- Nenhuma intervenção humana foi permitida durante as resoluções.
Para quem desenvolve software, isso é relevante porque derruba um problema clássico: “o modelo só acertou porque vazou ou porque teve contexto prévio”. A IMO é justamente o tipo de benchmark que tenta reduzir esse tipo de fraude.
Por trás do 100%: não é “só modelo grande” (é pipeline)
Quando eu vejo um resultado assim, eu não penso primeiro em “mais parâmetros”. Eu penso em workflow. Em provas matemáticas de alto nível, acertar todas as questões exige, quase sempre, um conjunto de mecanismos:
- : o modelo precisa propor múltiplas rotas de solução.
- : algum componente precisa checar consistência (seja formal, seja heurística robusta).
- : evitar o famoso “parece certo, mas…”.
- : decidir quando expandir raciocínio, quando truncar, e quando reescrever.
Esse ponto é ignorado em muitos posts de divulgação. Para devs, o recado é: se você está construindo sistemas com IA, o salto real costuma estar no orquestrador e na verificação, não apenas no “modelo mais novo”.
Comparativo com Google/OpenAI (e por que “muito bom” não é “100%”)
Segundo o Tecnoblog.net, no ano passado Google e OpenAI publicaram resultados bem positivos, mas não perfeitos. E existe uma diferença importante entre “resolver bem” e “resolver tudo”. Na prática:
- Modelos podem errar por um detalhe estrutural (uma identidade algébrica fora de lugar, uma hipótese implícita, um caso não tratado).
- Uma solução correta pode exigir tempo e iteração suficientes para o modelo “chegar no truque”.
- Em testes com restrições, a margem para “tentar de novo” é menor, e a taxa de erro acumulada aumenta.
Por isso, quando a Xiaohongshu diz que 100% é extremamente difícil, eu concordo. Em matemática olímpica, você tem poucas questões, mas cada questão costuma ser um “mini universo” de armadilhas.
O que o teste sugere: avaliação com menos viés e mais controle
O Tecnoblog.net também menciona, via Taipei Times, que as questões foram liberadas para teste apenas depois de concluídas por estudantes reais e sem intervenção humana. Isso é um passo em direção a avaliação mais “limpa”.
E tem outro ponto: o artigo relata testes independentes feitos pela Menlo Ventures com IAs americanas (ChatGPT GPT-5.6 Sol, Claude Fable 5 e Axiom Math), também com gabarito no teste.
Mesmo que você desconfie de qualquer claim isolado, o alinhamento do resultado entre atores diferentes tende a indicar que o teste estava mais “blindado” contra vazamento e interferência.
Na prática: como você avalia uma IA em “provas” sem se autoenganar
Vou ser bem direto com a minha experiência: se você quer medir capacidade em tarefas difíceis (matemática, programação competitiva, provas técnicas), você precisa de um pipeline de avaliação com três camadas. Caso contrário, você mede “narrativa fluida”, não “capacidade real”.
Passo a passo (modelo mental + implementação mínima)
- Trave o input: provas/itens devem ser fixos e publicados sem permitir contaminação (versão congelada do dataset).
- Bloqueie intervenção: sem “ajudas” do operador durante geração e checagem.
- Use múltiplas tentativas controladas: se o método permite, gere N soluções com sementes diferentes.
- Verifique: aplique um verificador programático sempre que possível (CAS, provers, checagem simbólica, ou regras determinísticas).
- Registre tudo: tokens, prompts, respostas intermediárias, tempo. Sem isso, você não aprende por que falhou.
Um exemplo funcional: avaliação com “gerar → verificar” (checam consistência)
Como dev, você pode começar com verificação automática mesmo que não seja prova formal completa. Em matemática, dá para checar invariantes, validar passos e/ou testar equivalência por simulação.
Exemplo em Python (esqueleto) que gera candidatos e passa por um verificador determinístico. (Aqui eu uso um verificador “stub”, mas a estrutura é o que importa.)
import time
from dataclasses import dataclass
@dataclass
class Result:
ok: bool
attempts: int
best_text: str
elapsed_s: float
def verify_solution(question: str, solution_text: str) -> bool:
# TODO: substitua por verificador real:
# - CAS / sympy
# - regras determinísticas
# - execução de código simbólico
# - ou integração com um provador
#
# Stub para exemplo:
return "QED" in solution_text or "provado" in solution_text
def solve_with_verification(model, question: str, n_attempts: int = 5) -> Result:
start = time.time()
best = None
for i in range(n_attempts):
prompt = f"""Resolva a questão com rigor.
Retorne a demonstração final e uma forma de verificação.
Questão: {question}
"""
# model.generate deve ser sua chamada ao LLM
text = model.generate(prompt)
if best is None:
best = text
if verify_solution(question, text):
return Result(ok=True, attempts=i+1, best_text=text, elapsed_s=time.time()-start)
return Result(ok=False, attempts=n_attempts, best_text=best or "", elapsed_s=time.time()-start)O “porquê” aqui é simples: se você não tem verificador, você tende a aceitar “soluções convincentes”, e isso explode em benchmarks difíceis. Com verificação, você mede algo mais próximo do que interessa: correção.
Erros comuns (e caros) que devs cometem ao avaliar IA em tarefas difíceis
1) Confundir qualidade textual com correção
Um erro clássico é olhar só para a resposta e não para o “por baixo”. Em tarefas matemáticas e de engenharia, o modelo pode soar confiante e ainda assim estar errado.
Como evitar: verificação automática ou checagem determinística. Se isso não existir, você não tem benchmark, tem opinião.
2) Não separar “tempo” de “resultado”
O Tecnoblog.net menciona um caso em que a resolução do Google/DeepMind demorou cerca de três dias (em 2024). Esse tipo de informação é crucial: às vezes a IA acerta, mas só quando você dá tempo/compute suficiente.
Como evitar: sempre reporte custo: tempo total, nº de tentativas, e limites (tokens/iteração).
3) Avaliar com dataset “viciado”
Se o dataset teve vazamento, fine-tuning sem controle, ou prompts parecidos com exemplos de treino, sua métrica vira propaganda.
Como evitar: congelar versão das questões, documentar origem e usar controles (ex.: perguntas inéditas ou blinds).
4) Falhar na orquestração: “gerou uma vez, acabou”
Muita gente testa assim: manda prompt, lê resposta, pontua. Em matemática, isso reduz demais a chance de encontrar o caminho certo.
Como evitar: tentativa multi-candidato com verificador e critérios de seleção.
5) Não cuidar do “contrato” do modelo
Quando você quer rigor, você precisa exigir saída compatível com verificação. Por exemplo: formato de prova, passos explícitos, ou uma seção final que possa ser checada.
Como evitar: use prompts que induzam verificabilidade (e não só “seja convincente”).
Implicações práticas para quem programa (fora do hype)
Agora vamos ao que importa no dia a dia.
1) Codar “verificação” vira requisito de produto
Se IAs estão se aproximando de acertos completos em tarefas estruturadas, o próximo gargalo deixa de ser “encontrar uma resposta” e passa a ser “confirmar a resposta”. Isso muda o desenvolvimento: você vai gastar mais energia em ferramentas de checagem e menos em tentativa e erro manual.
2) Pipelines com tentativa multi-candidato passam a ser padrão
Em produção, você não quer custo infinito. Mas você quer controle de tentativas até obter um estado válido. Pense em “falha rápida + retry inteligente”.
3) Monitoramento e auditoria ganham importância
Se o modelo acerta 100% em um benchmark, mas você não loga por que acertou (ou como verificou), você não tem segurança para escalar. Sistemas “corretos” sem rastreabilidade viram risco.
4) A fronteira é integração: LLM + ferramentas
Você provavelmente vai usar:
- CAS/simbólico (para matemática)
- linters e testes (para programação)
- executores sandbox (para validar comportamento)
- verificadores formais quando o domínio exige
Esse é o caminho que transforma IA de “chat” em “motor de solução”.
O que eu concluiria como dev sênior ao ler isso
Mesmo sem detalhes completos dos modelos exatos anteriores (o Tecnoblog.net ressalta que não foram revelados), a mensagem técnica é consistente: quando há avaliação controlada e verificação, a performance real pode ultrapassar humanos em tarefas específicas.
Mas eu não trataria isso como “IA vai substituir tudo”. Eu trataria como “os componentes certos estão ficando bons”, e o trabalho do dev agora é montar sistemas que:
- limitam vieses do teste;
- autenticam correção;
- otimizam custo-tempo;
- produzem saídas reutilizáveis para validação.
FAQ
1) Se a IA gabaritou a IMO, então ela “entende” matemática?
Entender no sentido humano é outro debate. O que dá para afirmar é que ela consegue resolver e sustentar soluções suficientes para passar por um sistema de avaliação (com restrições descritas). Em engenharia, isso é o que importa: desempenho verificável.
2) Por que 100% é tão difícil mesmo para modelos avançados?
Porque erros pequenos em hipóteses ou casos especiais derrubam a questão. Além disso, sem intervenção humana, você perde a “correção guiada” que humanos fazem quando percebem inconsistências.
3) O que diferencia esse teste de um “prompt e score” simples?
Controles como liberação das questões após conclusão e proibição de intervenção durante a resolução, além de (provavelmente) um mecanismo de verificação para considerar respostas como corretas.
4) Como eu aplico isso no meu produto com IA?
Adote a lógica “gerar → verificar → aceitar/rejeitar”. Sempre que possível, use ferramentas determinísticas para validação (testes, compilação, CAS, regras). Não pontue só por texto.
5) Quantas tentativas devo usar antes de falhar?
Depende do custo e do domínio. O padrão é começar com um limite pequeno (ex.: 3–5 tentativas) e ajustar com base na taxa de aceitação após verificação. O ideal é medir por classe de dificuldade.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.