DataFlow深度拆解:北大DCAI的以数据为中心AI基础设施
DataFlow深度拆解:北大DCAI的以数据为中心AI基础设施
当 Scaling Law 进入平台期,模型架构创新的边际收益递减。谁来决定 LLM 最终的能力上限?答案是:数据的语义密度和工程精度。
2026 年,大模型行业的共识正在经历一场从「模型中心(Model-Centric)」到「数据中心(Data-Centric)」的深刻范式转移。但当模型训练逐渐进入自动驾驶时代时,数据准备(Data Prep)却仍停留在「脚本拼贴 + 正则堆砌」的手工坊阶段:碎片化的 Python 脚本、不可复用的清洗逻辑、缺乏观测性的黑盒流程,已成为企业级应用落地的最大瓶颈。
DataFlow 就是针对这一痛点而生的系统化解决方案。它来自北京大学数据中心 AI 实验室(DCAI),定位是 「大模型数据生成、清洗与准备,一站式搞定」。2025 年 6 月正式开源,12 月技术报告发布即登顶 Hugging Face Daily Papers 榜首;此后每季度一次的大版本更新——2026 年 2 月 WebUI、5 月 Skills、7 月 Harness——让它从一个算子框架快速成长为覆盖「数据生成 → 清洗 → 评估 → 过滤 → Agent 辅助构建 → 分布式调度」完整链路的以数据为中心的 AI 基础设施。
本文提纲
- DataFlow 想解决什么问题
- 框架设计哲学:像写 PyTorch 一样定义数据流
- 两级抽象:Operator 算子层 + Pipeline 流水线层
- 四大算子分类体系:生成 / 评估 / 过滤 / 精炼
- 存储与模型后端解耦:Storage + LLMServing
- DataFlow 四件套套件:主框架 / Skills / WebUI(Harness) / RayOrch
- DataFlow-Harness 最新进展:Skills + MCP + WebUI 三合一,让 Agent 帮你建流水线
- 开箱即用的内置流水线:Text / Reasoning / Text2SQL / PDF→QA / 数学 / 代码
- 学术与产业双背书:ICDE 2026、KDD 2026、中国联通开源扩展
- 快速上手三条路径:pip 安装、代码调用、WebUI 启动
DataFlow 想解决什么问题
训练大模型的数据准备工作,和传统 ETL(抽取-转换-加载)有本质区别,DataFlow 的团队在论文和技术文章中归纳了三大结构性矛盾:
第一,语义断层与 Model-in-the-Loop。 传统清洗靠规则和正则,但高质量的数学推理数据、代码数据、垂直领域 QA,必须引入大模型来进行生成、评估和过滤。这要求系统具备灵活的模型在环调用编排能力——批处理、重试、限速、切模型,不能散落在每个脚本里自己写。
第二,工程碎片化导致的技术债。 数据链路环节多、周期长。缺乏统一抽象的后果是:不同团队的算子逻辑散落在各自的脚本里,正则写了三遍、Prompt 改过五版,最后没有人能完整复现一版数据的完整加工路径。同样的清洗逻辑,在 A 项目有效,搬到 B 项目就得从头重写。
第三,黑盒处理与观测性缺失。 动辄 TB 级的文本在流水线里流转,你不知道哪个算子引入了偏见,哪一步的过滤策略错杀了高价值样本,直到模型训练跑了数周后评测翻车,才发现数据分布在清洗时就出了问题。试错成本高到不可接受。
DataFlow 的回应,是一整套有抽象层次、有标准化命名规范、可观测可复现的系统设计。下面逐层拆开。
框架设计哲学:像写 PyTorch 一样定义数据流
DataFlow 的定位不是一个工具集合,而是一套类似 PyTorch 的数据编程协议。它借鉴了 PyTorch 的设计思路来组织代码:
- PyTorch:
Module → Layer → Parameter,一层套一层,声明式定义模型,.forward()执行 - DataFlow:
Pipeline → Operator → Prompt,一层套一层,声明式定义数据流程,.run()执行
两者核心思想是一致的:把原子单元(Layer 或 Operator)封装为可组合的对象,通过声明式的依赖注入(传参而非全局变量)连接成更上层的结构(Model 或 Pipeline),在统一的运行时接口(forward 或 run)下执行。
MERMAID_BLOCK_0
这个设计有三个直接好处:
- 可复现:一条完整的 Pipeline 就是一份可执行的「数据加工配方」。任何人拿到相同的原始数据 + 相同的 Pipeline JSON/Python 文件,就能复现完全一致的清洗结果,消除了脚本散落导致的复现困难。
- 可组合:Operator 是原子单元,不同 Pipeline 之间可以互相引用算子。研究数据质量和模型性能关系时,只需要替换算子或 Prompt,不用改整条链路。
- 可观测:因为所有数据流转都经过统一的 Storage 层,每个算子的输入输出都是 DataFrame 的列操作,天然支持在线预览中间结果、加探针、日志追踪。
两级抽象:Operator 算子层 + Pipeline 流水线层
Operator:原子数据转换单元
Operator 是 DataFlow 最小的逻辑单元,封装了一个独立的数据处理动作。它的设计有三个严格的接口规范:
__init__():初始化算子配置、超参数、以及(如果需要调用 LLM 的话)通过llm_serving形参注入模型后端。算子内部不允许自己声明大模型,必须从外部注入,这是为了避免每个算子各自建立连接、浪费资源。run(storage, input_*, output_*, ...):执行算子逻辑。第一个参数一定是 Storage 对象,后面的 key 参数明确声明这个算子读 DataFrame 的哪些列、写哪些列。没有被声明的列完全不碰,实现了「算子逻辑与数据 Schema 解耦」。- 标准化命名:类名直接体现算子功能类别(见下一节分类体系)。
以最简单的 PromptedGenerator 为例,它模拟了人们批量调用 GPT 的经典模式——同一个 system prompt,批量喂入不同的 input 数据,生成 answer 列:
from dataflow.operators.core_text import PromptedGenerator
from dataflow.utils.storage import FileStorage
from dataflow.serving import APILLMServing_request
storage = FileStorage(first_entry_file_name="./input.json")
llm_serving = APILLMServing_request(
api_url="https://api.openai.com/v1/chat/completions",
)
prompted_generator = PromptedGenerator(
llm_serving=llm_serving,
system_prompt="Please solve this math problem."
)
prompted_generator.run(
storage=storage.step(),
input_key="problem",
output_key="solution"
)
输入 input.json 中只有 problem 列,算子执行后 DataFrame 新增 solution 列。这种「Key-based I/O + 列操作」的模式非常适合 DataFrame 载体,也让每个算子的副作用范围清晰可控。
Pipeline:算子有序序列或 DAG
Pipeline 把多个 Operator 按顺序或 DAG 组织起来,形成完整的数据加工链路。DataFlow 的 Pipeline 支持:
- 顺序执行(最常用):算子 A → 算子 B → 算子 C,一步步流转
- DAG 执行:存在依赖分支时,构建有向无环图
- Compile 静态检查:执行前自动检查字段缺失、类型冲突,提前报错而非跑了一半才崩
- Lazy Execution + Checkpoint:支持延迟执行和断点续传,大规模分布式任务中断后不用从头跑
配合 DataFlow-WebUI 后,Pipeline 还能被序列化、可视化、导入导出。团队之间共享数据加工配方变成了共享一个 JSON 文件,和共享 PyTorch 模型权重文件一样自然。
四大算子分类体系:生成 / 评估 / 过滤 / 精炼
DataFlow 将内置的近 200 个算子严格划分为四大功能类别,并建立了标准化的语义命名规范。这四类算子恰好对应数据加工的四个典型阶段:
MERMAID_BLOCK_1
| 类别 | 功能定位 | 典型算子举例 |
|---|---|---|
| Generation(生成类) | 从无到有生成新样本,或从低语义密度源抽取高语义密度结构 | PromptedGenerator、PDF2QA、Text2SQL、AgenticRAG 数据生成 |
| Refinement(精炼类) | 对已有数据进行修正、扩展、润色,提高语义密度 | CoT Extension(扩展思维链)、Explanation Augment、Category Classification |
| Evaluation(评估类) | 对数据进行打分、分类、难度评估,为后续过滤提供量化依据 | Difficulty Estimator、Quality Scorer、Consistency Evaluator |
| Filtering(过滤类) | 根据规则或评估结果进行筛选、去重、去噪,保留高价值样本 | Deduplication、Threshold Filter、Quality Filter、Outlier Removal |
这套分类体系的意义不止于命名规范。它建立了一种跨团队沟通的通用语言:当有人说「我在 Refinement 阶段需要一个更好的 CoT 扩展算子」,不需要额外解释就知道这个算子应该放在流水线的哪个位置、输入输出应该是什么形态。
存储与模型后端解耦:Storage + LLMServing
DataFlow 的框架设计里有两个全局支撑组件,它们和 Operator/Pipeline 一起形成了完整的运行时:
Storage:全局表格化存储
当前版本的 DataFlow 以 pandas DataFrame 作为核心数据载体,因此天然支持 json / jsonl / csv / parquet / pickle 等常见格式的读写。数据的增删查改本质上就是 DataFrame 的列操作。
Storage 抽象的核心价值是 「算子逻辑与底层存储格式解耦」:算子通过 input_key/output_key 的字符串名与 Storage 交互,完全不关心底层是本地 JSONL 还是未来接入的分布式数据库。DataFrame 是中间协议,算子写的是「solution 列」,至于这一列最后落盘成 Parquet 还是 CSV,是 Storage 层配置决定的。
Storage 还提供了 step() 机制用于多步骤间的数据版本管理,每个算子执行前后自动形成 checkpoint,天然支持断点续传。
LLMServing:统一模型后端接口
大批量的数据扩增、过滤、打分都离不开 LLM 的语义理解能力。DataFlow 通过 LLMServingABC 抽象类统一了不同的模型后端,让算子的逻辑和「用哪个模型」完全解耦:
LocalModelLLMServing:基于 vLLM 或 SGLang 推理后端,在本地 GPU 部署模型。适合轻量用户的单机场景。APILLMServing_request:通过 HTTP 请求调用在线 API(GPT、DeepSeek、OpenRouter、企业自建集群接口),内置多进程并发、重试和限速。
算子在 __init__ 中接收 llm_serving 参数,用谁调用算子就注入谁。做 A/B 实验时,你可以用完全相同的 Pipeline 和 Operator,只替换不同的 LLMServing 对象,就能对比模型性能对数据质量的影响——不需要改一行算子代码。
DataFlow 四件套套件:主框架 / Skills / WebUI(Harness) / RayOrch
从 2025 年 6 月发布 1.0 到现在,DataFlow 的团队已经把核心框架扩展为四个紧密集成的子项目,外加一个生态扩展层,构成了完整的套件:
MERMAID_BLOCK_2
五个层次的定位:
- DataFlow 主仓库:地基。定义了 Operator / Pipeline / Storage / LLMServing 的核心抽象,内置 200 个算子和多条预置 Pipeline。
pip install open-dataflow装的就是它。 - DataFlow-Skills:2026 年 5 月发布。包含算子开发、Pipeline 构建、以及以数据为中心 AI 的各种最佳实践教程和 Skill 集,是降低上手门槛的知识库。
- DataFlow-WebUI(DataFlow-Harness):2026 年 2 月发布 WebUI、7 月升级为 Harness 形态。把复杂的算子和 Pipeline 包装进了可视化界面,同时引入 Agent 辅助和 MCP 支持。下一节单独讲。
- RayOrch:基于 Ray 的高性能编排层,为大规模数据任务提供分布式算力调度和资源管理。单机处理不了的数据量,靠 RayOrch 横向扩展。
- DataFlow-Ecosystem:模块化生态分发层,统一了算子注册机制。目前公开的子模块有多模态方向的 DataFlow-MM,以及 AI4S(AI for Science)扩展;中国联通软件研究院也基于这套生态贡献了 dataflow-speech-quality 扩展,用于客服语音语料的清洗、脱敏和标注。
这五件加起来,就是「从想法到分布式落地」的完整路径:小团队或个人可以只用主框架 + WebUI 做实验;企业用户接入 RayOrch 做大规模批处理;特定垂直领域则通过 Ecosystem 贡献和消费专用算子。
DataFlow-Harness 最新进展:Skills + MCP + WebUI 三合一,让 Agent 帮你建流水线
2026 年 7 月 18 日发布的 DataFlow-Harness(对应论文 2607.16617)是 DataFlow 目前最新的重大升级。它把三件事整合到了同一个产品里:
- 可视化 Canvas(WebUI):拖拉拽编排 Pipeline,实时预览算子输出,运行日志和进度可视化
- Skills:DataFlow 操作的技能集合,通过标准化的 Skill 规范提供给 Coding Agent 调用
- MCP(Model Context Protocol):通过 MCP 暴露 DataFlow 的能力,任何兼容 MCP 的 Agent 产品(比如 Claude Code、Trae 等)都可以直接操作 DataFlow
三者关系可以这样理解:
MERMAID_BLOCK_3
Harness 的核心价值主张是:不用你自己学 DataFlow 的 API,让 Coding Agent 通过 Skills + MCP 为你构建 Pipeline。
人类用户只需要描述意图(比如「我想把这 1000 份 PDF 转成高质量的中文 QA 对,还要分难度等级」),Agent 通过 MCP 连接 DataFlow-Harness,自动选择合适的算子、调 Pipeline 顺序、配置 LLM 后端,生成可执行的数据流水线。然后用户在 WebUI 里做审核和微调——比如某个算子输出质量不够好,改一下 Prompt 或过滤阈值,就能立即看到效果变化。
这把「数据工程专家写脚本」的模式,变成了「领域专家提需求 + Agent 写 Pipeline + WebUI 调参」的模式,进一步降低了 Data-Centric AI 的入门门槛。
开箱即用的内置流水线:Text / Reasoning / Text2SQL / PDF→QA / 数学 / 代码
框架的价值不止在于抽象,更在于「已经有人把最佳实践整理成了开箱即用的东西」。DataFlow 目前内置了多条经典流水线:
- Text Pipeline:从大规模爬取的纯文本中挖掘问答对,用于 SFT 和 RL 训练。输入是一堆爬下来的网页/书籍纯文本;经过「切分 → 生成问题 → 生成答案 → 质量过滤」输出结构化 QA 对。
- Reasoning Pipeline:在已有 QA 对基础上做三件事——(1)扩展链式思维(CoT),让答案带上推理过程;(2)分类打标签;(3)难度分级。处理后的数据适合训练具备推理能力的模型。
- Text2SQL Pipeline:将自然语言问题翻译成 SQL 查询,附带解释说明。该工作流的论文被 ICDE 2026 录用。
- 数学数据 Pipeline:生成、精炼、评估数学类训练数据。论文被 KDD 2026 录用。
- PDF → QA Pipeline:大规模 PDF 文档转成问答对,支持学术论文、手册、书籍等多种格式。
- 书籍 PDF → Visual-QA Pipeline:针对带插图和图表的书籍,生成视觉问答。
- 代码 / 文本数据生成 Pipeline:包含 DataFlow-Instruct-10K 等公开结果的参考实现。
每条 Pipeline 都提供了 HuggingFace 上的输入输出 Demo 数据集,方便用户直接对比效果,决定自己是直接复用还是在其基础上修改 Operator。
学术与产业双背书:ICDE 2026、KDD 2026、中国联通开源扩展
DataFlow 的团队在设计之初就走了「论文 + 工程 + 生态」三线并进的路线,所以它同时获得了学术界和产业界的认可:
学术端:
- 主技术报告:arXiv 2512.16676,发布后登顶 Hugging Face Daily Papers
- Text2SQL 工作流:被 ICDE 2026(数据工程顶会)录用
- 数学数据工作流:被 KDD 2026(数据挖掘顶会)录用
- DataFlow-Harness 论文:arXiv 2607.16617,2026 年 7 月最新
产业端:
- 中国联通软件研究院基于 DataFlow 生态贡献了 dataflow-speech-quality 扩展,用于运营商级的客服语音转录本的过滤、清洗、去标识和标注
- 公开的 Awesome-DataFlow 社区榜单持续接收来自不同机构的 DataFlow 应用成果
- B 站视频教程 + 飞书文档教程双路径覆盖中文用户的学习路径
学术顶会的录用说明框架设计和数据方法具备严谨性;实际企业用户贡献扩展说明它解决了真问题而不是论文里的玩具场景。两者缺一不可,而 DataFlow 同时拿到了。
快速上手三条路径
DataFlow 的设计面向多种用户画像,因此提供了三种深度不同的启动方式。
路径一:pip 安装,5 分钟跑第一个算子
适合熟悉 Python 的开发者,最快感受 API 风格:
pip install open-dataflow
export DF_API_KEY="sk-你的API密钥"
然后用前一节提到的 PromptedGenerator 示例即可跑通第一个算子。
路径二:启动 WebUI,拖拉拽 + 自然语言
适合不想写代码的领域专家或数据工程师:
pip install open-dataflow
dataflow webui
浏览器打开本地端口后,通过画布拖拽算子,或者用自然语言描述需求(搭配 Harness + MCP 模式下的 Agent 辅助)来构建 Pipeline。WebUI 内置了数据探针,可以实时预览每个算子的输出结果并调整参数。
路径三:Docker 或 Colab 一键体验
适合想零配置快速验证的用户:
- Docker 镜像:
molyheci/dataflow,一行docker run即可启动包含 WebUI 的完整环境 - Google Colab:官方提供了 Colab 笔记本,在云端就能跑完第一条 Text Pipeline 并查看结果
三条路径覆盖了从「硬核开发者深度定制」到「零配置探索」的全部光谱,用户可以随着熟悉程度的加深,从路径三逐步迁移到路径一、路径二,甚至贡献自己的 Operator 到生态中。
作者: itech001
来源: 公众号:AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/
关注每日最新AI新闻和技术博客,主页有更多的文章的AI 技术参考:https://www.theaiera.top
本文首发于 AI人工智能时代,转载请注明出处。

浙公网安备 33010602011771号