Ett genererat titelkort med titeln 'AlphaProof Code vs MathForm-8B' och underrubriken 'Två steg i en Lean-pipeline', ett diagram med tre rutor från vänster till höger märkt '1. Skriv specifikationen', '2. Bevisa det' och '3. Kontrollera det', där den första är märkt 'människa plus modeller' och den tredje är märkt 'Lean-kärna', samt en sidfot med texten 'MathForm-8B formulerar påståenden; AlphaProof Code bevisar och kontrollerar dem.'
Engineering & Research

AlphaProof Code vs MathForm-8B: Två stadier i samma Lean-pipeline, inte två rivaler

Författare

Rowan Sterling

Publiceringsdatum

Senaste modellerna · 20Visa alla modeller →
Benchmarks: Artificial Analysis · uppdateras dagligen
Tillbaka till alla inlägg

Läs AlphaProof Code-artikeln noga och en siffra sticker ut som tillkännagivandet inte betonar: av de fyra veckor som DeepMinds fem forskare spenderade på att verifiera Signal var den del som inte kunde automatiseras den inledande fasen. Mänskliga experter satt tillsammans med en blandning av modeller för att översätta Signals säkerhetsmål till formella Lean-specifikationer, och en expert granskade varenda en innan något bevisarbete påbörjades. Det är flaskhalsen. MathForm-8B, OpenBMB:s autoformaliseringsmodell med 8 miljarder parametrar som släpptes på Hugging Face den 14 augusti 2026, är ett direkt försök att automatisera exakt det steget – att ta ett matematiskt påstående i naturligt språk och generera en Lean 4-teoremformulering som är redo för någon annan att bevisa. Ställ dem sida vid sida och du jämför inte två produkter. Du tittar på två på varandra följande steg i en och samma pipeline, åtskilda av skillnaden mellan matematik och protokollsäkerhet.

Pipelinen, i den ordning arbetet sker

Formell verifiering av verklig programvara har tre uppgifter. För det första att avgöra vad som måste vara sant och skriva ner det i ett formellt språk. För det andra att bevisa att implementationen uppfyller det. För det tredje att kontrollera bevisen maskinellt, eftersom ett felaktigt bevis är värre än inget bevis.

MathForm-8B gör jobb ett, för en snäv indataklass: matematiska påståenden i läroboksstil. Ge den "för varje reellt tal x är x² icke-negativt" och den returnerar importerna, typerna och en satsrubrik i Lean 4. Det den inte returnerar är ett bevis, och författarna är tydliga med att bevisökning är någon annans problem. Dess rapporterade siffror, alla leverantörsrapporterade och icke reproducerade, är 88,06 % genomsnittlig Pass@8 under en syntaxkontroll och 72,37 % under den strängare konsistenskontrollen över sex benchmarks – gapet mellan dessa två siffror är det ärliga måttet på hur ofta ett syntaktiskt giltigt påstående betyder något annat än det som efterfrågades.

AlphaProof Code utför uppgifterna två och tre, plus en specifikationsfas som MathForm-8B inte kunde hantera. Signals säkerhetsmål är inte matematiska påståenden i den bemärkelse som MathForm tränades på; de är påståenden om ett protokoll – att meddelanden förblir skyddade före och efter att en enhet tillfälligt komprometteras, att initiatorn och svararen är vilka de utger sig för att vara. Att omvandla dem till Lean krävde protokollexpertis som ingen 8B-autoformaliserare besitter. När specifikationen väl fanns överlämnades bevisarbetet helt till agenter, och kontrollen överlämnades till Leans kärna plus en grindvaktsagent som använder en komparator mot en undanhållen specifikationskopia.

Vad var och en faktiskt kostar dig att använda

• Vikter — MathForm-8B: nedladdningsbar, Apache 2.0, fyra safetensors-shards i BF16, finjusterad från Qwen3-8B. AlphaProof Code: inga. Utgåvan är en Lean-utveckling, en AArch64-semantik och en libsignal-bindning på github.com/google-deepmind/code-verification.

• Att köra det — MathForm-8B: Transformers, vLLM eller SGLang, som alla exponerar en OpenAI-kompatibel endpoint, på hårdvara du äger. AlphaProof Code: ingen endpoint, inget API, ingen väntelista, inget pris; det är ett forskningsramverk som DeepMind säger behöver "fortsatt forskning" innan det kan skalas.

• Indata — MathForm-8B: ett matematiskt påstående i naturligt språk. AlphaProof Code: en formell specifikation plus binärfilen som du vill ska bevisas mot den.

• Utdata — MathForm-8B: ett Lean 4-satsuttalande, obevisat. AlphaProof Code: ett maskinkontrollerat bevis, eller en vederläggning när koden är trasig.

• Mänsklig granskning — {{1}}MathForm-8B{{/1}}: du granskar det genererade påståendet, och vid {{2}}72.37%{{/2}} konsistens kommer du att granska många av dem. {{3}}AlphaProof Code{{/3}}: experter granskar varje specifikation innan bevisarbetet börjar, sedan flaggar agenterna ungefär {{4}}1%{{/4}} av kodbasen för en andra titt.

• Kända begränsningar — MathForm-8B: endast matematiska påståenden, ingen bevisgenerering, och kodförrådet som länkades i dess README var fortfarande en platshållare vid lanseringen. AlphaProof Code: ingen postkvantgaranti för SPQR-healing, ingen sekretess för nyttolasten, en session per befordran, och en MAC-förfalskningsgräns som blir verkningslös nära 25 000 meddelanden i en enda session.

A screenshot of the Hugging Face model page for openbmb/MathForm-8B, showing the org and repo name, a like count of 2, tags for TextGeneration, Transformers, Safetensors, the FormalVerse dataset and English, 'License: apache-2.0', and the tabs for Model card, Files and versions, and Community.

Klyftan som MathForm-8B skulle behöva överbrygga

Det är frestande att säga att en autoformaliserare kunde ha skrivit Signals specifikationer och besparat forskarna de inledande veckorna av förberedande arbete. Artikelns egen redogörelse säger motsatsen, och skälet är specifikt. En specifikation av ett protokoll är inte en omformulering av ett påstående; den är ett val av angriparmodell. Signal-arbetet innehåller ett symboliskt spår i Dolev–Yao med en kvantangripare som bryter Diffie–Hellman efter handskakningen, och ett beräkningsteoretiskt spår med klassiska angripare och en konkret gräns. Dessa två spår anger olika satser om samma kod, och att välja mellan dem är ett ingenjörsbeslut med säkerhetskonsekvenser. Ingen modell som har tränats att omvandla "visa att x² ≥ 0" till Lean kommer att fatta det beslutet.

Det en autoformaliserare rimligen skulle kunna göra är den mekaniska delen av arbetet: givet ett säkerhetsmål i prosa och ett bibliotek med befintliga Lean-definitioner, ta fram ett första utkast till påståendet i projektets eget idiom, för en expert att rätta. Det är en verklig besparing, och en mycket mindre sådan än rubriken antyder. Artikeln rapporterar en katalog över specifikationsavvikelser med över 200 beräkningsmässiga poster och omkring 35 symboliska – femton av dem luckor eller buggar i Double Ratchet-analysen – vilket är vad det mänskliga granskningssteget hittade. En modell som skriver utkast till påståenden skulle behöva mätas mot den katalogen, inte mot en Pass@8-poäng på matematikbenchmarkar.

Där de två talen inte alls är jämförbara

MathForm-8B:s 88,06 % och AlphaProof Codes 6,5 miljoner rader mäter olika saker och bör aldrig placeras i samma kolumn. Det ena är en träffsäkerhet på en benchmark-svit som författarna har byggt; det andra är en mängd bevis som producerats för ett enda mål. Leverantören är öppen med att 88,06 % bygger på en syntaxkontroll, vilket är ett svagt kriterium – ett påstående kan kompileras och ändå formalisera ett felaktigt påstående, vilket är anledningen till att konsistenssiffran är 16 punkter lägre.

AlphaProof Code-exemplet med en jämförbar karaktär är valideringsarbetet: två tidigare åtgärdade Signal-buggar, en svag-tillståndsbugg och en småundergruppsbugg, återinfördes i en isolerad kopia, och i båda fallen producerade systemet ett maskinkontrollerat bevis för att den buggiga versionen inte uppfyller säkerhetsteoremet. Det är ett negativt test, och ett negativt test är precis vad ett autoformalizer-benchmark helt saknar. MathForm-8B rapporterar inget resultat av formen "givet ett avsiktligt felaktigt påstående, sade modellen att det var fel."

A generated two-column scoreboard headed 'AlphaProof Code vs MathForm-8B - the scoreboard'. Left column 'AlphaProof Code' rows: 'Weights: none - artifacts only', 'Input: formal spec plus binary', 'Output: machine-checked proof', 'Negative test: two bugs refuted', 'Cost: 5 researchers, 4 weeks', 'Availability: research only'. Right column 'MathForm-8B' rows: 'Weights: 8B, Apache 2.0', 'Input: natural-language math', 'Output: Lean 4 statement, unproved', 'Accuracy: 72.37% consistency', 'Cost: self-host, 8B', 'Availability: download now'. Footer: 'MathForm-8B figures vendor-reported by OpenBMB and unreproduced; AlphaProof Code per the DeepMind paper.'

Hur du faktiskt skulle använda dem tillsammans

Konkret, och detta är den enda delen av jämförelsen med en kortsiktig väg: använd en autoformaliserare för att ta fram ett utkast, en stark allmän modell för att kritisera utkastet och en bevisagent för att försöka genomföra beviset. Varje steg har ett eget slags fel, och att dirigera alla tre genom en enda nyckel är den praktiska bekvämligheten. På OrcaRouter, fler än 200 modeller finns bakom ett enda API till leverantörens listpris med 0 % påslag, så en loop för spec-utkast som skickar samma påstående till två modeller och kör diff på deras Lean är ett routing-DSL-anrop i stället för tre kontrakt och tre SDK:er. Automatisk failover täcker fallet där modellen du valde har en dålig eftermiddag.

Det som inget av detta tillhandahåller är garantin. MathForm-8B ger dig ett påstående, modellerna ger dig en kritik, och något måste fortfarande bevisa det. För närvarande är det enda publicerade systemet som sluter den loopen på verkligt driftsatt kod AlphaProof Code, och det är inte till salu.

A headless-Chromium capture of the OrcaRouter models catalogue at www.orcarouter.ai/models, showing the heading 'Models', the line '227 models · 17 providers · one API key, one bill', the left-hand filter rail with input modalities, context length, input price, status, access tier and series, and the beginning of the model grid.

Anledningen till att läsa båda artiklarna i stället för att utse en vinnare

MathForm-8B är en användbar artefakt med ett smalt uppdrag och ett verkligt, uppmätt noggrannhetstak. AlphaProof Code är en arbetsflödesdemonstration vars mest överförbara insikt inte är bevisvolymen utan uppdelningen: specifikationsarbete kräver människor och en stark allmän modell, bevisarbete kräver agentteam och en kärna, och gränsen mellan dem är där all svårighet ligger. Alla som bygger en verifieringspipeline bör ta uppdelningen på allvar och behandla autoformalisering som den del som minskar kostnaden för det första steget – inte den del som ersätter det.

Den ärliga sammanfattningen för ett team som ska besluta vad de ska ladda ner den här månaden: MathForm-8B, ja, om ni arbetar med Lean och vill ha ett hjälpmedel för utkast. AlphaProof Code, läs artefaktarkivet och katalogen över specifikationsavvikelser, eftersom katalogen berättar mer om vad formell verifiering av produktionskod fortfarande inte kan uppnå än något tillkännagivande kommer att göra.