HPD-Parsing: Baidu legge una pagina come una redazione, prima il menabò e poi i pezzi in parallelo

In una redazione il giornale non lo scrive una persona sola, dalla testata all’ultima breve. Il caporedattore disegna il menabò: qui l’apertura, lì la colonna di spalla, in basso il box con la tabella. Poi assegna i pezzi, e i redattori scrivono ciascuno il suo, nello stesso momento. Il caporedattore deve vedere tutta la pagina; chi scrive la breve sulla viabilità no, gli basta sapere dove va e quanto spazio ha.

I parser di documenti basati su modelli visione-linguaggio, quelli che trasformano la scansione di una pagina in testo, tabelle e formule, oggi lavorano come il redattore unico. Guardano l’immagine intera e poi scrivono tutto il risultato in una sola fila, un token dopo l’altro, dal titolo al numero di pagina. HPD-Parsing: Hierarchical Parallel Document Parsing, uscito su arXiv il 21 luglio 2026 (2607.18839), propone di organizzarli come una redazione. Lo firma il gruppo PaddleOCR di Baidu, con Shu Wei, Jingjing Wu e Lingshu Zhang primi autori a pari merito e Qunyi Xie a capo del progetto; codice nel repository PaddleOCR, pesi su Hugging Face.

Dove si perde il tempo

Il punto di partenza è una misura. Gli autori addestrano un parser convenzionale su InternVL3.5-1B, lo fanno girare con vLLM e dividono i campioni per lunghezza dell’uscita. La codifica dell’immagine costa più o meno lo stesso qualunque sia la pagina; la generazione del testo cresce con la lunghezza e, sulle pagine più dense, dura quasi 500 volte la codifica. Il collo di bottiglia non è guardare la pagina, è scriverla un token alla volta.

Le strade già battute per accorciare quel tempo sono due. Una riduce quello che il modello deve guardare a ogni passo: DeepSeek-OCR comprime i token visivi, Unlimited OCR, dello stesso gruppo di Baidu, limita l’attenzione sul testo agli ultimi 128 token scritti, e con essa la cache. L’altra fa avanzare il modello di più token per passo: GLM-OCR con la multi-token prediction, HunyuanOCR-1.5 con una bozza parallela verificata dal modello. HPD-Parsing appartiene alla seconda famiglia, ma cambia la domanda: non come scrivere più in fretta la stessa fila, ma perché scriverla come una fila sola.

L’osservazione su cui poggia tutto è che in una pagina la struttura è globale e il contenuto è locale. L’ordine di lettura, le colonne, dove comincia una tabella richiedono di vedere l’insieme. Ma per trascrivere un paragrafo basta la sua porzione di immagine: il testo della seconda colonna non dipende parola per parola da quello della prima.

Un ramo che impagina, tanti rami che scrivono

Il modello è piccolo: circa un miliardo di parametri, un encoder visivo InternViT da 0,3 miliardi che spezza la pagina fino a 24 riquadri da 448×448 pixel, e un decoder da 0,8 miliardi con l’architettura di Qwen3-0.6B. La novità sta tutta nel modo di generare.

Il ramo di layout percorre la pagina nell’ordine di lettura e, per ogni blocco, scrive tre cose: la categoria (paragrafo, tabella, formula…), le coordinate normalizzate del riquadro e un token speciale, <FORK>. Quando lo scheduler lo vede, apre un ramo di contenuto per quel blocco: il nuovo ramo riusa la cache già calcolata dell’immagine e dell’impaginato fin lì, sostituisce <FORK> con <CHILD> e comincia a trascrivere. Intanto il ramo di layout va avanti a individuare il blocco successivo. Quando tutti i figli di una pagina hanno finito, i risultati vengono ricuciti nell’ordine del menabò.

Ogni ramo vede l’immagine, la struttura della pagina fino al proprio blocco e il testo che ha scritto lui, non quello degli altri. Nell’addestramento questo si traduce in una maschera: di una sequenza di contenuto si valutano solo i token dopo <CHILD>,

$$M_t^{\text{dec}} = \mathbb{I}\big(t > t_{\langle\text{CHILD}\rangle}\big),$$

mentre il prefisso fa solo da contesto. La conseguenza, secondo gli autori, è che il percorso critico della decodifica non è più la somma delle lunghezze dei blocchi ma è determinato soprattutto dal ramo più lungo. In forma schematica (la scrittura è nostra, non del paper):

$$T_{\text{AR}} \approx \sum_{i} \ell_i \qquad\longrightarrow\qquad T_{\text{HPD}} \approx \ell_{\text{layout}} + \max_i \ell_i .$$

Dentro ogni ramo lavora poi la seconda leva, la P-MTP (Progressive Multi-Token Prediction), presentata dallo stesso gruppo in un lavoro di giugno: un piccolo modulo MLP propone i token successivi a partire dagli stati nascosti del decoder, il modello li verifica in parallelo e tiene quelli giusti. L’addestramento pesa di più le previsioni vicine e meno quelle lontane e incerte. Su un testo così ancorato all’immagine le previsioni sono facili: gli autori riportano in media 6,6 token accettati per passo.

Come ci arriva

Un modello non passa da una fila sola ai rami senza perdere qualcosa, e gli autori lo portano lì in tre tappe. Prima impara a leggere nel modo classico, su 2,8 milioni di pagine intere annotate soprattutto con MinerU-2.5 Pro. Poi cambia formato: 100 mila campioni curati, spezzati in sequenze di layout e sequenze di contenuto. Infine un breve apprendimento per rinforzo su 600 casi difficili, con ricompense separate per formule, tabelle e layout, più controlli di coerenza sui conteggi: la struttura a rami rende più facile dare il merito, o la colpa, al pezzo giusto.

Le etichette sono in larga parte prodotte da altri modelli. PaddleOCR-VL-1.5 e MinerU-2.5 Pro generano pseudo-annotazioni, una versione intermedia di HPD-Parsing le confronta con le proprie e divide i campioni in facili, medi e difficili; quelli difficili passano da un VLM «più forte», che il paper non nomina, finché non superano un criterio di qualità o non si esaurisce un numero massimo di tentativi.

I numeri

Velocità. Su OmniDocBench v1.6, con 512 richieste in parallelo su GPU A800, HPD-Parsing produce 3,06 volte i token al secondo della stessa architettura addestrata in modo autoregressivo, e 2,62 volte le pagine. Sul più veloce fra gli altri, DeepSeek-OCR-2, il vantaggio è di 1,62 volte in token e 1,31 in pagine. Il guadagno cresce con la lunghezza: nelle pagine più dense i passi di decodifica calano di 18 volte, il throughput sale di 3,67 e la latenza della singola richiesta, misurata da sola, scende di 5,8.

Qualità. Il punteggio complessivo è il più alto fra i parser «unificati» in tabella, di poco sopra HunyuanOCR-1.5. Le formule sono il punto forte (97,28 di CDM); sulle tabelle HunyuanOCR-1.5 resta avanti (93,67 contro 91,35 di TEDS). Nell’ordine di lettura, 0,124 di distanza di edit, è il migliore fra gli unificati. I migliori sistemi a pipeline, che usano un rilevatore di layout separato, restano sopra. PaddleOCR-VL-1.6 è dello stesso ecosistema di HPD-Parsing.

C’è poi un vantaggio che non è di velocità. Un modello che scrive tutta la pagina in una fila, se entra in un ciclo di ripetizioni, trascina l’errore fino in fondo; qui il ciclo resta chiuso nel suo ramo. Il paper lo mostra con un esempio, non con una misura.

Che cosa non si può ancora dire

Un numero sbagliato in copertina. L’abstract dice che HPD-Parsing ha «2,62 volte il throughput del modello più veloce esistente». Nel corpo del paper e in tabella il rapporto col più veloce è 1,62 in token e 1,31 in pagine; 2,62 è il guadagno sul proprio baseline, in pagine. Chi cita l’abstract riporta un numero gonfiato.

Quanto costa in accuratezza il passaggio ai rami. Il baseline autoregressivo compare nella tabella della velocità, non in quella della qualità. «Accuratezza competitiva» vuol dire competitiva con gli altri modelli: se l’HPD perda qualcosa rispetto alla stessa rete che scrive in fila, dal paper non si ricava. Manca anche l’ablazione che separi i due contributi, i rami e la P-MTP: con 6,6 token per passo, una parte consistente del guadagno potrebbe venire dalla sola seconda.

Velocità misurate in casa. Tutti i throughput sono misurati dagli autori sulla loro implementazione in vLLM. Unlimited OCR, che il suo rapporto di giugno dava a 5580 token al secondo su OmniDocBench con 512 richieste in parallelo (senza precisare la versione del benchmark), qui figura a 2902: le misure fra paper diversi non si possono mettere in fila.

L’ipotesi di località. L’idea regge finché i blocchi si possono trascrivere ciascuno per conto suo. Una tabella spezzata su due colonne, una nota che rimanda a un’altra, un paragrafo che continua dopo una figura: il paper non misura questi casi separatamente, e la valutazione si ferma a un solo benchmark, a pagina singola.

Perché conta adesso

I parser di documenti sono il primo anello di quasi ogni sistema RAG aziendale: quello che non entra bene dalla scansione non si ritrova dopo. E per chi deve digitalizzare milioni di pagine, 2,6 volte le pagine al secondo sulla stessa GPU vuol dire una bolletta di calcolo più che dimezzata: con la cautela che il confronto è col baseline degli stessi autori. Nell’arco di un mese lo stesso gruppo di Baidu ha attaccato la lentezza dei decoder da due lati: Unlimited OCR accorcia ciò che il modello deve ricordare, HPD-Parsing accorcia la fila che deve scrivere. Gli autori pensano già all’estrazione di informazioni e ai documenti di più pagine, dove la struttura «coordinata in alto, scomponibile in basso» si ripete. Con pesi e codice pubblici, il confronto che manca, rami contro fila sulla stessa rete e sulla stessa qualità, possono farlo anche altri.