Создаём более качественный бенчмарк для агентов по работе с данными

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

Для нас, специалистов по данным самых разных направлений, сигналы неоднозначны. Согласно недавнему исследованию Anthropic, специалисты по анализу данных уже используют ИИ, чтобы помогать себе выполнять или автоматизировать 46 процентов своей работы. За два года большие языковые модели (LLM) научились хорошо писать код; теперь они ещё и очень хорошо пишут SQL.¹

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

А может ли ИИ делать это? Конечно, Claude Code может посчитать количество аккаунтов в таблице dim_accounts, но способен ли он разобраться, чем отличаются 24 разных объекта аккаунтов в стандартной схеме Salesforce? Сможет ли он понять, что означает «аккаунт», если у маркетинговой команды одно определение, у отдела продаж — другое, а у команды разработки — третье? Сможет ли он решить безнадёжную задачу маркетинговой атрибуции? Сможет ли он сказать «нет»?

В прошлом году при поддержке dbt Labs и Macro, инструмента автоматической оптимизации контекста для аналитических агентов, мы взялись создать бенчмарк, который помог бы ответить на эти вопросы. Хотя сообщества специалистов по данным и инженеров уже создали ряд бенчмарков для аналитики и науки о данных (из некоторых мы многое позаимствовали и очень за это благодарны), большинство из них проверяли, насколько хорошо агенты выполняют конкретные технические задачи, например пишут SQL-запросы или разрабатывают прогнозные модели. Нашей целью было создать новый бенчмарк с открытым исходным кодом, который проверяет, как ИИ-агенты работают в реалистичных средах данных: с большими базами данных, в многослойных проектах dbt, решая сложные задачи аналитики и инженерии данных.

Так появился проект ADE-bench.

Как работает ADE-bench

ADE-bench, во многом вдохновлённый terminal-bench и Spider 2.0, состоит из двух основных компонентов:

• Среды данных
• Задачи

Среды данных

Среды данных — это сочетания проектов dbt и баз данных. Проекты dbt могут быть сколь угодно простыми или сложными, но большинство проектов в ADE-bench содержит полный набор моделей данных для соответствующей базы: слои staging, промежуточные слои и витрины данных; макросы; сторонние источники и связанные с ними пакеты dbt. Такая сложность совершенно намеренна: именно в подобных средах мы и хотели тестировать агентов.

Затем эти проекты запускаются на базах данных DuckDB и Snowflake.² DuckDB мы выбрали из соображений удобства: базы данных DuckDB можно передавать в виде отдельных файлов и запускать локально без сложных требований к хостингу или сторонних сервисов. Поскольку многие компании используют свои инструменты для работы с данными в промышленной эксплуатации поверх крупных облачных баз данных, таких как Snowflake, ADE-bench также включает скрипты, которые автоматически создают изолированные схемы в Snowflake, загружают в них базы данных DuckDB и адаптируют проекты dbt к диалекту SQL Snowflake вместо DuckDB.

Задачи

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

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

1. Создать изолированную среду данных. ADE-bench запускает отдельный контейнер Docker для задачи. Он загружает в контейнер соответствующий проект и, если задача выполняется в Snowflake, создаёт там изолированную базу данных.
2. Запустить скрипт подготовки для конкретной задачи. Поскольку значительная часть реальной работы команд по данным состоит в исправлении того, что сломалось (данные поступают в базу в некорректном виде; модели dbt рассинхронизируются; все мы знакомы с этими ужасами), задачи также могут включать скрипты, которые перед тестированием изменяют среду данных только для этой задачи. Чаще всего эти скрипты вносили ошибки, которые агент должен был исправить, или удаляли модели, которые мы хотели попросить агента создать.
3. Передать изолированную среду агенту. ИИ-агент получает проект, базу данных и задание. Затем ADE-bench ждёт, пока агент сообщит, что закончил.
4. Зафиксировать изменения агента. Когда агент завершает работу, ADE-bench делает снимок всех внесённых им изменений. В итоговых результатах они представлены в виде diff.
5. Оценить результат. Внесённые изменения проходят оценку. ADE-bench включает ряд стандартных типов тестов, например сравнение таблицы с эталонным решением или проверку наличия модели dbt.
6. Всё очистить. ADE-bench сохраняет результаты всех тестов и журналы работы агента, а затем удаляет контейнер.

Более подробную информацию о работе ADE-bench и его настройке можно найти в документации на GitHub.

Как и почему изменилась цель ADE-bench

Когда мы только начали разрабатывать ADE-bench, нашей первоначальной целью было сравнить, как разные модели справляются с различными аналитическими задачами. Мы хотели получить рейтинг: какую LLM стоит использовать? Насколько лаборатории приблизились к созданию модели, способной выполнять настоящую аналитическую работу?

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

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

Внутренний агент OpenAI для работы с данными построен на внутренней базе знаний и «контексте компании» из таких источников, как Slack, Google Docs и Notion. Описывая своего внутреннего агентного аналитика данных, компания Ramp отметила, что без бизнес-контекста он бы не работал:

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

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

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

Это создаёт фундаментальную проблему для разработки аналитических бенчмарков. Если самый эффективный способ улучшить аналитического агента — дать ему больше бизнес-контекста, синтетический тест в изолированной среде всегда будет неполным. Можно представить такой разговор: «Ваш ИИ-аналитик занял восьмое место в этом бенчмарке, и это не выглядит хорошим результатом», — говорит руководитель команды по данным. «Ну да, — отвечает поставщик, — потому что в этом бенчмарке при ответах на вопросы не используется наш проприетарный Enterprise Decision Context Hub™». И поставщик был бы по-своему прав. Если бенчмарк предназначен для сравнения разных продуктов, он не может исключать важнейший способ, которым эти продукты отличаются друг от друга.

Более того, для большинства внутренних команд по данным управление контекстом (улучшение документации; добавление переписки из Slack или записей встреч во внутреннюю базу знаний; создание репозитория с примерами запросов) — самый действенный способ получить больше пользы от современных ИИ-продуктов. Когда мы впервые представили ADE-bench на Coalesce 2025 (теперь dbt Summit), именно это люди сразу же и захотели узнать: не какую модель использовать, а какие архитектурные конфигурации работают лучше всего.

Так как же создать бенчмарк, который ответит на этот вопрос?

Три способа создать более качественный бенчмарк

Создать полноценный бизнес-кейс

Большинство бенчмарков, включая наш, стремятся охватить разные предметные области. Есть наборы данных о SaaS-бизнесе, электронной коммерции, а иногда — о спорте, науке и других темах, не связанных с бизнесом. Хотя такое разнообразие полезно, более качественный бенчмарк мог бы сосредоточиться на одной компании и попытаться смоделировать как можно больше окружающего её контекста. Вероятно, это неосуществимо (как подделать записи звонков?), но в мире агентов, общающихся друг с другом, случались вещи и постраннее.

Найти нескольких «спонсоров» бенчмарка

Более реалистичный вариант — существующая компания могла бы стать «спонсором» бенчмарка, предоставив для тестирования свои данные и свой контекст. Для этого необязательно публиковать данные компании; вместо этого несколько компаний могли бы взять на себя поддержку внутреннего бенчмарка и регулярно проверять на нём новых агентов. (Для бенчмарков программирования уже есть подобный прецедент.)

Однако здесь есть две сложности. Во-первых, внутренним бенчмаркам по определению труднее доверять, особенно если ими управляют компании, которые также продают собственных агентов. Во-вторых, в отличие от агентов для программирования, которые часто представляют собой терминальные приложения, работающие с кодовой базой, многие аналитические агенты — это SaaS-продукты, подключающиеся к другим SaaS-сервисам и требующие настройки для полноценной работы (например, они работают внутри базы данных вроде Snowflake или Databricks, управляют собственной документацией и т. д.). Поэтому одной компании сложно, хотя и не невозможно, тестировать сразу множество агентов.

Упростить компаниям проведение собственных тестов и обмен результатами

Прямо сейчас сотни команд по данным пытаются понять, что работает, а что нет. В этих экспериментах наверняка много вариантов (разные агенты, настройки, промпты, предметные области), но у большинства команд по данным есть гораздо более важные повседневные задачи. Поэтому мы надеемся, что ADE-bench станет полезной отправной точкой. Команды могут заменить наши задачи своими и использовать копии собственной базы данных и репозитория dbt для разработки своих тестов.

Если вы хотите попробовать, хорошая отправная точка — канал #tools-ade-bench в Slack-сообществе dbt.

Как создавать собственные задачи

Вот несколько самых важных уроков, которые мы извлекли при разработке тестов:

Промпт так же важен, как и сама задача

Поначалу мы хотели проверять разные типы аналитических задач: могут ли агенты исправлять синтаксические ошибки? Могут ли работать с макросами dbt? Могут ли создавать новые модели? Первые задачи должны были стать простыми тестами, а последние — более сложными.

Однако тип задачи часто имел меньшее значение, чем то, как она была описана.

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

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

Задавайте вопросы о самих данных

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

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

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

Проверяйте их работу

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

Ничего из этого не видно в итоговой отметке о том, пройден тест или нет. Но это видно в diff-файлах и журналах цепочек рассуждений — и то и другое ADE-bench сохраняет.

При разработке тестов эти журналы были не менее полезны, чем сами результаты. Они дают представление о том, как агент «думает» и какие предположения делает о разных типах задач. Да и просто чтение этих журналов позволяло увлекательно, а иногда и жутковато заглянуть в «мозг» LLM и увидеть, как модели рассуждают, решая задачи с данными. В нескольких случаях, особенно в задачах, где агенту требовалось отвечать на аналитические вопросы, модели рассматривали такие аспекты, о которых мы не подумали.

Помните: тест — не сама реальность

Кстати об аналитических вопросах: одна из главных трудностей при проверке того, насколько хорошо агент решает аналитические задачи, состоит в том, что многие такие вопросы не имеют точных ответов. «Какая маркетинговая кампания показала лучшие результаты?» — это вопрос, который, во-первых, часто встречается, во-вторых, важен для хорошего агента и, в-третьих, очень расплывчат. Но хороший бенчмарк не может игнорировать подобные вопросы лишь потому, что ответы на них трудно оценивать; в конце концов, именно на такие вопросы люди и хотят получать ответы.

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

Например, вот вопрос из ADE-bench:

Я попросил аналитика выяснить, стали ли гонщики со временем ездить быстрее или медленнее. Чтобы помочь мне разобраться, аналитик создал новую модель analysis__lap_times с тремя столбцами:

• circuit_name: Название трассы.
• race_year: Год проведения гонки.
• avg_adjusted_lap_time_in_ms: Среднее время круга в миллисекундах с поправкой на время пит-стопов.

Какие из перечисленных ниже проблем есть в этом анализе? Выберите все подходящие варианты.

• A. Он не учитывает изменения трассы.
• B. Он некорректно обрабатывает неполные или незавершённые круги.
• C. Он дважды учитывает время кругов с несколькими пит-стопами.
• D. На время круга могут влиять предупреждающие флаги.
• E. Поправка на пит-стопы рассчитана неверно.
• F. Он оценивает время круга по гонкам, а не по гоночным трассам.

Создайте модель dbt с именем analysis__answer, содержащую одну строку и один столбец с именем answer. Укажите буквы правильных ответов. Например, если правильные ответы — A и B, значение должно быть "AB".

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

Делитесь тем, что узнаёте

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

Мы с энтузиазмом продолжаем работать над этим проектом и экспериментировать с новыми способами проведения экспериментов. И будем рады, если вы присоединитесь к нам.

Footnotes

1. С одной стороны, можно возразить, что точность запросов в 97 процентов слишком низка, если вы готовите отчётность по критически важным финансовым показателям или принимаете важные стратегические решения. С другой стороны, как человек, у которого с первого раза правильными оказываются лишь 76 процентов запросов, я впечатлён результатом в 97 процентов. ↩

2. Мы рассматривали поддержку большего числа баз данных, но пришли к выводу, что это, вероятно, не оправдает затраченных усилий. Передовые LLM уже настолько хорошо пишут SQL, что редко спотыкаются на каком-либо из основных диалектов SQL. Кроме того, мы собирались проверять не то, насколько хорошо агенты пишут на разных вариантах SQL, а то, насколько хорошо они ориентируются в сложных средах с большими и запутанными моделями данных. В такой задаче результаты вряд ли различались бы в зависимости от базы данных настолько, чтобы оправдать поддержку множества дополнительных типов баз. ↩

3. Когда промпты были расплывчатыми, агенты склонны были проявлять избыточное рвение. Они часто находили проблему, которую мы и хотели, чтобы они обнаружили, но затем иногда вносили и другие изменения. Похоже, это вполне в их природе. ↩

4. По этой причине ADE-bench позволяет создавать несколько вариантов промпта для одной и той же задачи. ↩