Previsão do campeão da Copa do Mundo 2026: um guia de MLOps

Os dados por trás das previsões

Uma previsão só é tão boa quanto seus insumos, então vale começar pela matéria-prima. O modelo aprende com duas fontes de dados ao vivo e as transforma em uma única tabela enxuta de features.

De onde vêm os dados

Tudo é construído a partir de dois lugares. A API-Football fornece a tabela de jogos e as estatísticas por partida: quem jogou contra quem, quando, onde e como terminou. O eloratings.net fornece os ratings Elo de cada seleção nacional.

Um rating Elo é um único número que expressa a força de uma equipe. Toda equipe está em algum ponto da escala e, após cada jogo, o rating é atualizado: vença um adversário mais forte e você ganha muito; perca para um mais fraco e você cai bastante. A ideia vem do xadrez e se adapta muito bem ao futebol. Se quiser a intuição completa, este artigo da DataCamp explica no contexto da Copa de 2022.

Juntas, as duas fontes geram um dataset Gold com cerca de 6.900 partidas internacionais desde 2018 para treinar.

O que o modelo prevê

Aqui entra a primeira decisão de design importante. Em vez de prever o resultado diretamente (vitória, empate ou derrota), o modelo prevê algo mais granular: o número de gols que cada equipe marca na partida. Contagens de gols no futebol seguem, com boa aproximação, uma distribuição de Poisson, a forma padrão de modelar a ocorrência de eventos relativamente raros em uma janela de tempo fixa.

Prever gols, e não apenas resultados, é o que torna todo o resto possível. Quando o modelo consegue produzir um placar plausível para qualquer confronto, as perguntas que todo mundo realmente quer responder — quem passa de fase e quem levanta a taça — podem ser respondidas simulando esses placares milhares de vezes.

As features que importam

Cada partida é descrita por um conjunto pequeno e bem escolhido de features:

\n
• Diferença de Elo: o gap de rating entre as duas equipes. É, de longe, a feature mais importante, com importância cerca de duas ordens de grandeza acima da segunda. Isso bate com a intuição: a diferença de força entre os lados diz mais sobre o resultado provável do que quase qualquer outra coisa.
\n
• Soma de Elo: a soma dos dois ratings, um proxy da qualidade geral do confronto. A diferença sozinha não distingue Argentina x Espanha de San Marino x Andorra — jogos equilibrados em níveis completamente diferentes — e a soma recupera essa informação.
\n
• Variação recente de Elo (últimos 5 jogos): quanto o rating de cada equipe mudou recentemente. Isso captura a fase levando em conta a força dos adversários enfrentados.
\n
• Gols pró e contra recentes (últimos 5 jogos): produção ofensiva e defensiva recente em termos absolutos, calculada para cada equipe.
\n
• Contexto do jogo: o nível da competição (um jogo de Copa do Mundo tem peso diferente de uma eliminatória ou da Nations League), se é mata-mata e se é em campo neutro.
\n

Toda feature é estritamente à prova de vazamento de informação: usa apenas o que estava disponível antes do apito inicial. Parece óbvio, mas é uma das formas mais fáceis de construir sem querer um modelo que brilha no teste e desmorona no mundo real.

Uma ideia que ficou de fora: eu planejava um conjunto de features de \"estilo de jogo\" construídas por clusterização de seleções a partir de estatísticas em jogo, um passo de aprendizado não supervisionado. Na prática, as seleções não se separaram em grupos significativos e, para não alimentar o modelo com ruído, descartei. Resultado negativo também é resultado.

Garantindo reprodutibilidade dos dados

Com dados chegando de duas fontes continuamente, o caminho dos arquivos brutos até as features prontas para o modelo precisa ser idêntico toda vez. É isso que a arquitetura de medalhões oferece. Ela organiza os dados em três camadas:

\n
• Bronze: dados brutos, exatamente como chegam, sem toques.
\n
• Silver: dados limpos e padronizados. Aqui eu mapeio nomes de seleções entre as fontes (raramente concordam na grafia), valido o esquema, junto os ratings Elo aos registros de partidas e trato o que estiver faltando ou malformado.
\n
• Gold: a camada de modelagem, uma linha limpa por partida com todas as features calculadas e prontas para treinar.
\n

Uma camada alimenta a outra; quando algo parece fora do lugar, eu consigo rastrear etapa por etapa, em vez de desfazer tudo de uma vez. Para tornar o caminho todo reprodutível, uso o DVC (Data Version Control). Sempre que chegam resultados novos, um único dvc repro reconstrói as camadas Silver e Gold a partir da Bronze, reexecutando uma etapa só se suas entradas mudaram, e versiona os datasets resultantes para que qualquer estado anterior possa ser recuperado exatamente.

Escolhendo o melhor modelo

Prever gols é um problema muito estudado e não há uma ferramenta única e óbvia para isso. Em vez de decidir antes da hora, construí dez modelos e deixei que competissem.

Os concorrentes

Os dez modelos cobrem cinco famílias mais um baseline simples. Você não precisa conhecer os detalhes de cada um; o ponto é que eles fazem suposições bem diferentes sobre como os gols acontecem.

Como foram avaliados

Com dez candidatos, escolher no olho não ia funcionar. Em vez disso, cada modelo passa por três etapas, e o código decide se ele avança. É isso que significa deploy orientado por código: os modelos são promovidos de um ambiente a outro por checagens automatizadas, não por ajustes manuais, mantendo o processo reprodutível e auditável.

\n
• Experimento. Todo modelo é treinado apenas em partidas internacionais disputadas antes da Copa de 2022. Nem todos esses jogos pesam igual: partidas mais recentes e de maior importância recebem mais peso (decaimento temporal e ponderação por importância), então um resultado competitivo recente influencia mais do que um amistoso antigo. Em seguida, os hiperparâmetros são ajustados para minimizar a log-verossimilhança negativa de Poisson (NLL) usando validação cruzada. NLL é uma medida de quão bem as taxas de gols previstas batem com os gols que as equipes realmente marcaram — quanto menor, melhor. O resultado é a melhor versão ajustada de cada modelo.
\n
• Garantia de qualidade. Esses modelos ajustados são então testados em partidas que nunca viram: a Copa de 2022 e mais seis grandes torneios desde então (a EURO, duas Copas Africanas de Nações, a Copa América, a Copa da Ásia e a Gold Cup), 347 jogos ao todo. Aqui, a métrica muda para o ranked probability score (RPS), que mede a qualidade de uma previsão probabilística quando os desfechos têm ordem natural (derrota, empate, vitória) e recompensa a confiança na direção certa. Menor é melhor de novo. O modelo mais forte aqui vira o desafiante. O RPS é o critério certo porque o objetivo real é prever até onde as seleções chegam, não só totais de gols.
\n
• Deploy. O desafiante é comparado ao campeão vigente. Se vencer, é promovido e readequado com todos os jogos disponíveis, para entrar no torneio tendo aprendido de todos os dados.
\n

Quem venceu

Então, qual abordagem ficou no topo? Aqui está o ranking completo no holdout, medido por RPS (quanto menor, melhor):

Quatro pontos chamam atenção nesses resultados:

\n
• O XGBoost venceu, mas por muito pouco. Os cinco primeiros (XGBoost, Poisson bayesiano, binomial negativa, Poisson bivariado e Random Forest) ficaram dentro de ~0,0011 de RPS entre si. Quando abordagens tão diferentes chegam tão perto, geralmente o teto está nos dados e nas features, não no modelo. Aqui, a diferença de Elo faz tanto do trabalho que a escolha do modelo mexe pouco no ponteiro.
\n
• Uma feature domina. A diferença de Elo foi, de longe, o preditor mais importante, cerca de cem vezes mais influente do que a próxima feature. É reconfortante e nada surpreendente: em um único jogo, a diferença de força entre as equipes é quase toda a história.
\n
• Deep learning ficou por último (tirando o baseline). A CNN 1D e a LSTM foram as mais fracas além do baseline ingênuo. Com apenas ~7.000 partidas para aprender, não há dados suficientes para redes com tantos parâmetros; métodos clássicos lidam muito melhor com datasets pequenos e estruturados.
\n
• Nada de overfitting nos modelos clássicos. Normalmente, um modelo vai um pouco pior em dados não vistos do que no treino. Aqui, quase todos (exceto a LSTM) foram melhores nos torneios mantidos em holdout do que na validação cruzada. A razão provável é que o futebol de torneio é mais previsível do que o calendário internacional do dia a dia: maior peso, seleções mais fortes e conhecidas e campos neutros reduzem a aleatoriedade.
\n

Para o torneio ao vivo, não rodo todos os dez. Mantenho um elenco menor: o baseline de taxa média como referência e os três melhores. XGBoost e Poisson bayesiano ocupam as duas primeiras posições com folga.

A terceira posição é praticamente um empate: binomial negativa e Poisson bivariado ficam a menos de 0,0002 de RPS uma da outra e trocam de lugar dependendo da semente aleatória. Entre dois modelos indistinguíveis estatisticamente, optei pelo Poisson bivariado, cuja formulação tem base mais sólida na literatura de previsão de futebol (Karlis e Ntzoufras, 2004).

Isso deixa um elenco com XGBoost (machine learning), Poisson bivariado (estatística clássica) e Poisson bayesiano (inferência bayesiana). A próxima seção cobre como esses modelos rodam, se re-treinam e transformam previsões de jogos isolados em uma projeção do torneio completo.

Levando para produção

Um modelo que vive em um notebook só é útil enquanto você está na frente dele. Para prever partidas ao longo de um mês de torneio, tudo precisa rodar sozinho: buscar novos resultados, re-treinar, re-simular e atualizar a projeção sem intervenção humana. Esse é o papel do pipeline.

O pipeline a cada duas horas no GCP

O projeto inteiro roda como um job único e agendado no Google Cloud Run. Antes do torneio, ele acorda uma vez por dia; a partir do jogo de abertura, em 11 de junho, roda a cada duas horas. Cada execução segue o mesmo ciclo:

\n
• Checar novos dados. Se nenhuma partida terminou desde a última execução, não há o que fazer e o job encerra cedo.
\n
• Ingerir e reconstruir. Quando há resultados novos, eles são buscados nas fontes e um único dvc repro reconstrói as camadas Silver e Gold para atualizar as features.
\n
• Re-treinar, prever, simular. Os modelos do elenco são atualizados (explico já já), todos os confrontos futuros são previstos e o torneio completo é simulado.
\n
• Avaliar. Assim que uma partida termina, as previsões feitas para ela são pontuadas, alimentando o monitoramento descrito abaixo.
\n

Como cada etapa é disparada por código em um agendamento, não há cliques manuais durante o torneio. Entrou resultado novo, sai projeção atualizada.

Dois modos: congelado vs. por rodada

É aqui que o projeto também vira experimento. Durante o torneio, o elenco roda em dois modos paralelos, e a diferença entre eles é a pergunta que espero responder com os dados: re-treinar ao longo do torneio melhora as previsões?

\n
• Congelado. Os modelos são travados no pontapé inicial e nunca são re-treinados. Eles ainda reagem aos resultados porque cada simulação começa do chaveamento atualizado, mas os parâmetros do modelo não mudam.
\n
• Por rodada. Os hiperparâmetros (as configurações de alto nível) ficam fixos, mas os parâmetros aprendidos são reajustados com todos os dados disponíveis após cada rodada de grupos e cada fase do mata-mata, então os modelos continuam aprendendo com o torneio em andamento.
\n

Rodar os dois lado a lado permite compará-los, ao final, em dois pontos: a acurácia bruta e a velocidade com que a incerteza de cada um se resolve conforme o campo afunila. Se o modo por rodada vencer, o re-treinamento recorrente se paga; se o congelado se sustentar, talvez a máquina extra não valha o esforço.

Das previsões ao torneio: a simulação de Monte Carlo

Prever um jogo é uma coisa. Transformar isso em \"qual é a chance de cada seleção ser campeã\" é onde entra a simulação de Monte Carlo.

Primeiro, a inferência. Em vez de prever só os confrontos já conhecidos, o modelo prevê todo confronto possível entre as 48 seleções. Parece exagero, mas em um torneio qualquer seleção pode encarar outra no mata-mata, então é preciso ter previsão pronta para todo par.

Depois, é preciso codificar as regras — e o formato de 2026 complica. Nos 12 grupos, os dois primeiros avançam automaticamente, e também os oito melhores terceiros, e o slot no mata-mata de cada um desses oito depende de quais grupos eles vieram.

Existem 495 maneiras de escolher oito grupos classificando terceiros entre doze (doze escolhe oito), e cada uma gera um pareamento diferente nas oitavas de 32. Não há fórmula limpa; a FIFA simplesmente publica uma tabela. Então eu (na verdade, minha colega muito capaz, a Cursor) codifiquei todas as 495 combinações em um mapeamento, usando a tabela oficial como fonte.

\"best_third_mappings\": {\n  \"EFGHIJKL\": {\n    \"74\": \"3F\",\n    \"77\": \"3G\",\n    \"79\": \"3E\",\n    \"80\": \"3K\",\n    \"81\": \"3I\",\n    \"82\": \"3H\",\n    \"85\": \"3J\",\n    \"87\": \"3L\"\n  }, \n  \"DFGHIJKL\": ...

Cada chave, como EFGHIJKL, lista quais oito grupos forneceram os terceiros classificados, e os valores posicionam cada um desses times (3E, 3F etc.) em um número específico de jogo na fase de 32. Esse é um item; o mapeamento completo repete isso 495 vezes, uma por combinação.

As três sedes (Estados Unidos, Canadá e México) têm um tratamento extra. Quando uma anfitriã joga em seu próprio país, a simulação aplica um ajuste de mando de campo para essa partida, enquanto o resto do torneio é tratado como terreno neutro.

Com as previsões e as regras definidas, a simulação roda o torneio inteiro 10.000 vezes. Em cada execução, segue este procedimento:

\n
1. Sorteia um placar para cada partida amostrando gols de mandante e visitante das distribuições previstas pelo modelo
\n
2. Disputa a fase de grupos com regras reais de pontos e critérios de desempate
\n
3. Resolve a tabela dos melhores terceiros
\n
4. Preenche o chaveamento do mata-mata a partir dos mapeamentos acima
\n
5. Joga até chegar a um campeão.
\n

Ao longo de 10.000 torneios simulados, a fração de execuções em que uma seleção chega à final ou levanta a taça vira a probabilidade dela. Uma execução é um palpite; dez mil execuções são uma projeção.

Rastreando tudo com MLflow

Cada execução descrita até agora, nos dois modos, é registrada no MLflow (hospedado no DagsHub). O acompanhamento de experimentos significa registrar sistematicamente entradas, configurações, resultados e saídas de cada execução, para que qualquer uma possa ser comparada ou reproduzida exatamente. Alguns pontos que valem destaque:

\n
• Reprodutibilidade. A simulação usa uma semente aleatória fixa derivada da fase do torneio, compartilhada entre os modos congelado e por rodada. Assim, qualquer diferença entre os dois vem dos modelos, não da sorte do sorteio interno. Cada execução também registra o snapshot exato de dados que viu (número de linhas na Gold e timestamp), permitindo rastrear os resultados até suas entradas.
\n
• O experimento. Cada execução é marcada com seu modo (congelado ou por rodada) e seu estágio no ciclo de vida, do experimental e QA até inferência ao vivo e re-treino, espelhando o fluxo de promoção da seção anterior.
\n
• Comparação. O RPS do holdout é logado como métrica de seleção, junto com uma referência à execução campeã atual para linhagem. O tempo de ajuste também é registrado — é onde aparece, preto no branco, o treino ~100x mais lento do modelo bayesiano.
\n

Os modelos treinados e os próprios arquivos de previsão (probabilidades do torneio, classificações dos grupos e previsões de partidas) são armazenados como artefatos das execuções — e são exatamente esses arquivos que o dashboard ao vivo lê. Isso fecha o ciclo: de resultados brutos, passando por treino e simulação, até os números que você vê online.

Monitorando drift

A última peça roda quando as partidas terminam. À medida que chegam os resultados reais, as previsões feitas para eles são avaliadas e comparadas ao baseline simples de taxa média. Se os modelos completos começarem a perder terreno para um modelo que nada sabe sobre as equipes, é um sinal de drift: os padrões aprendidos antes do torneio podem não bater mais com o que acontece em campo.

Acompanhar isso é prática padrão em qualquer sistema com previsões ao vivo, e você pode ler mais sobre como é detectado neste guia sobre data drift e model drift.

Então, quem ganha a Copa?

Depois de toda essa engenharia, é para isso que ela serve.

Os favoritos

Em 10 de junho de 2026, véspera do jogo de abertura, o veredito do modelo é claro no topo e embolado logo atrás. Espanha e Argentina lideram, cada uma com cerca de 16% de chance de levantar a taça. Ver as atuais campeãs do mundo (Argentina) e da Europa (Espanha) no topo é um bom teste de sanidade: o modelo está ancorado na realidade.

Logo atrás vem um pelotão forte e próximo: França, Inglaterra, Brasil e Colômbia completam a lista dos mais prováveis campeões. Esses números são ao vivo e mudam assim que os resultados reais começam a sair — encare-os como um retrato do dia 10 de junho, não uma profecia fixa. O dashboard sempre mostra os números atuais, com atraso máximo de duas horas.

O dashboard ao vivo

Falando nisso: todo número deste artigo vem de um app ao vivo em Streamlit que atualiza automaticamente conforme o pipeline roda. Você pode abrir em wc2026-predictions.streamlit.app e acompanhar o torneio. Ele tem quatro visões principais:

\n
• Panorama do torneio: até onde cada seleção deve chegar, de relance.
\n
• Classificação dos grupos: em cada grupo, a probabilidade de cada equipe terminar em primeiro, segundo, terceiro (separando terceiro-classificado de terceiro-eliminado, por causa da regra dos melhores terceiros) ou quarto.
\n
• Previsões de partidas: em cada jogo da fase de grupos, a chance de vitória do mandante, empate ou vitória do visitante, além do chaveamento mais provável no mata-mata.
\n
• Confrontos mais comuns no mata-mata: os pareamentos que a simulação produz com mais frequência.
\n

Um detalhe na visão de partidas: algumas seleções aparecem em dois possíveis slots nas oitavas de 32 ao mesmo tempo. Não é bug. Acontece quando um grupo é tão equilibrado que o modelo não consegue apontar com confiança qual posição a equipe vai ocupar. Somado à incerteza dos melhores terceiros, os dois desfechos levam a slots diferentes no mata-mata. No caso da Turquia, isso até a colocou duas vezes nas oitavas.

A imagem a seguir mostra as fases finais (quartas até a final) projetadas pelo XGBoost antes do pontapé inicial do torneio:

O time “cara ou coroa”: Estados Unidos

A graça de um modelo como este está nas seleções que contrariam o olho, e o exemplo mais claro são os Estados Unidos. Se você for ao panorama do torneio no dashboard, vai notar que os EUA se destacam na cor.

Como coanfitriões jogando em casa, você poderia esperar um começo tranquilo, mas o modelo é bem mais cauteloso: dá apenas cerca de 54,6% de chance de passarem do grupo, a 13ª menor do torneio inteiro (lembre que dois terços dos times avançam!), porque o grupo com Austrália, Paraguai e Turquia é incomumente equilibrado.

O interessante é o que vem depois. Se avançarem no sufoco, os EUA ficam perto de um cara ou coroa em quase todas as fases seguintes. Empilhando essas moedas, eles chegam a algo como 2% de chance de título — a 13ª maior entre as 48 seleções.

Um time que é 13º de baixo para cima para sair do grupo e 13º de cima para baixo para ser campeão é praticamente a definição de “cara ou coroa”: nunca favorito, nunca morto.

Considerações finais

Este projeto deu muito trabalho e cobre bem mais coisa do que cabe em um artigo. O repo tem bastante do que ficou de fora: o conjunto completo de modelos candidatos, a engenharia de features e a orquestração que mantém tudo rodando, para citar alguns exemplos.

Por ora, o modelo fez suas apostas e o torneio vai julgar. Seja pelo MLOps ou pelo futebol, espero que você curta acompanhar tanto quanto eu. Você pode seguir a previsão ao vivo conforme os jogos acontecem e ver como as projeções se sustentam.

Se quiser se aprofundar em alguns dos conceitos que citei, recomendo nosso curso MLOps Concepts.