字节 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 应用、或者在数据领域深耕的开发者来说这既是挑战也是机会。数据团队的位置正在从幕后走向台前。这个趋势值得所有人关注。