把”模型放大到一定规模，能力突然从无到有”当成工程规律去依赖，是不靠谱的。涌现能力（Emergent Abilities）指的是在小模型上完全失败、放大参数或数据后才出现的能力，如多步算术、跨语种迁移、复杂代码补全。但这条规律在 2023 年起就遭到 Schaeffer 等学者的系统质疑——很多所谓的”突然跳跃”，只是评测指标选得不够平滑带来的视觉假象。在内部 AIGC 产品里，我曾因为”模型大了就一定涌现复杂能力”而推迟了小型化路线，结果小模型在合适的 prompt 工程与工具调用下，反而能稳定覆盖 80% 业务；后来把”押注涌现”改成”按任务门槛选模型”，整体响应成本才真正降下来。
一、涌现能力的定义与常见清单
Wei 等人在 2022 年给出的定义被广泛引用：能力在小模型上接近随机水平，模型规模超过某个阈值后成绩陡升，曲线形如跃迁而非平缓爬升。常见被列为”涌现”的任务包括：少样本 prompt 中的多步推理、字符级操作、跨语言翻译、形式化数学证明、复杂指令遵循。
| 能力类别 | 小模型表现 | 大模型表现 | 是否真正涌现 | 备注 |
|---|---|---|---|---|
| 多步算术（如 4 位数加法） | 接近 0% | 显著抬升 | 任务复杂度主导，指标非线性放大视觉 | 改用连续指标后曲线趋平 |
| In-context Learning | 弱 | 强 | 真正涌现 | 与”归纳头”等电路出现相关 |
| 跨语种翻译 | 差 | 显著改善 | 渐进式，混合涌现 | 训练数据覆盖度影响极大 |
| 复杂指令遵循 | 差 | 强 | 强涌现表现 | 指令微调可提前”诱发”该能力 |
| 代码补全 / 多文件改动 | 弱 | 强 | 任务难度阈值驱动 | 评测指标选择影响结论 |
判断某个能力是否”真涌现”的关键，是换用更平滑的连续指标（如 token 编辑距离、token 级 BLEU）后看曲线是否仍然跃迁。如果换指标后变成平滑上升，原始”涌现”多半是评测假象；如果跃迁依然在，那才是值得投入的能力。
二、为什么会有涌现，以及它为何被争议
涌现现象的理论根源可以追溯到 Anderson 那篇”More is Different”——复杂系统在不同尺度会展现新规律。在神经网络里，规模化带来了新的电路结构（如用于 in-context learning 的归纳头）和新能力（如长程推理），这在机制层面是真实的。
争议则集中在评测侧：很多所谓”涌现”严重依赖离散、非线性的指标（例如 exact match、pass@1 二值化），当改用平滑指标后，能力提升曲线常常是连续的、可预测的。这也解释了为什么”小模型在某些任务上居然打平大模型”——评测口径不同，结果就会反转。
更关键的是，涌现能力还和训练数据、提示策略、推理时计算深度强相关：chain-of-thought、工具调用、self-consistency 都能让”小模型 + 好工程”逼近”大模型裸跑”的水平。这条规律对应用开发的直接影响是：不要把”模型必须够大”当成前提，而要把”能力是否可被诱导”作为选型依据。
三、对 AI 应用开发的三条启示
- 以任务门槛选模型，不以规模选模型：先看业务要解决的任务在哪个难度区间，再选能稳定跨过门槛的最小模型。能用 7B + RAG 解决的，不上 70B；能用 Sonnet 解决的，不必上 Opus。
- 把”涌现”视为概率事件：把复杂能力看作”高方差能力”——同一 prompt 在不同请求上结果可能差异很大。设计上要做自检、投票、重试，而不是假设”模型既然涌现了就能稳定输出”。
- 用工程化手段主动诱发能力：instruction tuning、tool use、CoT prompting、self-consistency 等手段，可以把某些”涌现门槛”压到更小的模型上。换句话说，工程能换来部分规模红利。
下面这段用 OpenAI SDK 演示”小模型 + 工具调用”绕过”复杂涌现能力”假设的写法，在内部 RAG 项目里被反复用到：
from openai import OpenAI
import json
client = OpenAI()
def get_order_status(order_id: str) -> str:
# 真实业务里这里查 DB
return json.dumps({"order_id": order_id, "status": "shipped"})
response = client.chat.completions.create(
model="gpt-4o-mini",
tools=[{
"type": "function",
"function": {
"name": "get_order_status",
"description": "查询订单的当前状态",
"parameters": {
"type": "object",
"properties": {"order_id": {"type": "string"}},
"required": ["order_id"],
},
},
}],
messages=[
{"role": "system", "content": "你是订单助手，需要时调用工具查真实数据。"},
{"role": "user", "content": "帮我查一下订单 #A1029 的状态。"},
],
)
# 即使是"小模型"，只要工具明确，也能稳定给出可验证答案
tool_call = response.choices[0].message.tool_calls[0]
if tool_call.function.name == "get_order_status":
args = json.loads(tool_call.function.arguments)
result = get_order_status(args["order_id"])
print(result)这段代码说明：复杂多步推理不必全押在”大模型涌现”上，把决策拆给”小模型 + 工具链”往往更可控、更省成本。
四、几条容易踩的误区
不要把”涌现”和”AGI 前兆”混为一谈。涌现是规模化的伴生现象，不必然指向通用智能；同样的，模型也可能涌现出意料之外的有害行为（如策略性欺骗、奖励 hacking），评估框架必须配套升级。
另一个误区是把涌现曲线当成可预测的工程 milestone。Wei 等人的早期工作里，跃迁的阈值因任务而异、无法在事前精确预测——按”等模型到了再上”做产品规划，往往落后于”用工程手段把现有模型用到极限”的团队。
到这里，关于涌现是什么、它如何被争议、它对应用开发意味着什么就讲完了。真正的工程经验是：把涌现当高方差现象管理，比把它当确定性规律依赖，更接近 AI 应用的真实状态。
常见问题（FAQ）
Q1：涌现能力是真实存在的还是评测假象？
两者都有。机制层面真实存在（如归纳头电路），但部分”突然跳跃”是离散指标造成的视觉假象。
Q2：小模型能”诱导”出涌现能力吗？
能。CoT prompting、工具调用、self-consistency 等工程手段可让小模型逼近大模型的部分能力。
Q3：选模型该相信”规模越大越好”吗？
不应。以任务门槛选最小可用模型，叠加工程化能力诱发，比单纯堆规模更稳定且经济。
