Aggiorniamo il catalogo biblioteca con l’IA

Migrare dati da un vecchio database, da un’applicazione dismessa o da un CMS a una soluzione più moderna è sempre stata una delle mie attività preferite. Niente tool automatici “scatola chiusa”: pochi script ben strutturati e tante query SQL scritte al volo sono sempre bastati a darmi grandi soddisfazioni. Fino ad oggi, però, il compito era sempre stato quello di riorganizzare, pulire e spostare dati già esistenti.

Questa volta la sfida era decisamente più ambiziosa: i dati mancavano! E quando le informazioni assenti non si possono ricostruire con una semplice formula o un algoritmo deterministico, serve un salto di livello. Per risolvere il problema abbiamo sperimentato una strada nuova, ricombinando servizi online e intelligenza artificiale in maniera inusitata.

Nelle grandi biblioteche il passaggio ai nuovi standard di catalogazione avviene solitamente mediante esperti di database se l’archivio è già presente o, molto più spesso, mediante l’impiego di volontari e personale addestrato che inseriscono e controllano i volumi uno per uno. Nelle scuole — dove la gestione è spesso affidata alla collaborazione tra docenti e studenti — la ricatalogazione manuale e gratuita di un archivio di oltre 8.000 titoli rappresenta una sfida notevole e difficile da portare a termine anche con un progetto pluriennale.

L’archivio storico della nostra biblioteca ha una lunga storia: nato negli anni ’80 su dBase ad opera di veri pionieri, è stato poi migrato su Access e infine su MySQL. L’intero sistema si reggeva su un “codice parlante” interno per individuare genere e posizione dello scaffale, ma mancavano quasi del tutto i codici ISBN, copertine e metadati OPAC. Con il passare del tempo l’archivio si è espanso, ma parallelamente si sono evoluti anche i modelli di catalogazione. Oggi la semplice triade titolo-autore-editore non basta più: gli utenti si aspettano identificazione univoca, schede ricche, dettagliate e ricche di campi aggiuntivi che una banca dati figlia del passato non era più in grado di offrire.

Come trasformare questa banca dati obsoleta in un catalogo moderno, completo e consultabile online senza dover riprendere in mano ogni singolo libro?

Ecco la cronaca e la guida passo-passo di come abbiamo risolto il problema combinando script Python, servizi web API, LLM locali (con Ollama e GPT-OSS) ed un’architettura integrata su Microsoft 365 / SharePoint.

La filosofia di fondo: L’IA come partner di ragionamento

Progetti di questo genere non si risolvono chiedendo semplicemente all’IA di “scrivere un codice” o di “sistemare un catalogo”. Servono sessioni interattive di pianificazione in cui sviluppatore ed IA analizzano la struttura dei dati, testano i casi limite su piccoli campioni di dati, affinano i criteri di matching e progettano la logica della catalogazione integrativa.

Fase 1: Recupero del catalogo

Come prima operazione, abbiamo unito tramite le opportune JOIN le tabelle separate di MySQL (libri, autori ed editori… un classico), esportando il tutto in un unico file CSV. Lavorare su un file monolitico rende molto più agili sia le elaborazioni via script che i successivi passaggi di import/export.

Per comodità abbiamo impostato il punto e virgola (;) come separatore CSV, rendendo il file facilmente leggibile anche con Excel. Un’avvertenza fondamentale: Excel tende a “rovinare” i codici ISBN interpretandoli come numeri in notazione scientifica, motivo per cui va utilizzato unicamente da mani esperte e con molta prudenza nel sistemare il formato della colonna prima di salvare le modifiche al file.

In questa fase non ci serviva l’assistente IA ma se per voi queste operazioni sono nuove e non conoscete bene i database non esitate a chiedere agli LLM generalisti disponibili sull’ecosistema Cloud dell’Istituto come Copilot e Gemini le procedure migliori e passo-passo per esportare i dati che vi servono. Per arrivare rapidamente ad un risultato la domanda giusta non è ‘fammi un export’ ma ‘dimmi cosa devo fare per …’.

Fase 2: Arricchimento via API (Python + Google Books / OpenLibrary, OPAC SBN)

Al termine di questo step ci siamo trovati con una banca dati di oltre 8.000 righe: ciascun record presentava certamente i campi base (Titolo, Autore, Editore e Codice interno), ma carente dei codici ISBN per quasi tutti i volumi (quelli storici sono senza) e spesso sprovvisto di informazioni bibliografiche approfondite.

Abbiamo quindi sviluppato uno script Python per interrogare i webservice gratuiti di Google Books, OpenLibrary.org e OPAC SBN per recuperare tutte le informazioni mancanti, comprese le copertine. Il compito sembra semplice, ma le insidie nel matching bibliografico sono numerose:

• Inversione Autore/Titolo ed Articoli: Gli autori figuravano talvolta come Cognome Nome, altre volte Nome Cognome oppure con le sole iniziali; gli articoli determinativi figuravano all’inizio, in coda tra parentesi o posposti.
• Refining con Coding Assistant: Sfruttando modelli di coding (Copilot, Gemma o Qwen gestito tramite Ollama in locale), abbiamo generato e raffinato algoritmi di matching flessibili per normalizzare le stringhe prima di interrogare le API.
• Validazione tramite Campione: Eseguita una prima bozza dello script, lo si testava su un campione di 500 libri. Si passavano i CSV “Prima” e “Dopo” all’assistente IA per identificare dove la ricerca falliva o dava falsi positivi, perfezionando ricorsivamente la logica di ricerca.

Per la stesura e la messa a punto degli script ci si può affidare ai modelli generalisti Copilot e Gemini, perfettamente adeguati allo scopo oppure a modelli locali specializzati quali Qwen 3.8 27B, qwen3-coder:30b e DeepSeek-Coder. Non serve conoscere tutta la letteratura tecnica per utilizzare le API (Application Programming Interface) il nostro assistente con intelligenza artificiale ha già letto tutto per noi e conosce i trucchi del mestiere per giungere rapidamente al risultato. Attenzione non sarà sicuramente al primo colpo, si ragiona insieme, si fa un minimo di debug e si sistema in alcuni passaggi successivi.

Gestione dei limiti di API e script giornalieri

Google Books offre dati bibliografici eccellenti e immagini di copertina ad alta risoluzione, ma chiede la registrazione di una chiave di accesso (API KEY) e applica una quota limite di circa 1.000 chiamate/giorno.

OpenLibrary non ha restrizioni ma presenta un tasso di copertura leggermente inferiore sui volumi italiani e una catalogazione in inglese.

Infine, l’OPAC SBN garantisce la massima autorevolezza sui dati della biblioteca italiana, ma risulta decisamente più complesso da interrogare via script: la sua documentazione API è meno accessibile rispetto ai servizi di livello mondiale e gli script richiedono numerosi affinamenti e debug sui parametri riuscire a leggere i dati.

Strategia d’automazione a più riprese:

1. Nel CSV di output è stato introdotto uno specifico flag di tracciamento che indica se il record è già stato elaborato e da quale sorgente.
2. sono stati predisposti script solo per OpenLibrary, Google Books e OPAC per vedere anche le differenze di prestazioni, il file in output da un primo script può essere mandato in pasto ad un secondo servizio in modo da procedere a completamenti successivi
3. Lo script rileva quando Google Books risponde con un errore di quota (HTTP 429 / Rate Limit) e commuta interrompe l’elaborazione salvando lo stato e il file parzialmente completato
4. Un secondo script supervisor (pianificato per l’esecuzione automatica ogni 24 ore) riprendeva il file CSV di output del giorno precedente impostandolo come nuovo file di input.
5. Regola d’oro di sovrascrittura: I dati storici validi già presenti nella banca dati originale non venivano mai sovrascritti ma copiati in campi di backup per eventali confronti successivi. Lo script aggiornava principalmente i campi mancanti (con priorità assoluta all’ISBN per avere finalmente un identificatore univoco).
6. Se non soddisfa si riparte: trattandosi di un lavoro che eseguono i computer in maniera autonoma non bisogna avere nessuna remora a fermare lo script, analizzare i risultati con l’AI, migliorare il codice e ripartire da capo fino all’ottenimento del risultato sperato. Prima o poi avremo il catalogo che ci soddisfa basta ripartire tutte le volte che serve

Fase 3: Revisione e Normalizzazione tramite LLM Locale (Ollama + GPT-OSS 130B)

Completati i cicli di ricerca API sul WEB gratuiti, ci siamo trovati di fronte ad un catalogo enormemente arricchito ma “spettinato”:

• Vecchie catalogazioni storiche scritte interamente in MAIUSCOLO.
• Articoli nei titoli confinati in coda/testa alle frasi o tra parentesi.
• Generi, categorie e abstract scaricati dalle API spesso scritti in lingua inglese o con tassonomie incongruenti per una biblioteca scolastica italiana.

Trattandosi di oltre 8.000 righe di testo strutturato, inviare l’intero file a servizi cloud gratuiti tipo Gemini web o ChatGPT è impossibile per via dei limiti di contesto e della perdita di accuratezza sulle singole righe. Serviva una revisione puntuale riga per riga. Per questi lavori il cloud si fa pagare! bisogna attivare abbonamenti specifici e stare attenti ai limiti di spesa.

L’architettura con Server IA Dedicato e Modello GPT-OSS 130B

Abbiamo quindi predisposto uno script Python che interroga un server locale tramite Ollama, elaborando l’archivio riga per riga. Tra i vari modelli testati per la fase di rifinitura culturale e lessicale, la scelta è ricaduta su GPT-OSS 130B, un modello open weight ad alte prestazioni. In questo contesto, l’infrastruttura locale si rivela strategica: permette di abbattere completamente i costi di elaborazione ed evita i limiti di traffico o le tariffe a consumo imposti dai servizi Cloud via API su grandi volumi di dati.

Un modello di grandi dimensioni come GPT-OSS 130B possiede la sensibilità culturale necessaria per interpretare i termini bibliografici corretti, catalogare i generi senza ambiguità e tradurre gli abstract con il giusto registro espressivo. Probabilmente bastava anche meno ma GPT 130B ci piaceva così.

Il server impiegato nella nostra infrastruttura era ben dotato sul fronte CPU e RAM, pur essendo completamente privo di GPU dedicata. Trattandosi di una classica lavorazione batch, l’assenza della scheda video non è stata un ostacolo: è bastato lasciare lavorare lo script e attendere i tempi di calcolo.

Direttive Prompting per l’Elaborazione Batch

Per evitare allucinazioni o risposte prolisse che avrebbero rotto la struttura CSV, lo script invia all’LLM locale direttive ultra-rigorose:

“Sei un bibliotecario professionista esperto in catalogazione. Il tuo unico compito è tradurre e standardizzare il GENERE LETTERARIO che leggi in italiano corretto, adatto a un catalogo scolastico/bibliotecario. Restituisci ESCLUSIVAMENTE il valore del genere tradotto/corretto. NON aggiungere introduzioni, spiegazioni, virgolette o testo prima e dopo la risposta. Rimuovi caratteri speciali, parentesi e punteggiatura non necessaria. NON utilizzare mai il carattere punto e virgola ( ; ). Se sono presenti più generi, separali con una virgola e uno spazio. Se il testo è già in italiano, correggi solo la formattazione, eventuali errori e le maiuscole. Il genere è: ….”

Anche quest’elaborazione ripetuta per più campi ha richiesto diversi giorni di esecuzione continua sul server locale. Il lavoro è stato suddiviso in passaggi progressivi: prima la sistemazione dei generi, poi degli argomenti, ed infine la traduzione e sintesi degli abstract. In qualsiasi caso si lavora riga per riga, campo per campo, altrimenti le informazioni si mischiano tra libri e contesti.

Fase 4: Importazione ed Integrazione su SharePoint Online (Microsoft 365 Academic)

Ottenuto il CSV finale pulito e verificato con Excel, il passo successivo è stato rendere il catalogo facilmente accessibile a tutta la comunità scolastica (docenti e studenti).

Sfruttando l’infrastruttura Microsoft 365 Academic totalmente gratuita e già presente nel nostro Istituto, abbiamo realizzato un sito SharePoint dedicato alla Biblioteca. Per popolare l’elenco con i 8.000 record e collegare le relative copertine scaricate dalle API, abbiamo sviluppato, sempre con l’AI degli script PowerShell dedicati.

Nel nuovo catalogo, il contenitore principale degli oltre 8.000 titoli (e 13000 volumi) è rappresentato da un Elenco SharePoint, popolato tramite un’importazione batch eseguita via PowerShell. Grazie all’uso di colonne indicizzate e viste native di Microsoft 365, la piattaforma permette una ricerca full-text istantanea e l’applicazione di filtri dinamici per Genere, Autore, Anno e Codice di posizione interna. Le copertine dei libri, recuperate nella fase di arricchimento dei metadati, sono archiviate in una Raccolta Documenti SharePoint e collegate ai record tramite URL.

L’intero sistema è fruibile attraverso un’interfaccia web moderna inserita nella Intranet d’Istituto e, volendo, integrabile in Microsoft Teams. Un punto di forza fondamentale di questa architettura è che sfrutta le funzionalità standard degli elenchi SharePoint, ma consente un’ulteriore evoluzione a “zero costi” grazie all’ecosistema Microsoft 365: sfruttando Power Apps e Power Automate (entrambi già inclusi nelle licenze M365 A1 Academic), è possibile realizzare rapidamente un’interfaccia di ricerca personalizzata e automatizzare la gestione dei prestiti e dei solleciti via email o Teams, senza richiedere licenze aggiuntive o codice complesso e facendo leva sul fatto che tutti gli utenti della scuola sono già censiti nel tenant d’istituto.

Al posto delle liste di SharePoint Online, chi utilizza l’ecosistema Google può appoggiarsi a Google Sheets per memorizzare il catalogo e a Google Drive per archiviare le immagini delle copertine scaricate. Se non si desidera ricorrere a un gestionale bibliotecario di terze parti, è possibile sviluppare un’applicazione personalizzata tramite Google AppSheet (già compreso in Workspace for Education): un’ottima soluzione per offrire a docenti e studenti un’interfaccia di ricerca responsive e un sistema di gestione dei prestiti e delle prenotazioni.

Per la realizzazione di Power Apps, Power Automate e AppSheet anche qui non si serve passare un mese a leggere la documentazione tecnica sconfinata di questi ambienti, si impara con il learning by doing sempre con al nostro fianco un Copilot, Gemini, Qwen o DeepSeek-Coder in locale che ci spiega passo passo come fare per realizzare queste semplici applicazioni. Il procedimento in questo caso è più simile al coding che allo sviluppo software tradizionale, quindi una volta capito come si fa è anche più facile.

Conclusioni – per chi vuole replicare il progetto

1. Non fare tutto a mano, non delegare tutto all’IA: L’intelligenza artificiale è stata usata come assistente per scrivere codice e sistemare tassonomie, lasciando all’essere umano la regia. L’IA scrive e ottimizza gli script, l’operatore guida l’architettura e verifica i risultati. Poteva farlo un agente IA? può darsi, vedremo…
2. Architettura ibrida (Cloud per lo scibile, Locale per macinare): Il Cloud e le API esterne servono per arricchire i dati grezzi e supportare il coding; il server locale con Ollama si occupa invece dell’elaborazione massiva, svincolandoci da limiti di traffico e costi di licenza.
3. Un archivio finalmente libero: Con un patrimonio di metadati puliti e codici ISBN validi, il database non è bloccato sulla piattaforma scelta oggi (SharePoint o Google), ma è pronto per essere importato domani in un qualsiasi software bibliotecario open source, del registro elettronico o di mercato.
4. Tranquillità normativa (GDPR & AI Act Proof): L’intero processo è intrinsecamente immune da complicazioni burocratiche o legali. Non sono stati trattati dati sensibili, dati personali o account di minori. L’IA ha lavorato solo su schede bibliografiche pubbliche gestite in locale, rispettando alla lettera il GDPR e la normativa europea sull’IA senza appesantire la scuola di nuovi adempimenti.

In conclusione, questo progetto propone l’unione tra tecnologie aperte, piattaforme già presenti a scuola e intelligenza artificiale locale per risolvere problemi di digitalizzazione all’apparenza insormontabili.

Nessun budget stratosferico, zero rischi per la privacy, qualche settimana di lavoro e nessun adempimento burocratico: solo la dimostrazione che, unendo visione tecnica, curiosità e quel pizzico di sana sperimentazione, la scuola pubblica può guidare l’innovazione anziché rincorrerla.

Diteci la vostra nei commenti