La búsqueda vectorial de Notion es excelente. Su próximo problema es más difícil.
Leyendo "Dos años de búsqueda vectorial en Notion" — y lo que predice sobre lo que viene después
Notion publicó un artículo de ingeniería que cubre dos años de infraestructura de búsqueda vectorial. Lo leí con auténtica admiración y una fuerte sensación de déjà vu. Casi todos los problemas que describen, las migraciones que ejecutaron y las soluciones alternativas que construyeron tienen un paralelo cercano en la historia del big data. El big data tardó aproximadamente quince años en converger en su arquitectura a largo plazo.
Lo que más me llamó la atención no fue solo la calidad de la ejecución. Fue cuánto esfuerzo se dedicó a preocupaciones de nivel de plataforma que, en una arquitectura más completa, deberían residir en la infraestructura en lugar de en la ingeniería de producto.
Si tuviera que adivinar el título de su próximo artículo de ingeniería, podría ser "Cómo pasamos seis meses en una actualización del modelo de embeddings." O "Cómo migramos cien millones de espacios de trabajo a un nuevo espacio vectorial sin tiempo de inactividad." O "Cómo construimos ingeniería de contexto offline para darle memoria duradera a Notion AI."
Todo lo resuelto hasta ahora es el Capítulo 1. El Capítulo 2 es más difícil.
Lo que construyó Notion
La historia comienza en noviembre de 2023. Notion lanzó AI Q&A y casi de inmediato acumuló una lista de espera de millones de espacios de trabajo. Su base de datos vectorial se ejecutaba en clústeres de pods — almacenamiento y cómputo agrupados, particionados por ID de espacio de trabajo. En un mes, se estaban acercando a los límites de capacidad.
En lugar de reparticionar bajo tráfico en vivo, tomaron el camino pragmático: levantar nuevos clústeres de índices etiquetados con un ID de generación, dirigir los nuevos espacios de trabajo a generaciones nuevas y dejar los espacios de trabajo existentes en su lugar. Combinado con ajustes de Spark y Airflow, despejaron la lista de espera en cuatro meses. La capacidad de incorporación diaria aumentó 600 veces.
Ingeniería limpia bajo presión. El costo: lógica de enrutamiento multigeneración que los seguiría durante dos años.
Luego dos migraciones importantes:
Mayo de 2024 — de arquitectura de pods a serverless. El almacenamiento y el cómputo se desacoplan. Los costos bajaron un 50% de inmediato, y la complejidad del enrutamiento por generaciones se disolvió con ello — porque la capacidad ya no era un recurso finito que tuviera que planificarse con anticipación.
Desde finales de 2024 hasta principios de 2025 — de su proveedor serverless a turbopuffer. Sus datos estaban almacenados en un sistema de almacenamiento propietario de un proveedor, por lo que cambiar requirió una reindexación completa. También aprovecharon la oportunidad para actualizar su modelo de embeddings.
Mediados de 2025: lanzaron Page State. Cada fragmento de texto se hashea con xxHash (64-bit) y se almacena en DynamoDB. Cuando una página se actualiza, el sistema compara hashes antes de decidir si volver a generar embeddings. Si solo cambiaron los metadatos, parchea directamente la base de datos vectorial sin recomputar el vector.
Poco después, la generación de embeddings pasó de Spark + API externa a modelos autoalojados en Ray via Anyscale. El preprocesamiento en CPU y la inferencia en GPU ahora se ejecutan en una sola canalización, eliminando la transferencia por S3 entre sistemas.
Dos años. Cinco grandes apuestas. Costos un 90% por debajo del pico. Es una trayectoria genuinamente impresionante.
Esta es una historia que el big data ya contó
En cada paso, quería anotar con una marca temporal: el ecosistema de big data resolvió esto en [año]. No es una coincidencia. Las mismas restricciones producen los mismos movimientos arquitectónicos.
1. Separación de almacenamiento y cómputo y serverless: pagar por el trabajo, no por existir
Las dos migraciones de costos de Notion — de clústeres de pods a serverless, luego a una configuración serverless respaldada por almacenamiento de objetos — pueden leerse como un solo movimiento arquitectónico: dejar de pagar por la existencia de infraestructura y empezar a pagar por el trabajo real. Ya fuera que un espacio de trabajo se consultara activamente o permaneciera inactivo durante semanas, el modelo antiguo mantenía los clústeres en ejecución y facturando.
Visto así, el cambio clave es desacoplar el almacenamiento del cómputo: los índices viven en almacenamiento de objetos, las colecciones frías mantienen casi nada de cómputo, las colecciones calientes se cargan bajo demanda, y el gasto sigue mucho más de cerca el uso real. En big data, esto no fue solo un cambio de HDFS a S3; fue un movimiento más amplio desde la integración almacenamiento-cómputo hacia la separación almacenamiento-cómputo.
La secuencia importó: primero, el escalado independiente resolvió el dolor de la elasticidad y la planificación de capacidad; luego, el cómputo efímero más el almacenamiento de objetos persistente redujeron los costos de uso. El despliegue predeterminado de Hadoop colocaba juntos almacenamiento y cómputo por localidad de datos, lo que dificultaba el escalado independiente. Una vez que los datos se movieron a S3, los clústeres de Spark podían activarse por trabajo y apagarse después, mientras el almacenamiento seguía siendo persistente.
La compensación también es estructural. El acceso al almacenamiento de objetos establece un piso para la latencia de arranque en frío: múltiples solicitudes GET, deserialización y reconstrucción de índices. Esto no es tanto un problema de ajuste de parámetros como un problema de física del almacenamiento. Para la carga de trabajo actual de Notion, donde la mayoría de los espacios de trabajo se consultan con poca frecuencia, esta es una buena compensación. Pero a medida que el uso de IA se profundiza, dos límites se vuelven más difíciles de ignorar: grandes tenants con un alto volumen sostenido de consultas, y usuarios que regresan a espacios de trabajo fríos donde la latencia de cola se vuelve visible para el usuario. En ese punto, el caching nativo de S3 de una sola capa suele ser insuficiente; mantener datos templados en SSDs locales se vuelve materialmente más importante.
2. Arquitectura Lambda: el tiempo real es la necesidad, la fragmentación es el costo
El sistema de indexación de Notion ejecuta dos rutas: un pipeline offline de Spark para backfill a gran escala, y consumidores de Kafka para actualizaciones en tiempo real. Esta es una configuración Lambda clásica.
Si te importa la frescura de los datos, este diseño es un punto de partida natural. El problema es lo que ocurre después: la misma lógica empieza a dispersarse entre múltiples sistemas, y los equipos pasan más tiempo manteniendo las rutas consistentes.
En el caso de Notion, esa división ahora abarca Spark, consumidores de Kafka, DynamoDB para Page State, Ray para embedding, y una capa de serving separada.
Cada componente está haciendo el trabajo correcto. El impuesto oculto es la superficie de integración:
- más código de pegamento
- más traspaso de estado
- más posibilidades de deriva entre el comportamiento offline y online
Gran parte de esto se amplifica por el almacenamiento cerrado para serving. La migración de proveedor implica una reindexación completa. El soporte de actualizaciones parciales implica tablas externas de seguimiento. Las mejoras offline no ayudan a la recuperación online hasta que se completa otro paso de sincronización.
El núcleo de Kappa es simple: un modelo de procesamiento. La forma más fuerte es One Engine: batch y streaming como dos modos de un solo sistema, no dos sistemas pegados.
Ahí es exactamente donde encaja Lakebase. Lleva esta idea de One Engine a una base nativa de lake, cerrando la brecha OLTP/OLAP para que las actualizaciones en tiempo real, el serving online y el procesamiento offline se ejecuten sobre una sola tabla.
3. La capa faltante: una interfaz declarativa para operaciones vectoriales
El paso de Spark + una API externa de embedding a un pipeline Ray unificado es la decisión correcta — colapsar dos sistemas que se comunicaban vía S3 en un único grafo de cómputo es una simplificación real, y la reducción proyectada de más del 90% en costos de embedding refleja una mejora arquitectónica genuina. Pero es una simplificación en el nivel del cableado de infraestructura, y lo que aún falta es una en el nivel semántico.
En la era de Hadoop, hacer cualquier cosa con datos significaba escribir trabajos MapReduce: tenías que entender el ciclo de vida de Mapper y Reducer, cómo funcionaba el shuffle, cómo manejar fallos y cómo encadenar etapas. Hive añadió una capa declarativa: expresas qué resultado quieres en SQL, y el sistema averigua cómo convertir eso en ejecución MapReduce. Ese cambio no solo hizo las cosas más rápidas; cambió quién podía trabajar con datos en absoluto, e hizo que el costo de ingeniería de una nueva operación de datos se acercara mucho más al costo de escribir una consulta que al costo de escribir un sistema distribuido.
Sin embargo, los datos vectoriales y no estructurados aún no tienen esta capa.
- Si quieres deduplicar un corpus de mil millones de vectores antes de una ejecución de entrenamiento de modelo, escribes jobs de Spark, eliges los operadores adecuados de cálculo de distancia, gestionas los formatos de salida y averiguas cómo devolver los resultados a donde sea que viva tu capa de serving.
- Si quieres actualizar de un modelo de embeddings a uno más nuevo en cientos de millones de documentos, construyes un pipeline de backfill, gestionas la coexistencia de embeddings antiguos y nuevos durante el cutover, y limpias después — y este proceso es un proyecto de ingeniería de varios meses en lugar de una operación rutinaria.
- Si quieres mantener memoria de usuario comprimida entre sesiones, diseñas la lógica de compresión, gestionas escrituras versionadas y conectas manualmente la salida con la ruta de recuperación. Cada una de estas cosas es un proyecto de ingeniería de sistemas en lugar de una operación de datos.
El equivalente declarativo sería expresar la intención — "deduplicar esta colección con tolerancia coseno 0.05 y escribir los resultados de vuelta," "hacer backfill de embeddings usando este nuevo modelo," "comprimir el historial de interacción de más de 90 días en representaciones de memoria densas" — y hacer que el sistema se encargue de la planificación de ejecución, la gestión de recursos y la consistencia. Esa es la capa que hace que Context Engineering sea manejable a escala en lugar de un proyecto de ingeniería a medida cada vez. Y todavía falta en gran medida en las pilas actuales de infraestructura vectorial, independientemente del backend de serving.
| La decisión de Notion | Patrón arquitectónico |
|---|---|
| Clústeres pod → serverless → serverless respaldado por almacenamiento de objetos | Separación almacenamiento-cómputo: desacoplamiento del ciclo de vida aplicado a índices vectoriales |
| Indexación de doble ruta + Page State + enrutamiento por generación | Diseño Lambda con prioridad en tiempo real: frescura rápida, pero coste de sincronización creciente entre rutas online/offline |
| Spark + handoff de S3 → Ray | Colapso de I/O entre sistemas — pero la capa de interfaz declarativa por encima de ello aún falta |
Big data tardó 15 años en converger en una arquitectura en la que almacenamiento, cómputo y semánticas de procesamiento estuvieran limpiamente separados y fueran componibles. Notion ha recorrido la mayor parte de ese arco en dos años, lo cual es genuinamente impresionante. La pieza que aún no ha aterrizado es la que haría que los próximos dos años fueran sustancialmente más baratos de construir.
Pero esto es solo el capítulo uno
Todo lo que Notion ha resuelto es la infraestructura para una función de IA.
Toda esta ingeniería — enrutamiento por generación, migraciones de proveedores, Page State, unificación de cómputo con Ray — existe para hacer que AI Q&A funcione bien, de forma barata y fiable. Lo han logrado. La infraestructura para esta única función ahora es madura. Notion no va a lanzar una sola función de IA.
Tres problemas que espero en su próximo post de ingeniería
Problema 1: El techo de serverless + separación frío/caliente a escala
La elección actual de Notion es un buen equilibrio para su carga de trabajo actual: millones de workspaces, la mayoría de los cuales se consultan con poca frecuencia, donde la economía nativa de S3 es sólida. El límite es que los techos de rendimiento aquí están determinados más por el comportamiento del almacenamiento de objetos que por knobs de software ajustables.
La latencia de primer byte de S3 suele estar en el rango de 10-100 ms. Un índice frío puede requerir múltiples solicitudes GET y deserialización antes de poder consultarse. En producción, el p99 de consultas frías puede alcanzar rangos de varios segundos. Eso normalmente no es un problema del modelo; es calentamiento del índice.
Los principales puntos de dolor son previsibles.
- Primero, los tenants grandes con alto volumen de consultas sostenido empiezan a sentir los límites del caching de un solo nivel.
- Segundo, los usuarios que vuelven a workspaces fríos pueden ver picos de latencia notables. El caching multinivel (memoria + SSD local + almacenamiento de objetos) cambia esta forma de cola de maneras que los diseños de un solo nivel normalmente no pueden.
El modelo de facturación también puede sorprender a los equipos: cobrar por tamaño de namespace en lugar de por carga de trabajo de consultas significa que los espacios de trabajo grandes pueden parecer caros incluso cuando las consultas individuales escanean subconjuntos pequeños. En distribuciones multi-tenant sesgadas, el gasto puede divergir de la intuición a nivel de consulta.
El recall de filtros es otro problema latente para los enfoques de ANN más posfiltro. Cuando los filtros son estrechos — tipo de página, colaborador, intervalo de tiempo — los conjuntos de candidatos pueden volverse demasiado pequeños, lo que conduce a una caída del recall. A medida que Notion añade más rutas de recuperación de IA filtradas, este trade-off tiende a aparecer con más frecuencia.
Así que sí, el trade-off actual es bueno. Los límites simplemente están claros: los grandes tenants y la latencia de consultas en frío se convierten en las primeras grietas.
Problema 2: La separación entre tiempo real y offline se vuelve cada vez más cara
Stack actual de Notion: Spark + Airflow para procesamiento batch offline, consumidores de Kafka para actualizaciones en tiempo real, Ray para embeddings, Turbopuffer para consultas. Cuatro sistemas, cada uno haciendo bien su trabajo, todos operando sobre los mismos datos subyacentes: el contenido de las páginas de los usuarios.
Esta es la estructura de silos de datos en su forma clásica. Los mismos datos fuente se mantienen como múltiples vistas por diferentes sistemas, con lógica en la capa de aplicación responsable de mantenerlas sincronizadas. El xxHash + DynamoDB de Page State existe específicamente para mantener la consistencia entre la vista de procesamiento batch y la vista en tiempo real. Esa lógica es correcta, pero su complejidad escala linealmente con el número de funciones de IA: cada nueva función añade otro conjunto de lógica de sincronización que debe mantenerse en las rutas real y offline.
El problema más profundo: el procesamiento offline no puede mejorar directamente el serving online sin un paso de sincronización. Si el pipeline offline de Notion descubre relaciones semánticas fuertes entre documentos en un espacio de trabajo, esas relaciones no pueden mejorar la recuperación de AI Q&A hasta que los resultados se escriban en algún lugar que la lógica de consulta online pueda leer. Hay un límite del sistema de por medio, con latencia y riesgo de consistencia asociados.
Esto es lo que hace que el volante de datos sea difícil de hacer girar: las señales generadas por el uso online no pueden mejorar continuamente los modelos offline sin cruzar un límite del sistema en ambas direcciones.
La respuesta arquitectónica es OneData: el serving online y el procesamiento offline comparten la misma tabla subyacente. Sin múltiples vistas que sincronizar, sin lógica de consistencia en la capa de aplicación. Una tabla Iceberg, distintos modos de cómputo, leyendo y escribiendo en el mismo lugar. La capa offline hace más inteligente a la capa online; la capa online genera señales que la capa offline procesa. El volante funciona sobre una única base.
Problema 3: Ingeniería de contexto offline: donde se construye el verdadero moat
Notion AI hoy: el usuario hace una pregunta → recupera chunks relevantes en tiempo real → los pasa al LLM → devuelve la respuesta. El techo de calidad de este pipeline está determinado por lo que hay en el índice.
La brecha que cubre la ingeniería de contexto offline no es la calidad de recuperación en tiempo de consulta, sino la calidad de lo que has construido antes de que llegue la consulta.
Memoria. Cada conversación con Notion AI contiene una señal: lo que le importa al usuario, cómo trabaja, qué conocimiento es importante para él. Vectorizar esa señal y organizarla en memoria de usuario recuperable es sencillo. Mantenerla no lo es: los recuerdos antiguos necesitan compresión (una conversación de hace seis meses debe convertirse en una representación más densa), los recuerdos obsoletos necesitan actualización (cuando el contenido nuevo contradice registros antiguos) y los recuerdos relacionados deben organizarse jerárquicamente. Todo esto es procesamiento batch offline continuo sobre datos vectoriales. No puede hacerse en tiempo de consulta.
Grafos de conocimiento precomputados. En lugar de buscar “qué documentos son relevantes para esta consulta” desde cero cada vez, el procesamiento offline puede construir un modelo de la topología semántica del espacio de trabajo: qué documentos abordan los mismos conceptos, qué decisiones tienen dependencias, cómo han evolucionado las ideas a lo largo del tiempo. Ese modelo se convierte en el contexto que la IA ya tiene, de modo que razona a partir de una comprensión de tu espacio de trabajo en lugar de realizar una nueva búsqueda desde cero.
El volante de datos. ¿Qué resultados de recuperación se usaron? ¿Qué preguntas siguen apareciendo sin respuestas satisfactorias? ¿Qué documentos se referencian repetidamente en distintas consultas? Estas señales, procesadas offline, pueden ajustar continuamente la recuperación: modificando estrategias de fragmentación, poniendo en primer plano conocimiento que sigue demostrando ser relevante e identificando puntos ciegos. El volante solo gira si existe infraestructura para traducir señales en mejoras en la capa vectorial. Sin eso, las señales son solo bytes en un archivo de registro.
Notion se asienta sobre uno de los conjuntos de datos de IA más interesantes que existen: conocimiento estructurado, organizado deliberadamente, en decenas de millones de espacios de trabajo. Es una materia prima extraordinaria. Pero un foso de datos no se construye por tener datos: se construye por tener infraestructura que convierte continuamente los datos en capacidad. Su infraestructura vectorial actual está diseñada para el servicio online. Mantenimiento de memoria, precomputación de grafos de conocimiento, volantes de procesamiento de señales: estos son problemas por lotes a gran escala que no tienen un lugar natural en la arquitectura actual.
Posicionamiento de Lakebase
En este punto, el patrón está claro. El próximo cuello de botella no es una única decisión sobre el motor de consultas. Es la brecha entre el servicio en tiempo real y el procesamiento offline.
Vector Lakebase se posiciona como el puente:
Una plataforma unificada para OLTP y OLAP: el servicio en tiempo real, el descubrimiento iterativo y la analítica por lotes se ejecutan sobre la misma base de datos nativa del lago y una única fuente de verdad.
Un único flujo incremental en lugar de sincronización de doble vía. La captura de cambios, el re-embedding y la reindexación se convierten en capacidades de la capa de datos, no en código de integración de aplicaciones.
Un único lugar donde la inteligencia offline se lleva al online. La compresión de memoria, los backfills y las señales de calidad escriben de vuelta en la misma tabla y mejoran directamente el servicio.
Ese es el Capítulo 2 práctico: no solo una mejor búsqueda, sino un modelo operativo unificado para datos vectoriales.
Vector Lakebase es la respuesta de Zilliz Cloud al Capítulo 2: almacenamiento, procesamiento y servicio vectoriales unificados sobre tu lago de datos existente. No se requiere migración. Mantente atento.
Sigue leyendo
How to Choose the Best Embedding Model for RAG in 2026: 10 Models Benchmarked
We benchmarked 10 embedding models on cross-modal, cross-lingual, long-document, and dimension compression tasks. See which one fits your RAG pipeline.
Our Journey to 35K+ GitHub Stars: The Real Story of Building Milvus from Scratch
Join us in celebrating Milvus, the vector database that hit 35.5K stars on GitHub. Discover our story and how we’re making AI solutions easier for developers.
Building RAG Pipelines for Real-Time Data with Cloudera and Milvus
explore how Cloudera can be integrated with Milvus to effectively implement some of the key functionalities of RAG pipelines.