sul fatto di usare un tokenizzatore morfologico sono in polemica coi giovani nerd con cui lavoro i quali dicono che sono un vecchio parruccone e che all'atto pratico la cosa non servirebbe. sarà, ma io finché non vedo una forma clitica come 'mangiarselo' tokenizzata come: 'mangiar' 'se' e 'lo' (con quelle belle particelle che vanno ad attenzionare gli argomenti verbali) resto della mia idea. comunque, il tokenizzatore è la cosa migliore di Minerva, e non dubito con molti più dati di buona qualità alla fine un tokenizzatore di quel tipo approssimerebbe abbastanza bene la micidiale morfologia dell'italiano G. On Mon, 20 May 2024 at 13:07, Antonio <antonio@piumarossa.it> wrote:

...

https://huggingface.co/sapienzanlp/Minerva-3B-base-v1.0

You need to agree to share your contact information to access this model This repository is publicly accessible, but you have to accept the conditions to access its files and content. Login or Sign Up to review the conditions and access this model content

Ok, ma fortunatamente (sic!), la Hugging Face del "singolaritario" Julien Chaumond [1], non è schizzinosa e si accontenta di una "temporary email". Quello che mi serve scaricare, per un primo giudizio, è il file tokenizer.json [2] Per evitarvi la trasformazione da json a plain text, potete visualizzare i token ivi contenuti qui: https://www.saela.eu/minerva/ In breve, il vocab_size è 32768 token (quello di GPT2-3 è 50257, di GPT3.5-4 è 100256, di LLaMA 32768) Per un vocabolario "bilingue", inglese e italiano, è sufficiente. Ma i token sono quelli che rendono il model efficiente ? Secondo me, no. Intanto i 32768 vanno divisi per due (due lingue) e poi per quattro. Questa divisione può non essere chiara. Provo a spiegarla. Prendiamo un lemma semplice: casa. Come token possiamo trovarlo in quattro o anche più posizioni, casa, Casa, _casa, _Casa, _CASA (dove l'underscore sta per spazio) e già questo significa "spreco" di risorse computazionali, perché il significato è sempre lo stesso. Quindi, 32768 : 8 = 4096, 4096 token non sono tantissimi e bisogna sceglierli con "cura". Accuratezza che, ovviamente, i vari Sentencepiece, lavorando esclusivamente sulla statistica, non hanno. Basta dare un'occhiata all'elenco dei token per capire cosa voglio dire. Vi troviamo _casinò, _casino, _Casino e _casinos, tanti segni, ad esempio '.....', '...]', '0%)' ma mancano, per dire: gioioso, delizia, giocattolo. In questi casi il model dovrà usare due, o più, token di grandezza inferiore per comporre la parola e ciò a scapito dell'efficienza. Forse servirebbe un po' meno statistica e un po' più morfologia :)

Antonio

[1] https://medium.com/@julien_c/about [2] https://huggingface.co/sapienzanlp/Minerva-3B-base-v1.0/raw/main/tokenizer.j... [3] https://en.wikipedia.org/wiki/Byte_pair_encoding [4] https://medium.com/codex/sentencepiece-a-simple-and-language-independent-sub...