Riepilogo Tecnico: Frontiere Tasso–Utilità per le Codifiche del Linguaggio

Definizione del Problema

I modelli linguistici elaborano il testo attraverso varie codifiche: token di sottoparole, byte grezzi o pixel renderizzati. Sebbene studi precedenti abbiano stabilito che i tokenizer introducano squilibri multilingue (ad esempio, una variabile "fertilità" o lunghezze di sequenza variabili tra le lingue), tali confronti spesso confondono tre fattori distinti: il tasso sorgente (numero di posizioni di input), la capacità a valle (dimensione latente disponibile dopo la codifica) e l'informazione rilevante per il task preservata.

Gli studi esistenti spesso confrontano le codifiche utilizzando lunghezze di sequenza o budget computazionali fissi. Tuttavia, come dimostrato nella Figura 1, una lunghezza di input fissa espone quantità diverse di contenuto linguistico a seconda della codifica e della lingua (ad esempio, il cinese richiede più token ma meno byte rispetto all'inglese per la stessa frase). Di conseguenza, le differenze di prestazioni osservate possono riflettere quanto contenuto è stato mostrato al modello o quanta capacità è stata allocata, piuttosto che l'utilità intrinseca della codifica stessa. La domanda centrale affrontata è: Quale codifica preserva l'informazione utile e rilevante per il task sotto compressione quando sia il contenuto che la capacità a valle sono strettamente controllati?

Metodologia

Gli autori propongono un'analisi controllata delle frontiere tasso–utilità per disaccoppiare il tasso sorgente dalla capacità latente.

1. Regimi di Contenuto e Lingua Controllati

• Dataset: Lo studio utilizza SIB-200, un dataset parallelo tradotto da umani con 13 lingue e 5 script. Ogni frase appare in ogni lingua con un'identica etichetta tematica, garantendo che il contenuto rimanga costante.
• Regimi: Vengono testati cinque regimi specifici per isolare le variabili:
  • Monolingue: Inglese (script Latino) e Cinese (script Han).
  • Multilingue con Stesso Script: Latin-5 (Inglese, Spagnolo, Turco, Indonesiano, Swahili) e Cirillico-5 (Russo, Bulgaro, Ucraino, Serbo, Kazakh).
  • Multiscript: Cinque lingue con cinque script distinti (Inglese, Russo, Arabo, Hindi, Cinese).
• Addestramento del Tokenizer: Per evitare bias derivanti da tokenizer pre-addestrati, gli autori ri-addestrano tokenizer SentencePiece (Unigram, dimensione vocabolario 32k) su traduzioni bibliche parallele corrispondenti per ogni specifico regime linguistico.

2. Codifiche

Vengono confrontate tre codifiche sullo stesso contenuto:

• Token: Segmentazione di sottoparole appresa tramite SentencePiece.
• Byte: Sequenze di byte UTF-8 grezzi (alfabeto fisso di 256).
• Pixel: Testo renderizzato come immagini in scala di grigi (Noto Sans 16pt) e suddiviso in patch di pixel non sovrapponenti di $36 \times 32$.

3. Architettura di Bottleneck Condivisa

Per controllare la capacità a valle, tutte le codifiche passano attraverso un encoder basato su Transformer condiviso seguito da uno strato di bottleneck.

• Architettura: Un Transformer a 6 strati pre-norm con dimensione nascosta di 256.
• Bottleneck: Una singola query appresa (stile Perceiver) presta attenzione all'output dell'encoder e lo comprime in un singolo vettore di ampiezza $D$.
• Scansione della Capacità (Capacity Sweep): La larghezza del bottleneck $D$ viene scansionata attraverso 15 valori ($256, 128, \dots, 1$). Ciò consente di tracciare le frontiere di utilità: come le prestazioni degradano al ridursi della capacità.

4. Utilità di Valutazione

Tre task distinti sondano diversi aspetti della rappresentazione compressa:

1. Preservazione della Forma: Auto-recupero (perdita InfoNCE) per misurare se la forma superficiale della frase può essere recuperata dal latente.
2. Allineamento Cross-Linguale: Recupero cross-linguale (multi-positive InfoNCE) per misurare se le traduzioni della stessa frase rimangono vicine nello spazio di rappresentazione.
3. Classificazione del Tema: Un head di classificazione lineare per misurare se l'informazione sul tema semantico è preservata per la predizione a valle.

Risultati Chiave

1. Disparità del Tasso Sorgente

I tassi sorgente variano significamente per lingua e script, indipendentemente dall'efficienza intrinseca della codifica.

• Token: Il cinese è il più costoso (1.71$\times$ i token dell'inglese), mentre l'inglese è il più economico.
• Byte: Il cinese è più economico dell'inglese (0.94$\times$), ma l'hindi è il più costoso (2.59$\times$).
• Pixel: Il cinese, l'arabo e l'hindi sono i più economici (0.72–0.83$\times$ l'inglese), mentre gli script latini sono più costosi.
• Conclusione: La codifica "più economica" dipende interamente dal mix di lingue e script; non esiste una singola codifica universalmente più breve.

2. Frontiere di Utilità

Nessuna codifica domina in tutti i task o i regimi di capacità. La scelta ottimale dipende dall'utilità specifica e dalla larghezza del bottleneck ($D$).

• Preservazione della Forma:

  • I Pixel dominano quando la capacità è abbondante ($D \ge 48$), raggiungendo una Recall@1 quasi perfetta. Preservano gli aspetti superficiali (glifi, spaziatura) più efficacemente.
  • I Byte superano i pixel e i token in bottleneck molto stretti ($D < 10$) nei regimi con stesso script, poiché mantengono l'esatta sequenza UTF-8 che degrada lentamente.
  • I Token collassano più velocemente al diminuire di $D$, fallendo nel preservare elementi di vocabolario specifici in latenti stretti.

• Allineamento Cross-Linguale:

  • I Byte sono la codifica più robusta per allineare le traduzioni, superando token e pixel in tutte le ampiezze e i regimi.
  • I Pixel performano scarsamente, specialmente nelle impostazioni multiscript, poiché la somiglianza visiva non correla con l'equivalenza semantica tra script diversi.
  • I Token si collocano tra byte e pixel.
  • Insight: Il matching a livello di byte sfrutta la sovrapposizione di caratteri nelle lingue con stesso script (es. russo-ucraino), ma questo vantaggio diminuisce nelle impostazioni multiscript.

• Classificazione del Tema:

  • I Token dominano questo task, mantenendo alti punteggi di Macro-F1 anche a bassi valori di $D$ (fino a 8). Le loro unità dense e cariche di significato sono efficienti per decisioni semantiche grossolane.
  • I Byte performano moderatamente ma richiedono più capacità per riassemblare le parole dai caratteri.
  • I Pixel sono generalmente deboli, con prestazioni vicine al caso casuale, eccetto che in cinese. In cinese, i pixel ottengono un significativo incremento (0.36 Macro-F1) perché i caratteri logografici sono unità portatrici di significato, permettendo ai patch visivi di codificare direttamente unità semantiche.

3. Costo Computazionale

• FLOPs di Addestramento: I byte sono generalmente i più costosi da addestrare (a causa delle lunghezze di sequenza maggiori), mentre i pixel sono i più economici.
• Convergenza: I modelli a token convergono più velocemente per la preservazione della forma; i modelli a byte convergono più velocemente per il recupero cross-linguale.
• Trade-off: Per il recupero cross-linguale nei regimi con stesso script, il guadagno di performance dei byte rispetto ai token costa solo 1.4–1.6$\times$ i FLOPs. Tuttavia, nelle impostazioni multiscript, il guadagno è trascurabile (0.01 Recall@1) mentre il costo balza a 4.2$\times$.

Significato e Rivendicazioni

Il paper sostiene che la scelta della codifica del testo non è una preferenza fissa per token, byte o pixel, ma un trade-off tasso–utilità dipendente da:

1. Il Task: I task superficiali favoriscono i pixel; l'allineamento semantico favorisce i byte; la predizione del tema favorisce i token.
2. Il Mix Linguistico: La diversità degli script (es. multiscript vs stesso script) altera drasticamente quale codifica preserva l'informazione utile.
3. Il Regime di Capacità: Input brevi possono scartare il significato utile, mentre input lunghi possono preservare strutture che si comprimono bene.

Contributi Chiave:

• Confronto Controllato: Introduce una metodologia che mantiene costanti il contenuto linguistico e la capacità a valle per isolare l'utilità delle codifiche.
• Disaccoppiamento delle Quantità: Separa il tasso sorgente, la capacità latente e l'informazione preservata, dimostrando che il tasso sorgente da solo non predice l'utilità.
• Frontiere Empiriche: Fornisce prove empiriche che le codifiche "più economiche" (in termini di lunghezza della sequenza) non sono necessariamente "migliori", e che la codifica ottimale cambia in base al bottleneck informativo e ai requisiti del task.

Gli autori concludono che la codifica dell'input debba essere scelta insieme all'architettura del modello e agli obiettivi di addestramento piuttosto che essere trattata come un passaggio di pre-elaborazione statico, poiché la sua efficacia è contingente sull'utilità specifica che si intende ottimizzare e sulla capacità disponibile del sistema.