Guia de AlphaGeometry DSL: DSL geometrico de Google, acciones en defs.txt y predicados

Este articulo se centra solo en AlphaGeometry DSL. No cubre entrenamiento de modelos, estrategias de busqueda ni resultados del paper.

El objetivo es tratar este DSL como un documento de protocolo orientado a ingenieria y responder cuatro preguntas:

• Como se codifica la entrada del problema
• Como se definen las acciones en defs.txt
• Como se mapean las relaciones geometricas a predicados
• Como se conectan la construccion numerica y el razonamiento simbolico

Si quieres reproducir AlphaGeometry, construir un generador de datos geometricos o disenar una capa de compatibilidad para un solver propio, entender el protocolo DSL es un requisito previo.

1. Rol del DSL

AlphaGeometry DSL es un lenguaje especifico de dominio para construccion geometrica y expresion de relaciones. Cumple principalmente 3 funciones:

• Expresar las premisas geometricas iniciales
• Expresar acciones de construccion ejecutables
• Expresar objetivos geometricos que deben verificarse

Su salida no es un texto final de demostracion, sino un conjunto de relaciones geometricas que puede consumir un motor de razonamiento.

Desde la perspectiva de implementacion, el DSL se parece mas a una representacion intermedia:

• Hacia arriba, conecta con descripciones de problemas o generadores de datos
• En el medio, conecta con definiciones de acciones y expansion de relaciones
• Hacia abajo, conecta con rules.txt y el razonamiento DDAR

El centro del protocolo no es el dibujo del diagrama, sino la generacion de relaciones.

2. Estructura del archivo de problema

Un problema completo suele escribirse como:

problem_name
premises ? goal

Ejemplo:

orthocenter
a b c = triangle;
h = on_tline b a c, on_tline c a b
? perp a h b c

Puede descomponerse en 3 secciones:

1. a b c = triangle; Premisas iniciales y objetos libres
2. h = on_tline b a c, on_tline c a b Construccion basada en objetos conocidos
3. ? perp a h b c Predicado objetivo

Este fragmento DSL no es una solucion en lenguaje natural. Es un programa geometrico:

Premises
  -> constructions
  -> predicate graph
  -> goal checking

Despues del analisis, el sistema normalmente necesita producir:

• Una tabla inicial de objetos
• Una secuencia de invocaciones de acciones
• Un conjunto inicial de predicados
• Un objetivo por verificar

3. Convenciones basicas de sintaxis

La forma central de expresion del DSL es:

output = action(parameters)

Ejemplo:

h = on_tline b a c, on_tline c a b

Esto significa que el punto h satisface dos restricciones de construccion al mismo tiempo:

• Trazar una recta por b perpendicular a ac
• Trazar una recta por c perpendicular a ab

Por lo tanto, h es la interseccion de esas dos rectas perpendiculares.

Este estilo tiene dos propiedades principales:

• Las variables de salida se representan de forma uniforme como variables de punto
• Los objetos geometricos se representan implicitamente mediante conjuntos de puntos en lugar de tipos de objeto independientes

Por ejemplo:

line a b
circle o a

• line a b denota la recta definida por los puntos a y b
• circle o a denota el circulo con centro en o que pasa por a

Este diseno simplifica el parser y la estructura del grafo de relaciones, pero exige que el sistema de predicados sea lo bastante expresivo para cubrir la semantica de alto nivel de rectas, circulos y angulos.

4. Estructura de definicion de acciones en defs.txt

defs.txt es el registro de acciones. Cada accion suele contener 5 partes:

action_name outputs inputs

variable dependency

input conditions

geometric constraints

numerical constructions

Ejemplo:

midpoint x a b
x : a b
a b = diff a b
x : coll x a b, cong x a x b
midp a b

La funcion de cada parte es la siguiente.

1. Firma de la accion

midpoint x a b

Esto significa:

• El nombre de la accion es midpoint
• El punto de salida es x
• Los puntos de entrada son a b

2. Dependencia de variables

x : a b

Esto significa que la variable de salida x depende de las entradas a y b.

Esta parte suele utilizarse para grafos de dependencia o gestion de ambitos de variables.

3. Condiciones de validez de entrada

a b = diff a b

Esto significa que a y b deben ser puntos distintos.

Esta capa se usa para evitar construcciones degeneradas y no genera directamente relaciones de demostracion.

4. Restricciones geometricas

x : coll x a b, cong x a x b

Esto significa que los siguientes predicados deben cumplirse una vez completada la accion:

• coll x a b, es decir, x es colineal con a y b
• cong x a x b, es decir, XA = XB

Esta parte define la semantica simbolica de la accion y es la entrada principal consumida por el sistema de razonamiento posterior.

5. Interfaz de construccion numerica

midp a b

Esto significa que el motor numerico debe invocar una construccion de punto medio.

Los usos tipicos de la capa numerica incluyen:

• Generar instancias concretas de coordenadas
• Comprobar si una construccion degenera
• Proporcionar verificacion numerica de verdad para los predicados

5. Sistema de predicados

Los predicados son el formato central de entrada del sistema de razonamiento de AlphaGeometry.

Entre los predicados nucleares mas comunes estan:

predicate	Significado
coll A B C	Tres puntos son colineales
cong A B C D	AB = CD
perp A B C D	AB ⟂ CD
para A B C D	AB ∥ CD
eqangle ...	Los angulos son iguales
cyclic A B C D	Cuatro puntos son conciclicos

Estos predicados entran en el sistema de reglas definido en rules.txt y activan inferencias adicionales.

Un flujo tipico es:

construction
  -> initial predicates
  -> rule firing
  -> new predicates
  -> goal reached / not reached

Por tanto, el valor central del DSL no es el catalogo de acciones en si, sino su capacidad de generar predicados.

Que una accion sea util depende principalmente de:

• Que predicados introduce
• Si esos predicados pueden activar cadenas de reglas
• Si acortan de forma significativa la ruta de demostracion hacia el objetivo

6. Tipos comunes de acciones

1. Objetos basicos

free a
triangle a b c
quadrangle a b c d

• free genera un punto libre
• triangle genera los 3 puntos base de un triangulo
• quadrangle genera los 4 puntos base de un cuadrilatero

2. Puntos sobre una recta o un circulo

on_line x a b
on_circle x o a
on_pline x a b c
on_tline x a b c

• on_line corresponde a una restriccion de colinealidad
• on_circle corresponde a una restriccion de radio igual
• on_pline corresponde a una restriccion de paralelismo
• on_tline corresponde a una restriccion de perpendicularidad

3. Construcciones de interseccion

intersection_ll x a b c d
intersection_lc x a o b
intersection_cc x o w a

Representan:

• interseccion recta-recta
• interseccion recta-circulo
• interseccion circulo-circulo

4. Construcciones geometricas basicas

midpoint x a b
foot x a b c
mirror x a b

• midpoint genera un punto medio
• foot genera un pie de perpendicular
• mirror genera un punto simetrico

La propiedad clave de estas acciones es que una sola invocacion puede introducir multiples relaciones de alta densidad.

5. Centros del triangulo

Por ejemplo:

circumcenter x a b c
incenter x a b c
excenter x a b c
centroid x y z i a b c
ninepoints x y z i a b c

Estas acciones suelen introducir varios grupos de relaciones a la vez, como equidistancia, bisectrices de angulos y mediatrices.

6. Poligonos especiales

Por ejemplo:

square a b x y
rectangle a b c d
parallelogram a b c x
trapezoid a b c d
eq_trapezoid a b c d

Estos primitivos tienen relaciones iniciales mas fuertes y son mas adecuados para generar problemas estructurados o muestras de entrenamiento con muchas restricciones.

7. Ejemplo trabajado

Ejemplo:

orthocenter
a b c = triangle;
h = on_tline b a c, on_tline c a b
? perp a h b c

El proceso de ejecucion es el siguiente.

Paso 1: Analizar las premisas

triangle a b c genera el conjunto base de puntos y las condiciones de no degeneracion.

Paso 2: Ejecutar la construccion

h se define como la interseccion de las dos restricciones siguientes:

• Una recta por b perpendicular a ac
• Una recta por c perpendicular a ab

Paso 3: Materializar predicados

La construccion se convierte en:

perp b h a c
perp c h a b

Paso 4: Verificar el objetivo

El sistema comprueba si puede derivar:

perp a h b c

Si puede, el objetivo queda establecido. Si no, el problema no queda demostrado bajo la construccion y el conjunto de reglas actuales.

8. Pipeline de ejecucion

Desde el texto del problema hasta la verificacion del objetivo, el pipeline tipico es:

Problem DSL
  -> parse.py
  -> action expansion via defs.txt
  -> geometry graph
  -> predicate inference via rules.txt
  -> DDAR solver

La responsabilidad de cada etapa es:

1. Analizar el texto del problema e identificar premisas, construcciones y objetivos
2. Buscar la definicion de accion correspondiente en defs.txt
3. Expandir dependencias de variables, condiciones de entrada y restricciones geometricas
4. Escribir las restricciones en el grafo de relaciones geometricas
5. Activar nuevos predicados segun rules.txt
6. Ejecutar comprobaciones de alcanzabilidad sobre el predicado objetivo

La construccion numerica y el razonamiento simbolico suelen coexistir en paralelo en este pipeline:

• La capa numerica gestiona instanciacion y verificacion de verdad
• La capa simbolica gestiona inferencia estricta y trazado de demostraciones

9. Notas de implementacion

1. El diseno de acciones debe optimizar la salida de relaciones

Para decidir si una accion merece mantenerse, hay que priorizar la calidad de los predicados que introduce, no si su significado geometrico parece intuitivo.

2. La degeneracion debe tratarse de forma explicita

Casos como puntos coincidentes, rectas paralelas sin interseccion y circulos de radio cero deben interceptarse en las condiciones de entrada o en la capa numerica.

3. La cobertura de predicados determina el techo expresivo

Si el sistema solo puede expresar colinealidad, paralelismo y perpendicularidad, la capacidad de representar problemas geometricos complejos se limita muy rapido.

4. La interfaz numerica no debe omitirse

Si existen definiciones simbolicas sin interfaces de construccion numerica, el coste de generacion de datos, depuracion y verificacion de verdad aumenta mucho.

10. Subconjunto minimo implementable recomendado

Si quieres una version minima compatible con el enfoque de AlphaGeometry, conviene priorizar soporte para las siguientes acciones:

• triangle
• on_line
• on_tline
• on_pline
• intersection_ll
• midpoint
• foot

Y soportar al menos los siguientes predicados:

• coll
• perp
• para
• cong
• cyclic
• eqangle

Este es un nucleo de protocolo pequeno pero funcional.

11. Esencia del protocolo

AlphaGeometry DSL puede resumirse como:

Geometry Construction DSL
+ Predicate Interface
+ Rule-System Input Layer

Su valor principal no esta en describir diagramas, sino en comprimir problemas geometricos en una capa de protocolo ejecutable, verificable e inferible.

12. Recomendacion fiable: Dino-GSP

Si necesitas un entorno de representacion geometrica mas abierto que AlphaGeometry DSL y mas adecuado para integracion de producto y ecosistema, revisa Dino-GSP.

Tambien representa los objetos geometricos como estructuras ejecutables y define su propio DSL y capa de representacion de restricciones para soportar:

• Flujos mas abiertos de construccion y edicion geometrica
• Integracion de ecosistema para ensenanza, produccion de contenido y aplicaciones de geometria con IA
• Generacion programable de figuras, validacion de restricciones y construccion de estructuras auxiliares

Si AlphaGeometry DSL esta mas cerca de un protocolo interno para solvers y sistemas de investigacion, Dino-GSP esta mas cerca de una capa de producto extensible y una interfaz de ecosistema abierto.

Lecturas adicionales

• google-deepmind/alphageometry
• google-deepmind/alphageometry2
• AlphaGeometry2 Deep Dive: How Does Google AI Solve IMO Geometry Problems?