1. Kirjeldus

Rakenduse arhitektuur on loodud tehnilises kirjelduses välja toodud funktsionaalseid ja mittefunktsionaalseid nõudeid arvestades ning silmas pidades ka seda, et tulevikus oleks võimalus süsteemile lisada uusi võimekusi, nagu näiteks helifailide töötlus või muid masinõppel põhinevaid funktsioone.

Kommunikatsioon rakenduse komponentide vahel on hallatud läbi REST API päringute ja sõnumiteenuse. Komponendid, mille puhul võib eeldada suuremat ressursivajadust või eripäraseid tehnoloogilisi nõudeid ning mis ei vaja sünkroonset suhtlust, on seatud suhtlema sõnumiteenuse kaudu.

Kasutaja poole on suunatud kaks komponenti - Tellija moodul ja Tõlketöö moodul - mida on kirjeldatud allpool. Nende eraldihoidmise valiku taga on nende erinev kasutusmuster ning erinevad tehnoloogilised valikud, mis on vajalik funktsionaalsuse jaoks.

Väljapakutud arhitektuur võimaldab täita etteantud nõudeid arendusele ning lisaks ka analüüsi käigus selgunud nõudeid.

2. Kasutusjoonis

Joonis 1. Süsteemi kasutusdiagramm UML notatsioonis

3. Arhitektuurimudel

Joonis 2: Komponentdiagramm ArchiMate notatsioonis


Joonis 3: Komponentdiagramm UML notatsioonis. Loetavuse säilimiseks Andmebaasi teenindusmoodul toodud eraldi välja allpool, joonisel 4.

3.1. Identiteedihaldus

Identiteedihaldus on korraldatud läbi Riigi autentimisteenuse (TARA) ja rakendusesisese rollihaldussüsteemi. Rakendusse logides suunatakse kasutaja TARA lehele, kus tal on võimalik sisse logida TARA toetatud sisselogimisvahenditega, sh ID-kaart, mobiil-ID ja smart-ID.

Protsessi lõpus tagastab TARA käesolevale rakendusele identsustõendi, mille abil on võimalik tuvastada kasutaja roll ning sellega kaasnevad õigused käesolevas rakenduses. Täpne autentimisprotseduur on pikemalt selgitatud TARA kasutusjuhendis.

Kõik hilisemad päringud rakenduse komponentidele teostatakse autentimisküpsise ja kehtiva sessiooni abiga.

3.2. Liidestuste haldus

Süsteemil on nii liidestusi, kus süsteem ise on tarbija, kui ka neid, kus tarbitakse süsteemi teenuseid. Liidestustes, kus süsteem ise on tarbija, on vaja iga liidestus manuaalselt konfigureerida ehk uute allikate, nagu näiteks terminibaasid või X-tee teenused, liidestamise puhul on vajalik lisaarendus.

Liidestused, kus süsteem pakub tarbitavaid teenuseid, on kergemini hallatavad. Praeguses plaanis on ainsaks selliseks liidestuspunktiks ka väliste teenuste tõlkemoodul. Kuna teenusesse ilmselgelt ei saa lubada täiesti suvalisi päringuid, vaid vajalik on autoriseerimine, siis on võimalik hallata selliseid liidestusi läbi API võtmete. Üks võimalik ja laialdaselt kasutatud lahendus käib nii:

  1. Iga kasutaja, kes tahab platvormiga liidestuda, teeb endale kasutajakonto.
  2. Konto omanikuna saab ta nüüd genereerida endale API võtme.
  3. Päringud välisest tööriistast (nt sirviku, Tradose või MemoQ plugin) tehakse selle API võtmega.

See tähendab, et kõik päringud on võimalik ühendada konkreetse kasutajaga. See annab võimaluse genereerida päringute kohta statistikat, piirata API programmilise kasutuse määra ja sulgeda API võtmeid, mis käituvad süsteemi suhtes mitteheaperemehelikult.

3.3. Komponentide kirjeldus

3.3.1. Rollihaldus

Rollihalduskomponent on osa identiteedihaldusest. Selles hallatakse rakenduses defineeritud rolle ja isikuid, kellele need rollid on määratud. Ühele isikule võib olla määratud mitu rolli.

Isik tuvastatakse kasutaja poole suunatud rakenduse poolt läbi TARA ning tuvastatud isiku rolle kontrollitakse läbi rollihalduskomponendi. Isikut ja nendega seotud rolle hoitakse andmebaasis.

3.3.2. Tellija moodul

Tellija moodul on loogiliselt eraldiseisev komponent ning vahendab teenuseid, mis on seotud tõlketeenuse tellimisega. Rakenduses on võimalik täita tõlketaotlus, lisada failid ja vajadusel tõlkemälu, edastada see süsteemi ning jälgida selle seisu. Samuti saab läbi rakenduse võtta tõlketöö vastu, kui töö on valmis ja kvaliteedilt sobiv või suunata see tagasi.

Failid - nii tekst kui heli -, mis laetakse tõlketööga üles, salvestatakse failisüsteemi krüpteeritult ning tekstifailidest eraldatakse tekst, mis lisatakse andmebaasi.

Lisatud tõlkemälu saadetakse tõlkemälu haldusrakendusse anonümiseerimiseks.

Liidestused:

  • Kirjutab andmebaasi tõlketöö ja seotud info.
  • Saadab töid teavitusrakendusele sõnumiteenuse kaudu.
  • Saadab töid tõlkemälu haldusrakendusele sõnumiteenuse kaudu.
  • Salvestab failisüsteemi originaaldokumendid ja helifailid.
  • Kasutab TARA liidest kasutaja identifitseerimiseks.
  • Pärib rollihalduselt identifitseeritud kasutaja rolle.

3.3.3. Tõlketöö moodul

Peamine kasutajale suunatud moodul süsteemis. Vahendab funktsionaalsusi, mis on vajalikud kõigile rollidele peale tõlke tellija:

  • Tõlkekorraldaja
  • Tõlkija
  • Toimetaja
  • Peakasutaja
  • Tõlkemälude haldur (omanik)
  • Süsteemihaldur

Alamkomponendid/vaated:

  • Tõlkekorraldusmoodul - Teostab tõlgitava teksti eelanalüüsi ning võimaldab seada ja muuta tõlkeprojekti töövoogu ja selle atribuute, nagu tõlkija või tõlkebüroo, maksumus, terminikogud, tõkemälud jne. Ligipääsetav funktsionaalsus sõltub kasutaja rollist. Väline liidestus SAP-iga, kust päritakse informatsiooni ametnike tööaja kohta tõlketöö planeerimiseks.
  • Tõlkemoodul - Pakub tõlkijale tõlketööks töövahendeid. Vahendab automaattõlkemooduli funktsionaalsust.
  • Toimetusmoodul - Pakub vahendeid teksti toimetamiseks. Moodul on olemuselt sarnane tõlkija kasutatava mooduliga. Lisaks koostab toimetaja tehtud paranduste põhjal raporteid.
  • Statistikamoodul - Kuvab statistikuid ja raporteid mooduli töö kohta, mida koostab statistika kogumise moodul.
  • Töövoogude haldusmoodul - Võimaldab defineerida ja hallata töövoogusid.
  • Tõlkemälude haldus - Võimaldab tõlkemälusid sirvida, muuta, importida ja eksportida, seada ja muuta kasutuspiiranguid. Kuvab uuendusettepanekuid ja lubab neid vastu võtta või tagasi lükata.
  • Terminoloogiakogude haldus - Võimaldab terminoloogiakogusid sirvida, muuta, importida ja eksportida.

Võimalikud tõlketööriistad on välja toodud peatükis 6.1. Alternatiivide analüüs - Keskne tõlkekeskkond - RIK Avalik Conflu punktis 7.2.

Liidestused:

  • Loeb andmebaasist statistikuid ja statistika raporteid.
  • Loeb andmebaasist tõlketellimusi ja seotud andmeid.
  • Kirjutab andmebaasi tõlkeid ja raporteid.
  • Kirjutab andmebaasi tõlketellimuse muudatusi.
  • Loeb ja kirjutab andmebaasi tõlkemälusid, uuendusettepanekuid ja metaandmeid.
  • Loeb ja kirjutab andmebaasi töövoogusid.
  • Loeb ja kirjutab andmebaasi terminoloogia kogusid.
  • Saadab töid automaattõlkemoodulile sõnumiteenuse kaudu.
  • Saadab töid teavitusmoodulile sõnumiteenuse kaudu.
  • Saadab töid tõlkemälu haldusmoodulile sõnumiteenuse kaudu.
  • Saadab töid kvaliteedikontrollimoodulile sõnumiteenuse kaudu.
  • Võtab vastu tõlkeid automaattõlkemoodulilt sõnumiteenuse kaudu.
  • Pärib ja saadab rollihaldusele identifitseeritud kasutaja rolle.
  • Kasutab TARA liidest kasutaja identifitseerimiseks.
  • Kasutab SAPi teenust ametnike informatsiooni pärimiseks.
  • Loeb logiserverist süsteemi ja auditeerimise logisid.

3.3.4. Töövoogude teostusmoodul

Vastutab töövoogude orkestreerimise eest. Võtab andmebaasist tõlketellimuse ning sellele vastava töövoo. Haldab töövoogu sammhaaval, saates vajadusel ülesandeid teistele rakenduse komponentidele, teavitusi seotud isikutele ning uuendab tellimuse staatust andmebaasis vastavalt töövoo seisule.

Liidestused:

  • Loeb andmebaasist tõlke tellimuse ja töövood.
  • Saadab töid automaattõlkemoodulile sõnumiteenuse kaudu.
  • Saadab töid teavitusmoodulile sõnumiteenuse kaudu.
  • Saadab töid teksti liigi tuvastamise moodulile sõnumiteenuse kaudu.

3.3.5. Teavitusmoodul

Vastutab teavituste saatmise eest e-kirja, sõnumi või muu kommunikatsioonivahendiga.

Liidestused:

  • Võtab vastu töid sõnumiteenuse kaudu.

3.3.6. Kvaliteedikontrolli moodul

Teostab spell-checkeri ülesandeid ning kontrollib terminite tõlget. Ülesannete täitmiseks kasutab terminibaasi vastavalt töö kirjelduses täpsustatud vajadustele. Terminibaas võib olla kas sisestatud tõlkeplatvormi andmebaasi või liidestatud välisest süsteemist (nt Ekilex).

Andmebaasist mällu laetud sõnastikke cache’itakse, et vältida iga töö puhul uut päringut.

Võimalikud kvaliteedikontrolli tööriistad on välja toodud peatükis 6.1. Alternatiivide analüüs - Keskne tõlkekeskkond - RIK Avalik Conflu punktis 7.3.

Protsess:

  1. Võtab vastu töö sõnumiteenuse kaudu.
  2. Loeb andmebaasist sisse tõlgitud teksti.
  3. Loeb andmebaasist või välisest teenusest sisse terminibaasi, kui seda vahemälus ei ole.
  4. Teostab teksti kvaliteedikontrolli ja koostab raporti.
  5. Laeb raporti andmebaasi.

Liidestused:

  • Võtab töövoogude teostusmoodulilt vastu töid sõnumiteenuse kaudu.
  • Loeb andmebaasist dokumendi teksti, mida on vaja kontrollida.
  • Loeb andmebaasist sõnastikke vastavalt vajadusele.
  • Kirjutab andmebaasi kontrolli raporti.

3.3.7. Teksti liigi tuvastamise moodul

Moodul tuvastab iga tõlgitava dokumendiliigi selles sisalduva teksti alusel. Moodul töötab masinõppemudeliga, mis laetakse rakendusse selle käivitamisel.

Masinõppemudeli seisukohast on ülesannet kõige mõistlikum vaadelda klassifitseerimise ülesandena. See tähendab, et mudelit on varasemalt treenitud erinevate tekstiliigi näidetega ning sõnavara ja süntaksi põhjal suudab mudel tuvastada dokumendi liigi. See on antud juhul optimaalne lahendus, sest:

  1. teksti liigid on eelnevalt teada ja pigem staatilised,
  2. see tagab täpsema tulemuse kui juhendamata õppel põhinevad lahendused.

Mudelit ennast on mõistlik treenida süsteemivälises keskkonnas. Kuna võib arvata, et alusandmed muutuvad suhteliselt harva ning automaatne mudelite treenimine on alati seotud teatava riski ja antud juhul ebaproportsionaalselt suure arendus- ja halduskuluga, siis selle lisamine antud süsteemile ei oleks kulutõhus ega efektiivne lahendus.

Võimalikud tekstianalüüsi tööriistad on välja toodud peatükis 6.1. Alternatiivide analüüs - Keskne tõlkekeskkond - RIK Avalik Conflu punktis 7.1.

Liidestused:

  • Võtab töövoogude teostusmoodulilt vastu töid sõnumiteenuse kaudu.
  • Loeb andmebaasist dokumendi teksti.
  • Kirjutab andmebaasi dokumendi metainfo.

3.3.8. Andmebaasi teenindusmoodul

Vahendab suhtlust andmebaasiga ja haldab andmemudeleid. Mooduli eesmärk on tagada andmemudelite kergem haldus ning lihtsustada andmebaasi migratsiooni.

Moodul on jaotatud komponentideks vastavalt kontrollitavale domeenile.

Joonis 4. Andmebaasi teenindusmooduli osad

3.3.9. Avaandmete eksportimise moodul

Mooduli eesmärk on perioodiliselt värskendada avaandmeteks kategoriseeritud andmeid ning teha need laiemale publikule kättesaadavaks. Kuna riigis on võetud selge siht tsentraliseerida avaandmed, siis on mõistlik kasutada seda võimalust, vähendamaks antud süsteemi koormust ning kanda see üle Eesti Avaandmete Portaalile. See tähendab, et antud mooduli peamine ülesanne on avaandmete koosseisu värskendamine, metaandmete koostamine ja selle edastamine avaandmete portaalile vastavalt portaali kirjeldusele juhendis. Andmete pärimine toimub juba avaandmete portaalist ja välised teenused ja tööriistad antud mooduli vastu päringuid teha ei saa. Avaandmete püsivat hoidmist keskses tõlkekeskkonnas ei toimu.

Kuna antud süsteemis loodavad andmed - tõlked, tõlkemälud, terminikogud jmt - ei uuene tihti (võrreldes näiteks ilmastikuandmetega) ning vajavad enne avaldamist enamikul juhtudel ka ülevaatust inimese poolt, siis ei ole nende ligi reaalajaline avalikustamine mõistlik. Sobiv periood, mille järgi andmeid avaldatakse, sõltub juba praktikas avaandmete tekkimise kiirusest ja selgub detailanalüüsi käigus.

Avaandmete esialgne koosseis on kirjeldatud peatükis 5.3.8 Avaandmete avalikustamine. Kui pakutud avaandmete nimekirja tahetakse tulevikus täiendada, siis lisaks isikuandmete kaitsele peab siinkohal arvestama ka autoriõigustega ja intellektuaalse omandi õigustega, mis kaasnevad nii tõlkemälude, terminikogude kui ka tõlketöödega. Ehk mitmete andmekogude suhtes ei saa olla isegi kindel, et nende avaldamine avaandmetena antud süsteemi alt on mõistlik või juriidiliselt vettpidav tegevus.

Samuti on avaandmete teema juures oluline arvestada asjaoluga, et anonümiseerimise teenus ei ole täiuslik - see ei pruugi kõiki olemeid tuvastada, st et lõppsõna on inimesel.

Avaandmete avalikustamise protsessis valib avalikustaja objekti, mille andmeid tahetakse avalikustada, lisab vajalikud metaandmed ning kinnitab andmete edastamist avaandmete portaalile. Kohustuslikud ja vabatahtlikud metaandmed on kirjeldatud siin: Teabevärav (eesti.ee). Täpsem metaandmete koosseis selgub detailanalüüsi käigus.

Liidestused:

  • Loeb andmebaasist avaandmeteks märgitud andmeid.
  • Saadab avaandmed.eesti.ee teenusele uuendusi andmekogude kohta.

3.3.10. Automaattõlkemoodul

Teostab automaatset tõlget, kasutades masintõlkemootorit ja tõlkemälusid vastavalt tõlkimisel valitud prioriteedile. See on tõenäoliselt kõige suurema ressursinõudlusega komponent kogu süsteemis ning seetõttu sõltub selle jagunemine kõige enam praktilisest olukorrast. Kui masintõlke mudel ise suudab pakkuda tõlget mitme keele vahel, ent erinevate valdkondade jaoks on tarvis mudeleid häälestada, siis on mõistlik tekitada iga valdkonna jaoks eraldi järjekord sõnumiteenusesse. See võimaldab skaleerida iga mudelit individuaalselt, mis tagab optimaalse ressursikasutuse. Mudel laetakse rakenduse vahemällu käivitumisel.

Tõlkemälude jaoks eraldi rakenduste ega järjekordade tekitamine ei ole mõistlik. Vastavalt tehtavale tööle laeb rakendus andmebaasist vahemällu vastavad tõlkemälud ning hoiab neid seal perioodi jooksul, mille pikkus otsustatakse vastavalt süsteemi kasutusmustrile.

Moodul võtab vastu töid nii lausehaaval kui ka mitmest lausest koosneva üksusena. Nii on võimalik toetada lisaks kasutusjuhtudele, mil tõlgitakse terve dokument näiteks tõlkeprotsessi alguses, ka interaktiivset kasutust, kus tõlkija pärib tõlget lausekaupa tööd tehes. Oluline on, et suurte tööde puhul vormistaks rakendus töid tükikaupa ning saadaks neid pausidega, et mitte ummistada tööde järjekorda.

Liidestused:

  • Võtab vastu töid töövoogude teostusmoodulilt sõnumiteenuse kaudu.
  • Võtab vastu töid tõlketöö moodulilt sõnumiteenuse kaudu.
  • Saadab tõlgitud laused tõlketöö moodulile.
  • Kirjutab andmebaasi dokumendi tõlkimise tulemuse.
  • Loeb andmebaasist dokumendi teksti, mida on vaja tõlkida.
  • Loeb andmebaasist tõlkemälu.
  • Loeb failisüsteemist masintõlkemudeli.

Võimalikud masintõlkemootorid on välja toodud peatükis 6.1. Alternatiivide analüüs - Keskne tõlkekeskkond - RIK Avalik Conflu punktis 7.3.

3.3.10.1. Uue mudeli lisamine

Kuna mudelid on nii suured, et neid üle API kuhugi panna ei tasu - mitu GB tükk. Failisüsteemis asuvad mudelid ja andmebaasis on info mudelite kohta, mida kasutada saab. Detailid sõltuvad sellest, kuidas lõpuks mudelite tööd hallatakse, aga kui teha nii, nagu dokumendis välja on pakutud - iga domeeni mudel eraldi skaleeritavana - siis protsess peaks olema selline:

Mudeli lisamine:

  1. Mudel laetakse failisüsteemi
  2. Andmebaasi lisatakse mudeli info - süsteemi tekib valik uue mudeli kohta.
  3. Sõnumiteenusesse tekitatakse järjekord antud mudeli jaoks.
  4. Pannakse käima teenus, mis järjekorrast sõnumeid võtab ja uut mudelit kasutab - teenus ise on koopia automaattõlketeenusest, lihtsalt kasutab ainult seda kindlat masintõlkemudelit.

Pigem tuleks vältida automatiseeritavat süsteemi, sest:

  1. Masinõppe CI/CD on keeruline, habras ja suur tükk arendust, kui seda korralikult teha.
  2. Täiesti uue mudeli lisamise funktsionaalsust kasutatakse väga harva - mudelid on domeenispetsiifilised ehk täiesti uus mudel tähendaks uue domeeni lisamist. Mudeli lisamisele kuluv töö on marginaalne võrreldes mudeli arendamise tööga.

3.3.11. Kõnetuvastuse moodul

Teeb transkriptsiooni tõlketellimusele lisatud helifailide põhjal. Iga keelt transkribeeriv teenus peaks olema eraldi rakenduses (moodulis) eraldi sõnumijärjekorra taga, nii seepärast, et neid saaks eraldi skaleerida kui ka seepärast, et erinevad mudelid võivad kasutada väga erinevaid tehnoloogiaid. Pakutav tehnoloogia võimaldab reaalajalist masintõlget. Reaalajaline masintõlge tähendab, et tuleb oodata, kuni lause on lõppenud ja siis toimub lause tõlkimine. Võimalik on ka tõlkida kohe, kuid sellisel juhul ei ole tõlkimise kvaliteet nii kõrge ning koormus süsteemile suureneb. Samuti on võimalik ka transkribeeritud teksti kohe tõlkida, kasutades süsteemi integreeritud masintõlkemudelit. Kuid siin on oluline arvestada, et sellisel juhul peab olema transkribeeritud tekst väga hea kvaliteediga, mida ei pruugi iga kõnetuvastusmudel pakkuda, kuna palju sõltub ka helifaili/kõne kvaliteedist (täpsusest ja selgusest).

Lõpuks sõltub kõik sellest, milline kõnetuvastuse mudel valitakse ja kui palju seda veel arendatakse. Võimalikud mudelid on analüüsis välja pakutud.

Liidestused:

  • Võtab vastu töid töövoogude teostusmoodulilt sõnumiteenuse kaudu.
  • Loeb failisüsteemist helifaili.
  • Loeb failisüsteemist mudeli.
  • Kirjutab andmebaasi transkribeeritud teksti.

Võimalikud kõnetuvastuse töövahendid on välja toodud peatükis 6.1. Alternatiivide analüüs - Keskne tõlkekeskkond - RIK Avalik Conflu punktis 7.1.

3.3.12. Tõlkemälu haldusmoodul

Kuna tõlkemälud peavad olema anonümiseeritud, et neid oleks võimalik kasutada laiemalt, siis nii imporditavad tõlkemälud kui ka tõlkemälu uuendusettepanekud peavad läbima anonüümseks tegemise protsessi, milles tuvastatakse lausetes olemid ning asendatakse need kohatäitjatega. Kõige tõenäolisemalt kasutatakse selleks masinõppemudeleid, et tagada suurim võimalik täpsus. Võimalikud anonümiseerimise tööriistad on välja toodud siin: 6.1. Alternatiivide analüüs - Keskne tõlkekeskkond - RIK Avalik Conflu punktis 7.3.

Tõlkemälu haldusmoodul võtab vastu imporditud tõlkemälusid ja uuendusettepanekuid tõlkemäludele, teeb need anonüümseks ning edastab andmebaasi.

Liidestused:

  • Võtab tõlketöö moodulilt vastu imporditavad tõlkemälud  sõnumiteenuse kaudu.
  • Võtab tõlketöö moodulilt vastu uuendamise ettepanekud sõnumiteenuse kaudu.
  • Kirjutab andmebaasi anonüümseks tehtud tõlkemälu.
  • Kirjutab andmebaasi anonüümseks tehtud uuendamise ettepaneku.

3.3.13. Statistika kogumise moodul

Pärib regulaarselt andmeid andmebaasist, arvutab statistikuid ning koostab raporteid.

Moodul ise ei kuva statistikuid, aga valmistab neid ette kuvamiseks tõlketöö moodulis.

Liidestused:

  • Loeb andmebaasist rakenduse kasutamise infot.
  • Kirjutab andmebaasi raporteid.

3.3.14. Väliste teenuste tõlkemoodul

Mooduli eesmärk on pakkuda süsteemi välistele komponentidele liidestuspunkti automaattõlke funktsionaalsusega. Kui süsteemi enda CAT-tööriist saadab tõlkepäringuid otse sõnumiteenuse kaudu, siis antud moodul töötab vahendajana välismaailma ja sõnumiteenuse vahel. Võtab vastu tõlgitava materjali veebilehitseja pluginast, välisest CAT-pluginast või muust süsteemi välisest komponendist ning edastab selle automaattõlketeenusele sõnumiteenuse kaudu.

Näiteks kui on soov pakkuda tavakasutajale võimalust tõlkida mis tahes veebilehte, siis selleks on vaja arendada plugin sirvikule, mis võtab tõlgitava materjali lehelt, saadab selle väliste teenuste tõlkemoodulile, mis organiseerib selle tõlke antud süsteemis ning tagastab soovitud suunas tõlgitud teksti.

Selle töö käigus on antud mooduli ülesandeks ka pikemate tekstide segmentideks lahutamine, segmendi kaupa automaattõlke moodulile saatmine ning pärast uuesti ühendamine.

Sõltuvalt sellest, kui populaarne antud lahendus on ja kui tihti seda kasutatakse, võib see tekitada süsteemile arvestatava koormuse. Selle mõjusid süsteemi tööle on võimalik minimeerida sõnumitele prioriteetide määramisega või sõnumiteenuses uute sõnumijärjekordade ja seda teenindavate instantside loomisega.

Kui on soov pakkuda veebilehtede tõlketeenust veebilehe haldajatele endile, siis on järjepidev koormus tõlkesüsteemile väiksem, aga see tähendab jällegi iga vastava sisuhaldussüsteemi - nt WordPress või Drupal - jaoks plugina ehitamist, mis seda funktsiooni vahendaks. Tehtud tõlge aga salvestatakse sel puhul sisuhaldussüsteemi ning tõlketöö kogumaht on seega minimaalne võrreldes sirviku plugina puhul potentsiaalselt tekkivaga.

Esialgu ei ole ette nähtud, et veebilehtede tõlkimisel määrataks dokumendi kategooria või valitaks tõlkemälusid ja terminibaase, sest see kasvataks hüppeliselt nii tõlkemooduli kui ka plugina keerukust ning sellist funktsionaalsust ei ole otseselt nõutud.

Liidestused:

  • Võtab väliselt teenuselt vastu tõlgitava materjali HTTPSi kaudu.
  • Edastab tõlketöö automaattõlkemoodulile sõnumiteenuse kaudu.

3.3.15. X-tee turvaserver

Et süsteem saaks liidestuda X-teega, on sellele ette nähtud ka X-tee turvaserver, mis neid ühendusi vahendab. Esialgu süsteem ise teenuseid X-tee kaudu ei paku, sest pole ette nähtud teenuseid, mille jaoks X-tee vahendus oleks vajalik. Küll aga tarbib süsteem SAPi teenust X-tee kaudu ning X-tee turvaserveri olemasolu võimaldab süsteemi liidestada ka teiste allikatega X-teel. Samuti on hilisemal vajaduse tekkimisel võimalik teenuseid X-tee kaudu pakkuda.

Liidestused:

  • Saadab päringuid SAPi teenust vahendava turvaserveri pihta.
  • Pärib X-tee keskserverilt globaalset konfiguratsiooni.
  • Kasutab X-tee ajatempliteenust sõnumite tembeldamiseks.

3.3.16. Logiserver

Süsteemis salvestatakse laias laastus kahte tüüpi logisid - süsteemilogid ja auditeerimiseks vajalikud logid. Kuna nii nende logide kasutus kui ka tundlikkus on väga erinevad, peab neid hoidma eraldi ning erinevate ligipääsupiirangutega. Süsteemilogisid kasutatakse administreerimisel ja diagnoosiks, kui midagi valesti läheb ning sel puhul ei ole tingimata tarvis teada tegevusi isiku täpsusega ning selle info nendes logides hoidmine oleks turvarisk. Küll aga on seda infot tarvis siis, kui tekib vajadus hiljem auditeerida ning täita andmekaitseseadusest tulenevaid kohustusi.

Neid logisid on aga võimalik edukalt hallata samas moodulis, erinevate ligipääsupiirangutega. Oluline on küll, et logiserveri andmesalvestuskiht oleks eraldi ülejäänud rakenduse omast, et vältida olukorda, kus logide kirjutamisest tekkiv koormus pärsib rakenduse tööd.

Liidestused:

  • Kõik teenused salvestavad logid logiserverisse.
  • Tõlketöö moodul pärib logiserverist logisid.

3.3.17. Tõlkemootori treeningmoodul

Süsteemis toodetakse töö käigus masinõppe jaoks sobivaid treeningandmeid peamiselt kahel viisil:

  1. Tõlkemälude importimine ja uuendamine
  2. Masintõlke pakutud lahendustesse paranduste sisseviimine

Esimene neist hõlmab endas nii täiesti uute tõlkemälude importi kui ka muudatusi, mida tõlkemäludele tehakse. Peamine maht tuleb siin aga uute tõlkemälude importimisest. Teine neist hõlmab jooksvalt tekitatavat andmestikku - kui masintõlge pakub mingisuguse lahenduse, siis töö käigus teeb tõlkija sellesse vajalikud parandused, et tõlge oleks asjakohasem ning keeleliselt korrektsem. Seda infot saab kasutada tõlkemootori treenimiseks.

Mudeli treenimine ise käib automaatselt kindla perioodi tagant. Üldiselt selliste süsteemide puhul seatakse treenimine toimuma kas aja või tekkinud uue materjali koguse järgi sõltuvalt süsteemi spetsiifikast. Nimelt on automaatse mudeli treenimisega alati seotud teatavad riskid:

  1. Kõik sisendandmed ei ole kvaliteetsed
  2. Kõik sisendandmete allikad ei ole usaldusväärsed

Sellest tulenevalt võib juhtuda, et mudel ei treeni end paremaks, vaid hoopis halvemaks ning nõuaks eraldi kontrollimist pärast iga treeningut. Tulenevalt sellest on hea, kui mudeli sisendandmed läbivad kontrolli, kus spetsialist määrab teatava andmekogu treeninguks sobivaks. Sellisel puhul on tõenäoliselt mõistlik seada süsteem üles perioodiliseks treenimiseks, mille käigus moodul:

  1. Laeb sisse mudeli, mida on vaja treenida.
  2. Kogub kokku kõik andmed, mis on märgitud treenimiseks sobivateks andmeteks.
  3. Viib läbi treeningu.
  4. Salvestab mudeli kettale, kust automaattõlkemoodul selle üles leiab.

Tuleb arvestada, et kuna treening on palju arvutusmahukam protsess kui tõlke teostamine ise, siis ei ole võimalik seda mõistliku aja jooksul ilma GPUd kasutamata läbi viia. Seepärast on ka siin kohustuslik GPU olemasolu. Samas on võimalik ühe GPU peal treenida kõiki mudeleid, kui seda ei tehta paralleelselt.

Tuleb märkida, et tegu ei ole ühelgi juhul täiesti nullist mudeli treenimisega, vaid kasutatakse ainult uusi andmeid, et mudelit värskendada. Täiesti nullist mudeli treenimine on hüppeliselt keerukam protsess ning selle teostamiseks on vajalik suurusjärgu võrra suurem arvutusvõimekus. Kuna see on aga üpris haruldane tegevus, siis ei peaks see kindlasti kuuluma  automaatsete tegevuste ega ka käesoleva platvormi sisse.

Liidestused:

  • Loeb andmebaasist andmed, mis on sobivad mudeli treenimiseks.
  • Kirjutab andmebaasi uue mudeli versiooni andmed.
  • Salvestab mudeli uue versiooni failisüsteemi.

3.3.18. Sõnumiteenus

Sõnumiteenuse funktsioon on hallata sõnumijärjekordi ja vahendada sõnumeid süsteemi komponentide vahel. Sõltuvalt tehnoloogilistest valikutest on võimalik seda komponenti realiseerida näiteks RabbitMQ või Redis andmebaasi abil, täpne suhtlusprotokoll seega sõltub kasutatavast tehnoloogiast.

Suurem osa komponente süsteemis ei vaja sünkroonset suhtlust ning sõnumijärjekordadele tuginemine annab suurema paindlikkuse nii arendusmeeskondade, tehnoloogiate kui juurutuskeskkondade suhtes. Arenduse alguses vormistatakse vahetatavate sõnumite formaat ning seejärel on võimalik komponente ükshaaval välja vahetada, kui selleks peaks olema vajadus, pidades silmas, et uus komponent kasutaks suhtlemisel sama formaati ja protokolli, nagu väljavahetatav.

Seda ei ole aga mõistlik avada välistele teenustele ning seepärast on ka väliste tõlketööde süsteemile vahendamiseks loodud väliste teenuste tõlkemoodul.

  • No labels

2 Comments

  1. 3.3.15. X-tee turvaserver
    Digiriigi ristfunktsionaalsetest nõuetest (https://koodivaramu.eesti.ee/e-gov/cfr):
    #22 Infosüsteemide vaheline andmevahetus toimub üle X-tee.
    Kommentaar Priit Parmaksonilt (RIA) masintõlke arendamise kontekstis, kuid käib vähemalt sama palju ka tõlkekeskkonna kohta:
    Tuleks selgitada, milliste süsteemidega masintõlketeenus hakkab andmeid vahetama ja kui kõrged on nõuded edastavate andmete terviklikkusele, autentsusele ja konfidentsiaalsusele. Masintõlketeenuse API pakkumisel tuleks selgitada, kellele API-t hakatakse pakkuma ja kui tundlik saab olema tõlgitav teave. (ML: neid andmeid vaja eelkõige keskselt tõlkeplatvormilt)

    Kogemus näitab, et kuigi X-tee on keeruline, on kõrgemat turvalisust andmevahetuses isetehtud lahendustega raske saavutada. Isetehtud lahenduste suur puudus on ka, et need ei skaleeru. Masintõlketeenust tõenäoliselt hakkab aja jooksul kasutama suur hulk süsteeme. Seetõttu liidestumine peab olema standardne. Eestis on turvalise andmevahetuse standard X-tee ja seda peaks ka kasutama.

    Kui nõuded andmetevahetuse turvalisusele on madalamad - nt ei ole nõutav salgamatus ega kliendi tuvastamine - siis saab teenust pakkuda ka tavalise veebiteenusena (HTTPS). Kui API poole pöördumist tahate pakkuda ka sirvikus töötavatest rakendustest (CORS), siis on tava-HTTPS ainuke võimalus.

    X-tee aitab saada avalikust sektorist kliente ja rakendusi.

    Masintõlke projektis X-tee liidestust ei realiseerita, aga tulevikuks planeerida. Tõlkekeskkond peaks X-teed toetama.

    X-tee paigaldamine on ressursimahukas, kuid tasub end pikemas perspektiivis ära.

  2. Tõnise ettepanekutega arvestatud (HTTP asendatud HTTPS-ga)