NotebookLM, dividere i pdf pesanti per velocizzare

Uso NotebookLM per un lavoro di analisi su report statistici pubblici, in genere file PDF pesanti e ricchi di immagini. Pur restando ampiamente dentro i limiti dichiarati dallo strumento, mi sono ritrovato comunque con tempi di risposta lunghi. Qui racconto come ho individuato la causa più probabile, il peso delle immagini più che il numero di pagine, e la soluzione adottata, dividere ogni report in un file per capitolo. Nella seconda parte racconto anche come con Claude ho costruito lo script che lo fa, e i suoi limiti.

Sto portando avanti un lavoro di analisi di dati statistici che si appoggia su report pubblicamente scaricabili di enti governativi e organizzazioni non profit, i rapporti annuali che ministeri, istituti statistici e ONG pubblicano ogni anno, di solito composti da testo e grafici, tabelle e infografiche anche a piena pagina. Per interrogarli uso NotebookLM, lo strumento di Google che risponde solo sui documenti caricati dall’utente.

Il problema, caricando i report nella versione originale, alcuni oltre 70 megabyte, NotebookLM iniziava a rispondere con tempi percepibilmente più lenti di quando lavoro su documenti più leggeri. La cosa era strana visto che questi file erano ampiamente dentro i limiti dichiarati dallo strumento, quindi non stavo violando nessun vincolo tecnico noto. Il rallentamento non dipendeva da un limite superato, dipendeva da qualcosa che i limiti dichiarati non catturano.

L’ipotesi più probabile

Il problema non sembra dipendere dal numero di pagine, ma da quante elementi grafici contengono quelle pagine.

Un report da 470 pagine e 73,6 megabyte non pesa così tanto per il testo, pesa per le immagini distribuite tra grafici e infografiche. In uno dei report analizzati un singolo capitolo di appena 16 pagine pesa da solo 30,1 megabyte, quasi la metà del peso dell’intero volume concentrata in un ventesimo delle pagine. Questa è un’inferenza, non una certezza verificata su documentazione ufficiale di NotebookLM, ma è la spiegazione più coerente con quello che ho osservato, il file è pesante e denso di immagini più che semplicemente lungo, e questo genere di densità sembra rallentare l’elaborazione anche quando il file resta sotto ai limiti dichiarati.

La soluzione, dividere ogni report per capitolo

La soluzione che ho adottato è dividere ogni report in file più piccoli, uno per capitolo, e caricare quelli al posto del report intero. Il notebook continua a contenere lo stesso materiale, solo distribuito su più fonti invece che su una sola.

Per verificare l’effetto ho lavorato su quattro report reali, diversi per ente e per struttura, un report statistico nazionale, uno economico regionale, uno sociale e uno tematico annuale, tutti pubblicamente scaricabili dai rispettivi siti istituzionali. Questi sono i numeri prima e dopo la divisione:

Report	Peso originale	Pagine	Dopo la divisione	Peso dei file (min-max)
Statistico nazionale	9,6 MB	250	6 file	0,4-3,8 MB
Sociale	7,6 MB	74	10 file	0,1-3,4 MB
Economico regionale	73,6 MB	470	21 file	0,4-30,1 MB
Tematico annuale	10,3 MB	146	8 file	0,2-1,7 MB

Vale la pena essere precisi sui limiti di NotebookLM, perché cambiano da piano a piano e determinano quanto margine si ha per applicare questa tecnica. Al momento in cui scrivo, luglio 2026, ogni singola fonte può arrivare a 200 megabyte o 500.000 parole, il limite che arriva prima, uguale su tutti i piani. Cambia invece il numero di fonti ammesse per notebook, secondo i piani attualmente in vendita:

• piano gratuito, 50 fonti per notebook;
• Google AI Plus, 100 fonti;
• Google AI Pro, 300 fonti;
• Google AI Ultra, 500 o 600 fonti a seconda della soglia di archiviazione.

Dividere un report in 21 file consuma quasi metà del budget di chi ha il piano gratuito, un dettaglio da tenere presente se si gestiscono più report pesanti nello stesso notebook con un abbonamento di base.

Dopo aver caricato i file divisi al posto degli originali, le risposte di NotebookLM mi sono sembrate nettamente più rapide. Lo dico con una cautela precisa, è un’osservazione qualitativa, non una misura. Per avere un dato davvero comparabile servirebbe caricare le stesse fonti in due notebook paralleli, uno con i file originali e uno con quelli divisi, porre le stesse domande a entrambi e cronometrare le risposte, un test che richiede un tempo che al momento non ho investito. Quello che posso dire con certezza è che, da quando lavoro con i file divisi, l’attesa che prima notavo non si ripresenta più.

Il metodo però non è universale. Funziona quando il documento ha un indice leggibile da cui ricavare i numeri di pagina dei capitoli, la caratteristica che tutti e quattro i report analizzati condividono. Su un pdf scansionato senza OCR, o senza una struttura a capitoli riconoscibile, andrebbe adattato, e potrebbe anche non funzionare affatto.

Occorre fare anche una precisazione, prima di generalizzare troppo la conclusione. Dividere un report cambia più cose insieme, non solo il peso del singolo file, si passa da una fonte sola a molte fonti, e probabilmente cambiano anche i confini con cui NotebookLM segmenta il testo internamente, dato che un capitolo è un’unità tematica più coerente di un intero rapporto. La velocità percepita potrebbe dipendere da uno qualsiasi di questi fattori, non necessariamente dal peso del file preso da solo.

Come abbiamo costruito lo script, io e Claude

Quello che segue racconta il percorso con cui è nato lo strumento che divide i report, un lavoro fatto insieme a Claude. È un caso concreto di quello che nel gergo si chiama vibe coding, descrivere il problema in linguaggio naturale e lasciare che sia l’AI a proporre l’approccio e a scrivere il codice, verificando insieme passo dopo passo che il risultato fosse corretto, con la persona che guida le decisioni e controlla i risultati sui documenti reali.

L’idea di dividere i report per capitolo, invece di continuare a cercare una trasformazione che elaborasse il pdf intero, è arrivata da Claude, come alternativa quando la strada iniziale non stava dando risultati soddisfacenti. Inizialmente ho chiesto strumenti già pronti, per esempio PDFsam Basic, open source e capace anche di dividere un pdf sui segnalibri interni. Nei report su cui dovevo lavorare, però, i segnalibri erano assenti o troppo scarni per farci affidamento. È stato lo stesso Claude a propormi di scrivere uno script su misura, per avere un controllo preciso sul punto esatto in cui cade ogni confine di capitolo.
La proposta è stata:

“Per lo split in pdf più piccoli, non serve necessariamente cercare un software esterno. Se questi report ufficiali hanno segnalibri o un indice incorporato nel pdf, cosa comune nei documenti governativi, posso scrivere qui uno script Python che li separa automaticamente per capitolo, sfruttando quella struttura, gratuito e locale perché gira direttamente in questa sessione o sul tuo pc.”

Il primo tentativo, scritto da Claude, è stato il riconoscimento automatico, cioè leggere il testo estratto da ogni pagina e cercare un pattern testuale che segnalasse l’inizio di un capitolo. Sul primo report ha funzionato bene, l’estrazione del testo fondeva l’intestazione ricorrente della pagina con l’etichetta del capitolo in un artefatto di impaginazione specifico, per esempio «risultati capitolo 3», e cercare quella stringa esatta bastava a trovare tutti i confini.

Sul secondo report lo stesso approccio si è rivelato più fragile. Il layout era diverso, e il primo intervallo di pagine che Claude mi ha chiesto di controllare per trovare l’apertura di un capitolo si è rivelato sbagliato, abbiamo dovuto allargare la ricerca e ispezionare un intervallo più ampio prima di trovare l’apertura reale. Ha comunque funzionato, ma con un giro di verifica in più che il primo report non aveva richiesto. È stato il segnale che il riconoscimento automatico via pattern non era un metodo affidabile in generale, funzionava finché il layout del documento cooperava.

Il cambio di metodo, proposto da Claude, è arrivato con il terzo report, invece di cercare un pattern nel testo, leggere l’indice che il documento stesso mette a disposizione, di solito nelle prime pagine, e ricavare da lì i numeri di pagina esatti di ogni capitolo. Il punto delicato è che il numero di pagina stampato sul foglio può non coincidere con la posizione fisica della pagina all’interno del file, per via di copertine, pagine bianche o indici che precedono l’inizio della numerazione a stampa. Ho verificato questo scarto per ciascun report con almeno due controlli distanti tra loro nel documento, uno vicino all’inizio e uno molto più avanti, prima di fidarmi della mappa completa. Sul quarto report lo scarto si è rivelato ancora più insidioso, il documento aveva una numerazione autonoma solo per le prime pagine di sintesi, seguita da un riavvio del conteggio a pagina 1 per il corpo del testo, una struttura che senza i controlli incrociati avrebbe fatto sbagliare ogni capitolo dopo il primo.

Il metodo dell’indice, con la verifica dello scarto, si è rivelato il più affidabile dei due, ma resta legato a una condizione, il documento deve avere un indice leggibile da cui estrarre il testo. È il limite di cui parlavo sopra, se un report non ha questa caratteristica il metodo va adattato caso per caso.

Un effetto collaterale, la somma dei pesi dei file dopo la divisione è quasi sempre più alta del file originale, in un caso anche del 50%. È probabilmente legato alla duplicazione di risorse condivise, come font o profili colore, in ogni singolo file, nel mio caso è successo tre volte sui quattro report trattati. Non cambia la sostanza, ogni singolo file resta molto più leggero dell’originale, ed è quello che conta per NotebookLM, ma è onesto segnalare che la divisione non è un vantaggio a costo zero sullo spazio occupato.

Lo script è in Python e usa la libreria pypdf per leggere e ricomporre i file, in due modalità, riconoscimento automatico oppure mappa manuale ricavata dall’indice.

File zip da scaricare e scompattare

Il risultato pratico è che il notebook con i quattro report divisi risponde più rapidamente di prima, anche se scende il numero di report caricabili per singolo notebook.