Scribd: 400 milioni di documenti classificati con Gemini

Quattrocento milioni di documenti, una pipeline unica

Il 25 settembre 2026 Google Cloud ha pubblicato i numeri di un suo cliente: Scribd, Inc. ha classificato oltre 400 milioni di documenti caricati dagli utenti^[1], per più di 12 miliardi di pagine fra testo e immagini. Il perimetro copre due prodotti del gruppo, Scribd e Slideshare.

La società ne gestisce quattro in tutto: Scribd, Slideshare, Everand e Fable.

Il tema è la moderazione: regole di comunità da applicare a un archivio che cresce ogni giorno. Capire un documento vuol dire leggere insieme il testo e le immagini, dentro il loro contesto. Ogni lingua, ogni formato e ogni uso possibile entrano nel conto.

Il backfill sull'intero corpus si è chiuso in pochi mesi. Google Cloud ha alzato il throughput del batch per tenere quella scadenza.

La parte che vale sta prima dei numeri. Sono due scelte, una di architettura e una di prezzo, che hanno reso il lavoro pagabile.

L'idea originale: dare al modello il PDF così com'è

La prima decisione riguarda una cosa che il team ha evitato di costruire. Gemini legge il PDF in modo nativo, e oltre il 99% del corpus è passato così com'era: zero OCR, zero rendering, zero pipeline di screenshot.

Chi ha lavorato su un progetto di document AI sa quanto pesa quella frase. La pipeline di pre-processing si mangia mesi di sviluppo, produce errori silenziosi sui formati sporchi e invecchia male. Ogni cambio di prompt chiede un secondo giro su tutto.

Su 12 miliardi di pagine il rendering diventa una voce di bilancio autonoma. Ogni pagina convertita in immagine va archiviata, versionata e ripassata.

Scribd ha spostato quel lavoro dentro il modello.

Il valore della scelta si misura in codice assente: una componente che il team evita di scrivere e di mantenere per anni. Il 99% dice anche un'altra cosa, cioè che un archivio costruito dagli utenti in vent'anni resta leggibile in ingresso diretto.

L'economia del batch: metà prezzo, latenza accettata

La seconda decisione è contabile. La batch prediction di Gemini Enterprise costa metà del prezzo interattivo, e quello sconto del 50% ha reso praticabile la classifica con un LLM su scala di corpus.

Il prezzo per token scende, e in cambio arriva la latenza asincrona: il lavoro entra in coda e torna quando torna.

Qui sta il ragionamento che molti team sbagliano. Un backfill storico ha una scadenza misurata in mesi, e vive bene in coda. Un controllo sul caricamento in tempo reale pretende risposta immediata, e paga il prezzo pieno.

Separare i due regimi vuol dire comprare velocità dove porta valore e throughput dove conta il volume. Metà prezzo applicato a 12 miliardi di pagine cambia la natura della decisione, da investimento da approvare a riga di budget.

La coda porta un secondo vantaggio operativo. Quando la policy cambia, il corpus intero si ripassa, e le categorie nuove tornano sullo storico.

Chi vuole seguire le funzioni della piattaforma e le loro date trova le note di rilascio pubbliche: registro ufficiale di Gemini Enterprise^[2].

La frizione: gli strumenti pronti hanno retto poco

Il racconto ufficiale contiene anche il momento di attrito. Prima di arrivare a Gemini il team ha valutato vari strumenti di moderazione pronti all'uso e modelli aperti, e la qualità richiesta a quella scala è mancata a tutti.

Il limite storico era un altro ancora. Ogni area di policy chiedeva il suo rilevatore dedicato, e ogni rilevatore chiedeva anni di lavoro interno oppure una licenza da fornitore. Le due strade finivano contro lo stesso muro.

L'economia di un backfill da 400 milioni di documenti rompe il conto di una soluzione per categoria.

«Ogni categoria di contenuto si comporta in modo diverso, e storicamente ognuna chiedeva una soluzione dedicata», ha detto Sachin Sebastian, Senior Engineering Manager di Scribd, Inc. «Gemini ha fatto collassare tutto questo in un modello, un prompt, una pipeline.»

La frase vale come misura di architettura, più che come complimento al fornitore. Il guadagno sta nel numero di sistemi da tenere in vita: da molti a uno.

Risultato dichiarato e risultato verificato

Il post arriva da Google Cloud, firmato da un account manager del fornitore e da un capo ingegneria del cliente. Volume, tempi e sconto restano cifre dichiarate dalle due parti che hanno interesse al risultato.

Una verifica indipendente, al momento, manca.

Sul lato qualità il testo resta generico: parla di un mix di metodi umani e automatici per applicare le regole di comunità. Le persone restano dentro il processo, e questo è il dettaglio più credibile del comunicato. Mancano invece le cifre che un revisore chiederebbe.

Tre numeri resterebbero utili:

• precisione e richiamo per ogni categoria di policy
• tasso di falsi positivi sui documenti legittimi
• quota di documenti mandati a revisione umana

La differenza pesa sulla decisione di budget. Un ufficio che compra throughput misurabile firma su un numero che vede, un ufficio che compra accuratezza firma su una promessa. Il primo caso vale come riferimento di mercato, il secondo chiede una prova interna.

Chi legge la storia per copiarla deve tenere la distinzione in mano. Il dato di throughput è solido e tracciabile, il dato di qualità resta una dichiarazione del cliente.

Un modello, un prompt, una pipeline

Il cuore tecnico sta nella consolidazione. Un sistema con dieci rilevatori specializzati ha dieci dataset, dieci soglie, dieci cicli di rilascio e dieci modi di invecchiare.

Un sistema con un modello e un prompt ha un punto di controllo. Aggiungere una categoria diventa lavoro di testo, e il costo marginale di una policy nuova crolla.

Il rovescio esiste, e va dichiarato. Un prompt unico concentra il rischio, perché un errore di formulazione si propaga su tutto il corpus. La messa a punto fine di un rilevatore dedicato, in quello schema, resta fuori portata.

La contromisura ragionevole è la stessa dei casi documentati di questa classe: campioni di valutazione per categoria, confronto con giudizi umani, soglie diverse per aree diverse. Il modello unico regge quando la misura intorno resta per categoria.

A questa scala il saldo premia la semplicità: dieci sistemi mediocri mantenuti male perdono contro un sistema buono mantenuto bene.

Cosa possiamo portare via

La lezione trasferibile sta lontano dal nome del modello. Due domande fanno il lavoro su qualunque progetto di document AI.

La prima: quale pezzo della pipeline il modello assorbe già, e quindi conviene evitare di scrivere. La seconda: quale parte del carico tollera la coda, e quindi compra throughput a metà prezzo.

• Founder e CEO di PMI: il backfill storico è il posto giusto per il primo progetto a volume, con la latenza asincrona come leva di prezzo.
• CTO e capo di prodotto: l'input nativo cancella una componente intera dal diagramma, e con lei il suo debito tecnico.
• Board e investitori: 400 milioni di documenti in pochi mesi spostano l'asticella del possibile su un archivio grande.
• Manager di team: una categoria nuova di controllo diventa un paragrafo di prompt, con un ciclo che si misura in giorni.

Il caso suggerisce anche un ordine di marcia. Il primo progetto a volume parte dallo storico, dove la scadenza è generosa e lo sconto è strutturale.

Il pilota in tempo reale arriva dopo, con i costi già compresi.

La cultura interna conta quanto l'architettura. Il prompt lo scrive bene chi conosce le regole di comunità, e quella conoscenza pesa più di qualunque soluzione chiavi in mano.

Resta la domanda aperta, valida per ogni organizzazione con un archivio grande. Quante componenti della vostra pipeline esistono per compensare un limite dei modelli di tre anni fa? Un pomeriggio di prove sul formato grezzo dice quanta di quella impalcatura potete spegnere.