Leanstral 1.5 tikrina kodą formaliai: klaidos, kurių testai kartais nemato
Mistral pristatė Leanstral 1.5 - atvirą modelį formalios verifikacijos ir proof engineering užduotims.
Šiame straipsnyje · 6 dalys
- Kuo tai skiriasi nuo testų? Formalus tikrinimas bando įrodyti savybes, o testai tikrina pasirinktus pavyzdžius.
- Kam tai naudinga? Kritinėms sistemoms, kur klaidos kaina didelė.
Leanstral 1.5 skamba kaip techninis terminas. Bet kai pažiūri praktiškai, čia yra labai žemiškas klausimas: kiek darbo darome rankomis tik todėl, kad niekas neprisėdo sutvarkyti proceso?
Mistral pristatė Leanstral 1.5 – atvirą Apache-2.0 licencijos modelį, skirtą formalios verifikacijos darbams su Lean 4. Skamba akademiškai. Bet po šituo terminu slepiasi labai praktiškas klausimas: kaip įrodyti, kad kodas tikrai daro tai, ką galvojame?
Man tokiose naujienose visada įsijungia mažas vidinis buhalteris. Ne tas, kuris skaičiuoja sąskaitas, o tas, kuris klausia: kiek tai kainuos, kas prižiūrės ir kur gali lūžti?
Kas nutiko
Mistral teigia, kad Leanstral 1.5 turi 119B bendrų ir 6B aktyvių parametrų, sprendžia PutnamBench uždavinius, pasiekia stiprius FATE rezultatus ir realiuose kodų repozitorijose rado anksčiau nepraneštų klaidų.
Testai yra gerai. Bet testai dažnai tikrina tai, ką sugalvojome patikrinti. Kraštiniai atvejai kartais sėdi kampe tyliai, kol vieną penktadienį 17:12 nusprendžia pasirodyti.
Kodėl tai svarbu
Leanstral 1.5 svarbus todėl, kad DI pradeda padėti ne tik rašyti kodą, bet ir įrodinėti savybes: ar funkcija neperžengia ribų, ar algoritmas laikosi pažado, ar sudėtingas atvejis nesugrius.
DI jau nebe vien langelis, į kurį įmetame tekstą. Jis jungiasi prie įrankių, moka kviesti servisus, gali veikti keliais žingsniais ir pradeda liesti tikrus verslo pinigus. Čia romantika baigiasi. Prasideda tvarka.
Ką tai reiškia verslui
Verslui tai ypač aktualu ten, kur klaidos brangios: finansai, saugumas, infrastruktūra, medicininės sistemos, kriptografija, kritinis backend kodas. Ne kiekvienai svetainei reikia formalios verifikacijos, bet kai reikia – labai reikia.
- rinktis formalų tikrinimą kritinėms dalims
- naudoti DI kaip proof engineering pagalbininką
- nepainioti formalios verifikacijos su paprastais testais
- skaičiuoti riziką pagal klaidos kainą
Pavyzdys: mokėjimų sistemoje verta formaliai tikrinti skaičiavimo ar būsenų logiką, o ne kiekvieną mygtuko tekstą. Čia reikia ne fanatizmo, o sveiko prioriteto.
Kur pasislėpusi rizika
Rizika – manyti, kad modelis pats tampa auditoriumi. Jis gali padėti kurti įrodymus, bet komanda turi suprasti, ką įrodinėja ir kur rezultatas naudojamas.
Blogiausia DI klaida dažnai neatrodo kaip klaida. Ji ateina gražiai parašytu sakiniu, mandagiu tonu ir labai užtikrintu veidu. Todėl verslui reikia ne tik įrankių, bet ir įpročio tikrinti.
Ką pasidaryti šią savaitę
Paklauskite savęs: kuri jūsų sistemos dalis būtų brangiausia, jei tyliai suklystų? Ten verta pradėti kalbą apie griežtesnį tikrinimą.
Rašome apie dirbtinį intelektą lietuviškai. Kiekvienas straipsnis parengtas pagal nurodytą šaltinį, o nuorodą į originalą rasite kortelėje „Šaltinis“.
