Несколько заметок с Databricks Data + AI Summit 2026: почему уровень данных снова имеет значение
После этого года на Databricks Data + AI Summit я поймал себя на том, что думаю не столько о каком-то одном анонсе, сколько о вопросе, который уже давно не дает мне покоя:
Когда AI по-настоящему переходит в production, чем становится слой данных?
Мой текущий ответ прост, хотя его последствия — нет: в этом цикле слой данных — это та часть AI-стека, которую переоценивали медленнее всего. Это начинает меняться.
Данные: часть AI-стека, которую рынок еще не оценил
Алгоритмы были переоценены публично. Модели быстро улучшаются, и индустрия видит прогресс почти каждую неделю. Compute был переоценен NVIDIA, облачными провайдерами и рынками капитала. Все понимают, что GPU важны.
Данные двигались медленнее. Не потому, что они менее важны. Верно обратное. Данные медленно переоцениваются, потому что о них трудно говорить и еще труднее их исправлять. Корпоративные данные хаотичны, разбросаны, дублируются, устаревают и полны разрешений, которые никто до конца не понимает. Бизнес-семантика не выстраивается аккуратно между системами. То, что люди называют «real time», часто все еще является запланированной задачей, которая выполнялась когда-то прошлой ночью.
Эта работа болезненна. И она не очень гламурна. Но как только AI переходит от демо к production, эту боль становится невозможно скрыть.
В разговорах с людьми, которые создают и обучают модели, включая специалистов из OpenAI и Anthropic, обсуждение часто возвращается к одному и тому же тезису. Модели сходятся. Compute можно купить — по крайней мере, если у вас достаточно денег. Защищаемым слоем все чаще становятся данные: их качество, их актуальность, разрешения вокруг них и скорость, с которой их можно превратить в полезный контекст.
Это проблема не только уровня приложений. Внутри модельных компаний качество моделей по-прежнему сильно зависит от data pipeline. Training run может требовать нескольких дней подготовки до начала первого серьезного эксперимента. Если поле upstream загрязнено, batch размечен неверно или правило фильтрации ошибочно, дни compute и ожидания могут исчезнуть, прежде чем кто-то заметит, что loss curve отклонилась.
AI-агенты делают проблему данных невозможной для сокрытия
Агенты выявляют ту же проблему в более операционной форме.
Когда AI-агенты терпят неудачу в production, первая причина часто не в том, что модель неспособна. А в том, что модель действует на основе неправильного контекста: запись, к которой она не может получить доступ, документ, срок действия которого истек шесть часов назад, источник данных, который тихо изменился за ночь, или retrieval path, который слишком дорог, чтобы использовать его достаточно часто. Недавно я видел, как сильная команда потеряла почти неделю из-за устаревшего context pipeline. Агент уверенно отвечал на вчерашний вопрос. Модель не была глупой. Контекст был неправильным, а у системы не было чистого способа доказать, где ошибка вошла в цикл.
Именно этот режим отказа имеет значение. Следующее инфраструктурное узкое место — это не просто более сильное reasoning. Это свежий, надежный, дешевый и аудируемый контекст в тот момент, когда модель или агент принимает решение.
Вот почему я думаю, что слой данных — следующая часть AI-стека, которая будет переоценена.
Databricks нацеливается на правильную проблему
Я скептически отношусь ко многим продуктам, которые называют себя «AI data platforms». Слишком часто история появляется раньше системы.
Databricks достаточно отличается, и поэтому, на мой взгляд, заслуживает серьезного внимания. На Summit мне особенно запомнились две вещи.
Первая — это все еще инженерная культура. В масштабе Databricks компании было бы легко стать полностью ориентированной на продажи. И все же основатели по-прежнему выходят на сцену и говорят об execution engines, transactions, real-time analytics и трубах под продуктом. Я это уважаю. Чувствуется, когда в основе компании все еще лежат продуктовая и инженерная интуиция. Это проявляется в небольших архитектурных решениях задолго до того, как проявится в keynote.
Второе — это клиентская база. Пользователи, с которыми я говорил на Summit, не рассматривали AI как демонстрационный слой. Они пытались внедрить AI в производственные системы, и проблемы, которые они описывали, были гораздо более конкретными: агентам нужно читать и записывать бизнес-состояние; аналитика в реальном времени не может и дальше платить налог за перемещение данных; пайплайны должны становиться более автономными; поведение агентов нуждается в управлении во время выполнения, а не только постфактум.
Именно поэтому такие анонсы, как Lakebase, Lakehouse//RT, data agents и AI governance, имеют значение. Названия менее важны, чем направление. Переместить транзакции ближе к lake. Вернуть аналитику в реальном времени к той же основе данных. Автоматизировать большую часть пайплайна. Расширить управление от «кто может видеть этот dataset» до «что этому агенту разрешено делать на этом конкретном шаге?»
Я не считаю это неверным поворотом. Я вижу в этом доказательство того, что многие из нас смотрят на одно и то же будущее с разных углов.
База данных расширяется. Это уже не только место для хранения и запросов к данным. Она становится основой для фактов, состояния, семантики, управления и действий.
Карта хороша. Но она не завершена.
Databricks движется в правильном направлении. Это не означает, что архитектура достигла своей окончательной формы.
Фото: The Known Data Realm · Databricks Data + AI Summit 2026
Я вижу три области, в которых карта всё ещё неполна.
Сам lakebase.
Начать с Postgres — умная точка входа. Разработчики его знают. Экосистема огромна. Совместимость снижает трение при внедрении. Это важно.
Но архитектура, которая помогает людям войти, не всегда является архитектурой, которая выигрывает финальную рабочую нагрузку.
Операционным системам эпохи AI нужны транзакции, память, векторы, мультимодальные данные, трассировки, ветвление, откат и очень тонко гранулированная изоляция арендаторов. Традиционное реляционное ядро может предоставлять часть этого через расширения и окружающие сервисы, но от этого они не становятся нативными. Классический Postgres не был спроектирован для облачно-нативного распределённого масштаба, равно как и для агентов, которые создают короткоживущие базы данных, разветвляют состояние, записывают в память, генерируют трассировки и исчезают.
Перемещение Postgres ближе к объектному хранилищу не снимает этих вопросов. Объектное хранилище дешёвое и надёжное, но по умолчанию оно не низколатентное. Чтобы оно ощущалось быстрым, нужен слой кэша, одновременно агрессивный и корректный. Кэш, который остаётся стабильным под реальной транзакционной нагрузкой, — одна из самых сложных системных задач в базах данных. Поэтому мой честный вопрос о Lakebase не в том, впечатляет ли демо. Он в том, сможет ли система выдерживать реальные OLTP-нагрузки в промышленном масштабе, не превращая этот кэш в то, что будит людей в 3 часа ночи.
Мультимодальные данные.
Databricks начертила сильную карту, охватывающую OLTP, хранилища данных, аналитику в реальном времени, data science и управление. Но AI-приложения всё чаще потребляют текст, изображения, аудио, видео, embeddings, логи поведения и трассировки агентов. Это не просто объекты, лежащие рядом с таблицами. Это данные, которые агенты извлекают, осмысливают, преобразуют и записывают обратно.
Если мультимодальные данные остаются вне основной карты, то самые важные AI-активы данных всё ещё находятся на периферии.
Пользователь по умолчанию.
Большая часть поверхности продукта всё ещё предполагает пользователя-человека: dashboards, BI на естественном языке, Excel-подобные рабочие процессы и интерфейсы для аналитиков. Всё это ценно. Но агенты используют базы данных иначе.
Агент не открывает dashboard раз в день. Он работает в цикле. Он извлекает контекст, принимает решение, вызывает инструмент, записывает состояние, проверяет политику и повторяет. Каждый шаг может нуждаться в аудите. Каждое извлечение может влиять на следующее действие. Каждая запись может требовать отката. Каждая проверка разрешений может требовать выполнения во время runtime.
Это другая рабочая нагрузка для базы данных.
Фото: Unity AI Gateway · Управление —— Databricks Data + AI Summit 2026
Когда пользователь базы данных — агент
Десятилетиями база данных в основном могла фокусироваться на одном вопросе: как выполнить этот запрос корректно и быстро.
В эпоху агентов вопрос становится шире:
Как агент получает самый свежий, самый надежный, самый дешевый и наиболее пригодный для аудита контекст в момент, когда принимает решение?
Это не просто проблема оптимизации запросов. Это системная проблема, охватывающая хранение, индексирование, управление, происхождение данных, воспроизведение, контроль затрат и применение политик во время выполнения.
Именно здесь категория начинает смещаться. Система данных больше не может быть только системой интеллекта: вы задаете вопрос, она возвращает ответ. Она должна стать ближе к операционной системе для AI: месту, где агенты читают контекст, принимают решения, вызывают инструменты, записывают состояние и оставляют след, который могут проверить люди и другие системы.
Возможность аудита нельзя прикрутить постфактум. Если агент дает неправильный ответ, выполняет неправильное действие или тратит слишком много денег, первым вопросом будет: что именно он видел в тот момент?
Чтобы ответить на это, системе нужно знать, какие документы были извлечены, какие векторы совпали, какие фильтры метаданных были применены, какой reranker изменил порядок, какой инструмент был вызван, какая политика была применена и какое состояние было записано обратно. Отладка и управление становятся одним и тем же рабочим процессом.
Это та архитектура, которую, как мне кажется, пока еще никто полностью не решил.
Что на самом деле должно означать “AI-native”
“AI-native” становится одной из тех фраз, которые могут означать почти что угодно. Я не думаю, что для нее уже есть четкое определение. Но если идти в обратном направлении от реальных агентных нагрузок, AI-native система данных должна хорошо выполнять как минимум несколько вещей.
Мультимодальные данные должны быть первоклассными
Текст, изображения, аудио, видео, embeddings, логи и трассы не должны быть разбросаны по реляционной таблице, векторному столбцу, объектному bucket и нескольким побочным индексам. Они должны жить в одной логической системе, где извлечение, фильтрация, ранжирование и управление могут происходить вместе.
Сложность не в хранении этих активов. Сложность в том, чтобы сделать их совместно запрашиваемыми, не превращая архитектуру в еще одну проблему пайплайнов.
Эластичность должна начинаться с нагрузки
Трафик агентов носит всплесковый характер. Система может быть тихой в течение часа, а затем получить поток запросов на извлечение, память и использование инструментов. Data lake или object store должны стать прочной основой: дешевой, надежной и отделенной от вычислений.
Но вычисления не должны оставаться дорогими только потому, что корпус существует. Если никто не выполняет поиск, система должна тратить очень мало. Если нагрузка просыпается, вычислительные ресурсы должны появляться быстро. В таком мире естественной единицей ценообразования не всегда является постоянный кластер. Это может быть запрос, сессия или минута активных вычислений.
Мультитенантность должна перейти на уровень агента
Традиционные мультитенантные системы часто предполагают управляемое число крупных тенантов. Агентные системы могут создавать миллионы или миллиарды крошечных, краткоживущих, изолированных состояний. Каждый агент может нести собственную память, разрешения, трассы, временные ветки и пути записи.
Дизайн, созданный для тысяч крупных тенантов, столкнется с трудностями, когда тенантом станет сам запуск агента.
Ветвление и откат становятся базовыми функциями базы данных
Агенты будут записывать неправильные вещи. Это не крайний случай. Это часть нагрузки.
Полезному AI-слою данных нужны Git-подобное ветвление и быстрый откат состояния данных. Запуск агента должен иметь возможность создать рабочую ветку, протестировать действие, записать временное состояние и отбросить или продвинуть его. Если попадет плохое обновление, система должна иметь возможность быстро вернуться к заведомо хорошей точке.
Версионирование больше не является только удобством для аналитики. Оно становится механизмом операционной безопасности.
Трассировка и детерминированное воспроизведение обязательны
Когда агент терпит неудачу, вопрос не только в том, «каким был итоговый ответ?» Вопрос в том, «что агент увидел, извлек, ранжировал, решил, вызвал и написал?»
Для этого требуется трассировка каждого значимого шага. Что еще важнее, требуется воспроизведение. Система должна быть способна восстановить контекст принятия решения таким, каким он существовал в тот момент, а не таким, каким он выглядит после изменения документа или перестроения индекса.
Для агентов аудитируемость и отлаживаемость сводятся к одному и тому же требованию.
Разрешения должны управлять действиями, а не только строками
Традиционная авторизация спрашивает, кто может читать таблицу, столбец или строку. Агентным системам нужен более динамичный вопрос: что этому агенту разрешено извлекать, вызывать, изменять, раскрывать и тратить на этом конкретном шаге?
Сложная часть смещается с пути чтения на путь действия. Применение политик должно происходить во время работы агента, а не только когда человек открывает дашборд.
Операции должны стать самоуправляемыми
Масштаб на уровне агентов ломает инфраструктуру, управляемую людьми. Ни одна команда не может вручную управлять индексами, компакцией, прогревом кэша, размещением тенантов, восстановлением и планированием ресурсов для миллионов небольших, быстро меняющихся рабочих нагрузок.
Система должна эксплуатировать себя сама. Иначе архитектура может работать на диаграмме, но провалиться в единственном месте, которое имеет значение: в продакшене.
SQL недостаточно в качестве конечного интерфейса
Есть еще один вопрос, о котором я думаю все больше и больше: сам интерфейс.
SQL был правильным интерфейсом для эпохи аналитиков. Он по-прежнему необходим. Но для компаний, построенных вокруг баз данных и аналитики, SQL также может стать формой зависимости от выбранного пути. Поверхность продукта, модель пользователя и даже организация часто предполагают, что основной пользователь — это тот, кто умеет писать запрос.
Конечным интерфейсом для данных эпохи ИИ не будет чуть более хороший SQL-редактор. И им также не будет чат-бот, приклеенный перед базой данных.
Более интересная конечная точка — это headless, нативная для естественного языка система данных: такая, где человек или агент может напрямую сформулировать намерение, а система может ответить, выполнить действие или подготовить правильный план выполнения, не выставляя каждый внутренний шаг как упражнение по написанию запросов.
Но это должно быть нативно для базы данных, а не отдельный агент, стоящий перед ней.
Если естественный язык — это только прикладной слой, система заново вводит те самые швы, которые пытается устранить: еще один шаг перевода, еще одно устаревшее окно контекста, еще один разрыв в управлении. Сама база данных должна понимать вопрос, данные, политики и путь выполнения.
Это гораздо сложнее, чем построить дружелюбный интерфейс. Это означает, что база данных должна владеть семантикой.
Ров, который всё еще имеет значение
У меня нет идеально чистого вывода. Возможно, это уместно. Рынок движется слишком быстро, и слишком много старых предположений вымываются быстрее, чем ожидалось.
Проприетарный диалект запросов уже не является тем рвом, каким был раньше. Стоимость миграции слабее, когда агенты могут переписывать интеграционный код. Привычный UI имеет меньшее значение, когда следующим пользователем может быть не человек. Даже тихое преимущество простого владения данными слабее, когда открытые табличные форматы, интерфейсы на естественном языке и агенты, использующие инструменты, упрощают перемещение.
Ров, в который я все еще верю, менее гламурен: способность создавать реальную пользовательскую ценность на протяжении длительного времени, терпеливо и снова и снова.
Именно поэтому после Summit я стал серьезно относиться к Databricks. Я думаю, у Databricks есть реальный шанс стать следующей триллионной компанией в сфере данных. Не потому, что каждое объявление о продукте — это окончательный ответ. Некоторые из них изменятся. Некоторые, вероятно, окажутся неверными. Это нормально. Важно то, что компания продолжает возвращаться к правильной проблеме.
А правильная проблема — это уже не просто аналитика, хранилища данных или транзакционное хранение. Это фундамент данных для ИИ-систем, которые действуют.
Со стороны Zilliz мы пришли к похожему выводу с другой стороны. Векторные базы данных никуда не исчезают. Они становятся движком serving внутри более широкой архитектуры для неструктурированных и мультимодальных данных. Поэтому мы мыслим в терминах Vector Lakebase: не как о замене векторных баз данных, а как о следующей архитектуре, построенной вокруг них по мере того, как AI-нагрузки становятся более непрерывными, эластичными и агентными.
Карта еще не завершена. И это самое лучшее.
Дешевое побеждает дорогое. Надежное побеждает ненадежное. Аккуратное побеждает небрежное. Терпеливое побеждает нетерпеливое.
AI-native база данных все еще только прорисовывается. Для всех, кто строит в этой сфере, это очень хорошие новости.
И еще кое-что: Zilliz Vector Lakebase доступен в публичном превью
Мы запустили публичное превью Zilliz Vector Lakebase — значительную эволюцию Zilliz Cloud от чистой векторной базы данных к lake-native основе данных для AI, сочетающей низколатентный vector serving с открытостью, масштабируемостью и экономикой data lake.
Ключевые возможности Zilliz Vector Lakebase:
- Многоуровневый serving, оптимизированный под разные компромиссы между производительностью в реальном времени и стоимостью
- Поиск по требованию для крупномасштабных или исследовательских нагрузок без постоянно включенных вычислений
- Поиск во внешнем data lake — индексируйте и ищите напрямую по вашим существующим данным в lake
- Полноспектральный поиск по векторам, тексту, JSON и геопространственным данным с гибридным извлечением и reranking
- Унифицированное lake-native хранилище, построенное на Vortex, открытом формате с более быстрыми и дешевыми случайными чтениями, чем Lance или Parquet
Если ваш текущий стек разделяет serving и discovery на отдельные системы, возможно, стоит присмотреться к Vector Lakebase. Попробуйте его в Zilliz Cloud — новые регистрации с рабочей электронной почтой получают $100 бесплатных кредитов — или свяжитесь с нами, чтобы обсудить ваш сценарий использования.
Читать далее
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.
Smarter Autoscaling in Zilliz Cloud: Always Optimized for Every Workload
With the latest upgrade, Zilliz Cloud introduces smarter autoscaling—a fully automated, more streamlined, elastic resource management system.
Similarity Metrics for Vector Search
Exploring five similarity metrics for vector search: L2 or Euclidean distance, cosine distance, inner product, and hamming distance.