# Studie zeigt Lücken bei der Code-Verifizierung durch LLMs

> Ein arXiv-Paper unterscheidet zwischen der Akzeptanz durch einen Verifizierer, der Bindung eines Beweises an eine Spezifikation und der Korrektheit in der Praxis – und findet bei drei Code-Benchmarks erhebliche Lücken.

Oossa · 2026-11-05 · https://oossa.com/de/study-finds-gaps-in-llm-code-verification

Ein am 5. November auf arXiv veröffentlichtes Paper untersucht, was „verifiziert“ bei von großen Sprachmodellen generiertem Code bedeutet. Es unterscheidet drei Prüfungen: ob ein Verifizierer den Code akzeptiert, ob der Beweis an eine Spezifikation gebunden ist und ob diese Spezifikation die ursprüngliche Anforderung widerspiegelt.

In einem Test berichten die Autoren von einer Akzeptanzrate des Verifizierers von 99.1% bei HumanEval. Bei lediglich 1.9% der Beispiele war jedoch ein Zertifikat an ein durch die Spezifikation definiertes Prädikat oder eine Funktion gebunden. In einer separaten Rust-Pipeline, die diese Bindung sicherstellen sollte, scheiterten weiterhin 11.48% der strukturell verifizierten MBPP-Rust-Beispiele und 14.82% einer VeriContest-Teilmenge an versteckten Tests.

## Die Fakten

- Das Paper berichtet bei HumanEval von einer Akzeptanzrate des Verifizierers von 99.1% und von 1.9% an die Spezifikation gebundenen Zertifikaten.
- Für den VeriContest-LC-Ausschnitt berichten die Autoren eine End-to-End-Rate von 7.79% (535 von 6,870); Vergleiche mit anderen Modellen waren hinsichtlich Aufgabenbudget, Reparatur und Testumgebung nicht angeglichen.

## Warum es wichtig ist

Für Teams, die generierten Code mithilfe von Beweisprüfungen bewerten, zeigen die Ergebnisse: Die Akzeptanz durch einen Verifizierer allein belegt möglicherweise weder eine aussagekräftige Verbindung zu den Anforderungen noch die Korrektheit bei versteckten Tests.

## Quellen und Referenzen

1. [Verified but Vacuous: Three Failure Surfaces of LLM-Driven Verified Code Generation](https://arxiv.org/abs/2611.05590) – arXiv, 2026-11-05

Zuletzt aktualisiert: 2026-11-05