大模型方向的数据架构怎么做，是很多互联网数据人感兴趣的问题。表面看关键词相似（大规模数据处理、pipeline、质量治理），但实际做法和底层逻辑差异很大。

最近和大模型从业者有过些交流，有些体会。这篇文章打算从技术视角拆解，大模型的训练侧和应用侧，分别跟互联网数据架构的核心差异在哪里。

互联网数据架构的两条主线

分析侧：数仓 + BI

核心是业务指标体系 + 多层数仓建模。从 ODS（贴源层）经过 DWD（明细层）、DWS（汇总层）到 ADS（应用层），构建维度模型（星型/雪花），支撑报表、自助分析。架构关注点是数据口径一致性、指标定义规范、查询性能优化、权限管控。组织上往往有独立的数仓和 BI 团队。

算法侧：特征工程 + 模型服务

核心是离线特征计算 + 在线特征服务。用户行为产生事件流，ETL 管线做清洗聚合，输出到特征库（Feature Store），在线预测时从 Redis/HBase 读特征拼成向量，送入模型。特征是结构化的、预定义的、固定维度的。架构关注点是特征一致性（训练/推理）、实时性（Lambda/Kappa）、特征血缘、冷启动处理。

这两条主线共享底层存储和计算资源，但服务对象、质量标准、优化目标都不同。数据平台团队往往既要保证报表准确性，又要保证特征时效性，还要做好资源隔离防止互相影响。

训练侧：数据管线的范式转变

训练侧的数据分两半，预训练和后训练。后训练数据（SFT 数据构建、RLHF 偏好数据的标注和质检、合成数据生成）更像数据工程、标注运营和研究的混合体，跟互联网数据工作的差异更大，这里聚焦预训练管线。

大模型的预训练数据管线是语料驱动的批量迭代。从海量异构源（CommonCrawl、代码库、书籍、合成数据）采集，经过去重、质量过滤、有害内容过滤（毒性检测）、PII 清洗，组成 dataset snapshots，按配比混合（data mix）送入训练。

与互联网数据管线的关键差异

数据获取的挑战从「接入」变成「合规与质量」

互联网公司的数据主要在自己产品的埋点里，数据团队要做的是接入各业务线的日志：协议对不对、格式统不统一、链路稳不稳定。大模型公司的数据来自外部，要爬全网、跟出版社谈版权、设计规则过滤低质内容、用模型评估语料质量。

另外，语料配比（data mix）本身是被优化的对象：DoReMi 用一个小代理模型学各来源的最优权重，Llama 3 的技术报告专门描述了 mixture 的调整过程。大规模语料质量评估成了数据团队的核心工作。版权谈判本身归法务和 BD，但数据团队要为它提供依据（这份语料对模型效果值多少钱），还要维护每个来源的授权状态和溯源记录。这些工作内容在互联网数据团队里都没有对应。

schema 约束的对象变了

互联网数据管线强依赖预定义 schema（Hive 表、Protobuf），字段、类型、口径在写入时约定。预训练语料的内容是非结构化的，但管线本身高度结构化：文档在离线阶段就被规范成统一格式（jsonl/parquet，text 加 metadata），质量过滤、去重、验证全部在离线完成，很多 lab 还会预先 tokenize、pack 成定长序列存成二进制，训练时只做顺序读。

差异不在有没有 schema，而在 schema 约束的对象从业务字段变成了文档格式加元数据，验证的内容从字段口径变成了语料质量。

版本管理的对象变了

互联网数据管线版本化的是 ETL 代码和表结构，数据平台回滚是回滚代码。模型训练管线版本化的是 dataset snapshot、data mix 配比、deduplication 策略，dataset 本身成了一等公民。

一个训练 run 出了问题，要能追溯到它用的是哪个 dataset 版本、采样了多少、用了什么去重策略；发布模型前，要能证明训练语料里剔除了评测集（decontamination），否则 benchmark 分数不可信。互联网数据平台也有血缘（表级、字段级），但对象和粒度不同：那边追踪的是表和字段的加工链路，这边要的是 immutable snapshot 加实验级溯源。

计算模式从流式/定时批变成长周期大批量

互联网 ETL 是小时级/天级调度，增量更新。模型训练的数据准备是周/月级的任务，单次处理 PB 级语料，完成后 snapshot 冻结。训练时语料通常只过一个 epoch（高质量子集会重复采样几遍）。

难点在于：PB 级数据要做全局 shuffle，data loader 要有确定性，训练中断恢复后必须精确回到同一个数据位置，否则实验不可复现。对存储的要求也不同：互联网强调高并发写入和查询，模型训练强调顺序读的吞吐量。

质量评估从业务规则变成模型驱动

互联网数据质量是业务规则（空值率、枚举范围、逻辑一致性）+ 人工抽检。语料质量没法这样定规则，「一篇文档好不好」写不成校验条件，只能用模型来判断：算 perplexity（语言模型看这段文本通不通顺）、打 toxicity score（有害程度评分）、或者专门训一个小分类器给文档打质量分。最重的手段是 ablation（对比实验）：把某类数据从语料里去掉，重新训一个小模型对比效果，反向验证这类数据到底有没有贡献。质量标准本身是个研究问题，不是工程规范。

应用侧：从结构化特征到动态 Prompt Context

互联网算法侧的用法前面写过：特征是结构化的、预定义的、维度固定的。

大模型应用是另一种用法：运行时动态检索相关文档，组装成 prompt context，可能包括检索到的知识、few-shot examples、工具调用的返回、多轮对话历史。Context 是非结构化的、动态生成的、受 token 预算约束的。新增知识源只需要做 embedding 和 indexing，不需要改模型。

这两种用法带来的架构差异是连锁的。

存储从行式键值变成向量索引加原文。互联网特征存在 Redis 里，key 是 user_id 或 item_id，value 是特征向量。模型应用需要向量数据库做语义检索，同时保留原文以便组装 prompt。索引和存储是分离的，embedding 模型升级时只需要重建索引，不需要改原文。

数据新鲜度的权衡不同。互联网特征库追求秒级更新，因为用户行为立刻影响下一次推荐。模型应用的知识库可以接受小时级甚至天级的索引更新延迟，但对检索召回质量的要求极高：召回错了文档或召回的文档互相冲突，整个推理就歪了。

质量标准从数据指标变成端到端推理效果。互联网特征工程看特征覆盖率、缺失率这些数据本身的指标。RAG 的检索环节也有自己的指标，比如 recall@k（前 k 条召回结果里有没有相关文档）、MRR（相关文档排得靠不靠前），但这些只用来排查问题，不作验收，验收标准是最终回答的准确性和相关性。这意味着数据团队要深度参与 prompt 调优和 eval 设计，而不是只管交付数据。

治理的难点变了。互联网数据治理是用户画像脱敏、权限管控、满足合规要求。这些在模型应用里还得做，而且更难：以前权限管到表和字段就够了，现在检索是按语义找内容的，权限要管到「这个用户的提问不能召回哪些文档」，一份权限没设对的文档，随时可能被拼进别人的 prompt。另外多了一类新威胁：恶意指令可能直接写在用户输入里，也可能藏在知识库的文档里，随检索被拼进 prompt，诱导模型说出不该说的内容，也就是 prompt injection。

两种架构下数据团队在做什么

训练侧的数据工作

训练侧要的能力是：大规模数据处理的工程能力（处理 PB 级数据的去重和采样）、数据质量工程（设计过滤 pipeline，用模型评估语料质量）、合规流程（数据来源的授权和溯源管理，有害内容审核）。这些跟互联网数据平台的基础能力部分相通。

业务理解的焦点变了：从用户行为和业务指标，变成语料质量对模型能力的影响。哪类数据提升推理能力，哪类数据引入 bias。

技术栈的新部分包括 dataset 版本管理、大规模去重、合成数据生成、data mix 配比优化。

应用侧的数据工作

检索增强和 prompt context 管理：怎么设计 embedding 和 indexing 策略、怎么做召回和排序、怎么在 token 预算内做 context 组装、怎么让 agent 有有效的 memory。

技术栈跟互联网数仓和特征工程完全不同，向量数据库、embedding 模型、语义路由、prompt cache 是新的基础设施。

质量标准前面说过：端到端的推理效果，不是数据本身的指标。落到团队日常，prompt 调优和 eval 设计成了数据工作的一部分。

组织架构的差异

互联网数据平台是服务全公司业务的中台，数据团队相对独立，按技术域分工（数仓、工程、数据科学）。

大模型公司的数据团队往往直接嵌在 model development（训练侧）或 product（应用侧）里，不是独立中台。训练侧的数据负责人参与 model scaling 的决策（data scaling law），应用侧的数据负责人参与 product 的 prompt 设计和 eval 框架。

两种架构下，数据团队的价值证明方式不同。互联网是平台规模和服务稳定性，大模型是对模型效果的直接贡献。