Dirbtinis intelektas pastatų priežiūros srityje: paveldo apsaugos ateitis

Ačiū, kad šiandien su mumis kalbatės, Lukai. Ar galėtumėte pradėti nuo projekto pristatymo?

Pagrindinis šio "GovTech" projekto tikslas buvo sukurti programėlę, kuri supaprastintų kultūros paveldo pastatų ataskaitų kūrimo procesą. Ataskaitoje pateikiama pastato apžvalga, kartu su automatiškai ir rankiniu būdu iš naudotojo darytų nuotraukų aptiktais defektais, jų priežastimis, galimais taisymo sprendimais ir pastato priežiūros planu.

Gal galėtumėte išsamiau papasakoti apie problemą, dėl kurios reikėjo naujo sprendimo?

Šiuo metu pastatų priežiūros procesas reikalauja daug darbo ir laiko. Analitikų komanda turi apsilankyti pastate, fotografuoti, nustatyti defektus ir rankiniu būdu parengti ataskaitą. Naudodamasis mūsų sprendimu, savininkas dabar ataskaitą gali gauti iš karto. Jam tereikia paruošti nuotraukas ir kitą informaciją apie pastatą bei įkelti ją į programėlę. Tada jie gali peržiūrėti mūsų modelyje nurodytus defektus. Po šios patikros sugeneruojama ir naudotojui pateikiama PDF formato ataskaita.

Kaip, jūsų nuomone, tai paveiks paveldo apsaugą?

Įmonės arba šios programos naudotojai gali sutaupyti laiko ir išteklių ataskaitų kūrimo procese, todėl šis projektas prisideda prie platesnės procesų automatizavimo tendencijos, kai rankiniai procesai perkeliami į IT sistemas. Tai ypač aktualu viešojo sektoriaus įstaigoms, tokioms kaip mūsų klientas, kartu galime užtikrinti, kad valstybė būtų aprūpinta moderniausiais sprendimais ir pasirengusi skaitmeniniam amžiui.

Ar matote šio produkto panaudojimo galimybių už Lietuvos ribų? Ar jis gali būti pritaikytas kitur?

Programėlė išversta į anglų kalbą, todėl ją galima pritaikyti panašioms sistemoms kitose šalyse. Neabejotina, kad kiekviena šalis turi reikšmingą architektūros paveldą, kurį reikia nuolat saugoti, todėl yra daugybė pritaikymo galimybių.

Koks buvo didžiausias šio projekto pasiekimas?

Didžiausias pasiekimas - per labai trumpą laiką įvykdyti visus pagrindinius programėlės reikalavimus. Pagrindiniai reikalavimai buvo šie:

  1. Pastato informacijos įvedimo funkcija, leidžianti naudotojui įvesti informaciją ir įkelti pastato nuotraukas, buvo mažiausiai sudėtinga įgyvendinti.

  2. Automatinio pastato defektų aptikimo funkcija, leidžianti naudotojui gauti automatiškai aptiktus defektus. Tai buvo sudėtingiausia funkcija, nes reikėjo apmokyti defektų aptikimo modelį naudojant didelį kliento duomenų kiekį, įskaitant tūkstančius įvairių pastatų ir įvairių tipų defektų nuotraukų.

  3. Pastatų defektų aptikimo funkcija rankiniu būdu, skirta naudotojui atnaujinti automatiškai aptiktus defektus, jei modelyje padaryta klaida. Siekėme didelio patogumo naudotojui, todėl ji buvo vidutinio sudėtingumo.

  4. Ataskaitų kūrimo funkcija, kad naudotojas galėtų atsisiųsti sukurtą pastato informacijos ir nustatytų defektų ataskaitą. Šiai funkcijai reikėjo sukurti taisyklėmis pagrįstą modelį, skirtą įvairiems scenarijams nagrinėti.

Ar su projektu buvo susijusi kokia nors rizika ir kaip ją sumažinote?

Manau, kad didžiausia rizika buvo nebaigti projekto laiku. Kad ją sumažintume, išlaikėme nedidelį programėlės sudėtingumą ir svarbiausius reikalavimus iškėlėme į pirmą vietą. Mažesnį sudėtingumą pasiekėme sukūrę paprastesnę sistemos architektūrą. Sistema neturi būsenos, o visus procesus palengvina nuolatinis ryšys tarp naudotojo sąsajos ir serverio.

Ar vis dar dalyvaujate prižiūrint šį modelį, ar tai perėmė klientas?

Taip, nuolat tobuliname ir prižiūrime programėlę. Stengiamės didinti defektų nustatymo modelio tikslumą ir naudotojo sąsajos dizainą. Vykdydami techninę priežiūrą šaliname klaidas, remdamiesi klientų atsiliepimais, ir užtikriname bendrą prieinamumą.

Previous
Previous

AAI Labs pradėjo tris su 5G susijusius projektus

Next
Next

Audioknygos ateityje: pažangiausios platformos, skirtos mažai išteklių turinčioms kalboms, kūrimas