DataFlow: PyTorch для дата инженеров в эпоху LLM

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

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

Что именно ломается в обычных пайплайнах

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

DataFlow как раз пытается закрыть этот разрыв: сделать LLM-driven обработку данных главной частью пайплайна.

Как устроен DataFlow: операторы, ключи и общее хранилище

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

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

Поверх операторов строятся пайплайны с PyTorch-стилем: вы описываете конфигурацию, объявляете шаги и запускаете forward(). Есть компиляция пайплайна — она заранее проверяет зависимости по ключам, помогает поймать ошибки связности и упрощает отладку.

Сами операторы авторы делят на четыре большие роли: генерация, оценка, фильтрация и улучшение. На практике большинство подходов укладываются в цикл generate → evaluate → filter → refine, иногда с повторениями. Для этого в DataFlow собрана большая библиотека из почти 200 операторов и набор готовых пайплайнов под текст, математику, код, Text-to-SQL, агентный RAG и извлечение знаний.

Агент, который собирает пайлпайн по описанию

Отдельная часть системы — DataFlow-Agent. Это мультиагентная система, которая принимает запрос на естественном языке и пытается превратить его в исполнимый DAG-пайплайн (Directed Acyclic Graph): подобрать подходящие операторы, проверить совместимость входов/выходов, а если нужного шага нет — сгенерировать новый оператор, протестировать и встроить его в граф.

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

Text-to-SQL как фабрика данных

Один из самых наглядных кейсов в статье — Text-to-SQL. Там важно не просто сгенерировать SQL, а добиться исполнимости, соответствия вопросу, разумной сложности и пригодности для обучения. DataFlow делает это цепочкой операторов: генерация SQL, проверка выполнением на базе, генерация вопроса, построение цепочки рассуждений, сборка финального промта и разметка сложности.

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

Меньше данных — больше пользы

Авторы прогоняют DataFlow на шести типовых сценариях и показывают стабильные выигрыши на downstream-метриках. В математических задачах прирост составляет 1–3 пункта на MATH, GSM8K и AIME относительно сильных синтетических бейзлайнов. В коде средний выигрыш превышает 7% на наборе code-бенчмарков. В Text-to-SQL они получают до +3% точности по сравнению с SynSQL, причём достигают этого на заметно меньшем объёме тренировочных примеров. Объединённый датасет DataFlow-Instruct-10K (всего 10 тысяч примеров из разных доменов) позволяет базовым моделям Qwen обгонять аналоги.

Почему это важно, даже если вы не обучаете LLM с нуля

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

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

📜 Полная статья

💾 Код

***

Если вам интересна тема ИИ, подписывайтесь на мой Telegram-канал — там я регулярно делюсь инсайтами по внедрению ИИ в бизнес, запуску ИИ-стартапов и объясняю, как работают все эти ИИ-чудеса.