This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
需求与定位
一、DeepData 解决什么问题
典型的痛点场景
做模型微调或 RAG 的团队，都绕不开同一条流水线：数据从哪来 → 怎么洗干净 → 缺标注怎么办 → 质量够不够 → 能不能进知识库。
自建这套东西的典型代价：
| 环节 | 自建方案 | 问题 |
|---|---|---|
| 数据归集 | 写 DataX 调度脚本 + 手工执行 | 失败了只能靠日志；无重试、无状态记录 |
| 数据清洗 | PySpark脚本串成一条链 | 参数一改要改代码；无法可视化调参 |
| 数据标注 | 自建 Label Studio | 两套系统数据对不上；标注结果回不去 |
| 算子管理 | 脚本堆成 utils.py | 谁写的、什么版本、怎么复用，没人说得清 |
| 质量评估 | 人工抽查 | 不系统，无法量化 |
| 知识构建 | 另写一套向量化脚本 | 与上游数据脱节，语料更新无法感知 |
DeepData 的价值就是把这条链路上的人力搬运全部收进一个平台。
核心主张
数据处理的成本应该集中在算法本身，而不是在胶水脚本上。
平台提供：可视化拖拽编排 + 标准化算子 + 一体化元数据存储，让数据工程师只关注"用什么算子、参数怎么调"，而不是"怎么把这20 个脚本串起来跑"。
二、目标用户与角色
| 角色 | 用DeepData 做什么 | 常用模块 |
|---|---|---|
| 数据管理员 | 建数据集、发起标注任务、回收结果 | 数据管理、数据标注 |
| 数据工程师 | 编排清洗流水线、调算子参数 | 数据清洗、算子市场 |
| 算法工程师 | 合成指令数据、质量评估 | 数据合成、数据评估 |
| 知识库工程师 | 构建 RAG 知识库、管向量索引 | 知识生成 |
| 标注团队 | 在 Label Studio 里标图 | 见标注作业 SOP |
注意：DeepData 与外部标注平台的职责是分离的 —— DeepData 管数据（发起与回收），Label Studio 管标注执行。理解这个边界是理解整个系统的前提。
⚠️ 当前代码只集成了 Label Studio（硬编码，见使用说明 6.1）。虽然设计上预留了对接 CVAT/Label Studio 等外部平台的可能（见 需求映射），但 CVAT 集成尚未实现 —— 全库搜索
cvat零命中。若有CVAT 对接需求，需从零开发，详见接入清单。
三、典型使用场景
场景 1：大模型训练语料准备
原始PDF/图片 → 数据归集 → 解析算子(MarkItDown/MinerU) → 清洗(去重/去噪/PII)
→ 质量评估 → 合成指令数据(qwen2.5 蒸馏) → 入库 → 微调
对应模块：归集 → 管理 → 清洗 → 评估 → 合成
场景 2：RAG 知识库构建
文档 → 解析(MinerU 提取图文) → 切片(slicer 算子) → 向量化(知识生成)
→ Milvus 索引 → 提供检索 API
对应模块：知识生成 + RAG 索引服务
场景 3：图像目标检测标注
数据集(1000 张图) → 创建标注任务(平台固定为 Label Studio) → 标注员在 LS 内标注
→ 审核(LS 侧) → 同步回 DeepData → 标签落入 t_dm_dataset_files.tags
详见标注作业 SOP
场景 4：多源数据归集
NFS/S3/HDFS/数据库/API → DataX 统一 reader → 归集模板 → 数据集
对应模块：数据归集 + runtime/datax
四、选型判断：什么时候该用、什么时候不该用
适合用DeepData 的情况
- 需要端到端流水线，且团队里有人负责数据而非只做算法
- 语料需要反复迭代（改一个参数重跑全链路是常态）
- 需要让非工程角色（标注团队、数据管理员）参与流程
- 多模态数据（图片、PDF、音频）需要统一管理
- 需要在 RAG 与微调之间复用同一套数据底座
不建议用的情况
- 数据量小、流程固定、一次跑完就结束（杀鸡用牛刀）
- 强依赖 Hadoop 生态做超大规模批处理（DeepData 的调度是轻量的，不适合 PB 级离线批）
- 需要严格的实时/流式处理（平台以任务制为主，无流式调度）
- 团队只有算法工程师、无数据工程支持（学习成本高于收益）
五、与相邻方案的关系
| 方案 | 定位差异 |
|---|---|
| Label Studio | 只做标注，不做数据底座。DeepData 已完成对接（唯一已集成的标注平台） |
| CVAT | 同上，但DeepData 尚未集成（全库搜索零命中）。设计上有对接预案，实现需从零开发 |
| DataX | 只做数据传输，无编排无元数据。DeepData 内置集成 |
| Data-Juicer | 侧重数据清洗算法本身。DeepData 通过容器集成（profile data-juicer） |
| MinerU | 只做 PDF 解析。DeepData 通过远端 API 调用 |
| Milvus | 只做向量存储检索。DeepData 负责喂数据进去 |
| DeepFlow | 只做深度研究 Agent。作为可选组件挂在 deep-flow profile |
DeepData 的定位是把这些工具串起来的中枢，而非替代它们。
六、需求到功能的映射
| 原始需求 | 平台能力 | 实现载体 |
|---|---|---|
| 数据要有地方放 | 数据集 + 对象存储 | t_dm_datasets + MinIO/S3 |
| 清洗要能调参重跑 | 可视化编排 + 算子参数化 | runtime/ops 算子 + settings 定义 |
| 标注要能协作分工 | 对接外部标注平台 | 标注模块 + 双向同步服务（当前仅 Label Studio） |
| 算子要能复用共享 | 算子市场 | t_operator + 上传打包机制 |
| 质量要能量化评估 | 数据评估模块 | t_de_eval_task / _file / _item |
| 要能追溯数据怎么来的 | 血缘管理 | t_lineage_node / t_lineage_edge |
| 语料要能给 RAG 用 | 知识生成 + 向量索引 | Milvus + rag-indexer-service |
下一页：产品功能 —— 八大模块的具体能力边界