Progress report VIII

[AsherIDE]

Hi @maartenmarx ,

De vooruitgang van deze week is als volgt:

1. Noah heeft alle translations voor BG, CZ, DK, NL en SI in .csv files gezet die overeen komen met het aantal .xml files per land. Nu ben ik bezig met een notebook die al deze .csv files verwerkt in de Elastic database. Ik heb dat bijna af, maar ik was iets langer bezig omdat ik eerst een functie moest schrijven die segments (die een persoon achter elkaar zegt voordat iemand anders aan het woord is) samenvoegt tot een geheel van wat een persoon zegt. De meeste functie werken nu, ik hoef alleen nog een functie te schrijven die alles tot een geheel maken om in een keer alle landen toe te voegen aan Elastic. De bijbehorende file hiervoor:
   • https://github.com/AsherIDE/EU-scale-search/blob/main/Notebooks/translation_insertion.ipynb
2. De Ngram viewer werkt momenteel als een echte Ngram viewer. Ik heb de functie nu gemaakt op 1 query die opgedeeld wordt in lijnen voor het aantal landen waar de results in op kunnen worden gedeeld. De functie kan nu een ngram maken voor jaren: Ook voor maanden: En voor dagen: Ik heb veel tests gedaan om te kijken of er geen rekenfouten zaten in mijn functie en na veel trial and error kon ik niets meer vinden qua fouten. Verder zit ik nog wel te twijfelen of ik op een andere manier de query moet verwerken om boven het maximum van 10.000 resultaten te kunnen komen (wat Elastic heeft als softcap), ook al duurt het nu al een aantal seconden om in real time een Ngram op te stellen. Onderstaand is een link naar de notebook waarmee ik een .csv maak waarin alle total word counts staan en de andere notebook is de ngram notebook:
   • (Total word count per .xml) https://github.com/AsherIDE/EU-scale-search/blob/main/Notebooks/file_word_counter.ipynb
   • (Ngram) https://github.com/AsherIDE/EU-scale-search/blob/main/Notebooks/ngram_playground_1_2.ipynb
3. Verder heb ik websites verzameld met interessante zoekinterfaces, maar ik moet deze websites nog evaluaren aan de hand van het Search User Interfaces boek en de aantekeningen die ik daarbij heb.

Nog wat mooie uitdagingen voor komende week:

1. Komende week wil ik het invoeren van de vertaalde landen in Elastic afronden, zodat ik betere tests kan doen met meerdere landen voor mijn Ngrams.
2. De websites met interessante zoekinterfaces wil ik gaan evalueren om achter belangrijke punten te komen voor de zoekinterface die ik in elkaar wil gaan zetten.
3. Als beide punten zijn gelukt, wil ik experimenteren met de mogelijkheid om per land een losse query te doen voor de Ngram zodat elk land een maximum aan 10.000 resultaten heeft, in plaats van 10.000 resultaten voor alle landen samen. De afweging is alleen dat het ook (~5 seconden * aantal landen) langer duurt.

Groet,

Asher

[maartenmarx]

Hi @AsherIDE , gaaf! Even over die 10.000 cap. Wat zijn voor jouw documenten? En dus hits.

Je kan ook over de ngram viewer architectuur lezen en dan zie je dat alles hard-coded is. Is dat geen leuk idee om het af te ronden? Even echt CS! Maar dan dus wel heel erg snel! En je bent van die 10K max af, wat een stom gedoe.

Je kan daar altijd nog die zoek-interface aan koppelen. Die gaat dan daarna echt zoeken.

Snap je wat ik bedoel? Je hebt gewoon een tabel/dict/datastructuur met

ngram--> land-->jaar--> aantal

Ja, ik snap ook wel dat die best groot is. Maar dat maakt toch niet uit?

Ik ben beniuwd.

[AsherIDE]

Hi @maartenmarx ,

Ik heb nog geprobeerd om via Elastic al te tellen hoevaak een woord per entry voorkomt, maar gek genoeg is het op die manier stukken trager. Mogelijk omdat deze manier eerst alle zinnen moet samenvoegen onder een file, dan alle files van dezelfde dag samen moet voegen om als laatst al deze files op een date samen te voegen.

Dus nu heb ik de huidige functie aangepast om per land een aparte query te doen, wat nu ongeveer 10 seconden duurt voor hele grote queries. Bij een jaar duurde dat maar ongeveer drie seconden en een maand duurde maar een halve seconde.

Als ik u goed begrijp, stelt u voor dat ik alvast een aantal terms ga preprocessen om tijd te besparen voor gebruikers. Daar vraag ik mij dan wel bij af voor welke termen dat nou echt relevant zou zijn, aangezien mijn doelgroep heel breed is en het dus moeilijk te voorspellen is waar zij op zouden zoeken. Verder heeft alleen het grootste ngram overzicht rond de 10 seconden nodig en de rest is zo klaar.

Als u wil dat ik woorden ga preprocessen, heeft u dan een tip voor welke woorden ik het beste zou kunnen kiezen?

Groet,

Asher

[maartenmarx]

Hi @AsherIDE , volgens mij heeft de google ngram viewer gewoon elk 1,2,3,4,5 gram dat in de stukken voorkomt inm de index opgeslagen. Je kiest dus niet ,maar indexeert alles. Ja, dit is best serieus.

Maar goed, als je het redelijk snel kunt houden, doe je het toch fijn uit de index. Dat is ook prima joh. Die ngrammen "voorkoken" is eigenlijk alleen engineering.