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

21.02.2026 • Хабр

Коротко

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

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 после поглощения показано как пример того, что инфраструктурные решения могут резко менять режим доступности для внешних пользователей.

FAQ

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

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

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

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

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

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

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

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