BI снова хоронят — и снова преждевременно

BI снова хоронят — и снова преждевременно. На этот раз в гробу отчётливо слышен стук: в июне 2026 года Anthropic опубликовала описание своего внутреннего дата-агента с цифрами и, что редкость, с четырьмя отрицательными результатами. А у Hex появился бенчмарк, где рядом с оценкой ответа стоит его цена. Разбираю, что из этого следует для обычной команды, которая хочет построить своего дата-агента и не хочет наступить на грабли, на которые уже наступили другие.

Главное, что нужно понять сразу: переносимой цифры точности дата-агентов не существует. Авторы Spider 2.0 положили 180 одних и тех же задач на BigQuery и на Snowflake — получили 12.78% против 6.6%. Меняется только диалект SQL, всё остальное зафиксировано. А внутри одного лидерборда разброс между системами доходит до девяноста четырёх пунктов. Плюс в публичных цифрах про text-to-SQL сидит вклад ошибок эталонной разметки, и его размер неизвестен. В январе на CIDR вышла работа с говорящим названием «Text-to-SQL Benchmarks are Broken»: ошибки нашли в половине и в двух третях проверенных примеров двух широко используемых бенчмарков. Так что любая чужая цифра точности — это отправная точка для размышлений, а не гарантия.

Что изменилось у самой OpenAI. В февральской статье я приводил платформу на 600 петабайт, 70 000 датасетов, 3 500 пользователей и GPT-5.2. Третьего июня вышло интервью Эммы Тан, Head of Data Platform Engineering в OpenAI, и там уже другие цифры по состоянию на май 2026. Полтора экзабайта влияют в основном на счёт за хранение. Работу аналитикам создают две другие строки, и ведут они себя по-разному. Пользователей стало около четырёх тысяч вместо трёх с половиной — примерно на 14% больше. Датасетов стало 90 тысяч вместо 70, и это за четыре месяца. Аналитик полезен настолько, насколько знает, где что лежит сейчас, а входит в курс дела он месяцами, и схема данных за это же время успевает сильно измениться. Знание обесценивается примерно с той скоростью, с какой набирается, и от числа людей это не зависит. Темп работы впечатляет: миграцию 10 000 DAG, 90 000 таблиц и 600 ПБ между облаками OpenAI сделала за два месяца с помощью Codex.

И поправка к моему февральскому тексту. Я написал, что у OpenAI пять слоёв контекста. Их шесть. Я пропустил Layer #6: Runtime Context — живые запросы к хранилищу в момент ответа, когда нужного контекста нет или он устарел, плюс обращения к metadata service, Airflow и Spark. Слой важный: он про ту самую проблему, которую Anthropic позже назовёт одним из трёх главных источников ошибок.

Самое интересное в интервью — признание про инструменты. Начинали с сорока инструментов. Результаты были плохими: модель путалась в инструментах с перекрывающимися функциями. Оставили около тринадцати на вызов. Ни роутера, ни файнтюна, ни post-training. Агент, по описанию их собственной команды, «pretty vanilla». В тот же день, 3 июня 2026 года, Anthropic опубликует описание, в котором обвязки вокруг модели заметно больше.

Ожидание, что с аналитикой получится как с кодом, создали агенты, которые пишут код: Copilot, Cursor, Claude Code, Codex. Их результат в цифрах был выше — та же миграция 10 000 DAG, 90 000 таблиц и 600 ПБ между облаками прошла за два месяца с помощью Codex. Аналитика выглядит соседней задачей: там тоже надо получить корректный код, только на SQL. Но проверяется результат иначе, и из этой разницы вырастают и провалы дата-агентов, и вся обвязка, о которой пойдёт речь дальше.

В программировании у большинства ошибок есть дешёвая машинная проверка: компилятор, линтер, тест. Запустил — увидел. В аналитике инструменты проверки тоже есть, и немало: SQL-компилятор, dbt-тесты, сверки, data-quality checks. Но ловят они другой класс ошибок. Запрос может быть синтаксически корректным, пройти все тесты, вернуть правдоподобное число и отвечать при этом не на тот бизнес-вопрос, который задали. Такую ошибку видит только человек, знающий предметную область, то есть тот самый аналитик, чью работу мы пытаемся автоматизировать.

Anthropic в июньской статье сводит все ошибки своего агента к трём типам. Entity ambiguity — неоднозначность сущности: вопрос про «активных клиентов» упирается в пять таблиц, каждая из которых считает активность по-своему. Staleness — устаревание: документация описывает модель данных, которая менялась вчера. Retrieval failure — провал поиска: правильный ответ в системе есть, но агент до него не дошёл. Обратите внимание, чего в этом списке нет: «модель плохо пишет SQL». Синтаксис давно перестал быть проблемой.

Лучшая иллюстрация первого типа — из описания стенда, на котором Hex тестирует своих агентов. Они собрали синтетический бизнес Shorelane Commerce (поставщик канцелярии с выручкой около $129M) и специально воспроизвели реальный бардак. Пять колонок можно с равным правом назвать «revenue», и финансы, маркетинг и операции привычно ссылаются каждая на свою. Остальной список «данных с историей» узнает любой, кто работал в компании старше пяти лет: в 2021 переехали на другую платформу и по дороге потеряли часть customer ID; в том же году купили конкурента и так и не слили его данные до конца; в 2022 переименовали канал продаж, не сделав backfill; в 2023 перестроили тарифы, но столько клиентов оставили на старых условиях, что в обороте до сих пор все три схемы одновременно. Никакой компилятор такое не поймает. И модель не угадает, какая из пяти колонок правильная, потому что правильного ответа в данных нет — он в головах людей.

Anthropic заявляет, что достигла 95% бизнес-аналитических запросов автоматизированы, точность в агрегате ~95%, в отдельных доменах регулярно около 99%. Но если убрать один из основных компонентов их инфраструктуры — skills, то точность падает до 21%. Без skills, по словам самих Anthropic, способность Claude точно отвечать на аналитические вопросы не превышала 21% на их evals. С skills — стабильно выше 95% в агрегате. То есть основную точность даёт обвязка вокруг модели: контекст, инструкции и проверки. Обе цифры принадлежат самой Anthropic и получены на её собственном наборе тестов.

Обвязка состоит из четырёх слоёв, и каждый закрывает конкретный тип ошибки. Первый — Data foundations: канонические витрины, тесты, метаданные, владельцы. Скучная дата-инженерия, без которой дальше можно не читать. Второй — Sources of truth: семантический слой, к которому агент обязан обращаться первым по инструкции в skill. Raw SQL — только fallback, и в самом skill прописаны заранее опровергнутые отговорки, которыми агент пытается этот fallback оправдать («тут нужен join» — join уже внутри метрики). Третий — Skills: папки с markdown, которые агент читает по запросу. Их две: knowledge работает как лёгкий роутер («сначала семантический слой, если покрытия нет — вот ~30 reference-файлов по этому домену с таблицами, join-ами и подводными камнями») и runbook кодирует процесс, которым шёл бы старший аналитик: уточнить вопрос, найти источник, выполнить запрос, отдать результат на adversarial-ревью — критический разбор своего же ответа отдельным агентом, который ищет в нём дырки. Четвёртый — Validation: offline-evals как блокирующая проверка перед релизом плюс онлайн-сигналы: provenance-футер (приписка под ответом, откуда взято число и насколько оно свежее), доля запросов, прошедших через семантический слой, и доля ответов, в которых пользователь использует корректирующие формулировки вроде «это не та таблица» или «ты забыл фильтр по фроду».

Всё это интересно, но по-настоящему ценны отрицательные результаты. Их четыре, и каждый может сэкономить недели или месяцы при разработке своего дата-агента.

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

Второй отрицательный результат: сырой доступ к истории запросов не работает. Это мой любимый результат, потому что он опровергает совет, который я сам давал и придерживался. Логика «поднимите audit log за полгода, там уже лежат все правильные ответы» звучит безупречно. Anthropic дали агенту grep-доступ ко всему SQL из дашбордов, трансформаций и ноутбуков — тысячи файлов. Проверили по транскриптам, что он действительно читает их перед ответом. Точность изменилась меньше чем на пункт в любую сторону. Дальше проверили очевидное возражение: а был ли вообще ответ в корпусе для тех вопросов, где агент ошибся? Был, примерно в 80% случаев. Предсказывало ли «ответ есть в корпусе» то, что агент теперь ответит верно? Нет: доля исправившихся ответов от этого не выросла. Узкое место оказалось в структуре: как вопрос отображается на правильную сущность. Дамп истории в retrieval эту задачу не решает. Решает перенос знания из корпуса в короткие доменные справочники, которые агент читает вместо поиска по хранилищу. Их собственные примеры объясняют разницу лучше определения. Подводный камень: «исключай известные бесплатные почтовые домены, но оставляй корпоративные вроде anthropic.com». В корпусе это лежит фрагментом в сотнях запросов, и в каждом чуть по-своему; в справочнике стоит одной строкой сразу с исключением. Правило маршрутизации: «ЕСЛИ вопрос про прирост в эксперименте… НЕ используй для сырых счётчиков событий».

Третий и четвёртый отрицательные результаты — про рецепты, которые не работают. Anthropic пробовали разные подходы и честно перечислили, что не сработало. Это экономит недели или месяцы при разработке своего дата-агента.

Теперь про то, где размещена сложность. Vanilla-агент — это просто модель с доступом к данным. Тяжёлая обвязка — это весь описанный выше контекст, скиллы, проверки. Опыт OpenAI и Anthropic показывает: основная сложность не в модели, а в обвязке. Модель уже умеет писать SQL. Проблема в том, чтобы дать ей правильный контекст и не дать ей уйти в неверную сторону.

Сколько это стоит и что получается, показывает DataBench от Hex. Там рядом с оценкой ответа стоит его цена. Это важно для экономики: три статьи расходов, из которых обычно считают одну. Люди часто думают только про стоимость токенов. Но есть ещё расходы на разработку и поддержку обвязки, на дата-инфраструктуру, на ревью и валидацию. И есть расходы на ошибки: неверный ответ, который кто-то принял за истину, может стоить дороже всей инфраструктуры.

Чужая цифра точности к вам не переносится. Никак. Это надо принять и строить свои evals. Вопрос, который нужно задавать вендору: на каких данных получена цифра? Ваш стек, ваши метрики, ваши права доступа — всё другое. Методология при этом может быть подробной, как у OpenAI: golden SQL пишут руками, grader объясняет каждое своё решение. Это описание того, как измеряли, но без самого измерения. Одни вендоры дают методологию без цифр, другие — цифры без методологии. И те и другие нужно проверять на своих данных.

Три родственных сбоя, которые воспроизводятся и в других задачах: entity ambiguity, staleness и retrieval failure — это не только про SQL. Это про любую генерацию с использованием корпоративных данных. Если у вас в компании пять «revenue», агент будет путаться в любой задаче. Если документация отстаёт от реальности — будет устаревание. Если правильный ответ есть, но агент до него не дошёл — retrieval failure.

Governance — раздел, из-за которого весь проект может не состояться. Права доступа: что агент может читать, что писать, кому показывать ответы. Если агент работает поверх данных, к которым у пользователя нет доступа, — это нарушение. Если агент может писать в таблицы — это риск. Вопросы, которые нужно задавать вендору: как настроены права доступа? Можно ли ограничить агента по ролям? Как логируются его действия? Как откатываются изменения? Без этого проект может быть закрыт на стадии пилота, даже если точность отличная.

Экономика: три статьи расходов, из которых обычно считают одну. Первая — токены и инфраструктура: каждый запрос к агенту стоит денег, и при росте использования счёт растёт линейно. Вторая — разработка и поддержка обвязки: семантический слой, скиллы, evals — это работа инженеров, и она не заканчивается после релиза, потому что данные меняются. Третья — стоимость ошибок: неверный ответ, который ушёл в бизнес-решение. Обычно считают только первую статью, а вторая и третья оказываются больше.

А может, всё это лишнее? Для маленькой команды с простыми данными и одним аналитиком дата-агент может быть избыточен. Иногда проще оставить человека. Но для компаний, где данных много и топ-менеджмент одержим AI, вопрос не «делать или нет», а «как делать и как не разориться на ошибках».

Что делать обычной команде? Шесть шагов. Первый: проверить свой дата-стек. Если у вас нет канонических витрин, семантического слоя и владельцев данных —

Телеграм: t.me/ainewsline

Источник: vk.com

Комментарии: