Baduk project note

Go com IA, dos registros de partidas à contagem

O modelo ainda não tem memória

A cada jogada, o modelo olha apenas o tabuleiro como ele está naquele momento. Ele não lembra quais pedras foram capturadas alguns lances antes, onde surgiu um ko nem quais regras foram combinadas no início. Por isso, às vezes ele propõe um ponto já ocupado, um suicídio ou retomar um ko logo depois de ele ter sido tomado.

Por enquanto, o motor de regras da web preenche essa lacuna. Se a coordenada escolhida pelo modelo quebra as regras, ela vai para uma lista de rejeição e o modelo é consultado de novo; se mesmo assim não vier uma jogada legal, o erro é mostrado como está. Nunca trocamos discretamente por uma jogada aleatória.

Todas as jogadas de uma partida ficam registradas no servidor. Mas o modelo não lê esse registro antes de jogar. Anotar algo num caderno é diferente de se lembrar disso.

Isso não quer dizer que pretendemos deixar a memória por conta de um único modelo. Pesquisas mostrando que RAG e um LLM sozinhos não resolvem esse tipo de problema aparecem com bastante frequência. Por isso, estamos tentando construir a memória dividindo papéis entre vários motores.

  • Jogadas que nunca são permitidas, como retomar um ko imediatamente ou o suicídio, são bloqueadas pelo motor de regras. Mesmo que estejam escritas no prompt, o modelo pode ignorá-las. Esta parte já funciona hoje.
  • O que pode ser recalculado a partir do tabuleiro e da sequência de lances, como escadas, dame e formas capazes de fazer dois olhos, é calculado do zero a cada jogada por um motor de análise. Qualquer coisa memorizada ficaria desatualizada assim que o tabuleiro mudasse.
  • Só o que não aparece no tabuleiro, como as regras combinadas no início, os planos em andamento e os erros anteriores, é registrado como evento. Cada evento tem a jogada em que surgiu e o momento em que expira, e logo antes da consulta somente os eventos relevantes para o tabuleiro atual entram no prompt.
  • As mesmas anotações também são anexadas aos dados de treino. Um modelo que nunca viu um tabuleiro com anotações não consegue aproveitá-las direito durante uma partida.

Completar essa estrutura é a lição de casa que o MariaGO ainda precisa terminar.

O go do MariaGO em resumo

Tabuleiro padrão 19×19 · humano de pretas / IA de brancas · sem limite de tempo por jogada · todas as jogadas salvas automaticamente · navegação para frente e para trás no registro · continuação a partir de qualquer lance · contagem manual e por passe duplo.

Julgamento mais seguro de escadas e bocas de tigre

Em 28 de setembro de 2026, corrigimos dois casos em que a IA escolhia sem mais nem menos uma jogada taticamente desvantajosa. A coordenada proposta pelo modelo é verificada de novo com base nas pedras e liberdades do tabuleiro e, se for uma fuga inútil de uma pedra presa numa escada ou uma entrada numa boca de tigre onde seria capturada na hora, outra jogada legal é escolhida.

Escadas: evitando fugas inúteis e passes precipitados

Seguimos a sequência para ler se uma pedra em atari, depois de fugir um ponto, é perseguida por ataris sucessivos e acaba capturada. Se não houver quebra-escada e ela não conseguir escapar, essa fuga é retirada dos candidatos. Também impedimos que a IA passasse para evitar uma escada quando ainda havia lugares para jogar, de modo que ela escolha outra jogada legal no tabuleiro.

Bocas de tigre: saber quando entrar e quando preencher

A IA não entra numa boca de tigre cercada por pedras adversárias em três lados, onde ficaria em atari logo depois de jogar. Ela também evita preencher sem motivo especial uma boca de tigre formada pelas próprias pedras. Porém, se essa jogada capturar pedras adversárias ou se pedras aliadas próximas estiverem com poucas liberdades, ela pode ser a tática necessária, então continua como candidata normal.

Alcance atual

Essas correções se aplicam à etapa final de escolha da jogada da IA. Não se trata de uma leitura geral que resolve perfeitamente toda escada ou problema de vida e morte, e continuamos registrando e corrigindo as exceções encontradas em partidas reais.

Registro de desenvolvimento, setembro de 2026

Resolvemos em sequência problemas encontrados em partidas reais, envolvendo passes, jogadas ilegais e escolhas táticas, e adicionamos graduações por usuário. As mudanças abaixo são independentes do desempenho de treino do próprio modelo; elas se aplicam às regras do servidor e da web que verificam as respostas do modelo e conduzem as partidas.

Chega de passes precipitados numa partida ainda em andamento

Se ainda restarem áreas vazias e lutas não resolvidas suficientes, um passe respondido pelo modelo não é aceito de imediato; os candidatos legais urgentes são avaliados de novo. Por outro lado, um passe final quando o tabuleiro está realmente definido e não há mais nada que valha a pena jogar é permitido, e é diferenciado de um encerramento normal por passe duplo.

Riscos de atari duplo e de corte incluídos na avaliação de candidatos

Verificamos formas em que as pedras estão ligadas apenas na diagonal, de modo que, se o adversário cortar no meio, um dos dois grupos fica em atari. Avanços que permitem ao adversário criar um atari duplo na jogada seguinte são penalizados, e jogadas que conectam pedras fracas ou as salvam primeiro têm prioridade.

Ko e captura após preenchimento diferenciados pela forma atual do tabuleiro

Corrigimos um problema em que uma coordenada rejeitada uma vez continuava proibida em todas as jogadas seguintes. Uma coordenada proibida agora vale apenas para o tabuleiro e a vez atuais, e quando pedras são capturadas e a forma do tabuleiro muda, a legalidade é calculada de novo. Assim, um ko que recaptura imediatamente para recriar o mesmo tabuleiro é bloqueado, mas uma jogada legal num ponto que se abriu depois de preencher uma liberdade e capturar é permitida.

Graduações e histórico geral por ID de cliente

Mesmo usuários que não fizeram login têm suas vitórias, derrotas, empates e total de partidas salvos com base no ID de cliente do navegador. Os resultados das partidas são processados numa transação para que o mesmo resultado nunca seja contado duas vezes.

Graduação atualRegra de promoção / rebaixamento
18 kyu – 11 kyuPromoção com +3 pontos, rebaixamento com −3
10 kyu – 5 kyuPromoção com +5 pontos, rebaixamento com −5
4 kyu – 1 kyuPromoção com +10 pontos, rebaixamento com −10
DanPromoção com +15 pontos, rebaixamento com −15

Na promoção ou no rebaixamento, os pontos daquela faixa voltam a 0, e você nunca cai abaixo de 18 kyu. Empates não alteram os pontos e são apenas registrados no histórico geral.

Menos pedras espalhadas no centro pela heurística de avaliação

O antigo adversário de avaliação tendia a espalhar pedras escolhendo aleatoriamente candidatos perto do centro sempre que não havia nada para capturar. Nós o substituímos por uma pontuação que combina aberturas de canto na terceira e quarta linhas, capturas, fuga de atari, conexões, pressão sobre as pedras fracas do adversário e evitar o autoatari. O MIX R5 venceu as três primeiras partidas, mas a média de capturas do R5 até a jogada 80 caiu de 5,98 nas últimas 100 partidas anteriores para 3,0.

Como ler os resultados da avaliação

As partidas com heurística são atualmente interrompidas na jogada 80 e recebem uma contagem provisória, então não podem ser lidas como taxa de vitórias ou graduação oficiais. Uma diferença de força precisa exige uma avaliação longa à parte, com partidas completas alternando as cores e avaliação de vida e morte.

A heurística, o R5 e o Gemma 4 foram registrados separadamente

Em 9 de outubro de 2026, as partidas em que uma função de pontuação escolhia o lance foram separadas daquelas em que o modelo jogava sozinho. Em cinco partidas sem limite, a heurística de pretas venceu uma e o R5 de brancas venceu quatro; todas terminaram com dois passes. Gemma 4 contra R5 não foi um duelo entre modelos: quase todos os lances foram reescolhidos pela função de pontuação. Depois o Gemma 4 aprendeu os lances da heurística e, com essa função desligada, perdeu três partidas. O KataGo deu às pretas 76,2, 74,0 e 69,7 pontos. Na tela escolhe-se Gemma 4, IA local ou R5. A IA local é a heurística, e a escolha fica só nesse navegador.

Como ensinamos as coordenadas 19×19 à IA

Os dados de treino partem de registros SGF jogados por amadores fortes e profissionais. Em vez de decorar partidas inteiras, formamos pares com o tabuleiro logo antes de cada jogada e a próxima jogada real. Registros dos vencedores têm preferência, posições que exigem julgamento tático, como atari, são incluídas com mais frequência, e duplicatas são removidas para que o mesmo tabuleiro não se repita.

Nos primeiros experimentos, o modelo repetia sem parar coordenadas no canto inferior direito do tabuleiro. Os tabuleiros de treino tinham números, mas o espaçamento e o alinhamento eram diferentes dos do servidor de partidas reais, e o modelo lia errado tudo a partir da coluna 10, onde começam os números de coluna com dois dígitos. Não era um caso de “poucos registros de partidas”, e sim de formatos de entrada incompatíveis entre o treino e o jogo.

Hoje a mesma grade alinhada, com linhas e colunas em dois dígitos de 00 a 18, é usada tanto no treino quanto no jogo. Antes do treino principal, fazemos um teste de coordenadas em que o modelo precisa encontrar pedras colocadas aleatoriamente, e observamos separadamente a precisão dos quatro quadrantes: superior esquerdo, superior direito, inferior esquerdo e inferior direito. Mesmo que a média geral seja boa, se o modelo desmorona num canto, isso vira um viés de direção nas partidas reais.

EntradaUm tabuleiro 19×19 com linhas e colunas 00–18 alinhadas, mais as condições atuais da partida
AlvoA coordenada da próxima jogada, ou um passe, escolhida no registro real
TreinoPadrões de escolha de jogadas de go adicionados a um modelo base com LoRA
ValidaçãoObservação do reconhecimento de coordenadas, jogadas legais, viés de direção, passes precoces e preenchimento do próprio território

Por isso, a IA do MariaGO não é uma máquina de respostas pronta. Ela aprendeu as escolhas dos registros de partidas, mas em posições desconhecidas pode fazer jogadas ruins ou indicar coordenadas ilegais. Guardar essas falhas nos logs de partidas e corrigir o próximo conjunto de dados e as verificações de regras é uma parte importante do projeto.

Jogadas seguras e sem limite de tempo

Usamos jogadas em duas etapas para que um toque errado numa tela pequena de celular não seja confirmado. Toque uma vez numa interseção vazia e aparece uma pedra dourada de pré-visualização. Só quando você toca de novo no mesmo ponto ou aperta o botão “Jogar” na tela a jogada é salva no servidor e a vez passa para a IA. Tocar em outro ponto apenas move a pré-visualização.

Não há byo-yomi nem limite de tempo na vez do humano. Deixar a tela aberta por muito tempo não causa um passe automático. Enquanto a IA calcula a jogada, a entrada fica pausada por um instante para evitar requisições duplicadas, e o tempo de resposta pode variar conforme as condições da rede.

Não precisa ter pressa. Escolha uma jogada, confira a posição marcada e depois confirme. Jogadas que as regras não permitem, como suicídio ou ko, são explicadas na etapa de confirmação.

Registros de partidas servem para mais do que guardar um histórico

Quando você começa uma partida, são criados um código de partida de seis caracteres e uma chave de acesso. A cada jogada, o tabuleiro, o próximo jogador, as pedras capturadas, o ponto de ko e a sequência completa de lances são salvos no banco de dados do servidor. No mesmo navegador, a partida em andamento mais recente é carregada sem nenhuma busca, e na tela de registros você pode ver as partidas anteriores com o horário e o número de lances.

Durante a partida, você pode usar as setas de voltar e avançar para revisar posições passadas sem alterar o lance atual. Voltando ao último lance, a partida original continua. Se você escolher “Continuar daqui” enquanto olha um lance passado, os lances seguintes são descartados e uma nova variação começa a partir daquela posição. Isso une, numa só tela, a revisão de uma partida real e a exploração de variações hipotéticas.

Os dados salvos são protegidos por um identificador temporário do navegador e por uma chave de acesso. Saber só o código da partida não permite abrir o tabuleiro de outra pessoa, e para continuar em outro dispositivo você precisa de um link que inclua a chave de acesso. Limpar os dados do navegador pode fazer o dispositivo esquecer o identificador, então é mais seguro guardar em outro lugar os links das partidas importantes em andamento.

O que a contagem automática conta e o que ela deixa passar

Quando os dois lados passam em seguida ou o usuário aperta “Contar”, o MariaGO calcula uma pontuação de referência próxima da contagem de território coreana. Ele explora as áreas vazias: se a borda de uma área é formada só por pedras pretas, ela conta como território das pretas, e se só por pedras brancas, como das brancas. As pedras adversárias capturadas são somadas, e 6,5 pontos de komi são acrescentados às brancas antes de a diferença ser exibida.

A parte difícil não é contar os pontos vazios, e sim identificar as pedras mortas no tabuleiro. As pessoas concordam que grupos sem dois olhos ou pedras que não têm como escapar da captura estão mortos e os retiram, mas a contagem automática atual não julga completamente vida e morte. Se pedras mortas ficarem no tabuleiro, as bordas das áreas vizinhas se misturam, e elas podem não contar como território ou podem gerar um valor diferente do resultado real.

Por isso, a contagem no meio da partida é uma ferramenta para ter uma ideia aproximada da situação, e o resultado final também não deve ser tomado como veredito oficial de um árbitro. Principalmente quando ainda restam grandes jogadas de finalização ou quando pedras dos dois jogadores estão misturadas numa mesma área, há mais pontos neutros que não são contados. Nesse caso, conferir o próprio tabuleiro importa mais do que o número.

Como ler a pontuação

Pontuação das pretas = território cercado pelas pretas + pedras brancas capturadas. Pontuação das brancas = território cercado pelas brancas + pedras pretas capturadas + 6,5 de komi. A avaliação automática de vida e morte ainda não é suportada, então, se restarem pedras mortas no fim da partida, use a pontuação apenas como referência.

Antes de começar uma partida

  • As partidas web são jogadas num tabuleiro 19×19, com o humano de pretas e a IA de brancas.
  • Toque uma vez num ponto vazio, confira a pré-visualização e toque de novo para confirmar.
  • Não há limite de tempo para suas jogadas, e a sequência de lances é salva a cada jogada.
  • Reconecte-se no mesmo navegador e você poderá continuar automaticamente sua partida mais recente.
  • A contagem automática é um recurso de referência que não julga completamente vida e morte.