1 
Содержание
Astronomer представила de-bench — набор из 139 задач, построенных на реальных производственных окружениях Apache Airflow. Инструмент проверяет, насколько хорошо кодовые агенты справляются с оркестрацией, а не только с SQL или dbt. Airflow здесь выступает как система оркестрации, которая управляет последовательностью и зависимостями задач по обработке данных. Это важно, потому что большинство сбоев в дашбордах возникает именно на уровне расписаний, сенсоров и зависимостей задач, а не в самих запросах. Сенсор — это специальная задача, которая ждёт наступления определённого условия, например появления файла или завершения другого процесса. Без точной настройки таких элементов даже корректные SQL-запросы не дают нужный результат в продакшене.
Существующие бенчмарки ограничиваются проверкой SQL или моделей трансформации. Они не учитывают, что в продакшене данные проходят через несколько слоёв планировщика, и ошибка может скрываться в неправильном интервале сенсора или в задаче, которая формально завершилась успешно. При оценке агентов важно понимать, способна ли модель не только написать код, но и учесть контекст работы всей платформы.
Сложности оркестрации, которые не ловят обычные тесты
В реальных платформах одна и та же платформа Airflow часто обслуживает несколько команд с разными соглашениями. При этом рядом могут работать legacy-планировщики, а обновление версии Airflow требует проверки сотен DAG на совместимость импортов и провайдеров. DAG — это направленный ациклический граф, описывающий последовательность задач и их зависимости. Простая на вид задача «исправить расхождение в цифрах» превращается в поиск причины среди расписаний, выходных файлов и upstream-зависимостей.
Агенты должны не просто генерировать код, а понимать контекст: какой именно DAG отвечает за загрузку, почему сенсор сработал не вовремя и как изменить расписание, не сломав downstream. Downstream — это задачи, которые зависят от текущей и запускаются после её успешного завершения. Без такого понимания даже сильная модель даёт решения, которые проходят локальные тесты, но ломаются при реальном запуске. Для принятия решения о внедрении агента критично проверить именно эту способность, потому что ошибки в оркестрации приводят к задержкам отчётов и потере доверия к данным.
de-bench воспроизводит именно эти условия. Каждая задача поставлена на «грязный» проект, где изначально присутствуют ошибки, и агент должен привести его к состоянию, когда все проверки проходят. Это ближе к тому, с чем сталкиваются инженеры ежедневно. При выборе инструмента стоит учитывать, что бенчмарк фокусируется на реальных сценариях поддержки и обновления, а не на создании новых пайплайнов с нуля.
Как устроен бенчмарк и что он измеряет
Платформа создана совместно с группой баз данных Carnegie Mellon. В неё заложены типичные паттерны: разделение команд, разные версии провайдеров, наличие устаревших DAG и необходимость выполнять обновления без изменения поведения downstream. Для каждой из 139 задач известен правильный результат, который проходит все проверки.
При тестировании измеряли Pass@1 — долю задач, решённых с первой попытки, а также стоимость прогона и время работы. Сравнивали нативные обвязки моделей и harness Otto. Оказалось, что frontier-модели уже справляются с частью сложных задач, однако при одинаковом уровне мышления Otto показывает более высокий Pass@1 в 15 из 17 конфигураций, а прирост достигает 11 %. При этом на верхней части Pareto-фронтира Otto чаще оказывается выгоднее по соотношению точности и цены. Pareto-фронтир здесь отражает оптимальные точки между качеством и затратами.
Эти метрики помогают решить, стоит ли брать конкретного агента в команду. Если Pass@1 низкий на задачах обновления, то даже дешёвые запуски не окупят риск поломок в продакшене. Harness Otto при этом даёт преимущество за счёт лучшей интеграции с окружением Airflow.
Что это даёт командам, работающим с Airflow в РФ
В российских контурах Airflow часто разворачивают on-premise или в закрытых облаках, где недоступны последние версии моделей и где критична стоимость каждого вызова. On-premise означает локальное размещение без выхода в публичный интернет. Здесь важнее не абсолютный Pass@1, а стабильность на задачах обновления и отладки существующих DAG. Результаты бенчмарка показывают, что даже при среднем уровне мышления правильно настроенный harness даёт заметный прирост без увеличения числа токенов.
Для команд это означает возможность объективно сравнивать разных агентов перед внедрением. Если модель уже хорошо справляется с типовыми паттернами, нет смысла тратить токены на повторное объяснение базовых вещей — лучше подавать ей актуальные сведения о версиях провайдеров и внутренних соглашениях. Такой подход снижает и стоимость, и риск сломать работающие процессы при очередном обновлении Airflow. При принятии решения о покупке или подписке на агент стоит ориентироваться именно на результаты по задачам поддержки legacy-кода, а не только на генерацию нового.
Источник
Это краткий разбор материала Astronomer. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Бенчмарк Astronomer для Airflow.
Курс по теме — Каталог курсов Школы Больших Данных
