Von KI-Agenten geschrieben, von mir kuratiert und geprüft.
Mistral Leanstral 1.5: das Modell fürs Prüfen ist das interessantere Release
- Mistral
- Verification
- Agentic Engineering
- Coding Agents
Am 2. Juli hat Mistral Leanstral 1.5 veröffentlicht: ein offenes Modell unter Apache 2.0, 119 Milliarden Parameter insgesamt, 6 Milliarden davon aktiv, spezialisiert auf formale Beweise in Lean 4. Die Benchmark-Zahlen sind bemerkenswert. Aber sie sind nicht der Grund, warum ich über dieses Release schreibe. Der Grund ist der agentische Prüfmodus: Das Modell editiert Dateien, führt Bash-Kommandos aus, liest die Ausgaben des Lean-Sprachservers und hat in einem Experiment über 57 Repositories fünf Bugs gefunden, die auf GitHub bisher niemand gemeldet hatte. Neue Code-Generatoren erscheinen inzwischen fast wöchentlich. Ein Modell, das fürs Prüfen gebaut ist, ist die seltenere Nachricht.
Was ist Leanstral 1.5?
Leanstral ist Mistrals Modellreihe für Beweisführung in Lean 4, einem Beweisassistenten, dessen Kern jeden Beweis maschinell prüft. Version 1.5 ist ein Leistungsupgrade, trainiert in drei Stufen aus Mid-Training, Supervised Fine-Tuning und Reinforcement Learning mit CISPO. Die Zahlen: 100 Prozent auf miniF2F, Validierungs- wie Testset. 587 von 672 Aufgaben auf PutnamBench, laut Mistral für rund 4 Dollar pro Aufgabe, während der Vergleichskandidat Seed-Prover auf geschätzte 300 Dollar oder mehr komme. 87 Prozent auf FATE-H und 34 Prozent auf FATE-X, zwei Benchmarks für abstrakte Algebra auf Graduierten- beziehungsweise Promotionsniveau. Auf FLTEval, gebaut aus echten Pull Requests des Repositorys zum Großen Fermatschen Satz, steigt Pass@1 von 21,9 auf 28,9 und Pass@8 von 31,9 auf 43,2. Auffällig ist die Skalierung mit Rechenbudget: 44 gelöste Putnam-Aufgaben bei 50.000 Tokens, 587 bei 4 Millionen. Ein einzelner Beweis über AVL-Bäume lief laut Mistral über 2,7 Millionen Tokens und 22 Kompaktierungen des Kontexts.
Wie arbeitet der agentische Prüfmodus?
Mistral trainiert das Modell in zwei Umgebungen. Die erste ist eine Multiturn-Schleife: Das Modell bekommt ein Theorem, reicht einen Beweis ein, erhält die Rückmeldung des Lean-Compilers und verbessert den Versuch, bis der Beweis kompiliert oder das Budget erschöpft ist. Die zweite ist eine Code-Agent-Umgebung, und sie ist der interessante Teil. Dort arbeitet das Modell nach Mistrals Beschreibung „wie ein Entwickler in einem rohen Dateisystem“: Es editiert Dateien, führt Bash-Kommandos aus und fragt den Lean-Sprachserver in Echtzeit nach Beweiszielen, Fehlern und Typinformationen. Das ermöglicht Aufgaben mit langem Horizont, etwa teilfertige Beweise in einem Repository zu vervollständigen und Hilfslemmata zu bauen. Am Ende prüft ein Fork von SafeVerify gegen eine Liste von Zieltheoremen, ob das Ergebnis korrekt ist. Es ist dieselbe Werkzeugpalette wie bei den Coding-Agenten. Nur ist das Erfolgssignal hier kein bestandener Test, sondern ein maschinell geprüfter Beweis.
Wie findet ein Beweismodell Bugs in echtem Code?
Über eine Pipeline, die Mistral an 57 Repositories ausprobiert hat. Das Werkzeug Aeneas übersetzt Rust-Code nach Lean. Leanstral liest den Code, leitet daraus die vermutete Absicht ab und formuliert Korrektheitseigenschaften. Dann versucht es, jede Eigenschaft in vier Anläufen zu beweisen. Scheitern alle vier, versucht es in vier weiteren Anläufen, die Negation zu beweisen. Gelingt das, ist die Verletzung der Eigenschaft maschinell belegt. Das Ergebnis: 47 als verletzt markierte Eigenschaften, davon 11 echte Bugs, 5 davon auf GitHub bisher nicht gemeldet. Das Beispiel, das Mistral zeigt: In der Bibliothek datrs/varinteger lief die Sign-Funktion der Zigzag-Dekodierung bei der Eingabe U64.MAX über, weil sie value + 1 rechnet. Im Debug-Modus ein Absturz, im Release-Modus stille Datenkorruption. Die Pipeline hat den Fehler automatisch gefunden.
Was heißt das für Sie?
Ich halte dieses Release für interessanter als die meisten neuen Code-Generatoren, und der Grund steckt in der Zahlenreihe 47, 11, 5. Bei einem gewöhnlichen LLM-Review ist jede Meldung eine Behauptung, die ein Mensch vollständig nachprüfen muss. Hier ist der Beweis selbst maschinell geprüft: Ein Beweis, der nicht stimmt, kompiliert nicht, und der Lean-Kern lässt sich nicht überreden. Was bleibt, ist die schwächere Stelle der Kette, und die benennt die Zahlenreihe ehrlich. Von 47 markierten Eigenschaften waren nur 11 echte Bugs, weil das Modell die Absicht des Codes rät, bevor es sie formalisiert. Sie prüfen also nicht mehr den Beweis, sondern die Spezifikation. Das ist deutlich weniger Arbeit, aber sie verschwindet nicht, und die Verantwortung dafür bleibt bei Ihnen. Es ist genau die Verschiebung, die ich im Agentic Engineering beschreibe: Erzeugen ist billig geworden, die Prüfung ist der Engpass. Ein frei lizenziertes Modell, das an dieser Stelle ansetzt, ist deshalb die richtige Sorte Release. Wer es ausprobieren will: Die Gewichte liegen auf Hugging Face, der API-Endpunkt leanstral-1-5 ist laut Mistral kostenlos, und als Oberfläche empfiehlt Mistral das eigene Vibe mit vibe --agent lean. Der Anwendungsbereich ist eng: Mathematik zuerst, Rust-Code über den Umweg Aeneas. Aber die Richtung stimmt.