IA nos Projetos

Objetivo (com transparência)

Loterias são eventos aleatórios: não existe “garantia” e não prometemos acertos. Nosso foco é outro: aplicar engenharia de dados e um modelo de apoio (LSTM) para organizar escolhas, reduzir redundância entre jogos e aumentar a qualidade do conjunto final com regras, validações e rastreabilidade.

Em um bolão, a diferença prática não é “adivinhar o sorteio”, e sim montar um portfólio de apostas com diversidade, governança e menor risco de repetir padrões fracos — algo que “surpresinhas” e aleatoriedade pura não controlam.

Metodologia (fases do script)

O pipeline é dividido em fases, com artefatos e logs a cada etapa — para que tudo seja auditável.

1. Coleta e versionamento do histórico: download do XLS oficial e preservação de versões (evita “dados tortos” e facilita auditoria).
2. Fase 1 — Engenharia de dados (LSTM-ready): validações, ordenação temporal, criação de features e janelas (LOOK_BACK) para prever o próximo concurso.
3. Fase 2/3 — Treino e seleção do modelo: LSTM com atenção, tuning de hiperparâmetros, perdas/ponderações para desbalanceamento e seleção do melhor checkpoint (com logs e métricas).
4. Fase 4 — Geração das apostas: previsão → ranking Top‑N → montagem de subgrupos e aplicação de regras (fixas, blocos, vizinhos, bloqueios, sobreposição) → exportação em CSV e, opcionalmente, Google Sheets.

Fase 1 — Preparação dos dados (o que o modelo “enxerga”)

Para cada concurso, geramos um vetor de entrada com sinais que combinam histórico e tempo:

• One‑hot do sorteio: vetor binário 1..60 marcando as dezenas sorteadas.
• Tempo (cíclico): dia da semana/mês/dia do ano em seno/cosseno, além de delta_days (intervalo entre concursos).
• Recência por dezena: days_since_last_hit e decay = exp(-λ·dias) para modelar “memória” temporal.
• Frequência móvel: janelas (ex.: 10 e 20 concursos) mantidas por deque (eficiente) para gerar freq_last_w.
• Fusion em log‑space (por concurso): combina frequência e decaimento com normalização e checagens de sanidade (NaN/inf/clipping), reduzindo instabilidade numérica.
• Janelas temporais (LOOK_BACK): empilha N concursos passados para prever o próximo (split treino/validação por tempo, sem embaralhar).
• Estabilização opcional: normalização (minmax/z‑score), label smoothing e class weights (desbalanceamento por dezena).

Saídas da fase: X_train/X_val/y_train/y_val (NPY) + fase1_output.json com schema, parâmetros e logs.

Fase 2/3 — Construção do modelo (LSTM + Atenção)

O modelo é multi‑rótulo: ele produz uma probabilidade para cada dezena (1..60), com saída sigmoid (não “escolhe” um único número).

• Arquitetura típica: LSTM(256, return_sequences=True) → Dropout → LSTM(128) → Attention → Pooling → Dense(60, sigmoid).
• Desbalanceamento: Focal Loss (e/ou versão ponderada por class weights) para não “viciar” em dezenas muito frequentes.
• Tuning e seleção: Keras Tuner (Bayesian Optimization), early stopping, checkpoints e escolha do melhor modelo pelo conjunto de validação temporal.
• Métricas orientadas ao uso: além de loss/AUC, métricas do tipo “acertos médios em Top‑6” e percentuais de ≥3/≥4 acertos em Top‑6 (monitoramento realista do objetivo).
• Otimização opcional: magnitude pruning / “winning ticket” para reduzir complexidade e melhorar estabilidade/eficiência de inferência.

Saída da fase: um checkpoint .keras que a Fase 4 consome diretamente.

Fase 4 — Estratégias de geração de sequências (com regras)

Em vez de “uma aposta”, geramos um conjunto grande com diversidade controlada. As principais estratégias são:

• Top‑N + amostragem ponderada: seleciona um pool (ex.: Top‑35/Top‑45) e amostra sem reposição, com pesos pelas probabilidades do modelo.
• Pool por blocos: divide 1..60 em blocos de 10 e pega as melhores de cada bloco (equilíbrio entre faixas).
• Subgrupos e fixas: configura lotes com fixas manuais ou automáticas (Top‑N), evitando colisões entre subgrupos.
• Vizinhos em grade 6×10: aplica substituições controladas em torno de dezenas do sorteio de referência (lag), aceitando apenas trocas que preservam a qualidade e não degradam demais o score.
• FFT por blocos (opcional): extrai um score temporal por dezena e combina com o score logarítmico do modelo (log_prob + λ·fft_score).
• Integrações: leitura de exclusões/preexistentes via planilha e geração adicional por “Estratégia B” (quando habilitado) para compor apostas reais do bolão.

Ao final, exportamos CSV unificado e logs detalhados; opcionalmente, sincronizamos com Google Sheets para conferência e autopreenchimento.

Regras de qualidade (o “filtro”)

• Semelhança controlada: limite de sobreposição entre jogos do mesmo conjunto (evita “quase duplicatas”).
• Histórico protegido: rejeita jogos excessivamente parecidos com concursos anteriores (ex.: 5+ dezenas iguais em um jogo de 6).
• Exclusões e bloqueios: impede sequências já usadas/proibidas (inclusive via planilhas) e pode aplicar bloqueios hierárquicos quando há tamanhos diferentes.
• Rastreabilidade: cada decisão deixa trilha (parâmetros, seeds, logs e arquivos gerados).

Exemplo prático (Mega‑Sena)

Suponha que o bolão precise de 120 jogos de 6 dezenas. A Fase 4 faz, em alto nível:

1. Carrega o modelo .keras e gera a previsão para o próximo concurso (probabilidade por dezena).
2. Define um pool Top‑N (por exemplo Top‑35) e cria subgrupos com políticas de fixas (ex.: uma fixa Top‑N exclusiva por lote).
3. Gera jogos por amostragem ponderada e/ou por blocos, aplica “vizinhos” (grade 6×10) quando configurado.
4. Rejeita candidatos que violam regras (histórico, sobreposição, exclusões) até fechar a quantidade.
5. Exporta um CSV unificado e registra tudo em log (incluindo fixas, vizinhos aplicados e motivos de rejeição).

Resultados e qualidade dos dados

• Fontes confiáveis: histórico validado e modelos acompanhados por logs e auditorias internas.
• Higiene e consistência: limpeza, normalização e checagens automáticas antes de qualquer geração.
• Rastreabilidade: cada rodada deixa trilha de execução para conferência e reprodutibilidade.
• Organização clara: saídas estruturadas em planilhas/CSVs, fáceis de consultar e auditar.

Por que isso importa

Não é “mágica” nem promessa de acerto. É engenharia aplicada: modelo + regras + validações que buscam consistência na alocação das apostas, com transparência e reprodutibilidade.

• Diversidade com controle: evita jogar “muitas vezes o mesmo jogo” (alto overlap) e melhora cobertura do espaço de combinações dentro do orçamento.
• Menos erro humano: regras automáticas reduzem duplicações, inconsistências e esquecimentos na montagem manual.
• Melhor governança: tudo é rastreável (versões de dados/modelo, logs, parâmetros e arquivos gerados).
• Qualidade operacional: integração com planilhas e exportações padronizadas para conferência rápida.
• Honestidade estatística: o método não “quebra” a loteria; ele disciplina a construção do conjunto de apostas e evita aleatoriedade sem controle.

Em resumo: não prometemos resultados, mas entregamos um processo mais profissional do que “surpresinhas” — com dados oficiais, modelo de apoio, filtros de qualidade e rastreabilidade.