---
# System prepended metadata

title: Küsimused EstNLTK kohta
tags: [AT_DH_2022]

---

---
tags:  AT_DH_2022
---

# Küsimused EstNLTK kohta


Siimult: Tänud! Head küsimused, minu vastused allpool:

> - Kas EstNLTK on kasutatav standardAPIdega? Ma pole tegelikult kindel, mis see standard siin on. Aga vist küsimus, et kas saab nt teksti api kaudu saata ja siis tagasi nt?

Siin on, jah, tõesti küsimus selles, et millistest standardAPI-dest on jutt?
Kas teksti saab API kaudu saata? -- see on küsimus pigem veebiteenuste
maailmast, et kas estnltk on kasutatav veebiteenusena? Praegu otseselt
mitte, kuigi vajadusel võib nt morf analüüsi veebiteenusena jooksma
panna: https://github.com/estnltk/estnltk/blob/main/tutorials/taggers/web_taggers/web_pipeline_morph_analysis.ipynb
( aga see on juba veidi keerulisem teema )

> - Nimetuvastus - kui lausetes on Alar Karis ja hiljem lihtsalt Alar, siis EstNLTK vist neid kuidagi kokku ei vii? St neid kuidagi ühendamas ei ole, eeldan. Samamoodi ka Tema vms teksti sees.

Terane küsimus. Sedasorti nimede kokkuviimine on keeletehnoloogias
eraldi alamülesanne, mida nimetatakse "samaviitelisuse lahendamiseks"
-- st tuleb kindlaks teha, et kas eri fraasid viitavad ühele ja samale
persoonile, asukohale vms. Estnltk-s ei ole veel samaviitelisuse
lahendamise komponenti, aga katsetusi selles vallas on
keeletehnoloogid teinud ja loodetavasti tulevikus midagi tekib.

> - Nimetuvastuses - ta teeb Eesti Energiast  Eesti energia (väiketähega), miks nii, lihtsalt sest on lihtsam või on mingi loogika?

Tegelikult nimetuvastus ei tee seda, nimetuvastus leiab ainult
nimefraaside asukohad. Seal on morf analüüsist välja võetud nimede
lemmad ning morf analüüsis on tõesti lemma "(Eesti) energia" väikese
tähega. Nimede tuvastamise kvaliteeti morf analüüsis saab parandada
korpusepõhise- ja tekstipõhise ühestamisega ( st saab rakendada
automaatselt põhimõtet, et kui tekstis on "Energia" läbivalt suure
algustähega, siis see peaks olema ikkagi nimi ja ka lemma peaks olema
suure algustähega, vt
https://github.com/estnltk/estnltk/blob/main/tutorials/nlp_pipeline/B_morphology/04_morph_analysis_with_corpus-based_disambiguation.ipynb
).

> - Kui suure korpuse ta välja kannatab - mõistlikkuse piires - ehk vb siis et kui suure teksti talle korraga sisse sööta võiks? Mulle tundub, et küsimus võiks puudutada ka optimaalset Text objekti suurust või siis seda et kui on nt 1Gb teksti siis kuidas seda sisse sööta - kas kõik korraga või jupi kaupa? Kas on mingi tekstisuurus vs töötlusaeg numbrid ka teada?

Üldiselt: piirid seab masinas olemasolev mälu ja salvestamisel masina
kõvakettaruum. Teisalt on küsimus selles, mis liiki analüüs meid
huvitab ja kas meid huvitavad ka metaandmed? Nt ajaväljendite
tuvastamise puhul: kui meil on 1Gb teksti, kas see kõik on ikka
kirjutatud ühel kuupäeval või on seal mingid terviklikud alamlõigud /
tekstid, mis on kirjutatud eri aegadel? Seega on soovitatav analüüsida
terviklike tekstide kaupa, saab need varustada ka sobivate
metaandmetega. Kui on tarvis kiirust optimeerida, saab mitu lõime või
protsessi panna paralleelselt tekstihulka töötlema.

> - json_to_text - osalejad arvasid, et vb oleks lihtsam lihtsalt pickle-iga salvestada - kas json kasutusel sellepärast et on universaalsem formaat?

põhimõtteliselt küll. json-i eelis on see, et see on nii masinloetav
kui ka inimloetav ning andmeid saab importida erinevatele
platvormidele. Muidu on võimalik estnltk Text objekte salvestada ka
pickle-i abil.

> - paketi käsud - nad ütlesid, et see näeb välja nagu pandase tabelid tabelite sees, aga miks ei ole kasutusel ükski pandase käsk? Ma ei oska sellest midagi arvata. Üks loogika, mis jäi silma neile, jäi silma ka mulle - kui me võtame mingi konkreetse word-i juures nt lemmad ja pos-tagid - siis miks ei saaks lihtsalt seda tabelit filtreerida wordi koha pealt ja võtta terve rida korraga. St tegelt vist viimati kohtudes ka tuli see teemaks, et seda ei saa. Aga neil tekkis sama küsimus seal.

Ma ei ole ise estnltk liidest disaininud, aga ma pakun, et põhjus võib
olla selles, et estnltk andmestruktuurid on siiski keerulisemad, kui
lihtsalt tabelid. Nt põhjustab keerukust mitmesus, st üks rida võib
sisaldada nö "alamridu".
Muidu filtreerida saab kihti lambda funktsiooni abil, vt
https://nbviewer.org/github/estnltk/estnltk/blob/main/tutorials/basics/introduction_to_estnltk_api.ipynb#Selecting-multiple-annotations:-indexing-operators
seal on näide, kus võetakse välja ainult sõnad, mis on pikkusega 2.

> - Kas on olemas ka mingi närvivõrkude lahendus estnltk-s - keegi osalejatest leidis sellise githubi üles? St kas on plaane neid uuemaid meetodeid sisse integreerida (ja mis saab siis vanadest)?
>

Jah, meil on eraldi pakett estnltk_neural, mis sisaldab närvivõrkudel
põhinevaid mudeleid. Seal on peamiselt süntaks, natukene Berti ja üks
morf ühestamise mudel. Neuromudelite peamised miinused on, et need on
praegu suht ressurssimahukad, aeglasevõitu ning nende installimine on
keerukas. Sestap neid estnltk põhiteegis veel ei ole; kui neuromudelid
muutuvad kiiremaks ja lihtsamini installitavaks, saab need lisada ka
põhiteeki.

Parimat
Siim