Paper 10: Scaling Laws, Pretraining Objectives, BERT, GPT, and T5

本篇为经典论文精读（历史回顾/经典打底定位），机制正文以原论文为锚点；最新进展见文末「SOTA 检查」。

Source Anchors

核心导读

Scaling laws 研究的是参数量、训练数据量、计算预算和语言建模 loss 之间的经验规律。它解释为什么 foundation model 能随规模扩大获得更强迁移能力，也提醒团队不要把“更大”误读成唯一答案：Chinchilla 等工作说明，在固定算力下，模型大小和训练 token 的配比同样决定能力边界。

BERT、GPT 和 T5 则展示了预训练目标如何塑造能力形态。BERT 的 masked language modeling 更偏理解、分类、抽取和排序；GPT 的 causal language modeling 更偏生成、对话、续写和 few-shot 任务迁移；T5 的 text-to-text 思想把多类 NLP 任务统一成输入到输出的转换。规模提供潜在能力，目标函数决定默认优势。

系统学习这组论文的关键，是把能力、知识和控制分开。大模型能力强，不代表知道当前政策、客户事实和账户状态；生成能力强，也不代表有权执行动作。金融零售 AI 架构应按任务选择 encoder、小模型、生成模型、RAG、PEFT、规则、工具和人工复核的组合，而不是用最大模型硬做所有事情。

---

1. 核心问题：能力、知识和控制不是一回事

企业讨论大模型时，常把几个问题混在一起。 模型是否足够大，是能力问题。 模型是否知道最新政策和客户事实，是知识来源问题。 模型是否会按组织期望回答，是行为对齐问题。 模型是否被允许采取行动，是权限和流程控制问题。 Scaling laws 主要回答第一个问题：当参数量、训练 token 和计算预算扩大时，语言建模 loss 如何变化，能力边界如何移动。 BERT、GPT、T5 主要回答第二个基础问题：不同预训练目标会让模型更擅长什么任务形态。 企业落地时，真正的难点是把这两类认知合并起来。 一个金融零售 AI 系统可能同时需要：

• 用 encoder 模型对投诉、工单、交易备注做分类和抽取。
• 用 embedding/reranker 找到正确政策和证据。
• 用 GPT-style 生成模型写客服草稿、调查 narrative 和解释文本。
• 用 seq2seq 或结构化输出路径把非结构化材料转换为字段。
• 用规则、审批、权限和审计控制客户权益、资金动作和监管记录。 如果把这些都交给一个最大模型，成本、延迟、风险和可解释性都会失控。 如果只看传统小模型，又会错过生成式 AI 在复杂文本工作流中的价值。 本篇要建立的是一套判断框架：规模决定潜在能力，目标函数塑造能力形态，系统架构决定这些能力能否进入生产。

---

2. 论文和技术贡献

2.1 Scaling laws：能力随规模变化，但受瓶颈约束

Kaplan 等人的 scaling laws 研究把语言模型 loss 与三类变量联系起来：

• 模型参数量。
• 训练数据量。
• 训练计算量。 它的重要性不在于某个具体系数，而在于证明：在一定范围内，扩大模型、数据和计算会带来相对平滑、可预测的性能改善。 这让 foundation model 从“试试看大一点会怎样”变成“可以用工程和投资模型规划能力提升”。 Chinchilla 进一步修正了早期直觉。 在固定计算预算下，过去一些大模型可能参数太多、训练 token 太少，处在 under-trained 状态。 更优策略不是单独把模型做大，而是让模型规模和数据规模匹配。 这对企业的启发很直接：算力预算有限时，盲目追最大参数不一定最优；数据质量、数据覆盖和训练 token 规模同样是能力变量。

2.2 BERT：用双向上下文学习理解表征

BERT 的贡献是把 Transformer encoder 用于大规模双向语言理解。 它的 masked language modeling 会遮住输入中的部分 token，让模型利用左右上下文恢复被遮住内容。 这种训练方式让模型学到句子内部和句子之间的语义关系，适合分类、抽取、匹配、检索排序等理解型任务。 BERT 不以长篇生成为核心目标。 它更像是企业 AI 管线中的“理解层组件”：把文本转成稳定表征、标签、实体或排序分数。

2.3 GPT：用自回归预测学习生成和迁移

GPT 路线采用 decoder-only Transformer，通过 causal language modeling 预测下一个 token。 模型只能看当前位置之前的文本。 这个简单目标可以扩展到海量文本，并自然支持续写、对话、总结、代码生成和逐步推理。 GPT-3 展示了规模化 causal LM 的 few-shot 能力：模型可以在 prompt 中看到少量例子后完成新任务，而不需要为每个任务单独训练分类头。 这改变了产品设计方式。 很多知识工作不再需要先设计固定标签或菜单，而可以表达为“给上下文、约束和示例，让模型生成下一段工作产物”。

2.4 T5：把 NLP 任务统一成 text-to-text

T5 的核心贡献是把翻译、摘要、分类、抽取、问答、改写等任务统一表述为文本输入到文本输出。 架构上，T5 使用 encoder-decoder。 encoder 读取输入，decoder 生成输出。 训练上，T5 使用 denoising / span corruption，让模型从被破坏的文本中恢复缺失片段。 这种路线的长期价值，不只是某个模型本身，而是任务建模思想：许多企业流程都可以变成“输入证据和约束，输出结构化或半结构化结果”。

---

3. 机制原理：三类预训练目标塑造三类能力

3.1 规模变量如何影响能力

可以把预训练看成压缩世界文本分布的过程。 参数提供容量。 数据提供覆盖。 计算提供优化路径。 如果参数不足，模型没有足够容量表达复杂模式。 如果数据不足，大模型会记住训练分布中的偶然性，泛化不稳定。 如果计算不足，模型无法充分学习数据中的结构。 Scaling laws 的工程价值，是帮助团队识别瓶颈在哪里。 一个高质量小模型在某些固定任务上可能优于昂贵大模型。 一个大模型如果缺少当前政策、客户事实和权限上下文，仍会生成不可靠答案。 一个模型即使在通用 benchmark 上强，也可能因为企业术语、表单、流程和风险边界不同而表现不稳定。

3.2 Masked language modeling 的能力偏向

BERT 的 MLM 目标可以写成：

输入: 客户申请 [MASK] 额度调整，并上传了收入证明。
目标: 预测 [MASK] 可能是 信用卡、贷款、临时、消费 等 token。

模型同时看左侧和右侧上下文。 这种双向理解让它很适合回答“这段文本属于什么”“这里提到了哪些实体”“两个文本是否语义匹配”“哪个段落更相关”。 在金融零售中，它常用于：

• 投诉类型识别。
• KYC 文件类别识别。
• 客服工单路由。
• 风险标签抽取。
• 检索 reranking。 这些任务有明确输入、标签或排序目标，不一定需要开放生成。

3.3 Causal language modeling 的能力偏向

GPT 的 causal LM 目标可以写成：

输入: 客户投诉称账户被
目标: 预测下一个 token: 冻结、盗用、扣费、限制、关闭...

模型通过不断预测下一个 token 学习如何延续上下文。 当训练数据足够大、模型足够强时，这种延续能力会表现为摘要、解释、推理草稿、代码、对话和计划生成。 但它的核心仍然是“生成最可能的下文”。 它不会自动知道哪些事实需要查数据库，哪些政策已经过期，哪些动作需要审批。 这就是为什么 GPT-style 模型进入企业流程时，必须连接 RAG、工具、规则、权限、评测和人工复核。

3.4 Text-to-text 和 seq2seq 的能力偏向

T5 的思想可以写成：

任务: classify complaint
输入: 客户说年费被重复收取，客服承诺未兑现。
输出: fee_dispute; service_quality

或：

任务: extract fields
输入: 一段工资单 OCR 文本
输出: {"employer": "...", "gross_income": "...", "pay_period": "..."}

这种形式强化了“任务就是转换”的设计方式。 很多业务流程本质上是从一种信息形态转换到另一种信息形态：

• 客户来信转换为投诉分类和处理路径。
• 政策条款转换为客服可读话术。
• 调查证据转换为 narrative 草稿。
• OCR 文本转换为结构化字段。 现代 instruction-tuned LLM 继承了这种任务统一思想，但企业仍要通过 schema、验证器和工作流约束输出。

3.5 后训练不是预训练的替代

SFT、RLHF、DPO、Constitutional AI 等后训练方法会让模型更会遵循指令、更符合偏好、更安全。 但后训练通常不解决以下问题：

• 最新政策事实。
• 客户账户状态。
• 用户权限。
• 审批责任。
• 可审计证据。
• 高风险动作授权。 预训练提供基础能力，后训练塑造默认行为，RAG 和工具提供外部事实，系统控制负责权限和责任。 把这些层次分清，是架构判断的基础。

---

4. 为什么这些方法有效

4.1 语言任务共享底层结构

分类、抽取、摘要、问答、改写、翻译和报告生成看似不同，但都依赖语义、实体、关系、句法、领域词汇和上下文结构。 大规模预训练先学习这些共享结构。 下游任务只需要少量示例、prompt、检索上下文或微调，就可以复用底座能力。 这就是 transfer learning 的价值。

4.2 规模带来覆盖和组合能力

随着数据和模型规模增长，模型接触到更多主题、格式、推理模式和语言现象。 它不只是记住更多句子，也更容易组合已有模式处理新任务。 这解释了为什么 GPT-style 模型在 few-shot、复杂指令和多步骤文本任务上表现突出。 但这种能力并不等于可靠性。 模型可能用相似模式填补缺失事实，也可能把训练中常见但当前不适用的说法套到具体业务场景里。

4.3 目标函数让能力有方向

同样是 Transformer，不同目标函数会形成不同默认行为。 BERT 更适合理解输入。 GPT 更适合生成下文。 T5 更适合输入到输出的转换。 这不是绝对边界，而是默认优势。 生产架构要利用默认优势，而不是用一个模型硬做所有任务。

---

5. 局限和误用

5.1 把 scaling laws 误解为“越大越好”

更大模型通常有更强潜在能力，但生产系统还受成本、延迟、稳定性、数据安全、可审计性和任务风险约束。 在高吞吐固定分类任务中，小模型或 encoder 模型可能更稳、更便宜、更容易验证。 在需要事实引用的政策问答中，最大模型如果没有 RAG，也可能比中等模型加好检索更差。

5.2 把参数知识当成企业事实

预训练参数中包含统计知识，不等于当前事实库。 金融零售政策、费率、产品条款、审批规则和监管要求会变。 客户账户、交易、KYC、投诉状态更不能靠模型记忆。 这些事实必须来自系统、知识库、RAG、工具或人工确认。

5.3 用微调替代知识治理

微调适合稳定输出格式、边界语气、标签习惯和领域表达。 它不适合把频繁变化的政策、客户事实或权限规则写死到模型权重里。 如果问题是“模型不知道当前资料”，优先考虑 RAG。 如果问题是“模型不知道是否允许做某件事”，优先考虑 policy engine 和 workflow。

5.4 忽略数据质量和授权

Scaling laws 讨论数据规模，但企业更需要关注数据质量和数据权利。 重复、过期、错误、无授权、含 PII/PCI 或带偏见的数据，会把风险写入模型和评测体系。 金融零售数据尤其需要目的限制、保留期限、脱敏、跨境审查和审计记录。

5.5 任务目标和业务目标错位

语言建模 loss 下降不代表投诉处理更合规、客户解释更清楚、调查效率更高。 企业必须把模型指标映射到业务和风险指标：

• 正确率。
• 高风险 recall。
• 引用支持率。
• 人工覆盖率。
• 客户投诉率。
• 审批通过率。
• 成本和延迟。

---

6. 架构和产品价值

6.1 模型组合，而不是单模型崇拜

成熟的 AI 系统通常是模型组合：

flowchart TB
  Request[Business Request] --> Router[Task and Risk Router]
  Router --> Enc[Encoder: classify / extract / rerank]
  Router --> Rag[RAG + Generator: grounded answer]
  Router --> Gen[GPT-style Generator: draft / explain / summarize]
  Router --> S2S[Text-to-text Path: transform / structure]
  Router --> Rules[Rules and Workflow: authority / decision]
  Enc --> Eval[Validation and Evidence]
  Rag --> Eval
  Gen --> Eval
  S2S --> Eval
  Rules --> Eval
  Eval --> Human[Human Review where risk requires]
  Eval --> Output[Approved Output]

这张图的重点是：模型不是系统中心的唯一组件。 路由、检索、验证、规则、人工复核和审计同样是产品能力。

6.2 任务选型判断

如果任务是固定标签分类，优先评估 encoder、小模型或轻量微调。 如果任务是事实问答，优先评估 RAG、引用、权限和版本控制。 如果任务是开放文本草稿，使用 GPT-style 生成模型，但必须接证据和审阅流程。 如果任务是字段转换，使用结构化输出、schema 校验和低置信度复核。 如果任务影响资金、账户、信贷、监管记录或客户权益，模型只能提供建议、草稿或证据整理，最终动作必须由规则、审批或人工责任链控制。

6.3 自训 foundation model 的门槛

从零训练金融零售 foundation model 需要的不只是 GPU。 它需要：

• 大规模合法可用语料。
• 数据清洗和去重。
• 隐私、版权和跨境治理。
• 分布式训练和恢复能力。
• 安全、偏见和领域 eval。
• 模型对齐和红队。
• serving、监控、回滚和成本治理。 多数企业的护城河并不在“自己训练通用模型”，而在业务流程、数据治理、风险控制、分发渠道、评测体系和系统集成。 更务实的路线通常是成熟 foundation model + RAG + 小模型 + PEFT + 工作流控制。

6.4 需求写法要反映模型路线

模糊需求：

系统使用 AI 自动处理客户投诉。

可验证需求：

系统应将投诉文本分类为 fee_dispute、fraud_claim、service_quality、credit_reporting、other。
每条输出必须包含 label、confidence、supporting_phrase 和 review_required。
fraud_claim 与 credit_reporting 的 recall 不低于 0.95。
confidence 低于 0.75 或多意图投诉必须进入人工复核。

这种需求能直接推动模型选择、数据准备和 eval 设计。

---

7. 金融零售系统案例：模型组合式客户运营助手

7.1 场景设定

一家零售银行希望建设客户运营助手，覆盖投诉分类、政策问答、文档抽取和调查草稿。 如果只用一个通用大模型，系统会遇到四类问题：

• 固定分类成本太高。
• 政策事实可能过期。
• 文档字段容易幻觉。
• 调查草稿可能缺少证据或越权定性。 因此更合理的是按任务拆解。

7.2 投诉分类

投诉分类适合 encoder 或小型 instruction model。 模型输入是投诉文本、渠道、产品线和历史标签。 输出是分类、置信度、支持短语和复核条件。 关键指标不是整体 accuracy，而是高风险类别 recall、多意图识别、人工修正率和 SLA 触发准确率。

7.3 政策问答

政策问答适合 RAG + 生成模型。 模型不能依赖参数记忆回答手续费、豁免条件或监管话术。 检索必须按产品、地区、客户类型、渠道、有效日期和权限过滤。 答案必须引用当前有效政策。 资料冲突或无权访问时，系统应澄清、拒答或升级。

7.4 文档抽取

工资单、银行流水、税表和证明文件适合 text-to-text / structured output 思路。 输出必须受 schema 约束。 金额、日期、账号、身份证件等字段要有格式校验和原文定位。 低置信字段不能自动填充审批系统，应进入人工复核。

7.5 AML 或投诉调查 narrative

调查 narrative 适合 GPT-style 生成模型，但它必须基于证据包。 系统应先收集交易、KYC、历史 case、客服记录和政策条款，再让模型生成草稿。 草稿应使用审慎语言，区分事实、推断和待确认事项。 提交监管报告、关闭案件或裁定投诉不能由模型单独完成。

7.6 统一控制

这个案例的核心不是某个模型，而是统一控制面：

• 任务路由。
• 数据权限。
• RAG 版本控制。
• 输出 schema。
• 高风险人工复核。
• eval gate。
• 运行日志和反馈闭环。 Scaling laws 告诉我们为什么强模型有价值。 BERT/GPT/T5 告诉我们不同任务该用什么能力。 架构控制决定这些能力能否可靠落地。

---

8. 学习验证

8.1 概念复述

用自己的话回答：

• Scaling laws 讨论的三个核心变量是什么？
• Chinchilla 为什么会改变“只做更大模型”的直觉？
• BERT 的 MLM 为什么适合分类、抽取和 rerank？
• GPT 的 causal LM 为什么适合生成、对话和 agent？
• T5 的 text-to-text 思想如何帮助业务流程建模？

8.2 任务路由练习

把下面任务分别路由到 encoder、GPT-style generator、seq2seq/structured output、RAG、rules 或 human review：

• 投诉类型识别。

• 手续费减免政策问答。

• 贷款申请材料字段抽取。

• AML case narrative 草稿。

• 信贷拒绝原因解释。

• 客户请求立即解冻账户。 每个任务写出：

• 推荐路线。

• 为什么不是单纯最大模型。

• 需要哪些事实来源。

• 主要 eval 指标。

• 哪些条件触发人工复核。

8.3 架构决策练习

写一页 ADR，题目是：

是否从零训练金融零售 foundation model？

ADR 至少回答：

• 业务目标是什么。
• 自训需要哪些数据、算力和治理能力。
• mature model + RAG + 小模型组合能否满足目标。
• 什么条件下自训或深度自托管才值得重新评估。
• 回滚和供应商替换策略是什么。

8.4 Eval 设计练习

为“投诉分类 + 政策问答”设计 50 条 eval case。 至少覆盖：

• 高频普通投诉。
• 欺诈、信用报告、法律威胁等高风险投诉。
• 多意图投诉。
• 过期政策和当前政策冲突。
• 无答案问题。
• 无权限访问问题。 每条样本要有 expected behavior、gold source、risk tier 和 failure tag。

---

9. 读完后应形成的判断

Scaling laws 解释 foundation model 为什么值得投资，但它不是产品架构的全部答案。 BERT、GPT、T5 解释预训练目标如何塑造能力偏向，但实际系统需要把多种能力组合起来。 企业 AI 的核心设计问题不是“选最大的模型”，而是“用最小足够能力、正确知识来源和可审计控制完成业务任务”。 金融零售场景尤其如此。 客户权益、资金动作、监管记录和风险决策不能靠语言模型概率直接决定。 正确路线是：让模型承担理解、生成、转换和辅助推理，让系统承担事实、权限、验证、审批和责任。

---

SOTA 检查 (2026-07-01)

• Chinchilla 的「约 20 tokens/参数」已不再是生产实践默认，但框架被扩展而非推翻：开源部署优先的模型普遍严重 overtrain 以压低推理成本——Llama-3-8B 训练到约 2000 tokens/参数量级，Qwen3-0.6B 达到约 60,000:1 的数据/参数比（2025-04 发布）；"Beyond Chinchilla-Optimal"（Sardana et al.）把推理成本显式纳入 compute-optimal 框架。结论：本篇「固定算力下模型/数据配比决定能力边界」的判断仍成立，但最优配比取决于是否计入推理侧成本，纯训练侧 compute-optimal 不再是唯一目标函数。
• Scaling law 研究前沿转向数据质量与稳健性：quality-aware scaling law 把数据质量作为与模型规模、数据量并列的第三变量（arXiv 2510.03313, 2025-10）；对 Chinchilla 拟合稳健性的系统性重评也在进行（arXiv 2509.23963, 2025-09）。这与本篇 5.4 节「数据质量和授权比原始规模更关键」的判断一致，且现在有了定量化框架。
• 新的 scaling 轴是 test-time compute / reasoning：2025 年起各家均提供推理档位——DeepSeek-R1（GRPO 训练，2025-01）、OpenAI o3、Claude extended thinking——「预训练 loss 幂律」不再是能力提升的唯一叙事。库内配套笔记见 docs/llm/day140-test-time-compute-scaling.md、docs/llm/day47-reasoning-models-o1-path.md、docs/llm/day48-deepseek-r1-grpo.md（LLM-150 计划，2026 完成）。
• BERT 系 encoder 路线仍现役，未被生成模型取代：ModernBERT（2024-12 发布，2T tokens，8K 上下文，139M/395M 两档）与 EuroBERT（2025-03 发布，5T tokens，210M/610M/2.1B 三档）在分类、抽取、检索 rerank 上仍是同成本档位的主流选择——直接支持本篇 6.1/6.2「理解型任务用 encoder、不用单一最大模型硬做」的架构结论。
• T5 的 text-to-text 思想以另一种形式存续：encoder-decoder 架构在通用 LLM 中已边缘化（现役主流为 decoder-only：DeepSeek-V3、Llama 4 Scout/Maverick、Qwen3 系列），但 instruction-tuned decoder-only 模型 + 结构化输出/schema 校验实质上继承了「任务即转换」的建模思想；本篇 3.4 节的能力偏向分析应按此更新阅读。
• 不随版本过时的框架性结论：能力/知识/控制三分（第 1 节）、目标函数决定默认能力偏向（第 3 节）、模型组合+路由+人工复核而非单模型崇拜（第 6 节）、语言建模指标必须映射业务/风险指标（5.5 节）——这些是架构判断框架，与具体模型版本无关。深入对照见 docs/llm/day40-kaplan-scaling-laws.md、docs/llm/day41-chinchilla-compute-optimal.md、docs/llm/day43-llama4-scout-maverick-behemoth.md、docs/llm/day44-qwen3-technical-report.md。