Length-MAX Tokenizer: novità, come funziona e guida completa alla nuova tokenizzazione per Language Models

Di /
stato della ricerca deep learning

Novità del paper Length-MAX Tokenizer for Language Models e panoramica

Oggi su mauroscIA diamo uno sguardo al paper “Length-MAX Tokenizer for Language Models”. Propone una novità molto concreta ma spesso sottovalutata: cambiare il modo in cui costruiamo il tokenizer per un Large Language Model, con l’obiettivo esplicito di ridurre il numero di token usati per rappresentare un documento, senza peggiorare le prestazioni del modello e anzi migliorandole.

Oggi la maggior parte dei modelli usa varianti di Byte Pair Encoding (BPE), WordPiece o SentencePiece. Tutte queste tecniche scelgono i token più frequenti nel corpus e costruiscono il vocabolario combinando pezzi di testo molto usati. Il problema è che questa strategia tende a privilegiare token relativamente corti: molti frammenti frequenti ma piccoli producono sequenze più lunghe del necessario. Poiché il costo dell’attention cresce più che linearmente con la lunghezza della sequenza, questo si traduce in più GPU-hour, più memoria, più latenza e spesso peggior capacità di ragionare su contesti lunghi.

Length-MAX cambia la funzione obiettivo: invece di guardare solo alla frequenza, valuta ogni possibile token considerando insieme quanto compare e quanto è lungo, in pratica premiando i pezzi lunghi che coprono grandi porzioni di testo. In termini verbali, il punteggio di un token è il prodotto tra la sua frequenza nel corpus e il numero di caratteri che contiene. Questo porta naturalmente a favorire token che “mangiano” intere espressioni come “The_United_States_” o “in_the_midst_of_”, riducendo notevolmente il numero totale di token necessari a rappresentare la stessa frase.

Gli autori allenano tokenizers e modelli su FineWeb, un grande dataset open derivato da CommonCrawl, ormai uno standard de facto per la pre-training data pipeline. Confrontando Length-MAX con BPE, WordPiece e SentencePiece su vocabolari da 10k a 50k token, ottengono una riduzione dei tokens per character (TPC) del 14-18%, che rimane ancora del 13% quando il vocabolario cresce a 64k e intorno al 10% anche a 100k token.

La parte forse più interessante è che questi guadagni di compressione si traducono in benefici reali per i Language Models. Allenando GPT-2 da zero in tre varianti – 124M, 355M e 1.3B parametri – con hyperparameter identici e cambiando solo il tokenizer, i modelli con Length-MAX raggiungono la stessa loss di validazione con circa il 18% di passi in meno, riducono la latenza di inferenza di circa il 13-14% e aumentano la throughput del 16% sul modello da 124M.

Anche la qualità non solo non cala, ma migliora: su benchmark come GLUE, LAMBADA e HellaSwag, il modello con Length-MAX ottiene un macro-average più alto, una riduzione dell’11.7% della perplexity su LAMBADA e un incremento di 4.3 punti di accuracy su HellaSwag. In parallelo, il tokenizer raggiunge il 99.62% di copertura del vocabolario con un tasso di out-of-vocabulary intorno allo 0.12%, mantenendo quindi una rappresentazione robusta anche per parole rare.

Dal punto di vista di sistema, la novità è che Length-MAX è pensato come una libreria production-ready: l’algoritmo è progettato per scalare linearmente con i bytes del corpus, può sfruttare centinaia di core CPU con efficienza vicina al 90% e produce strutture di decodifica basate su DFA (deterministic finite automata) implementate in Rust, che rendono la decodifica 3-4 volte più veloce rispetto a una scansione naive.

In sintesi, il paper è interessante perché dimostra che intervenire “solo” sul tokenizer, senza cambiare l’architettura del modello, può portare a un miglior rapporto qualità/costo: meno passi, meno memoria, meno latenza, stessa o migliore accuracy. In un momento storico in cui ogni punto percentuale di efficienza conta, avere un tokenizer che accorcia le sequenze del 15% circa è un vantaggio competitivo notevole.

Riepilogo i link principali:

Indice

Length-MAX Tokenizer: come funziona, tecniche e training recipe

Per capire come funziona Length-MAX, conviene partire dal confronto con BPE. BPE costruisce il vocabolario partendo dai singoli caratteri e, a ogni passo, fonde la coppia di token contigua più frequente nel corpus. Dopo decine o centinaia di fusioni si ottiene un vocabolario di sottoparole che rappresenta bene le combinazioni frequenti, ma con una forte preferenza per unità corte: prefissi, suffissi e combinazioni molto locali.

Length-MAX ragiona invece in termini di copertura in lunghezza. Si considerano tutte le possibili stringhe candidate come token e per ognuna si calcola un punteggio che combina quante volte compare e quanti caratteri copre. Un token lungo che appare spesso ottiene un punteggio enorme, mentre un frammento corto, anche se molto frequente, non viene più favorito così tanto. In parole semplici, l’obiettivo non è più “spremere il massimo di frequenza da ogni fusion di simboli”, ma “coprire il testo con il minor numero possibile di pezzi lunghi sensati”.

Formulare questo problema in modo preciso porta a una connessione con il graph partitioning: si può costruire un grafo in cui i nodi sono sequenze di testo e i pesi degli archi misurano quanto prefisso hanno in comune. Gli autori mostrano che massimizzare la copertura in lunghezza equivale, in questo grafo, a trovare una partizione che massimizza una certa funzione dei pesi interni ai cluster. Questo problema è dimostrato NP-hard, quindi irrisolvibile in modo esatto per corpus realistici. Per questo viene usato un algoritmo greedy che, a ogni passo, sceglie la “split” più redditizia in termini di aumento di lunghezza media dei token, mantenendo però proprietà di monotonicità: a ogni iterazione la lunghezza media coperta dal vocabolario cresce e ci si avvicina a un optimum locale già molto buono nella pratica.

Tutta questa teoria viene poi concretizzata in un’implementazione molto attenta all’infrastructure engineering. Il corpus viene diviso in shard separati da un token di fine testo; ogni shard viene processato indipendentemente da un worker CPU, che scorre il testo con una finestra in stile Rabin-Karp rolling hash per contare gli n-gram candidati. Su ogni worker viene mantenuta una struttura tipo max-heap, chiamata local scoreboard, che tiene traccia dei candidati con punteggio più alto. A intervalli regolari, un processo driver fonde tutte le scoreboard locali in un global scoreboard, sceglie il token migliore, lo aggiunge al vocabolario e sostituisce tutte le sue occorrenze nel corpus tokenizzato, senza dover rileggere le bytes originali. Questo ciclo si ripete fino al raggiungimento della dimensione di vocabolario desiderata.

Un dettaglio importante è che Length-MAX applica le sostituzioni “in place” sullo stesso corpus che sta usando per allenare il tokenizer. Quando il processo termina, il dataset è già tokenizzato con il nuovo vocabolario e non serve una seconda passata di encoding. Se invece si vuole usare il vocabolario in un secondo momento, viene compilato in una trie e poi in una DFA Rust tramite la libreria regex-automata, seguendo una strategia “left-most longest match”: quando il decoder processa una stringa, prova sempre a fare il match con il token più lungo possibile, evitando di spezzare troppo la sequenza. Questo porta a una decodifica 3-4 volte più veloce rispetto a una ricerca token per token.

Sul fronte training recipe, gli autori si concentrano su modelli GPT-2 di tre taglie (124M, 355M, 1.3B parametri) addestrati da zero su porzioni di FineWeb10B di dimensioni crescenti, in modo da rispettare le scaling law del modello. Per ogni taglia allenano cinque run indipendenti con hyperparameter identici e cambiano solo il tokenizer: BPE, WordPiece, SentencePiece e Length-MAX, sempre addestrati sullo stesso corpus FineWeb. Questo design sperimentale è importante perché isola l’effetto della tokenizzazione da altri fattori come architettura, learning rate o scheduler.

Infine, dal punto di vista del deployment, Length-MAX è progettato per integrarsi in una pipeline standard per LLM: preprocessing dei dati in shard, tokenizzazione su CPU con parallelismo forte, salvataggio dei file tokenizzati e training del Transformer su GPU. La libreria espone API che permettono di scegliere dimensione del vocabolario, soglia minima di frequenza per i candidati, parametri della finestra Rabin-Karp e strategie di checkpointing per garantire fault tolerance durante l’addestramento del tokenizer in ambienti distribuiti.

Risultati sperimentali: cosa cambia davvero rispetto a BPE e agli altri tokenizer

La prima metrica analizzata è la tokenization efficiency, misurata tramite i tokens per character. Su FineWeb10B, con vocabolari tra 10k e 50k token, Length-MAX riduce il TPC del 14-18% rispetto a BPE, WordPiece e SentencePiece. Anche portando il vocabolario a 64k token il vantaggio rimane attorno al 13%, e a 100k – zona in cui tutti i metodi si avvicinano a un comportamento quasi word-level – la riduzione è comunque vicina al 10%.

Questa riduzione non è solo una media globale: gli autori valutano la compressione su domini diversi, come news, testi tecnici, letteratura, conversazioni e testo “misto”. Su ogni dominio Length-MAX usa circa il 14-15% di token in meno rispetto a BPE, con un risultato medio di circa 361 token per passaggio, contro i 425 di BPE e valori intermedi per WordPiece e SentencePiece. Questo suggerisce che l’approccio length-aware non dipende da un dominio molto specifico, ma si generalizza bene.

La seconda dimensione è il training cost. Nel caso più dettagliato, un GPT-2 da 124M parametri allenato su circa 15 GB di testo aperto con BPE richiede poco più di 92k passi per raggiungere una certa soglia di validazione loss; con Length-MAX bastano circa 75k passi, cioè circa il 19% di passi in meno e quasi il 20% di GPU-hours in meno, mantenendo invariati batch size, scheduler e hardware. In media, sulle cinque run, la riduzione dei passi è del 18.5%. Riduzioni simili, intorno al 17-18%, vengono osservate anche per i modelli da 355M e 1.3B parametri.

Terzo asse: inference cost. Per GPT-2 124M, misurando il tempo per decodificare fino a 1.024 caratteri su una GPU NVIDIA A100, il modello con BPE genera circa 1.98 token al secondo, con una latenza di circa 517 ms; il modello con Length-MAX arriva a 2.30 token al secondo, con latenza ridotta a circa 446 ms. Il miglioramento di throughput è quindi di circa il 16%, mentre la latenza scende di circa il 13.7%, con test di significatività statistica basati su bootstrap che confermano che non è solo rumore. A queste cifre si aggiunge una riduzione di circa il 18% della memoria occupata da embedding e KV-cache, perché ci sono meno token da rappresentare per ogni input e conseguente minor numero di stati in memoria.

Dal lato downstream performance, i risultati sono altrettanto interessanti. Sul benchmark GLUE, la macro-media di accuracy passa, per GPT-2, da circa 0.366 con BPE a 0.413 con Length-MAX. I guadagni sono particularmente significativi su task di natural language inference, come RTE e QNLI, dove si vedono incrementi rispettivamente del 58% e del 49% relativi rispetto al baseline. Anche su task come QQP, WNLI e MNLI si osservano miglioramenti che vanno da qualche punto percentuale fino a oltre il 20% relativo.

Per verificare che non si tratti di overfitting su GLUE, gli autori testano anche su BLiMP, LAMBADA, StoryCloze, HellaSwag, PIQA, SQuAD e WSC273. Qui Length-MAX mostra, ad esempio, una riduzione dell’11.7% della perplexity su LAMBADA e un aumento di 4.3 punti di accuracy su HellaSwag rispetto a BPE, con una macro-media complessiva di circa 2.9 punti più alta sui sette benchmark. Il messaggio che passa è che usare token più lunghi, spesso equivalenti a multi-word expressions, aiuta il modello a mantenere meglio il contesto e a rappresentare concetti complessi in meno passi di decoding.

Sul fronte robustezza e copertura, Length-MAX raggiunge una copertura del 99.62% sul vocabolario di test, con una OOV rate intorno allo 0.12%, quindi non sacrifica la capacità di rappresentare parole rare o varianti morfologiche poco comuni. Inoltre, gli autori verificano che la distribuzione delle frequenze dei token continui a seguire un profilo Zipf-like; l’allineamento Zipf rimane alto, con coefficienti che indicano una forte correlazione tra la distribuzione di Length-MAX e quella tipica di vocabolari di qualità.

Infine, viene proposta anche una extrapolation a 7B parametri, usando una stima dei FLOPs basata sulla riduzione di token e sull’andamento misurato ai tre scale testati. La previsione suggerisce che i guadagni relativi di steps e latenza si mantengono stabili anche per modelli molto più grandi. Pur essendo solo una stima analitica, dà un’indicazione interessante: un tokenizer più efficiente non è un trucco locale, ma qualcosa che potenzialmente scala con l’aumentare della dimensione del modello.

Concetti chiave da capire per leggere il paper: guida completa

Per leggere il paper in modo fluido è utile chiarire alcuni concetti fondamentali che ritornano continuamente.

Il primo è la differenza tra compressione “in token” e compressione “in byte”. Molte discussioni sulla compressione si concentrano sui bit necessari a rappresentare un testo; qui invece l’obiettivo è ridurre il numero di token che il modello vede per ogni carattere. Questo è importante perché il costo dell’attention nei Transformer dipende principalmente dalla lunghezza in token della sequenza, non dal peso in byte del file. Ridurre i tokens per character vuol dire avere sequenze più corte a parità di testo e quindi meno operazioni di attention e MLP da eseguire per batch.

Il secondo concetto è quello di vocabolario di subword. Invece di usare parole intere o singoli caratteri, i moderni tokenizer operano su unità intermedie: prefissi, suffissi, radici, parti di parole composte, simboli, spazi. BPE, WordPiece e SentencePiece sono tre famiglie di tecniche che costruiscono questo vocabolario in modo data-driven, partendo dai caratteri e fondendo gradualmente i pezzi più frequenti. Length-MAX si colloca in questa famiglia, ma modifica il criterio con cui decide quali unità finire nel vocabolario, enfatizzando la lunghezza media invece della sola frequenza.

Un terzo punto chiave è l’idea di graph partitioning. Il paper mostra che scegliere il miglior vocabolario rispetto alla copertura in lunghezza è equivalente a dividere un grafo di sequenze in cluster, in modo che dentro ogni cluster le frasi condividano un prefisso comune più lungo possibile. Intuitivamente, è come raggruppare tutte le frasi che iniziano con “the quick brown…” da una parte e quelle che iniziano con “she sells sea…” dall’altra, e poi creare token che catturino questi prefissi condivisi. Il fatto che questo problema sia NP-hard spiega perché serve una procedura greedy approssimata: non possiamo esplorare tutte le partizioni possibili, ma possiamo scegliere a ogni passo la split che più aumenta la lunghezza coperta dal vocabolario, garantendo che ogni iterazione sia un miglioramento.

Quarto elemento: la scoreboard architecture. In un corpus enorme non è possibile tenere in memoria tutte le possibili stringhe candidate come token. Length-MAX usa quindi una serie di scoreboard locali che mantengono soltanto i candidati migliori, aggiornandoli man mano che il corpus viene riscritto con i nuovi token inseriti. Periodicamente un processo centrale unisce questi scoreboard in uno globale e seleziona il token successivo da aggiungere al vocabolario. Questo design, unito all’uso di Rabin-Karp per l’hashing veloce degli n-gram, consente una complessità lineare in funzione della dimensione del corpus e una scalabilità quasi lineare rispetto al numero di core CPU.

Un quinto concetto che vale la pena capire è Zipf’s law nel contesto della tokenizzazione. In molti corpora linguistici la frequenza dei token segue una distribuzione a legge di potenza: pochi token molto frequenti, lunga coda di token rari. Lavori recenti suggeriscono che mantenere questa struttura Zipf-like è importante per la qualità dei modelli; un vocabolario troppo piatto o troppo estremo potrebbe compromettere la generalizzazione. Per questo gli autori controllano che, pur riallocando probabilità verso token più lunghi, la distribuzione finale continui a seguire una legge di Zipf con parametri realistici, cosa che i loro esperimenti confermano.

Infine, il paper si posiziona rispetto a due grandi alternative: i metodi linguistically informed, come MorphPiece, FLOTA o SuperBPE, che incorporano informazioni morfologiche o di confini di parola nel processo di tokenizzazione, e le soluzioni token-free, come CANINE, ByT5 o il Byte Latent Transformer, che lavorano direttamente su byte o caratteri senza vocabolario esplicito. Length-MAX è presentato come ortogonale a entrambi: da un lato può essere combinato con tecniche che usano confini grammaticali, dall’altro offre un modo di ottenere molti dei benefici delle sequenze più corte senza dover riprogettare l’architettura del modello per lavorare a livello di byte.

Se ti avvicini al paper con questi concetti in mente – tokens per character, vocabolario di subword, graph partitioning, scoreboard architecture, Zipf e relazione con metodi token-free – la lettura risulta molto più lineare e le sezioni più tecniche diventano interpretazioni di idee intuitive, più che pura matematica astratta.

Quiz: domande e risposte

In che cosa la funzione obiettivo di Length-MAX è diversa da quella di BPE?

La funzione obiettivo di BPE si basa praticamente solo sulla frequenza: a ogni passo si fonde la coppia di token che compare più spesso nel corpus, senza guardare a quanto testo copre. Length-MAX, invece, valuta ogni possibile token considerando sia quante volte appare sia quanto è lungo, cioè quanti caratteri copre. In pratica preferisce un token che appare meno spesso ma copre un’intera espressione multi-word rispetto a un frammento cortissimo ma frequentissimo. Questo sposta il focus dalla compressione “per fusioni frequentissime ma piccole” alla compressione “per blocchi lunghi e semanticamente coerenti”.

Perché ridurre i tokens per character è così importante per un Language Model?

Ridurre i tokens per character significa che, per una stessa frase, il modello vede una sequenza di token più corta. Poiché gran parte del costo computazionale di un Transformer deriva dal layer di self-attention, il cui costo cresce più che linearmente con la lunghezza della sequenza, anche un 10-15% di riduzione può trasformarsi in un risparmio di calcolo molto rilevante. Questo si traduce in meno GPU-hours per il training, latenza più bassa in inferenza e minore occupazione di memoria per embedding e KV-cache. Il paper mostra sperimentalmente che una riduzione media del 14-18% di TPC porta a circa il 18% di passi di training in meno e a un 13-14% di latenza in meno.

Che ruolo ha la Rabin-Karp rolling hash nell’implementazione di Length-MAX?

La Rabin-Karp rolling hash è usata per scorrere il corpus e calcolare velocemente i conteggi degli n-gram candidati a diventare token. Invece di ricomputare da zero il valore di hash per ogni finestra di caratteri, l’algoritmo aggiorna il valore precedente in modo incrementale quando la finestra scorre di un carattere. Questo permette di analizzare un corpus enorme in tempo lineare, mantenendo un overhead molto basso per ogni potenziale token, condizione necessaria per poter allenare il tokenizer su dataset come FineWeb con decine di miliardi di token.

Perché gli autori allenano GPT-2 da zero invece di usare modelli già pre-addestrati?

Allenare GPT-2 da zero con tokenizers diversi è l’unico modo per isolare l’effetto della tokenizzazione. Se cambiassero solo il tokenizer su un modello già pre-addestrato, la rappresentazione interna sarebbe stata ottimizzata su un altro spazio di token e i risultati sarebbero difficili da interpretare. Allenando da zero, con hyperparameter e dati identici, l’unica differenza strutturale tra i setup è il tokenizer: qualunque differenza in velocità di convergenza, latenza, memoria o qualità sui benchmark può quindi essere attribuita, con buona confidenza, alla scelta di Length-MAX rispetto a BPE o agli altri baseline.

Che differenza c’è tra i metodi linguistically informed e un approccio come Length-MAX?

I metodi linguistically informed, come MorphPiece, FLOTA o SuperBPE, usano conoscenze linguistiche esplicite, ad esempio segmentatori morfologici o regole sui confini di parola, per guidare la costruzione del vocabolario. Spesso danno priorità a token che corrispondono a morfemi o a unità grammaticali interpretabili. Length-MAX, invece, non utilizza informazioni linguistiche esterne; lavora solo sui pattern statistici del corpus ma modifica profondamente la funzione obiettivo, privilegiando la lunghezza media dei token. Gli autori sostengono che questi due approcci siano ortogonali: nulla vieta di costruire un sistema che combini la sensibilità ai confini linguistici con la funzione obiettivo length-aware proposta da Length-MAX.

Perché nel paper si parla di Zipf alignment e cosa significa che viene “preservato”?

Zipf alignment indica quanto bene la distribuzione di frequenze dei token segue una legge di Zipf, cioè una legge di potenza in cui pochi token sono molto frequenti e molti sono rari. Alcuni lavori recenti suggeriscono che questa struttura sia correlata alla qualità dei modelli, probabilmente perché riflette proprietà profonde della lingua e del modo in cui i modelli apprendono pattern linguistici. Length-MAX sposta massa di probabilità verso token più lunghi, quindi in teoria potrebbe destabilizzare questa distribuzione. Gli autori verificano però che la forma della curva Zipf rimane molto simile a quella di vocabolari considerati “buoni”, con coefficienti di correlazione elevati, il che implica che la ri-allocazione verso token più lunghi non altera le proprietà statistiche globali considerate benefiche.

Studi correlati: novità sulla tokenizzazione e guida completa al contesto

Per chi vuole collocare Length-MAX all’interno del panorama più ampio della ricerca, il paper offre una rassegna piuttosto ricca di lavori correlati e ci permette di costruire una piccola guida completa al tema della tokenizzazione per LLM.

Il punto di partenza sono ovviamente i metodi classici di subword tokenization: BPE, introdotto nel contesto del machine translation e poi adottato massicciamente per i Language Models; WordPiece, usato in modelli come BERT; e SentencePiece, che generalizza queste idee e lavora direttamente su stringhe raw senza bisogno di un pre-tokenizer basato su spazi. Questi metodi hanno reso possibile gestire vocabolari aperti e lingue con morfologia complessa, ma proprio il loro focus sulla frequenza li porta a creare vocabolari composti da molte unità corte, con le limitazioni che Length-MAX cerca di superare.

Un secondo filone è quello dei metodi linguistically informed. Qui rientrano sistemi come MorphPiece, che integra informazione morfologica per segmentare le parole in modo più coerente con la struttura della lingua; FLOTA, che usa regole sui confini e sulle categorie lessicali; e SuperBPE, che costruisce super-parole attraverso un curriculum che tiene conto dei confini e permette di ridurre le sequenze fino a un terzo in alcuni setup con vocabolari molto grandi. Queste tecniche partono dall’idea che i token dovrebbero corrispondere almeno in parte a unità linguistiche interpretabili. Length-MAX, pur non usando esplicitamente queste informazioni, può teoricamente essere combinato con loro: ad esempio, potresti vincolare il candidato token set a rispettare certi confini morfologici e poi usare la funzione obiettivo length-aware per scegliere quali unità mantenere.

C’è poi tutto un filone engineering and systems che guarda alla tokenizzazione in chiave di performance pura. Lavori su librerie ad alte prestazioni come tokenizers-fast, versioni parallele di SentencePiece e strumenti come tiktoken hanno spinto moltissimo su implementazioni in C++ o Rust ottimizzate per SIMD e multithreading. Altri lavori esplorano decode più veloci tramite DFA per BPE o costruzione di vocabolari su GPU. Length-MAX si inserisce qui con una proposta abbastanza originale: cambiare la funzione obiettivo e allo stesso tempo costruire un’implementazione che sfrutta a fondo parallelismo su CPU, scoreboard distribuiti e DFA per la decodifica.

Sul fronte dei dataset, il lavoro si appoggia a FineWeb, una collezione di dati web curata e deduplicata che ha lo scopo esplicito di offrire un pre-training dataset open di qualità paragonabile o superiore ad altri dataset aperti. Ci sono anche lavori derivati, come FinerWeb-10BT, che applicano filtri line-level basati su LLM per migliorare ulteriormente la qualità dei testi; questi studi mostrano quanto la scelta del dataset sia cruciale per valutare correttamente tecniche come Length-MAX.

Infine ci sono le token-free architectures. Modelli come CANINE e ByT5 elaborano direttamente byte o caratteri, eliminando completamente il vocabolario di subword. Più recentemente, il Byte Latent Transformer (BLT) ha mostrato che è possibile avvicinarsi alle prestazioni dei modelli con tokenizer classico lavorando su byte, pur richiedendo modifiche sostanziali all’architettura. Questo filone rappresenta una direzione radicalmente diversa: invece di migliorare la tokenizzazione, la elimina. Length-MAX si posiziona proprio come alternativa pragmatica: non cambia l’architettura, è drop-in compatibile con pipeline esistenti, ma offre una parte significativa dei benefici che ci si aspetterebbe da sequenze più corte.

Guardando l’insieme di queste novità – dai dataset come FineWeb alle architetture token-free, passando per i tokenizers linguistically informed e per gli sforzi di ottimizzazione sistemistica – Length-MAX si presenta come un tassello importante in una guida completa alla progettazione di tokenizer moderni: non l’unica risposta possibile, ma un approccio ben motivato teoricamente, verificato sperimentalmente e pensato per essere immediatamente utile a chi costruisce e mette in produzione LLM ad ampia scala.

Torna in alto