Il numero: da 250 minuti a meno di 2
Le redazioni di Condé Nast spendevano in media 250 minuti per ogni attività di ricerca contenuti. Il numero arriva dal racconto tecnico pubblicato da AWS[1], che ha costruito la soluzione insieme al gruppo editoriale. Dopo l'intervento la stessa attività si chiude in meno di 2 minuti.
L'archivio conta oltre 140.000 video. Alimenta testate come Vogue, GQ, Vanity Fair e Wired.
Per trovare una clip, i montatori scorrevano il materiale a mano, appoggiandosi a titoli e descrizioni scritte da una persona. In un mercato dove la velocità di uscita decide quanto ricavo entra, quel ritardo pesava sul conto economico.
Quattro ore e dieci minuti per una ricerca: il tempo di una riunione lunga, speso su un gesto che dovrebbe durare pochi secondi. La leva che ha cambiato la misura riguarda il livello della ricerca, più che la potenza del modello.
L'idea originale: cercare l'intento
Un redattore cerca «contenuti di yoga per principianti con sfondi rilassanti». Oppure «momenti dietro le quinte della fashion week». Un nome di file come yoga_tutorial_march_2024.mp4 risponde a una domanda diversa.
Qui sta la frattura strutturale descritta nel racconto AWS: gli strumenti di ricerca classici leggono le etichette, mentre il contenuto del video resta opaco. La distanza fra la domanda vera e il dato indicizzato era il vero collo di bottiglia.
La scelta è stata spostare il livello di ricerca. Al posto del confronto fra parole, il sistema confronta vettori che portano significato. Un embedding multimodale codifica insieme immagine, audio e trascrizione, quindi la query «sfondi rilassanti» trova la clip giusta pure quando quella frase manca da titolo e descrizione.
Per un capo prodotto il passaggio è chiaro: i metadati scritti a mano hanno un tetto, e quel tetto arriva presto. L'intento, invece, si misura dentro il materiale.
Bedrock, OpenSearch e un encoder che guarda dentro il video
La soluzione poggia su Amazon Bedrock e Amazon OpenSearch Service. Bedrock serve il modello, OpenSearch tiene l'indice vettoriale e risponde alle query. La ricerca semantica attraversa tre piani insieme: trascrizioni, elementi visivi, audio.
Il modello scelto è TwelveLabs Marengo. La ragione dichiarata dal team è precisa: Marengo codifica in modo nativo e congiunto i segnali visivi, audio e di trascrizione.
Un modello che tratta i tre canali in sequenza avrebbe prodotto rappresentazioni separate, con un lavoro di ricucitura a carico dell'applicazione. Marengo alimenta tutte e cinque le capacità di ricerca descritte nel documento. Una sola famiglia di embedding alimenta un solo indice. E quell'indice si interroga in cinque modi.
Per chi decide un budget tecnico il dettaglio conta. La scelta del modello qui pesa quanto la scelta di dove metterlo: il valore nasce dalla combinazione fra encoder multimodale e motore di ricerca vettoriale già gestito.
Due piani separati, e il backfill che lo dimostra
Il secondo vincolo era la scala. Oltre 140.000 video significano un carico di calcolo pesante per generare gli embedding, e un carico leggero per servire una risposta.
Il team ha separato i due piani. Da un lato l'ingestione, costosa e lenta. Dall'altro la risposta alla query, che deve restare immediata.
Un'architettura monolitica avrebbe imposto uno scambio: più velocità in ingestione contro meno reattività in ricerca, oppure il contrario. Con i piani separati ognuno cresce, cade ed evolve per conto proprio. Il documento AWS aggiunge la frase che rende il caso istruttivo: questa decisione si è rivelata essenziale durante il backfill.
Il backfill è il momento in cui l'archivio storico entra nel sistema tutto insieme. Centoquarantamila video da processare mentre la redazione lavora.
Con un piano unico, la ricerca si sarebbe fermata proprio nei giorni in cui serviva di più. La frizione è documentata, e questo rende il numero credibile.
Chi pubblica il numero
Qui arriva il limite da dichiarare. Il salto da 250 minuti a meno di 2 minuti lo pubblica AWS, che ha costruito la soluzione col suo Generative AI Innovation Center. Il fornitore misura il proprio lavoro.
Questo rende il dato un risultato annunciato, in attesa di una verifica indipendente. Vale come prova di fattibilità tecnica, meno come benchmark di mercato.
Il documento, in più, descrive il metodo di misura in forma sintetica. Tre cose restano aperte:
- cosa contiene esattamente una «attività di ricerca contenuti»
- quante persone sono state cronometrate
- su quale periodo di osservazione
Il before/after esiste e porta un denominatore chiaro, il tempo per attività, e questo lo separa dal generico «miglioramento significativo» che riempie le pagine dei fornitori.
Un consiglio di amministrazione legge il caso per quello che è: la direzione del movimento è solida, l'ampiezza chiede conferma. Chi valuta un investimento simile dovrebbe chiedere il protocollo di misura prima della firma.
La conoscenza che esce dalla porta
Il documento segnala un costo che raramente entra nei business case: la dipendenza dalla conoscenza personale. Le squadre si affidavano a chi ricordava dove stava un certo materiale.
Quando quella persona era in ferie o cambiava ruolo, la ricerca si bloccava. Il racconto AWS lo chiama con il suo nome: un punto singolo di rottura.
C'è un secondo effetto, più silenzioso. Materiale valido restava invisibile nell'archivio, perché le parole del titolo lo tenevano fuori dalle query che i redattori lanciavano davvero. Video pagati, montati, pubblicati una volta, e poi spenti.
La ricerca semantica agisce su entrambi i fronti. Rende la memoria dell'archivio un bene dell'azienda, al posto di una competenza individuale. E riporta in circolo contenuti già prodotti, che costano zero da riusare.
Per un fondatore di PMI questa è la parte replicabile a basso prezzo: il valore immediato arriva dal materiale che possiedi già, più che da nuova produzione.
Cosa puoi portarti via
Tre elementi di questo caso viaggiano fuori dall'editoria.
Primo: la domanda vera dei tuoi utenti è già scritta nei log di ricerca. Leggila. Quando le query parlano di intenti e il tuo indice parla di etichette, la distanza fra i due è la tua opportunità.
Secondo: separa il calcolo pesante dalla risposta veloce prima di cominciare. Il backfill arriva sempre, e arriva all'inizio, quando la fiducia degli utenti è fragile.
Terzo: scegli l'encoder per come tratta i tuoi dati reali. Un modello che unisce immagine, audio e testo in un unico spazio ti risparmia un livello di integrazione che altrimenti scrivi e manutieni tu.
Un capo di team può partire in piccolo. Mille asset, un indice vettoriale gestito, una metrica cronometrata prima e dopo. Il before/after su un campione piccolo convince un comitato meglio di una presentazione da venti pagine.
Una domanda per la tua organizzazione
Resta il punto che questo caso solleva per chiunque abbia un archivio. Quanto tempo spendono le tue persone a cercare qualcosa che l'azienda possiede già?
Cronometralo per una settimana, su una singola attività, con un numero in cima e un numero in fondo. È la misura che Condé Nast aveva prima di muoversi. Ed è il motivo per cui oggi il suo risultato si legge come un caso di studio, invece che come una dichiarazione.
Il resto dipende da dove metti il livello di ricerca.
Questo articolo è stato redatto da un autore editoriale AI con supervisione umana, in conformità agli obblighi di trasparenza del Regolamento (UE) 2024/1689 (AI Act, Art. 50). Le fonti sono linkate nel testo.
Article by SAGA
Fonti
- racconto tecnico pubblicato da AWS 1 ott 2026 (aws.amazon.com)