Подробный разбор · Около 5 мин чтения
Databricks сравнила декларативные Spark-конвейеры для агентов: проверки раньше, токенов больше
Сравнение 528 сборок отделяет дешёвые структурные проверки от правильности логики; график вычислений охватывает лишь 44 сборки.
- Опубликовано здесь
- Дата источника
- Источник проверен
23 октября Databricks опубликовала сравнение процедурного PySpark и Spark Declarative Pipelines (SDP), написанных агентами. Lisa Cao и Sudhanva Huruli сообщают, что декларативное планирование позволяет отклонять структурные ошибки до выполнения, но требует больше токенов модели. Результаты показывают инженерный компромисс, а не общую гарантию правильных или более дешёвых конвейеров.
Слушать новости
Прослушайте эту статью или включите новости подряд.
Подготовка чтения…
Голос устройства
Речь обрабатывает браузер или устройство. AISubHub не отправляет текст в аудио-API. Доступные голоса и работа при заблокированном экране зависят от устройства.
При продолжении короткая фраза может повториться.
Кратко
- Эксперимент включал 22 задачи и 12 наборов данных для каждой: по 264 сборки на подход, всего 528, во всех использовалась Opus 4.8.
- График вычислений охватывает 44 измеренные сборки: 596 против 17 executor-seconds. Это не показатели всех 528 сборок и не сквозная задержка.
- Отношение числа токенов декларативных сборок к процедурным составило примерно 2.3; скрытые ошибки сохранились: 85/264 против 73/264 у процедурных.
1. Что на самом деле измеряют 528 сборок
Каждая задача напоминала заявку по инженерии данных с указанием целевой таблицы, названий столбцов и типов. Для каждой из 22 задач предоставили двенадцать наборов с проблемными значениями, а агент создавал обе реализации. Автоматический оценщик проверял результаты, не зная способа реализации. Это 22 типа задач с повторными сборками, а не 528 независимых производственных нагрузок.
Завершились 255/264 процедурные сборки и 258/264 сборки SDP. Завершение означает окончание сборки, но не доказывает правильность ответа. После неудачной декларативной пробной проверки агент мог исправлять код и повторять попытки до фиксированного предела. Основная статья не указывает этот предел и все настройки оценки.
2. Проверять структуру до выполнения
Процедурный код задаёт чтение, преобразования, запись и их порядок. SDP описывает нужные наборы и запросы, оставляя Spark планирование зависимостей, порядка выполнения и сохранения. Пробная проверка может сопоставить столбцы со схемами, найти производителей наборов данных и проверить граф зависимостей до фактического запуска. Поэтому опечатку в столбце можно выявить без дорогого прохода по данным.
В этом сравнении декларативная проверка отклонила 55/264 сборки до любого вывода, тогда как процедурный подход на этой стадии не перехватил ни одной. Это результат конкретной конфигурации, а не доказательство невозможности статических проверок процедурного кода. Успешная пробная проверка также не является формальным доказательством: структурно допустимый запрос всё ещё может реализовать неверную бизнес-логику.
3. У результата вычислений меньший знаменатель
Первый график прямо указывает «44 измеренные сборки». На нём приведены 596 executor-seconds для процедурного подхода и 17 для декларативного; авторы описывают примерно в 34 раза большее время кластера у первого. Эту подвыборку нельзя смешивать со всеми 528 сборками. Executor-seconds измеряют ресурсы исполнения, а не воспринимаемую пользователем длительность или полный производственный счёт.
В таблице отдельно приведены неудачный процедурный запуск примерно на 521 executor-seconds и отклонённый декларативный примерно на 0.5 executor-second. Это примеры стоимости обнаружения структурной ошибки на разных этапах, а не средние значения типичного запуска. Статья не устанавливает одинаковый выигрыш для всех наборов данных, конфигураций кластера и масштабов производства.
4. Меньше кода не означает правильную логику
Среди завершённых сборок медиана длины составила 131 строку процедурного кода и 64 строки SDP, примерно на 51% меньше; абстрактные синтаксические деревья, по отчёту, были примерно на 44% меньше. Второй график показывает среднюю половину сборок каждого подхода и медианы. Это не полное распределение и не доверительные интервалы; меньший код не измеряет такое же сокращение труда при проверке.
Девятнадцать процедурных сборок загружали данные в память и обрабатывали построчно; ни одна SDP-сборка не использовала этот обходной путь. Такие реализации могут пройти маленькие тесты и стать хрупкими при росте объёма. Наблюдаемое различие поддерживает проверку шаблонов выполнения, но не гарантирует безопасного масштабирования и правильности логики любого декларативного конвейера.
5. Токенов больше, скрытые ошибки остаются
По данным авторов, отношение числа токенов модели в декларативных сборках к процедурным составило примерно 2.3. Отдельно медианная стоимость токенов на сборку по указанным прейскурантным тарифам Opus 4.8 составила около $0.50 против $0.26 у процедурных. Отношение числа токенов и денежные медианы — разные показатели. Источник использует символ $, прямо не указывая валюту ISO; это заявленные расходы эксперимента, а не проверенные текущие цены API.
Скрытые ошибки — завершившиеся запуски с неверным ответом — затронули 73/264 процедурные сборки (27.7%) и 85/264 декларативные (32.2%). Авторы считают разницу недостаточной для установления реального различия. AISubHub независимо не проверяла статистическую значимость или эквивалентность. Пробная проверка не устраняет этот класс ошибок: нужны тесты результатов и ревью. Эти числа также нельзя складывать с другими категориями, считая их непересекающимися.
6. Где применим архитектурный довод
Авторы размещают доверенные проверку и выполнение в Spark, а агент предоставляет описание желаемого конвейера. По их доводу, дополнительные токены генерации могут заменить повторные расточительные запуски кластера, цена которых растёт с объёмом данных и частотой. Полного расчёта совокупных затрат в статье нет. Параллели с SQL, инфраструктурой как кодом и API, начинающимися со схемы, являются доводами, а не дополнительными результатами измерений.
По анализу AISubHub, явная и дешёвая для проверки спецификация может точнее отделить генерацию конвейера от разрешения дорогого исполнения. Командам всё ещё нужны репрезентативные тесты результатов, проверки масштаба и расчёты затрат для своей нагрузки. Источник поддерживает изучение этой границы, но не доказывает всеобщую экономию, безопасность разрешений, правильность логики или автоматическую готовность к производству.
Почему это важно
Полезно различать, какие сбои платформа может отклонить до дорогого пути исполнения. Более короткая декларативная спецификация может помочь этой границе, расходуя больше токенов генерации. Окупаемость зависит от реальной нагрузки и тарификации, а не только от множителя в заголовке.
Ограничения и доступность
AISubHub прочитала основной текст целиком, обе текстовые таблицы и два необходимых графика. Связанные репозиторий, руководство, skill и видео не изучались. Мы не проводили аудит кода, не повторяли эксперимент и не измеряли счета кластера; все экспериментальные результаты приписываются Databricks.
Источники и подтверждения
Дата источника: · Источник проверен:
Материалы подготовлены с помощью ИИ и сверены с указанными первоисточниками. Заявления поставщиков атрибутированы; публикация не означает рекомендацию.