Negli ultimi tempi sto cercando di capire quale sia il modo più affidabile per tradurre documenti PDF complessi con l’intelligenza artificiale.
A prima vista il problema sembra semplice:
- estrarre il testo;
- inviarlo a un modello;
- ricevere la traduzione;
- inserirla nuovamente nel PDF.
Questo approccio funziona abbastanza bene con una pagina composta da pochi paragrafi. Inizia però a mostrare molti limiti quando il documento contiene tabelle, colonne, formule, note a piè di pagina, diagrammi o pagine scansionate.
Il problema, quindi, non è soltanto tradurre le frasi. È conservare le relazioni tra le frasi e il resto del documento.
Un PDF non è un testo lineare
In una pagina web o in un file Markdown il contenuto ha normalmente un ordine abbastanza chiaro.
Un PDF, invece, può memorizzare ogni riga o persino ogni parola come un elemento posizionato in coordinate precise.
Una pagina può contenere:
- due o tre colonne;
- un riquadro laterale;
- un’intestazione ripetuta;
- una tabella;
- una didascalia;
- una nota a piè di pagina;
- un’immagine con del testo incorporato.
Un estrattore poco attento potrebbe leggere prima una riga della colonna sinistra, poi una della colonna destra e infine l’intestazione.
Tutte le parole sono presenti, ma il ragionamento originale è stato distrutto.
Prima della traduzione, quindi, sarebbe necessario ricostruire l’ordine di lettura della pagina.
Una traduzione corretta può diventare un documento sbagliato
Immaginiamo una tabella finanziaria con quattro categorie e tre anni di dati.
Il sistema traduce correttamente ogni intestazione e conserva tutti i numeri. Durante la ricostruzione, però, una delle etichette viene spostata di una riga.
Le parole sono corrette.
I numeri sono corretti.
L’informazione finale è sbagliata.
Lo stesso problema può verificarsi quando:
- un avviso viene separato dall’operazione a cui si riferisce;
- una didascalia finisce vicino all’immagine sbagliata;
- una nota viene collegata al paragrafo successivo;
- il testo di due colonne viene mescolato;
- una percentuale rimane sotto l’intestazione errata;
- un riferimento a “Figura 3” non corrisponde più alla figura giusta.
Questo rende la traduzione dei PDF un problema di elaborazione documentale, non soltanto linguistico.
Le scansioni aggiungono un ulteriore livello di errore
Molti PDF non contengono vero testo digitale. Sono semplicemente immagini di pagine stampate.
In questi casi bisogna utilizzare l’OCR prima ancora di iniziare la traduzione.
La catena diventa:
- riconoscimento dei caratteri;
- ricostruzione dei paragrafi;
- traduzione;
- reinserimento nella pagina.
Un errore commesso nella prima fase viene propagato in tutte le altre.
L’OCR può confondere:
- la lettera
O con il numero 0;
- la lettera
I con il numero 1;
- il trattino con il segno meno;
- un punto decimale con un difetto della scansione;
- un codice prodotto con una parola normale.
La parte pericolosa è che il modello linguistico può produrre una traduzione molto fluida anche partendo da un testo riconosciuto male.
L’errore diventa quindi meno visibile.
Non tutto ciò che assomiglia a una parola deve essere tradotto
Nei documenti tecnici possono comparire elementi che devono rimanere identici:
- nomi di funzioni;
- comandi;
- percorsi di file;
- indirizzi URL;
- codici prodotto;
- numeri di brevetto;
- variabili matematiche;
- simboli chimici;
- riferimenti bibliografici;
- identificatori di standard.
Termini come FLOW, ONE, GAS o NEAR possono essere parole comuni, ma anche nomi, token o identificatori tecnici.
Un possibile metodo è sostituire temporaneamente questi elementi con placeholder:
Aprire {{FILE_PATH_1}} e impostare {{CONFIG_KEY_1}} su true.
Dopo la traduzione, i valori originali vengono reinseriti.
Il sistema dovrebbe anche controllare che nessun placeholder sia stato eliminato, duplicato o modificato.
La coerenza deve attraversare tutto il documento
Un manuale può utilizzare lo stesso termine centinaia di volte.
Se ogni pagina viene tradotta separatamente, lo stesso componente potrebbe ricevere tre o quattro nomi diversi.
Localmente, ogni traduzione può sembrare accettabile. Globalmente, il lettore potrebbe pensare che si tratti di oggetti differenti.
Per questo credo che un buon sistema debba avere almeno:
- un glossario di progetto;
- un elenco di termini da non tradurre;
- il contesto della sezione corrente;
- una memoria delle traduzioni già approvate;
- un controllo finale delle varianti terminologiche.
Non è necessario inserire tutto il documento nel prompt. Bisogna però fornire abbastanza contesto da evitare che ogni paragrafo venga trattato come un testo indipendente.
Meglio preservare il layout o convertire il contenuto?
Qui nasce una scelta interessante.
Opzione 1: conservare il PDF originale
Vantaggi:
- il documento rimane familiare;
- tabelle e immagini restano nelle loro posizioni;
- i riferimenti alle pagine continuano ad avere senso;
- è più facile confrontare il risultato con l’originale.
Svantaggi:
- il testo tradotto può essere più lungo;
- le caselle originali possono non avere spazio sufficiente;
- il carattere originale può non supportare la nuova lingua;
- tabelle e colonne possono diventare troppo strette.
Opzione 2: convertire tutto in HTML o Markdown
Vantaggi:
- il testo può adattarsi liberamente allo schermo;
- il contenuto è più accessibile;
- è più semplice cercare, copiare e modificare;
- il layout può funzionare meglio su dispositivi mobili.
Svantaggi:
- si perde parte dell’identità visiva;
- i numeri di pagina cambiano;
- alcune tabelle e diagrammi sono difficili da ricostruire;
- i riferimenti interni possono non corrispondere più.
Forse la soluzione migliore non è sceglierne una soltanto.
Si potrebbe produrre:
- una versione PDF che conserva il layout;
- una versione HTML più flessibile;
- una versione bilingue per il controllo.
La versione bilingue potrebbe essere il risultato più utile
Una traduzione monolingue è più pulita per il lettore finale.
Una versione bilingue è più utile durante la revisione.
Permette di verificare rapidamente:
- nomi;
- numeri;
- date;
- termini tecnici;
- avvisi;
- formule;
- contenuti mancanti;
- errori dell’OCR.
Per i documenti legali, medici, finanziari o relativi alla sicurezza, non considererei comunque la traduzione automatica come autorità finale.
L’IA può ridurre molto il lavoro umano, ma dovrebbe anche rendere più semplice individuare i punti incerti.
Come immagino un flusso di lavoro più robusto
Un possibile processo potrebbe essere:
- analizzare ogni pagina;
- capire se contiene testo digitale o una scansione;
- utilizzare l’OCR soltanto quando serve;
- rilevare titoli, paragrafi, tabelle, immagini e formule;
- ricostruire l’ordine di lettura;
- proteggere codici, numeri e identificatori;
- tradurre blocchi abbastanza grandi da conservare il contesto;
- applicare un glossario coerente;
- ricostruire il documento;
- generare una versione bilingue;
- eseguire controlli automatici su numeri, placeholder e overflow;
- segnalare le pagine con bassa affidabilità.
In questo modello, l’intelligenza artificiale non è soltanto il traduttore.
Può essere utilizzata anche per classificare le aree della pagina, individuare incoerenze e suggerire quali sezioni richiedono una revisione umana.
La domanda che mi interessa di più
Secondo voi, quale dovrebbe essere la priorità di uno strumento di traduzione documentale?
- conservare il più possibile il layout originale;
- produrre un testo semanticamente pulito in HTML o Markdown;
- creare una versione bilingue pensata soprattutto per la revisione;
- lasciare scegliere il formato in base al tipo di documento?
E per chi ha lavorato con OCR o document intelligence: nella pratica avete trovato più difficile il riconoscimento del testo, la coerenza della traduzione oppure la ricostruzione del layout finale?