Агент над данными: почему одного SQL недостаточно

Возьмём учебный пример. В таблице заказов две записи: на 100 и 200 денежных единиц. У первого заказа два частичных возврата — 20 и 30. Для этого примера договоримся, что выручка после возвратов равна сумме заказов минус сумме возвратов. Правильный результат — 250.

Агент соединяет таблицы через LEFT JOIN, сохраняя заказы без возвратов, и суммирует обе колонки. Первый заказ появляется в соединении два раза. Сумма заказов становится 400, возвраты составляют 50, результат — 350. Синтаксис корректен, база довольна, никаких исключений. Ошибка живёт в уровне детализации данных: одна строка заказа встретилась с несколькими строками возвратов.

Модель может исправить запрос, сначала агрегировав возвраты до заказа. Но в реальной задаче следующим слоем появится смысл: считать выручку по дате оплаты или признания, вычитать ли налог, куда относить возврат за прошлый месяц. Эти правила нельзя надёжно восстановить из названий колонок. Иногда нужный следующий шаг — найти определение метрики или задать вопрос владельцу данных.

В обычной задаче разработки тест часто уже существует рядом с кодом. Для аналитического вопроса тест ещё нужно сформулировать. Поэтому способность написать SQL — только часть работы. Агент должен добраться до смысла, построить вычисление и предъявить основания считать результат правильным.

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

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

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

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

Первый путь — встроенный агент. По документации Databricks Genie Code работает с блокнотами, SQL, заданиями и другими поверхностями платформы; использует документацию, Unity Catalog и код рабочего пространства. Snowflake Cortex Code (CoCo) интегрирован со схемами и ролевой моделью Snowflake. Выигрыш такого подхода нужно искать в коротком пути от вопроса к нужному контексту и действию.

Второй путь — привычный кодовый агент с подключёнными инструментами данных. Например, dbt MCP предоставляет доступ к моделям, метрикам, происхождению и свежести данных, а также к поддерживаемым действиям. В зависимости от настройки это локальный сервер или управляемое удалённое подключение. Сам MCP не выбирает правильную метрику и не создаёт политику доступа: он даёт интерфейс, через который эти возможности становятся доступны клиенту.

Третий путь — собственная среда вокруг модели: каталог, исполнение SQL/Python, состояние сессии, ограничения и проверяющий модуль. Её имеет смысл собирать, когда предметные правила или несколько платформ плохо укладываются в готовую интеграцию. Цена — собственная ответственность за изоляцию задач, обновления адаптеров, трассировку и воспроизводимость.

Эти варианты могут пересекаться. Встроенный агент способен вызывать внешние инструменты, универсальный — пользоваться семантическим слоем. Для выбора важнее пройти весь путь конкретной задачи. Есть ли у системы определение нужной метрики? Может ли она увидеть ошибку задания? Получает ли только разрешённые строки? Чем подтверждает исправление? Число интеграций само по себе на эти вопросы не отвечает.

В сравнении Snowflake CoCo и Claude Code с одной моделью Opus 5 получили соответственно 73,8 % и 69,6 % успешных попыток; средняя стоимость попытки составила $0,756 и $2,959. Это около 4,2 процентного пункта качества и примерно 3,9 раза по стоимости. Результат интересен именно совместным движением качества и затрат.

Но в сноске есть существенное условие. В запусках 3–5 августа 2026 года CoCo использовал нативный доступ к схеме и метаданным Snowflake, а другие агенты — стандартные SQL-интерфейсы; настройки оставались по умолчанию. Общая модель здесь не делает инструменты одинаковыми. Измерен эффект пакета «обвязка плюс интеграция». Это полезный ответ покупателю системы, но недостаточный ответ исследователю отдельного агентного цикла.

Ещё одна цифра того же отчёта — 64,1 % задач, решённых CoCo во всех трёх повторах. Она ниже средней доли успеха 73,8 %. Средняя доля успешных попыток и успех во всех трёх запусках — разные свойства; второй ближе к вопросу о повторяемости результата.

Databricks сообщает о 76,6 % и $0,55 у Genie Code против 72,1 % и $1,09 у ближайшего конкурента на 401 внутренней задаче с лимитом 20 минут. Здесь речь об одном классе передовых моделей, а не об идентичной модели. Кодовые агенты работали в собственных обвязках, но все участники были подключены к Databricks MCP. Конкуренты обезличены, корпус закрыт. Кроме того, Genie Ontology в эксперименте была отключена: приписать ей наблюдаемый выигрыш нельзя.

Оба отчёта дают основания проверять специализированную среду на своей работе. Они не устанавливают универсального победителя. Сравнение готовых продуктов и выделение вклада одного компонента требуют разных экспериментов; скрывать эту разницу за словами «одна и та же модель» особенно легко.

Одного корпуса для всех задач данных не хватает. Исправление проекта dbt, анализ платёжных файлов, уточнение вопроса пользователя и управление интерфейсом облачной платформы предъявляют разные требования. Хороший результат на коротких SQL-запросах мало говорит о восстановлении упавшего задания.

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

Для первого сравнения я бы взял data-eng-bench, ADE-bench и открытые 60 задач DataSpace. Первый даёт проверяемое изменение состояния данных, второй удобен для измерения вклада навыков, третий расширяет работу за пределы одного SQL-диалекта и одного типа файлов. Их результаты следует показывать раздельно: усреднение трёх процентов скроет различие задач.

Версия корпуса — часть результата. Например, в Data Agent Bench v3 от 7 октября 2026 года уже 104 запроса, 17 наборов данных и четыре СУБД; ранняя версия содержала 54 запроса. В рейтинге также различаются подсказки и специально настроенные промпты. Название бенчмарка без ревизии и режима запуска не определяет сопоставимый эксперимент.

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

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

Для воспроизведения нужно фиксировать и версию этой среды. Исторические результаты до перехода на Data Workbench Runtime 1.0 нельзя автоматически объединять с новыми. Точно так же один провайдер модели не гарантирует один снимок весов, одинаковую обработку запросов или одинаковый режим рассуждений.

Что должно попасть в паспорт запуска

1. Модель и все её вызовы. Точный идентификатор, провайдер, параметры генерации, лимиты вывода, вспомогательные модели и фактические значения в трейсе. Если провайдер не обещает неизменный снимок, это ограничение результата.
2. Среда. Ревизии корпуса и обвязки, образ контейнера, снимок базы, версия схемы и документов, часовой пояс, права, доступ к сети и набор инструментов. Каждая попытка начинается с чистого состояния.
3. Бюджет. Одинаковый лимит времени и заранее определённые ограничения затрат. Число шагов отдельно: один шаг разных агентов может скрывать разное число вызовов и запросов.
4. Независимая проверка. Агенту доступны условия задачи и рабочие проверки; эталоны и итоговые тесты остаются вне его среды. Интернет ограничивается так, чтобы нельзя было скачать опубликованные решения.
5. Повторы и ошибки. Одни и те же задачи для всех вариантов, несколько независимых попыток, чередующийся порядок запусков. Сбой инфраструктуры, неверный ответ и превышение бюджета учитываются раздельно.

Особенно поучительна инструкция адаптера CoCo для data-eng-bench: значение model_name в YAML может перекрыть модель из командной строки, а reasoning_effort адаптер принимает, но не применяет. Поддержка параметров отключения инструментов тоже зависит от версии Harbor. В документации эти оговорки привязаны к Harbor 0.22.0 и CoCo 1.1.66. Команда, которая выглядит симметрично, ещё не доказывает симметричность запуска.

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

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

Стоимость принятого результата = затраты всех попыток, вычислений, проверки и исправлений / число принятых результатов.

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

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

Публичные корпуса помогают отсеять слабую конфигурацию, но плохо покрывают особенности конкретной компании. Внутренний набор стоит дополнить случаями с устаревшей документацией, опоздавшими событиями, правами на строки, изменённой схемой и неясной бизнес-метрикой. Правильным исходом части таких задач будет уточнение или обоснованная остановка. Если оценивать только получение числа, стенд будет поощрять уверенную выдумку.

Первый этап — проверить сам стенд. В ADE-bench для этого есть агент sage, использующий контрольное решение без вызова модели. Затем на малой выборке надо убедиться, что сбрасывается база, видны все вызовы модели, работают ограничения и итоговая проверка действительно ловит неверный артефакт. Иначе красивый график будет описывать особенности запускателя.

Дальше я бы выбрал три доступные обвязки с общей моделью. Если одна из них не поддерживает этот сервер или режим, её стоит вынести в отдельное сравнение продуктов. Для первичного отбора — fast-30 в data-eng-bench, по три попытки на задачу. Итоговую оценку — на оставшихся задачах с зафиксированными настройками; результат всего корпуса при необходимости показывать отдельно, обозначив использованную для настройки часть. Открытый поднабор DataSpace добавить как проверку переноса на другой тип работы.

Отдельным опытом в ADE-bench оставить одну обвязку и одну модель, сравнив отсутствие дополнительных навыков с набором dbt. Это уже понятная проверка одной гипотезы. Для подключения MCP потребуется учесть ограничение поставляемого набора на Snowflake; объявлять такой опыт целиком локальным с DuckDB нельзя.

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

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