Spaces:
Sleeping
Sleeping
| # 项目定位与生态比较 | |
| 做完当前项目之后,我忽然萌生一个想法:当前项目是不是在重复造轮子。 | |
| ## 故事 | |
| 在最开始学习深度学习的时候,我是按照教程将它们整理成一份一份的 Notebook 文档。这中间遭遇了很多的训练流水线上的重复。于是,为了消除重复,我开启了这个项目。 | |
| 前两版,我将项目设计得非常抽象和复杂,于是我的工作从一种重复转换成了另一种重复。重复的去修改适应框架。我逐渐意识到,过度的抽象和复杂反而是大量重复工作的源泉。你要不断地去重复理解你的东西。 | |
| 到最后,我终于妥协了。不在一开始就去设计得高度抽象从而去兼容遥远的未来。立足当下,做适合当下的选择。 | |
| 所以,这个项目真正想消除的不是所有重复,而是学习和实验过程中那些低价值的重复:重复搭训练入口、重复整理数据流、重复写导出和展示流程、重复猜一个任务应该从哪里改。 | |
| ## 与成熟生态的关系 | |
| 成熟生态通常已经覆盖了这些能力: | |
| - 标准数据集读取 | |
| - 预训练模型和 backbone | |
| - 训练循环封装 | |
| - 分布式训练 | |
| - 回调、日志和检查点 | |
| - 模型导出和部署 | |
| - 在线展示和推理 | |
| - 特定任务的高质量实现,例如目标检测 | |
| 本项目可以追求通用训练框架的形状,但不应该试图在所有方向上追赶成熟生态。更合理的判断标准是:它能不能让我,或者和我处在类似阶段的学习者,更快看懂一个任务从数据到展示的完整过程,并且能低成本修改。 | |
| ### Keras Examples | |
| Keras Examples 是当前项目最接近的来源。它提供了大量高质量、短小、直观的教学示例,覆盖分类、分割、文本生成等任务。 | |
| 重叠点: | |
| - 都以 Keras 为核心 | |
| - 都强调可读性和教学价值 | |
| - 很多任务形态可以从 Keras Examples 学习或改写 | |
| 差异点: | |
| - Keras Examples 通常是单篇示例,更像教程 | |
| - 本项目尝试把多个任务整理成统一入口、统一目录、统一检查点和统一展示方式 | |
| - 本项目更强调“改一个任务时应该去哪里改”,而不只是“这个示例能跑通” | |
| 合理定位:本项目可以把 Keras Examples 风格的任务整理成一个更统一的本地实验框架,但不需要替代 Keras Examples。 | |
| ### KerasHub | |
| KerasHub 提供成熟的预训练模型、backbone、tokenizer 和任务封装。 | |
| 重叠点: | |
| - 都在 Keras 生态里构建模型 | |
| - 都可能涉及文本、视觉和预训练组件 | |
| 差异点: | |
| - KerasHub 的核心价值是高质量预训练模型和标准化模型组件 | |
| - 本项目的核心价值是任务级组织方式,包括数据、训练、导出、测试和展示 | |
| - 本项目不应该自己维护一套大型 backbone 或预训练模型库 | |
| 合理定位:当任务需要成熟 backbone 或 tokenizer 时,应该优先接入 KerasHub,而不是重写同类能力。 | |
| ### fastai | |
| fastai 提供低门槛的高层训练体验,用较少代码完成数据处理、训练、调参和可视化。 | |
| 重叠点: | |
| - 都希望降低深度学习任务的使用门槛 | |
| - 都试图把常见训练流程封装起来 | |
| 差异点: | |
| - fastai 是完整框架,有自己的数据块、Learner、回调体系和最佳实践 | |
| - 本项目更小,主要围绕 Keras 教学任务和本地实验 | |
| - 本项目不追求用最少代码隐藏所有细节,而是让细节保持可读 | |
| 合理定位:本项目不需要成为 Keras 版 fastai。它更适合保留显式的数据源、模型构建器和 Pipeline,让学习者知道每一步在哪里。 | |
| ### PyTorch Lightning | |
| PyTorch Lightning 专注训练工程化,把训练循环、分布式、日志、检查点和回调体系标准化。 | |
| 重叠点: | |
| - 都封装训练流程 | |
| - 都关注日志、检查点和训练入口 | |
| 差异点: | |
| - Lightning 解决的是生产训练工程和大规模训练组织问题 | |
| - 本项目解决的是个人学习和实验场景下,Keras 训练任务如何保持统一、可读和可改 | |
| - 本项目没有必要复刻 Trainer、Callback、Strategy、Logger 等完整体系 | |
| 合理定位:本项目可以借鉴 Lightning 对训练职责边界的划分,但不应该复制它的完整工程体系。 | |
| ### Hugging Face Transformers / Datasets / Spaces | |
| Hugging Face 生态覆盖模型、数据集、tokenizer、训练辅助、模型托管和在线展示。 | |
| 重叠点: | |
| - 文本生成任务会涉及 tokenizer、模型加载、生成策略和展示 | |
| - Datasets 与 Spaces 分别覆盖数据读取和应用展示 | |
| 差异点: | |
| - Hugging Face 是模型和数据生态,强调复用社区模型、数据集和部署能力 | |
| - 本项目是本地任务组织框架,强调从源码看懂训练、导出和展示 | |
| - 本项目不应该重复实现通用模型仓库、数据集仓库或托管平台 | |
| 合理定位:如果任务要使用主流预训练模型或公开数据集,应优先接入 Hugging Face 生态。本项目保留自己的价值:把接入后的任务组织成易读、可改、可运行的本地结构。 | |
| ### Ultralytics YOLO | |
| Ultralytics YOLO 是目标检测领域非常成熟的专业生态,覆盖训练、推理、导出、评估和部署。 | |
| 重叠点: | |
| - 本项目有 YOLO 相关任务和检测展示 | |
| - 都可能涉及检测模型、标注格式、推理后处理和可视化 | |
| 差异点: | |
| - Ultralytics YOLO 是目标检测专业工具 | |
| - 本项目里的 YOLO 更适合作为学习和实验任务 | |
| - 本项目不应该试图追平 Ultralytics 在检测算法、训练技巧、格式兼容和部署优化上的积累 | |
| 合理定位:检测任务如果追求效果、速度和生产可用性,应优先使用 Ultralytics。本项目可以保留检测任务作为学习统一任务结构的案例。 | |
| ### TensorFlow Datasets | |
| TensorFlow Datasets 提供标准数据集下载、版本管理、切分和 `tf.data` 集成。 | |
| 重叠点: | |
| - 都涉及数据集读取和 `tf.data` | |
| - 都要处理训练集、验证集和测试样例 | |
| 差异点: | |
| - TFDS 的价值是标准数据集生态和稳定读取接口 | |
| - 本项目的数据层更关注把具体任务的数据整理成项目内统一的 DataSource | |
| - 本项目不需要维护标准数据集仓库 | |
| 合理定位:标准数据集优先使用 TFDS 或官方读取方式。本项目的数据源负责把这些数据转成任务需要的训练数据和样例测试能力。 | |
| ## 是否重复造轮子 | |
| 如果项目目标是下面这些方向,就属于重复造轮子: | |
| - 做生产级通用深度学习训练平台 | |
| - 做预训练模型库 | |
| - 做标准数据集平台 | |
| - 做目标检测专业工具 | |
| - 做模型托管和在线部署平台 | |
| - 做类似 fastai 或 Lightning 的完整高层训练生态 | |
| 这些方向已有成熟工具,当前项目没有必要也不适合重新实现。 | |
| 如果项目目标是下面这个方向,那么它至少不是为了替代成熟生态: | |
| > 做一个面向个人学习和实验的通用 Keras 训练框架。 | |
| 这个定位下,“通用”指的是常见任务可以共享一套训练形状,而不是覆盖生产训练平台的完整能力。本项目的价值不是“能力比成熟生态更多”,而是“把一个任务从数据、模型、训练、导出、测试到展示放在一套清楚的结构里”。 | |
| 至于这是否仍然算重复造轮子,可以留给读者判断。对我来说,更重要的问题是:这个项目有没有帮助我减少真实重复、看清任务结构,并在学习和实验中保持可修改。 | |