Kodėl vien teisingumo neužtenka

Kodo generavimo modeliai vertinami daugiausia pagal tai, kiek užduočių jie išsprendžia teisingai – populiariausi etalonai matuoja funkcijų lygio sprendimų taisyklingumą. Tačiau realūs programavimo projektai retai būna atskiri funkcijų failai: jie reikalauja nuoseklaus kūrimo, priklausomybių valdymo ir gebėjimo išlaikyti kontekstą per keliasdešimt sąveikų. Nauja tyrimų metodika šią spragą bando užpildyti vertindama ne vien automatinius testus, bet ir kodo kokybę bei programuotojų atsiliepimus.

Naujojo požiūrio esmė – trys vienu metu veikiantys vertinimo kanalai. Tyrėjai sukūrė specialų etaloną, pagrįstą sudėtingu bioinformatikos projektu „Building the Tree of Life from Scratch“, ir juo patikrino tris bendrosios paskirties didžiuosius kalbos modelius: GPT-4.1, DeepSeek-V3-0324 ir Claude Opus 4. Modeliams buvo pateikta 14 iš anksto apibrėžtų užuominų, vedančių per visą projektą – nuo DNR sekų analizės iki filogenetinių medžių kūrimo – be jokio pradinio kodo šablono.

Vertinimo sistema apima automatinius vienetų testus tikslumui patikrinti, statinę analizę kodo kokybei įvertinti ir struktūruotą programuotojų apklausą, kuri atliekama per kodo peržiūros procesą. Būtent žmogiškasis vertinimas, pasak autorių, leidžia pastebėti, ar sugeneruotas kodas yra „parengtas gamybai“ – mato, kurio nepasiekia joks automatizuotas testas.

Formalių kontraktų barjeras

Paraleliai atliekami tyrimai su formalaus verifikavimo įrankiu Dafny atskleidžia dar vieną silpnybę: net kai kodas veikia, jį sunku paversti matematiškai įrodomu. Bandymai versti natūralią kalbą į Dafny reikalaujamus formalius parašus, prieš- ir po-sąlygas rodo, kad didžioji dalis modelių, įskaitant GPT OSS 120B ir Qwen serijas, be papildomų gairių negeneravo nė vieno sėkmingai verifikuoto sprendimo.

Eksperimentai parodė, kad kai modeliams pateikiamos struktūrinės gairės (vadinamasis signatūrinis užuominų teikimas), kuriose nurodomi funkcijų parašai ir kontraktų šablonai, situacija apverčiama – nesėkmių, užfiksuotų konteksto stokojančioje aplinkoje, smarkiai sumažėja. Vis dėlto gebėjimas save taisyti (angl. self-healing) stipriai priklauso nuo pradinės užuominos kokybės: kuo tikslesnis pirmas bandymas, tuo didesnė tikimybė, kad verifikavimo klaidos bus pašalintos.

Ką atskleidžia programuotojų akys

Grįžtant prie projekto lygmens vertinimo, raktinis skirtumas slypi žmogaus atliekamoje peržiūroje. Automatiniai testai patvirtina, ar išvestis atitinka lūkesčius (pavyzdžiui, Needlemano–Wunsho balai išsaugomi JSON formatu, filogenetiniai medžiai – Newick notacija). Tačiau tik tikri programuotojai pastebi, ar kodas aiškus, pavyzdingai struktūrizuotas ir lengvai prižiūrimas po kelių mėnesių pertraukos. Šis aspektas ypač svarbus, kai kodo generavimo modeliai naudojami ne vienkartiniams skriptams, o nuosekliai kuriamiems programiniams produktams.

Vis dar atviras lieka klausimas, ar programuotojų vertinimai gali būti pakeisti vadinamaisiais „LLM-kaip-teisėjas“ metodais, tokiais kaip CompassJudger-1 – modeliu, specialiai perkvalifikuotu lyginti dviejų kitų modelių atsakymus ar generuoti šių atsakymų analizę. Nors automatizavimas mažina kaštus, žmogiškasis įvertinimas kol kas išlieka vienintelis būdas užčiuopti priežiūros ir panaudojamumo problemas.

Sujungus projekto lygmens etalonus su programuotojų apklausomis ir formalaus verifikavimo iššūkiais, aiškėja svarbi išvada: išsamus didžiųjų kalbos modelių vertinimas privalo aprėpti ne tik funkcinį teisingumą, bet ir kodo kokybę bei gebėjimą veikti patikimumui kritiškose srityse. Tai ypač aktualu, kai modeliai taikomi nuo nulio kuriamiems sprendimams, o ne izoliuotoms funkcijoms – tokiu atveju kiekvienas perėjimas tarp užuominų ir kiekviena priklausomybė tarp failų tampa galimu klaidų tašku, kurį pastebėti gali tik daugiasluoksnis vertinimas.

Šaltiniai

  1. [1] [X.com] Announcing Robostral Navigate, our first model for embodied navigation: an 8B robotics navigation model that guides robo