Снова хороним BI. Из гроба стучит

Привет, меня зовут Полоротов Александр, co-founder Datanomix.pro. Последние восемь лет я помогал компаниям внедрять BI, а теперь нищий вайбкодер.

Полгода назад я написал здесь статью «Как OpenAI похоронила традиционный BI» ^[1] про внутреннего дата-агента OpenAI, который работает поверх 600 петабайт без единого дашборда. Статья залетела (по моим меркам). Меня даже в телеграме несколько раз спросили: а какая у этого агента точность ответов? Ответить я не смог: ни одного значения accuracy OpenAI не привела. Методологию при этом описала подробно: golden SQL пишут руками, grader объясняет каждое своё решение. Получилось описание того, как измеряли, без самого измерения.

Я даже собрал свой замер на Spider (это такой бенч с задачами text-to-SQL): 2400 прогонов, слои контекста добавлял по одному и смотрел, что даёт каждый. Из этого выросла идея продукта под рабочим названием ctx-as-code: контекст как код, сборка бандла для модели, evals на каждом PR. До кода дело не дошло: в июле я закрыл идею. Из пяти опрошенных команд платить за отдельный инструмент не собиралась ни одна, а те же функции к тому времени уже добавляли Atlan, DataHub, Snowflake и Wren.

Но тема своего дата-агента и сокращения расходов на BI до сих пор гуляет по коридорам каждой компании, где топ-менеджмент одержим AI, а кто-нибудь из офиса данных открыл для себя вайбкодинг.

Дров в этот костёр подбросила Anthropic, выложив описание своего внутреннего дата-агента с цифрами и, что редкость, с четырьмя отрицательными результатами: что попробовали и что не сработало. У Hex появился бенчмарк, где рядом с оценкой ответа стоит его цена. А несколько академических работ независимо от вендоров нащупали три самых неприятных свойства таких систем.

Коротко:

• Без skills Claude не превышал 21% на внутренних evals Anthropic. Со skills — стабильно выше 95% в агрегате. Обе цифры принадлежат самой Anthropic и получены на её собственном наборе тестов.

• Переносимой цифры точности дата-агентов не существует. Авторы Spider 2.0 положили 180 одних и тех же задач на BigQuery и на Snowflake: 12.78% против 6.6%. Меняется только диалект SQL, всё остальное зафиксировано. А внутри одного лидерборда разброс между системами доходит до девяноста четырёх пунктов.

• В публичных цифрах про text-to-SQL сидит вклад ошибок эталонной разметки, и его размер неизвестен. В январе на CIDR вышла работа с говорящим названием «Text-to-SQL Benchmarks are Broken»: ошибки ^[2] нашлись в половине и в двух третях проверенных примеров двух широко используемых бенчмарков.

• Главная слабость — суждение. Считать модели уже умеют. Хуже у них с пониманием, когда считать вообще нельзя.

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

Всё со ссылками на первоисточники. Где цифра принадлежит вендору, который продаёт этот же продукт, я отмечаю.

---

Оглавление

• Часть 1. Что изменилось у самой OpenAI ^[3]

• Часть 2. Почему ошибку дата-агента некому поймать ^[4]

• Часть 3. Стек Anthropic: что сработало и что нет ^[5]

• Часть 4. Где размещена сложность: vanilla-агент и тяжёлая обвязка ^[6]

• Часть 5. Сколько это стоит и что получается: DataBench ^[7]

• Часть 6. Чужая цифра точности к вам не переносится ^[8]

• Часть 7. Три родственных сбоя, которые воспроизводятся и в других задачах ^[9]

• Часть 8. Governance: раздел, из-за которого весь проект может не состояться ^[10]

• Часть 9. Экономика: три статьи расходов, из которых обычно считают одну ^[11]

• Часть 10. А может, всё это лишнее? ^[12]

• Часть 11. Что делать обычной команде ^[13]

• Часть 12. Как проверить текущий дата стэк? ^[14]

• Заключение: смысл, зафиксированный в версиях ^[15]

---

Часть 1. Что изменилось у самой OpenAI

В февральской статье я приводил платформу на 600 петабайт, 70 000 датасетов, 3 500 пользователей и GPT-5.2. Третьего июня вышло интервью Эммы Тан, Head of Data Platform Engineering в OpenAI ^[16], и там уже другие цифры — по состоянию на май 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 опубликует описание, в котором обвязки вокруг модели заметно больше.

↑ К оглавлению ^[17]

---

Часть 2. Почему ошибку дата-агента некому поймать

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

Аналитика выглядит соседней задачей: там тоже надо получить корректный код, только на SQL. Но проверяется результат иначе, и из этой разницы вырастают и провалы дата-агентов, и вся обвязка, о которой пойдёт речь дальше.

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

Anthropic в июньской статье ^[18] сводит все ошибки своего агента к трём типам:

1. Entity ambiguity — неоднозначность сущности. Вопрос про «активных клиентов» упирается в пять таблиц, каждая из которых считает активность по-своему.

2. Staleness — устаревание. Документация описывает модель данных, которая менялась вчера.

3. Retrieval failure — провал поиска. Правильный ответ в системе есть, но агент до него не дошёл.

Обратите внимание ^[19], чего в этом списке нет: «модель плохо пишет SQL». Синтаксис давно перестал быть проблемой.

Лучшая иллюстрация первого типа из описания стенда, на котором Hex тестирует своих агентов. Они собрали синтетический бизнес Shorelane Commerce (поставщик канцелярии с выручкой около $129M) и специально воспроизвели реальный бардак. Цитирую их же формулировку: пять колонок можно с равным правом назвать «revenue», и финансы, маркетинг и операции привычно ссылаются каждый на свою.

Остальной список «данных с историей» узнает любой, кто работал в компании старше пяти лет: в 2021 переехали на другую платформу и по дороге потеряли часть customer ID; в том же году купили конкурента и так и не слили его данные до конца; в 2022 переименовали канал продаж, не сделав backfill; в 2023 перестроили тарифы, но столько клиентов оставили на старых условиях, что в обороте до сих пор все три схемы одновременно.

Никакой компилятор такое не поймает. И модель не угадает, какая из пяти колонок правильная потому что правильного ответа в данных нет, он в головах людей.

↑ К оглавлению ^[17]

---

Часть 3. Стек Anthropic: что сработало и что нет

Anthropic заявляет: 95% бизнес-аналитических запросов автоматизированы, точность в агрегате ~95%, в отдельных доменах регулярно около 99%. Сразу дисклеймер, который придётся повторить несколько раз: «95% запросов автоматизированы» и «точность 95%» два разных числа, и их постоянно склеивают в пересказах.

А вот цифра, ради которой их статью стоит читать. Дословно:

Without skills, Claude’s ability to answer analytics questions accurately didn’t exceed 21% on our evals.

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

Стек состоит из четырёх слоёв, и каждый закрывает конкретный тип ошибки:

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

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

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

Сырой доступ к истории запросов не работает. Это мой любимый результат, потому что он опровергает совет, который я сам давал и придерживался. Логика ^[20] «поднимите audit log за полгода, там уже лежат все правильные ответы» звучит безупречно. Они дали агенту grep-доступ ко всему SQL из дашбордов, трансформаций и ноутбуков — тысячи файлов. Проверили по транскриптам, что он действительно читает их перед ответом. Точность изменилась меньше чем на пункт в любую сторону. Дальше проверили очевидное возражение: а был ли вообще ответ в корпусе для тех вопросов, где агент ошибся? Был, примерно в 80% случаев. Предсказывало ли «ответ есть в корпусе» то, что агент теперь ответит верно? Нет: доля исправившихся ответов от этого не выросла.

Узкое место оказалось в структуре: как вопрос отображается на правильную сущность. Дамп истории в retrieval эту задачу не решает. Решает перенос знания из корпуса в короткие доменные справочники, которые агент читает вместо поиска по хранилищу.

Их собственные примеры объясняют разницу лучше определения. Подводный камень: «исключай известные бесплатные почтовые домены, но оставляй корпоративные вроде anthropic.com». В корпусе это лежит фрагментом WHERE в сотнях запросов, и в каждом чуть по-своему; в справочнике стоит одной строкой сразу с исключением.

Правило маршрутизации: «ЕСЛИ вопрос про прирост в эксперименте… НЕ используй для сырых счётчиков событий», где многоточие стоит у самой Anthropic вместо имени таблицы. Прирост, он же lift, — это насколько тестовый вариант обогнал контроль в A/B-тесте: считают его по своей таблице с разбивкой на группы, и она же не подходит, когда надо просто пересчитать события. Вот это и есть отображение вопроса на сущность в чистом виде. И десяток готовых схем разбора в runbook-skill: кривые retention, декомпозиция показателя, анализ воронки, чтобы типовой запрос не собирали заново каждый раз. Общее правило у них такое: историю запросов надо считать сырьём, а не источником истины, который агент читает напрямую.

Бесконечная доработка документации не работает. Они получили три подряд отрицательных итерации: доки становились длиннее, но не лучше.

Экономия на adversarial-ревьюере не работает. Замена ревьюера на более дешёвую модель ради снижения задержки съела почти весь прирост точности, а ускорения не дала.

И цифра, которая отвечает на вопрос «сколько стоит поддержка»: без активного сопровождения их offline-точность уехала с ~95% до ~65% за месяц. Лечение — держать документацию в одном репозитории с кодом: markdown skill-ов лежит там же, где модели трансформаций, поэтому PR, меняющий модель, оказывается тем же PR, который правит документацию. Хук в code review помечает любое изменение отчётной модели, не затронувшее ни одного skill-файла. Сейчас примерно 90% их PR по моделям данных содержат правку skill в том же диффе.

↑ К оглавлению ^[17]

---

Часть 4. Где размещена сложность: vanilla-агент и тяжёлая обвязка

Сначала оговорка, без которой сравнение будет некорректным. Соблазнительно назвать это противоположными подходами, но сравнивались бы тогда разные уровни системы: у OpenAI «vanilla» относится к самому агенту и набору инструментов, а Anthropic описывает весь производственный контур целиком. Фундамент есть у обеих: у OpenAI — монорепо, владельцы таблиц и шесть слоёв контекста, у Anthropic — семантический слой с человеком-владельцем определений, канонические витрины и почти весь дата-код в одном репозитории с CI-проверками целостности между слоями.

OpenAI: простота агента — сознательный выбор. Один LLM на все запросы, тринадцать инструментов, никакого роутера. Сложность вынесена в платформу данных: каждая таблица порождается кодом в едином монорепо, за соблюдением конвенций и за дублирующимися колонками жёстко следят, у каждой таблицы есть владелец, критичность и требования к свежести.

Anthropic: без skills было 21% на их evals, чтобы улучшить, вокруг модели выросла обвязка: два вида skills, adversarial sub-agent, provenance-футер, evals как блокирующая проверка перед запуском домена, сбор корректировок из тредов.

Думаю правы оба. Разница между ними в том, где размещена сложность. OpenAI платит за порядок преимущественно в платформе данных. Anthropic платит там же, но дополнительно в runtime-контексте и в процессе поддержки. Поэтому и агенты на выходе получились разные.

Сходятся обе команды в одном: главная инвестиция — в контекст и фундамент, а не в саму модель.

Три компании по очереди убирали куски системы и публиковали, что получилось:

Средние в строке Vercel скрывают самое интересное. На худшем из пяти запросов старая архитектура потратила 724 секунды, сто шагов и 145 463 токена и всё равно провалилась. Новая ответила на тот же вопрос за 141 секунду, девятнадцать шагов и 67 483 токена, и ответила верно.

Про кейс Vercel важны две оговорки, и первую они ставят сами. Замер сделан на пяти запросах . И вывод авторов дословно: это сработало только потому, что их семантический слой уже был хорошей документацией; если ваш слой данных — каша из легаси-именования и недокументированных join-ов, прямой файловый доступ не спасёт, вы просто получите быстрые плохие запросы. Заодно поправка к хронологии: эта статья вышла 22 декабря 2025 года, то есть за полгода до публикации Anthropic.

Первые три строки в таблице выше говорят, что лишнее вредит.

Четвёртая что и экономия вредит: заменив дорогого adversarial-ревьюера дешёвым, Anthropic потеряла почти всю точность и даже не выиграла в скорости. Вместе они дают вывод точнее, чем «меньше — лучше»: не максимальная и не минимальная обвязка, а только та, чей вклад подтверждён замером с ней и без неё. Поэтому четыре отрицательных результата Anthropic полезнее их же 95%: цифра говорит, что у них получилось, а абляции — какие именно детали это дали. Про количество рассуждений то же самое независимо показывают DataBench и академические работы, к ним дальше.

Прежде чем идти дальше, надо обозначить границу доказательной базы. Почти все публичные кейсы принадлежат компаниям, которые продают аналитические продукты. Ближе всех к исключению GitHub: аналитику он не продаёт и описывает агента, сделанного для себя, хотя и он в теме агентов сторона заинтересованная. А вот первоисточника от компании, которая данными просто пользуется (банк, телеком, ритейл), я за июнь–август не нашёл, хотя искал специально.

Из производственных кейсов численную точность при этом не публикует никто, кроме Anthropic: GitHub говорит «точнее», но не говорит насколько, LangChain и Snowflake показывают использование, а не качество. Списывать это на один маркетинг не стоит — измерить точность аналитического агента действительно тяжело, и об этом дальше будет отдельная часть. Но когда вам в следующий раз скажут «все уже перешли на агентную аналитику», попросите три ссылки на первоисточники. А я перехожу к единственному найденному публичному стенду, где на одном наборе задач сразу видны и score, и стоимость, и время.

↑ К оглавлению ^[17]

---

Часть 5. Сколько это стоит и что получается: DataBench

Тринадцатого августа Hex опубликовал DataBench ^[22] сто реалистичных аналитических задач на том самом стенде Shorelane Commerce из части 2, где пять колонок можно с равным правом назвать «revenue». И это самый полезный внешний ориентир, который у нас есть, по одной причине.

Стенд собран с той самой обвязкой, которую прописывает Anthropic. Там есть dbt-модели, документация хранилища, события, триггеры и персоны стейкхолдеров со своими историями — 30 000 рукописных строк, шесть лет данных, миллионы строк, десятки таблиц. То есть фундамент, за который агитирует весь остальной текст, там уже стоит.

Лучший результат в срезе от 13 августа — 88 из 100. Потолком я это называть не буду: это лучшая из 32 конфигураций одного прогона, а не измеренный предел технологии.

Сразу про единицу измерения, потому что её легко прочитать неверно. Цена в лидерборде — это стоимость модельного прогона одной задачи целиком, а не одного обращения к модели: внутри такого прогона у агента десятки ходов, вызовов инструментов и SQL-запросов, и на Opus 5 High это восемь минут по медиане. Но только модельного прогона: включена ли туда работа самого хранилища, Hex не раскрывает, так что за полную стоимость ответа эти суммы принимать нельзя.

Колонку Tokens/Task тоже не стоит читать как расход задачи. У Opus 5 High там 42 тысячи токенов, а разобранный на той же странице прогон той же конфигурации показывает 2.4 млн входных и 54.3 тысячи выходных. То есть 42K описывают явно не весь оборот токенов, а что именно они считают, в лидерборде не сказано. И ещё деталь: цену Hex даёт как среднее по ста задачам, а время — как медиану. Среднее чувствительно к длинному хвосту, так что редкие затяжные прогоны подтягивают цену вверх сильнее, чем можно подумать по времени.

Вот выжимка из лидерборда. Полная таблица — 32 конфигурации, дата прогона 13 августа 2026, я снимал её вручную:

Вывод первый: разброс цены на порядки шире разброса качества

Luna на xHigh даёт 73% за девять центов. Opus 5 на High даёт 88% за $2.13 в двадцать четыре раза дороже за пятнадцать пунктов сверху.

Это разница в цене между двумя конкретными конфигурациями разных моделей, а не стоимость последних пунктов точности в одной системе. Кривую “Сколько стоит дополнительный пункт” из этого лидерборда не построить. Но масштаб разброса почти в сто раз, при разнице в качестве меньше чем в двое (стоимость прогона от $0.05 до $4.73).

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

И деталь, которая портит любую среднюю. На странице бенчмарка показаны две конкретные задачи. Первая — собрать список клиентов, которых надо обзвонить из-за проблем с оплатой, когда Commerce и Stripe расходятся в статусах подписок. Opus 5 на High решил её верно (107 аккаунтов, 3.19 и тринадцать минут**. Вторая — какие дубликаты OfficeMax слить перед подсчётом клиентов. Fable 5 на Max потратил $8.49 и двенадцать с половиной минут и получил 0% pass. Восемь с половиной долларов за неверный ответ.

Вывод второй: кривая усилий не монотонна, и здесь я расхожусь с самим Hex

Посмотрите на Opus 5 по уровням усилий:

На максимальном усилии модель возвращается ровно к результату минимального, потратив втрое больше денег. На опечатку это не похоже: обе строки стоят в одном лидерборде.

Доказательство при этом слабое. Лидерборд даёт по одному прогону на конфигурацию, без повторов и доверительных интервалов, а сто задач при пяти уровнях усилий означают, что несколько задач туда-сюда сдвигают процент на заметную величину. Так что «немонотонность» здесь — наблюдение, которое хорошо согласуется с академическими работами из части 7, а не измеренный эффект. Проверять его надо было бы повторными прогонами, которых у нас нет.

В тексте статьи Hex утверждает дословно: Fable 5 — «the only model where scaling test-time compute and effort consistently buys better outcomes without regressions». Их собственная таблица это не вполне подтверждает: Fable 5 идёт Low 72% → Medium 76% → High 71% → Max 85%, то есть на High просадка пять пунктов. Точнее было бы сказать так: среди моделей, протестированных на уровне Max, только Fable 5 заканчивает на своём максимуме, но и у неё в середине кривой есть регрессия. А монотонно растут по всем своим уровням GPT-5.6 Sol (65 → 71 → 72 → 75) и Luna (50 → 64 → 64 → 73), у которых уровня Max в таблице просто нет. Про Luna Hex это, к их чести, отмечает отдельно.

Ещё веселее у Terra: Low 70% → Medium 57% → High 63% → XHigh 68%. Самый дешёвый режим оказался лучшим.

Механику Hex описывает точно: на высоких усилиях модели «уговаривают себя» мимо правильного простого ответа к более сложному и неверному. Пример из их разбора. Клиент заплатил $92K за год и отменил подписку через четыре дня. На среднем усилии Opus 5 отвечает верно и коротко: доступ сохраняется до конца оплаченного периода. На максимальном — делает втрое больше работы, исчерпывающе доказывает по всем 916 отменам, что биллинг никогда не обрезает оплаченный период, и всё равно подстраховывается, предлагая дату отмены как возможную границу доступа.

Вывод третий: разрыв между «посчитать» и «сделать вывод»

По типам задач: сбор доказательств (Q&A) — 75%, открытые делегированные решения — 66%, а специально заложенные ловушки, где очевидный ответ неверен, дают худший результат.

Вот показательная ловушка. Вопрос: генерируют ли заказы, отправленные несколькими посылками, больше обращений в поддержку? Агент делает арифметику верно (корреляция действительно есть) и на этом объявляет причину найденной. Формулировка Hex: «It verified the counting right, but not the actual cause». А настоящий механизм в том, что заказ разбивается на несколько посылок не случайно: так происходит, когда товар разбросан по разным складам или заканчивается, а это и есть ситуации, которые сами по себе дают задержки и жалобы.

Галлюцинацией это назвать нельзя: цифры верные. Неверен переход от корреляции к причинности, и тон при этом абсолютно уверенный. Это и есть то, что Anthropic называет silent failure: ответ неверен, но выглядит правдоподобно и уходит дальше без возражений. И честно признаёт, что надёжного решения у них нет.

Второй пример из той же серии — ловушка с дубликатами после поглощения 2021 года. Fable 5 на максимальном усилии верно заметил, что ни одна из этих записей никогда не была связана с реестром клиентов, и всё равно порекомендовал слить сотню из них. Это тот самый прогон за $8.49 с нулевым зачётом.

Дисклеймер. DataBench — бенчмарк вендора, который продаёт этот же продукт. Сто задач, бизнес выдуманный, а правильность ответа определяет не проверка результата, а другая фронтир-модель, оценивающая ответ по подробным рубрикам. И никто, кроме самой Hex, эти задачи не прогонял: сверить её цифры не с чем, приходится верить на слово. Сама Hex, впрочем, публикует и пример сбоя своей модели-судьи: в одном тесте верный ответ — 2.04%, типичная ошибка агента — 2.03%, и судья принимал этот неверный ответ за верный в 35% прогонов. Разница в одну сотую процентного пункта для него была неразличима.

↑ К оглавлению ^[17]

---

Часть 6. Чужая цифра точности к вам не переносится

Судья, не отличающий 2.03% от 2.04%, — частный случай общей проблемы. Пора вернуться к вопросу, с которого началась статья: какая у дата-агента точность.

Сначала о том, что стоит за словом «точность» в источниках, которые я разбирал. Все три пишут проценты, но проверяют разное:

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

Дальше пару примеров почему может быть странным попытки приложить к своему стеку цифры с точностью из публичных лидербордов.

Хватает смены диалекта, чтобы результат уехал вдвое. Самый чистый эксперимент на эту тему поставили сами авторы Spider 2.0 ^[23]: взяли 180 случайных задач, разложили их одновременно на BigQuery и на Snowflake и задали один и тот же набор вопросов. На BigQuery решено 12.78% задач, на Snowflake — 6.6%. Вопросы те же, данные те же, меняется только диалект SQL. Какую модель они на этом гоняли, в работе не указано, но в обеих половинах она одна и та же, поэтому сравнение внутри себя корректно. Ваше хранилище тоже стоит на каком-то одном диалекте, и цифра, снятая на другом, о вашем случае уже ничего не говорит.

Название модели в чужом лидерборде говорит мало. На сайте Spider 2.0 стоит самая цитируемая в этой теме пара чисел: «у GPT-4o успех 10.1% на Spider 2.0 против 86.6% на Spider 1.0». Бенчмарки эти и правда очень разные. Spider 1.0 собран на учебных базах: в среднем 27 колонок на базу, эталонный запрос на 18 токенов, диалектных функций нет вообще. В Spider 2.0 схемы взяты из корпоративных проектов: около 800 колонок на базу, эталонный запрос почти на 150 токенов и шесть-семь специальных функций диалекта в каждом. Поэтому пара 86.6% → 10.1% и читается как приговор корпоративным схемам: на учебных базах модель справляется, на настоящих нет.

Но 86.6% принадлежат не голой модели, а методу DAIL-SQL ^[24], который подбирает к вопросу похожие примеры «вопрос → готовый SQL», укладывает их в промпт и голосованием выбирает лучший из нескольких сгенерированных запросов. И получен этот результат на другой модели и в другой год. Склейка модели, обвязки и постановки задачи в одну строку случается и у авторов бенчмарков.

Сколько в такой цифре обвязки, видно там же. В одной постановке текущего лидерборда Snow связка DAIL-SQL + GPT-4o стоит на 2.20%, а верх занимает Sentinel Agent v2 Pro компании Genloop с 96.70%. Девяносто четыре пункта на одних и тех же 547 задачах, с поправкой на то, что заявки приходили в разное время, а проверяющие скрипты обновлялись. Что создало разброс (модель, инструменты, число попыток, тюнинг под лидерборд) из таблицы результатов не восстановить. Направление подтверждается независимо: на ScienceAgentBench ^[25] при неизменных модели и задачах одна возможность выполнить код, увидеть ошибку и переписать поднимает Claude 3.5 Sonnet с 16.7% до 32.4%. И верхняя пятёрка Snow говорит о том же: Sentinel Agent v2 Pro, Native mini, QUVI-3 на Gemini 3 Pro, TCDataAgent-SQL от Tencent Cloud, Prism Swarm от Paytm собранные системы, а не модели.

Эталонные ответы, по которым всё это считали, сами с ошибками. В январе 2026 на CIDR вышла работа группы из UIUC с названием, не оставляющим места интерпретации: «Text-to-SQL Benchmarks are Broken» ^[26]. Авторы вручную проверили эталонные запросы двух широко используемых бенчмарков: в BIRD Mini-Dev ошибки разметки нашлись в 52.8% из 498 примеров, в Spider 2.0-Snow — в 66.1% задач, для которых опубликованы эталоны. Ошибки бытовые и узнаваемые: перепутанные широта с долготой внутри самого эталона, колонка с подготовительным классом там, где вопрос был про первый–двенадцатый, потерянный DISTINCT после JOIN. Есть и семь вопросов, где верный ответ забракуют за лишние кавычки в выводе.

Оговорки обязательны: аудит делался по срезу до того, как команда Spider 2.0 поправила часть формулировок в июле 2025, а 66.1% — доля среди 121 проверенной задачи, а не по всем 547. Так что связывать это напрямую с сегодняшним верхом лидерборда нельзя, и я не связываю.

Точность не принадлежит ни модели, ни классу «дата-агенты». Она принадлежит одной версии одной системы на заданном наборе вопросов, заданных данных и заданном протоколе проверки. Поменяйте любую из этих четырёх составляющих (саму систему, вопросы, данные или протокол), и результат уедет на десятки пунктов.

Поэтому ответ на вопрос про точность оказался неожиданным для меня самого. Я исходил из того, что проблема в закрытости: OpenAI цифру не опубликовала, отвечать нечем. Проблема в другом. Опубликуй они её — она описывала бы систему OpenAI на данных OpenAI по критериям OpenAI, и переносить её на ваше хранилище было бы примерно так же осмысленно, как переносить результат с BigQuery на Snowflake. Переносимой цифры точности не существует, и её отсутствие в статье OpenAI я теперь читаю не как скрытность, а как понимание, что публиковать нечего.

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

Это же причина, по которой я не тащу сюда свои 2400 прогонов на Spider. Они измеряли мою обвязку на академических схемах по чужим эталонам: три составляющие из четырёх не мои.

↑ К оглавлению ^[17]

---

Часть 7. Три родственных сбоя, которые воспроизводятся и в других задачах

Вернёмся к трём сбоям, которые уже встретились в кейсах Hex и Anthropic. Два пришли с лидерборда Hex, один из отрицательных результатов Anthropic.

Немонотонность усилий. Opus 5 на DataBench: 88% на High, 80% на XHigh, 70% на Max — максимальное усилие вернуло результат минимального за втрое большие деньги. У Terra лучшим вообще оказался самый дешёвый режим. Механика по разбору Hex: на высоких усилиях модель уговаривает себя мимо простого верного ответа к сложному и неверному — как в истории с отменой подписки за $92K.

Перегрузка контекстом. Anthropic дала агенту grep-доступ ко всему корпусу своего SQL — тысячи файлов из дашбордов, трансформаций и ноутбуков. Точность изменилась меньше чем на пункт в любую сторону, хотя ответ в корпусе лежал примерно в 80% случаев. Плюс три подряд отрицательные итерации на удлинении документации.

Уверенность вместо отказа. На ловушках DataBench, где очевидный ответ неверен, агент делает арифметику правильно и объявляет найденную корреляцию причиной — уверенным тоном и без оговорок. Ровно то, что Anthropic называет silent failure и признаёт, что надёжного решения у них нет.

Каждый из трёх легко списать на местную специфику: два на вендорский стенд, третий на внутреннее устройство одной компании. Но у всех есть близкие родственники в академической литературе, измеренные на других задачах и другими группами. Сразу оговорю границу этого аргумента, потому что она важна: ни одна из работ ниже не повторяет эксперимент DataBench на его же задачах. Их ставили на математике ^[27], на поиске в длинном контексте и на отказах от ответа, а не на корпоративной аналитике. Поэтому доказательством того, что DataBench прав, они не служат. Они показывают другое: у наблюдений Hex и Anthropic есть близкие аналоги за пределами одного вендорского стенда. Насколько одинаковы механизмы, лежащие под ними, — отдельный открытый вопрос.

Больше рассуждений — хуже ответ

Контролируемый эксперимент Zhou et al., Findings of ACL 2026 ^[28]: бюджет рассуждений принудительно увеличивали шагами по 500 токенов от 500 до 16 000 на моделях DeepSeek-R1-32B и s1-32B. На научных вопросах GPQA Diamond точность растёт до 10 тысяч токенов — с 41.4% на 2K до 55.6% на 10K — а затем падает: 54.9% на 12K, 53.1% на 16K. На математических AIME пик приходится на 12K (55.8%) с откатом до 54.9% на 16K.

Самая полезная метрика оттуда — «перевороты». Авторы отдельно считают, сколько ответов меняются с неверного на верный и сколько наоборот. На 7 тысячах токенов отношение впервые превышает единицу, то есть дальнейшее размышление начинает вредить чаще, чем помогать. К 16K оно доходит до 7.55. Ручной разбор 80 случаев: 67.5% негативных переворотов — настоящее передумывание, когда модель явно отвергает верный ответ, 20% уход в валидный альтернативный метод с арифметической ошибкой, и только 12.5% артефакт обрезки.

И деталь, которая точно ложится на историю с $92K: порог, за которым лишнее размышление начинает вредить, зависит от сложности задачи. Простые задачи (Level 1–2 в MATH-500) переходят его уже на 2 тысячах токенов, сложные (Level 5) — на 8 тысячах, а сами оптимальные бюджеты авторы оценивают в диапазоне примерно от 1 до 7.5 тысяч токенов. Вывод из этого осторожный: единый уровень усилий на все вопросы нельзя заранее считать оптимальным для разнородных задач — в этом эксперименте полезный бюджет существенно зависел от сложности вопроса.

Две оговорки. Эксперимент на математике и естественных науках, а не на аналитике. И часть эффекта могла бы объясняться принудительной остановкой рассуждения, но авторы это проверили: на образцах, где модель сама писала длинно без принуждения, спад точности такой же.

Больше контекста — хуже ответ

Термин Lost in the Middle ^[29] появился ещё в работе 2023 года. В эксперименте с двадцатью документами GPT-3.5-Turbo отвечал правильно в 75,8% случаев, когда документ с ответом стоял первым, и в 53,8% — когда его помещали в середину. Это оказалось хуже результата вообще без документов — 56,1%. Цифры относятся к модели прошлого поколения, поэтому сегодня интересны скорее как история обнаружения эффекта.

Более свежая проверка — NoLiMa ^[30], опубликованная на ICML 2025. Авторы прятали среди десятков тысяч токенов короткий искусственный факт и задавали вопрос без дословных совпадений с ним. Например, из фразы «Yuki живёт рядом с Semper Opera House» модель должна была по вопросу о Дрездене восстановить связь и найти Yuki.

На контексте 32K одиннадцать из тринадцати моделей потеряли больше половины своего результата на коротком контексте. GPT-4o снизился с 99,3% до 69,7%. Reasoning и CoT иногда смягчали падение, но не устраняли его.

Это не модель корпоративного data catalog и не прямое доказательство против загрузки всего каталога. Но риск показан чисто: даже когда нужный факт присутствует во входе, увеличение объёма постороннего контекста может затруднить его поиск. Поэтому полный каталог и отфильтрованный retrieval надо сравнивать на своих evals, а не исходить из правила «больше контекста — всегда лучше».

Модели не умеют говорить «не знаю»

AbstentionBench ^[31] собран из вопросов, на которые ответить нельзя: неизвестный ответ, недоопределённый контекст и прочие случаи, где правильное поведение ^[32] — сказать «не знаю». Главный результат: reasoning-тюнинг снижает способность к отказу в среднем на 24% по сравнению с теми же моделями без него. У DeepSeek-R1-Distill Llama 70B средняя точность ответов 0.81 (лучший результат в таблице), а recall отказов 0.46, почти худший. Модели, которые лучше всех отвечают, хуже всех молчат.

Связь с DataBench тут слабее, чем в предыдущих двух блоках, и это стоит сказать прямо. Ловушка с посылками — вопрос формально ответимый: данные есть, арифметика сходится, неверен переход к причине. AbstentionBench проверяет другое — вопросы, на которые отвечать нельзя вообще. Общий знаменатель у них не «отказ», а уверенный ответ при недостаточных основаниях.

Что действительно совпадает — форма кривой. Рост бюджета рассуждений с 512 до 4096 токенов улучшает точность, а отказ либо не улучшает, либо ухудшает. А в API o1 recall отказов по reasoning_effort на GPQA-Diamond идёт 0.63 на low, 0.78 на medium и 0.60 на high — немонотонность той же формы, что у Opus 5 на лидерборде Hex, только в другой метрике и у другого вендора.

Что из этого следует для аналитики. В AbstentionBench reasoning-тюнинг в среднем повышал способность отвечать и снижал способность воздерживаться. Значит, тестировать надо отдельно две вещи: правильные ответы на посильные вопросы и поведение ^[33] там, где данных для вывода не хватает. Второе почти никогда не попадает в набор тестов, и оно же срабатывает, когда бизнес просит посчитать что-то в разрезе, которого в данных нет.

Что из этого складывается в требования к своему eval

Часть 6 закончилась тем, что чужая цифра точности на ваш стек не переносится и мерить придётся самим. Три сбоя выше говорят, что именно должен покрывать этот замер, и это три отдельных класса задач:

1. Выбор уровня усилий. Вопросы разной сложности с фиксированным бюджетом рассуждений чтобы увидеть, где рост усилий перестаёт помогать и начинает вредить. Один общий уровень на все вопросы этот сбой не поймает, потому что усреднит его.

2. Лишний и устаревший контекст. Один и тот же вопрос при отфильтрованном retrieval и при полной выдаче каталога, плюс отдельно с устаревшей или противоречивой документацией внутри контекста. Здесь проверяется не знание, а устойчивость к шуму.

3. Вопросы, на которые правильный ответ — отказ. Разрез, которого в данных нет; метрика, определённая неоднозначно; период, за который данные не собирались. Отказ с объяснением здесь и есть верный ответ, его и надо оценивать.

Общий accuracy-score скроет все три: усреднит немонотонность по уровням усилий, не заметит деградации от шума, а там, где ответа в данных нет, уверенное «вот ваша цифра» зачтётся как обычная ошибка наравне с опечаткой в JOIN.

↑ К оглавлению ^[17]

---

Часть 8. Governance: раздел, из-за которого весь проект может не состояться

Даже агент, прошедший все три класса evals из части 7, не готов к продакшену, пока не определено, чьи права он использует и какие данные вообще может увидеть. Для банка, телекома или госкомпании это решающая часть, и она обычно втиснута в один абзац. Разберём подробно, потому что здесь я сам сначала сделал неверное обобщение.

Anthropic описывает свою схему в августовской статье про Slack ^[34] предельно прямо:

Claude Tag queries your warehouse as a service account, not as the human who asked the question. <…> everyone who can mention the bot has the bot’s data access. There is no per-user row-level security: what the service account can read, anyone in the channel can ask about.

Их собственная метафора: агент в Slack — это shared read replica вашего управляемого хранилища. Из неё они выводят пять практик:

1. Сервисный аккаунт — только на governed-данные. Их аккаунт читает выходные таблицы семантического слоя и питающие их curated marts. Не читает сырые события, staging и личные песочницы. Если вопрос требует данных за пределами этого контура — агент говорит об этом, а не угадывает.

2. Классификация PII на уровне колонок с отказом в допуске. Governed не значит безопасный: в curated-таблице может лежать email. Claude сканирует новые колонки и помечает кандидатов в PII, классификацию ставит человек, lineage разносит метку по производным таблицам. У сервисного аккаунта допуска к PII нет, поэтому колонки для агента просто не читаются — таблицу запросить может, чувствительные поля не видит.

3. Описание способа подключения внутри самого skill. Отдельная секция про то, как агент подключается — CLI, API или MCP — и как работает аутентификация для каждого пути. Скучная деталь, которая отличает «агент явно сообщил, что не смог подключиться» от «агент молча пошёл другим путём».

4. Добавление бота в канал равно выдаче доступа.

5. Метки на каждом запросе — канал, разговор, пользователь. Прав не даёт, но позволяет потом выяснить, кто задал вопрос, который обошёлся дороже всех остальных.

И правило старта, которое стоит повесить на стену: решите, что может читать сервисный аккаунт, до того как напишете первую строку кода агента. Расширить доступ потом легче, чем отобрать.

А теперь поправка, которую я должен сделать к самому себе

Начинал я эту статью с убеждения, что per-user row-level security у дата-агентов попросту не существует. Как утверждение о рынке это неверно: схема Anthropic — архитектурный выбор их Slack-деплоя, а не ограничение всей категории. Другие платформы документируют per-user enforcement прямо:

Правильный вопрос к вендору не «есть ли у вас RLS». Многие зрелые платформы его поддерживают, но само наличие RLS не означает, что агент исполняет запросы с правами конкретного пользователя. И даже вопрос «от чьего имени выполняется запрос» ещё недостаточен. Выяснять надо три вещи: по чьему authorization context хранилище проверяет доступ, в какой точке применяются row filters и column masks и сохраняется ли этот контекст на всём пути пользователь → агент → MCP или API → хранилище.

Почему одного вопроса про identity мало, лучше всего видно как раз на Databricks. Genie использует два разных credential: запрос идёт на SQL warehouse под compute-credentials того, кто настраивал агента (конечному пользователю права на warehouse вообще не нужны), а доступ к данным Unity Catalog оценивает по идентичности этого самого конечного пользователя, и row filters с column masks применяются при выполнении запроса. То есть техническая identity запроса и authorization context здесь разные вещи, и совпадать они не обязаны.

По этому критерию продукты делятся на три группы: те, где per-user enforcement описан в документации (таблица выше); те, где заявлены сильные политики доступа, но путь исполнения из документации не восстанавливается и проверять надо на стенде; и те, где всё решает конфигурация — например, dbt MCP поддерживает и персональные, и сервисные токены, так что итог зависит от того, как вы его развернёте.

Slack-бот на сервисном аккаунте это один из вариантов: осознанный обмен строгости прав на удобство. Для банка разница принципиальная.

И то, о чём в этих статьях не пишут вовсе

Наличие OAuth само по себе не гарантирует, что права конечного пользователя доедут до данных. OAuth делегирует авторизацию в границах конкретного resource, audience и scope, но автоматического переноса прав через всю цепочку не обещает. Дальше в MCP security guidance разобраны две разные вещи, которые легко спутать. Первая token passthrough: сервер принимает токен, выпущенный не для него, и пересылает дальше в downstream-сервис; спецификация это прямо запрещает. Вторая — confused deputy: посредника заставляют воспользоваться собственными полномочиями в интересах атакующего.

Публично описанные атаки и уязвимости:

• PromptArmor описал уязвимость в Ramp Sheets AI: инъекция, спрятанная во внешнем датасете, заставила ИИ вставить формулу, создающую исходящие сетевые запросы. Без подтверждения пользователя.

• EchoLeak (CVE-2025-32711) в Microsoft 365 Copilot — zero-click утечка данных через инъекцию. Не BI-копилот, но тот же класс.

• В экосистеме MCP опубликованы command injection (CVE-2025-54073), неаутентифицированный SSRF (CVE-2026-27826) и утечка серверных секретов через подставленный URL MCP-сервера (CVE-2026-32625). Последняя показательна: дыра не в самом протоколе, а в его интеграции внутри приложения — LibreChat подставлял значения переменных окружения в пользовательский URL при валидации схемы и отправлял JWT_SECRET и строку подключения к базе на домен атакующего. CVSS 9.6, права нужны минимальные.

Практический вывод: комментарии к таблицам, описания колонок, записи в каталоге метаданных и заголовки дашбордов становятся недоверенным вводом. Ровно те поля, которые мы всю статью призываем заполнять, становятся вектором атаки, если агент читает их как инструкции.

Одного осознания проблемы тут мало, нужны технические ограничения. Описания таблиц и колонок должны попадать модели как данные, а не как инструкции. И держаться защита должна не на одном промпте: нужен allowlist инструментов, read-only доступ, ограничение сетевого egress и явный запрет выполнять команды, найденные внутри метаданных.

И требования к проверяемости становятся жёстче, когда ответ читает не человек. В отчёте Vercel с конференции Ship 2026 ^[40] сказано, что d0 «now gets 45% of its questions from other agents, rather than people» — почти половина обращений к аналитическому агенту приходит уже от других агентов. Знаменатель под этой цифрой не раскрыт, но направление важнее точного значения: агент перестаёт быть интерфейсом для человека и становится инфраструктурным сервисом. Человек хотя бы иногда замечает, что число странное, и переспрашивает. Следующий агент, скорее всего, просто возьмёт его как входные данные и посчитает дальше. Поэтому и происхождение ответа, и права, под которыми он получен, и журнал вызовов нужны не для отчётности, а как единственный способ потом восстановить, откуда взялась цифра.

↑ К оглавлению ^[17]

---

Часть 9. Экономика: три статьи расходов, из которых обычно считают одну

После evals из части 7 и защитных контуров из части 8 у агента появляется не только качество и безопасность, но и своя структура расходов. И считать её по одному счёту за токены — та же ошибка, что принимать чужую цифру точности за свою: цифра есть, а к вашему случаю она отношения не имеет.

Считать надо полную стоимость одного верифицированного ответа и сравнивать её с тем, во что тот же процесс обходился до внедрения. Эта стоимость распадается на три статьи, из которых в бюджет обычно попадает первая, и то не целиком.

Статья первая: выполнение

Модель, агент и запросы к хранилищу тарифицируются независимо друг от друга, и это не деталь биллинга, а свойство архитектуры.

Snowflake разделяет их прямо. Через Cortex Agents счёт идёт в AI Credits за миллион обработанных токенов, ставка зависит от выбранной модели, а расходы складываются по всем сервисам, которые агент вызвал по пути — Analyst, Search и остальным. Standalone API Cortex Analyst устроен иначе: плата за тысячу сообщений, и считается она в Platform Credits, чья цена зависит от вашей редакции и региона. Цена самого AI Credit — $2.00 при глобальной маршрутизации и $2.20 при региональной: требование не выпускать запросы за пределы своего региона, обычно поставленное один раз на комплаенс-ревью, добавляет 10% ко всему счёту за AI. И главное, что стоит выписать дословно: «In both cases, executing the generated SQL incurs standard virtual warehouse compute charges». Выполнение сгенерированного SQL оплачивается как обычный warehouse, сверху.

В BigQuery при on-demand pricing оплачиваются обработанные данные (есть и capacity-модель, там иначе), так что разведочные запросы агента и его повторы бьют прямо в счёт.

Следствий два. Первое: токены — плохой прокси стоимости. Счёт формируют кэш-хиты и промахи, разные тарифы на вход и выход, повторы и разведочные запросы; сокращение числа токенов в логах само по себе не означает, что счёт уменьшился. Сравнивать надо биллинг до и после. Второе: счёт может убежать. Retry-петля без лимита, таймаута и алерта способна работать сутками, а каждая попытка тарифицируется заново, и в модели, и в хранилище. Kill switch и квоту на агента ставят до запуска, иначе они не успеют помочь.

Статья вторая: эксплуатация

Сюда попадает всё, что нужно, чтобы агент вообще работал, — и часть этого платится до первого вопроса.

Порог входа может превышать стоимость использования. Power BI Copilot требует платной ёмкости Fabric F2 или выше: «Only paid SKUs (F2 or higher, or P1 or higher) are supported». Что это стоит, я снимал вручную 28 августа 2026 для East US и West US 2: F2 идёт по 262.80 в месяц при непрерывно включённой ёмкости (730 часов — база расчёта самой Microsoft) или 1 876 до $3 154 ещё до первого вопроса агенту. Считать на свою дату и свой регион придётся заново: в West US та же ёмкость выходит в $292 в месяц, в Brazil South — в $408.80, а per-SKU суммы на странице цен подставляются скриптом и в документации Microsoft Learn не публикуются вовсе.

Дальше — то, что в смету попадает реже всего, хотя следует прямо из предыдущих двух частей: прогон evals на каждом изменении контекста, телеметрия с версиями skill и git SHA, хранение и разбор транскриптов, аудит доступов и те самые защитные контуры — allowlist, read-only, ограничение egress. Это не разовая настройка, а постоянная статья: обвязку вокруг skills, по формулировке самой Anthropic, надо регулярно подчищать.

Статья третья: стоимость результата

Самая важная и почти никогда не считаемая. Ответ агента не бесплатен в момент получения: его кто-то читает, проверяет, иногда переспрашивает, иногда переделывает. А иногда не проверяет и тогда счёт приходит позже и в другой валюте.

Сюда входят проверка человеком, исправления и цена ошибочного решения. Из части 5 уже есть готовая иллюстрация: $8.49 и двенадцать с половиной минут за ответ с нулевым зачётом, и это ещё дешёвый случай, потому что ошибку заметил судья бенчмарка. Убедительная ошибка, ушедшая дальше без возражений, стоит столько, сколько стоило принятое по ней решение. Этот класс сбоя Anthropic называет silent failure и признаёт, что надёжного решения у них нет.

Поэтому сравнение «token bill против зарплаты аналитика/затрат на лицензии BI» и ведёт не туда: оно подсказывает модель «агент вместо человека», тогда как всё предыдущее в статье говорит, что человеческое суждение и ответственность за число из контура не убираются.

Сравнивать надо полную стоимость одного верифицированного ответа — compute, хранилище, проверка, сопровождение, исправления — с тем, во что тот же результат обходился в прежнем процессе.

Как это мерить у себя

Вендорские ROI-заявления вида «отчёты выходят кратно быстрее» и «сэкономлены тысячи часов» встречаются без базы сравнения, знаменателя и периода. Это маркетинг, а не оценка. И «принятые ответы» как метрика тоже не годятся: пользователь может принять правдоподобный и неверный ответ — об этом половина статьи.

Считать стоит четыре величины:

1. верифицированные ответы, использованные без последующего исправления;

2. полную стоимость такого ответа;

3. время от вопроса до результата;

4. долю ошибок, обнаруженных позже.

И тут важно не спутать два инструмента. Evals из части 7 отвечают на вопрос до запуска: держит ли система заданную планку на известных вопросах. Ни «использован без исправления», ни «обнаружено позже» из них не получить — обе величины существуют только в проде и требуют трёх вещей: телеметрии по каждому ответу, канала обратной связи, где исправление фиксируется как событие, а не как реплика в треде, и окна наблюдения, за которое поздняя ошибка успевает всплыть. Evals показывают, чего ждать; телеметрия — что произошло. Без второй половины экономика считается отдельно от качества и всегда получается выгодной.

Когда в расчёт попадают не только токены, но и данные, контроль и цена ошибки, возникает естественный вопрос: не окажется ли вся эта обвязка дороже, чем просто дождаться следующего поколения моделей? Это и разберём дальше.

↑ К оглавлению ^[17]

---

Часть 10. А может, всё это лишнее?

Не получится ли у нас построить дорогую инфраструктуру вокруг ограничений, которые скоро исчезнут сами? Полностью — нет. Но три части этой обвязки действительно стоит поставить под сомнение.

Не обесценит ли всё следующая модель?

Этот риск прямо называет Anthropic. Их вопрос номер один при выборе подхода: насколько важен правильный ответ сегодня против в будущем? Компании часто строят инфраструктуру под слабости текущих моделей — слабости, которые исчезают со следующим поколением. Оговорки они делают сами: после нескольких десятков evals на тему отдача падает, и этот потолок снижается с каждым новым поколением моделей; обвязку вокруг skills надо регулярно подчищать — в их формулировке «we regularly prune skill scaffolding as models improve».

DataBench даёт этому численную иллюстрацию: Opus 4.8 на High — 70%, Opus 5 на High — 88%. Восемнадцать пунктов от одной смены поколения, без перестройки остальной системы; ручной настройкой такой прирост пришлось бы добывать заметно дольше. Две оговорки, и обе существенные. Это один прогон одного вендорского стенда, а не доказательство, что обвязка больше не нужна. И «одна строчка в конфиге» — правда только на стенде: в проде смена модели тянет за собой стоимость, безопасность и полный прогон регрессионных тестов.

Практический вывод из этого риска важнее самого прогноза: не привязывайте долговечные знания к временному интерфейсу. История естественных интерфейсов к данным история замен. Tableau Ask Data выведен из Tableau Cloud в феврале 2024 и из Server 2024.2. Legacy Power BI Q&A объявлен устаревшим с выводом в декабре 2026 и заменой на Copilot. Значит, контекст надо хранить отдельно от BI-вендора: интерфейс может исчезнуть раньше, чем внедрение окупится.

Обязательно ли собирать семантический слой?

MotherDuck поставила аккуратный эксперимент: собрала семантический слой на Malloy полностью агентно, без ручной правки, и получила рабочий результат — который при этом оказался дороже в эксплуатации, чем обычные Markdown и SQL: в 2.5 раза больше токенов, медленнее и точность 95% против 100%. Ожидаемого преимущества в извлечении контекста слой не дал вовсе.

Но главный их вывод не про Malloy. Как только намерение и способ проверки заданы явно, реализация становится одноразовой: слой можно выбросить, улучшить обвязку и сгенерировать заново — они делали это по многу раз в день. Формулируют они это так: «your data tests become more valuable than your semantic layer», а связующим звеном они прямо называют evals рядом с каждым ожидаемым поведением.

Легко прочитать это как «слой не нужен», но сами авторы так не пишут. MotherDuck не спорит с необходимостью единого смысла, они отдельно оставляют за семантическим слоем три роли: щит между изменениями моделей данных и потребителями, механизм протолкнуть одну правку метрики сразу всем и рамка, внутри которой эксперты удерживают детерминированность расчёта. Их тезис в другом: долговечным активом должны быть определения и тесты, а сам слой — их проекция. Спорят они не с выводом статьи, а с тем, где живёт долговечность. Версия MotherDuck при этом сильнее моей: она делает evals не проверкой качества, а основным носителем смысла.

А если проблема вообще не в агенте?

Опрос dbt Labs 2026 года (363 респондента, декабрь 2025 — февраль 2026): 71% обеспокоены тем, что галлюцинированные или неверные данные дойдут до стейкхолдеров. При этом 72% уже используют ИИ для написания аналитического кода, то есть внедряют быстрее, чем успевают выстроить доверие. Барьеры называют организационные: 41% — неясное владение данными, 36% — грамотность в данных у стейкхолдеров, а самой частой проблемой остаётся качество данных.

Практический вопрос здесь такой: тот же бюджет разумнее сначала потратить на качество данных, владельцев и грамотность пользователей, а не на skills и evals для агента? И я с этим соглашусь почти полностью. Эти проблемы первичны, агентная инфраструктура их не решает и не заменяет. Единственная поправка: она делает накопленный долг заметным. Пока с расхождением определений живут люди, они его обходят молча; агент на том же расхождении выдаёт уверенный неверный ответ в Slack-канал.

Чего мы всё ещё не знаем

Публичных постмортемов провалившихся дата-агентов с названным автором, датой, описанной системой и причиной отката не найдешь. Раскрытие провалов в этой области непривычно скудное, и это само по себе повод для скепсиса ко всей публичной картине, включая и мою.

Для себя я делю обвязку на два слоя.

Временный — промпты, роутеры и обходные пути под слабости конкретной модели; его надо регулярно подчищать, и следующее поколение его обесценит.

Долговечный — канонические данные, владельцы, определения метрик, права и evals; он описывает то, что бизнес считает правильным, и от модели не зависит. Модель поменяется, определение выручки останется. Строить поэтому стоит минимальное ядро, которое переживёт смену и модели, и интерфейса. Что в него входит — дальше.

↑ К оглавлению ^[17]

---

Часть 11. Что делать обычной команде

Не «постройте как Anthropic». У них другой бюджет и другие люди. Их же рекомендация для старта с нуля звучит скромно, и её стоит взять дословно: горстка канонических датасетов, несколько десятков offline-evals и один лёгкий knowledge skill (у них — «thin») дают большую часть выигрыша — всё остальное они добавляли потом.

Развернутый минимум. Числа в первых двух пунктах — моя эвристика, а не чей-то замер: Anthropic говорит «горстка» и «несколько десятков», конкретные интервалы я ставлю просто чтобы было от чего отсчитывать при планировании.

1. Один домен, 5–10 канонических витрин. Не всё хранилище. Тот домен, где вопросы повторяются и где вы точно знаете правильные ответы.

2. 20–50 evals, собранных из реальных провалов, а не придуманных, и с покрытием всех трёх классов из части 7: уровень усилий, шум в контексте, вопросы без ответа в данных. Сразу решите, что считать эталоном. Если это конкретное число, оно перестанет сходиться при следующей же загрузке данных, и тест начнёт падать не из-за агента: либо жёстко ограничьте вопрос закрытым периодом и зафиксируйте снимок данных, на котором эталон посчитан, либо оценивайте не число, а логику запроса — те же таблицы, фильтры и определение метрики.

3. Один knowledge skill как роутер: сначала семантический слой, дальше несколько десятков reference-файлов по домену.

4. Документация рядом с кодом. Markdown с контекстом лежит в том же репозитории, что и модели трансформаций. PR, меняющий модель без правки документации, помечается ревьюером.

5. Телеметрия с первого вопроса. Каждый прогон — строка в таблице: версия skill, git SHA, ID модели, pass/fail по каждому утверждению, токены, время.

6. Права до кода. Что читает сервисный аккаунт — решается первым.

7. Уровень усилий и модель — бюджетный параметр. Начните с дешёвой конфигурации и эскалируйте по тесту на неоднозначность, но как гипотезу, которую ваш же eval из пункта 2 должен подтвердить или опровергнуть. И поставьте лимит расхода с алертом, прежде чем пускать агента в петлю.

Весь этот список держится на одном допущении: определения метрик, логику трансформаций и права из вашего стека можно вытащить машинно. Без этого не выполняются пункты 2, 4 и 6 — половина минимума. Допущение сильное, и проверяется оно отдельно.

---

Часть 12. Как проверить, потянет ли ваш стек агента

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

Вот приёмочный тест, который стоит прогнать до того, как вы купите у BI-вендора агента или начнёте писать своего поверх его данных. Шесть шагов, и у каждого — свой смысл.

1. Создайте сложную вычисляемую метрику с вложенными выражениями и расчётом «период к периоду»: нарастающий итог с начала года, сравнение с прошлым годом (в Power BI эта группа функций называется time intelligence). Простую «сумму продаж» отдаст в выгрузке любой продукт, ломается всё на сложных.

2. Выгрузите проект целиком автоматизируемым способом — API, CLI или воспроизводимый файловый экспорт, годится любой machine-readable вариант. Если выгрузка возможна только руками из интерфейса, дальше можно не проверять: агенту вы такой контекст не отдадите.

3. Поменяйте одну формулу и сравните две выгрузки. В идеале в диффе видна одна изменённая строка. Если поменялся бинарник или дифф нечитаем, определения метрик не положить в git и не отревьюить в PR, а приём из части 3 держится на этом.

4. Импортируйте выгрузку в чистую инсталляцию, ничего не правя руками. Так видно, лежит ли в файле вся логика или половина осталась в настройках сервера.

5. Достаньте формулу и список прав скриптом, не открывая интерфейс. И проверьте, что в формуле есть смысл: она может ссылаться на переменную или флаг, собранные в скрипте загрузки. В Qlik мера запросто выглядит как Sum($(vSetYTD) Sales) извлечь такую формулу легко, только про «с начала года» в ней не сказано ничего. Достать нужно и всё, на что она ссылается.

6. Проверьте права на контрольном наборе. Добавьте тестовые строки, видимые только определённым ролям, и заранее выпишите, какой ответ должен получить каждый из трёх: сервисный аккаунт и два пользователя с разными правами. Сверяйте с этой матрицей, а не просто смотрите, различаются ли ответы: без контрольных строк результаты могут законно совпасть, если ограниченные данные на этот запрос не влияют.

Как читать результат. Провал на шагах 3 и 5 не обязательно значит, что слой закрыт наглухо: экспорт может существовать и быть полным, но не давать читаемого диффа или отдавать формулу без того, на что она ссылается. Для агентного контура разницы нет. Если определения метрик нельзя положить в git и отревьюить в PR, слой непригоден как версионируемый источник смысла как бы вендор ни называл свой формат открытым. Провал на шаге 6 это ловушка из части 8, только в вашей инфраструктуре: RLS в продукте может быть полноценным, но если агент ходит одним техническим пользователем, права конкретного человека ничего не значат. Anthropic выбрала такую схему сознательно, так что сам по себе это не стоп-сигнал. Плохо обнаружить это в проде.

Legacy ETL. Informatica PowerCenter и Oracle ODI умеют выгружать объекты и зависимости в machine-readable XML. Это лучше бинарного чёрного ящика, но ещё не готовый семантический контекст: правила разбросаны по выражениям и скриптам, часть runtime-параметров может жить снаружи, а чувствительные значения в ODI при экспорте шифруются. Парсить такую выгрузку можно. Но чтобы определения стали читаемыми, тестируемыми и пригодными для ревью, их придётся отдельно нормализовать вместе со всеми ссылками и порядком выполнения, то есть формально шаг 5 может пройти, а основная работа только начнётся.

Модели и внутренний eval. Self-hosted Qwen, DeepSeek, Llama и GLM технически реалистичны, если внешний API для ваших данных закрыт. Публичные русскоязычные execution-based наборы уже есть — PAUQ и более предметный RedSQL. Но ни один из них не воспроизводит вашу корпоративную схему, определения метрик и ограничения доступа. Поэтому внутренний eval из части 11 для вас не пожелание, а условие закупки: сравнивать вендоров всё равно придётся на своих данных и своих вопросах.

Итого по стеку. Воспроизводимо прямо сейчас, без всякого вендорского агента: канонические витрины, контекст в git, offline-evals как условие запуска, provenance-футер, метки на запросах, ограничение прав роли агента. Частично: семантический слой — не ждите идеального вендорского, начинайте с версионируемых SQL-витрин и контрактов метрик в YAML или Markdown. Самое трудоёмкое: автоматическая нормализация семантики из repository- и package-форматов в читаемые, версионируемые контракты.

Там, где бизнес-логика вынесена в SQL и Git, агент реалистичен уже сегодня. Там, где единственная версия истины заперта в кубе или пакете, LLM просто маскирует старый vendor lock-in новым чат-интерфейсом.

↑ К оглавлению ^[17]

---

Заключение: смысл, зафиксированный в версиях

BI не умер в феврале. И сейчас не умер, оба раза я так не думал, хотя заголовки были бойкие.

Что действительно произошло за полгода: индустрия перестала спорить об интерфейсе и начала описывать замену. Замена — это смысл, зафиксированный в версиях и покрытый регрессионными тестами, а чат в этой картине остаётся всего лишь способом задать вопрос. Определения метрик как код. Документация в том же PR, что и модель. Набор вопросов с известными ответами, который блокирует релиз. Футер под каждым ответом с указанием, откуда взято число и насколько оно свежее.

Дашборды при этом никуда не уходят. Они остаются тем, чем всегда были неплохи: согласованным набором KPI, где число одно и утверждено. Агент забирает длинный хвос, те вопросы, которые раньше уходили в очередь к аналитику и умирали там.

Про сами цифры важно не перепутать направление. Переход от 21% к >95% Anthropic связывает с добавлением skills поверх уже существовавшего управляемого фундамента и с процессом их поддержки: семантический слой и канонические витрины стояли у них в обеих конфигурациях, так что разницу объясняют не они. А самые опасные из ошибок, которые остаются после всего этого, упираются в суждение: выбрать правильную сущность из пяти похожих, заметить ловушку, не превратить корреляцию в причину и сказать «по этим данным так не считается». Здесь решения нет даже у тех, кто делает модели, поэтому держите человека в контуре там, где число влияет на решение.

А вы уже попробовали отказаться от затрат на BI и полностью отдаться дата-агентам? Расскажите что получилось в комментариях

↑ К оглавлению ^[17]

---

Источники

Первоисточники с измеренными результатами

1. Anthropic: How Anthropic enables self-service data analytics with Claude ^[18] — 21% без skills, ~95% в агрегате, дрифт до 65%, четыре отрицательных абляции

2. Anthropic: Self-service data analytics in Slack ^[34] — сервисный аккаунт, пять практик governance

3. ByteByteGo: интервью с Эммой Тан, OpenAI ^[16] — обновлённые цифры платформы, с 40 до 13 инструментов

4. OpenAI: Inside our in-house data agent ^[41] — исходная статья, шесть слоёв контекста

5. GitHub: How we built an internal data analytics agent ^[42] — Qubot, структурированный контекст в 3 раза быстрее

6. Vercel: We removed 80% of our agent’s tools ^[21] — 22 декабря 2025, замер на 5 запросах, и оговорка про хороший семантический слой как условие успеха

7. Vercel Ship 2026 recap ^[40] — 45% вопросов к d0 приходят от других агентов

8. LangChain: agent-first data stack ^[43] — 40x объёма, 2200 диалогов

9. Snowflake: Building an internal context layer for AI agents ^[44] — 400 пользователей и 5400 запросов за июль 2025, отрицательный результат по латентности на сырых event-таблицах

Бенчмарки и академия

1. Hex: Introducing DataBench ^[22] и лидерборд ^[45] — прогон от 13 августа 2026

2. Hex: How we built a lab to evaluate data agents ^[46] — пять колонок «revenue», сбой судьи на 2.03 против 2.04

3. Jin, Choi, Zhu, Kang. Text-to-SQL Benchmarks are Broken (CIDR 2026) ^[26] — 52.8% и 66.1% ошибок разметки

4. AbstentionBench ^[31] — reasoning-тюнинг снижает отказ на 24%

5. Zhou et al. When More Thinking Hurts (Findings of ACL 2026) ^[28] — пик на 10K токенов, кроссовер переворотов на 7K

6. Lost in the Middle ^[47] — деградация от позиции и объёма контекста; NoLiMa ^[48] (ICML 2025) — то же на 13 моделях с окном 128K и больше

7. ScienceAgentBench ^[25] — 16.7% против 32.4% от одной только петли self-debug

8. Статья про Spider 2.0 ^[23] — эксперимент с диалектами лежит в приложении C.4; лидерборды Snow / Lite ^[49], DAIL-SQL ^[24], BIRD ^[50] — протоколы и результаты, на которые опирается часть 6

9. PAUQ ^[51] и RedSQL ^[52] — публичные русскоязычные text-to-SQL наборы с execution-based оценкой

Governance и безопасность

1. MCP: Security Best Practices ^[53] — token passthrough и confused deputy как отдельные разделы

2. PromptArmor: Ramp’s Sheets AI exfiltrates financials ^[54]

3. NVD: CVE-2025-32711 ^[55] — EchoLeak в Microsoft 365 Copilot; CVE-2025-54073 ^[56] — command injection в mcp-package-docs; CVE-2026-27826 ^[57] — неаутентифицированный SSRF в mcp-atlassian; CVE-2026-32625 ^[58] — утечка переменных окружения через MCP-интеграцию LibreChat, CVSS 9.6

4. Документация per-user enforcement: Databricks Genie ^[35], Fabric Data Agent ^[36], BigQuery Data Agents ^[37], Conversational Analytics в Looker ^[38], Tableau Agent ^[39]

5. VeloDB База данных для аналитики реального времени и ваших AI-агентов. RLS security, data masking https://datalakehouse.kz ^[59]

Опросы и экономика

1. dbt Labs: State of Analytics Engineering 2026 ^[60] — 363 респондента, 71% про неверные данные у стейкхолдеров

2. Snowflake Cortex pricing ^[61] — как считается стоимость: AI Credits за токены и warehouse-compute за выполнение SQL отдельно

3. Microsoft: Copilot in Fabric FAQ ^[62] — минимум F2, и страница цен Fabric ^[63], где суммы по SKU подставляются скриптом (значения в тексте сняты 28 августа 2026 для East US)

4. MotherDuck: AI writes the semantic layer ^[64] — реализация как одноразовый артефакт, evals как долговечный

5. Выводимые из эксплуатации интерфейсы: Tableau Ask Data ^[65], Power BI Q&A ^[66]

Форматы legacy ETL

1. Informatica PowerCenter: Exporting Objects ^[67] — экспорт объектов репозитория в XML

2. Oracle Data Integrator: Exporting and Importing ^[68] — XML-экспорт объектов, зависимостей и шифрование чувствительных данных ключом экспорта

---

Автор — Александр Полоротов (Alex Polorotov), co-founder Datanomix.pro. Создаю сообщество лидеров управления данными в Центральной Азии THECDO Telegram: @apolorotov ^[69]