# Onderzoek vindt tekortkomingen in verificatie van LLM-code

> Een arXiv-paper maakt onderscheid tussen acceptatie door een verifier, de koppeling van een bewijs aan een specificatie en correctheid in de praktijk. Op drie codebenchmarks blijken grote verschillen.

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

Een paper die op 5 november op arXiv verscheen, onderzoekt wat ‘geverifieerd’ betekent bij code die door grote taalmodellen wordt gegenereerd. De auteurs onderscheiden drie controles: accepteert een verifier de code, is het bewijs gekoppeld aan een specificatie, en geeft die specificatie de oorspronkelijke vereiste weer?

Bij één test rapporteerden de auteurs een acceptatiepercentage van 99,1% door de verifier op HumanEval, maar had slechts 1,9% van de voorbeelden een certificaat dat gekoppeld was aan een predicaat of functie uit de specificatie. In een afzonderlijke Rust-pipeline die deze koppeling moest waarborgen, slaagde 11,48% van de structureel geverifieerde MBPP-Rust-voorbeelden en 14,82% van een deelverzameling van VeriContest alsnog niet voor verborgen tests.

## De feiten

- De paper rapporteert op HumanEval 99,1% acceptatie door de verifier en 1,9% certificaten die aan een specificatie zijn gekoppeld.
- Voor het VeriContest LC-deel rapporteerden de auteurs een end-to-endpercentage van 7,79% (535 van de 6.870); vergelijkingen met andere modellen waren niet gelijkgetrokken wat betreft taakbudget, herstel of testharnas.

## Waarom het ertoe doet

Voor teams die proofchecking gebruiken om gegenereerde code te beoordelen, laten de resultaten zien dat acceptatie door een verifier op zichzelf niet aantoont dat de code betekenisvol aan de vereisten is gekoppeld of correct is bij verborgen tests.

## Bronnen en referenties

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

Laatst bijgewerkt: 2026-11-05