过去一年AI 圈子最明显的变化不是又多了一两个“炸场”的演示视频而是大家讨论技术的方式换了套逻辑。以前开口就喜欢问“模型有多大、训练数据有多少”现在更多在问“它能不能在回答前多想一会儿、能不能自己调用工具、能不能同时看懂图听懂语音”。这种底层的讨论转向其实比任何一个单独的产品发布都值得复盘。有一位长期在开源社区做技术科普的工程师圈里人习惯喊他 K 君。他的年度复盘视频被转得很广核心观点是过去一年大模型的演进可以压缩成六个关键转折。我一边看一边对比自己过去一年实际跑过的几个项目发现每一条都能落到真实的技术选型和工程成本上不是那种“看着热闹、读完就忘”的观点。所以这篇就把六个转折拆开不讲虚的重点说清楚每个转折背后的原理、对工程的影响以及普通人能直接抄的落地思路。1. 从“堆参数闭卷考试”转向“允许模型现场多打草稿”1.1 预训练一家独大的时代开始松动过去很长一段时间提升模型能力最省事的方式就是“堆”堆更大的参数量、更多的训练数据、更长的训练步数。这种方法在早期非常有效因为模型规模和知识覆盖度之间存在清晰的强相关大家默认“大力出奇迹”就是唯一主线。但过去一年这套逻辑开始出现明显的边际递减。高质量文本数据就那么点模型把人类现有文本学完之后继续盲目增大规模收益已经撑不起翻倍的算力账单。业界开始认真追问既然预训练阶段已经把“闭卷知识”装进模型那能不能在“考试”的时候让它多花点时间思考这个思路的转变本质上就是把计算资源从训练阶段挪一部分到推理阶段。以前模型接到问题后必须一口气给出答案过程中不能停下来重新检查错了就只能错着。现在的做法是允许模型把思考过程显式写出来先生成多个候选答案再逐个自检甚至来回回溯几轮最后挑一个最有把握的结果。很像一个学生考试时允许在草稿纸上多试几种解法而不是交卷之后才后悔。1.2 思维链和“推理预算”为什么会奏效这条路线能跑通的底层原因是模型在训练时已经学习到了大量知识但单次推断时它只“激活”了其中很小一部分相关模式。如果给它机会把推理步骤摊开写下来它就能逐步检索知识、组织逻辑而不是在一句话里草率地完成所有判断。实际操作中最常见的做法是“思维链 自我一致性”让模型不直接输出最终答案而是先输出一步一步的推理过程如果预算允许同一个问题可以生成多条不同的推理路径再去比对结果一致性多数一致的答案往往更可靠。我去年在一组数学推理测试里做过对照同一个中小尺寸模型直接回答的正确率大约在六成出头而让它先生成三个候选方案、再选置信度最高的那个正确率能拉到七成五以上。代价也很直观推理时间大幅拉长消耗的 token 数量可能是原来的五到十倍。这就是“推理预算”的概念——模型在回答前愿意花多少资源去思考是需要人为设定的。1.3 工程侧真正要付的三笔账把推理时扩展落进真实系统比调 prompt 复杂得多。第一个要面对的是 KV Cache 暴涨。模型思考得越久缓存的历史状态就越多显存压力随之上升原来一台卡能服务的并发量会明显下降。第二个是动态批处理变得更难。普通请求响应很快思考型请求却迟迟不结束一个批次里如果混了两种类型要么慢请求拖垮快请求要么把快请求提前返回、损失吞吐。现在比较通用的做法是按任务复杂度做路由低风险问答走快速路径推理题和复杂任务才进入高预算通道。第三个是延迟评估方式变了。之前只要看首 token 速度和总延迟现在还得看“思考质量”生成的推理步骤有没有冗余、有没有绕进死胡同。建议在评估集里单独留一类“长推理样本”用最终答案正确率和平均思考长度两个指标一起卡别只看一头。2. 高质量文本数据撞上玻璃天花板合成数据从替补变主力2.1 真实文本数据为什么突然不够用大模型训练依赖海量文本但地球上有价值的文本是有限的。过去一年好几支团队在清洗数据时都发现公开互联网上可用的高质量文本已经被反复抓取过多轮新增样本里重复比例越来越高低质量垃圾内容反而越来越多。这不是说世界上没有新文章了而是说“能显著提升模型能力的前沿文本”增速跟不上算力扩张的需求。就像一家饭馆的食材供应链突然变慢后厨再大、炉子再多也炒不出更多好菜。数据这道坎单靠继续加大爬取力度已经过不去了。2.2 合成数据是怎么被一步步抬上主力的被逼到墙角之后行业开始认真把“模型生成的数据”当原材料。最早大家对合成数据很警惕担心模型自己教自己会越学越偏。但过去一年这套操作已经成熟了不少核心变成了“生成 强校验”。代码数据是最典型的成功案例。传统爬虫抓下来的代码质量参差不齐很多还缺上下文。合成管线的做法是先用种子题目让模型生成新的题目描述再让模型据此写代码然后用单元测试用例去跑跑得过的才进训练集。每一步都有客观验证模型就算想胡编也编不过测试用例。数学数据也类似先生成问题再生成逐步解答最后用规则验证器或确定性程序检查答案对不对而不是依赖人工去读推理过程。这比单纯拿模型对着屏幕“想象”出来的数据可靠得多因为它有一道外部关卡。蒸馏本质上也是合成数据的一种让大模型当老师把输出当作“标准答案”喂给小模型学。老师负责展示高水平解法学生负责把解法内化成自己的行为习惯。过去一年大量“小而强”模型背后几乎都离不开这条蒸馏产线。2.3 用合成数据时最容易踩的三个坑第一坑是多样性衰减。模型生成数据时会天然倾向于重复自己见过的分布如果合成数据占比过高训练集看起来很大实际有效信息量很小甚至会让模型逐渐失去罕见知识和多元化表达。避免方法是在合成数据里做采样去重并强制混入足够比例的真实数据。第二坑是验证器太弱。代码靠测试用例、数学靠规则校验这没问题但如果有人想用合成数据做“开放问答”或“文案生成”验证器往往只能看格式和长度这时候合成内容里的错误就会被原样学进模型。我的建议是只有在任务存在强客观校验时才大面积使用合成数据主观任务宁可少用。第三坑是忘记持续更新。合成数据管线如果长期不换种子问题、不换生成提示词产出的数据会越来越同质。最好每次训练前都让校验器重新筛选一遍并且定期加入新的真实样本。3. “大而全”让位给“小而强”MoE 和多任务蒸馏成为主流3.1 为什么小模型忽然能打以前大家默认“大模型就是比小模型好”这在早期确实成立。但过去一年很多团队发现把一个开源小模型拿到垂直场景里用高质量数据做深度微调之后它的表现经常能逼近甚至超过比自己大一个数量级的通用模型而推理成本可能只有后者的十分之一。原因并不玄学。通用大模型要兼顾全世界所有领域等于把知识摊得很薄垂直小模型则可以集中弹药在某个窄业务里反复训练把该领域的句式、规则、例外情况都吃透。如果把大模型比作一个见识广博的全科医生那垂直小模型更像是专攻某一科、但经验极其丰富的专科医生。日常问诊时后者在专科场景下往往更“对症”。3.2 MoE不算“小参数”但算力消耗真变小“小而强”还有另一条路就是用混合专家架构钻空子。MoE 模型的总参数量可以很大知识容量也很大但每次处理一个 token 时并不会激活所有参数而是通过门控网络挑出少数几个“专家”来干活。这样既保留了知识广度和参数量又大幅降低了单次推理的计算成本。真正让 MoE 变得流行的是它对部署更友好一个几十亿总参数的稠密模型可能要把所有参数都塞进显存才能跑而 MoE 模型可以通过专家并行把不同专家放到不同机器上按需调度。我用一个比较形象的类比稠密大模型就像一整支球队全员上场踢满九十分钟MoE 则是大名单里几十个人但每次进攻只换上去最适合当前战术的那几个。知识容量没缩水体力消耗却少了一大截。3.3 落地时到底怎么选这一年的经验让我逐渐总结出一套选型标准核心是看任务形状而不是看参数数字。整理成表格会更直观对比维度垂直小模型通用大模型MoE 模型知识广度窄而深广而泛广且深单次推理成本最低高中等延迟低高中低垂直任务精度很高中上高维护与调参简单复杂中等适合场景高频固定业务开放探索多样化复杂任务具体的做法是如果业务场景非常固定比如客服意图识别、合同关键信息抽取、代码补全直接选一个小模型加高质量数据性价比最高如果要做的是无人见过的新颖任务需要模型临场发挥那还是得靠大模型如果既要知识广度又要控制成本则考虑 MoE。我踩过的坑是“小模型贪多”。一开始我把十几个任务塞进一个小模型结果每个任务都学了个皮毛。后来拆成三个模型每个只做三四个强相关任务效果立刻上来了。小模型不怕窄怕的是又想小又想全。4. 聊天机器人的天花板到了Agent 化把“对话”升级成“办事”4.1 从一句接一句到真实调用工具过去一年最大的认知刷新之一是模型不再只负责“说话好听”而是开始负责“把事办成”。以前大模型最常用的形态是聊天框用户说一句模型回一句闭环到此结束。而 Agent 化的核心是让模型在对话过程中能够主动调用外部的搜索引擎、数据库、代码解释器、API甚至操作软件界面然后把工具返回的结果消化成长上下文继续推进下一步。实现这种能力的关键技术是结构化输出和函数调用。模型不再只输出自然语言还可以输出一个明确的“调用意图”比如“调用查询接口参数是订单号”系统收到这段结构后去真的执行再把结果塞回模型。这一步的难度在于模型需要学会“什么时候该说话、什么时候该动手”不能什么都靠嘴硬编。4.2 Agent 循环怎么设计才不会脱缰一个完整的 Agent 循环通常包含四步规划、行动、观察、再规划。模型先根据用户目标拆出任务列表然后选择一个动作执行动作后观察返回结果再决定下一步。听起来很顺滑真实跑起来到处都是问题。最常见的翻车点有两个。第一个是工具返回了异常数据模型却会“脑补”出一个合理结果交差。比如工具返回空列表模型直接说“查询完成数据为空”但它其实没有区分“真的没数据”和“接口报错了”。解决办法是让工具返回结构化状态码并且要求模型在观察阶段明确引用状态不允许跳过异常分支。第二个是无限循环。模型在某个决策点上反复尝试同一条路径浪费 token 和时间。工程上必须加最大迭代次数、单步超时、以及“循环检测”逻辑——如果模型连续两次做出相同决策且结果相同就直接中断并进入人工接管流程。在这类系统的落地顺序上我的经验是“先局部后全自动”。比如做一个内部报表 Agent最稳妥的拆分方式是用户意图解析用模型来做数据查询和图表渲染用确定性代码来做最后摘要生成再交给模型。模型只负责它擅长的短路径决策而不是把整个流程都撒手交给模型。等局部链路稳定了再逐步放开模型的自主范围。4.3 安全护栏不是附加项而是前置条件Agent 比聊天机器人危险得多因为模型有了真实的副作用能力。过去一年业界对“越权”这个词讨论特别多比如模型被 prompt 注入后去调用了不该调用的接口或者在被诱导的情况下执行了危险操作。防御手段不是让模型变聪明而是从架构上收权模型只允许通过白名单 API 执行动作权限最小化关键操作必须经过人工审批所有调用日志可回溯。另一个非常实用的手段是“沙箱”让 Agent 在隔离环境里执行代码确认行为正常后再把结果拷回生产环境。宁可让 Agent 慢一点也不能让它拿到它本不该有的权限。5. 多模态不再“外挂拼接”而是长在同一个模型里5.1 从拼乐高到整体铸造过去要做多模态应用最省事的办法是拼装一个文本模型负责理解文字一个视觉模型负责识别图像一个语音模型负责处理音频再用胶水代码把它们串起来。这种做法最大的问题是信息在模块间传递时会损耗模型没法真正理解“图像中的这块区域对应文本里的那个词”。过去一年的转折点在于主流架构开始转向统一的 Transformer 底座图像切块、音频片段、文本 token 都被转成同样的“模态标记”装进同一个模型里一起做注意力计算。相当于不再用几个各说各话的部门对接而是直接建了一个所有部门都能使用共同语言的总部。这个统一的底层收益非常大。模型可以从图片里看到证据再回来核对文本表述也可以把语音里的语气和文本里的情绪对齐。多模态从“能处理”变成了“能理解关联”这是一个本质差别。5.2 模型结构不难难的是数据配比我见过不少人第一次训练多模态模型时以为把图片和文本随便拼在一起就能成。真正跑起来才发现最难的不是网络结构而是数据的配比和顺序。如果文本数据占比过高模型会逐渐丢掉视觉细节的敏感度图像输入变成了可有可无的装饰反过来如果图像数据太多模型的语言能力又会退化连句子都说不顺。很多团队的做法是先用大量图文交错的长文档做预训练让模型习惯在文本和图像之间来回切换注意力再用短图文对做指令微调最后再用纯文本的高质量数据“拉”一下语言能力。评估也比以前麻烦得多。单纯看知识问答的分数不够还得看跨模态对齐能力比如“图像里的红色圆球是不是对应文字描述里的那个物体”“文中的时间点和视频里的画面是否匹配”。这类评估集目前还很稀缺需要自己造。5.3 应用侧的新机会和注意点多模态统一之后最直接的机会是那些需要“多感官协同”的场景把一段会议录音自动转成结构化纪要并配上关键截图把一张产品原型图直接转成可操作的前端页面描述把视频里的人物动作和字幕逐帧对齐。这些都是以前拼接式架构很难做好的事。但也要清醒多模态模型的幻觉问题比纯文本更隐蔽因为它会一本正经地描述一张根本不存在的图片细节。做生产系统时必须增加一道“可溯源校验”当模型声称看到某件事时系统要能把对应的原始图片区域或音频片段截出来供用户核验。否则一个错误的多模态描述会造成比纯文本幻觉严重得多的误导。6. 后训练从“讨好人类”变成“接受环境检验”强化学习找到新大陆6.1 RLHF 的瓶颈不是技术是“裁判”过去几年模型对齐主要靠 RLHF人类标注员对模型的多个回答打分训练一个奖励模型再用奖励模型去引导模型生成更“讨喜”的答案。这套流程在一段时间内非常有效但也暴露了天花板。人工标注太贵太慢而且审美和立场高度主观更麻烦的是奖励模型本身会被“骗”。模型很容易学会输出一些表面上符合奖励模型偏好、实际上质量很差的内容比如过度冗长、堆砌套话、迎合关键词。这就是业内常说的“奖励模型被 hack”。6.2 可验证奖励为什么能改变游戏规则过去一年最值得关注的转折之一是“可验证奖励”全面崛起。它的思路很简单不靠人类打分而是让模型去解决那些存在客观标准答案的任务然后用程序或规则直接判定对错。代码能不能跑通测试用例、数学题答案是否正确、棋局最终是否获胜这些都是确定性的机器自己就能当裁判。有了这种自动裁判模型就可以大规模试错。同一个问题模型生成十种不同解法测试用例直接筛掉八种错误的剩下两种正确解法再拿去做监督微调。反复跑上几千轮模型就渐渐学会了“先想清楚再写代码”“解数学题要逐步演算”这类内部策略。这也是过去一年推理能力明显提升的最核心推动力。更进阶的做法是过程奖励不只看最终答案对不对还对每一步中间步骤打分。比如一道数学题只要某一步明显推导错误就算最终答案碰巧对了这一步也要被扣分。这有点像老师在批改作业时不仅看结果还要看证明过程有没有逻辑漏洞。过程奖励能有效防止模型用“歪打正着”的方式混过最终检查。6.3 普通团队怎么接住这波红利可验证奖励并不是大团队专属武器普通开发者也完全可以先用起来。关键动作是先整理业务里“存在客观对错”的任务。比如代码缺陷检测可以定义一组已知缺陷样本模型修完之后跑单元测试跑过就算成功比如简历结构化抽取可以预先定义好字段边界用数据对比器自动比对结果哪怕是审核规则判断也可以把规则转成 if-else 检测器给模型输出自动打分。有了这些自动打分能力后你就能用它来筛选训练数据而不是靠人工一条条看。我自己的做法是先构造一个几百条的“可验证测试集”让当前模型在测试集上跑分再用跑分结果筛选候选训练样本微调后又回到测试集上复跑。这个闭环跑通之后模型质量的迭代速度比之前人工标注快了不止一倍。需要特别提醒的是可验证奖励不能完全替代人类偏好。业务里还有大量没有标准答案的软性要求比如文案的语气、回复的亲和力、风格的统一性。最佳实践是把两类目标分开客观部分用环境验证主观部分保留少量 RLHF两边叠加而不是互相替代。我自己消化这六个转折的方式读 K 君的复盘最触动我的不是某条新技术的出现而是整个行业的重心从“花更多钱预训练”转向了“花更少钱推理 更聪明地后训练”。对普通团队来说这其实是个好消息以前做大模型应用决定权基本握在几个巨头手里现在出现了推理预算、合成数据、小模型蒸馏、可验证奖励这些新变量个人开发者和小团队也能在某个垂直切面上做出真正好用的东西。我自己过去一年实际动过的刀子包括把线上一个高频分类任务换成了蒸馏小模型推理成本降了接近八成准确率还涨了三个点给内部问答系统加了“快速回答 / 深度思考”双通道用户体验变好的同时算力账单也没爆最值得的投入是搭了一套代码任务的可验证奖励评估管道现在每次微调前都能先跑一遍自动打分再决定值不值得放上线。如果让我从这六条里选一条给刚入坑的团队我会说先不要六个全追。挑一个和你当前业务最相关的切入口比如数据稀缺就研究合成数据客服自动化就研究 Agent 化推理成本高就研究小模型蒸馏先把一条链路跑出确定性收益再慢慢铺开。毕竟这些转折背后都不是单一技巧而是一整套工程体系的重新组织需要时间一点点磨。