“语言模型的天花板”最近成了圈子里的高频词。不是大家突然唱衰而是很多事情实实在在发生了变化如果你仔细对比这两年发布的主流模型会发现综合能力还在涨但幅度明显放缓产品侧能感受到的惊喜越来越少用户在具体业务里遇到的问题也从“模型不会”慢慢变成“模型看起来会了但真用起来还是不够顺”。恰恰是这个时候一位以风格犀利、决策大胆著称的创始人成了所有人关注的焦点。因为他之前的几次判断都被验证过所以大家更关心在“模型能力接近上限”的预期下他下一场会押注哪里。这篇文章不打算做谜语人而是从技术角度把“天花板”这件事掰开揉碎再聊聊我认为最可能被押注的几个方向。顺便也会把普通开发者和团队真正用得上的选型方法、避坑经验一起写清楚。1. 语言模型的“天花板”到底卡在哪1.1 一个被忽略的事实模型没有退步是榜单不够用了过去一年我拿不同模型做内部测试时最大的感受是单一维度的分数已经说明不了问题。几个主流模型在综合评测榜单上咬得很紧差距只有一两分但这看似微弱的一两分在复杂业务里会被放得极大。举个例子一个涉及五十步推理的任务有的模型能从头到尾保持逻辑一致性有的模型中途开始自说自话甚至把所有中间步骤重新编排了一遍。评测分数接近真实体验天差地别这在行业内被称为“长尾能力差距”。这里有个关键原因评测基准趋于饱和了。头部模型在传统任务上的得分普遍冲到90分以上这些题对它们而言已经不算挑战剩下没被刷上去的部分恰恰是最难评分、最难自动验证的开放性问题。更要命的是数据污染——预训练语料可能已经包含了评测集原文模型根本不是“学会了推理”而是“记住了答案”。这就像考试前背过题库的学生你不能因为他考了高分就说他真正理解了这门课。所以当我们谈“天花板”时首先要区分两个概念能力分数天花板和实际应用天花板。前者是被评测集定义的后者是被真实世界中五花八门的任务定义的。最近头部模型发布时官方演示往往都选那些“看起来聪明、但很难被自动评测”的场景就是因为传统榜单已经撑不起差异化叙事。如果只看评测榜单你会觉得天花板早就到了但如果换到真实业务场景你会发现离“够用”还有相当的距离。1.2 三重瓶颈数据快到顶、算力不便宜、能源扛不住但从更宏观的维度看模型能力增长确实在逼近某种物理意义上的极限最直接的约束来自三个地方。第一是数据。高质量文本语料快用完了这是业内公开讨论过很多次的问题。市面上几乎所有能爬到的书籍、论文、网页、代码基本都被模型“读”过一遍。剩下的要么是重复内容要么是低质量噪声。有人提出用合成数据来续命但合成数据本身就是模型的输出如果拿模型生成的内容再去训练新模型很容易出现“循环退化”——像是复印件的复印件细节一层层丢失。最近很多训练团队都在做数据清洗不是因为洁癖而是因为不洗模型就真的不涨了。第二是算力。Scaling Law还在起作用但边际收益明显递减。过去可能付出2倍算力换来模型能力稳定提升现在可能要付出4倍算力才能换来评测分数上涨0.5个点。训练成本已经高到只有少数机构能玩更尴尬的是推理成本也在同步上升。一个模型训练出来用户每次调用都要承担推理开销如果模型本身不够高效“叫好不叫座”的困境就出现了。我见过不止一个团队因为推理账单太夸张被迫把已经上线的模型切成小尺寸版本。第三是能源这一点很多技术文章会忽略。大模型训练和持续运转需要大量电力数据中心已经成为电力消耗大户。单次大规模训练的耗电量可以和一个中小城市一天的用电量相当。这不是一句玩笑话。算力可以堆但电力供给、散热、碳中和指标都会成为扩张的硬约束。用一句行业里常说的话“以前是淤泥里淘沙现在是沙漠里滤水成本翻了好几倍收获还没怎么涨。”1.3 架构层面的隐性上限会“背诵”不等于会“推理”数据、算力、能源是外部约束更麻烦的是现有主流模型的架构本身也有上限。绝大多数大模型基于Transformer架构靠注意力机制在token之间建立联系。注意力机制非常强大但它倾向于把输入里的每个词都“平等地看一遍”于是当上下文特别长时有效信息会被稀释。我做过一个实验把一份120页的行业报告直接塞进长上下文窗口让模型抽取某一章的关键指标结果它经常把开头几页和结尾几页的内容回答得很准确中间部分则开始混淆。这不是模型“偷懒”而是注意力分配天然偏向序列两端。后来换了RAG的方案把文档切片之后再检索效果立刻好了很多。这说明当前架构的长上下文能力并没有很多人想象中那么可靠。更深层的问题是“记忆”和“推理”的边界。大模型本质上是一个巨大的记忆系统从训练语料中学会了统计规律。你问它“法国的首都是哪里”它能答对因为它见过太多类似的句子你问它“三个苹果加五个苹果等于几个”它也能答对因为它见过太多加减法的表达。但当你问一个真正需要多步推导、从未以类似形式出现在语料里的问题时它做得往往就不太好。思维链、自一致性、搜索增强这些方法能在推理时提升表现但代价是推理时间变长、成本变高。这就像一个人可以靠查资料、打草稿解决难题但你不能指望他每一道题都翻书翻半小时。2. 天花板之下的投注逻辑算力效率与物理世界2.1 从追求“最大参数”到追求“最高转换率”那位创始人最让我印象深刻的不是他押中了某些模型路线而是他反复强调的视角算力的价值不在于是不是最大而在于能不能被高效地转换成实际能力。过去两年很多人都在赌“更大更通用的底座”他也在赌但他更关注单位算力产出——也就是每花一块钱训练成本模型能力到底涨了多少每调用一次模型推理成本会不会把商业模式压垮。这个视角特别符合现在的局面。如果模型能力已经进入边际递减区间那么“再堆一倍参数”带来的竞争力提升很可能覆盖不了多出来的成本和工程复杂度。于是决策逻辑会从“模型有多大”转向“模型好不好用、单位能力贵不贵”。很多团队开始做模型蒸馏、做混合专家架构MoE把大模型的能力压缩到更小的体积或者只激活一部分参数。本质上都是在做“降本增效”这件事。在开源社区里这种趋势更明显。头部开源模型发布之后紧接着就会涌现一大批基于它的微调版本、量化版本、剪枝版本。这些工作不一定让模型变得更强但会让它变得更容易用。我认为下一阶段竞争的核心不是“谁的底座更聪明”而是“谁能把聪明的模型变得更便宜、更可控、更贴合场景”。2.2 最可能的三个押注方向推理侧、端侧、物理世界如果基于上述逻辑推断我认为“下一场投注”大概率会在三个方向上展开。第一个方向是推理侧增强。训练阶段已经把模型教会了基础能力但使用时还有很大的提升空间。比如用强化学习和搜索策略让模型在回答前“多想几步”或者用小参数模型搭配外部工具在推理时动态调用代码解释器、数据库、浏览器。它的核心卖点是不必重新花大钱训练就能显著提高模型在复杂任务上的表现。这对成本敏感的商业场景尤其友好。第二个方向是端侧模型与硬件协同。模型体积越来越小就有机会跑在手机、PC、车载设备甚至智能家居上。端侧的好处是低延迟、隐私安全、离线可用但它需要模型和底层芯片深度协同优化。这不只是软件问题还涉及到芯片设计、内存带宽、量化压缩等工程问题。一旦跑通就能摆脱“每次调用都要联网、都要付费”的中心化模式。第三个方向是具身智能。把语言模型接上视觉、听觉和行动能力放在机器人或仿真环境里让它通过与物理世界的交互学习。这可能是最疯狂、也最有想象力的押注。因为语言模型目前最大的局限是它只能从静态文本中学习缺少“验证”环节——它说错了也没有人会立刻告诉它错了。具身智能提供了一个闭环模型出指令实体执行传感器反馈结果模型据此修正。这个过程产生的新数据是真实世界的一手经验正好能绕开高质量文本数据枯竭的死结。横向对比这三个方向押注方向训练成本推理成本可落地阶段主要风险推理侧增强较低中当下可落地收益容易被少数大厂复制端侧模型与硬件协同中很低2-3年硬件生态碎片化严重具身智能高中3-5年技术链太长周期波动大2.3 为什么“物理世界”比“更大模型”更能摆脱天花板“更大模型”这个方向正在变得尴尬。继续用海量文本数据训练模型当然还会更强但已经明显接近那个“用一倍资源换小数点后几位提升”的阶段而且文本数据里缺失的常识、动作、因果反馈都无法靠继续“读书”补上。就像一个人把全世界的书都背下来也不代表他就能学会游泳。物理世界的反馈不一样。一个模型如果在仿真环境或者机器人上完成任务它能得到明确的成功或失败信号。这种信号可以用于强化学习不断修正模型的决策策略。更关键的是这种交互产生的数据是动态的、分布式的永远不会枯竭——太阳每天升起现实世界的场景组合是无限的。一旦这条数据生产链路跑通模型就不再局限于“人类写在网页上的知识”而是能获得“只有动手做才知道”的经验。所以我认为对“天花板”最强烈的对冲就是把AI从“语言的世界”拉进“物理的世界”。语言模型作为大脑机器人或仿真体作为手和眼睛让模型通过行动去验证语言描述。这条路线的门槛比单纯训练更高正因如此才更值得下重注。如果押中了它打开的就不是下一个版本的模型而是全新一类应用场景。3. 天花板之下普通从业者的实用应对3.1 别迷信公开榜单用一套自建任务集做选型听再多关于天花板和投注的讨论落到自己项目里最实际的问题还是预算有限到底选哪个模型。我的建议是不要直接拿公开榜单排名做决策哪怕是大厂发布的评测报告也别全信。正确做法是自己搭一套任务集亲自跑一遍。具体操作分三步根据业务场景选出15到20个有代表性的任务。不要全是技术题要包含逻辑推理、中文知识问答、产品文案改写、代码debug、长文档信息抽取等。每个任务写一个固定的Prompt确保不同模型收到完全相同的输入。给每个任务的输出定判断标准。能用脚本判定的用脚本比如JSON格式是否正确、代码能否跑通不能自动判定的至少制定一个简单打分表。重点记录三类数据正确率、平均响应时间、单次调用成本。用同一套任务集跑所有候选模型。把结果拉一张表按照“业务效果优先、成本第二”的原则做选择。我在一个文本抽取项目里做过对比某开源模型在公开榜上紧咬商业模型价格便宜很多我一度准备直接切换。结果自建测试一跑它在“从混排表格里按语义抽取指定字段”这个任务上成功率比商业模型低了接近三成。后来我结合了“开源模型 额外规则校验 二次重试”的方案效果才追平。公开榜单解决的是“谁更强”的泛化问题自建测试解决的是“谁适合你”的具体问题后者才值得你花半天时间去做。3.2 用组合拳绕开单点上限RAG 与 Agent 配合业务中很多“模型不够聪明”的现象其实不是模型能力真不够而是任务给得太“裸”。两个非常成熟的思路可以组合使用它们不要求你重新训练只需要做好系统工程。第一个是RAG检索增强生成。当模型对你不熟悉的私有知识回答得不好时不必指望它“记住”你的文档。正确做法是先把文档切片存储到向量数据库用户提问时检索出最相关的几个片段和问题一起交给模型生成回答。这里有个关键参数是切片大小。太短则上下文丢失太长则检索噪声大。我常用的经验值是每片500到800字重叠100字左右召回topK取8到12个片段。实际效果不够好时先检查召回再检查生成——多数问题的根源在召回。第二个是Agent智能体。当任务需要多步推理时不要让模型一口气输出最终答案而是让它规划步骤调用工具逐步验证再汇总结果。比如“帮我查一下某个产品近30天的价格走势”模型可以分成三步搜索产品信息、抓取历史价格、生成趋势总结。每一步的结果都可以被单独检查和修正。我在开发一个行业报告助手时把这两个思路缝合起来先用Agent规划需要哪些数据再用RAG去检索对应文档最后让模型基于检索结果生成结论。在长文档问答场景下正确率比直接塞长上下文提升了至少40%。3.3 微调前先劝退微调时再避坑这两年最容易被高估的技术就是微调。很多团队觉得模型表现不好第一反应是“微调一下”但大多数时候迁移学习里那句“data is king”会给你上一课。如果你的任务效果差是因为缺少领域知识微调效果好但如果任务效果差是因为Prompt没写好、召回没做好微调反而会让模型变笨。我踩过一个很典型的坑。有一段时间我需要让模型按指定格式输出结构化内容当时没有先做Prompt实验直接拿500条标注数据去微调一个基座模型。结果发现模型确实学会了输出JSON格式但它在其他通用能力上出现了明显退化连简单的常识问答都开始丢三落四。后来才知道这属于典型的“灾难性遗忘”——微调过程中模型原本学习到的通用知识被新数据冲淡了。从那以后我给自己定了三条规矩第一能用Prompt模板解决的绝对不动微调第二如果必须微调优先用LoRA这类参数高效微调方法冻结底座参数只更新少量额外参数第三准备微调数据时一定要做配比加入20%左右的通用数据防止模型“偏科”。现在很多人一开口就问“微调用的多少条数据”其实比数量更重要的是数据质量、任务难度和是否做防遗忘处理。4. 关于“天花板”的常见争议与踩坑实录4.1 “是模型笨还是你问得不对”的新解关于模型表现最常听到的一句话是“你问的方式不对”。这句话有一定道理但也常被当成万能挡箭牌。我的经验是要把问题分成两类一类是表达问题一类是能力问题。表达问题很好解决。模型对模棱两可的指令会给出随机发挥的结果把你的需求换成更明确的指令输出质量立刻上升。我的做法是同一件事用三种不同方式提问观察结果是否一致。如果换一种问法结果就好了说明是表达问题如果怎么问都答错那大概率是能力问题。后者不能指望靠提示词工程来翻盘要换模型或者改任务设计。提示词优化能提升的是模型能力的“可释放程度”好比一个运动员实力100分如果教练指令不清他只能跑到80分但你没法靠喊加油让他把实力提高到120分。我见过很多团队花几个星期调提示词调到最后能提升的空间已经很有限这时候最重要的决策是止损去试更强的模型或者改技术方案。4.2 投资叙事里的伪需求概念热不等于真实需求聊到“投注”时市场上最不缺的就是伪需求。前两年几乎所有行业都冒出一堆“大模型XX”的项目这些项目听起来很有想象力但很多都经不起成本测算。真正的落地场景有几个特征高频、重复、有明确的成本节约空间、用户愿意为结果付费。客服问答、代码辅助、文案生成、表格处理属于真实需求而单纯的聊天、角色扮演、内容生成则更多停留在“试用”阶段。技术人尤其容易混淆“技术先进”和“业务可行”。一个新模型在演示视频里再惊艳如果部署成本高于它节省的人力成本它在商业上就不可持续。我认为判断一个需求真伪不需要多高深的理论就看两件事一是有没有用户愿意持续付费二是能不能在不烧钱的情况下跑通单位经济模型。很多炒作概念的项目核心问题都是第二件事算不过账。4.3 我踩过的两个具体坑复盘这两年与大模型打交道的经历有两个坑让我印象最深写出来给大家避雷。第一个坑是微调数据里的噪声。我接手过一个客服意图识别项目从业务系统里导出了一批历史对话记录简单清洗之后直接作为微调数据。结果模型训练完上线原本分类准确率不错但模型开始频繁把“询问业务规则”归类成“投诉建议”因为历史数据里这部分用户情绪强烈。后来检查数据才发现标签是从旧系统迁移过来的存在大量错误标签。这次教训让我彻底明白了微调数据要先抽样人工检查标签噪声超过2%时宁可重新标注也别用自动化流程一股脑灌进去。第二个坑是拿公开榜单选型导致业务效果翻车。我在做一个复杂指令跟随的项目时某开源模型公开榜单分数比商业模型高出不少我一开始就选了它做到一半才发现它经常在指令里“漏步骤”。比如让它“先总结再翻译最后写标题”它经常只做前两步把最后一步忘掉。公开榜单对这种指令跟随能力的覆盖其实不算深入但我当时没有自建相关任务来测试。后来我调整了选型流程在正式接入前务必跑一批贴近业务的压力测试题。这两个坑都不是模型本身“坏”而是我的流程有漏洞数据没有验证评测没有贴近场景。写出来是希望大家少走点弯路。最后再分享一条我自己的体会。天花板这个话题其实不用太焦虑。模型能力增长变慢对普通开发者未必是坏事——它意味着基础设施趋于稳定你的技术选型不需要每三个月推倒重来。与其去猜哪个方向是终局不如把自己手头的事情做扎实自建测试集、算清单位成本、控制数据质量。等到下一阶段真正的突破来临时你已经站在一个足够稳的基座上随时可以接住它。