Векторный поиск Notion превосходен. Их следующая проблема сложнее.
Чтение «Two Years of Vector Search at Notion» — и что это предсказывает о том, что будет дальше
Notion опубликовал инженерный пост о двух годах инфраструктуры векторного поиска. Я прочитал его с искренним восхищением и сильным ощущением дежавю. Почти каждая проблема, которую они описывают, каждая миграция, которую они провели, и каждый обходной путь, который они построили, имеют близкую параллель в истории больших данных. Большим данным потребовалось примерно пятнадцать лет, чтобы сойтись к своей долгосрочной архитектуре.
Больше всего меня поразило не только качество исполнения. А то, сколько усилий ушло на платформенные вопросы, которые в более полной архитектуре должны находиться в инфраструктуре, а не в продуктовой инженерии.
Если бы мне пришлось угадывать заголовок их следующего инженерного поста, это могло бы быть «Как мы потратили шесть месяцев на обновление embedding-модели». Или «Как мы мигрировали сто миллионов рабочих пространств в новое векторное пространство без простоя». Или «Как мы построили offline context engineering, чтобы дать Notion AI долговременную память».
Всё, что решено на данный момент, — это глава 1. Глава 2 сложнее.
Что построил Notion
История начинается в ноябре 2023 года. Notion запустил AI Q&A и почти сразу накопил список ожидания из миллионов рабочих пространств. Их векторная база данных работала на pod-кластерах — хранилище и вычисления были связаны вместе, с шардированием по ID рабочего пространства. В течение месяца они начали приближаться к пределам ёмкости.
Вместо того чтобы выполнять решардинг под живым трафиком, они выбрали прагматичный путь: поднять новые индексные кластеры, помеченные generation ID, направлять новые рабочие пространства в свежие поколения и оставить существующие рабочие пространства на месте. В сочетании с настройкой Spark и Airflow это позволило им разгрузить список ожидания за четыре месяца. Ежедневная пропускная способность онбординга выросла в 600 раз.
Чистая инженерия под давлением. Цена: логика маршрутизации между поколениями, которая сопровождала их два года.
Затем две крупные миграции:
Май 2024 — от pod-архитектуры к serverless. Хранилище и вычисления разделены. Затраты сразу снизились на 50%, а сложность маршрутизации по поколениям исчезла вместе с этим — потому что ёмкость больше не была конечным ресурсом, который нужно было планировать заранее.
С конца 2024 по начало 2025 — от их serverless-провайдера к turbopuffer. Их данные хранились в проприетарной системе хранения поставщика, поэтому переключение потребовало полной переиндексации. Они также использовали эту возможность, чтобы обновить embedding-модель.
Середина 2025: они выпустили Page State. Каждый текстовый фрагмент хешируется с помощью xxHash (64-bit) и хранится в DynamoDB. Когда страница обновляется, система сравнивает хеши, прежде чем решить, нужно ли повторно строить embedding. Если изменились только метаданные, она напрямую патчит векторную базу данных без пересчёта вектора.
Вскоре после этого генерация embeddings перешла с Spark + external API на self-hosted модели на Ray через Anyscale. CPU-предобработка и GPU-инференс теперь выполняются в едином пайплайне, устраняя S3-handoff между системами.
Два года. Пять крупных ставок. Затраты снижены на 90% от пика. Это действительно впечатляющий путь.
Это история, которую большие данные уже рассказывали
На каждом шаге мне хотелось сделать пометку с датой: экосистема больших данных решила это в [year]. Это не совпадение. Одни и те же ограничения приводят к одним и тем же архитектурным ходам.
1. Разделение хранения и вычислений и serverless: платить за работу, а не за существование
Две стоимостные миграции Notion — от pod-кластеров к serverless, затем к serverless-схеме на основе объектного хранилища — можно рассматривать как один архитектурный ход: перестать платить за существование инфраструктуры и начать платить за фактическую работу. Независимо от того, активно ли рабочее пространство запрашивалось или простаивало неделями, старая модель продолжала держать кластеры запущенными и выставлять счета.
С этой точки зрения ключевой сдвиг — это отделение хранения от вычислений: индексы живут в объектном хранилище, холодные коллекции почти не держат вычислительных ресурсов, горячие коллекции загружаются по требованию, а расходы гораздо точнее соответствуют реальному использованию. В больших данных это была не просто замена HDFS на S3; это был более широкий переход от интеграции хранения и вычислений к их разделению.
Последовательность имела значение: сначала независимое масштабирование решило проблемы эластичности и планирования ёмкости; затем эфемерные вычисления плюс постоянное объектное хранилище снизили затраты на использование. Деплоймент Hadoop по умолчанию совмещал хранение и вычисления ради локальности данных, что затрудняло независимое масштабирование. Когда данные переместились в S3, кластеры Spark смогли запускаться под каждую задачу и выключаться после её завершения, тогда как хранилище оставалось постоянным.
Этот компромисс также структурный. Доступ к объектному хранилищу задаёт нижнюю границу задержки холодного старта: несколько GET-запросов, десериализация и реконструкция индекса. Это не столько вопрос настройки параметров, сколько вопрос физики хранения. Для текущей рабочей нагрузки Notion, где к большинству рабочих пространств обращаются нечасто, это хороший компромисс. Но по мере углубления использования AI становится всё труднее игнорировать два ограничения: крупные арендаторы с устойчиво высоким объёмом запросов и пользователи, возвращающиеся в холодные рабочие пространства, где хвостовая задержка становится заметной для пользователя. На этом этапе одноуровневого S3-native кэширования часто недостаточно; хранение тёплых данных на локальных SSD становится существенно важнее.
2. Lambda Architecture: реальное время — это потребность, фрагментация — это цена
Система индексирования Notion работает по двум путям: офлайн-пайплайн Spark для крупномасштабного обратного заполнения и Kafka consumers для обновлений в реальном времени. Это классическая Lambda-схема.
Если для вас важна свежесть данных, такой дизайн — естественная отправная точка. Проблема в том, что происходит дальше: одна и та же логика начинает расползаться по нескольким системам, и команды тратят всё больше времени на поддержание согласованности путей.
В случае Notion это разделение теперь охватывает Spark, Kafka consumers, DynamoDB для Page State, Ray для embedding и отдельный serving layer.
Каждый компонент выполняет правильную работу. Скрытый налог — это интеграционная поверхность:
- больше glue code
- больше передачи состояния
- больше возможностей для расхождения между офлайн- и онлайн-поведением
Во многом это усиливается закрытым хранилищем для serving. Миграция провайдера означает полную переиндексацию. Поддержка частичных обновлений означает внешние таблицы отслеживания. Офлайн-улучшения не помогают онлайн-поиску, пока не завершится ещё один этап синхронизации.
Суть Kappa проста: одна модель обработки. Более сильная форма — One Engine: batch и streaming как два режима одной системы, а не две системы, склеенные вместе.
Именно здесь подходит Lakebase. Она переносит эту идею One Engine на lake-native основу, преодолевая разрыв OLTP/OLAP так, чтобы обновления в реальном времени, онлайн-serving и офлайн-обработка выполнялись на одной таблице.
3. Недостающий слой: декларативный интерфейс для векторных операций
Переход от Spark + внешнего embedding API к унифицированному Ray pipeline — правильное решение: объединение двух систем, которые взаимодействовали через S3, в единый вычислительный граф действительно упрощает архитектуру, а прогнозируемое снижение затрат на embedding более чем на 90% отражает настоящее архитектурное улучшение. Но это упрощение на уровне инфраструктурной связки, и всё ещё не хватает упрощения на семантическом уровне.
В эпоху Hadoop, чтобы что-то сделать с данными, нужно было писать задания MapReduce: необходимо было понимать жизненный цикл Mapper и Reducer, как работает shuffle, как обрабатывать сбои и как связывать этапы в цепочки. Hive добавил декларативный слой — вы выражаете нужный результат в SQL, а система сама решает, как превратить это в выполнение MapReduce. Этот сдвиг не просто ускорил работу; он изменил сам круг людей, способных работать с данными, и приблизил инженерную стоимость новой операции с данными к стоимости написания запроса, а не распределённой системы.
Однако у векторных и неструктурированных данных такого слоя пока нет.
- Если вы хотите дедуплицировать корпус из миллиарда векторов перед запуском обучения модели, вы пишете Spark-задачи, выбираете правильные операторы вычисления расстояний, управляете форматами вывода и разбираетесь, как передать результаты обратно туда, где находится ваш serving-слой.
- Если вы хотите обновиться с одной модели эмбеддингов на более новую для сотен миллионов документов, вы строите pipeline обратного заполнения, управляете сосуществованием старых и новых эмбеддингов во время переключения и затем выполняете очистку — и этот процесс является многомесячным инженерным проектом, а не рутинной операцией.
- Если вы хотите поддерживать сжатую пользовательскую память между сессиями, вы проектируете логику сжатия, управляете версионированными записями и вручную подключаете результат к пути retrieval. Каждый из этих пунктов является проектом системной инженерии, а не операцией с данными.
Декларативный эквивалент состоял бы в том, чтобы выразить намерение — «дедуплицируй эту коллекцию с косинусным допуском 0.05 и запиши результаты обратно», «выполни обратное заполнение эмбеддингов с использованием этой новой модели», «сожми историю взаимодействий старше 90 дней в плотные представления памяти» — и чтобы система сама занималась планированием выполнения, управлением ресурсами и согласованностью. Это тот слой, который делает Context Engineering осуществимой в масштабе, а не каждый раз отдельным инженерным проектом. И его всё ещё в значительной степени не хватает в современных стеках векторной инфраструктуры, независимо от serving-бэкенда.
| Решение Notion | Архитектурный паттерн |
|---|---|
| Pod-кластеры → serverless → serverless с опорой на object storage | Разделение хранения и вычислений: развязка жизненного цикла, применённая к векторным индексам |
| Двухпутевая индексация + Page State + маршрутизация по поколениям | Real-time-first Lambda-дизайн: высокая свежесть, но растущая стоимость синхронизации между online/offline путями |
| Spark + передача через S3 → Ray | Схлопывание межсистемного I/O — но декларативного интерфейсного слоя поверх этого всё ещё не хватает |
Big data потребовалось 15 лет, чтобы сойтись к архитектуре, в которой хранение, вычисления и семантика обработки были чётко разделены и компонуемы. Notion прошёл большую часть этой дуги за два года, что действительно впечатляет. Деталь, которая пока не появилась, — это та, которая сделала бы следующие два года существенно дешевле в разработке.
Но это только первая глава
Всё, что решил Notion, — это инфраструктура для одной AI-функции.
Вся эта инженерная работа — маршрутизация генерации, миграции провайдеров, Page State, унификация вычислений на Ray — существует для того, чтобы AI Q&A работал хорошо, дёшево и надёжно. Они этого добились. Инфраструктура для этой одной функции теперь зрелая. Notion не собирается выпускать только одну AI-функцию.
Три проблемы, которых я ожидаю в их следующем инженерном посте
Проблема 1: Потолок serverless + разделения cold/hot в масштабе
Текущий выбор Notion — хороший компромисс для их нынешней нагрузки: миллионы рабочих пространств, большинство из которых запрашиваются нечасто, где экономика S3-native сильна. Ограничение в том, что потолки производительности здесь задаются скорее поведением object storage, чем настраиваемыми программными параметрами.
Задержка S3 до первого байта часто находится в диапазоне 10–100 мс. Холодному индексу может потребоваться несколько GET-запросов и десериализация, прежде чем он станет доступен для запросов. В production p99 холодных запросов может достигать многосекундных диапазонов. Обычно это не проблема модели; это прогрев индекса.
Основные болевые точки предсказуемы.
- Во-первых, крупные tenants с высоким, устойчивым объёмом запросов начинают ощущать пределы одноуровневого кэширования.
- Во-вторых, пользователи, возвращающиеся в холодные рабочие пространства, могут видеть заметные всплески задержки. Многоуровневое кэширование (memory + local SSD + object storage) меняет форму этого хвоста так, как одноуровневые дизайны обычно не могут.
Модель биллинга также может удивлять команды: тарификация по размеру namespace, а не по нагрузке запросов означает, что большие рабочие пространства могут выглядеть дорогими, даже когда отдельные запросы сканируют небольшие подмножества. В перекошенных multi-tenant распределениях расходы могут расходиться с интуицией на уровне запросов.
Filter recall — еще одна скрытая проблема для подходов ANN-plus-post-filter. Когда фильтры узкие — тип страницы, collaborator, временной диапазон — пулы кандидатов могут становиться слишком маленькими, что приводит к падению recall. По мере того как Notion добавляет больше путей AI retrieval с фильтрацией, этот компромисс, как правило, проявляется чаще.
Так что да, текущий компромисс хорош. Ограничения просто очевидны: крупные tenants и latency холодных запросов становятся первыми трещинами.
Проблема 2: Разделение real-time/offline становится всё дороже
Текущий стек Notion: Spark + Airflow для offline batch processing, Kafka consumers для real-time updates, Ray для embedding, Turbopuffer для queries. Четыре системы, каждая хорошо выполняет свою работу, все работают с одними и теми же базовыми данными — содержимым страниц пользователей.
Это структура data silo в ее классической форме. Одни и те же исходные данные поддерживаются как несколько views разными системами, а application-layer logic отвечает за их синхронизацию. Page State с xxHash + DynamoDB существует специально для поддержания consistency между view batch processing и real-time view. Эта логика корректна, но ее сложность растет линейно с количеством AI features — каждая новая feature добавляет еще один набор synchronization logic, который нужно поддерживать в real и offline paths.
Более глубокая проблема: offline processing не может напрямую улучшать online serving без шага синхронизации. Если offline pipeline Notion обнаруживает сильные семантические связи между документами в workspace, эти связи не смогут улучшить AI Q&A retrieval, пока результаты не будут записаны туда, откуда online query logic сможет их прочитать. Между ними есть системная граница, к которой прикреплены latency и риск consistency.
Именно это затрудняет раскручивание data flywheel: signals, генерируемые online usage, не могут непрерывно улучшать offline models без пересечения системной границы в обоих направлениях.
Архитектурный ответ — OneData: online serving и offline processing используют одну и ту же базовую таблицу. Нет multiple views для синхронизации, нет application-layer consistency logic. Одна Iceberg table, разные compute modes, чтение и запись в одно и то же место. Offline layer делает online layer умнее; online layer генерирует signals, которые обрабатывает offline layer. Flywheel работает на едином фундаменте.
Проблема 3: Offline context engineering — где строится настоящий moat
Notion AI сегодня: пользователь задает вопрос → retrieve relevant chunks в real time → передать в LLM → вернуть ответ. Потолок качества этого pipeline определяется тем, что находится в index.
Пробел, который закрывает offline context engineering, — это не retrieval quality во время query, а качество того, что вы построили до того, как query поступит.
Memory. Каждый разговор с Notion AI содержит signal: что важно пользователю, как он работает, какие knowledge имеют для него значение. Vectorizing этого signal и его организация в retrievable user memory — это просто. Поддерживать ее — нет: старые memories нуждаются в compression (разговор шестимесячной давности должен превратиться в более плотное representation), stale memories нужно обновлять (когда новый content противоречит старым records), а связанные memories нужно организовывать hierarchically. Всё это — continuous offline batch processing over vector data. Это нельзя сделать во время query.
Предвычисленные графы знаний. Вместо того чтобы каждый раз заново искать, «какие документы релевантны этому запросу», офлайн-обработка может построить модель семантической топологии рабочего пространства — какие документы затрагивают одни и те же концепции, какие решения имеют зависимости, как идеи эволюционировали со временем. Эта модель становится контекстом, который у ИИ уже есть, поэтому он рассуждает на основе понимания вашего рабочего пространства, а не выполняет новый поиск с нуля.
Маховик данных. Какие результаты retrieval были использованы? Какие вопросы постоянно возникают без удовлетворительных ответов? Какие документы многократно упоминаются в разных запросах? Эти сигналы, обработанные офлайн, могут непрерывно настраивать retrieval — корректировать стратегии разбиения на чанки, выводить на поверхность знания, которые снова и снова доказывают свою релевантность, и выявлять слепые зоны. Маховик вращается только тогда, когда есть инфраструктура для преобразования сигналов в улучшения в векторном слое. Без этого сигналы — всего лишь байты в лог-файле.
Notion располагает одним из самых интересных наборов данных для ИИ из существующих: структурированными знаниями, намеренно организованными, в десятках миллионов рабочих пространств. Это исключительный исходный материал. Но защитный ров данных создается не наличием данных — он создается инфраструктурой, которая непрерывно превращает данные в возможности. Их текущая векторная инфраструктура предназначена для онлайн-обслуживания. Поддержание памяти, предвычисление графов знаний, маховики обработки сигналов — это крупномасштабные пакетные задачи, для которых в текущей архитектуре нет естественного места.
Позиционирование Lakebase
На этом этапе закономерность ясна. Следующее узкое место — не решение по одному движку запросов. Это разрыв между обслуживанием в реальном времени и офлайн-обработкой.
Vector Lakebase позиционируется как мост:
Единая платформа для OLTP и OLAP: обслуживание в реальном времени, итеративное обнаружение и пакетная аналитика работают на одной и той же lake-native основе данных и едином источнике истины.
Один инкрементальный поток вместо двухконтурной синхронизации. Захват изменений, повторное embedding и переиндексация становятся возможностями уровня данных, а не связующим кодом приложения.
Одно место, где офлайн-интеллект становится онлайн. Сжатие памяти, backfill и сигналы качества записываются обратно в ту же таблицу и напрямую улучшают обслуживание.
Такова практическая Глава 2: не просто более качественный поиск, а единая операционная модель для векторных данных.
Vector Lakebase — это ответ Zilliz Cloud на Главу 2: единое векторное хранилище, обработка и обслуживание на вашем существующем озере данных. Миграция не требуется. Следите за новостями.
Читать далее
Announcing VDBBench 1.0: Open-Source VectorDB Benchmarking with Your Real-World Production Workloads
Discover VDBBench 1.0, an open-source tool for benchmarking vector databases with real-world production data, streaming ingestion, and concurrent workloads.
8 Latest RAG Advancements Every Developer Should Know
Explore eight advanced RAG variants that can solve real problems you might be facing: slow retrieval, poor context understanding, multimodal data handling, and resource optimization.
How to Build RAG with Milvus, QwQ-32B and Ollama
Hands-on tutorial on how to create a streamlined, powerful RAG pipeline that balances efficiency, accuracy, and scalability using the QwQ-32B and Milvus.