Kai pradedi domėtis mašininio vertimo technologijomis giliau, greitai pastebi vieną įdomų reiškinį – dauguma didžiųjų kalbos modelių, apie kuriuos girdime žiniasklaidoje, yra uždari, komerciniai produktai. Tačiau lygiagrečiai su jais egzistuoja visa ekosistema atvirojo kodo vertimo sprendimų, kurie dažnai lieka šešėlyje, nors realiai varo didelę dalį interneto vertimo įrankių, akademinių tyrimų ir net kai kurių komercinių produktų infrastruktūros. Šiandien pasinerkime į šią temą – kas tie atvirojo kodo modeliai, kodėl jie svarbūs ir ką reikėtų žinoti, jei norite juos naudoti ar tiesiog suprasti, kaip veikia jūsų mėgstamas vertimo įrankis.
Kas iš tikrųjų yra atvirojo kodo vertimo modelis
Paprastai tariant, atvirojo kodo vertimo modelis – tai neuroninis tinklas, kurio architektūra, svoriai (parametrai) ir dažnai net mokymo kodas yra viešai prieinami. Bet kas gali juos parsisiųsti, paleisti savo serveryje, modifikuoti ar net integruoti į savo produktą – dažniausiai be jokių licencijos mokesčių, priklausomai nuo konkrečios licencijos tipo.
Skirtingai nei uždari sprendimai, kur vartotojas tiesiog siunčia tekstą per API ir gauna rezultatą nežinodamas, kas vyksta „viduje”, atvirojo kodo modeliai leidžia pažvelgti po gaubtu. Tai reiškia, kad galima suprasti, kokiais duomenimis modelis buvo treniruotas, kokios kalbos porų kombinacijos palaikomos geriausiai, ir – kas ne mažiau svarbu – kur slypi jo silpnosios vietos.
Žinoma, čia iškart kyla klausimas: jei tokie modeliai laisvai prieinami, kodėl visi nesinaudoja tik jais? Atsakymas paprastas – kokybė. Didieji komerciniai sprendimai dažnai investuoja milijonus dolerių į duomenų rinkimą, treniravimo infrastruktūrą ir fine-tuning procesus, todėl kai kuriose kalbų porose jie vis dar lenkia atvirojo kodo alternatyvas. Tačiau atotrūkis mažėja kiekvienais metais, ir tai nėra tušti žodžiai.
Populiariausi projektai, kuriuos verta pažinti
Jei norite pradėti eksperimentuoti su atvirojo kodo vertimu, tikriausiai pirmiausia susidursite su keliais pagrindiniais vardais.
OPUS-MT – tai vienas seniausių ir plačiausiai naudojamų projektų, kurio pagrindas yra Helsinkio universiteto komandos darbas. Jie sukūrė šimtus atskirų modelių skirtingoms kalbų poroms, naudodami Marian NMT karkasą. Įdomu tai, kad kiekvienam kalbų deriniui dažniausiai naudojamas atskiras, specializuotas modelis, o ne vienas universalus – tai leidžia pasiekti gana neblogą kokybę net retesnėms kalboms, tokioms kaip lietuvių–suomių ar lietuvių–islandų.
NLLB (No Language Left Behind) – Meta (buvusio Facebook) projektas, kuris kelia kitokį tikslą: sukurti vieną didelį modelį, gebantį versti tarp daugiau nei 200 kalbų, įskaitant tokias, kurioms iki šiol praktiškai nebuvo jokių skaitmeninių vertimo įrankių. Šis projektas ypač svarbus mažesnėms kalbų bendruomenėms, nes anksčiau daugelis „egzotiškesnių” kalbų tiesiog nebuvo įtrauktos į jokius komercinius produktus – tiesiog neapsimokėjo investuoti.
M2M100 – dar vienas Meta projektas, kurio esmė – galimybė versti tiesiogiai iš vienos kalbos į kitą, neinant per angliškąjį „tarpinį” žingsnį. Tai skamba techniškai, bet praktinė nauda akivaizdi: vertimas iš, pavyzdžiui, lietuvių į portugalų kalbą tampa tikslesnis, nes nebereikia dviejų vertimo etapų, kur klaidos kaupiasi.
Yra ir mažiau žinomų, bet vertų dėmesio projektų – MADLAD-400, mBART, ar naujesni, tokie kaip Tower LLM, kurie taiko didelių kalbos modelių architektūrą specifiškai vertimo užduotims.
Kodėl kai kurios kalbos verčiamos geriau nei kitos
Čia liečiame gana skaudžią temą – duomenų kiekio problemą. Vertimo modeliai mokosi iš lygiagrečių tekstų, tai yra dokumentų, kurie egzistuoja abiem kalbomis vienu metu (pavyzdžiui, ES teisės aktai, kurie verčiami į visas oficialias sąjungos kalbas). Anglų, prancūzų, vokiečių ar ispanų kalboms tokių duomenų yra begalė – internetas tiesiog knibždėte knibžda lygiagrečiais tekstais.
Su lietuvių kalba situacija jau kiek sudėtingesnė. Nors ES institucijų dėka turime nemažai kokybiškų lygiagrečių korpusų (Europarl, DGT-Translation Memory ir panašūs), bendras duomenų kiekis vis tiek yra kelis dešimtis kartų mažesnis nei, tarkim, vokiečių kalbai. O jei kalbame apie retesnes kalbas – tarkim, žemaičių tarmę ar mažesnes Afrikos kalbas – ten duomenų gali praktiškai nebūti, todėl modeliai tiesiog „spėlioja” pagal panašias kalbas tos pačios kalbų šeimos viduje.
Būtent todėl projektai kaip NLLB yra tokie reikšmingi – jie sąmoningai stengiasi surinkti duomenis mažiau atstovaujamoms kalboms, naudodami įvairias technikas, tokias kaip atgalinis vertimas (back-translation) ar duomenų generavimas iš religinių tekstų, kurie, kad ir keistai skamba, dažnai yra vieninteliai plačiai išversti tekstai tam tikroms mažoms kalboms.
Praktinė pusė: kaip paleisti tokį modelį pačiam
Jei jums kilo noras patiems pabandyti, geros naujienos – tai nebe taip sudėtinga, kaip buvo prieš kelerius metus. Hugging Face platforma tapo faktiniu standartu, kur talpinama dauguma šių modelių, ir su Transformers biblioteka Python kalba galima paleisti vertimą vos keliomis eilutėmis kodo.
Svarbiausia, ką reikia žinoti prieš pradedant:
- Skaičiavimo galia. Didesni modeliai, tokie kaip NLLB-200 pilnoje versijoje, reikalauja rimtos GPU atminties. Yra ir mažesnės, distiliuotos versijos (600M, 1.3B parametrų), kurios veikia net ir vidutiniame kompiuteryje, nors kokybė šiek tiek nukenčia.
- Kalbos kodai. Kiekvienas modelis naudoja savo kalbos identifikavimo sistemą – kai kur tai ISO 639-1 kodai (lt, en, de), kai kur ilgesni FLORES-200 formatai (lit_Latn, eng_Latn). Painiava čia dažna, tad visada patikrinkite modelio dokumentaciją.
- Batch apdorojimas. Jei planuojate versti didelius tekstų kiekius, verta iškart nusistatyti batch apdorojimą, o ne siųsti sakinius po vieną – tai sutaupys nemažai laiko.
Praktiškai tai atrodo maždaug taip: parsisiunčiate modelį per transformers biblioteką, paruošiate tekstą, nurodote šaltinio ir tikslo kalbas, ir per kelias sekundes gaunate rezultatą. Žinoma, jei norite integruoti tai į realų produktą, reikės pagalvoti ir apie serverio infrastruktūrą, ir apie eilių valdymą, jei tikitės daug užklausų vienu metu.
Kur atvirojo kodo modeliai atsilieka nuo komercinių
Būtų nesąžininga nutylėti trūkumus. Nors pažanga akivaizdi, atvirojo kodo modeliai vis dar dažnai atsilieka keliose srityse.
Pirma, konteksto suvokimas. Didieji komerciniai modeliai, ypač tie, kurie remiasi naujausiomis GPT ar Gemini architektūromis, dažnai geriau supranta platesnį teksto kontekstą, idiomas, humoro atspalvius ar kultūrines nuorodas. Atvirojo kodo modeliai, ypač specializuoti vertimo modeliai (kaip OPUS-MT), dažniausiai dirba sakinys po sakinio, praradę platesnį dokumento kontekstą.
Antra, retesnių terminų ir specifinių sričių žodyno tikslumas. Medicininiai, teisiniai ar techniniai tekstai reikalauja specifinio žodyno, kurio mažesni atviri modeliai gali tiesiog neturėti pakankamai gerai išmokę.
Trečia – nuolatinis atnaujinimas. Komerciniai produktai nuolat renka vartotojų atsiliepimus ir tobulina modelius realiu laiku, o atvirojo kodo projektai priklauso nuo entuziastų ar mokslininkų komandų, kurios turi ribotus resursus ir laiką.
Tačiau reikia pripažinti – šis atotrūkis sparčiai mažėja specifinėse kalbų porose, ypač tose, kur yra pakankamai treniravimo duomenų.
Privatumo ir kontrolės klausimas
Vienas dalykas, kurį verta paminėti atskirai – duomenų privatumas. Kai naudojate uždarą API paremtą vertimo paslaugą, jūsų tekstas keliauja per trečiosios šalies serverius, ir niekada iki galo negalite būti tikri, kaip tie duomenys naudojami toliau (net jei kompanija skelbia, kad jie nesaugomi).
Su atvirojo kodo modeliais situacija visiškai kitokia – galite paleisti viską lokaliai, savo serveryje ar net asmeniniame kompiuteryje, ir jokia informacija niekur „neišeina”. Tai ypač aktualu įmonėms, dirbančioms su konfidencialiais dokumentais, teisininkams, medicinos įstaigoms ar bet kam, kas verčia jautrią informaciją.
Šis aspektas dažnai nusveria net ir šiek tiek prastesnę vertimo kokybę – geriau turėti šiek tiek mažiau tobulą vertimą, bet žinoti, kur tiksliai keliauja jūsų duomenys.
Vietoj apibendrinimo: ką verta pasiimti iš šito viso
Jei turėčiau duoti vieną praktinį patarimą, tai būtų toks – nebandykite rasti vieno „geriausio” atvirojo kodo modelio visoms situacijoms. Tokio tiesiog nėra. Vertimui tarp didelių Europos kalbų puikiai tiks specializuoti OPUS-MT modeliai, kurie dažnai netgi greitesni ir tikslesni siaurose srityse nei universalūs milžinai. Jei dirbate su retesnėmis ar mažiau atstovaujamomis kalbomis, verta rinktis NLLB šeimą, nors ir teks susitaikyti su lėtesniu darbo greičiu ir didesniais skaičiavimo reikalavimais.
Jei jums svarbiausia privatumas – tarkim, verčiate vidinius įmonės dokumentus ar teisinę medžiagą – atvirojo kodo sprendimas, paleistas lokaliai, tikrai verta investuoto laiko, net jei pradžioje teks šiek tiek pasikapstyti su technine dalimi.
Ir dar vienas dalykas, kurį verta įsidėmėti: atvirojo kodo bendruomenė šioje srityje juda nepaprastai greitai. Tai, kas prieš dvejus metus atrodė neįmanoma mažoms kalboms, šiandien jau realybė. Todėl, jei kartą bandėte kokį nors modelį ir nusivylėte kokybe, verta grįžti ir patikrinti dar kartą – tikėtina, kad per tą laiką atsirado naujesnė, gerokai patobulinta versija. Technologijų pasaulyje šioje srityje stovėti vietoje reiškia iš tikrųjų atsilikti, o vertimo modelių atveju pažanga per pastaruosius kelerius metus buvo tiesiog stulbinanti.
