据 36 氪独家报道字节跳动在 AI 组织架构上又落下一枚棋子继 Seed、Flow 之后一个直指「数据」方向的新 AI 一级部门正式成型。这件事放到技术社区里最值得关注的不是“又多了一个部门”而是大模型公司的竞争重心正在从模型结构、算力规模悄悄转移到数据效率上。模型参数可以靠堆算力追赶但数据质量、数据配比、数据评估、合成数据这一整套工程能力很难短期复制。这篇文章不聊八卦只讲技术影响。我们从字节现有 AI 部门布局出发拆一下新数据部门可能在做什么然后落到实际大模型时代的数据工程到底怎么做AI 应用开发者应该提前做哪些准备。1. 核心信息速览字节 AI 部门阵列补齐数据拼图在分析新部门之前先看一张简化版的字节 AI 组织布局。需要说明的是字节跳动没有公开完整的组织架构图以下信息主要来自公开报道和行业共识具体以公司官方口径为准。部门/方向外界普遍理解技术关键词对外的典型产物SeedAI 大模型研究团队预训练、多模态、模型能力豆包大模型系列FlowAI 应用与智能体团队智能体、产品化、Agent豆包 App、即梦等 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, weightsweights, k1)[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, encodingutf-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, indexFalse, encodingutf-8)清洗过程要保留日志记录每一步删除了多少数据方便回溯。5.3 转换成大模型训练的 JSONL 格式非结构化文本和结构化表格最终都要转换成模型可读的格式。指令微调最常用的是 JSONL每行一个 JSON 对象。import json def convert_to_jsonl(clean_df, output_path): with open(output_path, w, encodingutf-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_asciiFalse) \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_rate0.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. 常见问题与排查思路在数据工程落地过程中以下是几个高频问题和排查方向。问题现象可能原因排查方式解决方案清洗后数据量骤减过滤规则过严或去重阈值过低查看每步过滤日志抽样检查被删数据放宽规则分层抽样验证过滤合理性数据量大但模型效果不提升数据质量差或分布单一用评测集对比不同数据版本效果提高质量过滤标准增加数据多样性合成数据导致模型重复输出合成样本同质化严重检查合成数据的重复率和模板多样性增加改写环节加入约束性采样指令数据格式混乱多个来源字段语义不一致统计各来源字段填充率统一字段 schema增加格式校验评测集分数虚高测试数据泄漏或评测集过旧检查评测集是否出现在训练数据中定期更新评测集建立泄漏检测机制批量任务卡住单条数据异常或外部服务超时查看任务日志定位卡住文件增加超时控制和单条失败隔离数据集存在版权风险来源未确认授权检查数据来源清单和授权记录下线无授权数据建立白名单机制隐私数据未脱敏缺少 PII 检测环节扫描训练集命中敏感字段加入脱敏模块过滤确认后再入库9. 总结与下一步字节继 Seed、Flow 之后成立直指「数据」的新 AI 一级部门释放的信号很明确大模型竞争已经进入数据效率时代。头部公司不再只比谁的模型参数大、谁的 GPU 多而是比谁能把数据变成模型能力的效率更高。对技术团队和个人开发者来说最值得做的三件事第一把数据工程正式纳入项目主线配好清洗、转换、版本管理、评测四个环节。第二建立自己的最小评测集所有模型和数据的改动都用评测集说话不凭感觉判断效果。第三严格守住数据合规红线版权、隐私、授权、安全边界一道都不能省。字节的数据部门具体会发布哪些数据集、开放哪些数据和工具能力还需要等官方信息。但趋势已经很清楚谁先把数据变成可复用、高质量、可评估的工程资产谁就能在大模型下一阶段竞争中拿到更大的主动权。
