Egy egyszerűbb alkalmazást ma már nem feltétlenül kell kézzel megírni. Elég pontosan elmondani, mit várunk a géptől, és az összeállítja: felületet tervez, háttérrendszert épít, teszteket készít, adatokat elemez, sőt más eszközöket is vezényel, ha képre vagy grafikai elemre van szükség. Ami néhány éve még programozói rutinfeladat volt, ma egyre inkább mérnöki irányítás.

Dr. Bilicki Vilmos szerint ezért nem az a kérdés, hogy eltűnik-e a programozó. Az a programozó tűnik el, aki csak kódot ír. A szoftvermérnök viszont fontosabb lesz, mint valaha: neki kell értenie a problémát, kontextust adnia a gépnek, ellenőriznie az eredményt, és eldöntenie, mikor válhat egy működő prototípus valódi, felelős rendszerré.

Az SZTE szoftverfejlesztő kutatójával, akinek neve az újszülöttek légzésének monitorozásától a szúnyogzümmögés azonosításán át a mentális betegségek szűréséig számos projektben felbukkan, gépi kollégákról, kontextusmérnökségről, feketedoboz-modellekről és arról beszélgettünk, miért állhat meg egy ígéretes orvosi MI-alkalmazás a tanúsítás kapujában.

A gép már nemcsak segít, hanem dolgozik

– Mit változtatott a mesterséges intelligencia egy szoftverfejlesztő mindennapjain?

– Most nagy kapuk nyílnak ki. A belépő szintű fejlesztés – mondjuk egy prototípus elkészítése – ma talán már programozói tudás nélkül is elvégezhető: scripteket, kis alkalmazásokat egy jogász is meg tud íratni a géppel. Az MI-vel támogatott eszköztárral mobil- vagy webalkalmazást lehet fejleszteni, adatokat lehet elemezni úgy, hogy közben nem kell a Python-kódhoz értenem – elég pontosan megadnom, mit várok. Az eredmény nem tökéletes, vannak még buktatók, de egy egyszerűbb alkalmazást a gép úgy is összerak, hogy nem programozom.

Ráadásul a teljes láncot lefedi a felhasználói felülettől a háttérrendszerig. Egy kódoló ágens, mint a Codex, a grafikai munkát is megszervezi: utasításra előállíttatja és szétdarabolja a képeket, és beilleszti a grafikus elemeket – nem maga rajzol, hanem a megfelelő eszközöket vezényli. És elvégzi azt a rutinszerű, időigényes munkát is, amit a fejlesztők gyakran halogattak – például a tesztek különféle válfajait. Ezért emelkedik a munkánk absztrakciós szintje: a kód bepötyögése helyett inkább olyan mérnökként viselkedünk, akinek gépi kollégái vannak. Kötöttségei persze vannak – a memória terjedelme, vagy hogy az adott modell mennyire tud önállóan jól tervezni –, de ez a határ is egyre följebb csúszik.

A programozó eltűnik, a mérnök felértékelődik. Az új kulcsszó: kontextusmérnökség

Dr. Bilicki Vilmos csoportja évek óta más tudományterületek problémáit fordítja működő mérnöki rendszerekké – újszülött-monitorozást, agrárszenzorokat, klinikai szűrőket. Éppen ezért látja élesen, hogy nem a szakma tűnik el, hanem a benne végzett munka szintje tolódik feljebb. Az SZTE szoftverfejlesztő kutatója úgy látja, ha a gép már képes kódot írni, a következő kérdés nem az, hogyan írassunk vele még több kódot – hanem az, hogyan értse meg azt a világot, amelyben dolgoznia kell. Egy nagy szoftver ugyanis nem fér bele a modell memóriájába. A mérnök új feladata ezért nemcsak az utasításadás, hanem a kontextus megtervezése.

– Akkor a programozó el fog tűnni?

– Az a programozó tűnik el, akit eddig ismertünk – aki a kódot írta. Mi már nem programozói, hanem szoftvermérnöki munkát végzünk, és erre készítjük fel a hallgatókat is. A programozó a kódot írta; a mérnök a teljes kontextust ismeri. Az MI megjelenésével a munkánk átlép erre a másik szintre: inkább tervezni kell, kevésbé megvalósítani.

– Hogyan adja át a gépnek azt a tudást, amivel egy meglévő, nagy rendszerben dolgozni tud? Hiszen a gép nem ismerheti azt a kódot, amelybe integrálják.

– Az információátadásnál a helyi szabályok, minták ismerete mindenhol fontos – ugyanúgy, ahogy egy junior és egy senior kolléga között is. Meg kell tanulnunk ezeket jól, tömören leírni: melyik mintákat használja az adott projekt, hol a kódbázis, milyen interfészek vannak – éppen azokat a részleteket, amelyek kellenek neki, hogy ne írjon újra valamit, és ne teljesen másképp csinálja, mint ahogy eddig. Ez egyáltalán nem triviális; külön neve is van a szakterületnek: kontextusmérnökség, angolul context engineering.

Mert mi a baj? A gépnek van egy memóriája – a mai modelleknél nagyságrendileg egymillió token, ami durván néhány millió karakter. Egy nagy szoftver ebbe nem fér bele. A modell a világot ismeri, mert az internet adataiból tanult, de az én kódomat nem. Ezért absztrakció szintű leírást adok neki, hogy a memóriájában maradjon hely a tényleges munkára is. Gondoljon egy mérnöki munkára: megvan az egész épület áttekintő tervrajza, de az nem tartalmaz minden részletet; ha a vizesblokk csövezésére vagyok kíváncsi, előveszem a részletes tervet. A szoftvernél is fel kell építeni ezt a piramist: az alján a kódsorok, fölötte egyre tömörebb információk. Az MI-nek a modulokat és a szerepüket mondom el; a kódot magát nem, mert ha kell neki, hozzáfér, és visszakérdez, amikor egy részletre szüksége van.

Dr. Bilicki Vilmos, az SZTE Szoftverfejlesztés Tanszékének egyetemi docense. Fotó: Bartha Karina

Mit tanítsunk, ha a gép is kódol?

– Ön egyes tárgyakon a hallgatókat nem a kódírásra, hanem a kód megíratására tanítja. Majd lesz olyan fejlesztő, aki kódot már nem is tud olvasni?

– Olvasni biztosan tudnia kell! De kezdjük ott, hogyan jutottunk idáig. A szakma gyorsan változik: az a képesség, hogy az MI ennyire jól fejleszt, egy 2025 végi modellgenerációval vált igazán kézzelfoghatóvá – ezt sok tapasztalt fejlesztő is egyértelmű lépcsőként élte meg. Nem mintha korábban használhatatlan lett volna; inkább addig a megbízhatósága és a sebessége miatt egy jó fejlesztőnek nem mindig érte meg rábíznia magát, ma viszont egyértelműen gyorsabb az embernél. Hangsúlyozom: ez nem szakmai konszenzus, hanem az én olvasatom.

Vissza tehát az olvasáshoz: a kód megértését nem felejthetjük el. A gép által gyártott kód nem lehet feketedoboz a fejlesztő számára. Valószínűleg nem soronként nézzük majd át, és nem is mi írjuk – de választanunk kell egy ellenőrzési paradigmát, és a kódolvasás mint tudás megkerülhetetlen marad. A rutinszerű, kézi kódírás súlya viszont radikálisan csökken: nem az lesz a fő tudás, hogy valaki soronként megírja a kódot, hanem hogy megértse, specifikálja, ellenőrizze és felelősen beillessze a rendszerbe.

– Az oktatás hogyan tart lépést ezzel?

– Nehezen, mert lassabb a dinamikája, mint a modelleké – gondoljon csak egy éves hálóterv elfogadására. A területet napi szinten követni kell – nálam ez puritán: néhány tudományos csatorna és gyűjtőportál, például a Hugging Face hírlevelei –, mert a modellek gyorsabban változnak, mint az oktatási programok. A képzésben éppen ezért nem az operatív rész a hangsúlyos: nem az Android aktuális API-ja az érdekes, hanem a miértek, a tartós mérnöki tudás. Egy jó alapozó anyagból eddig is hét évig el lehetett tanítani az alapokat, és ez a tudás valószínűleg sokáig érvényes marad. A hallgatók egyébként, akik járnak az MI-vel való fejlesztés kurzusra, felkészültebben jönnek ki, és nálam a szak- és diplomadolgozatok is mélyebbek lettek.

A jól működő modell még nem megbízható rendszer

Csakhogy attól, hogy a gép megírja a kódot, a felelősség nem tűnik el – sőt, nehezebb lesz megmondani, pontosan hol van. A hagyományos szoftvernél legalább elvileg végigolvasható, mi történik. Egy MI-modellnél a működés sokszor akkor is feketedoboz, ha maga a rendszer ott van előttünk.

– Mikor jár valódi előnnyel egy MI-modell egy szoftverben – és honnan tudja, hogy megbízható?

– Van olyan feladat, amelyet a modell egyszerűen pontosabban végez el. Tegyük fel, van egy zavaros szövegfájlunk: az ember elolvassa, bosszankodik, de megérti a lényegét. Ha ezt kézzel megírt szabályokkal próbálom feldolgozni, mindig lesz egy minta, amelyre nem vonatkozott szabály, és elhasal a szoftverem. Klasszikus esetben a programozó elmondja a heurisztikát, leprogramozza, és megnézi a végét; az MI esetében a fejlesztő az elejét meg a végét mondja el, a közepét a modell találja ki. Csak éppen ennek a működése ugyanúgy feketedoboz, mint a többi szoftverkomponensé.

Hogy megbízható-e, azt mindkét esetben a tesztelés dönti el. A hagyományos szoftvernél is ritka, hogy formálisan, vagyis matematikailag garantáltan helyes legyen – a hatalmas állapottér miatt az ellenőrzés a gyakorlatban mindig valószínűségi: egy nagy teszthalmazon mérünk. Az MI-t végső soron ugyanígy, tesztekkel validáljuk – a különbség inkább abban van, hogy mit látunk a motorháztető alatt.

– És ha más környezetben mást ad – mondjuk az egyik kórházban működik, a másikban sok a téves jelzés?

– Az adateltolódás létező jelenség, de generikus, mérnöki probléma, nem az MI sajátja. Egy ember írta szoftvernél is: ha a tesztelésnél csak a kód lefedettségét nézem, örülhetek, hogy minden sor lefutott – de nem minden adatfajtával! Ami viszont tényleg az MI sajátja: nem értem meg az általa hozott döntés belső logikáját. Egy Python-kódra ránézek, akármekkora, és értem, mi van benne. Az MI-nél látom a kódot, látom a rengeteg kapcsolót – csak nem biztos, hogy értem. A teljes modell előttem van, a működése mégis feketedoboz.

Amikor a modell rossz dolgot tanul meg

A feketedoboz-probléma azonban nem elméleti. Előfordul, hogy a modell látszólag orvosi mintázatot tanul meg, valójában viszont egy vonalzót, egy beteget vagy egy adatrögzítési szokást ismer fel.

– Ha maga a kód nem rejtett, honnan ered mégis a nem-értés, és van-e remény megérteni?

– Onnan, hogy van egymilliárd kapcsoló, össze vannak kötve, de a kapcsolatok nem átláthatók. A működésben rétegeket, rétegenként megjelenő tudást keresünk – nem véletlen a párhuzam az aggyal, ahol tomográfiával próbálják feltérképezni, mikor melyik terület aktiválódik. Látványos eszköz például a SHAP, amely megmutatja, hogy a bemenet egyes részei mekkora súllyal járultak hozzá a kimenethez: egy levél vagy egy röntgenkép esetében kirajzolódik, mely régiókat vette figyelembe a modell. De a magyarázhatóság nem mindent vagy semmit kérdés: néha látjuk, melyik képrégió számított, néha azt, hogy melyik bemeneti jellemző volt fontos; a teljes „miért” viszont sokszor nem fejthető vissza.

– Olvastam egy esetről: egy melanóma-felismerő minden képet kórosnak ítélt, amelyen ott volt egy vonalzó. Kiküszöbölhető minden ilyen tévedés?

– Itt érdemes két, gyakran összemosott jelenséget szétválasztani. A vonalzós eset rátanulás egy hamis együttjárásra: a modell egy irreleváns, de a beteg esetekkel együtt megjelenő jegyre – a vonalzóra – tanul rá a tényleges elváltozás helyett. Ez nem a tanító- és a validációs halmaz összekeveredése, hanem egy zavaró tényező, amely élesben is ott lehetne a képen.

A másik jelenség a tényleges adatszivárgás. Nekünk is volt rá példánk: egy körömbetegségre tanított modellünk meglepően jól ismerte fel a magas vérnyomást. Csakhogy nem a betegséget ismerte fel, hanem a beteget – a bőrén volt egy jellegzetesség, és ugyanaz a személy szerepelt a tanító- és a validációs halmazban is, ráadásul magas vérnyomásos volt. Ez alany-szintű átfedés a két halmaz között, vagyis valódi szivárgás.

A megoldás mindkettőre a tanítás módjában van: ki kell küszöbölni az egyénre vagy a környezetre jellemző, irreleváns jegyeket. És ugyanez a tudatosság kell az elfogultság ellen is: ha az adathalmaz túlnyomórészt egészséges emberektől származik, a modell hajlamos mindenkit egészségesnek mondani, ezért célzottan kell mintát venni a másik csoportból is. Van egy jó ökölszabály: ha egy modell gyanúsan jól működik, az figyelmeztető jel – az adattudomány éppen ilyenkor ösztönöz hibakeresésre.

Fotó: Bartha Karina

Amikor a gépnek is csapata lesz

A következő lépés nem az, hogy egyetlen modell jobb programozó lesz, hanem hogy több, specializált modell kezd együtt dolgozni: az egyik ágens tervez, a másik végrehajt, a harmadik ellenőriz.

– Hol tartanak az ágensek? Magára lehet hagyni egy szoftvert, mondjuk egy beteg állapotának követésére?

– A lényeg a lépésszám: hány lépésen át tud futni a modell anélkül, hogy hibázna. Ha hetente van egy mérés, sokáig elműködik hibátlanul; ha percenként kell mérnie, hamarabb elcsúszik. A képességére van egy bevett mérőszám is: a legfejlettebb modellek ma már 7–14 órás feladatokat is megoldanak. Csak vigyázni kell, mit jelent ez. Nem azt, hogy a gép 14 órát dolgozik – ennél rendszerint sokkal gyorsabb. A 14 óra a feladat nehézségét méri: ennyi ideig tartana egy embernek, és a modell az ekkora feladatot 50 százalék körüli sikerességgel teljesíti.

Ezért egy ritka, jól specifikált, ember által felügyelt utánkövetés már reálisabb feladat, mint a folyamatos, beavatkozással járó autonóm működés – minél sűrűbb a beavatkozás, annál rövidebb a hibátlan lánc. A működés egyébként ugyanaz, akár beteget követünk, akár szoftvert fejlesztünk: az ágens tervet készít, nekiáll, majd lépésenként ellenőrzi, mennyire volt jó. Éppen ez az önellenőrzés az, ami egyre hosszabb láncon át kezd működni.

– Mit ad ehhez hozzá, ha több ágens dolgozik együtt?

– Ez teszi lehetővé a specializációt, ugyanúgy, ahogy egy emberi csapat is specializálódik. Van a menedzser, aki nem látja a kódot, de tudja, merre kell menni; van a mérnök, aki tudja, hogyan kell megszervezni; és vannak a végrehajtók, akik meg is csinálják. Kvázi okos ügynökök munkáját vezényeljük – és közben éppen ebben a folyamatban kell tudni hibát keresni: ki kivel beszélt, hol romlott el a folyamat. Gondolja el: ha egy-egy ágens bizonyos részfeladatokban emberi szintű teljesítményhez közelít, akkor egy jól vezényelt gépi csapat már nagyon jelentős munkát tud elvégezni.

Az orvosi MI-nél ütközik ki a tét

A technológiai kérdés itt válik valódi társadalmi kérdéssé. Egy prototípus működhet, egy modell pontos lehet, egy kutatási eredmény ígéretes lehet. De amikor betegadatról, diagnózisról vagy beavatkozásról van szó, már nem elég, hogy „működik”: tanúsíthatónak, auditálhatónak és felelősen bevezethetőnek kell lennie. A gép megírja a kódot. A felelősség – a megértés, az ellenőrzés, a tanúsítás – továbbra is emberi és mérnöki marad.

– Létezhet olyan fejlett MI, amely egy orvoshoz mérve önállóan, megbízhatóan diagnosztizál?

– Ez területfüggő. A gép nyers feldolgozóképessége és memóriája sok területen meghaladhatja az emberét: több esetet, több szakirodalmat, több paramétert tud egyszerre figyelembe venni. A műtéteknél ismerheti az összes rögzített eset videóját; gondoljon bele, egy sebész hány műtétet láthat életében, és egy gép elvileg a világ összesét. A ritka betegségeknél ez még hangsúlyosabb: ott az orvos nekiáll átnézni a szakirodalmat, a gép viszont elvileg ezt mind „olvasta” már.

De az orvosi döntésben nemcsak elemzés van, hanem felelősség, betegkommunikáció, klinikai kontextus és szabályozott folyamat is. Ezért az ember szerepe rövid távon nem eltűnik, hanem áthelyeződik: a validálásban, a felügyeletben és a döntési felelősségben marad kulcsfontosságú. Az elemző munka nagy részét a gép hatékonyan elvégezheti – a végső felelősség viszont emberi.

– Nemrég a stresszállapot kijelzésére is fejlesztettek egy biomarker-alapú alkalmazást. Ez eljutott a gyakorlatba?

– A stressznek több élettani jellemzője van, és többféle megbízható jelből is kimutatható – ilyenek az EEG-alapú mutatók éppúgy, mint a szívfrekvencia ingadozási szélessége, a HRV. Olyan algoritmust építettünk, amely megbecsüli a stressz szintjét; a tervezésnél arra építettünk, hogy a stresszcsökkentés tudatos is lehet, hiszen a légzésünk ritmusán és a szívverés ütemén is tudunk változtatni. Az alkalmazás magas stresszszintnél visszacsatolást ad használójának. A kiskunhalasi kórház sürgősségi osztályán próbáltuk ki: a felhasználók egy része az alkalmazást használta, mások csak zenét hallgattak – és az eredmény igazolta, hogy az alkalmazás használói jobban kezelték a stresszüket. És itt kezdődik a valódi nehézség: ehhez most céges partnert keresünk, hogy orvosi eszközként egyáltalán tanúsíttathassuk.

– Egy másik alkalmazásuk a skizofrénia és a bipoláris zavar szűrésére alkalmas. Ezt miért nem használják még?

– Mert az orvosi alkalmazások bevezetése hosszadalmas és szigorúan szabályozott. Erre a modellre egy aktigráffal működő szűrőalkalmazás épülhetne, de az ilyen eszközök tanúsításához az európai orvostechnikai rendelet, az MDR költséges és időigényes feltételeket szab: nagyjából két év és 100 millió forint, ami a piacon vagy megtérül, vagy nem. Az MDR mellett ma már az AI Acttel való együttélés is újabb megfelelőségi réteget jelent az ilyen rendszereknél.

És itt van a valódi feszültség. Az MI fejlődési üteme mellett két év nagyon hosszú idő. Ha most lezárjuk a fejlesztést, és nekiállunk két évig pecséteket gyűjteni, a végére a mai csúcs már elavult lesz. Vagyis nem feltétlenül azon múlik, elég ügyesek voltunk-e – inkább azon, hogy az MI órája és a szabályozás órája teljesen más tempóban jár. Sok helyen születnek így eredmények, amelyek megállnak ott, hogy elkészültek, és nem jutnak el az orvosig. A prototípust ma már könnyebb megcsinálni; a nehéz az, hogy ellenőrizhető, tanúsítható, valóban használható rendszer legyen belőle. Mi a partnereinkkel éppen erre törekszünk – és az orvoslásban lenne ennek a legnagyobb tétje.

Panek Sándor

A borítóképen: Dr. Bilicki Vilmos, az SZTE Szoftverfejlesztés Tanszékének egyetemi docense. Fotó: Bartha Karina