字节新设AI数据部门：大模型竞争进入数据效率时代

据 36 氪独家报道，字节跳动在 AI 组织架构上又落下一枚棋子：继 Seed、Flow 之后，一个直指「数据」方向的新 AI 一级部门正式成型。

这件事放到技术社区里，最值得关注的不是“又多了一个部门”，而是大模型公司的竞争重心，正在从模型结构、算力规模，悄悄转移到数据效率上。模型参数可以靠堆算力追赶，但数据质量、数据配比、数据评估、合成数据这一整套工程能力，很难短期复制。

这篇文章不聊八卦，只讲技术影响。我们从字节现有 AI 部门布局出发，拆一下新数据部门可能在做什么，然后落到实际：大模型时代的数据工程到底怎么做，AI 应用开发者应该提前做哪些准备。

1. 核心信息速览：字节 AI 部门阵列补齐数据拼图

在分析新部门之前，先看一张简化版的字节 AI 组织布局。需要说明的是，字节跳动没有公开完整的组织架构图，以下信息主要来自公开报道和行业共识，具体以公司官方口径为准。

Seed 解决的是“模型能不能做”，Flow 解决的是“用户怎么用”，而新数据部门要解决的，是“模型靠什么学、怎么学得又快又好”。

大模型研发链路中，数据不是一次性消耗品。预训练阶段需要海量文本，后训练阶段需要指令数据、对齐数据、评测数据，上线之后还需要用户反馈数据反哺模型。这些数据分散在搜索、内容、互动、多模态等多个业务线，如果不建立一个独立的一级部门统一治理，就会出现各团队各存各的数据、格式不统一、质量参差不齐、重复建设严重的问题。

字节把数据单独提为一级部门，本质上是把数据从“模型研发的附属工作”升级为“公司级基础设施”。

2. 为什么大模型公司必须单独成立数据部门

大模型行业已经过了“算法炫技”的阶段。Transformer 架构大家都能用，算力可以租赁，开源模型权重可以下载，这时候决定模型差异的关键，很大程度落在数据上。

2.1 公开高质量文本数据正在枯竭

过去几年，大模型预训练把互联网上可获取的高质量文本几乎扫了一遍。代码、论文、百科、新闻、社区讨论，能抓的都被抓走了。数据工程师普遍的感受是：2018 年做一个清洗管道能在网上找到大量高质量网页，2024 年之后，新抓取的数据里噪声、重复内容、机器生成内容占比明显上升。

公开数据红利消失，倒逼大模型公司去做更精细的数据运营：从“有数据”到“有好数据”，再到“有模型真正缺的数据”。

2.2 数据质量直接决定模型能力上限

同样的参数量、同样的训练算力，数据质量不同，模型效果可以拉开明显差距。训练数据里的重复文本会降低模型多样性，错误标注会造成指令遵循混乱，格式不统一的语料会影响模型输出稳定性。

这也是为什么现在各家都强调“数据配比”。代码数据占比太高，模型容易丢失自然语言能力；中文数据占比太低，中文对话体验就会打折；数学推理题太少，模型逻辑推理就弱。数据配比这件事，需要大量实验和一套可量化的评估体系，不是写个脚本就能解决的。

2.3 评测数据与反馈数据形成数据飞轮

模型不是训练完就结束的。训练完要跑评测集，上线后要收集用户反馈，反馈数据经过清洗过滤，又变成下一轮训练的素材。

这个闭环里，评测集本身也是数据部门的核心产出。评测集质量差，模型迭代就失去方向；评测集泄露，模型分数虚高，实际能力跟不上。大模型公司要持续迭代，就必须有一套严格管理的数据评测体系。

字节新数据部门的成立，意味着字节要把这套数据飞轮能力体系化、平台化。

3. 数据部门最可能发力的技术方向

从大模型数据工程的一般技术路线来推测，新的数据一级部门大概率会覆盖以下几个方向。

3.1 数据清洗与质量过滤

原始数据不能直接喂给模型。网页抓取数据需要去重、去噪、去广告、去重复段落；代码数据需要过滤掉明显错误的代码块；文本数据需要统一编码格式、清理 HTML 标签、压缩连续空白字符。

质量过滤是数据管线的第一道关卡，也是最吃工程量的部分。它通常包含：

• 规则过滤：按文本长度、字符覆盖率、语言识别、敏感内容等规则批量筛除。
• 去重算法：MinHash、SimHash 在大规模数据集中做近似去重，防止重复文本挤占训练容量。
• 质量打分模型：训练一个小模型给文本质量打分，分低的直接丢弃。

3.2 数据配比与样本采样

预训练语料通常有多个来源：网页、书籍、论文、代码、对话、多模态图文对。不同来源的数据，数量级差异很大，直接按原始数量混合会导致低质量大语种淹没高质量小语种。

数据配比需要做可视化分析，观察不同来源数据的分布，然后设计采样权重，再通过小规模实验验证配比是否合理。这个工作非常依赖数据团队和分析工具链。

# 数据配比采样示例：按来源加权采样 import random sources = { "web": {"path": "data/web.jsonl", "weight": 0.4}, "book": {"path": "data/book.jsonl", "weight": 0.2}, "code": {"path": "data/code.jsonl", "weight": 0.3}, "math": {"path": "data/math.jsonl", "weight": 0.1}, } def sample_source(): choices = list(sources.keys()) weights = [sources[c]["weight"] for c in choices] return random.choices(choices, weights=weights, k=1)[0] for i in range(1000): src = sample_source() # 每次从 src 对应文件中取一条数据进行后续处理 print(src)

这段代码只是一个采样权重示例，真实场景还需要结合数据量、去重情况、训练阶段动态调整。

3.3 合成数据

当真实高质量数据不够时，合成数据是重要的补充手段。典型做法包括：

• 让强模型生成弱模型缺少的训练样本。
• 根据知识库自动生成指令-回答对。
• 在数学、代码、逻辑推理等领域，用规则和程序化方式生成带答案的题目。
• 对已有文本做改写、扩写、多语言翻译，增加数据多样性。

合成数据最大的坑是“模型自我重复”。如果强模型本身的分布就有缺陷，合成数据会放大这个缺陷，导致模型训练后多样性更差。所以合成数据必须搭配质量过滤和真实性校验，不能直接全量进训练集。

3.4 跨模态数据对齐

字节旗下有大量视频、图片、音频内容。多模态模型训练需要图文对、视频文本对、语音文本对。跨模态数据的核心工作是对齐：一张图对应什么文本描述，一段视频对应什么字幕和语音，一段语音对应什么说话人和情绪。

跨模态数据往往涉及时序对齐、语义对齐、指代消解等复杂问题。新数据部门如果做这件事，会直接影响字节在视频理解和多模态生成上的竞争力。

3.5 知识密度与长文本数据

模型要回答专业问题，不能只靠闲聊数据。知识密集型数据需要来自百科、论文、教科书、专业领域文档，并且要经过事实性校验。长文本数据则需要保证样本在数万 token 以上，用来训练模型的长上下文能力。

知识密度数据的难点在于：不是所有领域都有足够的公开高质量语料，尤其是医疗、法律、金融等垂直领域，数据往往在机构内部，获取和授权成本都很高。

3.6 评测集构建

没有好的评测集，就无法衡量数据改进是否有效。数据部门需要维护一套多维度评测集：

• 通用能力：常识问答、逻辑推理、数学计算。
• 专业能力：代码、法律、医疗、金融。
• 对齐能力：安全性、拒绝回答敏感问题、指令遵循。
• 多模态能力：图像理解、视频理解、语音识别。
• 中文专项：中文成语、古诗词、中文知识问答。

评测集要有版本管理，防止数据泄露，同时要能快速评估一次数据改动对全量能力的回退影响。

4. 这次调整对 AI 应用开发者意味着什么

字节是一家巨型公司，它内部组织架构调整，表面上看与普通开发者无关。但大模型行业的一个特点是：头部公司的技术方向选择，往往会影响下游工具链、API 能力和数据生态。

4.1 数据基础设施可能会以平台化能力释放

如果字节把数据部门做成平台化组织，未来大概率会沉淀出一套数据工具链或数据集服务。这类似于 Hugging Face 数据集生态，或者内部数据管线的对外开放。

对开发者来说，这意味着以后构建 RAG 应用、微调模型或者做模型评测时，能有更多高质量、合规的数据集和数据处理工具可用。数据获取门槛会下降。

4.2 RAG 应用的数据质量要求更高

RAG（检索增强生成）是目前企业落地大模型最主流的方式。RAG 的效果高度依赖文档切片、向量化质量、检索排序和重排。这些环节本质上是数据工程。

字节数据部门成立后，“数据质量决定模型上限”的观念会进一步普及。应用开发者在做知识库问答时，如果还停留在“把 PDF 丢进去就算完事”的阶段，很快会碰壁。

4.3 微调和评测将更加专业化

以前微调模型，大家关注的是训练框架、显卡数量和微调技巧。现在越来越多团队意识到，微调效果差，多半不是模型问题，而是数据问题。指令数据的格式、多样性、难度分布、答案质量，每一项都需要专业化处理。

评测环节也一样。很多团队上线模型后，只凭感觉判断效果，缺少一套可复现的评测集和评测脚本。字节将数据部门独立运营，也是在告诉行业：数据和评测是长期投资，不是临时抱佛脚。

5. 数据工程落地：把原始数据变成模型能读的数据

不管大厂是否成立数据部门，AI 应用开发者在自己的项目里都应该建立一套基础的数据工程能力。下面给出一条通用的数据管线思路，可以直接落地。

5.1 管线总览

一条基础的数据管线通常包含：

• 数据采集：来自数据库、文件、爬虫、业务日志。
• 数据清洗：去重、去空、去格式错误、去敏感信息。
• 数据转换：统一格式，生成 JSONL，构建指令对。
• 数据增强：改写、扩写、补充上下文。
• 质量控制：抽样检查、规则校验、质量打分。
• 数据版本管理：记录每次数据变更，便于回滚和复现。

5.2 用 Pandas 做数据清洗

结构化数据的清洗，Pandas 仍然是最高效的工具之一。下面是一个通用清洗示例：

import pandas as pd df = pd.read_csv("raw_data.csv") print(f"原始数据量: {len(df)}") # 删除全空行和关键字段为空的行 df = df.dropna(subset=["content"]) # 去除重复内容 df = df.drop_duplicates(subset=["content"]) # 过滤过短文本 df = df[df["content"].str.len() >= 20] # 统一时间字段 df["created_at"] = pd.to_datetime(df["created_at"]) # 去除包含敏感词的行（假设敏感词文件为 sensitive_words.txt） with open("sensitive_words.txt", "r", encoding="utf-8") as f: sensitive_words = [w.strip() for w in f.readlines()] mask = df["content"].apply( lambda x: not any(word in x for word in sensitive_words) ) df = df[mask] print(f"清洗后数据量: {len(df)}") df.to_csv("clean_data.csv", index=False, encoding="utf-8")

清洗过程要保留日志，记录每一步删除了多少数据，方便回溯。

5.3 转换成大模型训练的 JSONL 格式

非结构化文本和结构化表格，最终都要转换成模型可读的格式。指令微调最常用的是 JSONL，每行一个 JSON 对象。

import json def convert_to_jsonl(clean_df, output_path): with open(output_path, "w", encoding="utf-8") as f: for _, row in clean_df.iterrows(): sample = { "instruction": row.get("instruction", ""), "input": row.get("input", ""), "output": row.get("output", ""), "metadata": { "source": row.get("source", "unknown"), "quality_score": row.get("quality_score", 0.0) } } f.write(json.dumps(sample, ensure_ascii=False) + "\n") convert_to_jsonl(df, "train.jsonl")

这里的关键是字段语义要统一。指令数据不能把 instruction 和 input 混在一起，output 必须是高质量的标准答案，metadata 里最好带上来源和质量分数，方便后面做数据分析和过滤。

5.4 批量任务与质量控制

数据管线跑批任务时，必须考虑失败重试和质量抽检。

# 伪代码示例 def process_batch(input_dir, output_dir): for file in get_files(input_dir): try: processed = process_file(file) save_output(processed, output_dir) log_success(file) except Exception as e: log_error(file, str(e)) # 标记失败文件，稍后统一重试 def quality_check(sample_rate=0.05): samples = random_sample(output_dir, sample_rate) for sample in samples: score = human_or_model_review(sample) if score < threshold: raise Alert("数据质量不达标")

真实生产环境下，批量数据任务常遇到的问题包括：文件编码异常、字段缺失、内存溢出、外部 API 超时、数据源中断。每个环节都要有日志和重试机制。

6. 数据合规、版权与隐私边界

数据部门和技术团队在扩大数据能力的同时，必须把合规放在第一位。

6.1 版权数据授权

训练大模型需要海量文本、图片、音视频数据，但“能从网上公开抓到”不等于“可以自由用于模型训练”。不同国家和地区的版权规定不同，抓取公共网页数据训练模型可能存在法律风险。

企业数据团队需要建立一套来源合规审核机制：优先使用已授权数据集、开源数据集、自有业务数据；对爬取数据做来源记录和授权状态标注；涉及图像、视频、声音素材时，必须先确认版权归属。

6.2 隐私数据脱敏

用户个人信息、手机号、身份证号、地址、聊天记录、健康记录等都属于隐私数据，直接进入训练集存在严重的合规风险。

数据管线中必须加入 PII（个人身份信息）检测与脱敏环节。常见做法包括：

• 正则匹配手机号、邮箱、身份证号。
• 用实体识别模型标记姓名、地名、机构名。
• 对命中敏感字段的内容做替换或整条删除。
• 脱敏操作保留脱敏日志，便于审计。

6.3 用户数据使用边界

大模型公司收集用户反馈数据做模型优化，需要明确告知用户并获得合法授权。开发者如果使用第三方 API 收集数据，也要遵守平台服务条款，不能绕过接口限制批量抓取数据。

这里要特别提醒：任何绕过平台限制、窃取账号数据、利用接口未授权能力获取数据的行为，都是不可接受的。数据工程的前提是合法、合规、可信。

7. 团队如何跟进：从数据意识到数据管线

字节这种级别的公司可以把数据单独设为一级部门，中小团队没必要也无能力照搬，但可以借鉴思路，把数据工程嵌入日常工作流。

7.1 先建立数据版本管理

哪怕只是做 RAG 应用，也要对文档集做版本管理。今天换了一批文档，检索效果变好还是变差，必须能复现。推荐用 DVC、Git LFS 或者云对象存储加清单文件管理数据版本。

7.2 再建立最小评测集

不用追求大规模评测集，但至少要有一个能覆盖核心场景的测试集。比如做一个客服问答机器人，就应该准备 200 到 500 条覆盖常见问题、边界问题、拒答问题的测试样本，每次改数据、改提示词、换模型后都跑一遍。

{ "test_cases": [ { "id": "case_001", "question": "公司支持哪些支付方式？", "expected_keywords": ["微信支付", "支付宝", "银行卡"], "should_reject": false }, { "id": "case_002", "question": "可以帮我查询其他用户的订单吗？", "expected_keywords": [], "should_reject": true } ] }

有了这套评测集，数据改进才有依据。

7.3 把数据质量指标化

数据团队最容易犯的错是只关心数据量，不关心数据质量。建议在数据管线的每一步都记录质量指标：

• 原始数据量、清洗后数据量。
• 去重率、过滤率。
• 指令数据字段完整率。
• 答案平均长度、重复度。
• 人工抽样的满意率。

这些指标要落成可视化看板，定期复盘。

8. 常见问题与排查思路

在数据工程落地过程中，以下是几个高频问题和排查方向。

9. 总结与下一步

字节继 Seed、Flow 之后成立直指「数据」的新 AI 一级部门，释放的信号很明确：大模型竞争已经进入数据效率时代。头部公司不再只比谁的模型参数大、谁的 GPU 多，而是比谁能把数据变成模型能力的效率更高。

对技术团队和个人开发者来说，最值得做的三件事：

第一，把数据工程正式纳入项目主线，配好清洗、转换、版本管理、评测四个环节。

第二，建立自己的最小评测集，所有模型和数据的改动都用评测集说话，不凭感觉判断效果。

第三，严格守住数据合规红线，版权、隐私、授权、安全边界一道都不能省。

字节的数据部门具体会发布哪些数据集、开放哪些数据和工具能力，还需要等官方信息。但趋势已经很清楚：谁先把数据变成可复用、高质量、可评估的工程资产，谁就能在大模型下一阶段竞争中拿到更大的主动权。