OCR sotto il cofano: come i computer imparano a leggere il testo dalle immagini

Apri una qualsiasi immagine in un editor esadecimale. La foto di un cartello stradale, uno scontrino, uno screenshot di un PDF. All'offset zero trovi l'header del formato. Qualche kilobyte più in là, incontri i dati dei pixel: tre byte per pixel in RGB, una griglia di numeri dove (128, 52, 19) potrebbe essere un muro di mattoni e (240, 238, 220) potrebbe essere carta. Da qualche parte in quella griglia c'è un segnale di stop con la parola "STOP" resa in bianco Highway Gothic su sfondo rosso. Un essere umano vede quattro lettere. Il computer vede un'area di 47 × 19 pixel di valori rosso-adiacenti dove il canale R si aggira intorno a 200 e G e B scendono sotto 40. Mappare quell'area sulla stringa "STOP" è il riconoscimento ottico dei caratteri, ed è stato un problema di ricerca aperto da quando Gustav Tauschek brevettò la prima macchina di lettura nel 1929.

L'OCR è ingannevolmente difficile perché leggere è ingannevolmente facile. Un bambino di sei anni riconosce la lettera A in una dozzina di caratteri, a dimensioni diverse, sotto illuminazione irregolare, leggermente ruotata, parzialmente occlusa e scritta a matita. Un computer ha bisogno di una pipeline: pulire l'immagine, trovare le regioni di testo, segmentare i caratteri o le sequenze di glifi e classificarli uno per uno. Ognuna di queste fasi ha una modalità di guasto, e i guasti si sommano.

Cosa rende difficile l'OCR

Il problema centrale non è la classificazione. Classificare un'immagine di carattere pre-segmentata di 28 × 28 pixel in una delle 62 classi (A–Z, a–z, 0–9) è un compito che una LeNet degli anni '90 può risolvere al 99% di accuratezza. La parte difficile è tutto ciò che viene prima del classificatore.

Variazione dei caratteri. La lettera "g" ha almeno quattro varianti strutturali comuni: a un occhiello (scrittura a mano), a due occhielli (la maggior parte dei caratteri con grazie), la coda ad anello dell'Helvetica e la coda aperta del Futura. Un modello addestrato su Tahoma leggerà male l'Univers a un tasso misurabile. L'OCR reale copre centinaia di caratteri tipografici più la scrittura a mano, che non ha affatto una topologia dei tratti coerente.

Distorsione geometrica. Le foto di documenti raramente sono scansioni piane. Una foto al telefono di uno scontrino introduce inclinazione prospettica, curvatura e scala non uniforme. Il testo vicino alla costa di un libro si piega. Le foto di lavagne catturano l'ombra del fotografo. Un'inclinazione di 10 gradi riduce l'accuratezza di Tesseract da ~97% a meno dell'85% sui benchmark standard. Gli algoritmi di raddrizzamento (rilevamento delle linee di Hough, trasformata di Radon, analisi del profilo di proiezione) recuperano parte di quella perdita, ma nessuno la recupera tutta.

Illuminazione e rumore. Un'illuminazione irregolare trasforma uno sfondo uniforme in un gradiente, rompendo la sogliatura globale. Gli artefatti di compressione JPEG creano ringing intorno ai bordi netti. In termini di OCR, ciò significa ringing intorno ai tratti delle lettere. Il rumore sale e pepe dei sensori in bassa luce riempie lo spazio bianco di pixel scuri che sembrano punteggiatura. Una fotocopia di una fotocopia fonde insieme i tratti sottili, trasformando "rn" in "m" e "cl" in "d".

Complessità del layout. I documenti hanno colonne, didascalie, tabelle, intestazioni, note a piè di pagina e barre laterali. Il testo scorre intorno alle immagini. Alcune lingue vanno da destra a sinistra. Altre mescolano direzioni nello stesso paragrafo. Identificare l'ordine di lettura (quale blocco di testo segue quale) è un problema di analisi del layout separato dal riconoscimento, e sbagliarlo rimescola l'output anche quando ogni carattere è classificato correttamente.

Ambiguità contestuale. Considerando solo il pattern di pixel, "0" (zero), "O" (lettera O maiuscola) e "o" (lettera o minuscola) sono identici in molti caratteri sans-serif. "1", "l", "I" e "|" condividono un tratto verticale. La risoluzione aggiunge un'altra dimensione: a 12 pixel di altezza, "e" e "c" differiscono per un singolo tratto orizzontale largo tre pixel. I lettori umani risolvono queste ambiguità dal contesto. Alle macchine servono modelli linguistici, statistici o appresi, per fare la stessa scelta.

La pipeline OCR tradizionale

Prima del deep learning, l'OCR era una sequenza di fasi progettate a mano. Ogni fase era sviluppata indipendentemente, spesso da gruppi di ricerca diversi, e ottimizzata per un degrado specifico. La pipeline aveva questo aspetto:

Immagine grezza → Pre-elaborazione → Binarizzazione → Raddrizzamento → Analisi del layout
  → Segmentazione dei caratteri → Estrazione delle feature → Classificazione
  → Post-elaborazione (modello linguistico) → Output testuale

Pre-elaborazione e binarizzazione

Le immagini a colori vengono convertite in scala di grigi. La riduzione del rumore smussa il segnale prima della sogliatura. Il filtro mediano gestisce il rumore sale e pepe. La sfocatura gaussiana gestisce il rumore del sensore. Il filtro bilaterale si usa quando la conservazione dei bordi è importante.

La binarizzazione trasforma l'immagine in scala di grigi in testo nero su sfondo bianco. L'algoritmo standard è il metodo di Otsu (1979): cerca esaustivamente la soglia che minimizza la varianza intra-classe tra le distribuzioni dei pixel di primo piano e di sfondo. Otsu presuppone un istogramma bimodale (i pixel del testo si raggruppano a un'intensità, quelli dello sfondo a un'altra), il che funziona per scansioni piane in condizioni di illuminazione controllata e fallisce per foto al telefono con ombre. I metodi adattivi locali (Sauvola, Niblack) calcolano una soglia diversa per pixel basandosi sulle statistiche del vicinato, gestendo l'illuminazione irregolare al costo di artefatti vicino ai bordi.

Raddrizzamento e analisi del layout

L'inclinazione del documento si rileva trovando le linee: o con la trasformata di Hough sui pixel dei bordi, o con l'analisi del profilo di proiezione dove il documento viene ruotato attraverso un intervallo di angoli e si sceglie l'angolo con i picchi di proiezione orizzontale più netti. Una volta noto l'angolo di inclinazione, una trasformazione affine ruota l'immagine all'indietro.

L'analisi del layout segmenta la pagina in blocchi di testo. L'approccio classico esegue l'analisi delle componenti connesse (CCA) per trovare ammassi di pixel di primo piano, li raggruppa in parole per prossimità, poi raggruppa le parole in linee e le linee in blocchi. L'algoritmo XY-cut divide ricorsivamente la pagina trovando spazi bianchi lungo le proiezioni orizzontali e verticali, costruendo un albero di regioni. Le implementazioni moderne usano un approccio ibrido: CCA per gli ammassi iniziali, poi un modello appreso per classificare ogni ammasso come testo, immagine, tabella o separatore.

Segmentazione dei caratteri

Per il testo stampato a macchina, la segmentazione significa tagliare le immagini delle parole in caratteri individuali. Il profilo di proiezione verticale (un istogramma dei conteggi dei pixel di primo piano per colonna) produce picchi ai centri dei caratteri e valli ai confini dei caratteri. Questo funziona finché due caratteri non si toccano, o un carattere non contiene parti disconnesse ("i", "j", ":", "%"). La sovra-segmentazione (tagliare troppo aggressivamente) seguita da fusione basata sulla confidenza del classificatore è una soluzione. Un'altra è saltare del tutto la segmentazione e riconoscere intere parole, che è ciò che fanno i moderni metodi basati su sequenze.

Estrazione delle feature e classificazione

Una volta ottenuta l'immagine di un carattere, bisogna descriverla numericamente per un classificatore. Le feature pre-deep-learning includevano:

• Valori dei pixel grezzi come vettore appiattito (semplice, fragile a traslazione e scala)
• Zoning: dividere il bounding box del carattere in una griglia N × N, contare i pixel di primo piano per cella, usare i conteggi come feature
• Feature basate sul gradiente (HOG): l'istogramma dei gradienti orientati cattura le direzioni dei bordi, robusto a piccole traslazioni
• Scale-invariant feature transform (SIFT): rileva e descrive punti chiave invarianti a scala, rotazione e illuminazione

Il classificatore era tipicamente una support vector machine (SVM) con kernel RBF, addestrata su decine di migliaia di immagini di caratteri etichettate per ogni font. Una pipeline SVM + HOG ben calibrata poteva raggiungere circa il 98% di accuratezza per carattere su testo stampato pulito. Con input rumoroso, inclinato o scritto a mano, l'accuratezza scendeva al 70–80%.

Tesseract: dagli HP Labs alle LSTM

Tesseract è il motore OCR open-source di riferimento. Nacque come progetto di dottorato agli HP Labs di Bristol negli anni '80, fu reso open-source nel 2005, ed è mantenuto da Google dal 2006. La sua architettura si divide nettamente in due ere.

Versione 3: la pipeline classica

Tesseract 3 implementava la pipeline tradizionale con alcune innovazioni. La sua analisi del layout usava un algoritmo di rilevamento dei tab-stop che trovava i confini delle colonne allineando i bounding box delle parole, un'euristica pragmatica calibrata per il tipo di documenti che HP scansionava negli anni '90. La segmentazione dei caratteri usava una logica chopper/associator: il chopper sovra-segmentava l'immagine della parola in tagli candidati, e l'associator usava la confidenza del classificatore e un dizionario per decidere quali tagli unire.

Il classificatore era un sistema a due passate. La prima passata (classificatore statico) confrontava gli ammassi segmentati con prototipi (campioni di addestramento raggruppati) usando una ricerca nearest-neighbor. La seconda passata (classificatore adattivo) si calibrava sul documento stesso, imparando il font specifico usato in quell'immagine. Il classificatore adattivo aveva bisogno di circa una pagina di testo per diventare efficace, motivo per cui Tesseract 3 funzionava male su immagini di singole parole come cartelli stradali e didascalie.

Tesseract 3 distribuiva file .traineddata: archivi contenenti i cluster di prototipi, le definizioni dei set di caratteri, un dizionario di frequenza delle parole e una tabella di ambiguità unichar che mappava coppie di caratteri confondibili. Addestrare una nuova lingua richiedeva fornire a Tesseract immagini di testo abbinate a trascrizioni di riferimento, delimitare ogni carattere ed eseguire gli strumenti di addestramento. Un processo di ore per ogni lingua.

Versione 4/5: LSTM sostituisce la pipeline

Tesseract 4 (2018) ha sostituito l'intero percorso di riconoscimento con una singola rete neurale LSTM. La LSTM opera su una sequenza di fette verticali dell'immagine della linea di testo, ogni fetta larga un pixel e alta quanto l'intera linea di testo. Ogni fetta viene inserita in uno stack di strati LSTM bidirezionali. L'output è una sequenza di probabilità di caratteri con una loss Connectionist Temporal Classification (CTC) che allinea la sequenza di output di lunghezza variabile al testo di riferimento senza richiedere posizioni dei caratteri pre-segmentate.

Il modello LSTM gestisce caratteri a larghezza variabile, caratteri che si toccano e variazione dei font senza il meccanismo chopper/associator. Si basa ancora sull'analisi del layout legacy di Tesseract per trovare le linee di testo, ma il riconoscimento delle linee è neurale end-to-end. Sul benchmark ICDAR 2017, Tesseract 4 ha raggiunto un tasso di errore per carattere (CER) del 4,4% sull'inglese stampato, rispetto al 7,2% di Tesseract 3. Il processo di addestramento è passato dal vecchio strumento di delimitazione all'abbinamento di linee di testo con trascrizioni. Ancora supervisionato, ma con un'etichetta per riga invece che per carattere.

Il formato .traineddata è stato esteso per contenere i pesi del modello LSTM (diversi megabyte) insieme ai dati legacy (dizionario, tabelle unichar) in un unico file. Addestrare da zero un modello LSTM veloce richiede circa 24 ore su una GPU moderna per una lingua a scrittura latina con circa 100 classi di caratteri; le lingue CJK richiedono più tempo a causa dei set di caratteri più grandi.

Caratteristiche di accuratezza

Tesseract 5 ha migliorato la versione 4 con un corpus di addestramento più ampio e parametri predefiniti migliori, ma l'architettura è invariata. L'accuratezza dipende fortemente dall'input:

Il modello LSTM elimina la maggior parte dei problemi di sensibilità ai font della versione 3, ma il motore peggiora ancora su bassa risoluzione (sotto 200 DPI, l'input a fette di pixel della LSTM perde i dettagli dei tratti), testo scritto a mano (il modello è stato addestrato su font stampati; la scrittura a mano ha statistiche dei tratti fondamentalmente diverse) e layout complessi (l'analisi del layout è ancora il percorso di codice legacy, non quello neurale).

Approcci moderni di deep learning

A livello accademico, l'OCR ha superato il paradigma CTC + LSTM intorno al 2019. Tre architetture dominano ora la letteratura.

CRNN + CTC

La Convolutional Recurrent Neural Network (CRNN), pubblicata da Shi et al. nel 2015, abbina un estrattore di feature CNN con un modello di sequenza RNN e decodifica CTC. La CNN estrae feature spaziali dall'immagine, essenzialmente imparando ciò che la LSTM di Tesseract riceveva manualmente (rappresentazioni a fette verticali). La RNN modella le dipendenze sequenziali tra le feature estratte. La CTC gestisce l'allineamento. CRNN-CTC è diventata la baseline standard: addestrabile end-to-end, buona generalizzazione, inferenza veloce (~20 ms per linea su GPU).

Encoder-decoder basato su attention

I modelli basati su attention hanno adattato il paradigma seq2seq dalla traduzione automatica. Un encoder CNN o vision produce una mappa di feature dell'immagine. Un decoder RNN genera il testo di output un carattere alla volta, prestando attention alle regioni spaziali rilevanti della mappa di feature a ogni passo. Il meccanismo di attention rimuove il vincolo monotonico della CTC: il decoder può tornare a parti precedenti dell'immagine quando il modello linguistico si aspetta un pattern ripetuto, sebbene questa flessibilità introduca anche il rischio di allucinazione per input illeggibili. I decoder basati su attention raggiungono circa l'1,5–3% di CER sull'inglese stampato pulito, superando i modelli solo CTC su sequenze lunghe e layout irregolari.

Vision Transformer (TrOCR, Donut)

TrOCR (Microsoft, 2021) ha applicato l'architettura Transformer all'OCR. L'immagine viene divisa in patch, codificata da un encoder ViT (Vision Transformer), e il testo viene decodificato autoregressivamente da un decoder Transformer testuale. È l'architettura di un modello multimodale standard, addestrato specificamente per l'OCR. TrOCR raggiunge risultati state-of-the-art sul testo stampato (CER sotto l'1% su scansioni pulite) senza pre-elaborazione CNN, modello linguistico esplicito o segmentazione a livello di carattere.

Donut (NAVER, 2022) ha esteso l'approccio alla comprensione dei documenti: l'input è un'immagine completa del documento, e l'output è JSON strutturato estratto direttamente dalle feature visive, saltando completamente la pipeline OCR → NLP. Questo sfuma il confine tra OCR e parsing dei documenti in un modo che conta per le applicazioni reali: estrarre il totale di una fattura, un numero di passaporto o una tabella da un articolo di ricerca diventa una singola chiamata al modello invece di OCR + regex + euristiche.

Confronto delle prestazioni (inglese stampato, 300 DPI pulito)

Il divario tra Tesseract e i migliori modelli Transformer è reale sui benchmark. Nella pratica, il divario si restringe perché la maggior parte dei sistemi in produzione fornisce a Tesseract input pulito, ben illuminato, a 300 DPI, e su quell'input, un CER dell'1,8% significa un carattere sbagliato ogni 55. Accettabile per l'indicizzazione di ricerca, meno per la trascrizione di un documento legale.

OCR non inglese: perché è più difficile

L'OCR inglese è un problema risolto. Un set di caratteri di 26 maiuscole, 26 minuscole, 10 cifre e una manciata di punteggiatura dà circa 70 classi. Un problema di classificazione multi-classe ampiamente alla portata di una LeNet degli anni '90. Il resto dei sistemi di scrittura del mondo è meno indulgente.

CJK: esplosione del set di caratteri

Cinese, giapponese e coreano (CJK) rappresentano la sfida OCR più difficile per la sola dimensione del set di caratteri. Il cinese semplificato usa circa 3.500 caratteri comuni e oltre 6.000 nel testo generale. Il cinese tradizionale aggiunge un altro migliaio di forme varianti. Il giapponese mescola due sillabari (hiragana, katakana: 46 caratteri ciascuno) con circa 2.000 kanji comuni più caratteri alfanumerici latini nella stessa frase. L'hangul coreano è foneticamente regolare (24 lettere base che si combinano in blocchi sillabici), ma visivamente denso: un singolo blocco può contenere fino a sei componenti jamo individuali compressi in uno spazio grande circa quanto due caratteri latini affiancati.

Un sistema OCR CJK non può trattare il riconoscimento come una classificazione a 70 vie. È una classificazione a 4.000 vie per il giapponese, 6.000 vie per il cinese semplificato e oltre 10.000 vie per il cinese tradizionale, come minimo. Il solo strato di output softmax ha più parametri di un intero modello OCR a scrittura latina. I dati di addestramento devono scalare con il set di caratteri: circa 100 campioni etichettati per classe per un'accuratezza accettabile, quindi i set di addestramento cinesi partono da 600.000 immagini di linee di testo.

Tesseract fornisce file traineddata CJK (chi_sim, chi_tra, jpn, kor), ma sono significativamente più grandi dei modelli latini. chi_sim.traineddata è circa 50 MB contro circa 15 MB per eng.traineddata, e il riconoscimento è più lento perché lo spazio di output è più grande. L'accuratezza sul testo CJK stampato pulito si attesta al 2–5% di CER per Tesseract 5, circa 2–3 volte il tasso di errore dell'inglese in condizioni equivalenti.

Arabo e scritture destra-sinistra

L'arabo aggiunge due problemi oltre al set di caratteri (28 lettere con forme contestuali che cambiano in base alla posizione nella parola). Primo, si scrive da destra a sinistra, quindi il motore OCR deve rilevare la direzione del testo e invertire l'ordine di output. Secondo, l'arabo è corsivo. Le lettere all'interno di una parola si collegano tramite un tratto di base, rendendo la segmentazione intrinsecamente più difficile rispetto alle forme di lettere per lo più disconnesse delle scritture latine e cirilliche. L'immagine di una parola araba è un unico ammasso contiguo; la segmentazione basata sui caratteri è effettivamente impossibile, motivo per cui l'approccio LSTM/CTC (che opera su immagini di parole senza segmentazione dei caratteri) è stato una svolta più grande per l'OCR arabo che per l'OCR inglese.

Ebraico, urdu, farsi e pashto condividono una qualche combinazione di queste sfide. Tesseract fornisce traineddata per l'arabo, ma l'accuratezza è di circa il 5–8% di CER sul testo stampato pulito, circa 4 volte peggiore dell'inglese nelle stesse condizioni.

Scritture indiche: il problema dei congiunti

La devanagari (hindi, marathi, nepalese) e altre scritture brahmiche rappresentano una sfida distinta: l'unità di scrittura non è il carattere ma il congiunto, un cluster visivamente fuso di una consonante, un modificatore vocalico e talvolta una consonante aggiuntiva. Il blocco Unicode Devanagari ha 128 code point, ma il numero di congiunti possibili supera i 1.000. La "shirorekha" (la linea orizzontale superiore che collega i caratteri in una parola) rende la segmentazione più difficile perché la linea unisce caratteri adiacenti in un'unica unità visiva.

Il traineddata hindi di Tesseract (hin) copre i congiunti comuni ma l'accuratezza è inferiore a quella dell'inglese di 3–4 volte sul testo stampato. Tamil, telugu, bengalese e altre scritture indiane sono meno supportate, e ad alcune mancano del tutto file traineddata ufficiali. La causa principale è il volume dei dati di addestramento: immagini di linee di testo annotate di alta qualità per l'hindi esistono in milioni, mentre per il kannada i dataset disponibili si contano in decine di migliaia.

Testo verticale e layout a direzione mista

Il giapponese e il cinese tradizionale sono talvolta composti verticalmente, con linee che corrono dall'alto in basso e colonne da destra a sinistra. L'analisi del layout di Tesseract presuppone testo orizzontale; il testo verticale richiede pre-rotazione o un motore separato. Il testo misto orizzontale e verticale sulla stessa pagina, comune nei giornali giapponesi e nei manga, rompe completamente il presupposto di direzione singola e richiede il rilevamento della direzione a livello di regione prima del riconoscimento.

Lingue minori e dati di addestramento

Per le lingue con meno di 10 milioni di parlanti, dati di addestramento OCR di alta qualità raramente esistono. Il consorzio Unicode ha codificato oltre 150 scritture, ma Tesseract distribuisce traineddata per circa 120 lingue, molte delle quali generate da testo sintetico renderizzato con font standard su sfondi puliti. I dati sintetici funzionano per il testo stampato in font comuni e falliscono per i font, la carta e la qualità di stampa dei documenti reali di quelle lingue. Un modello addestrato su Arial sintetico a 300 DPI non leggerà un documento amarico dattiloscritto degli anni '70.

OCR lato browser con Tesseract.js

Eseguire l'OCR nel browser era impraticabile prima dell'arrivo di WebAssembly. Tesseract.js compila Tesseract 5 (LSTM) in WebAssembly tramite Emscripten, avvolgendo il motore C++ in un'API JavaScript che esegue un Web Worker per ogni compito di riconoscimento. Il motore, i dati linguistici e il worker vengono caricati da asset statici. Nessun round-trip al server per i dati dell'immagine.

La superficie dell'API è semplice: crea un worker con uno o più codici lingua, passagli un'immagine, ottieni il testo riconosciuto con punteggi di confidenza per carattere. Più worker possono essere eseguiti in parallelo, limitati dai core CPU disponibili. Tipicamente quattro job di riconoscimento paralleli su un laptop consumer, da sei a otto su telefoni recenti.

Le prestazioni sono limitate da tre fattori. Primo, WebAssembly gira a circa il 50–70% della velocità nativa; una linea di testo che richiede 100 ms in Tesseract nativo ne richiede circa 160 ms nel browser. Secondo, i file traineddata vengono caricati via rete. eng.traineddata è circa 15 MB, chi_sim.traineddata è circa 50 MB, ed entrambi devono essere completamente scaricati prima che il riconoscimento inizi. Terzo, la decodifica delle immagini (JPEG/PNG/WebP/HEIC in dati pixel grezzi) usa i decoder integrati del browser, che sono veloci ma variano per formato e dispositivo.

Il vantaggio della privacy è strutturale. L'OCR lato client significa che l'immagine non lascia mai il dispositivo. Una foto del passaporto, un estratto conto bancario, un referto medico. I pixel vengono decodificati nel browser, l'equivalente di Textract gira in un Web Worker, e il risultato è una stringa di testo che l'utente può copiare o salvare. Nessun data center elabora l'immagine. Non è una funzionalità; è l'assenza di un server, che è categoricamente diverso da una privacy policy che promette di non guardare.

Il nostro strumento Image to Text esegue esattamente questo stack: Tesseract.js con riconoscimento LSTM, Web Worker per l'elaborazione parallela, e traineddata per 12 lingue (inglese, spagnolo, francese, tedesco, portoghese, italiano, cinese semplificato e tradizionale, giapponese, coreano, hindi e russo). Carica una foto, seleziona le lingue, ottieni il testo. Lo strumento legge input JPEG, PNG, WebP, BMP e GIF, applica un pre-scalatura consapevole della risoluzione (le immagini sopra i 3.000 pixel sul lato più lungo vengono ridimensionate per mantenere ragionevole la latenza di riconoscimento) e produce testo semplice per immagine con la confidenza per carattere disponibile.

La scelta del formato immagine influisce sulla qualità dell'OCR nella pratica. Le foto HEIC dagli iPhone, convertite in JPEG prima dell'OCR, acquisiscono artefatti di compressione intorno ai bordi del testo che riducono l'accuratezza del riconoscimento. Convertire HEIC in PNG prima (senza perdita, senza artefatti di quantizzazione) preserva i bordi netti su cui si basa la LSTM. I nostri convertitori HEIC to JPG e HEIC to PNG gestiscono questa fase di pre-elaborazione direttamente nel browser. Allo stesso modo, le foto scattate in condizioni di scarsa illuminazione beneficiano della conversione in un formato che preserva l'intera gamma tonale prima della sogliatura: JPG to PNG evita gli artefatti JPEG di seconda generazione che si accumulano quando una sorgente JPEG viene ricodificata.

Lo stack OCR nel browser non è competitivo con i modelli lato server accelerati da GPU in termini di throughput. Un server che esegue Tesseract su 32 core CPU con C++ nativo sarà sempre più veloce di una scheda del browser. Vince su privacy, zero infrastruttura e zero costo per richiesta. Per scansionare qualche pagina, uno scontrino o una manciata di cartelli, la differenza di latenza tra 200 ms e 50 ms è invisibile.

Dove sta andando l'OCR

L'OCR ha smesso di essere un campo di ricerca autonomo intorno al 2022 e si è fuso nello spazio più ampio del document AI e dei modelli multimodali. Tre cambiamenti sono in corso.

LLM multimodali come OCR zero-shot. GPT-4V, Claude e Gemini possono leggere il testo dalle immagini senza addestramento OCR esplicito. Fornisci la foto di un documento e chiedi il testo, e il modello lo restituisce. Non perché abbia una testa OCR dedicata, ma perché il riconoscimento del testo emerge dall'addestramento su miliardi di coppie immagine-testo. La qualità non è uniforme. Su inglese stampato pulito, GPT-4V raggiunge circa l'1% di CER, paragonabile a un TrOCR fine-tuned. Su foto a bassa risoluzione di scontrini cinesi, può superare Tesseract perché il modello sfrutta il contesto (sa che aspetto ha uno scontrino e quali numeri aspettarsi) invece di basarsi solo sull'evidenza a livello di pixel. Sulla scrittura a mano, è peggiore di un riconoscitore specializzato perché la distribuzione di addestramento non includeva abbastanza immagini di scrittura a mano.

Il compromesso è costo e latenza. Una chiamata API a GPT-4V per OCR costa 1–3 centesimi a pagina a seconda del conteggio dei token e richiede 1–3 secondi. Tesseract gira localmente in 100–500 ms e non costa nulla a pagina. Per scansionare un documento di 200 pagine, la differenza è di $2–6 e diversi minuti di tempo reale contro zero e meno di un minuto. Per un uso occasionale (un singolo scontrino, una foto di lavagna), il modello multimodale è più semplice e spesso più accurato.

Inferenza on-device. I modelli dietro l'OCR lato server si stanno riducendo. ONNX Runtime Web esegue modelli CRNN quantizzati e piccoli ViT nel browser a 50–100 ms per linea di testo su WebGPU. Il framework Vision di Apple include un modello OCR compatto on-device per iOS e macOS, accessibile tramite VNRecognizeTextRequest senza chiamate di rete. Il divario tra "modello GPU server" e "modello browser" si sta chiudendo perché entrambi stanno convergendo sullo stesso punto ottimale architetturale: un piccolo encoder ViT (~20–50M parametri) con un decoder leggero, quantizzato a INT8 o FP16.

Comprensione dei documenti, non solo trascrizione. L'output dell'OCR è una stringa. La maggior parte dei compiti reali implica estrarre informazioni strutturate da quella stringa: numeri di fattura, date, totali, nomi, indirizzi. L'approccio tradizionale concatena OCR con regex, named entity recognition e mappatura di schema. Ogni fase è un modello separato con le proprie modalità di guasto. I modelli di comprensione dei documenti end-to-end (Donut, LayoutLMv3, Pix2Struct) saltano l'OCR e mappano le immagini dei documenti direttamente a output strutturati. Un modello Donut fine-tuned sugli scontrini non produce una trascrizione testuale per poi analizzarla. Produce {"total": "42.50", "date": "2026-07-27", "vendor": "..."} direttamente dall'input di pixel. La fase OCR, la parte di cui parla questo articolo, diventa un dettaglio implementativo invisibile.

Questo non rende l'OCR obsoleto. Lo rende un mattone. La pipeline deve ancora gestire i casi limite: lo scontrino fotografato di traverso in un ristorante buio, il documento dattiloscritto di 50 anni su carta ingiallita, il cartello in una lingua per cui nessun grande modello multimodale è stato addestrato. Motori OCR specializzati addestrati su quelle distribuzioni specifiche supereranno in velocità e prestazioni un modello generico per anni, perché un modello generico addestrato sull'intera internet alloca una frazione evanescente della sua capacità alla lettura dell'output di una macchina da scrivere amarica degli anni '70.

L'OCR non è un problema risolto per la maggior parte delle lingue del mondo e delle condizioni reali di acquisizione delle immagini. È un problema risolto per testo stampato a macchina, pulito, 300 DPI, inglese, a colonna singola — la fetta più ristretta e meglio finanziata dello spazio del problema. Il resto è ancora aperto.