Deduplicazione dei dati su scala di trilioni: come risolvere il più grande collo di bottiglia dell’addestramento degli LLM
La corsa allo scaling degli LLM—e il suo costo invisibile
Gli LLM hanno trasformato quasi ogni aspetto dell’IA moderna, aprendo nuove frontiere nella generazione di contenuti, nello sviluppo software, nel ragionamento e nell’uso autonomo degli strumenti. E le loro capacità non mostrano segni di rallentamento.
Prendiamo gli annunci più recenti: Grok 4 di X.ai e Kimi K2 di Moonshot introducono capacità di ragionamento più solide, un migliore uso degli strumenti e una generazione più coerente, il tutto alimentato da corpora di addestramento significativamente più grandi e più diversificati.
La tendenza è chiara: la frontiera delle capacità viene spinta in avanti dall’addestramento su una scala senza precedenti. Consideriamo le impronte dei dati dei modelli recenti:
| Modello | Rilascio | Parametri | Dati di addestramento |
|---|---|---|---|
| Kimi K2 | 2025 | 1T | 15,5 trilioni di token |
| Grok 4 | 2025 | ~175B | 100 volte più di Grok 2, probabilmente su scala dei trilioni |
| GPT-4 | 2023 | 1,8T (stima) | 13 trilioni di token |
| LLaMA 3.1 | 2024 | 405B | 15 trilioni di token |
Kimi K2, ad esempio, ha triplicato la dimensione del suo dataset in soli sei mesi, un tasso di crescita che quasi supera l’espansione di internet. Con 15,5 trilioni di token, è più grande del contenuto cumulativo di ogni grande biblioteca globale, molte volte tanto.
Ma nascosta dentro questa crescita c’è l’ipotesi che più dati equivalgano sempre a prestazioni migliori. In pratica, i guadagni marginali derivanti dal semplice aggiungere più token stanno diminuendo e sono sempre più vincolati dalla qualità dei dati.
Questo ci porta al primo—e forse più sottovalutato—collo di bottiglia nell’addestramento moderno degli LLM: la duplicazione dei dati.
Deduplicazione dei dati: perché è importante per l’addestramento degli LLM
I dataset moderni di pre-addestramento degli LLM provengono principalmente da crawl web su larga scala, repository aperti, corpora pubblici e documenti specifici di dominio raccolti dal web. Man mano che queste pipeline crescono, la ridondanza diventa non solo comune, ma sistemica.
Documenti con variazioni minori (ad esempio modifiche di formattazione, piè di pagina, intestazioni boilerplate) ricompaiono su domini diversi. Le pagine popolari vengono duplicate, tradotte o ripubblicate su altri siti web. Codebase e articoli di conoscenza vengono duplicati tra forum, wiki e snapshot archiviati. Persino fonti strutturate, come Wikipedia, mostrano ripetizioni nei percorsi dei link e nei mirror.
Quando questo contenuto duplicato confluisce senza controllo nei set di addestramento, le conseguenze sono significative:
Inefficienza computazionale: esempi ripetuti non forniscono nuove informazioni ma consumano le stesse risorse computazionali.
Rischio di overfitting: gli LLM esposti a formulazioni, strutture o pattern di contenuto ripetuti possono diventare eccessivamente dipendenti da questi pattern, riducendo così le loro capacità di generalizzazione.
Memorizzazione letterale: un’elevata duplicazione aumenta il rischio che i modelli memorizzino sequenze specifiche, sollevando preoccupazioni relative a sicurezza, privacy e proprietà intellettuale.
Contaminazione della valutazione: se esistono duplicati tra i set di addestramento e quelli di validazione/test, i punteggi dei benchmark possono essere artificialmente gonfiati, fornendo un’impressione fuorviante della qualità del modello.
In breve, la duplicazione non è solo un fastidio. È un problema esistenziale per run di addestramento su larga scala e ad alto costo.
Uno dei nostri clienti enterprise—un provider LLM di primissimo livello—ha incontrato esattamente questo problema. Doveva deduplicare decine di miliardi di documenti prima che venissero ingeriti. Gli strumenti di corrispondenza hash esatta non individuavano i quasi-duplicati. I modelli semantici erano troppo costosi da eseguire su larga scala. E gli stack tradizionali di pulizia dei dati semplicemente non riuscivano a soddisfare i loro vincoli di tempo e risorse.
Questo è il contesto in cui la deduplicazione è diventata infrastruttura mission-critical, non un ripensamento di preprocessing.
Una panoramica delle tecniche di deduplicazione
Esistono tre strategie dominanti per la deduplicazione su larga scala, ciascuna con compromessi in termini di precisione, costo e fattibilità.
Corrispondenza esatta: Utilizza l’hashing crittografico per trovare documenti identici. Veloce e precisa, ma non rileva i quasi duplicati con piccole differenze di formattazione.
Corrispondenza semantica: Sfrutta modelli di embedding vettoriale per trovare contenuti concettualmente simili. Altamente accurata ma computazionalmente costosa su larga scala.
Corrispondenza approssimata: Trova quasi duplicati utilizzando algoritmi probabilistici come MinHash LSH e la similarità di Jaccard. Bilancia accuratezza ed efficienza computazionale: perfetta per dataset da trilioni di token.
Con corpora di preaddestramento che raggiungono terabyte o persino petabyte, i metodi tradizionali di corrispondenza esatta, come i confronti a coppie, sono computazionalmente impraticabili. La deduplicazione semantica aggiunge un sovraccarico significativo utilizzando modelli di embedding per generare vettori.
Abbiamo bisogno di metodi approssimati più innovativi—come MinHash LSH—che bilancino richiamo e precisione mantenendo i costi gestibili, rendendo pratica la deduplicazione su larga scala.
MinHash LSH: Rilevare quasi duplicati in dataset su scala di trilioni
Nel contesto dell’addestramento LLM su larga scala, una deduplicazione efficiente richiede un algoritmo di corrispondenza che sia non solo accurato, ma anche computazionalmente fattibile alla scala di decine di miliardi di documenti. MinHash LSH (Locality Sensitive Hashing) è progettato appositamente proprio per questo tipo di scenario.
MinHash: Stima scalabile della similarità
MinHash è una tecnica probabilistica progettata per stimare la similarità di Jaccard tra insiemi, senza calcolare intersezioni esplicite a coppie. Nel contesto della deduplicazione dei documenti, agisce come un meccanismo di compressione con perdita che preserva la struttura di similarità attraverso corpora enormi.
Il processo funziona come segue:
Ogni documento viene scomposto in un insieme di shingle, tipicamente n-grammi di caratteri o parole di lunghezza fissa.
Una serie di funzioni hash indipendenti viene applicata a questi insiemi.
Per ogni funzione hash, viene conservato il valore minimo risultante nell’insieme di shingle.
Questo produce una firma MinHash di lunghezza fissa per ciascun documento. La proprietà fondamentale è questa: per due documenti qualsiasi, la probabilità che un particolare valore hash sia condiviso nella stessa posizione delle loro firme approssima la loro similarità di Jaccard.
Ciò riduce drasticamente il carico computazionale per il rilevamento della similarità su larga scala. Invece di confrontare documenti completi, confrontiamo brevi vettori di firme. Ma c’è un problema di scalabilità. Anche con questa ottimizzazione, confrontare ogni coppia di documenti rimane computazionalmente impraticabile su scala web.
Locality Sensitive Hashing: Accelerare la ricerca di similarità
Per rendere MinHash pratico per corpora su scala di miliardi, applichiamo Locality Sensitive Hashing (LSH) sopra i vettori di firma. L’idea centrale di LSH è aumentare la probabilità che documenti simili collidano in almeno un bucket hash, senza richiedere un confronto esaustivo.
Ecco come funziona:
Ogni firma MinHash viene divisa in più bande, ciascuna contenente un sottoinsieme delle dimensioni della firma.
Ogni banda viene sottoposta indipendentemente a hashing in un bucket.
Se due documenti condividono almeno una banda che viene mappata tramite hash nello stesso bucket, sono considerati candidati per una potenziale duplicazione.
Questa strategia di banding assicura che i documenti con alta similarità (cioè molti valori MinHash condivisi) abbiano molte più probabilità di collidere. Regolando il numero di bande e di righe per banda, possiamo bilanciare richiamo (il numero di duplicati accurati intercettati), precisione (il numero di falsi positivi evitati) e prestazioni.
Il risultato è un sistema di deduplicazione approssimata scalabile che rimane trattabile anche quando applicato a corpora contenenti decine di miliardi di documenti.
Integrare MinHash LSH con Milvus e Zilliz Cloud
Tradizionalmente, la deduplicazione è gestita da pipeline di pre-elaborazione standalone disconnesse dall’infrastruttura principale di retrieval o storage. Questo introduce una serie di inefficienze:
Costoso trasferimento dei dati tra i componenti di deduplicazione e di indicizzazione vettoriale.
Logica duplicata per la normalizzazione dei dati e lo shingling.
Difficoltà nel far scalare insieme le pipeline di deduplicazione e retrieval.
Abbiamo affrontato il problema in modo diverso. Riconoscendo il punto di forza di Milvus come database vettoriale ad alta produttività, ci siamo chiesti: E se MinHash LSH fosse una primitiva di indicizzazione di prima classe, integrata nativamente?
Questo ha portato all’integrazione nativa di MinHash LSH in Milvus 2.6 e Zilliz Cloud (Milvus gestito), trasformando la deduplicazione approssimativa in una parte fondamentale del workflow di indicizzazione e retrieval vettoriale.
Cosa consente questa integrazione
Workflow end-to-end: Dall’ingestion e dalla generazione delle firme MinHash al rilevamento approssimativo dei duplicati e al successivo retrieval semantico, tutto all’interno di Milvus.
Scala distribuita: Costruita sull’architettura cloud-native di Milvus, l’indicizzazione LSH scala orizzontalmente su terabyte o persino petabyte di dati.
API unificate: La stessa API usata per la ricerca di embedding semantici può ora supportare anche query di deduplicazione basate su MinHash, rendendo i workflow MLOps più puliti e più manutenibili.
Nella nostra implementazione attuale:
Gli utenti generano esternamente le firme MinHash (ad es., usando le strategie di shingling e hashing preferite).
Questi vettori di firma (tipicamente array
uint32) vengono inseriti in Milvus.L’indicizzazione LSH restringe lo spazio dei candidati per il rilevamento approssimativo dei duplicati usando la strategia di banding descritta sopra.
Questo design consente ai team di deduplicare corpora di training su scala massiva senza introdurre livelli di storage aggiuntivi o logiche di pre-elaborazione disconnesse.
Abbiamo anche esteso l’API sottostante per supportare workflow come inserimento ibrido (vettori semantici e MinHash), costruzione dinamica degli indici e query di deduplicazione batch. Queste capacità sono ancora in evoluzione e accogliamo con piacere il feedback dei team che le implementano in produzione.
Le sfide ingegneristiche della deduplicazione di decine di miliardi di documenti con MinHash LSH
Far funzionare MinHash LSH in produzione è stato per anni la balena bianca del settore.
La sfida si riduce a due requisiti brutali:
Serve una profonda competenza sia negli algoritmi MinHash sia in quelli LSH, oltre alle capacità ingegneristiche per integrarli senza soluzione di continuità.
Qualsiasi caso d’uso reale per MinHash LSH implica la deduplicazione di decine di miliardi, centinaia di miliardi o persino trilioni di punti dati. Questo impone requisiti schiaccianti in termini di prestazioni e capacità ingegneristiche che la maggior parte dei team non può soddisfare.
Ecco un esempio perfetto: circa un anno fa, un’importante azienda di AI ci ha contattato con una richiesta apparentemente semplice. Avevano bisogno di deduplicare decine di miliardi di punti dati (in un formato int32 a 780 dimensioni), con la possibilità di avviare rapidamente servizi ed elaborare rapidamente i dati per la deduplicazione e l’inserimento.
Ci siamo subito imbattuti in un ostacolo bloccante: la maggior parte dei database vettoriali usa per impostazione predefinita formati di dati float32, ma i vettori MinHash sono collezioni di valori hash uint32.
A prima vista, sembra un non-problema: float32 può rappresentare valori uint32 nella maggior parte dei casi, giusto?
Sbagliato.
Ecco il punto critico: float32 può rappresentare solo interi senza segno nell’intervallo da 0 a 16.777.216, mentre uint32 copre da 0 a 4.294.967.295. Se un valore hash supera 16.777.216, float32 inizia a perdere precisione nei bit meno significativi.
Fortunatamente, il supporto ai vettori binari di Milvus e Zilliz Cloud risolve elegantemente questo problema.
Potrebbe sembrare un dettaglio tecnico minore, ma mette in evidenza un punto cruciale: hai bisogno di un database progettato fin dall'inizio per gestire formati di dati diversi, scale enormi e requisiti enterprise variegati. Se non progetti fin da subito per scenari di livello enterprise, anche piccoli problemi di compatibilità come questo possono trasformarsi in disastri per l'esperienza del cliente più avanti.
Ma la sfida del formato dei dati era solo l'inizio: i nostri clienti richiedevano anche prestazioni estreme. Durante il processo di integrazione, il cliente l'ha detto senza mezzi termini: "Devo avviare rapidamente servizi Zilliz Cloud in grado di eseguire immediatamente una deduplicazione vettoriale ad alta precisione. Ogni importazione coinvolge file da 30 GB con dati di firma int32 a 780 dimensioni, e l'intero processo di importazione deve completarsi in meno di 15 minuti."
A prima vista sembra una missione impossibile, ma abbiamo rapidamente fornito la nostra risposta: dimenticate i 15 minuti: lo faremo in 4.
Questo salto di prestazioni è derivato da due ottimizzazioni chiave di Milvus:
Innanzitutto, abbiamo implementato l'elaborazione parallela multi-file, che ha infranto il tradizionale collo di bottiglia dell'importazione seriale. Il sistema ora può gestire simultaneamente più file di dati, aumentando drasticamente il throughput complessivo e le velocità di importazione.
In secondo luogo, abbiamo integrato l'allocazione dinamica delle risorse, che pianifica in modo intelligente le risorse computazionali in base alla complessità e al volume dell'attività. Questo elimina sprechi e contese di risorse massimizzandone al contempo l'utilizzo. Insieme, queste ottimizzazioni consentono a Milvus di sfruttare appieno le capacità dell'hardware moderno e le caratteristiche di lettura-scrittura concorrente dello storage cloud, offrendo esperienze di importazione dei dati quasi in tempo reale.
Risolvere la sfida dell'importazione era solo il primo passo: come gestire deployment e calcolo rapidi su scala massiccia?
Gli scenari di addestramento di grandi modelli AI creano una tempesta perfetta di requisiti impegnativi. Devi gestire enormi volumi di dati in ingresso, database esistenti massicci e carichi di picco che possono raggiungere 44.000 recuperi vettoriali al secondo: il tipo di concorrenza estrema che schiaccia la maggior parte dei sistemi. Man mano che i dati continuano ad affluire e il tuo database cresce esponenzialmente, le esigenze computazionali aumentano di conseguenza, esercitando una pressione incessante sulle prestazioni del sistema.
La soluzione richiede una seria potenza di calcolo distribuito. L'architettura cloud-native di Zilliz Cloud è stata progettata specificamente per affrontare queste sfide tramite una distribuzione intelligente dei carichi di lavoro e uno scaling elastico.
L'arma segreta: integrazione del Cardinal Engine
Guardando al futuro, MinHash LSH rappresenta solo l'inizio. Stiamo integrando questa capacità nel motore proprietario Cardinal di Zilliz Cloud, che accelererà ulteriormente l'elaborazione dei dati non strutturati su tutta la linea.
Cardinal è il nostro motore di ricerca vettoriale di nuova generazione basato sull'AI, costruito da zero con C++ moderno e algoritmi di ricerca approssimata del vicino più prossimo (ANNS) all'avanguardia. L'obiettivo è semplice: gestire più richieste degli utenti con le stesse risorse hardware.
Ottimizzazioni a livello di algoritmo: Cardinal offre un'ampia ottimizzazione delle prestazioni per algoritmi core come IVF e l'indicizzazione a grafo, raggiungendo l'equilibrio ottimale tra velocità ed efficienza della memoria.
Innovazioni a livello ingegneristico: Il motore include allocatori di memoria personalizzati e pooling intelligente della memoria, insieme a un'architettura modulare dei componenti che consente una composizione flessibile della pipeline di ricerca. Ogni pipeline può essere ottimizzata per casi d'uso specifici e mission-critical.
Ottimizzazione specifica per l'hardware: Cardinal include molteplici kernel di calcolo specializzati, ciascuno ottimizzato manualmente per piattaforme hardware e pattern di workload specifici.
Queste ottimizzazioni complete consentono a Cardinal di operare alla massima efficienza 24 ore su 24, offrendo prestazioni di ricerca vettoriale leader del settore. Con Cardinal alla base di Zilliz Cloud, abbiamo ottenuto miglioramenti delle prestazioni di 10 volte rispetto a Milvus open-source, combinati con velocità di query ultra-rapide e alti tassi di recall. Che tu stia elaborando dataset enormi o creando applicazioni che richiedono tempi di risposta fulminei, Cardinal fornisce la base prestazionale per esperienze utente superiori e applicazioni AI competitive.
Il futuro è non strutturato—E noi siamo pronti
La deduplicazione dei dati di addestramento degli LLM è solo l'atto di apertura di una storia di trasformazione molto più ampia. IDC prevede che entro il 2027 i dati non strutturati esploderanno fino a quasi 250ZB a livello globale, rappresentando l'86,8% di tutti i dati esistenti. Sebbene questi dati costino significativamente di più da elaborare e archiviare rispetto ai dati strutturati, il valore racchiuso in testi, immagini, audio, video, log di sensori, contenuti dei social media, PDF, pagine web, repository di codice, imaging medico e foto satellitari è impossibile da ignorare.
Questo crea la sfida determinante della nostra era: come possiamo estrarre valore in modo efficiente da dati non strutturati in crescita esponenziale senza spendere una fortuna?
Le capacità di deduplicazione che abbiamo costruito per l'addestramento dell'AI rappresentano solo un tassello di questo puzzle più ampio. Man mano che i dati non strutturati continuano la loro crescita esplosiva, gli stessi principi—algoritmi intelligenti, ingegneria su scala enterprise e prestazioni cloud-native—diventeranno infrastrutture essenziali per ogni organizzazione guidata dai dati.
Il futuro appartiene alle aziende che sanno trasformare il caos dei dati non strutturati in un vantaggio competitivo strutturato. Stiamo costruendo quel futuro, un algoritmo alla volta. Pronto a unirti a noi?
Pronto a esplorare la deduplicazione su larga scala per la tua pipeline di addestramento AI? Scopri di più sulle funzionalità MinHash LSH di Milvus 2.6 nella nostra documentazione completa, prova Zilliz Cloud (Milvus gestito) per carichi di lavoro di produzione, oppure connettiti con il nostro team di ingegneria su Discord per discutere il tuo caso d'uso specifico.
Continua a leggere
Top 10 Context Engineering Techniques You Should Know for Production RAG
A practical guide to context engineering for production LLM systems, covering RAG, context processing, memory, agents, and multimodal context.
Introducing Zilliz MCP Server: Natural Language Access to Your Vector Database
Developers can easily manage and query vector databases with natural language via Zilliz MCP Server in AI-native environments.
What Exactly Are AI Agents? Why OpenAI and LangChain Are Fighting Over Their Definition?
AI agents are software programs powered by AI that can perceive their environment, make decisions, and take actions to achieve a goal—often autonomously.