Привет, меня зовут Полоротов Александр, co-founder datanomix.pro последние восемь лет я помогал компаниям внедрять BI.
Насмотрелся на ситуации, когда существует десяток дашбордов, которые никто не смотрит. Хотя, какой только систематизацией не занимались.
На сотни отчётов, которые генерируются по расписанию и уходят в пустоту. И аналитиков, которые 80% времени тратят не на анализ, а на поиск «а где вообще эти данные лежат?»
Недавно OpenAI опубликовала статью о том, как устроена их внутренняя аналитика.
И меня зацепило: компания, которая создала ChatGPT, для анализа собственных 600 петабайт данных** не использует ни Tableau, ни Power BI, ни Looker, ни Qlik, ни SuperSet**, как централизованный инструмент удовлетворения информационной потребности.
Но думаю, вот такие ребята все равно существуют у них в компании, от этих дилеров правильных отчетов никогда не избавишься.
600 петабайт и ни одного дашборда
Масштаб проблемы
Дата-платформа OpenAI обслуживает 3 500 внутренних пользователей — это инженеры, продакт-менеджеры, аналитики, финансисты, исследователи. Они работают с 600 петабайтами данных, разбросанными по 70 000 датасетам.
И вот цитата из самой статьи OpenAI, от их реального внутреннего пользователя:
"We have a lot of tables that are fairly similar, and I spend tons of time trying to figure out how they're different and which to use. Some include logged-out users, some don't. Some have overlapping fields; it's hard to tell what is what."
Знакомая боль, да? У вас, может, не 70 000 таблиц, а 700 или 7 000.
Но ощущение «а какая из пяти похожих таблиц правильная?» универсальное.
Почему дашборды не справились
Проблема не в конкретном BI-инструменте.
Проблема в самой модели «человек → дашборд → инсайт». Вот что ломается на масштабе:
SQL-запросы на 180+ строк — это не аналитика, это ��рограммирование. Одна ошибка в JOIN-условии и результат молча искажается
Many-to-many джоины классический источник дублирования строк, который BI-инструменты не поймают
Unhandled nulls тихо обнуляют ваши средние и суммы, а вы об этом узнаёте через месяц
Filter pushdown errors когда фильтр применяется не на том уровне, и весь отчёт врёт
OpenAI показала SQL-запрос из своей реальной практики — 180+ строк. И честно написала: "It's not easy to know if we're joining the right tables and querying the right columns."
Вот тезис, от которого стоит оттолкнуться: Может, дело не в дашбордах, а в самом подходе?
Зачем OpenAI купила базу данных за $117M — и тут же её убила
Июнь 2024: неожиданное поглощение
Вернёмся на два года назад. Июнь 2024 OpenAI объявляет о покупке Rockset, real-time аналитической базы данных. Сделка непубличная, но известно, что Rockset к тому моменту привлёк $117.5 миллионов инвестиций от Sequoia, Greylock и Icon Ventures. Клиенты — Meta, JetBlue, финтех-компании.
Что происходит дальше? OpenAI закрывает Rockset для всех клиентов за три месяца и удаляет их данные. Вот так. Без предупреждения, без переходного периода.
Представьте: вы клиент Rockset, ваш прод работает на их базе, и вам говорят: «У вас три месяца, чтобы куда-нибудь уехать. Данные мы удалим.»
Что такое Rockset и почему именно он
Rockset основали в 2016 году экс-инженеры Facebook. Один из основателей — Dhruba Borthakur тот самый человек, который создал RocksDB в Facebook.
Из RocksDB выросла целая экосистема: это хранилище данных используется внутри десятков современных систем.
Ключевая идея Rockset три типа индексов в одной системе:
Индекс | Для чего | Аналог отдельной системы |
|---|---|---|
Inverted Index | Полнотекстовый поиск | Elasticsearch |
Columnar Index | Аналитические запросы | ClickHouse, Snowflake |
Document Index | Key-value доступ | MongoDB, DynamoDB |
Плюс real-time ingestion из Kafka, MongoDB, DynamoDB и SQL-интерфейс поверх полуструктурированных данных (JSON, CSV).
Одна система — вместо трёх-четырёх отдельных.
Контринтуитивный выбор
А вот что действительно интересно. В 2024 году, на пике хайпа векторных баз данных, когда Pinecone оценивалась в $750 миллионов, OpenAI покупает НЕ векторную БД, а аналитическую.
Почему? Потому что для AI нужны не только эмбеддинги. Нужны структурированные и полуструктурированные данные в реальном времени. Метрики, логи, транзакции, события всё то, что живёт в таблицах, а не в векторном пространстве.
Как точно подметил Madhukar Kumar:
"AI is a feature. Vectors are a feature. Data is the real product."
А Forbes добавил: поглощение Rockset это стратегический шаг OpenAI к созданию полного enterprise-стека.
Не просто LLM, а LLM + retrieval + real-time analytics. Полная вертикаль.
У Rockset есть живой родственник
Вот что мне показалось особенно любопытным. Архитектурная идея Rockset multi-index real-time analytics не уникальна. У неё есть живые open-source аналоги: Apache Doris (коммерческая версия VeloDB) и переписанный форк [StarRocks] (https://github.com/StarRocks/starrocks).
Сравните:
Аспект | Rockset | Apache Doris / VeloDB |
|---|---|---|
Индексы | Inverted + Columnar + Document | Inverted + Columnar + Vector (HNSW) |
Real-time ingestion | Kafka, MongoDB, DynamoDB | Kafka, Flink CDC, MySQL/PG binlog |
SQL-интерфейс | SQL поверх JSON | MySQL-протокол, стандартный SQL |
Философия | Одна система заменяет несколько | Одна система заменяет несколько |
Векторный поиск | Нет | Нативный (HNSW, IVPQ) |
Open-source | Нет (проприетарная) | Да (Apache License 2.0) |
Статус | Убита после поглощения | Активно развивается |
Одна и та же школа мысли: не множить системы, а объединить разные типы доступа к данным в одном движке. Только Doris ещё и добавил нативный векторный поиск для AI то, что OpenAI пришлось достраивать повер�� Rockset самостоятельно.
Это не «Doris лучше Rockset». Это наблюдение: технология, за которую OpenAI заплатила как минимум $117M и закрыла для всех, существует в open-source и доступна любой компании.
Пять слоёв контекста как устроен AI-агент OpenAI
Окей, хватит про поглощения — давайте разберёмся, что OpenAI в итоге построила.
Архитектура агента
Их data agent работает на GPT-5.2 и доступен везде, где работают сотрудники: Slack, веб-интерфейс, IDE, Codex CLI через MCP, внутренний ChatGPT через MCP-коннектор.
Пользователь задаёт вопрос на естественном языке: "Для поездок на такси в Нью-Йорке, какие пары зон посадки-высадки самые ненадёжные, с наибольшей разницей между типичным и worst-case временем поездки?"
И агент сам делает всё: находит нужные таблицы, пишет SQL, запускает запросы, анализирует результаты, визуализирует и генерирует отчёт. Без единого дашборда.
Но самое интересное не сам агент, а то, откуда он берёт контекст. OpenAI описывает пять слоёв:
Слой 1: Table Usage — метаданные и история
Базовый слой: схемы таблиц, типы колонок, lineage (какие таблицы откуда берут данные), история SQL-запросов. Агент видит, какие таблицы обычно джойнятся вместе, какие колонки используются чаще всего.
Это то, что умеет любой data catalog. Необходимый, но недостаточный минимум.
Слой 2: Human Annotations — экспертное знание
Описания таблиц и колонок от доменных экспертов. Не автоматически сгенерированные, а написанные людьми, которые знают: «эта таблица не включает logged-out пользователей», «эта колонка содержит NULL для европейских клиентов до марта 2024».
Те самые оговорки и нюансы, которые обычно живут в головах аналитиков и передаются устно.
Слой 3: Codex Enrichment — смысл живёт в коде
А вот это уже по-настоящему ново. Агент через Codex читает код пайплайнов, которые создают таблицы. Не метаданные, не описания — а сам исходный код ETL.
Зачем? Потому что, как пишет OpenAI: "Meaning lives in code." Истинное определение таблицы — не в её схеме, а в коде, который её создаёт. Только из кода можно узнать:
Как часто таблица обновляется
Какие фильтры применяются при загрузке
Какие предположения заложены в трансформации
Уникальны ли значения в колонке
И этот контекст обновляется автоматически — агент перечитывает код по мере изменений.
Слой 4: Institutional Knowledge — корпоративная память
Агент имеет доступ к Slack, Google Docs и Notion. Оттуда он вытаскивает: даты запусков фичей, информацию об инцидентах, внутренние кодовые названия, канонические определения метрик.
Все эти документы индексируются, встраиваются (embeddings) и хранятся с метаданными и правами доступа. Retrieval-сервис обеспечивает контроль доступа и кэширование.
Слой 5: Memory — самообучение
Когда пользователь поправляет агента или агент обнаруживает нюанс в процессе анализа, он сохраняет это знание для следующего раза.
Пример из статьи OpenAI: агент не знал, как фильтровать конкретный A/B-тест (нужно было match-ить строку из experiment gate).
После корректировки он запомнил это — и в следующий раз сделал правильно сам.
Памяти бывают глобальные (для всех) и персональные. Пользователи могут создавать и редактировать их вручную.
┌─────────────────────────────────────────┐ │ AI Data Agent (GPT-5.2) │ ├─────────────────────────────────────────┤ │ Слой 5: Memory │ │ ↑ Самообучение, корректировки │ ├─────────────────────────────────────────┤ │ Слой 4: Institutional Knowledge │ │ ↑ Slack, Docs, Notion, инциденты │ ├─────────────────────────────────────────┤ │ Слой 3: Codex Enrichment │ │ ↑ Код пайплайнов, ETL-логика │ ├─────────────────────────────────────────┤ │ Слой 2: Human Annotations │ │ ↑ Описания от экспертов, оговорки │ ├─────────────────────────────────────────┤ │ Слой 1: Table Usage │ │ ↑ Схемы, метаданные, история запросов │ └─────────────────────────────────────────┘
Self-healing и workflows
Ещё два важных свойства.
Во-первых, агент сам себя проверяет: если промежуточный результат выглядит неправильно (например, 0 строк после джоина — красный флаг), он не выдаёт его пользователю, а исследует проблему, исправляет подход и пробует снова.
Во-вторых, повторяющиеся анализы упакованы в workflows переиспользуемые инструкции. Еженедельный бизнес-отчёт, валидация таблиц, анализ запуска фичи — всё это делается одним запросом, а не многочасовой ручной работой.
Три урока OpenAI, которые стоит украсть
OpenAI честно рассказала о своих ошибках. И вот три урока, которые применимы к любой компании:
Урок 1: Less is More
Первая версия агента получала слишком много контекста. Все метаданные, все описания, все связи. Результат? Агент путался и давал худшие ответы.
Решение: тщательная фильтрация контекста. Не «дай модели всё», а «дай модели только то, что релевантно именно этому вопросу». Меньше шума — лучше сигнал.
Если вы строите что-то подобное — не пытайтесь запихнуть весь ваш data catalog в промпт. Лучше вложитесь в качественный retrieval.
Урок 2: Guide the Goal, Not the Path
Ранние версии использовали очень детальные инструкции: «сначала найди таблицу X, потом соедини с Y, примени фильтр Z». И это работало хуже, чем просто: «Ответь на вопрос Q, используя данные платформы».
Почему? Потому что каждый аналитический вопрос уникален. Жёсткий алгоритм ломается на нестандартных случаях. А GPT-5, получив высокоуровневую цель, сам находит оптимальный путь.
Это принцип, который стоит запомнить: давайте модели цель, а не маршрут. (Если подумать, это работает не только с AI, но и с людьми. Но это тема для другой статьи.)
Урок 3: Meaning Lives in Code
Это, пожалуй, самый глубокий инсайт. Схема таблицы говорит вам «что». Описание — «зачем». Но только код пайплайна говорит «как именно» — а значит, раскрывает все скрытые допущения.
Таблица daily_active_users может выглядеть одинаково в каталоге. Но код покажет, что одна считает DAU по уникальным сессиям, а другая — по уникальным device_id. Разница? Потенциально 30% расхождение в метриках.
Для любой компании это значит: документируйте и поддерживайте в порядке код ваших пайплайнов. Это не техдолг — это будущий контекст для AI-агентов.
80% дашбордов никому не нужны
Статистика, которая отрезвляет
Пока OpenAI строила своего агента, индустрия BI тоже не стояла на месте. Вот что показывают исследования:
80%+ дашбордов в крупных компаниях не используются и не нуждаются в миграции при обновлении BI-платформы — Dataiku
Только 25% бизнес-пользователей реально работают с BI-инструментами — IBM. Остальные считают их слишком сложными
45% крупных предприятий уже внедрили AI-аналитику, 80-90% планируют в ближайшие два года — IBM
Вдумайтесь: мы годами строили дашборды, которые 80% сотрудников компании не могут или не хотят использовать.
Напишите в комментах честно: сколько дашбордов в вашей компании реально открывают хотя бы раз в неделю? Подозреваю, ответ многих расстроит.
Фундаментальное ограничение дашбордов
Дашборд отвечает на вопрос «что произошло?» — и только. Он не скажет «почему?», не предложит «что делать?». Для этого нужен аналитик, который интерпретирует графики, копает глубже, строит гипотезы.
Дашборд — это витрина, а не мозг.
AI-агенты переворачивают эту модель.
Вместо:
Пользователь ищет дашборд → тыкает нужный фильтр → интерпретирует график → формулирует гипотезу → → прове��яет в другом дашборде → ...
Получается:
Пользователь задаёт вопрос → получает ответ с анализом, источниками и рекомендациями → предлагает конкретное действие → выполняет действие при получении разрешения
Не «данные ждут, пока их найдут», а «данные находят пользователя».
Новая роль аналитика
И нет, это не «аналитики больше не нужны». Как раз наоборот. Dataiku описывает новую роль аналитика:
Архитектор знаний проектирует knowledge banks, из которых агент берёт контекст
Создатель инструментов пишет SQL-шаблоны, модели прогнозирования, логику извлечения
Аудитор качества проверяет reasoning traces агента, находит ошибки, улучшает точность
Хранитель semantic layer определяет, что такое «активный пользователь», «выручка», «churn»
Аналитик перестаёт быть человеком, который строит отчёты. Он становится человеком, который учит систему строить отчёты правильно. И это, честно говоря, гораздо интереснее.
Что делать уже сейчас
Окей, OpenAI построила агента за год, потратила $117M на поглощение Rockset, использует GPT-5.2 и Codex. Что из этого может взять обычная компания?
Что делать
1. Инвестировать в semantic layer и каталог данных.
Это фундамент. Без единых определений метрик AI-агент будет давать разные ответы разным людям. Когда отдел продаж и финансов спрашивают «какой у нас CAC?» — они должны получать одно и то же число.
Определите метрики один раз, задокументируйте — и любой будущий агент сможет на это опираться.
2. Документировать пайплайны и бизнес-логику.
«Meaning lives in code» работает, только если код читаем.
Прокомментируйте ваши ETL-пайплайны. Вот здесь мне становится понятным, почему ETL процессы, которые у вас остались зашиты в Informatica навсегда закрывают полезную информацию от AI агентов.
Объясните, почему фильтр применяется именно здесь. Зафиксируйте допущения. Это инвестиция, которая окупается даже без AI, потому что новый аналитик в команде тоже скажет спасибо.
3. Думать об аналитике как о диалоге.
Следующий раз, когда бизнес попросит «ещё один дашборд» задайте вопрос: а какой вопрос вы хотите задать?, какие решения или действия хотите выполнить?
Может, ответ лучше дать в виде автоматического отчёта в Slack? Или text-to-SQL запроса?
Или сразу предложить выполнить конкретное действие - сделать автозаказ, отклонить заявку.
Дашборд — один из форматов, не единственный.
4. Начать с малого: text-to-SQL уже работает.
Не нужно строить полноценного агента. Open-source стек вроде Apache Doris или DuckDB + LangChain или LlamaIndex + любая LLM, позволяет за пару недель собрать прототип, где бизнес-пользователь задаёт вопрос на естественном языке и получает SQL-запрос с результатом.
Это не замена BI — но это первый шаг к новой парадигме.
Чего НЕ делать
Не бросайте всё и не стройте «своего AI-агента». OpenAI потратила на это год плюс поглощение. У них в команде люди, которые буквально обучали GPT.
Если вы попытаетесь повторить это без подготовки — получите революцию в аналитике дорогой генератор галлюцинаций.
Ваш первый шаг — подготовить данные, мета-информацию, инфраструктуру.
Заключение: аналитика — это разговор, а не витрина
OpenAI показала, к чему идёт индустрия. Аналитика будущего — это не коллекция графиков на экране.
Это разговор с данными: вопрос → анализ → ответ → уточнение → новый инсайт.
Поглощение Rockset было не про покупку базы данных. Это была покупка фундамента для AI-first аналитики, real-time индексация, SQL поверх semi-structured данных, multi-index архитектура.
Всё то, что нужно, чтобы AI-агент мог быстро и точно работать с любыми данными компании.
И вот ещё один принцип, который здесь работает: Distribution = Product (Питер Тиль одобряет). Агент OpenAI встроен в Slack, IDE, CLI, MCP он там, где люди уже работают.
Лучший дашборд в мире проигрывает посредственному агенту, если агент отвечает в том же чате, где идёт обсуждение.
Мы стоим в начале этого перехода. Дашборды не исчезнут завтра — как не исчезли физические газеты с появлением интернета (хотя, если честно, когда вы в последний раз покупали газету?).
Но направление очевидно: от статичных отчётов к диалогу, от витрины к мозгу, от «посмотри сам» к «спроси и получи ответ, подтверди действие».
А у вас в компании сколько процентов дашбордов реально смотрят?
Источники
OpenAI: Inside our in-house data agent — основной источник
OpenAI acquires Rockset — официальное объявление о поглощении
Rockset — Database of Databases (CMU) — техническое описание архитектуры
Forbes: Analysis of OpenAI's Acquisition of Rockset — стратегический анализ
TechCrunch: OpenAI buys Rockset to bolster its enterprise AI — детали сделки ($117.5M, Sequoia, Greylock)
Medium: What Does OpenAI's Acquisition of Rockset Mean — "AI is a feature, data is the product"
Dataiku: The AI Agent Revolution for Self-Service BI — 80% дашбордов не используются
IBM: AI-Powered Business Intelligence — 25% adoption of BI tools, 80-90% planning AI analytics
Apache Doris — open-source аналог multi-index подхода Rockset
VeloDB — enterprise версия Apache Doris
