A Pesquisa Vetorial do Notion É Excelente. O Próximo Problema Deles É Mais Difícil.
Lendo "Dois Anos de Busca Vetorial na Notion" — e o que isso prevê sobre o que vem a seguir
A Notion publicou um post de engenharia cobrindo dois anos de infraestrutura de busca vetorial. Li com admiração genuína e uma forte sensação de deja vu. Quase todo problema que eles descrevem, migração que executaram e solução alternativa que construíram tem um paralelo próximo na história de big data. Big data levou aproximadamente quinze anos para convergir para sua arquitetura de longo prazo.
O que mais me chamou a atenção não foi apenas a qualidade da execução. Foi quanto esforço foi dedicado a preocupações de nível de plataforma que, em uma arquitetura mais completa, deveriam viver na infraestrutura em vez de na engenharia de produto.
Se eu tivesse que adivinhar o título do próximo post de engenharia deles, poderia ser "Como passamos seis meses em uma atualização de modelo de embeddings." Ou "Como migramos cem milhões de workspaces para um novo espaço vetorial sem downtime." Ou "Como construímos engenharia de contexto offline para dar memória durável à Notion AI."
Tudo o que foi resolvido até agora é o Capítulo 1. O Capítulo 2 é mais difícil.
O que a Notion construiu
A história começa em novembro de 2023. A Notion lançou AI Q&A e quase imediatamente acumulou uma lista de espera de milhões de workspaces. Seu banco de dados vetorial rodava em clusters de pods — armazenamento e computação agrupados, particionados por ID de workspace. Em um mês, eles estavam se aproximando dos limites de capacidade.
Em vez de reparticionar sob tráfego ativo, eles seguiram o caminho pragmático: criar novos clusters de índice marcados com um ID de geração, rotear novos workspaces para gerações novas e deixar os workspaces existentes no lugar. Combinado com ajustes de Spark e Airflow, eles eliminaram a lista de espera em quatro meses. A capacidade diária de onboarding aumentou 600x.
Engenharia limpa sob pressão. O custo: lógica de roteamento multigeração que os acompanharia por dois anos.
Depois, duas grandes migrações:
Maio de 2024 — da arquitetura de pods para serverless. Armazenamento e computação são desacoplados. Os custos caíram 50% imediatamente, e a complexidade de roteamento por geração se dissolveu com isso — porque a capacidade deixou de ser um recurso finito que precisava ser planejado com antecedência.
Do fim de 2024 ao início de 2025 — do provedor serverless deles para turbopuffer. Os dados deles estavam armazenados em um sistema de armazenamento proprietário de um fornecedor, então a troca exigiu uma reindexação completa. Eles também aproveitaram a oportunidade para atualizar seu modelo de embeddings.
Meados de 2025: eles lançaram Page State. Cada trecho de texto é hasheado com xxHash (64-bit) e armazenado no DynamoDB. Quando uma página é atualizada, o sistema compara hashes antes de decidir se deve gerar o embedding novamente. Se apenas os metadados mudaram, ele aplica um patch diretamente no banco de dados vetorial sem recomputar o vetor.
Pouco depois, a geração de embeddings passou de Spark + API externa para modelos auto-hospedados no Ray via Anyscale. O pré-processamento em CPU e a inferência em GPU agora rodam em um único pipeline, eliminando a transferência via S3 entre sistemas.
Dois anos. Cinco grandes apostas. Custos 90% abaixo do pico. É uma trajetória genuinamente impressionante.
Esta é uma história que big data já contou
A cada etapa, eu ficava querendo anotar com um timestamp: o ecossistema de big data resolveu isso em [ano]. Não é coincidência. As mesmas restrições produzem os mesmos movimentos arquiteturais.
1. Separação de armazenamento e computação e serverless: pagar pelo trabalho, não pela existência
As duas migrações de custo da Notion — de clusters de pods para serverless, depois para uma configuração serverless apoiada em object storage — podem ser lidas como um único movimento arquitetural: parar de pagar pela existência da infraestrutura e começar a pagar pelo trabalho real. Quer um workspace fosse consultado ativamente ou ficasse ocioso por semanas, o modelo antigo mantinha clusters rodando e gerando cobrança.
Visto dessa forma, a mudança-chave é desacoplar armazenamento de computação: os índices ficam no armazenamento de objetos, coleções frias mantêm quase nenhuma computação, coleções quentes carregam sob demanda, e o gasto acompanha o uso real muito mais de perto. Em big data, isso não foi apenas uma troca de HDFS para S3; foi um movimento mais amplo da integração armazenamento-computação para a separação armazenamento-computação.
A sequência importou: primeiro, o escalonamento independente resolveu a dor da elasticidade e do planejamento de capacidade; depois, computação efêmera mais armazenamento de objetos persistente reduziu os custos de uso. A implantação padrão do Hadoop colocava armazenamento e computação juntos para localidade dos dados, o que tornava o escalonamento independente difícil. Uma vez que os dados migraram para S3, clusters Spark podiam ser iniciados por job e encerrados depois, enquanto o armazenamento permanecia persistente.
O trade-off também é estrutural. O acesso ao armazenamento de objetos estabelece um piso para a latência de inicialização a frio: múltiplas requisições GET, desserialização e reconstrução de índices. Isso não é tanto uma questão de ajuste de parâmetros quanto uma questão de física do armazenamento. Para a carga de trabalho atual do Notion, em que a maioria dos workspaces é consultada com pouca frequência, esse é um bom trade-off. Mas, à medida que o uso de IA se aprofunda, dois limites ficam mais difíceis de ignorar: grandes tenants com alto volume sustentado de consultas, e usuários retornando a workspaces frios onde a latência de cauda se torna visível para o usuário. Nesse ponto, cache S3-native de camada única muitas vezes é insuficiente; manter dados mornos em SSDs locais torna-se materialmente mais importante.
2. Arquitetura Lambda: Tempo Real É a Necessidade, Fragmentação É o Custo
O sistema de indexação do Notion executa dois caminhos: um pipeline Spark offline para backfill em larga escala, e consumidores Kafka para atualizações em tempo real. Esta é uma configuração Lambda clássica.
Se você se importa com frescor dos dados, esse design é um ponto de partida natural. O problema é o que acontece depois: a mesma lógica começa a se espalhar por múltiplos sistemas, e as equipes passam mais tempo mantendo os caminhos consistentes.
No caso do Notion, essa divisão agora abrange Spark, consumidores Kafka, DynamoDB para Page State, Ray para embedding, e uma camada de serving separada.
Cada componente está fazendo o trabalho certo. O imposto oculto é a superfície de integração:
- mais código de cola
- mais transferência de estado
- mais chances de desvio entre o comportamento offline e online
Muito disso é amplificado pelo armazenamento fechado para serving. Migração de provedor significa reindexação completa. Suporte a atualizações parciais significa tabelas externas de rastreamento. Melhorias offline não ajudam a recuperação online até que outra etapa de sincronização seja concluída.
O núcleo do Kappa é simples: um modelo de processamento. A forma mais forte é One Engine - batch e streaming como dois modos de um sistema, não dois sistemas colados.
É exatamente aí que o Lakebase se encaixa. Ele traz essa ideia de One Engine para uma base lake-native, preenchendo a lacuna OLTP/OLAP para que atualizações em tempo real, serving online e processamento offline rodem em uma única tabela.
3. A Camada Ausente: Uma Interface Declarativa para Operações Vetoriais
A mudança de Spark + uma API externa de embedding para um pipeline Ray unificado é a decisão certa — colapsar dois sistemas que se comunicavam via S3 em um único grafo de computação é uma simplificação real, e a redução projetada de mais de 90% nos custos de embedding reflete uma melhoria arquitetural genuína. Mas é uma simplificação no nível da fiação de infraestrutura, e o que ainda falta é uma no nível semântico.
Na era Hadoop, fazer qualquer coisa com dados significava escrever jobs MapReduce: você precisava entender o ciclo de vida do Mapper e do Reducer, como o shuffle funcionava, como lidar com falhas e como encadear estágios. O Hive adicionou uma camada declarativa — você expressa qual resultado quer em SQL, e o sistema descobre como transformar isso em execução MapReduce. Essa mudança não apenas tornou as coisas mais rápidas; ela mudou quem podia trabalhar com dados, e tornou o custo de engenharia de uma nova operação de dados muito mais próximo do custo de escrever uma consulta do que do custo de escrever um sistema distribuído.
No entanto, dados vetoriais e não estruturados ainda não têm essa camada.
- Se você quiser deduplicar um corpus de um bilhão de vetores antes de uma rodada de treinamento de modelo, você escreve jobs Spark, escolhe os operadores corretos de computação de distância, gerencia formatos de saída e descobre como alimentar os resultados de volta para onde quer que sua camada de serving esteja.
- Se você quiser fazer upgrade de um modelo de embeddings para um mais novo em centenas de milhões de documentos, você constrói um pipeline de backfill, gerencia embeddings antigos e novos coexistindo durante o cutover e faz a limpeza depois — e esse processo é um projeto de engenharia de vários meses, em vez de uma operação rotineira.
- Se você quiser manter memória de usuário comprimida entre sessões, você projeta a lógica de compressão, gerencia escritas versionadas e conecta manualmente a saída ao caminho de recuperação. Cada um desses é um projeto de engenharia de sistemas, em vez de uma operação de dados.
O equivalente declarativo seria expressar a intenção — "deduplicar esta coleção com tolerância de cosseno 0,05 e gravar os resultados de volta", "fazer backfill de embeddings usando este novo modelo", "comprimir histórico de interação com mais de 90 dias em representações densas de memória" — e deixar que o sistema cuide do planejamento de execução, gerenciamento de recursos e consistência. Essa é a camada que torna a Engenharia de Contexto tratável em escala, em vez de um projeto de engenharia customizado a cada vez. E ela ainda está em grande parte ausente das stacks atuais de infraestrutura vetorial, independentemente do backend de serving.
| Decisão da Notion | Padrão arquitetural |
|---|---|
| Clusters de pods → serverless → serverless apoiado por armazenamento de objetos | Separação entre armazenamento e computação: desacoplamento de ciclo de vida aplicado a índices vetoriais |
| Indexação de caminho duplo + Page State + roteamento de geração | Design Lambda priorizando tempo real: frescor rápido, mas custo crescente de sincronização entre caminhos online/offline |
| Handoff Spark + S3 → Ray | Colapso de I/O entre sistemas — mas a camada de interface declarativa acima disso ainda está ausente |
Big data levou 15 anos para convergir para uma arquitetura em que armazenamento, computação e semântica de processamento fossem claramente separados e componíveis. A Notion percorreu a maior parte desse arco em dois anos, o que é genuinamente impressionante. A peça que ainda não se consolidou é aquela que tornaria os próximos dois anos substancialmente mais baratos de construir.
Mas Este É Apenas o Primeiro Capítulo
Tudo o que a Notion resolveu é a infraestrutura para um recurso de IA.
Toda essa engenharia — roteamento de geração, migrações de provedores, Page State, unificação de computação com Ray — existe para fazer o AI Q&A funcionar bem, de forma barata e confiável. Eles conseguiram. A infraestrutura para esse único recurso agora está madura. A Notion não vai lançar apenas um recurso de IA.
Três Problemas que Espero no Próximo Post de Engenharia Deles
Problema 1: O teto de serverless + separação cold/hot em escala
A escolha atual da Notion é uma boa troca para sua carga de trabalho atual: milhões de workspaces, a maioria consultada com pouca frequência, onde a economia nativa de S3 é forte. O limite é que os tetos de desempenho aqui são definidos mais pelo comportamento do armazenamento de objetos do que por knobs de software ajustáveis.
A latência até o primeiro byte do S3 costuma ficar na faixa de 10-100ms. Um índice cold pode exigir múltiplas requisições GET e desserialização antes de poder ser consultado. Em produção, o p99 de consultas cold pode chegar a faixas de vários segundos. Isso normalmente não é um problema de modelo; é aquecimento de índice.
Os principais pontos de dor são previsíveis.
- Primeiro, grandes tenants com volume de consultas alto e sustentado começam a sentir os limites do cache de camada única.
- Segundo, usuários retornando a workspaces cold podem perceber picos de latência notáveis. Cache multinível (memória + SSD local + armazenamento de objetos) muda esse formato da cauda de maneiras que designs de camada única normalmente não conseguem.
O modelo de cobrança também pode surpreender equipes: cobrar pelo tamanho do namespace, em vez da carga de consultas, significa que grandes workspaces podem parecer caros mesmo quando consultas individuais varrem pequenos subconjuntos. Em distribuições multi-tenant enviesadas, o gasto pode divergir da intuição em nível de consulta.
A revocação de filtros é outro problema latente para abordagens ANN-plus-post-filter. Quando os filtros são estreitos — tipo de página, colaborador, intervalo de tempo — os pools de candidatos podem se tornar pequenos demais, levando a uma queda na revocação. À medida que o Notion adiciona mais caminhos de recuperação de IA filtrados, esse trade-off tende a aparecer com mais frequência.
Então, sim, o trade-off atual é bom. Os limites simplesmente estão claros: grandes tenants e latência de consultas frias se tornam as primeiras rachaduras.
Problema 2: A divisão real-time/offline continua ficando mais cara
A stack atual do Notion: Spark + Airflow para processamento em batch offline, consumidores Kafka para atualizações em tempo real, Ray para embeddings, Turbopuffer para consultas. Quatro sistemas, cada um fazendo bem seu trabalho, todos operando sobre os mesmos dados subjacentes — o conteúdo das páginas dos usuários.
Esta é a estrutura de silos de dados em sua forma clássica. Os mesmos dados de origem são mantidos como múltiplas visualizações por diferentes sistemas, com a lógica na camada de aplicação responsável por mantê-las sincronizadas. O xxHash + DynamoDB do Page State existe especificamente para manter a consistência entre a visualização de processamento em batch e a visualização em tempo real. Essa lógica está correta, mas sua complexidade escala linearmente com o número de recursos de IA — cada novo recurso adiciona outro conjunto de lógica de sincronização que precisa ser mantido entre os caminhos real e offline.
O problema mais profundo: o processamento offline não consegue melhorar diretamente o serving online sem uma etapa de sincronização. Se o pipeline offline do Notion descobre relações semânticas fortes entre documentos em um workspace, essas relações não podem melhorar a recuperação de Q&A de IA até que os resultados sejam gravados em algum lugar que a lógica de consulta online consiga ler. Há uma fronteira de sistema no meio, com latência e risco de consistência associados.
É isso que torna difícil fazer o flywheel de dados girar: sinais gerados pelo uso online não conseguem melhorar continuamente modelos offline sem cruzar uma fronteira de sistema em ambas as direções.
A resposta arquitetural é OneData: serving online e processamento offline compartilham a mesma tabela subjacente. Sem múltiplas visualizações para sincronizar, sem lógica de consistência na camada de aplicação. Uma tabela Iceberg, diferentes modos de computação, lendo e escrevendo no mesmo lugar. A camada offline torna a camada online mais inteligente; a camada online gera sinais que a camada offline processa. O flywheel roda sobre uma única base.
Problema 3: Engenharia de contexto offline — onde o verdadeiro fosso defensivo é construído
Notion AI hoje: o usuário faz uma pergunta → recupera chunks relevantes em tempo real → envia ao LLM → retorna a resposta. O teto de qualidade desse pipeline é determinado pelo que está no índice.
A lacuna que a engenharia de contexto offline preenche não é a qualidade da recuperação no momento da consulta — é a qualidade do que você construiu antes de a consulta chegar.
Memória. Toda conversa com o Notion AI contém um sinal: o que importa para o usuário, como ele trabalha, qual conhecimento é relevante para ele. Vetorizar esse sinal e organizá-lo em memória de usuário recuperável é simples. Mantê-lo não é: memórias antigas precisam de compressão (uma conversa de seis meses atrás precisa se tornar uma representação mais densa), memórias obsoletas precisam ser atualizadas (quando novo conteúdo contradiz registros antigos), e memórias relacionadas precisam ser organizadas hierarquicamente. Tudo isso é processamento contínuo em batch offline sobre dados vetoriais. Não pode ser feito no momento da consulta.
Grafos de conhecimento pré-computados. Em vez de pesquisar “quais documentos são relevantes para esta consulta” do zero todas as vezes, o processamento offline pode construir um modelo da topologia semântica do workspace — quais documentos abordam os mesmos conceitos, quais decisões têm dependências, como as ideias evoluíram ao longo do tempo. Esse modelo se torna o contexto que a IA já tem, de modo que ela raciocina a partir de uma compreensão do seu workspace, em vez de fazer uma nova busca do zero.
O volante de dados. Quais resultados de recuperação foram usados? Quais perguntas continuam surgindo sem respostas satisfatórias? Quais documentos são referenciados repetidamente em diferentes consultas? Esses sinais, processados offline, podem ajustar continuamente a recuperação — adaptando estratégias de chunking, destacando conhecimento que continua se mostrando relevante e identificando pontos cegos. O volante só gira se houver infraestrutura para traduzir sinais em melhorias na camada vetorial. Sem isso, os sinais são apenas bytes em um arquivo de log.
O Notion está sobre um dos conjuntos de dados de IA mais interessantes que existem: conhecimento estruturado, deliberadamente organizado, em dezenas de milhões de workspaces. Isso é uma matéria-prima extraordinária. Mas um fosso de dados não é construído por ter dados — ele é construído por ter infraestrutura que transforma continuamente dados em capacidade. A infraestrutura vetorial atual deles é projetada para serving online. Manutenção de memória, pré-computação de grafos de conhecimento, volantes de processamento de sinais — estes são problemas de batch em larga escala que não têm um lugar natural na arquitetura atual.
Posicionamento do Lakebase
Neste ponto, o padrão está claro. O próximo gargalo não é uma decisão sobre um único mecanismo de consulta. É a lacuna entre serving em tempo real e processamento offline.
Vector Lakebase está posicionado como a ponte:
Uma plataforma unificada para OLTP e OLAP: serving em tempo real, descoberta iterativa e análises em batch rodam sobre a mesma base de dados lake-native e uma única fonte da verdade.
Um único fluxo incremental em vez de sincronização de caminho duplo. Captura de alterações, re-embedding e re-indexing tornam-se capacidades da camada de dados, não código de integração da aplicação.
Um único lugar onde a inteligência offline chega ao online. Compressão de memória, backfills e sinais de qualidade gravam de volta na mesma tabela e melhoram diretamente o serving.
Esse é o Capítulo 2 prático: não apenas uma busca melhor, mas um modelo operacional unificado para dados vetoriais.
Vector Lakebase é a resposta da Zilliz Cloud ao Capítulo 2: armazenamento, processamento e serving vetoriais unificados no seu data lake existente. Nenhuma migração necessária. Fique atento.
Continue lendo
A Developer's Guide to Exploring Milvus 2.6 Features on Zilliz Cloud
Milvus 2.6 marks a shift from “vector search + glue code” to a more advanced retrieval engine, and it is now Generally Available (GA) on Zilliz Cloud (a managed Milvus service).
Expanding Our Global Reach: Zilliz Cloud Launches in Azure Central India
Zilliz Cloud expands to Azure Central India. This new region helps customers meet compliance, reduce latency, and optimize cloud costs when building AI applications.
Vector Databases vs. Key-Value Databases
Use a vector database for AI-powered similarity search; use a key-value database for high-throughput, low-latency simple data lookups.