AlphaProof Code vs MathForm-8B: dos etapas del mismo pipeline de Lean, no dos rivales

Lea detenidamente el artículo AlphaProof Code y hay una cifra que salta a la vista y que el anuncio no destaca: de las cuatro semanas que los cinco investigadores de DeepMind pasaron verificando Signal, la parte que no se pudo automatizar fue la inicial. Expertos humanos trabajaron junto con una combinación de modelos para traducir los objetivos de seguridad de Signal a especificaciones formales en Lean, y un experto revisó cada una de ellas antes de que comenzara cualquier trabajo de demostración. Ese es el cuello de botella. MathForm-8B, el modelo de autoformalización de 8.000 millones de parámetros de OpenBMB publicado en Hugging Face el 14 de agosto de 2026, es un intento directo de automatizar exactamente ese paso: tomar un enunciado matemático en lenguaje natural y generar un enunciado de teorema en Lean 4 listo para que otra persona lo demuestre. Si los pone uno al lado del otro, no está comparando dos productos. Está viendo dos etapas consecutivas de un mismo pipeline, separadas por la diferencia entre las matemáticas y la seguridad de protocolos.

El pipeline, en el orden en que ocurre el trabajo

La verificación formal de software real tiene tres tareas. Primero, decidir qué debe ser cierto y escribirlo en un lenguaje formal. Segundo, demostrar que la implementación lo satisface. Tercero, comprobar las demostraciones mecánicamente, porque una demostración incorrecta es peor que ninguna demostración.

MathForm-8B realiza la tarea número uno, para una clase de entrada estrecha: afirmaciones matemáticas al estilo de los libros de texto. Si se le da «para todo número real x, x² no es negativo», devuelve los imports, los tipos y una cabecera de teorema en Lean 4. Lo que no devuelve es una prueba, y sus autores son explícitos en que la búsqueda de pruebas es problema de otra persona. Sus cifras reportadas, todas reportadas por el proveedor y no reproducidas, son 88,06 % de Pass@8 promedio bajo una verificación de sintaxis y 72,37 % bajo la verificación de consistencia más estricta en seis benchmarks; la diferencia entre esas dos cifras es la medida honesta de con qué frecuencia una afirmación sintácticamente válida significa algo distinto de lo que se pidió.

AlphaProof Code realiza las tareas dos y tres, además de una etapa de especificación que MathForm-8B no pudo abordar. Los objetivos de seguridad de Signal no son afirmaciones matemáticas en el sentido en que se entrenó a MathForm; son declaraciones sobre un protocolo: que los mensajes permanecen protegidos antes y después de que un dispositivo se vea comprometido temporalmente, que el iniciador y el respondedor son quienes dicen ser. Convertir eso en Lean requería una experiencia en protocolos que ningún autoformalizador de 8B posee. Una vez que existió la especificación, el trabajo de prueba se entregó por completo a agentes, y la verificación se entregó al kernel de Lean más un agente guardián que utiliza comparator frente a una copia de la especificación reservada.

Cuánto te cuesta realmente usar cada uno

• Pesos — MathForm-8B: descargable, Apache 2.0, cuatro fragmentos de safetensors en BF16, con ajuste fino a partir de Qwen3-8B. AlphaProof Code: ninguno. La publicación consiste en un desarrollo en Lean, una semántica de AArch64 y un binding de libsignal en github.com/google-deepmind/code-verification.

• Ejecutarlo — MathForm-8B: Transformers, vLLM o SGLang, todos exponiendo un endpoint compatible con OpenAI, en hardware de tu propiedad. AlphaProof Code: sin endpoint, sin API, sin lista de espera, sin precio; es un marco de investigación que DeepMind dice que necesita «investigación continua» antes de escalar.

• Entrada — MathForm-8B: un enunciado matemático en lenguaje natural. AlphaProof Code: una especificación formal junto con el binario que deseas demostrar con respecto a ella.

• Salida — MathForm-8B: un enunciado de teorema en Lean 4, sin demostrar. AlphaProof Code: una demostración verificada por máquina, o una refutación cuando el código está defectuoso.

• Revisión humana — MathForm-8B: tú revisas el enunciado emitido y, con una consistencia del 72,37 %, estarás revisando muchos de ellos. AlphaProof Code: los expertos revisan cada especificación antes de que comience el trabajo de demostración; después, los agentes señalan aproximadamente el 1 % del código base para una segunda revisión.

• Límites conocidos — MathForm-8B: solo enunciados matemáticos, sin generación de pruebas, y el repositorio de código enlazado en su README seguía siendo un marcador de posición en el lanzamiento. AlphaProof Code: sin garantía poscuántica para la sanación de SPQR, sin privacidad de la carga útil, una sesión por promoción, y una cota de falsificación MAC que se vuelve vacua cerca de 25.000 mensajes en una sola sesión.

La brecha que MathForm-8B tendría que cerrar

Es tentador decir que un autoformalizador podría haber escrito las especificaciones de Signal y ahorrado a los investigadores sus semanas de trabajo inicial. El propio relato del artículo dice lo contrario, y la razón es específica. Una especificación de un protocolo no es una reformulación de una afirmación; es una elección sobre el modelo de adversario. El trabajo de Signal incluye una vía simbólica en Dolev–Yao con un atacante cuántico que rompe Diffie–Hellman después del handshake, y una vía computacional con adversarios clásicos y una cota concreta. Esas dos vías enuncian teoremas diferentes sobre el mismo código, y elegir entre ellas es una decisión de ingeniería con consecuencias para la seguridad. Ningún modelo que haya sido entrenado para convertir "demuestre que x² ≥ 0" en Lean tomará esa decisión.

Lo que un autoformalizador plausiblemente podría hacer es la parte mecánica de ese trabajo: dado un objetivo de seguridad en prosa y una biblioteca de definiciones Lean existentes, producir un primer borrador del enunciado en el idioma propio del proyecto, para que un experto lo corrija. Eso es un ahorro real, y mucho menor de lo que sugiere el titular. El artículo reporta un catálogo de desviaciones de especificación de más de 200 entradas computacionales y unas 35 simbólicas —quince de ellas lagunas o errores en el análisis de Double Ratchet—, que es lo que encontró el paso de revisión humana. Un modelo que redactara enunciados tendría que medirse contra ese catálogo, no contra una puntuación Pass@8 en benchmarks de matemáticas.

Donde los dos números no son comparables en absoluto

El 88,06 % de MathForm-8B y los 6,5 millones de líneas de AlphaProof Code miden cosas distintas y nunca deberían colocarse en la misma columna. Una es una tasa de aciertos en un conjunto de pruebas de referencia creado por los autores; la otra es una cantidad de demostración generada para un solo objetivo. El proveedor admite con franqueza que el 88,06 % utiliza una verificación de sintaxis, que es un criterio débil —una afirmación puede compilar y aun así formalizar la proposición equivocada, por lo que la cifra de consistencia es 16 puntos menor.

El caso de AlphaProof Code con un matiz comparable es el trabajo de validación: se reintrodujeron dos fallos de Signal corregidos anteriormente —un fallo de estado débil y un fallo de subgrupo pequeño— en una copia aislada y, en ambos casos, el sistema produjo una prueba verificada por máquina de que la versión defectuosa no cumple el teorema de seguridad. Esa es una prueba negativa, y una prueba negativa es justo lo que le falta por completo a un benchmark de autoformalización. MathForm-8B no reporta ningún resultado de la forma «dado un enunciado deliberadamente incorrecto, el modelo dijo que lo era».

Cómo los usarías realmente juntos

En concreto, y esta es la única parte de la comparación con una vía a corto plazo: usa un autoformalizador para redactar el borrador, un modelo general potente para criticar el borrador y un agente de demostración para intentar la prueba. Cada etapa tiene un modo de fallo distinto, y enrutar las tres a través de una sola clave es la comodidad práctica. En OrcaRouter, más de 200 modelos están detrás de una única API al precio de lista del proveedor con un 0 % de margen, así que un bucle de redacción de especificaciones que envía la misma afirmación a dos modelos y compara las diferencias de su Lean es una llamada a un DSL de enrutamiento en lugar de tres contratos y tres SDK. La conmutación por error automática cubre el caso en el que el modelo que elegiste está teniendo una tarde mala.

Nada de eso proporciona la garantía. MathForm-8B te da un enunciado, los modelos te dan una crítica, y algo todavía tiene que demostrarlo. En la actualidad, el único sistema publicado que cierra ese bucle sobre código real desplegado es AlphaProof Code, y no está a la venta.

La razón para leer ambos artículos en lugar de elegir un ganador

MathForm-8B es un artefacto útil con un trabajo acotado y un techo de precisión real y medido. AlphaProof Code es una demostración de flujo de trabajo cuyo hallazgo más transferible no es el volumen de pruebas, sino la división: el trabajo de especificación requiere humanos y un modelo general potente; el trabajo de prueba requiere equipos de agentes y un kernel; y la frontera entre ambos es donde reside toda la dificultad. Cualquiera que construya un pipeline de verificación debería tomar en serio esa división y tratar la autoformalización como la pieza que reduce el coste de la primera etapa —no como la pieza que la sustituye.

El resumen honesto para un equipo que decide qué descargar este mes: MathForm-8B, sí, si trabajas con Lean y quieres una ayuda para redactar borradores. AlphaProof Code: lee el repositorio de artefactos y el catálogo de desviaciones de especificación, porque el catálogo te dice más sobre lo que la verificación formal de código de producción todavía no puede alcanzar que cualquier anuncio.