Como o motor calcula as probabilidades.

A unidade básica do modelo é uma estimativa de quantos gols cada time vai fazer naquele jogo específico — chamamos isso de lambda (λ). Essa estimativa é montada em três etapas:

1. Força ofensiva e defensiva: mistura 70% de xG médio com 30% de gols médios reais dos últimos jogos. xG é o sinal preferido porque captura qualidade de chance independente de sorte.
2. Ajustes contextuais: mando (+18% ataque, −12% defesa para mandante), descanso (−5% se ≤2 dias, +2% se ≥6), ausências (cada titular fora reduz força até 6%, com cap em −25%) e a tendência pró-mandante do árbitro escalado.
3. Lambda final: força ofensiva ajustada × vulnerabilidade defensiva do oponente, normalizado pela média de gols do Brasileirão (~2.42 por jogo).

Com os dois lambdas em mãos, calculamos a probabilidade de cada placar usando a distribuição de Poisson: P(k gols) = e^−λ · λ^k ÷ k!. A matriz 8×8 de placares (até 7×7) dá probabilidade conjunta de todos os resultados, e a partir dela derivamos os mercados — 1X2, dupla chance, over/under, ambas marcam, etc.

Por que Poisson e não machine learning? O Brasileirão tem ~380 jogos por temporada. Em 5 temporadas, ~1.900 jogos — não dá pra treinar deep learning sem overfit. Poisson com xG ajustado é o estado-da-arte prático pra esse volume e tem três vantagens decisivas: custo zero, comportamento determinístico (mesmo input dá mesmo output, sempre) e explicabilidade total. Sempre dá pra dizer por que uma probabilidade é o que é.

Nem todo jogo merece bilhete sugerido. Pelo contrário — o filtro é severo, e quando ele falha, o produto fica em silêncio. Silêncio é uma resposta válida.

Pra uma perna entrar no bilhete sugerido, ela precisa atender simultaneamente:

• Probabilidade calculada > 60%
• Expected Value (probabilidade × odd de referência − 1) > 4%
• Confiança histórica do mercado > 60%
• Não conflita com outra perna do mesmo bilhete (mesmo jogo + mesmo mercado)

Quando há múltiplos candidatos, o motor escolhe o de maior (Expected Value × probabilidade). Bilhete combinado de rodada agrega até 3 pernas independentes — exige no mínimo 2 cenários favoráveis pra existir.

O texto que explica a análise é gerado por um sistema de templates contextuais: frases pré-escritas que o motor encaixa a partir dos números do jogo. Não usamos modelo de linguagem (LLM) no MVP — a decisão é deliberada.

• Custo zero por bilhete (paga só servidor)
• Determinismo: mesmo input gera mesma narrativa, sempre
• Zero alucinação (sem inventar fato)
• Sem dependência de preço de API externa

LLM (Claude Haiku) pode entrar em Fase 3 como camada premium opcional, gerando texto mais elaborado — mas o produto inteiro funciona sem isso.

Um modelo só é confiável se for medido. Toda vez que o motor diz "64% de probabilidade" e o jogo termina, esse acerto/erro entra no contador. No final, o que importa é a calibração: das vezes que o sistema disse X%, ele acertou de verdade X%?

Isso é mostrado em tempo real na página /histórico — sem cherry-picking, sem soft delete. Se o modelo está superestimando consistentemente algum mercado (ex: "ambas marcam"), aparece no desvio e a gente ajusta.

Esta é a v1 do motor. Sabemos das limitações:

• Independência entre gols. O modelo assume que os gols do mandante e os do visitante são independentes — Dixon-Coles (1997) ajustaria placares baixos (0-0, 1-1) que tendem a ser sub-estimados. Entra na v2.
• Tendência por mando do árbitro está em base agregada, sem cruzar com perfil específico dos times. Cruzamento fica na v1.1, quando tivermos massa de dados.
• Clima, gramado, viagem. Não modelamos ainda. Tem evidência marginal de impacto; entra quando tivermos fonte estável.
• Calibração desta versão de demonstração é hipotética. Os números do histórico atual são determinísticos pra renderizar a UI antes de plugar a fonte real.