潜在能力天花板：为什么更大的模型解决不了你的问题

在一个运行时间足够长的 AI 项目中，几乎都会出现一种模式。团队构建了一个原型，演示效果看起来不错，但在生产环境中，输出结果不够一致。有人建议切换到最新的前沿模型——用 GPT-4o 代替 GPT-3.5，用 Claude Opus 代替 Sonnet，用 Gemini Ultra 代替 Pro。有时这会有所帮助，但最终这种方法会不再奏效。团队发现，他们为每次推理支付了 5-10 倍的费用，延迟增加了一倍，而任务准确率仍然停留在 78%，而不是他们需要的 90%。

这就是潜在能力上限（latent capability ceiling）：即你所使用的语言模型的原始规模不再是限制因素的临界点。这是一个有经验数据支持的真实现象，大多数团队在遇到它时却浑然不觉——因为“使用更大的模型”这一反射动作成本低、速度快，并且在项目早期往往非常有效。

扩展数据究竟说明了什么

关于大语言模型（LLM）的传统说法是：参数越多 → 能力越强。这个说法从总体上看是正确的，但它掩盖了从业者在特定任务中所经历的现实。

将模型从 10B 参数扩展到 20B 参数，通常会在基准测试任务上带来 10-15% 的提升。而从 100B 扩展到 200B，提升仅为 1-2%。这并不是什么秘密——它与 Chinchilla 扩展定律的发现一致，并在 2024 年和 2025 年的多篇研究论文中得到了体现。曲线起初很陡峭，随后趋于平缓。

更令人不安的是，大约 61% 的下游任务表现出非单调扩展行为：它们并不会随着模型规模的增长而如期改进，有些甚至会陷入停滞或出现倒退。政治说服任务、专门领域的推理以及窄领域的分类任务特别容易达到饱和。无论模型规模如何增加，模型都达到了一个无法超越的性能水平。

根本性的限制不在于架构，而在于通用目的的预训练，无论规模多大，都无法替代特定任务的信号。一个在互联网数据上训练的模型对万事万物都了解很多。而你的任务可能非常具体。这两者并不会像人们假设的那样契合。

诊断问题：是能力差距还是其他原因？

在断定你遇到了能力上限之前，你需要排除另外三个更常见且修复成本更低的解释。

提示词定义不足（Prompt underspecification）。 像“让它更专业”或“总结这份文档”之类的指令为模型留下了巨大的模糊空间。输出的差异并非模型失效，而是模型在面对不完整的规格说明时尽其所能。在你动模型之前，明确的要求（格式、长度、包含什么、排除什么、如何处理边缘案例）通常能缩小 20-40% 的感知准确率差距。反直觉的是，对于像 o1 和 o3 这样经过推理优化的模型，简单的零样本（zero-shot）提示词往往优于复杂的多步脚手架（multi-step scaffolding）——因此，“在提示词中添加更多内容”并不总是答案。

评估集失效（Broken evals）。 在新评估集上 0% 的通过率几乎总是评估集本身的问题，而不是模型能力不足。如果评分器惩罚了有效的替代措辞，或者两个领域专家都无法独立达成一致的任务规范，亦或是与实际使用模式不匹配的死板模板，都会让一个有能力的模型看起来显得无能。在将失败归咎于模型之前，请手动阅读对话记录。确认失败是真正的错误，而不是评估过程的人为偏差。

分布不匹配（Distribution mismatch）。 如果你的评估集是根据精选示例构建的，而生产流量更加杂乱——不同的术语、不同的句子结构、不同的边缘案例——你会看到性能崩溃。这看起来像是能力上限，但实际上是数据问题。模型是有能力的；只是你的评估集不能代表你实际要求它做的事情。

一旦你排除了这些因素，你面对的就是真正的上限。接下来的问题是该怎么办。

究竟什么能突破上限

当原始模型规模失效时，有三种策略可以可靠地释放进一步的改进：针对特定领域数据进行微调（fine-tuning）、检索增强（RAG）以及任务拆解。每种策略都解决了上限行为背后的不同根本原因。

针对特定领域数据进行微调

近期研究中最显著的例子是：一个经过微调的 27B 开源模型在临床笔记生成方面的表现比 Claude Sonnet 4 高出 60%。而在微调之前，同一个 27B 模型的表现要差 35%。微调完全逆转了这一差距——且推理成本降低了 10-100 倍。

这种模式在客服工单分类、法律文档分析和金融信息提取任务中反复出现。一个经过微调的小模型通常能达到比通用前沿 API 更高的准确率，同时运行成本便宜约 50 倍。只有在以下情况下，这种经济效益才会对你有利：

• 任务定义明确、稳定，具有一致的输入/输出结构。
• 拥有足够的高质量示例（对于 LoRA/PEFT 通常需要 500-5000 对，全量微调则需要更多）。
• 在该任务中，模型的行为和格式与它的知识储备同样重要。

当你的知识库频繁变化、无法策划足够高质量的训练数据，或者你仍在摸索任务究竟是什么时，微调就没有意义了。

检索增强生成

微调教会模型 如何表现。RAG 赋予模型 知识。这种区别很重要，因为它们解决的是不同的问题。

如果你的准确率瓶颈是由于模型缺乏最新的或特定领域的底层事实——它不了解你的产品功能、内部政策或客户的合同条款——那么 RAG 就是正确的杠杆。在提示词编写正确的前提下，为模型增加检索功能通常能使知识密集型任务的准确率提升 5–8 个百分点。与微调结合使用时，两者的收益大致是可以叠加的。

失败的模式是将 RAG 应用于行为问题。如果模型掌握了事实，但输出格式错误、无法遵循指令或在推理步骤中产生幻觉，那么检索并不能提供帮助。在选择解决方案之前，你需要诊断出你面临的是哪种类型的差距。

任务分解

有些任务之所以遇到瓶颈，是因为模型试图在一次生成中完成过多的工作。对组合式和多跳查询任务的研究表明，通过系统化的任务分解——将复杂任务分解为模型可以按顺序可靠处理的子任务——可以带来 10–40 个百分点的提升。

典型的例子是研究任务，它需要检索相关事实、合成草稿、根据源材料进行验证并对输出进行格式化。一个要求完成所有这些工作的单一提示词会创建一个漫长且脆弱的依赖链。将其分解为四个较小的调用——每个调用都有自己的输入、输出模式（schema）和评估——可以使每个步骤都可验证，并使整个流水线更加稳健。

这里的失败模式是过度分解。过多微小的子任务会增加协调开销，可能导致你错过单次生成模型本可以发现的联系，并成倍增加延迟和成本。这需要根据你的具体任务进行经验测量来找到平衡点——通常 2–4 个专门的子任务是合适的粒度级别。

何时采用哪种方案

这一决策并非主观臆断。有四个变量决定了哪条路径值得投资：

准确率要求。如果你需要在某个窄领域任务中达到 95% 以上的准确率，微调通常是必经之路。如果 85% 就可以接受，那么一个提示词优化良好且配合 RAG 的前沿模型通常能在没有训练开销的情况下达到目标。

数据新鲜度。如果你的任务所需的知识每周或每天都在变化，那么微调静态模型会带来维护负担。RAG 能更好地处理动态知识。

推理规模。在低请求量的情况下，前沿模型的成本无关紧要。在每天数百万次请求的情况下，1.50 美元 / 百万 token 的前沿模型与 0.30 美元 / 百万 token 的微调小语言模型（SLM）之间 5 倍的成本差异，往往决定了一个产品是盈利的还是昂贵的。

任务稳定性。如果你仍在摸索任务的具体内容，请不要在微调上投入任何精力。它会将你锁定在目前对问题的理解中。先通过提示词优化确定任务规范，当定义稳定后再进行微调。

常见的失败模式：盲目扩展而非诊断

组织最大的失败不在于使用了错误的技术，而在于从未诊断过你面临的是哪种类型的问题。团队升级到下一个前沿模型，看到微小的改进，再次升级，花费数月时间去追求那些在结构上无法通过扩大模型规模获得的收益。

这种情况的发生是因为升级模型在操作上成本很低。你只需更改一个参数，运行现有的评估，看看数值是否上升。而微调需要数据清洗、训练基础设施和更长的迭代周期。任务分解则需要重新思考你的架构。两者都需要承认问题出在系统设计上，而不是模型本身。

在进行任何模型升级之前，需要询问的诊断性问题是：如果这项任务由领域专家仅凭记忆来完成，他们能做对吗？如果能，那么问题可能出在数据获取（RAG）或格式一致性（微调）上。如果不能——如果该任务确实需要人类凭记忆无法完成的推理——那么模型能力可能才是真正的瓶颈。

大多数生产环境中的 AI 准确率问题都无法通过第二次检查。在能够获取正确信息的情况下，这些任务完全在人类的能力范围之内。瓶颈并不在于模型的智能，而在于系统呈现正确上下文、清晰定义任务以及为下游可靠使用而结构化输出的能力。

另一个考量因素：测试时计算

推理模型类别——如 o1、o3、Claude extended thinking——代表了一个完全不同的扩展维度。这些模型不是增加预训练计算量，而是在推理过程中投入更多计算量来思考更难的问题。在之前看似遇到瓶颈的基准测试中，推理模型已经取得了突破：o3 在 ARC-AGI 上达到了 87.5%（而 GPT-4o 仅为 5%），在 SWE-bench Verified 上达到了 71.7%。

对于受限于推理能力的任务——如数学推导、多步逻辑推理、复杂代码生成——推理模型可能值得投入额外的延迟和成本溢价。对于受限于知识或格式的任务，它们通常没有帮助。

实际意义是：如果你已经排除了提示词问题、评估问题和数据问题，而微调或 RAG 仍无法提升指标，那么推理模型可能是下一个正确的实验方向。但要将其视为一个特定的假设，而不是默认选项。

天花板是系统信号

生产环境 AI 任务中的能力天花板几乎总是在向你传递关于模型周边系统的信息，而不仅仅是模型本身。它在告诉你：模型缺乏正确的知识；或者任务定义不够精准；或者输出结构过于模糊，导致无法持续稳定生成；又或者该任务本质上是多个小任务的组合，需要拆开独立处理。

那些能最快突破这些天花板的工程师，是那些不再将模型选择视为唯一变量的人。他们会诊断出究竟是哪种约束在真正起限制作用，通过评估工具（evals）来独立衡量每种约束，并选择能够解决特定瓶颈的技术，而不是仅仅选择尝试成本最低的技术。

更多的算力无法解决数据问题。更大的模型无法修复失效的评估。更好的提示词（prompt）无法弥补缺失的检索层。天花板是诊断结果，而非最终判决。