O que este post constrói

O resultado da primeira etapa não é um modelo chamativo, e sim uma folha de projeto de uma página. Uma IA de go precisa de um modelo que recomenda jogadas, um motor que julga as regras, um servidor que salva as partidas e uma tela onde o usuário coloca as pedras, tudo funcionando junto. Se você treinar o modelo antes de definir esses limites, é fácil confundir jogadas ilegais e erros de salvamento com problemas de desempenho do modelo.

  1. Usar um tabuleiro padrão de 19×19.
  2. O humano joga com as pretas e a IA com as brancas.
  3. Não há limite de tempo para as jogadas do humano.
  4. O motor de regras verifica de novo a resposta do modelo.
  5. O tabuleiro e a sequência de jogadas são salvos no servidor a cada jogada.

Etapa 1: Separar o modelo do motor de regras

A responsabilidade do modelo vai até olhar o tabuleiro atual e propor coordenadas candidatas para a próxima jogada. Se o ponto está vazio, se é suicídio ou se é um ko que repete o tabuleiro anterior, quem decide é o motor de regras. Se o modelo responder um ponto que já tem uma pedra, o candidato é recusado e o modelo é consultado de novo. Se a nova tentativa também falhar, não trocamos por uma jogada aleatória; registramos o erro.

Essa separação é importante por causa da reprodutibilidade. Quando surge um problema em um mesmo tabuleiro, dá para verificar separadamente se o modelo escolheu mal ou se o código das regras estava errado. As regras ficam fixadas com testes, e o modelo continua sendo uma peça substituível.

Etapa 2: Definir o estado da partida como um único objeto

O estado mínimo contém o tabuleiro 19×19, de quem é a vez, o número de pedras capturadas, o ponto proibido por ko, a sequência completa de jogadas e o horário do último salvamento. Não tente reconstruir o estado só olhando a tela; o servidor deve guardar o original. Para continuar a mesma partida depois de abrir o navegador de novo, também são necessários um código da partida e uma chave de acesso.

Etapa 3: Escrever a condição de conclusão

A condição de conclusão da primeira versão não é "uma IA forte". Basta que o humano consiga fazer jogadas legais, que as respostas ilegais da IA sejam recusadas, que a sequência de jogadas sobreviva a uma atualização da página e que dois passes seguidos encerrem a partida. Só depois de passar por esse critério você deve melhorar os dados de treinamento e a força de jogo, para poder rastrear a causa de cada problema um de cada vez.

O próximo post explica como dividir o registro SGF de uma partida em entradas de treinamento e coordenadas corretas.

O código real desta etapa

A partida na web do MariaGO salva no servidor o "estado da partida como um único objeto" da etapa 2 com o tipo GameRow abaixo. O tabuleiro, o próximo jogador, o ponto de ko, as pedras capturadas, o número de passes consecutivos e a sequência completa de jogadas ficam em uma única linha, junto com uma chave de acesso para continuar a partida em outro dispositivo.

mariago-web/lib/gameTypes.tstypescript · 32 linhas
export type MoveRec = {
  ply: number;
  color: 1 | 2;
  pass?: boolean;
  r?: number;
  c?: number;
};

export type GameWinner = "black" | "white" | "draw";

export type GameRow = {
  code: string;
  guest_id: string;
  /** 비공개 키 — 다른 기기 이어두기용. 남에게 코드만 공유하면 안 됨 */
  access_key: string;
  board: number[];
  to_play: number;
  ko: { r: number; c: number } | null;
  last_move: { r: number; c: number } | null;
  move_no: number;
  cap_b: number;
  cap_w: number;
  pass_streak: number;
  epoch: number;
  started: boolean;
  status: "playing" | "ended";
  end_text: string | null;
  winner: GameWinner | null;
  moves: MoveRec[];
  created_at: string;
  updated_at: string;
};

Modelo usado: Qwen3-VL-8B-Instruct + adaptador LoRA (lora_mix_qwen_r5). O código-fonte completo e a descrição do modelo estão no post "8. O código-fonte completo e os modelos usados".