字节 AI 数据部门“升咖”：组织架构升级背后，为什么数据团队仍然没有交给科学家？
最近，字节跳动 AI 数据部门迎来了一次重要的组织调整。从公开信息来看，字节的一部分数据相关团队正在转岗至 Core Data 部门，而这一变动也被外界解读为 AI 数据部门在字节内部的“升咖”。但有意思的是，这次架构调整中，数据团队并没有直接划归到 Seed（字节的大模型团队）或者交给科学家体系管理。
这一动作背后，到底释放了什么信号？对做 AI 工程、数据工程、大模型应用的人来说，又意味着什么？
这篇文章我想从组织架构变化、数据团队在大模型时代的定位、以及“为什么不交给科学家”这三个角度，拆解一下这次调整背后的逻辑。同时，也会结合 AI 数据工程的实际场景，聊聊数据团队在模型训练、数据治理、数据标注、评测迭代中扮演的真实角色。这不是一篇内部爆料，而是基于公开信息的技术与组织分析，供大家参考。
1. 字节 AI 数据部门“升咖”：这次调整到底改了什么
先看这次调整的核心事实。
根据公开报道，字节跳动的部分 AI 数据团队正在转岗至 Core Data 部门。Core Data 是字节内部负责数据中台、数据基础设施、数据治理等方向的核心部门。换句话说，原本分散在 AI 业务线或者大模型项目组里的数据团队，开始向一个更加中心化的数据基础部门集中。
这件事为什么值得关注？
因为它反映了一个趋势：在大模型时代，数据团队的地位正在从“支撑角色”向“核心角色”迁移。过去，数据团队在大部分互联网公司里属于“中台部门”，服务的对象是业务方、算法团队、分析团队。数据团队的工作价值，往往通过“别人用数据做了什么”来体现，自身很难直接量化。
但在大模型时代，数据不再是辅助决策的“石油”，而是模型能力的“直接组成部分”。一条高质量的数据样本，可能直接决定模型在某个任务上的表现上限。数据团队的工作，从“支撑业务”变成了“定义模型能力边界”。
所以，字节把 AI 数据团队升咖、集中到 Core Data，本质上是在做一件事：把数据从项目制资源，升级为组织级基础设施。
这里有一个值得注意的细节：这次调整强调的方向是“集中”和“基础化”，而不是“项目化”和“垂直化”。
什么意思？
如果数据团队直接划给 Seed 大模型团队，那数据团队会变成大模型项目的“附属资源”，服务对象单一，数据建设也容易围绕短期项目目标展开。但把数据团队放到 Core Data，意味着数据建设会朝着平台化、复用化、基础设施化的方向走。数据团队服务的对象，就不只是一个模型团队，而是整个字节的 AI 生态。
这个判断，是理解整件事的关键。
2. 为什么数据团队没有交给科学家：组织逻辑与技术逻辑的双重考量
很多人第一反应是：AI 数据部门升咖了，为什么不直接交给 Seed 或者科学家团队管理？科学家不是最懂数据质量的人吗？
这个问题，恰恰是这次调整最值得琢磨的地方。
2.1 科学家的核心能力是建模，不是数据工程
先看技术分工。大模型团队里的科学家，核心能力集中在模型架构设计、训练策略优化、评测方案设计、算法创新这些方向。他们的核心交付物是“模型”，而不是“数据”。
但是，高质量数据集的构建，是一项系统工程。它涉及数据采集、数据清洗、数据标注、数据增强、数据版本管理、数据质量评估、数据安全与合规、数据流水线建设等大量工程化工作。
举个例子。一个用于训练大模型的指令微调数据集，从原始数据到最终可用的训练集，通常要经过以下流程：
- 数据源接入与采样
- 数据去重与清洗
- 敏感信息识别与过滤
- 数据分类与打标
- 指令模板设计与改写
- 人工标注与审核
- 数据质量抽检
- 数据版本管理与发布
这中间，真正需要科学家深度参与的，其实是“指令模板设计与改写”和“数据质量抽检标准制定”这两个环节。而其他环节，更多是数据工程、数据治理、产线管理的问题。
如果把数据团队直接交给科学家管理，会出现什么情况？科学家会把数据团队当成“标注资源池”，今天需要什么数据就提需求，明天模型迭代又要换一批数据。数据团队会陷入“需求驱动”的被动模式，很难有精力去建设通用、复用、高质量的数据基础设施。
2.2 数据团队的交付对象，不只是大模型团队
再看业务需求。字节的业务线非常多，从抖音、今日头条到飞书、剪映，再到各类 AI 应用。每条业务线都需要数据支持。
如果把数据团队全部划给 Seed，那其他业务线的数据需求怎么办？再建一套数据团队？这显然不经济。更合理的做法是：数据团队作为 Core Data 的一部分，向全公司提供统一的数据能力。大模型团队是重点客户之一，但不是唯一客户。
这里的组织逻辑，和“中台战略”是一脉相承的。数据中台的核心价值，就是能力的复用。在大模型时代，数据团队的能力复用价值不但没有减弱，反而因为数据质量对模型效果的影响越来越大，变得更加重要。
2.3 “没有交给科学家”，其实是一种更成熟的组织设计
从组织设计的角度看，“数据团队不归科学家管”不是贬低数据团队，恰恰是对数据团队专业性的认可。
数据团队需要的是独立的技术栈和管理体系。数据工程师关心的是数据管道稳定性、数据质量指标、数据治理规范、存储与计算成本。这些和科学家关心的模型指标、训练效率、评测分数，虽然有交集，但不能互相替代。
如果数据团队和科学家团队混在一起管理，很容易出现以下问题：
- 数据团队的绩效难以独立评估，容易受模型短期效果波动影响；
- 数据团队的技术规划容易被项目需求打断，无法形成长期积累；
- 数据团队的人才晋升通道不清晰，数据工程师的价值很难被看见。
把数据团队放在 Core Data，相当于在组织层面承认：数据建设本身是一项专业工作，需要独立的技术积累和管理体系。
3. 大模型时代，数据团队的核心价值正在被重新定义
字节这次调整，表面上是组织架构变化，本质上是对“数据团队在大模型时代应该承担什么角色”的一次重新定义。
过去，数据团队的价值可以用四个字概括：支持业务。做报表、搭数仓、跑分析，核心是服务决策。
但在大模型时代，数据团队的价值正在变成：定义模型能力边界。
大模型的训练与迭代，本质上是一个“数据飞轮”：
- 数据质量决定模型能力的上限；
- 模型能力决定产品体验的上限；
- 产品使用产生新的数据；
- 新数据反哺模型迭代。
在这个飞轮里，数据团队处于最上游。数据团队交付的数据质量，直接影响后面所有环节的效果。
所以你会发现，在大模型时代，数据团队的工作内容发生了几个重要变化：
3.1 从“数据管理”到“数据生产”
传统的数据团队，主要工作是“管理”已经产生的数据：采集、清洗、存储、分析。数据是业务过程的副产品。
但大模型时代，数据团队开始主动“生产”数据：设计数据配比、构造训练样本、生成指令数据、组织人工标注、进行数据增强。数据不再是被动产生的，而是为了模型能力目标主动设计的。
举个例子。训练一个代码生成模型，你需要的不只是“网上已有的开源代码”，还需要设计各种指令模板、构造不同难度的编程题目、组织人工编写高质量代码样本、设计代码错误修复的数据对。这些数据不是天然存在的，需要数据团队主动生产。
3.2 从“追求数据量”到“追求数据质量”
以前做数据分析，数据量越大，统计意义越强，结论越可靠。但在大模型训练里，数据量不等于数据质量，甚至数据量过大会带来负面影响。
训练数据里的重复样本、低质量样本、错误样本，会被模型“学进去”，导致模型生成质量下降。所以大模型团队对数据质量的要求，是“精”而不是“多”。
这带来一个核心变化：数据团队的核心指标，从“产出了多少数据”变成“数据质量合格率是多少”“低质量数据占比降到多少”“数据错误对模型效果的负面影响降低了多少”。
3.3 从“一次性交付”到“持续迭代”
传统的数据需求，基本是“提需求-开发-交付”的一次性模式。但大模型的数据需求是持续的、循环的。
模型每迭代一个版本，都需要新的数据。数据团队需要建设的是“数据流水线”而不是“数据项目”。数据流水线的意思是：从数据采集、处理、标注、质检到发布的完整流程，可以自动、持续、稳定地运行。
3.4 从“成本中心”到“核心竞争力”
过去，数据团队在很多公司里被看作“成本中心”：投入大、产出难以量化。但大模型时代，数据团队的产出可以直接对标模型效果。
一个高质量的数据集，可能让模型在某个任务上的准确率提升几个百分点。这种价值，是可以用业务指标直接衡量的。
字节这次把 AI 数据部门升咖到 Core Data，本质上是承认：数据团队不是成本中心，而是 AI 时代的基础设施。
4. 从这次调整看 AI 数据工程的核心技术栈
聊完了组织逻辑，我们落地到技术层面。如果数据团队要承担起“定义模型能力边界”的角色，那 AI 数据工程师需要掌握哪些核心技术能力？
结合当前大模型数据的热门方向，我认为以下六个方向是 AI 数据工程的核心技术栈。
4.1 数据采集与数据源管理
大模型训练需要的数据来源非常多样：
- 公开网页数据
- 开源代码仓库
- 学术论文与书籍
- 结构化数据库
- 用户行为数据（需合规授权）
- 人工生产的数据
数据采集不是简单地把数据“抓下来”，而是要解决数据源的覆盖度、时效性、合规性、更新频率等问题。对于一个数据团队来说，建设统一的数据源管理平台，是第一步。
4.2 数据清洗与数据去重
这是数据工程里最基础也最重要的环节。大模型训练数据里常见的“脏数据”包括：
- 重复数据：同一个文本出现多次，会导致模型过拟合；
- 噪音数据：HTML 标签、乱码、无意义符号；
- 低质量数据：短文本、无信息量文本、病句；
- 有害数据：违反安全规范的内容、越狱指令、隐私信息。
数据清洗的目标，是在不损失有效信息的前提下，把噪音和低质量数据降到最低。
这里想多说一句去重。很多人低估了数据去重对大模型训练的重要性。如果训练数据里有大量的重复文本，模型会把这些文本当成“重点知识”来学习，导致模型对其他低频知识的记忆能力变差。高质量的去重，是大模型训练数据建设的第一步。
4.3 数据标注与指令数据构建
指令微调（SFT）阶段，需要大量高质量的人工标注数据。如何管理标注团队、设计标注规范、控制标注质量，是数据团队的核心能力。
此外，指令数据的构建也是一个技术活。不是简单地把问题-答案对收集起来就行，而是要设计数据配比，确保模型在数学、代码、逻辑推理、知识问答、创意生成等能力上的均衡发展。
4.4 数据增强与合成数据
当真实数据不够用或者质量不够高时，就需要数据增强。在 CV 领域，数据增强已经很成熟了，比如旋转、裁剪、加噪。但在 NLP 和大模型领域，数据增强还在快速演化中。
现在比较热门的方向是合成数据：用大模型生成训练数据。比如，用 Teacher 模型生成一批高质量的问答对，再经过清洗和人工审核，作为 Student 模型的训练数据。这种方式在数学推理、代码生成、角色对话等场景中已经有不少落地案例。
不过，合成数据也有风险。如果合成数据的分布和真实数据分布偏差过大，会导致模型在真实场景中表现不稳定。所以，合成数据通常是作为真实数据的补充，而不是替代。
4.5 数据版本管理与数据血缘
大模型的训练数据，会频繁迭代。一个数据集从 v1 到 v2，中间可能经历了多轮清洗、标注、增强。如何管理数据集的版本？如何追溯一条数据从哪里来、经过了什么处理？这就是数据版本管理和数据血缘要做的事。
数据血缘的价值在于：当模型效果出现问题时，能够快速定位是训练数据中的哪一部分导致的。如果数据血缘不清晰，出了问题只能“全量回滚”，效率非常低。
4.6 数据质量评估与监控
数据质量不能靠“感觉”，需要一套量化指标来评估。常见的数据质量指标包括：
- 完整性：数据字段是否有缺失；
- 一致性：同一实体在不同数据源中是否一致；
- 准确性：数据内容是否正确；
- 时效性：数据是否过期；
- 安全性：是否包含敏感信息。
在大模型训练场景中，还需要关注数据分布指标：数据在类别、长度、难度、领域上的分布是否合理。如果训练数据中代码数据占比过高，模型可能在其他领域上的表现会下降。数据配比的合理性，通常需要用实验来验证。
5. 从“关系数据库里的数据”到“大模型能读懂的数据”
这次字节的组织调整，也让我联想到一个在数据工程领域被反复讨论的问题：如何把关系数据库里的数据，加工成大模型能读懂的数据？
很多企业积累了大量的业务数据，这些数据存储在 MySQL、PostgreSQL、Oracle 等关系型数据库中。但大模型无法直接“读懂”结构化数据。模型需要的是自然语言文本。于是，从结构化数据到自然语言文本的转换，就成了企业落地大模型应用必须解决的问题。
这里给出一个通用的处理思路。
5.1 第一步：理解数据结构
关系数据库里的数据以表（Table）为单位组织，表之间通过主外键关联。要处理和转换这些数据，第一步是理解数据库的 Schema。
核心要做的事包括：
- 了解每张表的字段含义；
- 了解表之间的关联关系；
- 了解数据的更新频率和时效性；
- 识别敏感字段和需要脱敏的字段。
建议通过编写数据字典，把每张表的 Schema 和业务含义文档化。数据字典是后续所有工作的基础。
5.2 第二步：设计数据抽取与预处理流程
根据后续使用场景，决定抽取哪些数据，以及如何处理。
关键步骤：
- 按时间范围抽取数据；
- 过滤掉明显无效的数据；
- 对敏感字段进行脱敏处理；
- 将多个相关表进行关联，形成完整的业务记录。
这一步的技术难点是：如何保证抽取的数据能够覆盖完整的业务逻辑。比如，用户的“订单记录”和“退单记录”分布在不同的表里，抽取时需要做关联，否则后续生成的文本就会缺少关键信息。
5.3 第三步：将结构化数据转为文本描述
这一步是核心。常见的转换方式有两种：
第一种是模板化转换。设计统一的文本模板，将结构化数据填充进去。例如，将订单表数据转换为：
用户张三在2024年6月1日下单购买了商品A，数量2件，单价199元，实付金额358元（优惠40元），支付方式为微信支付。第二种是语义化转换。针对特定任务，把结构化数据转换成更自然的语言描述。比如，用于客服问答场景时，可以把订单数据转换成“用户咨询话术”和“客服回答话术”的对话对。
这两种方式各有优劣。模板化转换效率高、准确率高，但自然度一般；语义化转换更接近真实场景，但成本更高，需要结合大模型生成和人工审核。
5.4 第四步：构建可训练或可检索的数据集
转换后的文本，需要根据应用场景进一步加工：
- 如果用于模型微调，需要整理成“输入-输出”的样本对，并做数据配比；
- 如果用于 RAG（检索增强生成），需要做文本切块、向量化，并构建向量索引；
- 如果用于评估，需要构建评测集，附上标准答案或评估规则。
这一步的产出，才是大模型真正能“读懂”的数据。
这个流程看起来不复杂，但在实际项目里，几乎每一步都有坑。最典型的坑有两个：一个是数据脱敏没做好，导致敏感信息泄漏；另一个是表关联逻辑不对，导致转换后的文本语义错误。建议在项目初期，用小样本先把整个流程跑通，再逐步放大数据量。
6. 数据团队升咖后，对 AI 应用开发的三个实际影响
回到字节这次调整。数据团队从业务线剥离、集中到 Core Data，看起来是一次内部组织变动，但它会对 AI 应用开发产生实际影响。
6.1 影响一：数据能力将更加平台化
数据团队集中管理后，数据能力会以平台化的方式对外输出。AI 应用开发者不需要自己去对接各个业务线的数据团队，而是直接使用统一的数据平台能力。
这意味着，AI 应用开发中的数据获取成本会下降，数据质量会更有保障。对于开发者来说，这是一件好事。
6.2 影响二：数据治理和合规的要求会更高
数据团队集中到 Core Data 后，数据治理和数据合规的边界会变得更加清晰。所有数据资产统一管理，敏感数据的识别、脱敏、权限管控也更容易标准化。
对 AI 应用开发者来说，这意味着使用数据时需要更加关注合规要求。特别是在涉及用户隐私数据的场景中，数据权限申请、数据使用留痕会成为标准流程。
6.3 影响三：数据工程岗位的需求会持续增加
这次调整释放了一个信号：数据团队在大厂组织架构中的地位在上升。随之而来的，是数据工程相关岗位的需求持续增加。特别是以下三类人才：
- 懂大模型训练数据建设的数据工程师；
- 懂数据治理和数据合规的数据架构师；
- 懂数据标注产线管理和质量控制的 AI 数据产品经理。
如果你正在考虑技术方向，AI 数据工程是一个值得关注的领域。它不像算法岗位那样有很高的数学门槛，但对工程能力、数据敏感度、业务理解力的要求很高，是一个“越老越吃香”的方向。
7. 数据团队建设中的常见问题与思考
不管是字节这样的大厂，还是正在做 AI 应用的中小团队，数据团队建设都会遇到一些共性问题。这里整理几个典型的场景，并聊聊我的思考。
7.1 数据团队应该放在业务线还是中台？
这是组织设计中最常见的问题。
业务线拥有数据团队，优点是响应快、贴近业务，缺点是容易重复建设、数据标准不统一。中台拥有数据团队，优点是标准化、复用性强，缺点是可能离业务远、响应慢。
字节的这次调整，给出的答案更偏向“中台化”。但实际落地中，很多公司会采用“双轨制”：中台数据团队负责基础设施和通用数据能力，业务线保留少量数据开发人员，负责业务侧的数据需求对接。
这个模式的核心，是明确中台与业务线的边界：中台负责“建好路”，业务线负责“用好路”。
7.2 如何评估数据团队的产出价值？
数据团队的产出，不像算法团队那样有直接的指标（比如模型准确率、召回率）。所以数据团队的绩效评估，在很多公司是一个难题。
在大模型时代，我建议用“数据对模型效果的影响”来评估数据团队，而不是用“产出了多少数据”来评估。
比如，可以设计这样的评估维度：
- 数据质量合格率：抽检数据样本中的合格比例；
- 数据交付及时率：数据是否按计划交付给模型训练团队；
- 数据迭代效果：数据更新后，模型在评测集上的指标变化；
- 数据基础设施效率：数据平台的处理效率、稳定性、成本指标。
这些维度不一定适用所有团队，但方向是明确的：数据团队的评估，要围绕“数据对业务/模型的实际贡献”来设计，而不是围绕“工作量”来设计。
7.3 如何避免数据团队变成“标注团队”？
在大模型团队里，数据团队很容易被“降级”为标注管理团队——只负责组织人力做标注，技术含量低，话语权弱。
要避免这一点，数据团队需要主动向上游和下游延伸：
- 向上游延伸：参与数据采集方案设计、数据源选择、数据配比规划；
- 向下游延伸：参与数据质量对模型效果的影响分析、数据迭代策略制定。
换句话说，数据团队不能只做“执行”，还要做“规划”和“分析”。如果数据团队只被动响应需求，那就很难摆脱“标注团队”的定位。
8. 给数据工程师与 AI 开发者的实践建议
最后，结合这次字节调整和行业趋势，给正在做数据方向或者对 AI 数据工程感兴趣的开发者一些具体建议。
8.1 重视数据质量的量化评估
数据质量不能靠“感觉”，要建立量化指标体系。建议从完整性、一致性、准确性、时效性、安全性、分布合理性几个维度设计指标，并形成数据质量报告。大模型训练数据尤其要关注数据分布指标，避免数据配比失衡导致模型能力偏差。
8.2 建立数据血缘意识
在做数据清洗、转换、增强时，要养成记录数据血缘的习惯。哪条数据来自哪里、经过了哪些处理、最后被哪个模型使用，都要有记录。建议使用数据版本管理工具，每次数据变更都生成新版本，并记录变更说明。这样在模型效果出现问题时，才能快速定位数据原因。
8.3 建设自动化数据处理流水线
数据处理不能靠“手工操作”，要建设自动化的数据流水线。建议从以下环节开始自动化：
- 数据源定时接入；
- 数据清洗的自动触发；
- 数据质量检查的自动运行；
- 数据版本发布的自动记录。
自动化流水线的好处是可以减少人为错误，也能提高数据处理效率。一开始不用追求完整，可以先跑通最小链路，再逐步完善。
8.4 关注数据合规与安全边界
大模型训练数据涉及大量文本内容，数据合规与安全是绝对不可忽视的红线。建议重点关注：
- 敏感信息识别与脱敏；
- 数据访问权限的最小化管控；
- 数据使用的审计留痕；
- 涉及个人信息的数据处理，严格遵守相关法规要求，准确理解并执行数据主体的授权范围。
数据合规不是数据团队一个部门的事，但从数据团队做起是最佳切入点。因为数据团队是数据的入口和出口，把好合规关，才能让下游模型训练和应用开发没有后顾之忧。
8.5 不要只做数据执行，要理解模型
数据工程师如果想在 AI 时代有更强的竞争力，建议花时间理解大模型的基本原理。不需要成为算法专家，但要知道以下几点：
- 训练数据、评测数据、预训练数据、SFT 数据的区别与用途；
- 数据分布对模型能力的影响；
- 数据质量与模型评测指标之间的关系；
- 合成数据、数据增强的常见方法与风险。
当你理解了模型，你才能真正理解“什么样的数据是好数据”。从“执行数据需求”到“定义数据标准”，是数据工程师向更高层级跃迁的关键一步。
9. 总结与思考
字节 AI 数据部门升咖、并入 Core Data，是一次值得行业关注的组织信号。它说明在大模型时代，数据不再是“辅助资源”，而是和算力、算法并列的核心基础设施。
数据团队没有交给科学家，并不是数据团队的价值被低估，恰恰相反，数据团队的价值正在被重新评估。科学家的核心能力在建模，而数据团队的核心能力在数据工程、数据治理和数据生产。两者需要分工协作，而不是互相替代。
对技术人来说，这次调整带来的启示是：
第一，AI 数据工程是一个有长期价值的赛道。无论大模型技术如何演进，数据质量始终是模型能力的基石。
第二，数据工程师要主动提升对模型的理解，从“执行者”变成“定义者”。
第三，数据治理、数据合规、数据版本管理这些基础能力，在大模型时代不是被削弱了，而是更加重要了。
字节的这次组织调整，只是行业的一个切片。但透过这个切片，我们能看到的是一场正在发生的、关于数据价值的重新定义。对于正在做 AI 应用、或者在数据领域深耕的开发者来说，这既是挑战，也是机会。
数据团队的位置，正在从幕后走向台前。这个趋势，值得所有人关注。
