Дата-пайплайны надёжнее и дешевле, чем Claude Code, без потери качества

Когда ИИ строит пайплайн, а не одноразовый скрипт

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

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

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

В чём проблема со скриптами

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

В реальных системах пайплайн — это не просто текстовый файл. Это объект, который:

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

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

Что такое DataFlow-Harness

DataFlow-Harness — это платформа, в которой ИИ-агент не пишет свободный скрипт, а постепенно собирает платформенный DAG, то есть ациклический граф шагов обработки данных.

Важный момент: агент не создаёт всё одним большим куском. Он вносит типизированные изменения. Добавляет оператор. Меняет параметр. Соединяет два узла. Удаляет лишний шаг. После каждого действия система проверяет, что граф остаётся корректным.

Архитектура DataFlow-Harness: агент, общая модель пайплайна, навыки, слой инструментов и проверка изменений.

Внутри у системы четыре главные части.

Вместо «вот вам запрос, напишите код» получается «вот вам живая платформа, реестр операторов, текущее состояние и набор допустимых действий».

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

Можно подумать: если агент уже видит список операторов, зачем ещё какие-то навыки? Разве не достаточно дать ему доступ к платформе?

Оказалось, нет.

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

Для этого и нужны DataFlow-Skills. Это набор процедурных знаний:

Иначе говоря, инструменты дают факты о платформе, а навыки дают рабочую практику.

Как это выглядит для пользователя

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

Два синхронизированных режима работы: диалог с агентом и визуальный редактор графа.

Это снимает типичную проблему ИИ-инструментов: «модель что-то сгенерировала, а дальше или принимай как есть, или переписывай всё сам». Здесь пайплайн остаётся живым объектом. Вы можете редактировать его руками, а агент продолжит работу с последней версией.

Для рабочих задач это базовое требование.

Как проверяли систему

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

Сравнение шло между четырьмя настройками:

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

Метрики тоже выбраны практичные:

Главные результаты

Цифры здесь интересны именно балансом, а не одной максимальной строкой в таблице.

Полный DataFlow-Harness дал 93,3% успешных прогонов. Это почти на уровне лучшего скриптового базового варианта с доступом к контексту платформы, у которого 94,2%. Разница очень небольшая. Но при этом DataFlow-Harness работал заметно дешевле и быстрее.

Если сравнивать с обычным Claude Code без контекста платформы:

Если сравнивать с более сильной базой, где агенту дали кодовую базу платформы:

Что особенно показательно: вариант только с инструментами без навыков просел до 83,3%. То есть просто подключить агент к платформе недостаточно. Нужна ещё процедурная опора.

Здесь и проявляется тот самый разрыв NL2Pipeline: написать исполняемый скрипт модели легче, чем собрать корректный платформенный DAG. Но если дать ей правильные ограничения и знания о процессе, разрыв почти закрывается.

Где навыки реально помогают

Авторы отдельно разобрали задачи по типам. Это одна из самых полезных частей работы.

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

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

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

Итог выглядит так:

Кейс посложнее: извлечение вопросов и ответов из учебников

Авторы отдельно проверили систему на более жизненной задаче: извлечь пары «вопрос—ответ» из учебных материалов. Это тяжёлый сценарий. Документы длинные, структура ломанная, рядом могут быть рисунки, таблицы, решения, подписи, куски с разной логикой.

Здесь DataFlow-Harness показал лучшие результаты сразу по двум метрикам:

У базовых вариантов цифры были заметно ниже. Особенно важна полнота: система не просто осторожнее фильтровала результат, а действительно извлекала больше корректных пар.

Это хорошо показывает, где платформенный подход выигрывает. В сложной задаче уже мало просто «уметь писать код». Нужно находить и правильно связывать специализированные компоненты: разбор PDF, восстановление структуры страницы, OCR, извлечение рисунков, мультимодальный анализ, сопоставление вопроса и ответа на расстоянии.

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

Самая интересная проверка: влияет ли это на качество данных дальше

Авторы пошли ещё дальше и спросили: хорошо, пайплайн можно построить. А станет ли лучше результат на следующем этапе? Например, если этим пайплайном сгенерировать обучающие данные и потом дообучить модель.

Они провели два таких сценария.

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

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

И это в целом подтвердилось. В математическом сценарии данные, полученные через DataFlow-Harness, дали лучший средний результат при одинаковом бюджете обучения. В общем сценарии особенно заметен выигрыш на задачах по программированию: модель, обученная на данных из такого пайплайна, лучше решала HumanEval и MBPP.

Это не означает, что платформа автоматически делает лучшие датасеты всегда и везде. Авторы сами осторожны в выводах: кейсов пока два, прогонов немного. Но направление важное. Вопрос уже не только в том, «умеет ли агент собрать граф», а в том, «ведёт ли этот граф к более полезным данным».

Почему это важно

У этой работы есть практическая мысль, которая легко переносится и за пределы инженерии данных.

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

Это можно применить не только к пайплайнам данных. Та же логика годится для внутренних бизнес-процессов, визуальных редакторов, систем автоматизации, возможно, и для части инструментов в робототехнике или многопользовательских средах, где важен общий объект состояния.

Главная идея тут не в «более умном агенте». А в том, что агенту нужна правильно устроенная среда.

Вывод

Разрыв между текстовой инструкцией и настоящим платформенным пайплайном — отдельная инженерная проблема. Её нельзя закрыть только более мощной LLM.

DataFlow-Harness показывает более практичный путь: агент должен работать не со свободным кодом, а с живым представлением пайплайна; не с абстрактными знаниями, а с реестром доступных операторов; не с одним ответом, а с цепочкой проверяемых изменений.

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

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