La recherche vectorielle de Notion est excellente. Son prochain problème est plus difficile.
Lecture de « Two Years of Vector Search at Notion » — et ce que cela prédit sur la suite
Notion a publié un article d’ingénierie couvrant deux années d’infrastructure de recherche vectorielle. Je l’ai lu avec une admiration sincère et un fort sentiment de déjà-vu. Presque chaque problème qu’ils décrivent, chaque migration qu’ils ont exécutée et chaque solution de contournement qu’ils ont construite a un parallèle proche dans l’histoire du big data. Le big data a mis environ quinze ans à converger vers son architecture à long terme.
Ce qui m’a le plus frappé, ce n’était pas seulement la qualité de l’exécution. C’était l’ampleur de l’effort consacré à des préoccupations de niveau plateforme qui, dans une architecture plus complète, devraient relever de l’infrastructure plutôt que de l’ingénierie produit.
Si je devais deviner le titre de leur prochain article d’ingénierie, ce serait peut-être « Comment nous avons passé six mois sur une mise à niveau de modèle d’embedding. » Ou « Comment nous avons migré cent millions d’espaces de travail vers un nouvel espace vectoriel sans interruption. » Ou « Comment nous avons construit une ingénierie de contexte hors ligne pour donner à Notion AI une mémoire durable. »
Tout ce qui a été résolu jusqu’ici est le chapitre 1. Le chapitre 2 est plus difficile.
Ce que Notion a construit
L’histoire commence en novembre 2023. Notion a lancé AI Q&A et a presque immédiatement accumulé une liste d’attente de millions d’espaces de travail. Leur base de données vectorielle fonctionnait sur des clusters de pods — stockage et calcul regroupés, partitionnés par ID d’espace de travail. En un mois, ils approchaient des limites de capacité.
Plutôt que de repartitionner sous trafic en production, ils ont choisi la voie pragmatique : lancer de nouveaux clusters d’index marqués avec un ID de génération, router les nouveaux espaces de travail vers de nouvelles générations, et laisser les espaces de travail existants en place. Combiné à l’optimisation de Spark et d’Airflow, cela leur a permis de résorber la liste d’attente en quatre mois. La capacité d’onboarding quotidienne a été multipliée par 600.
Une ingénierie propre sous pression. Le coût : une logique de routage multi-génération qui allait les suivre pendant deux ans.
Puis deux migrations majeures :
Mai 2024 — de l’architecture en pods au serverless. Le stockage et le calcul sont découplés. Les coûts ont immédiatement baissé de 50 %, et la complexité du routage par génération a disparu avec eux — parce que la capacité n’était plus une ressource finie qu’il fallait planifier à l’avance.
De fin 2024 au début 2025 — de leur fournisseur serverless à turbopuffer. Leurs données étaient stockées dans le système de stockage propriétaire d’un fournisseur, donc le changement nécessitait une réindexation complète. Ils ont aussi profité de l’occasion pour mettre à niveau leur modèle d’embedding.
Mi-2025 : ils ont lancé Page State. Chaque segment de texte est haché avec xxHash (64 bits) et stocké dans DynamoDB. Lorsqu’une page est mise à jour, le système compare les hachages avant de décider s’il faut recalculer l’embedding. Si seules les métadonnées ont changé, il applique directement un correctif à la base de données vectorielle sans recalculer le vecteur.
Peu après, la génération d’embeddings est passée de Spark + external API à des modèles auto-hébergés sur Ray via Anyscale. Le prétraitement CPU et l’inférence GPU s’exécutent désormais dans un seul pipeline, éliminant le transfert via S3 entre systèmes.
Deux ans. Cinq paris majeurs. Des coûts en baisse de 90 % depuis le pic. C’est un parcours véritablement impressionnant.
C’est une histoire que le big data a déjà racontée
À chaque étape, j’avais envie d’annoter avec une date : l’écosystème big data a résolu cela en [année]. Ce n’est pas une coïncidence. Les mêmes contraintes produisent les mêmes choix architecturaux.
1. Séparation stockage-calcul et serverless : payer pour le travail, pas pour l’existence
Les deux migrations de coûts de Notion — des clusters de pods au serverless, puis à une configuration serverless adossée au stockage objet — peuvent être lues comme un seul mouvement architectural : arrêter de payer pour l’existence de l’infrastructure et commencer à payer pour le travail réel. Qu’un espace de travail soit activement interrogé ou inactif pendant des semaines, l’ancien modèle gardait les clusters en fonctionnement et facturés.
Vu sous cet angle, le changement clé consiste à découpler le stockage du calcul : les index résident dans le stockage objet, les collections froides mobilisent presque aucune capacité de calcul, les collections chaudes se chargent à la demande, et les dépenses suivent de beaucoup plus près l’usage réel. Dans le big data, il ne s’agissait pas simplement de remplacer HDFS par S3 ; c’était un mouvement plus large, passant de l’intégration stockage-calcul à la séparation stockage-calcul.
La séquence a compté : d’abord, la mise à l’échelle indépendante a résolu la douleur liée à l’élasticité et à la planification de capacité ; ensuite, le calcul éphémère associé au stockage objet persistant a réduit les coûts d’utilisation. Le déploiement par défaut de Hadoop colocalisait le stockage et le calcul pour bénéficier de la localité des données, ce qui rendait difficile la mise à l’échelle indépendante. Une fois les données déplacées vers S3, les clusters Spark pouvaient démarrer pour chaque tâche puis s’arrêter ensuite, tandis que le stockage restait persistant.
Le compromis est également structurel. L’accès au stockage objet fixe un plancher à la latence de démarrage à froid : multiples requêtes GET, désérialisation et reconstruction d’index. Il s’agit moins d’un problème d’ajustement de paramètres que d’un problème de physique du stockage. Pour la charge de travail actuelle de Notion, où la plupart des espaces de travail sont interrogés peu fréquemment, c’est un bon compromis. Mais à mesure que l’usage de l’IA s’approfondit, deux limites deviennent plus difficiles à ignorer : les grands locataires avec un volume de requêtes élevé et soutenu, et les utilisateurs revenant à des espaces de travail froids où la latence de queue devient visible pour l’utilisateur. À ce stade, la mise en cache S3-native à niveau unique est souvent insuffisante ; conserver les données tièdes sur des SSD locaux devient nettement plus important.
2. Architecture Lambda : le besoin est le temps réel, le coût est la fragmentation
Le système d’indexation de Notion exécute deux chemins : un pipeline Spark hors ligne pour le backfill à grande échelle, et des consommateurs Kafka pour les mises à jour en temps réel. C’est une configuration Lambda classique.
Si la fraîcheur des données vous importe, cette conception est un point de départ naturel. Le problème est ce qui se passe ensuite : la même logique commence à se disperser entre plusieurs systèmes, et les équipes passent plus de temps à maintenir la cohérence des chemins.
Dans le cas de Notion, cette séparation couvre désormais Spark, les consommateurs Kafka, DynamoDB pour Page State, Ray pour les embeddings, et une couche de service séparée.
Chaque composant fait le bon travail. La taxe cachée réside dans la surface d’intégration :
- davantage de code de liaison
- davantage de transfert d’état
- davantage de risques de divergence entre les comportements hors ligne et en ligne
Une grande partie de cela est amplifiée par le stockage fermé pour le service. La migration de fournisseur implique une réindexation complète. La prise en charge des mises à jour partielles implique des tables de suivi externes. Les améliorations hors ligne n’aident pas la récupération en ligne tant qu’une autre étape de synchronisation n’est pas terminée.
Le cœur de Kappa est simple : un seul modèle de traitement. Sa forme la plus forte est One Engine - batch et streaming comme deux modes d’un même système, et non deux systèmes collés ensemble.
C’est exactement là que Lakebase intervient. Il apporte cette idée de One Engine à une fondation lake-native, en comblant l’écart OLTP/OLAP afin que les mises à jour en temps réel, le service en ligne et le traitement hors ligne s’exécutent sur une seule table.
3. La couche manquante : une interface déclarative pour les opérations vectorielles
Le passage de Spark + une API d’embedding externe à un pipeline Ray unifié est le bon choix — fusionner deux systèmes qui communiquaient via S3 en un seul graphe de calcul est une véritable simplification, et la réduction projetée de plus de 90 % des coûts d’embedding reflète une amélioration architecturale réelle. Mais c’est une simplification au niveau du câblage de l’infrastructure, et il en manque encore une au niveau sémantique.
À l’ère Hadoop, faire quoi que ce soit avec des données signifiait écrire des tâches MapReduce : il fallait comprendre le cycle de vie du Mapper et du Reducer, le fonctionnement du shuffle, la gestion des défaillances et l’enchaînement des étapes. Hive a ajouté une couche déclarative — vous exprimez le résultat souhaité en SQL, et le système détermine comment le transformer en exécution MapReduce. Ce changement n’a pas seulement accéléré les choses ; il a transformé les personnes qui pouvaient travailler avec les données, et il a rapproché le coût d’ingénierie d’une nouvelle opération de données du coût d’écriture d’une requête plutôt que de celui d’écriture d’un système distribué.
Cependant, les données vectorielles et non structurées ne disposent pas encore de cette couche.
- Si vous voulez dédupliquer un corpus d’un milliard de vecteurs avant une exécution d’entraînement de modèle, vous écrivez des jobs Spark, choisissez les bons opérateurs de calcul de distance, gérez les formats de sortie et déterminez comment réinjecter les résultats là où se trouve votre couche de service.
- Si vous voulez passer d’un modèle d’embedding à un modèle plus récent sur des centaines de millions de documents, vous construisez un pipeline de backfill, gérez la coexistence des anciens et des nouveaux embeddings pendant la bascule, puis nettoyez ensuite — et ce processus est un projet d’ingénierie de plusieurs mois plutôt qu’une opération de routine.
- Si vous voulez maintenir une mémoire utilisateur compressée entre les sessions, vous concevez la logique de compression, gérez les écritures versionnées et raccordez manuellement la sortie au chemin de récupération. Chacun de ces cas est un projet d’ingénierie système plutôt qu’une opération de données.
L’équivalent déclaratif consisterait à exprimer une intention — « dédupliquer cette collection avec une tolérance cosinus de 0,05 et réécrire les résultats », « effectuer un backfill des embeddings avec ce nouveau modèle », « compresser l’historique d’interactions de plus de 90 jours en représentations de mémoire denses » — et à laisser le système gérer la planification de l’exécution, la gestion des ressources et la cohérence. C’est la couche qui rend le Context Engineering praticable à grande échelle plutôt qu’un projet d’ingénierie sur mesure à chaque fois. Et elle manque encore largement dans les piles d’infrastructure vectorielle actuelles, quel que soit le backend de service.
| La décision de Notion | Pattern architectural |
|---|---|
| Clusters pod → serverless → serverless adossé au stockage objet | Séparation stockage-calcul : découplage du cycle de vie appliqué aux index vectoriels |
| Indexation à double chemin + Page State + routage par génération | Conception Lambda privilégiant le temps réel : fraîcheur rapide, mais coût de synchronisation croissant entre chemins en ligne/hors ligne |
| Relais Spark + S3 → Ray | Réduction des I/O inter-systèmes — mais la couche d’interface déclarative au-dessus manque toujours |
Le big data a mis 15 ans à converger vers une architecture dans laquelle le stockage, le calcul et les sémantiques de traitement étaient clairement séparés et composables. Notion a parcouru l’essentiel de cet arc en deux ans, ce qui est vraiment impressionnant. La pièce qui n’a pas encore abouti est celle qui rendrait les deux prochaines années nettement moins coûteuses à construire.
Mais ce n’est que le premier chapitre
Tout ce que Notion a résolu constitue l’infrastructure d’une seule fonctionnalité d’IA.
Toute cette ingénierie — routage par génération, migrations de fournisseurs, Page State, unification du calcul avec Ray — existe pour que les questions-réponses IA fonctionnent bien, à moindre coût et de manière fiable. Ils y sont parvenus. L’infrastructure de cette fonctionnalité unique est désormais mature. Notion ne va pas livrer une seule fonctionnalité d’IA.
Trois problèmes que j’attends dans leur prochain article d’ingénierie
Problème 1 : Le plafond du serverless + séparation froid/chaud à grande échelle
Le choix actuel de Notion est un bon compromis pour sa charge de travail actuelle : des millions d’espaces de travail, dont la plupart sont interrogés peu fréquemment, où l’économie native de S3 est avantageuse. La limite est que les plafonds de performance ici sont davantage fixés par le comportement du stockage objet que par des réglages logiciels ajustables.
La latence au premier octet de S3 se situe souvent dans la plage de 10 à 100 ms. Un index froid peut nécessiter plusieurs requêtes GET et une désérialisation avant d’être interrogeable. En production, le p99 des requêtes à froid peut atteindre plusieurs secondes. Ce n’est généralement pas un problème de modèle ; c’est un problème de préchauffage de l’index.
Les principaux points de douleur sont prévisibles.
- Premièrement, les grands tenants avec un volume de requêtes élevé et soutenu commencent à ressentir les limites de la mise en cache à un seul niveau.
- Deuxièmement, les utilisateurs revenant à des espaces de travail froids peuvent observer des pics de latence notables. La mise en cache multiniveau (mémoire + SSD local + stockage objet) modifie cette forme de queue de distribution d’une manière que les conceptions à un seul niveau ne peuvent généralement pas reproduire.
Le modèle de facturation peut également surprendre les équipes : une tarification basée sur la taille de l’espace de noms plutôt que sur la charge de travail des requêtes signifie que les grands espaces de travail peuvent sembler coûteux, même lorsque les requêtes individuelles analysent de petits sous-ensembles. Dans les distributions multi-locataires déséquilibrées, les dépenses peuvent diverger de l’intuition au niveau des requêtes.
Le rappel des filtres est un autre problème latent pour les approches ANN-plus-post-filtrage. Lorsque les filtres sont étroits — type de page, collaborateur, plage temporelle — les pools de candidats peuvent devenir trop petits, entraînant une baisse du rappel. À mesure que Notion ajoute davantage de chemins de récupération IA filtrés, ce compromis tend à apparaître plus souvent.
Donc oui, le compromis actuel est bon. Les limites sont simplement claires : les grands locataires et la latence des requêtes à froid deviennent les premières fissures.
Problème 2 : La séparation temps réel/hors ligne devient de plus en plus coûteuse
La pile actuelle de Notion : Spark + Airflow pour le traitement par lots hors ligne, des consommateurs Kafka pour les mises à jour en temps réel, Ray pour l’embedding, Turbopuffer pour les requêtes. Quatre systèmes, chacun faisant bien son travail, tous opérant sur les mêmes données sous-jacentes — le contenu des pages des utilisateurs.
C’est la structure de silo de données dans sa forme classique. Les mêmes données sources sont maintenues sous forme de vues multiples par différents systèmes, avec une logique de couche applicative chargée de les garder synchronisées. Le xxHash + DynamoDB de Page State existe précisément pour maintenir la cohérence entre la vue de traitement par lots et la vue en temps réel. Cette logique est correcte, mais sa complexité évolue linéairement avec le nombre de fonctionnalités d’IA — chaque nouvelle fonctionnalité ajoute un autre ensemble de logique de synchronisation qui doit être maintenu à travers les chemins temps réel et hors ligne.
Le problème plus profond : le traitement hors ligne ne peut pas améliorer directement le service en ligne sans une étape de synchronisation. Si le pipeline hors ligne de Notion découvre de fortes relations sémantiques entre des documents dans un espace de travail, ces relations ne peuvent pas améliorer la récupération pour les questions-réponses IA tant que les résultats ne sont pas écrits quelque part où la logique de requête en ligne peut les lire. Il y a une frontière système entre les deux, avec une latence et un risque de cohérence associés.
C’est ce qui rend difficile l’activation de la boucle de données : les signaux générés par l’usage en ligne ne peuvent pas améliorer continuellement les modèles hors ligne sans franchir une frontière système dans les deux directions.
La réponse architecturale est OneData : le service en ligne et le traitement hors ligne partagent la même table sous-jacente. Pas de vues multiples à synchroniser, pas de logique de cohérence au niveau applicatif. Une table Iceberg, différents modes de calcul, lisant et écrivant au même endroit. La couche hors ligne rend la couche en ligne plus intelligente ; la couche en ligne génère des signaux que la couche hors ligne traite. La boucle tourne sur une fondation unique.
Problème 3 : L’ingénierie du contexte hors ligne — là où le véritable avantage défensif se construit
Notion AI aujourd’hui : l’utilisateur pose une question → récupération en temps réel des fragments pertinents → envoi au LLM → retour de la réponse. Le plafond de qualité de ce pipeline est déterminé par ce qui se trouve dans l’index.
L’écart que comble l’ingénierie du contexte hors ligne n’est pas la qualité de la récupération au moment de la requête — c’est la qualité de ce que vous avez construit avant que la requête n’arrive.
Mémoire. Chaque conversation avec Notion AI contient un signal : ce qui importe à l’utilisateur, sa façon de travailler, les connaissances qui comptent pour lui. Vectoriser ce signal et l’organiser en mémoire utilisateur récupérable est simple. La maintenir ne l’est pas : les anciens souvenirs nécessitent une compression (une conversation datant de six mois doit devenir une représentation plus dense), les souvenirs obsolètes doivent être mis à jour (lorsque du nouveau contenu contredit d’anciens enregistrements), et les souvenirs liés doivent être organisés hiérarchiquement. Tout cela relève d’un traitement par lots hors ligne continu sur des données vectorielles. Cela ne peut pas être fait au moment de la requête.
Graphes de connaissances précalculés. Plutôt que de rechercher à chaque fois « quels documents sont pertinents pour cette requête », un traitement hors ligne peut construire un modèle de la topologie sémantique de l’espace de travail — quels documents traitent des mêmes concepts, quelles décisions ont des dépendances, comment les idées ont évolué au fil du temps. Ce modèle devient le contexte dont l’IA dispose déjà, de sorte qu’elle raisonne à partir d’une compréhension de votre espace de travail plutôt que d’effectuer une nouvelle recherche à partir de zéro.
Le volant d’inertie des données. Quels résultats de récupération ont été utilisés ? Quelles questions reviennent sans cesse sans réponses satisfaisantes ? Quels documents sont référencés à plusieurs reprises dans différentes requêtes ? Ces signaux, traités hors ligne, peuvent affiner en continu la récupération — en ajustant les stratégies de découpage, en faisant remonter les connaissances qui se révèlent sans cesse pertinentes et en identifiant les angles morts. Le volant d’inertie ne tourne que s’il existe une infrastructure permettant de traduire les signaux en améliorations dans la couche vectorielle. Sans cela, les signaux ne sont que des octets dans un fichier journal.
Notion repose sur l’un des jeux de données d’IA les plus intéressants qui existent : des connaissances structurées, délibérément organisées, à travers des dizaines de millions d’espaces de travail. C’est une matière première extraordinaire. Mais un moat de données ne se construit pas en possédant des données — il se construit en disposant d’une infrastructure qui transforme continuellement les données en capacité. Leur infrastructure vectorielle actuelle est conçue pour la mise à disposition en ligne. Maintenance de la mémoire, précalcul de graphes de connaissances, volants d’inertie de traitement des signaux — ce sont des problèmes de traitement par lots à grande échelle qui n’ont pas de place naturelle dans l’architecture actuelle.
Positionnement de Lakebase
À ce stade, le schéma est clair. Le prochain goulot d’étranglement n’est pas une décision liée à un seul moteur de requête. C’est l’écart entre la mise à disposition en temps réel et le traitement hors ligne.
Vector Lakebase se positionne comme le pont :
Une plateforme unifiée pour l’OLTP et l’OLAP : la mise à disposition en temps réel, l’exploration itérative et l’analyse par lots s’exécutent sur la même fondation de données native du lakehouse et une source unique de vérité.
Un flux incrémental unique au lieu d’une synchronisation à double chemin. La capture des changements, la régénération des embeddings et la réindexation deviennent des capacités de la couche de données, et non du code de liaison applicatif.
Un seul endroit où l’intelligence hors ligne arrive en ligne. La compression de la mémoire, les backfills et les signaux de qualité réécrivent dans la même table et améliorent directement la mise à disposition.
Voilà le Chapitre 2 pratique : pas seulement une meilleure recherche, mais un modèle d’exploitation unifié pour les données vectorielles.
Vector Lakebase est la réponse de Zilliz Cloud au Chapitre 2 : stockage, traitement et mise à disposition vectoriels unifiés sur votre lac de données existant. Aucune migration requise. Restez à l’écoute.
Continuer à lire
We spent 8 years making vector databases faster. Then we stopped.
Rarely queried embeddings still need to stay searchable. See how Vector Lakebase enables on-demand vector search without always-on compute costs.
The AWS Outage Was a Wake-Up Call for Vector Database Cross-Region Disaster Recovery
Zilliz Cloud Had the Answer Before the Crisis. Zilliz Cloud is the world's first vector database with native cross-region disaster recovery.
DeepRAG: Thinking to Retrieval Step by Step for Large Language Models
Discover DeepRAG, an advanced retrieval-augmented generation (RAG) model that improves LLM accuracy by retrieving only essential data through step-by-step reasoning.