大模型涌现能力的工程含义：哪些任务靠堆参数，哪些不行

产品经理常常问一个看起来很合理的问题：再过半年模型变强，这个功能是不是就不用做了？

答案取决于这个功能在 LLM 能力图谱里落在哪一档。有些能力是规模的副产品，模型一变大就有了，再去封装就是浪费。有些能力是结构性缺口，模型再大也补不上，必须靠工程兜底。还有一档介于中间——上一代等不到，但花更多推理 token 就能兑换出来。把任务分错档，是 LLM 应用工程里最大的浪费源。

涌现到底是什么，又不是什么

Jason Wei 等人在 2022 年提出"涌现能力"这个提法：一种能力在小模型上根本不存在，模型规模超过某个阈值之后突然出现。论文里的例子很具体。8 位数加法在 PaLM 540B 之前几乎是 0，到 PaLM 540B 才跳到能用的水平；多步算术和思维链推理在 100B 参数（约 10²³ 训练 FLOPs）附近出现拐点；MMLU 在 Chinchilla 70B、GPT-3 175B 这一档开始从随机水平爬出来。Wei 等人把这种"非渐进式"的能力跃迁称为 emergent。

2023 年 Rylan Schaeffer 等人在 NeurIPS 拿了 Outstanding Paper 奖，立场不太一样。他们指出，很多"涌现"曲线是评测指标制造的视觉效果。8 位数加法用 exact-match 评分时，每一位都要正确才得分，小模型几乎全错——曲线被"贴在 0"贴了很久，直到大模型才"突然"抬头。换成 token edit distance 或 log-likelihood，曲线会变得平滑、可外推。Schaeffer 的结论不是"能力是假的"，而是"突变是指标造成的，性能本身是可预测的连续函数"。

两篇论文表面上对立，工程上其实可以合用：

性能确实随规模上升，这是事实。
用户体验是否突变，取决于指标——产品里的"通过/失败"判定天然就是非连续的。
涌现从工程视角看，不是物理学问题，是产品定义问题。

下面这套分类，建立在这个工程视角上。

靠规模"白送"的能力

过去三年，下面几类能力已经从"要做"变成"默认有"。在它们上面做太多自定义工程，是在和模型版本号赛跑。

少样本上下文学习。GPT-3 那篇论文（Brown et al., 2020）展示了一个在 13B–175B 之间显著抬头的能力：给模型几个例子，它就能照着做，不需要梯度更新。今天任何一个主流 chat 模型都默认具备。早期社区写的 few-shot prompt 模板生成器、动态示例选择库，绝大多数已经没什么用。

指令跟随。InstructGPT 论文（Ouyang et al., 2022）里有一个反直觉的结果：1.3B 经过 RLHF 的 InstructGPT，输出比 175B 的原版 GPT-3 更受人类偏好。指令跟随不是参数堆出来的，是对齐方法叠加上去的；今天每一代基础模型出来时，这一层基本是免费配套。如果产品逻辑里还在写"如果模型回复跑题，回退到关键词匹配"，可以拿掉了。

基础常识推理和简单代码理解。一段中文请求"把下面这段 JSON 里的时间戳全部转成 ISO 8601 格式"，今天任何一个 70B 级开源模型都能完成。早年要靠 LangChain 链式封装的事情——先抽实体、再判断类型、再调用工具、再合并——很多在新一代模型里一次 prompt 就够了。

判断一个能力是不是"白送"档，有一个粗略信号：能不能找到一年前需要用工程解决、今天一次 prompt 就能拿到结果的同类任务。如果能，正在做的相似封装大概率也活不过下一代。

靠规模永远等不到的能力

下面几类是结构性问题，不是参数量的问题。模型再大，它们也不会自己出现。

领域事实和私有数据。模型的训练截止时间是物理事实——公司昨天发布的新 SKU、内部 wiki 上周修订的合规条款、客户上个月签的合同里那条 SLA，无论模型有多大都不可能"通过看 token 看出来"。Soudani 等人在 2024 年 SIGIR-AP 的一份对比里很直接：对长尾事实知识，RAG 大幅领先持续微调；微调能调风格、调格式，不擅长往模型里塞具体事实。工程对策是 RAG——把权威源放在调用上下文里，并要求模型给出引用。

实时数据。股价、库存、天气、上一秒的航班状态。即使是 Claude 3.7 Sonnet，知识截止也只到 2024 年 10 月。这一档没有讨论空间——必须做工具调用或检索。一个反模式是让模型"猜"实时数据再加一句"作为参考"的免责声明，这只是把准确性问题转嫁给用户。

确定性结构化输出。下游要消费严格符合 JSON Schema 的输出时，prompt 工程能做到的极限大约在 95%。OpenAI 2024 年 8 月发布 Structured Outputs 时给了一个对照数据：GPT-4 在复杂 schema 上用 prompt 引导只能做到大约 40%，引入基于上下文无关文法的约束解码之后，gpt-4o-2024-08-06 直接到 100%。100% 合法 JSON 不是模型能力上限的问题，是采样策略的问题——靠工程层包住采样器才能解决，靠堆参数不行。

忠实摘要、严格不超出来源。Vectara 维护的 Hallucination Leaderboard 长期显示一个尴尬现象：模型变大，摘要可读性确实提升，但"加入来源里没有的事实"也变多了。大模型的世界知识更多，它会"补全"它认为合理但来源未声明的信息。任何要求"严格只用来源内容"的产品——合同摘要、医疗记录归纳、法务问答——必须靠工程做事后比对，不能假设模型自己会守住边界。

长尾任务可靠性。从 90% 到 99.9% 的距离，往往比 50% 到 90% 还远。规模带来平均水平上升，但尾部失败模式经常很顽固。这一档的工程对策是评估体系——把失败案例固化成测试集、给关键路径加 fallback、对高风险输出加人工审核或重试。

中间档：靠推理 token 兑换的能力

2024 下半年到 2025 上半年，能力图谱多了一个新变量。OpenAI 在 2024 年 9 月发布 o1，把训练目标从"一次性产生答案"改成"先在内部思考、再产出答案"。内部那段思考链不暴露给用户，但消耗 token、消耗时间。o1 在 IMO 资格赛拿到 83%，同期 GPT-4o 只有 13%。12 月预告的 o3 在 ARC-AGI-1 半私有集上拿到 75.7%（标准计算预算）和 87.5%（172 倍计算预算），FrontierMath 25.2%，AIME 2024 96.7%。2025 年 1 月 DeepSeek-R1 用 GRPO 把这种"推理时间换能力"的训练范式开源化，AIME pass@1 拿到约 79.8%。2 月 Anthropic 在 Claude 3.7 Sonnet 上把"标准模式 / 扩展思考模式"做成同一个模型的两套行为，思考预算由调用方控制，最高到 128k token。

Snell 等人 2024 年 8 月的一篇论文给出了一个反直觉对比：在 MATH-500 部分子集上，一个 1B 模型用最优测试时计算策略，可以打过一个 14 倍参数量的大模型。参数和推理 token 是两种可以互换的资源。

这件事改写了工程图谱。原来标在"靠规模等不到"那栏的几类任务——复杂多步推理、严肃数学、需要长程规划的代码任务——开始往中间档挪。但这一档没有外延到所有任务：

领域事实、实时数据、确定性输出这三项不会因为"想得更久"而被解决。它们是信息不在模型里、不在采样空间里的问题，给再多思考 token 也补不出来。
推理时间成本以数量级增长。o3 在最高分那一档的单题成本是数千美元算力，不是产品里能默认开启的开关。
推理模型在简单任务上反而会变啰嗦、变慢。Claude 3.7 Sonnet 的 hybrid reasoning 设计承认了这一点——大多数请求不需要扩展思考。

实际做法是在路由层判断任务类型，把"该思考"的请求送进推理模式，把"该即时"的请求送进标准模式。多一个 SKU、多一档预算、多一套评估——不能假装它免费。

一张判断表

把上面的讨论压成一张可以直接用的表。

任务特征	是否随规模白送	推理 token 能否换	推荐工程对策	典型反模式
指令跟随 / chat 对齐	是	—	直接用基础模型	自己写规则引擎做意图分类
少样本上下文学习	是	—	Prompt + 示例选择	复杂的模板编排库
基础常识推理	是	—	单 prompt	多步链式抽取再合并
多语言基础翻译	是	—	直接调用	中转到专用翻译 API
领域 / 私有事实	否	否	RAG + 引用要求	把私有文档塞进微调集
实时数据	否	否	工具调用 / 搜索	让模型猜 + 免责声明
严格 JSON Schema 输出	否	否	约束解码（Structured Outputs / grammar）	反复在 prompt 里要求"只输出 JSON"
忠实于来源的摘要	否	部分	事后 NLI 比对 + 引用追踪	假设大模型自然忠实
复杂多步数学 / 推理	部分	是	推理模型 + 推理预算控制	让标准模型展开十级 CoT
长程代码重构	部分	是	推理模型 + 工作流分解	单 prompt 让模型一次性改全仓
长尾失败可靠性（99.9%+）	否	否	评估 + fallback + 人审	用平均准确率代表产品质量

第二列"是否随规模白送"指过去两年的趋势；第三列"推理 token 能否换"指 2024 下半年起的推理模型范式。

接到新需求时可以走下面这条决策路径，把它分进对应的工程档位。

图 1：LLM 应用任务分档决策

flowchart TD
  A[新任务] --> B{依赖最新或私有数据?}
  B -- 是 --> C[RAG / 工具调用]
  B -- 否 --> D{要求确定性结构或边界?}
  D -- 是 --> E[约束解码 / 事后校验]
  D -- 否 --> F{复杂多步或严肃推理?}
  F -- 是 --> G[推理模型 + 预算控制]
  F -- 否 --> H[基础模型 + 单 prompt]
  C --> I[评估 + 兜底]
  E --> I
  G --> I
  H --> I

所有路径最后都汇到"评估 + 兜底"——这是下面要说的最后一点。

落地建议

第一，每个新功能先做"规模假设三档分类"。在开工前明确这个功能依赖的核心能力属于哪一档：现在就白送、推理 token 能换、永远靠工程兜底。三档对应三种工期估计、三种成本结构、三种生命周期预期。分错档，整个工程预算就错了。

第二，别和模型抢会被下一代碾压的工作。如果正在写的封装是给一个"今天模型勉强能做、需要规则修补"的任务做兜底，那这层封装的生命周期大概率不会超过下一代模型。把工程资源投到模型本来就不擅长的地方——RAG 索引质量、工具调用的安全边界、约束解码的 schema 设计、评估集的覆盖度——这些是模型变强也不会让你白做的工作。

第三，别让模型独自承担确定性、最新性、域知识。这三件事是 LLM 的结构性弱项，无论参数多大。任何把它们交给模型独自完成的设计，本质上是在用产品 SLA 赌模型当天的状态。

第四，评估比 prompt 更值得长期投入。一套覆盖关键失败模式的评估集，价值会随时间累积——下一代模型上来可以一晚上跑完回归。一段写得很巧的 prompt，下一代模型出来可能就过时了。Anthropic 在 2024 年 12 月的 Building Effective Agents 里把这一点说得很直白：先用最简单的方案跑起来，让评估告诉你下一步要不要加复杂度，而不是反过来。

结尾

涌现是路标，不是路。路标告诉你哪些事不用自己修，但路还是要修——而且越是参数变大也修不掉的那一段，越值得现在投资。

参考资料

Wei et al., "Emergent Abilities of Large Language Models," TMLR 2022. https://arxiv.org/abs/2206.07682
Schaeffer et al., "Are Emergent Abilities of Large Language Models a Mirage?" NeurIPS 2023 Outstanding Paper. https://arxiv.org/abs/2304.15004
Wei et al., "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models," 2022. https://arxiv.org/abs/2201.11903
Brown et al., "Language Models are Few-Shot Learners," 2020. https://arxiv.org/abs/2005.14165
Ouyang et al., "Training Language Models to Follow Instructions with Human Feedback" (InstructGPT), 2022. https://arxiv.org/abs/2203.02155
Snell et al., "Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters," 2024. https://arxiv.org/abs/2408.03314
OpenAI, "Introducing OpenAI o1-preview," September 2024. https://openai.com/index/introducing-openai-o1-preview/
DeepSeek, "DeepSeek-R1 Release Notes," January 2025. https://api-docs.deepseek.com/news/news250120
Anthropic, "Claude 3.7 Sonnet and Claude Code," February 2025. https://www.anthropic.com/news/claude-3-7-sonnet
OpenAI, "Introducing Structured Outputs in the API," August 2024. https://openai.com/index/introducing-structured-outputs-in-the-api/
Anthropic, "Building Effective Agents," December 2024. https://www.anthropic.com/research/building-effective-agents
Soudani et al., "Fine Tuning vs. Retrieval Augmented Generation for Less Popular Knowledge," SIGIR-AP 2024.
Vectara Hallucination Leaderboard. https://github.com/vectara/hallucination-leaderboard