Go con IA, de los registros de partidas al recuento

El modelo todavía no tiene memoria

En cada jugada, el modelo solo mira el tablero tal como está en ese momento. No recuerda qué piedras se capturaron hace unas jugadas, dónde surgió un ko ni qué reglas se acordaron al principio. Por eso a veces propone un punto que ya está ocupado, un suicidio o retomar un ko justo después de que se haya tomado.

Por ahora, el motor de reglas de la web cubre ese hueco. Si la coordenada que elige el modelo infringe las reglas, se añade a una lista de rechazos y se le vuelve a preguntar; si aun así no devuelve una jugada legal, el error se muestra tal cual. Nunca la sustituimos a escondidas por una jugada aleatoria.

Todas las jugadas de una partida se registran en el servidor. Pero el modelo no lee ese registro antes de jugar. Apuntar algo en un cuaderno no es lo mismo que recordarlo.

Eso no significa que pensemos dejar la memoria en manos de un solo modelo. Con bastante frecuencia aparecen investigaciones que muestran que RAG y un LLM por sí solos no pueden resolver este tipo de problema. Por eso intentamos construir la memoria repartiendo funciones entre varios motores.

• Las jugadas que nunca están permitidas, como retomar un ko de inmediato o el suicidio, las bloquea el motor de reglas. Aunque las escribas en el prompt, el modelo puede ignorarlas. Esta parte ya funciona hoy.
• Lo que se puede volver a calcular a partir del tablero y del orden de jugadas, como las escaleras, los dame y las formas que pueden hacer dos ojos, lo calcula de nuevo un motor de análisis en cada jugada. Cualquier cosa memorizada quedaría desactualizada en cuanto cambiara el tablero.
• Solo lo que no se ve en el tablero, como las reglas acordadas al principio, los planes en curso y los errores anteriores, se registra como eventos. Cada evento tiene la jugada en la que apareció y el momento en que caduca, y justo antes de preguntar solo se incluyen en el prompt los eventos relevantes para el tablero actual.
• Las mismas notas se añaden también a los datos de entrenamiento. Un modelo que nunca ha visto un tablero con notas no puede aprovecharlas bien durante una partida.

Completar esta estructura es la tarea que MariaGO aún tiene pendiente.

Un juicio más seguro de escaleras y bocas de tigre

El 28 de septiembre de 2026 corregimos dos casos en los que la IA elegía tal cual una jugada tácticamente perdedora. La coordenada que propone el modelo se vuelve a comprobar con las piedras y las libertades del tablero, y si se trata de una huida inútil de una piedra atrapada en una escalera o de una entrada en una boca de tigre donde sería capturada de inmediato, se elige otra jugada legal.

Escaleras: evitar huidas inútiles y pases precipitados

Seguimos la secuencia para leer si una piedra en atari, tras escapar un punto, es perseguida con ataris sucesivos y acaba capturada. Si no hay rompedor de escalera y no puede salir, esa huida se elimina de los candidatos. También impedimos que la IA pase para evitar una escalera cuando todavía quedan sitios donde jugar, de modo que elija otra jugada legal en el tablero.

Bocas de tigre: saber cuándo entrar y cuándo rellenar

La IA no entra en una boca de tigre rodeada por tres lados de piedras rivales, donde quedaría en atari nada más jugar. También evita rellenar sin una razón especial una boca de tigre formada por sus propias piedras. Sin embargo, si esa jugada captura piedras rivales o a las piedras propias cercanas les faltan libertades, puede ser la táctica necesaria, así que se mantiene como candidata normal.

Registro de desarrollo, septiembre de 2026

Fuimos resolviendo problemas detectados en partidas reales, relacionados con los pases, las jugadas ilegales y las elecciones tácticas, y añadimos rangos por usuario. Los cambios siguientes son independientes del rendimiento de entrenamiento del propio modelo; se aplican a las reglas del servidor y de la web que comprueban las respuestas del modelo y gestionan las partidas.

Se acabaron los pases precipitados en una partida aún en curso

Si quedan suficientes zonas vacías y combates sin resolver, un pase respondido por el modelo no se acepta de inmediato; se vuelven a evaluar los candidatos legales urgentes. Por el contrario, un pase final cuando el tablero está realmente decidido y no queda nada que valga la pena jugar se permite, y se distingue de un final normal por doble pase.

Riesgos de doble atari y de corte incluidos en la evaluación de candidatos

Comprobamos las formas en las que las piedras solo están conectadas en diagonal, de modo que si el rival corta entre ellas, uno de los dos grupos queda en atari. Se penalizan los avances que permiten al rival crear un doble atari con su siguiente jugada, y se prefieren las jugadas que conectan piedras débiles o las salvan primero.

Ko y captura tras rellenar, diferenciados según la forma actual del tablero

Corregimos un problema por el que una coordenada rechazada una vez quedaba prohibida en todas las jugadas posteriores. Ahora una coordenada prohibida solo se aplica al tablero y al turno actuales, y cuando se capturan piedras y cambia la forma del tablero, la legalidad se vuelve a calcular. Así, se bloquea un ko que recaptura de inmediato para recrear el mismo tablero, pero se permite una jugada legal en un punto que quedó libre tras rellenar una libertad y capturar.

Rangos e historial global por ID de cliente

Incluso los usuarios que no han iniciado sesión tienen sus victorias, derrotas, empates y total de partidas guardados con el ID de cliente de su navegador. Los resultados de las partidas se procesan en una transacción para que el mismo resultado nunca se cuente dos veces.

Al ascender o descender, los puntos de ese tramo se reinician a 0, y nunca se baja de 18 kyu. Los empates no cambian los puntos y solo se anotan en el historial global.

Menos piedras dispersas en el centro por la heurística de evaluación

El antiguo rival de evaluación tendía a dispersar piedras eligiendo al azar candidatos cercanos al centro siempre que no había nada que capturar. Lo sustituimos por una puntuación que combina las aperturas de esquina en la tercera y cuarta línea, las capturas, la salida del atari, las conexiones, la presión sobre las piedras débiles del rival y evitar el autoatari. MIX R5 ganó las tres primeras partidas, pero la media de capturas de R5 hasta la jugada 80 bajó de 5,98 en las 100 partidas anteriores más recientes a 3,0.

La heurística, R5 y Gemma 4 quedaron registradas por separado

El 9 de octubre de 2026 se separaron las partidas en las que una función de puntuación elegía la jugada y aquellas en las que el modelo jugaba solo. En cinco partidas sin límite, la heurística con negras ganó una y R5 con blancas cuatro; todas terminaron con dos pases. Gemma 4 contra R5 no fue un duelo entre modelos: casi todas las jugadas las volvió a elegir la función de puntuación. Después Gemma 4 aprendió las jugadas de la heurística y, con esa función apagada, perdió tres partidas. KataGo dio a las negras 76,2, 74,0 y 69,7 puntos de ventaja. En la pantalla se elige Gemma 4, IA local o R5. La IA local es la heurística y la elección queda solo en ese navegador.

Cómo enseñamos a la IA las coordenadas de 19×19

Los datos de entrenamiento parten de registros SGF jugados por aficionados avanzados y profesionales. En lugar de memorizar partidas enteras, emparejamos el tablero justo antes de cada jugada con la jugada siguiente real. Se prefieren los registros de los ganadores, se incluyen con más frecuencia las posiciones que requieren juicio táctico, como el atari, y se eliminan los duplicados para que no se repita el mismo tablero.

En los primeros experimentos, el modelo repetía una y otra vez coordenadas de la parte inferior derecha del tablero. Los tableros de entrenamiento llevaban números, pero el espaciado y la alineación eran distintos de los del servidor de partidas reales, y el modelo leía mal todo a partir de la columna 10, donde empiezan los números de columna de dos dígitos. No era un caso de “faltan registros de partidas”, sino de formatos de entrada que no coincidían entre el entrenamiento y el juego.

Hoy se usa la misma cuadrícula alineada, con filas y columnas de dos dígitos del 00 al 18, tanto en el entrenamiento como en el juego. Antes del entrenamiento principal hacemos una prueba de coordenadas en la que el modelo tiene que encontrar piedras colocadas al azar, y miramos por separado la precisión de los cuatro cuadrantes: superior izquierdo, superior derecho, inferior izquierdo e inferior derecho. Aunque la media global sea buena, fallar en una esquina se convierte en un sesgo direccional en las partidas reales.

Así que la IA de MariaGO no es una máquina de respuestas terminada. Ha aprendido las elecciones de los registros de partidas, pero en posiciones desconocidas puede hacer malas jugadas o elegir coordenadas ilegales. Guardar estos fallos en los registros de partidas y corregir el siguiente conjunto de datos y las comprobaciones de reglas es una parte importante del proyecto.

Jugadas seguras sin límite de tiempo

Usamos jugadas en dos pasos para que un toque erróneo en la pequeña pantalla de un móvil no quede confirmado. Toca una intersección vacía una vez y aparecerá una piedra dorada de vista previa. Solo cuando vuelves a tocar el mismo punto o pulsas el botón “Jugar” de la pantalla, la jugada se guarda en el servidor y el turno pasa a la IA. Tocar otro punto solo mueve la vista previa.

No hay byo-yomi ni límite de tiempo en el turno de la persona. Dejar la pantalla abierta mucho tiempo no provocará un pase automático. Mientras la IA calcula su jugada, la entrada se pausa brevemente para evitar peticiones duplicadas, y los tiempos de respuesta pueden variar según el estado de la red.

No hay prisa. Elige una jugada, comprueba la posición marcada y luego confírmala. Las jugadas que las reglas no permiten, como el suicidio o el ko, se explican en el paso de confirmación.

Los registros de partidas sirven para más que guardar un historial

Al empezar una partida se crean un código de partida de seis caracteres y una clave de acceso. Con cada jugada, el tablero, el siguiente jugador, las piedras capturadas, el punto de ko y el orden completo de jugadas se guardan en la base de datos del servidor. En el mismo navegador, la partida en curso más reciente se carga sin necesidad de buscarla, y en la pantalla de registros puedes ver las partidas anteriores con su hora y su número de jugadas.

Durante una partida puedes usar las flechas de atrás y adelante para repasar posiciones pasadas sin cambiar la jugada actual. Al volver a la última jugada se continúa la partida original. Si eliges “Continuar desde aquí” mientras miras una jugada pasada, las jugadas posteriores se descartan y empieza una nueva variante desde esa posición. Así se unen en una sola pantalla el repaso de una partida real y la exploración de variantes hipotéticas.

Los datos guardados están protegidos por un identificador temporal del navegador y una clave de acceso. Conocer solo el código de una partida no te permite abrir el tablero de otra persona, y para continuar en otro dispositivo necesitas un enlace que incluya la clave de acceso. Borrar los datos del navegador puede hacer que el dispositivo olvide su identificador, así que es más seguro guardar en otro lugar los enlaces de las partidas importantes en curso.

Qué cuenta el recuento automático y qué se le escapa

Cuando ambos jugadores pasan seguidos o el usuario pulsa “Recuento”, MariaGO calcula una puntuación de referencia cercana al recuento por territorio coreano. Explora las zonas vacías: si el borde de una zona está formado solo por piedras negras, cuenta como territorio de las negras, y si solo por piedras blancas, como territorio de las blancas. Se suman las piedras rivales capturadas y se añaden 6,5 puntos de komi para las blancas antes de mostrar la diferencia.

Lo difícil no es contar los puntos vacíos, sino identificar las piedras muertas del tablero. Las personas acuerdan que los grupos sin dos ojos o las piedras que no pueden evitar la captura están muertos y los retiran, pero el recuento automático actual no juzga por completo la vida y muerte. Si quedan piedras muertas en el tablero, los bordes de las zonas cercanas se mezclan, de modo que pueden no contar como territorio o dar un valor distinto del resultado real.

Por eso, el recuento a mitad de partida es una herramienta para hacerse una idea aproximada de la posición, y tampoco el resultado final debe tomarse como el veredicto oficial de un árbitro. Sobre todo cuando quedan grandes jugadas de final o las piedras de ambos jugadores están mezcladas dentro de una misma zona, hay más puntos neutrales que no se cuentan. En ese caso, comprobar el propio tablero importa más que la cifra.

Antes de empezar una partida

• Las partidas web se juegan en un tablero de 19×19, con la persona con negras y la IA con blancas.
• Toca un punto vacío una vez, comprueba la vista previa y vuelve a tocar para confirmar.
• No hay límite de tiempo para tus jugadas, y el orden de jugadas se guarda con cada jugada.
• Si vuelves a conectarte desde el mismo navegador, puedes continuar automáticamente tu partida más reciente.
• El recuento automático es una función de referencia que no juzga por completo la vida y muerte.