Tekoälyn kirjoittama koodi voidaan todistaa oikeaksi – jos sille annetaan oikea tuki
Tekoälyn kirjoittama koodi voidaan todistaa oikeaksi – jos sille annetaan oikea tuki
Uudet kokeet osoittavat, että avoimet kielimallit yltävät matemaattisesti todennettuun koodiin, kun ne saavat rakenteen ja palautetta tarkistimelta.
Moni ohjelmoija on kokenut saman: tekoälyavustaja sylkäisee nopeasti valmiin näköisen ratkaisun, testit näyttävät vihreää – ja silti ohjelma hajoaa myöhemmin nurinkurisessa tilanteessa. Nopeus on hurmaavaa, mutta luottamus on ohutta. Mitä jos koodin oikeellisuus voitaisiin varmistaa etukäteen, ei vasta käyttäjien raportoimien virheiden jälkeen?
Perinteinen ajatus on ollut, että lisää testejä ja isompi malli paikkaavat virheet. Tuore ehdotus kääntää asetelman: kielimallin tulisi kirjoittaa koodin lisäksi myös sen täsmällinen vaatimuslista – ikään kuin sopimus siitä, mitä ohjelman on pakko tehdä – ja antaa matemaattisen tarkistimen todistaa, että koodi todella täyttää lupauksensa. Suurin hankaluus on ollut muuntaa luonnollinen kieli tällaiseen täsmälliseen muotoon.
ArXivissa julkaistu työ tarttuu juuri tähän kuiluun. Tutkijat kokosivat NL2VC-60-nimisen aineiston: 60 monimutkaista algoritmista tehtävää, joissa ratkaisu edellyttää sekä toteutusta että siihen liittyviä täsmällisiä määrittelyjä. He testasivat seitsemää avointa kielimallia 11 satunnaisesti valitulla tehtäväjoukolla ja ohjasivat malleja kolmella eri tavalla. Tavoitteena ei ollut vain toimiva koodi, vaan koodi, jonka oikeellisuus voidaan todistaa Dafny-nimisellä tarkistimella – järjestelmällä, joka tarkistaa ohjelmasta ja sen määrityksistä, pitävätkö väitteet varmasti paikkansa kaikissa tilanteissa.
Kolme ohjaustapaa paljastivat olennaisen eron "kirjoita koodi" -pyynnön ja järjestelmällisemmän työskentelyn välillä. Kun mallit saivat tehtävänannon ilman lisätietoja, ne epäonnistuivat lähes aina. Kun niille annettiin runko – esimerkiksi funktioiden nimet sekä syötteiden ja tulosten rakenteet – suunta muuttui. Parhaat tulokset tulivat, kun prosessiin lisättiin palaute: malli kirjoitti ehdotuksen, Dafny kertoi, mikä ei täsmää, ja malli korjasi yritystään, kunnes todiste meni läpi.
Tulokset olivat yllättävän vahvoja. Gemma 4‑31B -malli ylsi 90,91 prosentin todentamisprosenttiin. GPT‑OSS 120B nousi nollasta 81,82 prosenttiin, kun se sai sekä rakenteellisen rungon että iteratiivista palautetta. Ilman rakennetta menestystä ei juuri tullut – mutta oikeilla kaiteilla avoimetkin mallit pystyivät tuottamaan koodia, jonka oikeellisuus tarkistui matemaattisesti.
Mitä tällainen todennus tarkoittaa arkikielellä? Ajatellaan ohjelmaa, joka palauttaa jonkin lukuarvon. Jos määrittelyksi kirjoitetaan vain "palauttaa nollan", malli voi toteuttaa ohjelman, joka tosiaan palauttaa aina nollan. Tarkistin on tyytyväinen, koska ehto pitää – mutta ohjelma ei tee mitään hyödyllistä. Tätä ilmiötä kutsutaan paperissa tyhjänpäiväiseksi todennukseksi: tarkistin todistaa jotain, joka on sinänsä totta mutta väärin valittu, koska itse tehtävä jää ratkaisematta. Tutkijat torjuivat tätä ongelmaa yhdistämällä Dafnyn uDebug-alustaan, joka vertaa ratkaisun ulostuloja esimerkkitapauksiin. Näin pelkällä näennäisellä määrittelyllä läpi livahtaminen vaikeutuu.
Käytännössä prosessi muistutti keskustelevaa työpajaa. Ensin malli sai tehtävänannosta ydinasiat ja rakenteen: minkä niminen funktio tarvitaan ja millaista syötettä ja tulosta se käsittelee. Sitten malli ehdotti sekä täsmällisiä ehtoja että toteutusta. Dafny tarkisti yrityksen ja palautti tarkat huomautukset epäjohdonmukaisuuksista tai puuttuvista perusteluista. Malli muokkasi tekstiä ja koodia, kunnes tarkistin hyväksyi kokonaisuuden. Ilman rakennetta ja palautetta sama malli yleensä harhaili.
Tämä asettaa vastakkain kaksi tapaa ajatella tekoälyn koodausta. Ennen: riittää, että malli arvaa oikean lopputuloksen ja että muutama testi menee läpi. Nyt: malli on tehokas, kun se pannaan selittämään itselleen ja tarkistimelle, mitä se yrittää todistaa – ja kun järjestelmä kieltäytyy hyväksymästä huteria selityksiä. Kysymys ei ole mallin pelkästä älykkyydestä vaan työnjaosta: ihminen tarjoaa kaiteet, tarkistin vahtii loogista yhtenäisyyttä, ja malli oppii korjaamaan kurssia.
Rajoituksia on hyvä painottaa. Aineisto sisältää 60 algoritmista tehtävää. Kokeissa arvioitiin 11 tehtäväjoukkoa seitsemällä mallilla. Tehtävät ovat luonteeltaan rajattuja ja sopivat Dafnyllä todennettaviksi; se ei ole sama asia kuin suurten ohjelmistojen ylläpito tai käyttöliittymien kaltaiset ongelmat. Ilman rakennetta ja palautetta mallit epäonnistuivat lähes aina – siis lähestymistapa vaatii kurinalaista kehystä, ei pelkkää "kysy ja saat" -tyyliä. Ja vaikka uDebug vähentää tyhjänpäiväisen todennuksen riskiä, se ei poista sitä kokonaan: huonosti valittu määrittely voi yhä tuottaa kauniin mutta väärän varmuuden.
Silti löydös on merkittävä. Se osoittaa, että myös avoimet kielimallit voivat toimia käytännöllisinä apureina korkean varmuustason ohjelmoinnissa, kunhan ne pannaan oikeaan rooliin: tuottamaan määrityksiä, ottamaan vastaan järjestelmän palautetta ja parantamaan omaa tuotostaan kierros kierrokselta. Se on eri asia kuin luottaa sokkona valmiiseen vastaukseen.
Seuraava kysymys kuuluu: jos koodi voidaan todistaa oikeaksi näin kurinalaisessa asetelmassa, miten sama ajattelu viedään arjen ohjelmistotyöhön – työkaluihin, joilla miljoonat ihmiset jo nyt koodaavat? Kun tekoäly, ihminen ja tarkistin löytävät yhteisen sävelen, mitä kaikkea ohjelmistosta voikaan lopulta luvata – ja kenen vastuulla nuo lupaukset ovat?
Paper: https://arxiv.org/abs/2604.22601v1
Register: https://www.AiFeta.com
tekoäly ohjelmointi ohjelmistokehitys verifiointi tutkimus
