La ricerca vettoriale di Notion è eccellente. Il loro prossimo problema è più difficile.
Leggendo "Two Years of Vector Search at Notion" — e cosa preannuncia su ciò che verrà
Notion ha pubblicato un post tecnico che copre due anni di infrastruttura di ricerca vettoriale. L'ho letto con sincera ammirazione e un forte senso di déjà vu. Quasi ogni problema che descrivono, ogni migrazione che hanno eseguito e ogni workaround che hanno costruito ha un parallelo stretto nella storia dei big data. I big data hanno impiegato circa quindici anni per convergere sulla loro architettura di lungo periodo.
Ciò che mi ha colpito di più non è stata solo la qualità dell'esecuzione. È stato quanto impegno sia stato dedicato a questioni a livello di piattaforma che, in un'architettura più completa, dovrebbero risiedere nell'infrastruttura anziché nell'ingegneria di prodotto.
Se dovessi indovinare il titolo del loro prossimo post tecnico, potrebbe essere "Come abbiamo trascorso sei mesi su un aggiornamento del modello di embedding." Oppure "Come abbiamo migrato cento milioni di workspace verso un nuovo spazio vettoriale senza downtime." Oppure "Come abbiamo costruito l'ingegneria del contesto offline per dare a Notion AI una memoria durevole."
Tutto ciò che è stato risolto finora è il Capitolo 1. Il Capitolo 2 è più difficile.
Cosa ha costruito Notion
La storia inizia a novembre 2023. Notion ha lanciato AI Q&A e quasi immediatamente ha accumulato una lista d'attesa di milioni di workspace. Il loro database vettoriale girava su cluster pod — storage e compute raggruppati insieme, partizionati per ID del workspace. Nel giro di un mese, si stavano avvicinando ai limiti di capacità.
Invece di effettuare un resharding sotto traffico live, hanno scelto la strada pragmatica: avviare nuovi cluster di indice contrassegnati con un generation ID, indirizzare i nuovi workspace verso nuove generazioni e lasciare i workspace esistenti al loro posto. Insieme al tuning di Spark e Airflow, hanno smaltito la lista d'attesa in quattro mesi. La capacità di onboarding giornaliera è aumentata di 600 volte.
Ingegneria pulita sotto pressione. Il costo: una logica di routing multi-generazione che li avrebbe accompagnati per due anni.
Poi due grandi migrazioni:
Maggio 2024 — dall'architettura pod al serverless. Storage e compute vengono disaccoppiati. I costi sono scesi immediatamente del 50%, e con essi si è dissolta la complessità del routing per generazioni — perché la capacità non era più una risorsa finita da pianificare in anticipo.
Dalla fine del 2024 all'inizio del 2025 — dal loro provider serverless a turbopuffer. I loro dati erano archiviati nel sistema di storage proprietario di un vendor, quindi il passaggio ha richiesto una reindicizzazione completa. Hanno colto l'occasione anche per aggiornare il loro modello di embedding.
Metà 2025: hanno rilasciato Page State. Ogni span di testo viene sottoposto a hash con xxHash (64-bit) e archiviato in DynamoDB. Quando una pagina viene aggiornata, il sistema confronta gli hash prima di decidere se ricalcolare l'embedding. Se sono cambiati solo i metadati, aggiorna direttamente il database vettoriale senza ricalcolare il vettore.
Poco dopo, la generazione degli embedding è passata da Spark + external API a modelli self-hosted su Ray via Anyscale. Il preprocessing su CPU e l'inferenza su GPU ora girano in un'unica pipeline, eliminando il passaggio tramite S3 tra sistemi.
Due anni. Cinque scommesse importanti. Costi ridotti del 90% rispetto al picco. È una serie di risultati davvero impressionante.
Questa è una storia che i big data hanno già raccontato
A ogni passaggio, continuavo a voler annotare con una data: l'ecosistema dei big data ha risolto questo nel [year]. Non è una coincidenza. Gli stessi vincoli producono le stesse mosse architetturali.
1. Separazione storage-compute e serverless: pagare per il lavoro, non per l'esistenza
Le due migrazioni di costo di Notion — dai cluster pod al serverless, poi a una configurazione serverless basata su object storage — possono essere lette come un'unica mossa architetturale: smettere di pagare per l'esistenza dell'infrastruttura e iniziare a pagare per il lavoro effettivo. Che un workspace venisse interrogato attivamente o restasse inattivo per settimane, il vecchio modello manteneva i cluster in esecuzione e in fatturazione.
Vista in questo modo, la svolta chiave è il disaccoppiamento dello storage dal compute: gli indici vivono nell'object storage, le collezioni fredde mantengono quasi nessun compute, le collezioni calde vengono caricate on demand, e la spesa segue molto più da vicino l'utilizzo reale. Nei big data, questo non è stato solo uno scambio da HDFS a S3; è stato un passaggio più ampio dall'integrazione storage-compute alla separazione storage-compute.
La sequenza è stata importante: prima, lo scaling indipendente ha risolto il problema dell'elasticità e della pianificazione della capacità; poi, il compute effimero più l'object storage persistente hanno ridotto i costi di utilizzo. Il deployment predefinito di Hadoop co-locava storage e compute per la data locality, il che rendeva difficile lo scaling indipendente. Una volta spostati i dati su S3, i cluster Spark potevano avviarsi per ogni job e spegnersi al termine, mentre lo storage rimaneva persistente.
Anche il compromesso è strutturale. L'accesso all'object storage stabilisce un limite inferiore alla latenza di cold-start: molteplici richieste GET, deserializzazione e ricostruzione dell'indice. Non è tanto un problema di tuning dei parametri quanto un problema di fisica dello storage. Per il workload attuale di Notion, in cui la maggior parte degli workspace viene interrogata di rado, questo è un buon compromesso. Ma man mano che l'utilizzo dell'AI si approfondisce, due limiti diventano più difficili da ignorare: grandi tenant con volumi di query elevati e sostenuti, e utenti che tornano a workspace freddi dove la tail latency diventa visibile all'utente. A quel punto, la caching single-tier S3-native è spesso insufficiente; mantenere i dati warm su SSD locali diventa materialmente più importante.
2. Architettura Lambda: il real-time è la necessità, la frammentazione è il costo
Il sistema di indicizzazione di Notion esegue due percorsi: una pipeline Spark offline per il backfill su larga scala, e consumer Kafka per gli aggiornamenti in real-time. Questa è una configurazione Lambda classica.
Se ti interessa la freschezza dei dati, questo design è un punto di partenza naturale. Il problema è ciò che accade dopo: la stessa logica inizia a diffondersi su più sistemi, e i team passano più tempo a mantenere coerenti i percorsi.
Nel caso di Notion, quella separazione ora si estende a Spark, consumer Kafka, DynamoDB per Page State, Ray per l'embedding, e un layer di serving separato.
Ogni componente sta svolgendo il lavoro giusto. La tassa nascosta è la superficie di integrazione:
- più glue code
- più passaggio di stato
- più possibilità di deriva tra comportamento offline e online
Molto di questo è amplificato dallo storage chiuso per il serving. La migrazione del provider significa re-indicizzazione completa. Il supporto agli aggiornamenti parziali significa tabelle di tracking esterne. I miglioramenti offline non aiutano il retrieval online finché un altro passaggio di sincronizzazione non viene completato.
Il nucleo di Kappa è semplice: un unico modello di elaborazione. La forma più forte è One Engine - batch e streaming come due modalità di un unico sistema, non due sistemi incollati insieme.
È esattamente qui che Lakebase si inserisce. Porta questa idea di One Engine su una base lake-native, colmando il divario OLTP/OLAP in modo che aggiornamenti in real-time, serving online ed elaborazione offline girino su un'unica tabella.
3. Il layer mancante: un'interfaccia dichiarativa per le operazioni vettoriali
Il passaggio da Spark + un'API di embedding esterna a una pipeline Ray unificata è la scelta giusta — collassare due sistemi che comunicavano tramite S3 in un unico grafo di compute è una vera semplificazione, e la riduzione prevista di oltre il 90% nei costi di embedding riflette un reale miglioramento architetturale. Ma è una semplificazione a livello di cablaggio infrastrutturale, e ciò che manca ancora è una semplificazione a livello semantico.
Nell'era Hadoop, fare qualunque cosa con i dati significava scrivere job MapReduce: dovevi comprendere il ciclo di vita di Mapper e Reducer, come funzionava lo shuffle, come gestire i failure e come concatenare gli stage. Hive ha aggiunto un layer dichiarativo — esprimi in SQL quale risultato vuoi, e il sistema capisce come trasformarlo in esecuzione MapReduce. Quel cambiamento non ha solo reso le cose più veloci; ha cambiato chi poteva lavorare con i dati, e ha reso il costo ingegneristico di una nuova operazione sui dati molto più vicino al costo di scrivere una query che al costo di scrivere un sistema distribuito.
Tuttavia, i dati vettoriali e non strutturati non hanno ancora questo livello.
- Se vuoi deduplicare un corpus da un miliardo di vettori prima di un'esecuzione di training di un modello, scrivi job Spark, scegli gli operatori giusti per il calcolo delle distanze, gestisci i formati di output e capisci come reinserire i risultati ovunque risieda il tuo serving layer.
- Se vuoi passare da un modello di embedding a uno più nuovo su centinaia di milioni di documenti, costruisci una pipeline di backfill, gestisci la coesistenza di embedding vecchi e nuovi durante il cutover e fai pulizia dopo — e questo processo è un progetto di engineering di più mesi anziché un'operazione di routine.
- Se vuoi mantenere una memoria utente compressa tra le sessioni, progetti la logica di compressione, gestisci scritture versionate e colleghi manualmente l'output al percorso di retrieval. Ognuno di questi è un progetto di systems engineering anziché un'operazione sui dati.
L'equivalente dichiarativo sarebbe esprimere l'intento — "deduplica questa collection con tolleranza coseno 0,05 e scrivi indietro i risultati," "esegui il backfill degli embedding usando questo nuovo modello," "comprimi la cronologia delle interazioni più vecchia di 90 giorni in rappresentazioni di memoria dense" — e lasciare che il sistema gestisca pianificazione dell'esecuzione, gestione delle risorse e coerenza. È questo il livello che rende il Context Engineering gestibile su larga scala anziché un progetto di engineering personalizzato ogni volta. Ed è ancora in gran parte assente dagli stack attuali di infrastruttura vettoriale, indipendentemente dal backend di serving.
| La decisione di Notion | Pattern architetturale |
|---|---|
| Cluster pod → serverless → serverless supportato da object storage | Separazione storage-compute: disaccoppiamento del lifecycle applicato agli indici vettoriali |
| Indicizzazione dual-path + Page State + routing della generazione | Design Lambda real-time-first: freschezza rapida, ma costo di sincronizzazione crescente tra percorsi online/offline |
| Handoff Spark + S3 → Ray | Collasso dell'I/O tra sistemi — ma il livello di interfaccia dichiarativa sopra di esso è ancora assente |
I big data hanno impiegato 15 anni per convergere su un'architettura in cui storage, compute e semantiche di processing fossero nettamente separati e componibili. Notion ha attraversato gran parte di quell'arco in due anni, il che è davvero notevole. Il pezzo che non è ancora arrivato è quello che renderebbe i prossimi due anni sostanzialmente meno costosi da costruire.
Ma questo è solo il primo capitolo
Tutto ciò che Notion ha risolto è l'infrastruttura per una sola funzionalità AI.
Tutta questa engineering — routing della generazione, migrazioni di provider, Page State, unificazione del compute Ray — esiste per far funzionare bene, in modo economico e affidabile, AI Q&A. Ci sono riusciti. L'infrastruttura per questa singola funzionalità è ora matura. Notion non rilascerà una sola funzionalità AI.
Tre problemi che mi aspetto nel loro prossimo post di engineering
Problema 1: Il limite di serverless + separazione cold/hot su larga scala
La scelta attuale di Notion è un buon compromesso per il suo workload attuale: milioni di workspace, la maggior parte dei quali interrogati di rado, dove l'economia S3-native è forte. Il limite è che qui i ceiling di performance sono determinati più dal comportamento dell'object storage che da knob software regolabili.
La latenza al primo byte di S3 è spesso nell'intervallo 10-100 ms. Un indice cold può richiedere più richieste GET e deserializzazione prima di essere interrogabile. In produzione, il p99 delle query cold può raggiungere intervalli di più secondi. Di solito non è un problema del modello; è il warmup dell'indice.
I principali pain point sono prevedibili.
- Primo, i tenant di grandi dimensioni con volume di query elevato e sostenuto iniziano a sentire i limiti della cache a singolo livello.
- Secondo, gli utenti che tornano a workspace cold possono vedere picchi di latenza evidenti. La cache multi-tier (memoria + SSD locale + object storage) cambia questa forma della coda in modi che i design single-tier di solito non possono.
Il modello di fatturazione può anche sorprendere i team: addebitare in base alla dimensione del namespace anziché al carico di lavoro delle query significa che workspace di grandi dimensioni possono sembrare costosi anche quando le singole query analizzano piccoli sottoinsiemi. In distribuzioni multi-tenant sbilanciate, la spesa può divergere dall’intuizione a livello di query.
Il recall dei filtri è un altro problema latente per gli approcci ANN-plus-post-filter. Quando i filtri sono ristretti — tipo di pagina, collaboratore, intervallo temporale — i pool di candidati possono diventare troppo piccoli, portando a un calo del recall. Man mano che Notion aggiunge più percorsi di retrieval AI filtrati, questo compromesso tende a emergere più spesso.
Quindi sì, il compromesso attuale è buono. I limiti sono semplicemente chiari: tenant di grandi dimensioni e latenza delle query a freddo diventano le prime crepe.
Problema 2: La divisione real-time/offline continua a diventare più costosa
Lo stack attuale di Notion: Spark + Airflow per l’elaborazione batch offline, consumer Kafka per gli aggiornamenti in tempo reale, Ray per l’embedding, Turbopuffer per le query. Quattro sistemi, ciascuno che svolge bene il proprio compito, tutti operano sugli stessi dati sottostanti — i contenuti delle pagine degli utenti.
Questa è la struttura dei silos di dati nella sua forma classica. Gli stessi dati sorgente sono mantenuti come viste multiple da sistemi diversi, con la logica a livello applicativo responsabile di mantenerle sincronizzate. Page State's xxHash + DynamoDB esiste specificamente per mantenere la coerenza tra la vista di elaborazione batch e la vista in tempo reale. Quella logica è corretta, ma la sua complessità scala linearmente con il numero di funzionalità AI — ogni nuova funzionalità aggiunge un altro insieme di logiche di sincronizzazione che deve essere mantenuto attraverso i percorsi real-time e offline.
Il problema più profondo: l’elaborazione offline non può migliorare direttamente il serving online senza un passaggio di sincronizzazione. Se la pipeline offline di Notion scopre forti relazioni semantiche tra documenti in un workspace, quelle relazioni non possono migliorare il retrieval per AI Q&A finché i risultati non vengono scritti da qualche parte dove la logica di query online possa leggerli. C’è un confine di sistema nel mezzo, con latenza e rischio di coerenza associati.
Questo è ciò che rende difficile far girare il volano dei dati: i segnali generati dall’uso online non possono migliorare continuamente i modelli offline senza attraversare un confine di sistema in entrambe le direzioni.
La risposta architetturale è OneData: serving online ed elaborazione offline condividono la stessa tabella sottostante. Nessuna vista multipla da sincronizzare, nessuna logica di coerenza a livello applicativo. Una tabella Iceberg, diverse modalità di calcolo, che leggono e scrivono nello stesso posto. Il livello offline rende più intelligente il livello online; il livello online genera segnali che il livello offline elabora. Il volano gira su un’unica base.
Problema 3: Context engineering offline — dove si costruisce il vero moat
Notion AI oggi: l’utente pone una domanda → recupera chunk rilevanti in tempo reale → li fornisce all’LLM → restituisce una risposta. Il tetto qualitativo di questa pipeline è determinato da ciò che si trova nell’indice.
Il divario che il context engineering offline colma non è la qualità del retrieval al momento della query — è la qualità di ciò che hai costruito prima che la query arrivi.
Memoria. Ogni conversazione con Notion AI contiene un segnale: ciò che interessa all’utente, come lavora, quale conoscenza conta per lui. Vettorizzare quel segnale e organizzarlo in una memoria utente recuperabile è semplice. Mantenerla non lo è: i vecchi ricordi necessitano di compressione (una conversazione di sei mesi fa deve diventare una rappresentazione più densa), i ricordi obsoleti devono essere aggiornati (quando nuovi contenuti contraddicono vecchi record) e i ricordi correlati devono essere organizzati gerarchicamente. Tutto questo è elaborazione batch offline continua su dati vettoriali. Non può essere fatto al momento della query.
Grafi di conoscenza precalcolati. Anziché cercare "quali documenti sono rilevanti per questa query" da zero ogni volta, l'elaborazione offline può costruire un modello della topologia semantica del workspace — quali documenti affrontano gli stessi concetti, quali decisioni hanno dipendenze, come le idee si sono evolute nel tempo. Quel modello diventa il contesto che l'AI possiede già, così ragiona a partire da una comprensione del tuo workspace invece di effettuare una nuova ricerca da zero.
Il volano dei dati. Quali risultati di retrieval sono stati utilizzati? Quali domande continuano a emergere senza risposte soddisfacenti? Quali documenti vengono citati ripetutamente in query diverse? Questi segnali, elaborati offline, possono ottimizzare continuamente il retrieval — regolando le strategie di chunking, facendo emergere conoscenze che continuano a dimostrarsi rilevanti e identificando punti ciechi. Il volano gira solo se c'è un'infrastruttura per tradurre i segnali in miglioramenti nel livello vettoriale. Senza di essa, i segnali sono solo byte in un file di log.
Notion si trova su uno dei dataset AI più interessanti esistenti: conoscenza strutturata, organizzata deliberatamente, attraverso decine di milioni di workspace. È una materia prima straordinaria. Ma un data moat non si costruisce avendo dati — si costruisce avendo un'infrastruttura che trasforma continuamente i dati in capacità. La loro attuale infrastruttura vettoriale è progettata per il serving online. Manutenzione della memoria, precalcolo dei grafi di conoscenza, volani di elaborazione dei segnali — questi sono problemi batch su larga scala che non hanno una collocazione naturale nell'architettura attuale.
Posizionamento di Lakebase
A questo punto, lo schema è chiaro. Il prossimo collo di bottiglia non è una singola decisione sul motore di query. È il divario tra serving in tempo reale ed elaborazione offline.
Vector Lakebase si posiziona come il ponte:
Un'unica piattaforma unificata per OLTP e OLAP: serving in tempo reale, scoperta iterativa e analisi batch vengono eseguiti sulla stessa base dati lake-native e su un'unica fonte di verità.
Un unico flusso incrementale invece della sincronizzazione a doppio percorso. Change capture, re-embedding e re-indexing diventano capacità del livello dati, non codice collante applicativo.
Un unico luogo in cui l'intelligenza offline arriva online. Compressione della memoria, backfill e segnali di qualità scrivono sulla stessa tabella e migliorano direttamente il serving.
Questo è il pratico Capitolo 2: non solo una ricerca migliore, ma un modello operativo unificato per i dati vettoriali.
Vector Lakebase è la risposta di Zilliz Cloud al Capitolo 2: storage, elaborazione e serving vettoriali unificati sul tuo data lake esistente. Nessuna migrazione richiesta. Resta sintonizzato.
Continua a leggere
Why We Built Vector Lakebase: Rethinking Unstructured Data Architecture for AI
Vector Lakebase: a unified, lake-native data foundation for AI workloads — and an answer to what happens after vector databases succeed.
Introducing Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud
We're announcing the general availability of Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud.
How to Improve Retrieval Quality for Japanese Text with Sudachi, Milvus/Zilliz, and AWS Bedrock
Learn how Sudachi normalization and Milvus/Zilliz hybrid search improve Japanese RAG accuracy with BM25 + vector fusion, AWS Bedrock embeddings, and practical code examples.