{"id":2174,"date":"2026-05-27T12:52:54","date_gmt":"2026-05-27T10:52:54","guid":{"rendered":"https:\/\/userbot.ai\/blog\/?p=2174"},"modified":"2026-05-27T12:52:55","modified_gmt":"2026-05-27T10:52:55","slug":"le-immagini-nei-documenti-ocr-embeddings-e-limiti","status":"publish","type":"post","link":"https:\/\/userbot.ai\/blog\/le-immagini-nei-documenti-ocr-embeddings-e-limiti\/","title":{"rendered":"Come leggiamo le immagini nei documenti: OCR, embeddings e limiti reali"},"content":{"rendered":"\n
\n\n\n\n

Leggere un PDF<\/strong><\/h2>\n\n\n\n

Quando si parla di document processing in un contesto AI, la maggior parte delle persone pensa a una semplice estrazione di testo. La realt\u00e0 \u00e8 molto diversa: i documenti contengono tabelle sotto forma di immagini, grafici, diagrammi, loghi decorativi e layout complessi che un parser testuale non pu\u00f2 nemmeno vedere.<\/p>\n\n\n\n

In questo articolo raccontiamo come abbiamo costruito una pipeline di document processing che combina OCR, modelli vision e post-processing intelligente, e soprattutto dove abbiamo incontrato i limiti reali di queste tecnologie.<\/p>\n\n\n\n

L’architettura: estrazione e strutturazione del documento<\/strong><\/h2>\n\n\n\n

Il cuore della nostra pipeline \u00e8 un sistema di componenti OCR e di layout analysis che trasforma i PDF in una rappresentazione pi\u00f9 strutturata, separando testo, immagini e tabelle. Questo processo richiede risorse computazionali dedicate, ma \u00e8 il presupposto necessario per integrare effettivamente immagini e tabelle nelle risposte dei nostri Agenti AI.<\/p>\n\n\n\n

\"esempio<\/figure>\n\n\n\n

Vediamo insieme come le cose si fanno interessanti.<\/p>\n\n\n\n

Il problema delle immagini: non tutto ci\u00f2 che \u00e8 immagine \u00e8 utile<\/strong><\/h2>\n\n\n\n

Durante l’estrazione, vengono individuate tutte<\/em> le immagini dal PDF. Ma in un documento tipico, la maggior parte delle “immagini” sono:<\/p>\n\n\n\n

    \n
  • indicatori di layout (linee, separatori)<\/li>\n\n\n\n
  • icone decorative<\/li>\n\n\n\n
  • loghi ripetuti in header\/footer<\/li>\n\n\n\n
  • artefatti grafici senza valore informativo<\/li>\n<\/ul>\n\n\n\n
    \"\"<\/figure>\n\n\n\n

    Tenere tutte queste immagini ha un costo: occupano spazio, confondono i modelli di embedding downstream, e rallentano il processing. Passare ogni immagine al modello di embedding cos\u00ec com’\u00e8, quindi, non \u00e8 una strategia sostenibile: \u00e8 costoso, lento e introduce rumore nel knowledge base. Avevamo bisogno di un sistema che capisse per ogni immagine, se vale la pena tenerla, e se s\u00ec, come trattarla.<\/p>\n\n\n\n

    La soluzione: filtro <\/strong>visuale intelligente<\/h3>\n\n\n\n

    Abbiamo costruito un sistema di post-processing che usa modelli multimodali per classificare ogni immagine estratta. Il modello riceve l’immagine e il testo circostante, e deve rispondere a tre domande precise:<\/p>\n\n\n\n

    1. \u00c8 un artefatto di layout?<\/strong> Questa domanda serve a scartare subito tutto ci\u00f2 che non porta informazione reale: linee divisorie, frecce decorative, loghi ripetuti in ogni pagina, icone di navigazione. Un’immagine classificata come artefatto viene eliminata prima ancora di generare una descrizione.<\/p>\n\n\n\n

    2. \u00c8 una tabella?<\/strong> Questa classificazione innesca un percorso di trattamento completamente diverso. Le tabelle non possono essere gestite come immagini generiche: il loro valore sta nella struttura, nelle relazioni tra righe e colonne, nei dati che contengono. Se il modello riconosce una tabella, quella immagine non viene descritta a parole, bens\u00ec il suo contenuto viene ricostruito in modo strutturato.<\/p>\n\n\n\n

    3. Qual \u00e8 la descrizione?<\/strong> Per tutte le immagini che non sono artefatti n\u00e9 tabelle – grafici, diagrammi, screenshot, infografiche – il modello genera un breve riassunto del contenuto visivo. Questa descrizione diventa il punto di accesso all’immagine per i sistemi di retrieval. La qualit\u00e0 di questa risposta determina direttamente la qualit\u00e0 del retrieval downstream.<\/p>\n\n\n\n

    Il contesto \u00e8 tutto<\/strong><\/h3>\n\n\n\n

    Un’immagine senza contesto \u00e8 ambigua. Un grafico a torta potrebbe essere irrilevante o fondamentale, dipende da cosa dice il testo intorno. Per questo, per ogni immagine il modello vision riceve anche il testo che la circonda nel documento, usato come contesto per produrre una descrizione pi\u00f9 accurata e coerente con il contenuto complessivo.

    Questo approccio ha un side-effect positivo: la descrizione generata usa la stessa lingua del documento, perch\u00e9 il contesto “ancora” il modello al linguaggio corretto.<\/p>\n\n\n\n

    Tuttavia non c’\u00e8 nessuna garanzia che la posizione dell’immagine sia effettivamente vicino al testo a cui fa riferimento e questo avr\u00e0 effetti negativi downstream.<\/p>\n\n\n\n

    Tabelle: il caso pi\u00f9 insidioso<\/strong><\/h2>\n\n\n\n

    Le tabelle sono il nemico numero uno dell’OCR tradizionale. I sistemi di layout detection le riconoscono come immagini, ma il testo al loro interno viene perso. La nostra soluzione \u00e8 un secondo passaggio in cui un modello vision ricostruisce la struttura della tabella in formato testuale strutturato, che viene poi reinserito nel documento elaborato.<\/p>\n\n\n\n

    Questo \u00e8 un game-changer per la qualit\u00e0 del testo finale<\/strong>: le tabelle diventano ricercabili, embeddable<\/em> e comprensibili da un LLM.<\/p>\n\n\n\n

    Tuttavia tabelle molto complesse (merge di celle, tabelle nested, layout non standard, o una tabella composta da immagini) rimangono problematiche. Il modello a volte inventa dati o perde l’allineamento delle colonne. Non c’\u00e8 una soluzione perfetta, solo mitigazione.<\/p>\n\n\n\n

    Embeddings: come si “vettorializza” un’immagine<\/strong><\/h2>\n\n\n\n

    Le immagini ritenute valide vengono salvate con la loro descrizione testuale.<\/p>\n\n\n\n

    Perch\u00e9 \u00e8 importante? I modelli di embedding testuale che usiamo per il RAG non possono “vedere” le immagini, ma possono leggere le descrizioni associate. La descrizione generata dal modello vision, insieme alla sua posizione all’interno del testo, diventano il ponte tra mondo visuale e mondo vettoriale<\/strong>.<\/p>\n\n\n\n

    La qualit\u00e0 dell’embedding, quindi, dipende interamente dalla qualit\u00e0 della descrizione. Una descrizione generica (“un grafico”) \u00e8 quasi inutile. Una descrizione ricca (“grafico a barre che confronta revenue Q1 vs Q2, mostrando un incremento del 23%”) \u00e8 oro per il retrieval.<\/p>\n\n\n\n

    I limiti reali che abbiamo incontrato<\/strong><\/h2>\n\n\n\n

    1. Tempi di processing<\/strong><\/h4>\n\n\n\n

    Il processing di documenti complessi richiede tempo: l’estrazione, la classificazione visuale e la ricostruzione delle tabelle sono fasi sequenziali, ognuna con il proprio peso. Per documenti lunghi o ricchi di immagini, il tempo totale pu\u00f2 essere significativo.<\/p>\n\n\n\n

    2. Errori del modello vision<\/strong><\/h4>\n\n\n\n

    I modelli multimodali non sono infallibili: a volte classificano come “invalide” immagini che contengono informazioni utili, altre creano descrizioni che possono essere troppo generiche o contenere allucinazioni, altre ancora le tabelle ricostruite possono avere errori di allineamento.<\/p>\n\n\n\n

    Insomma, come tutte le volte che si usa un modello AI, i risultati non possono per loro natura essere deterministici ed avere il 100% di precisione e accuratezza.<\/p>\n\n\n\n

    3. La catena di errori<\/strong><\/h4>\n\n\n\n

    Ogni step della pipeline pu\u00f2 introdurre errori che si propagano: se l’estrazione del layout non \u00e8 precisa, le immagini risultano tagliate male; se il filtro visuale scarta un’immagine importante, l’informazione viene persa; se la descrizione \u00e8 inaccurata, gli embedding sono di bassa qualit\u00e0 e il retrieval peggiora. La qualit\u00e0 finale \u00e8 il prodotto di tutte le probabilit\u00e0 di successo di ogni step.<\/p>\n\n\n\n

    4. Scalabilit\u00e0<\/strong><\/h4>\n\n\n\n

    Il processing di documenti complessi richiede un equilibrio tra qualit\u00e0, performance e sostenibilit\u00e0 operativa. Non \u00e8 un servizio che si pu\u00f2 semplicemente “tenere sempre acceso”: le risorse computazionali devono essere allocate in modo intelligente, bilanciando velocit\u00e0 di risposta ed efficienza complessiva.
    <\/p>\n\n\n\n

    Cosa abbiamo imparato<\/strong><\/h2>\n\n\n\n

    L’OCR da solo non basta<\/strong>: servono modelli vision per capire cosa<\/em> c’\u00e8 nelle immagini e se vale la pena tenerle.<\/p>\n\n\n\n

    Il contesto salva la qualit\u00e0<\/strong>: passare il testo circostante al modello vision migliora drasticamente le descrizioni. Ma attenzione: un documento non progettato per essere indicizzato semanticamente produrr\u00e0 comunque risultati limitati.<\/p>\n\n\n\n

    Le tabelle richiedono un trattamento speciale<\/strong>: non puoi trattarle come immagini normali n\u00e9 come testo OCR. Serve un passaggio dedicato.<\/p>\n\n\n\n

    Conclusione<\/strong><\/h2>\n\n\n\n

    Leggere immagini nei documenti nel 2026 \u00e8 ancora un problema aperto. Non esiste una soluzione end-to-end che funzioni sempre. Abbiamo sviluppato un approccio che combina estrazione documentale, analisi visuale e post-processing intelligente, con l’obiettivo di rendere i contenuti pi\u00f9 accessibili ai sistemi AI; consapevoli che ogni componente ha i propri limiti.<\/p>\n\n\n\n

    Il consiglio pi\u00f9 onesto che posso dare: non bisogna cercare di adattare i docuemnti esistenti al retrieval, ma bisogna produrre documenti pensati din dall’inizio per la ricerca semantica. <\/strong>La nostra soluzione \u00e8 un buon punto di partenza, per permettere di utilizzare documenti pre-esistenti, ma non pu\u00f2 essere il punto di arrivo.<\/p>\n\n\n\n

    \n\n\n\n