Привет, меня зовут Полоротов Александр, 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 три типа индексов в одной системе:

Плюс 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).

Сравните:

Одна и та же школа мысли: не множить системы, а объединить разные типы доступа к данным в одном движке. Только 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 он там, где люди уже работают.

Лучший дашборд в мире проигрывает посредственному агенту, если агент отвечает в том же чате, где идёт обсуждение.

Мы стоим в начале этого перехода. Дашборды не исчезнут завтра — как не исчезли физические газеты с появлением интернета (хотя, если честно, когда вы в последний раз покупали газету?).

Но направление очевидно: от статичных отчётов к диалогу, от витрины к мозгу, от «посмотри сам» к «спроси и получи ответ, подтверди действие».

А у вас в компании сколько процентов дашбордов реально смотрят?

---

Источники

1. OpenAI: Inside our in-house data agent — основной источник

2. OpenAI acquires Rockset — официальное объявление о поглощении

3. Rockset — Database of Databases (CMU) — техническое описание архитектуры

4. Forbes: Analysis of OpenAI’s Acquisition of Rockset — стратегический анализ

5. TechCrunch: OpenAI buys Rockset to bolster its enterprise AI — детали сделки ($117.5M, Sequoia, Greylock)

6. Medium: What Does OpenAI’s Acquisition of Rockset Mean — «AI is a feature, data is the product»

7. Dataiku: The AI Agent Revolution for Self-Service BI — 80% дашбордов не используются

8. IBM: AI-Powered Business Intelligence — 25% adoption of BI tools, 80-90% planning AI analytics

9. Apache Doris — open-source аналог multi-index подхода Rockset

10. VeloDB — enterprise версия Apache Doris