Как OpenAI похоронила традиционный BI — и что пришло ему на смену

21.02.2026 • Хабр

OpenAI описала, как внутри компании устроена аналитика без центрального BI-инструмента: вместо дашбордов используется data agent, который сам находит данные, пишет SQL и собирает отчёт. В тексте это подаётся как смена парадигмы от «витрины» к диалогу с данными.

OpenAI пишет, что их дата-платформа обслуживает 3 500 внутренних пользователей и работает с 600 петабайтами данных, распределёнными по 70 000 датасетам.
В статье утверждается, что для внутренней аналитики не используется Tableau, Power BI, Looker, Qlik или Superset как единый централизованный инструмент.
В июне 2024 OpenAI объявила о покупке Rockset; в тексте также указано, что Rockset привлёк $117.5 млн инвестиций и был закрыт для клиентов через три месяца с удалением данных.
Data agent описан как система на GPT-5.2, доступная в Slack, веб-интерфейсе, IDE и через Codex CLI по MCP, которая выполняет цикл «вопрос → поиск таблиц → SQL → анализ → визуализация → отчёт».
OpenAI выделяет пять слоёв контекста для агента: история использования таблиц, человеческие аннотации, чтение ETL-кода через Codex, корпоративные источники знаний (Slack/Docs/Notion) с контролем доступа и слой памяти для закрепления исправлений.

Почему это важно: Текст фиксирует типовую боль на масштабе: похожие таблицы, сложные джоины и «тихие» ошибки в SQL приводят к тому, что ответы становятся недостоверными или слишком дорогими по времени. Переход к агенту строится вокруг идеи, что смысл живёт в коде: ключевые допущения о метриках и фильтрах часто лежат в логике пайплайнов, а не в схемах и описаниях. В результате основная ценность смещается с «построить дашборд» на «собрать правильный контекст и воспроизводимый способ ответа».

На что обратить внимание: В описании подчёркивается, что ранние версии агента ухудшались от избытка данных, и отдельно выделяется фильтрация контекста под вопрос как фактор качества. Также важна связка retrieval и прав доступа: корпоративные документы и переписки индексируются, но доступ к ним должен соблюдаться на уровне выдачи. Наконец, закрытие Rockset после поглощения показано как пример того, что инфраструктурные решения могут резко менять режим доступности для внешних пользователей.

Коротко

В тексте описан сдвиг от модели «человек → дашборд → инсайт» к модели «вопрос → агент → ответ с источниками и объяснением», где поиск нужного отчёта исчезает.
Практический вывод из кейса: при множестве похожих таблиц критичны аннотации и история запросов, иначе выбор «правильного» источника превращается в угадывание.
Необычная деталь архитектуры — использование ETL-кода как источника смысла: определения метрик и допущения извлекаются из логики загрузки, а не только из каталога.
В тексте роль аналитика переопределяется: меньше сборки отчётов, больше работы с семантикой метрик, knowledge bank, шаблонами и контролем качества ответов агента.
Упоминание Apache Doris/VeloDB и StarRocks читается как сигнал: часть «дорогой» архитектурной идеи multi-index real-time analytics доступна в open-source для пилотов.

FAQ

Зачем это важно, если в компании уже есть Tableau/Power BI и десятки дашбордов — что принципиально меняется в модели потребления аналитики?

В тексте дашборды описаны как формат, который отвечает на «что произошло», но плохо закрывает «почему» и «что дальше». Агент переносит аналитику в формат диалога и автоматизирует путь от вопроса до отчёта.

Почему в материале так много внимания уделено покупке Rockset и последующему закрытию сервиса — что этот эпизод объясняет в контексте аналитики OpenAI?

Эпизод используется как иллюстрация ставки на real-time аналитику и инфраструктурный фундамент для AI-first подхода. В тексте также подчёркнуто, что продукт для внешних клиентов был закрыт через три месяца с удалением данных.

Что означает «пять слоёв контекста» у OpenAI data agent и чем они отличаются друг от друга, если кратко пересказать логику из текста?

Описаны слои от метаданных и истории запросов до человеческих аннотаций, чтения ETL-кода, корпоративных документов и памяти исправлений. Смысл в том, что контекст берётся из разных источников и дополняется со временем.

Какие проблемы качества аналитики автор связывает с «SQL как программированием» и почему это важно именно на большом масштабе данных и таблиц?

В тексте приводятся примеры рисков: ошибки в JOIN, many-to-many, NULL и неверный уровень применения фильтров могут «тихо» искажать результат. На масштабе это усложняет проверку корректности и повышает цену ошибок.

PubMag