★ FEATURED ARTICLE 大语言模型上线之后最让人头疼的事,不是推理延迟,也不是并发扛不住,而是效果衰减。模型刚训练完的时候表现惊艳,跑两三个月就肉眼可见地变笨,用户开始反馈答非所问老一套话术同一个问题换个问法就翻车。你翻看日志,发现大量长尾错误根本不在训练集覆盖范围内,想靠人工标注去补,标了几万条也补不齐。市面上大多数团队的做法是定期攒数据、重新SFT、重新对齐,周而复始,每轮成本高且周期长,而模型在下一次更新之前,始终在用一套过期的策略应对一个不断变化的世界。这篇文章想聊的,是我在团队内部立项大语言模型在线自改进闭环(对抗评估在线DPO)的完整思考和执行提案。核心思路不是再训一版更大的,而是让模型边用边学,通过一套对抗评估机制持续发现自身弱点,再利用在线DPO(Online Direct Preference Optimization)把发现的问题转成训练信号,形成一个评估-挖掘-训练-上线的自动回路。对做LLM应用落地、做模型调优、以及负责算法团队资源规划的朋友,都有直接参考价值。1. 为什么静态对齐注定不够:在线自改进闭环的立项缘起1.1 静态对齐的三个天花板传统的开源大模型微调链路,大致是SFT加RLHF或DPO,整个流程依赖一个前提:标注数据是完整的、分布是稳定的、未来的输入跟训练集来自同一个世界。可大模型上线之后,这三个前提全不成立。第一是数据时效性。今天用户问今年最新的政策变动,训练语料里根本没有,模型只能根据旧知识生成一个看起来合理但错了的答案。这类错误不是模型能力不够,是它的知识快照过期了。第二是分布漂移。上线初期的query集中在基础知识问答,随着产品推广,用户开始问行业术语、复杂推理、多轮对话中的上下文依赖问题,输入的分布慢慢偏移到训练时覆盖不足的区域。第三是长尾错误。哪怕准确率到了98%,剩余2%的长尾case分布在各种意想不到的角度,靠人工找根本找不完,而恰好是这2%决定了用户对模型傻不傻的感知。这三个天花板,本质上是同一个问题:训练时用的静态数据集,无法与线上的动态分布保持同步。1.2 在线自改进闭环要解决的四个具体问题立项之前,我先把诉求收敛成四个可执行的问题,避免方案做大做空:如何持续发现当前模型最不擅长、最影响体验的输入场景?如何把发现的问题转成明确的改进信号,而不是靠感觉补数据?如何在不大规模人工标注的前提下,批量产出高质量的偏好样本?如何控制迭代风险,让模型每轮更新只变好、不变坏?这四个问题分别对应闭环里的四个环节:对抗评估(发现问题)、偏好构建(生成信号)、在线DPO(训练更新)、回归防退化(控制风险)。整个循环以周为粒度运转,每轮产出一个新的模型候选版本,经评估和回归后决定是否上线。2. 对抗评估层设计:怎么让模型自己找到自己的软肋2.1 从人工抽检升级到对抗生成-自动判分两段式很多团队做模型评估,还是拉一批测试集,算一下pass率。这个做法在摸清模型基准能力时有用,但用来驱动自改进远远不够,因为静态测试集的覆盖是有限的,模型翻车的角度总是超出测试集的想象。我们的对抗评估层采用两段式架构。第一段叫对抗生成。每次评估时,从一个基础问题库出发,让两个角色协同作业:一个角色是攻击者,负责改写问题,包括换场景、加条件、改语气、增加干扰项、追问前置细节;另一个角色是被测者,也就是当前待评估的模型版本。攻击者会在一次会话里连续追问,观察模型在哪些转折点上开始胡言乱语、在哪类限定条件下开始含糊其辞。这些让模型难受的路径,比单纯测几百道固定题能挖出更多真实弱点。第二段叫自动判分。每一条对抗路径的结果不能只靠人工看,要接入一个判分器(即reward model或者一个强推理LLM)。判分器按四维打分:正确性(事实是否有误)、完整性(该答的点是否都覆盖)、逻辑一致性(前后是否有矛盾)、指令遵循度(是否遵守了约束条件)。判分结果不只有一个总分,还要求给出具体的扣分理由。这个设计的核心理念是:对抗生成负责扩大搜索空间,自动判分负责把搜索到的失败case变成结构化信号,两者配合,评估就不再是抽样,而是围绕当前模型弱点进行的主动探测。2.2 判分器本身的标定与自我优化判分器质量是整套闭环的地基,但也是最容易被忽略的一环。一旦判分器对某些错误视而不见,模型就会反复强化错误答案,收敛到错误的方向。我们的做法分三步。第一步,用一份人工标注的mini集做标定。挑200条历史对抗样本,由两个标注员独立按四维标准打分,不一致的地方讨论合并成gold标准。然后让判分器在这200条上跑一遍,算和gold的吻合率,目标定在90%以上,不够就调prompt或者换更强的判分基座。第二步,加入双向判分。如果判分器判A答案对、B答案错,而另一路判分器判正好相反,这条pair直接标记为conflict,不进训练集,而是回流到人工review池,由人来终审。这样能在早期拦住判分器的不稳定区间。第三步,定期对判分器本身做对抗攻击。就是用已经发现的高难度问题去压判分器,看它的打分逻辑是否经过推理还是仅看表面措辞。比如同一个错误答案换个权威口吻,如果分数明显变高,说明判分器被自信语气骗了,需要重新标定。2.3 对抗评估集的分层与冷启动纯靠模型主动生成对抗样本,一开始会发散,无法聚焦到业务重点。我的建议是评估集分三层:核心层:约500条和业务强相关的必测题,每条都有对应的gold答案,用于衡量每轮迭代是否保持基本能力。探索层:约2000条由对抗生成机制持续产出的难题,覆盖长尾场景,用于发现新的弱点。压力层:约300条多轮对话、超长上下文、强约束条件下的极限测试,用于探测模型在极端输入下的退化。冷启动时,核心层靠人工整理,探索层用通用题库加LLM改写撑起来,压力层直接借用线上日志中用户真实的长对话记录(脱敏后)重放生成。等到闭环跑起来,探索层和压力层会随每轮对抗结果自动更新,整个评估集变成一个活的动态资产。3. 在线DPO:从偏好数据收集到策略更新的完整链路3.1 DPO原理回顾:为什么在线版本可行DPO的核心思想是绕过强化学习中复杂的reward建模和PPO采样,直接用偏好对(chosen/rejected)来优化策略模型。标准DPO的损失函数是:L_DPO -log σ(β * (log(π_θ(y_w|x) / π_ref(y_w|x)) - log(π_θ(y_l|x) / π_ref(y_l|x))))其中π_θ是当前策略模型,π_ref是训练开始时的参考模型(通常就是SFT版本),y_w是chosen答案,y_l是rejected答案,β控制对参考模型的偏离程度。直观理解是:让模型在保持与参考模型不过度偏离的前提下,尽量提升chosen相对于rejected的概率。离线DPO的痛点在于偏好数据是过去时:标注好一对数据,模型才去学,等学完,线上的问题分布可能又变了。在线DPO的思路是让模型自己去生成候选答案,用实时评估结果动态构造偏好对,再立刻做策略更新,形成一个回合制的自我博弈。算力允许的情况下,这个循环可以做得很快,小时级到一个晚上就能完成一轮。3.2 在线偏好对构建的三种策略在线DPO的关键问题不是损失函数怎么改,而是偏好对怎么实时、可靠地产生。我设计了三种策略,按优先级组合使用。**策略一:模型自博弈对比采样。**给定一个query,让当前模型采样两次或三次(调高temperature),再让判分器给多个采样结果打分,取最高分和最低分构成chosen和rejected。这个做法的前提是温度调高后,模型能产出有区分度的候选,对大多数生成模型是成立的。好处是成本低,不需要外部模型配合,劣势是模型自己受限的地方,采样多样性也会受限。**策略二:强弱模型交叉对比。**同一个query,当前模型生成一份答案,另一个更强或者风格不同的模型生成一份答案,判分器对比打分,分出胜负构成偏好对。这里的强模型可以是一个更大参数量的模型,也可以是经过更多轮历史迭代的模型版本。这条路径能把模型跳一跳够得着的好答案示范出来,引导当前模型往上靠。**策略三:线上真实反馈挖掘。**已经上线的对话日志里,用户对答案的隐式反馈(复制、点赞、追问、离开对话、明确点踩)可以转化成弱信号弱标签。对用户明确点踩或直接结束会话的回合,做一次自动重放,生成新的回复,如果新回复判分显著高于之前被吐槽的旧回复,就把新回复/旧回复构造成一对偏好样本。这招能让训练信号紧贴真实用户场景,价值比人为构造的case高很多。3.3 在线DPO训练中的参数与稳定性细节有三件事特别影响在线DPO的稳定性,值得单独说。第一是参考模型的冻结问题。标准DPO要求π_ref从头到尾不变,否则损失函数中的log-ratio失去锚点。在线DPO最容易踩的坑是:有人直接把上一轮的模型当本轮参考模型,结果参考模型和策略模型互相追逐,训练完全发散。我的做法是固定最初的SFT版本做参考模型,除非业务方向有重大改变,否则不换。第二是β值的调节。β太小时模型会严重偏离参考模型,容易出现迷失方向式的崩坏;β太大时模型几乎不学新东西,闭环等于没跑。按我们的实验经验,β初始值设在0.1到0.3之间,观察chosen和rejected的平均log概率差,如果差值收敛得太快(模型很快就完全倾向chosen),说明β过大;如果跑了若干step差值纹丝不动,说明β过小。第三是批次内去重与多样性控制。在线生成的偏好对天然有重复性,同一类问题反复出现会让模型过拟合到高频样例。我会在构造训练batch时做一次embedding相似度去重,保证同一batch里的query尽量分散,同时把探索层评估集里的高难度case按一定比例(约15%)混合进训练集,防止模型只顾着学简单偏好评测而丢掉复杂推理能力。下面是我们在实验环境中用过的一组关键超参,可以作为起步模板:参数取值备注训练步数200-400在线场景不追求大epoch,防止过拟合batch size32-64偏好对去重后计算学习率5e-7 到 2e-6比普通SFT低一个量级,强调稳定β0.1-0.3若chosen/rejected差值收敛过快则调大采样temperature0.8-1.2用于自博弈采样多样性每轮偏好对数量2000-5000太少学不到,太多难以消化3.4 参考模型与悔棋机制:防退化的一种兜底方案在线自改进有个天然风险:模型可能在一个小范围评估集上变好,却在更广的能力面上变差。必须设计防退化机制。我的做法是在每轮DPO训练完成后,先不直接更新线上版本,而是跑一个回归门禁。门禁要过的关卡包括:核心层500条黄金用例的通过率不低于上一版本、上一轮修复的定向case(写进一个fixed-case清单里)不能回退、压力层测试的极端输入不能出现明显劣化。如果三项都过,才允许发布候选版本;任何一项不过,就把本轮训练数据整体废弃,回滚到上一版本,并且在下一轮的对抗评估中重点补充导致退化的相关case。这套悔棋机制听起来保守,但它保证了闭环是单调改进的,而不是整体指标微涨、关键能力崩盘的假改进。4. 闭环工程架构与数据回流:让每一轮评估都变成训练信号4.1 四个模块的数据流转图(无图,文字描述)整个闭环由四个模块组成,数据流动的方向是单向且闭环的:采集层:上线模型实时接入对话日志,完成数据脱敏、session切分和难度筛选,输出待评估样本池。评估层:接收两类输入,一类是采集层的线上样本,另一类是探索层的历史case,统一经过对抗生成、三路判分,输出结构化评估报告和带分数的偏好候选。训练层:把评估层产出的候选pair按三策略合并、去重,构造偏好数据集,执行在线DPO训练,产出新模型权重。发布层:对候选权重跑回归门禁,通过后灰度上线,再把灰度期的效果指标反馈给采集层,形成下一轮循环的输入。4.2 数据质量清洗与去重管线的落地细节在线生成的训练数据是脏的,不能直接丢给训练器。清洗要过四关:格式清洗:判断生成文本是否空、是否截断、是否包含大量重复n-gram,不合格的pair直接丢弃。脱敏校验:凡是包含手机号、邮箱、身份证模式串的响应,整条去掉,防止用户隐私进入训练。判分一致性校验:三路判分器如果对某一对答案的胜负判断不一致(即出现conflict),这pair进不去训练集,除非有人工确认。难度过滤:判分器给两个答案打的分都很高(比如都在9分以上),说明这对样本区分度弱,对DPO训练帮助小,按阈值过滤掉,保留那些有明显好坏之分的样本,训练信号更强。这些细节属于那种不做也不会立刻报错、但做了效果差很多的工程隐性成本,建议在方案阶段就考虑进去。4.3 每轮迭代的KPI口径与观测方式闭环没有KPI就是白跑。我定义的迭代核心指标分两层:能力提升指标:探索层评估集通过率(每轮绝对提升目标1到3个百分点)、核心层通过率(不低于上轮)、fixed-case回退率(必须为0)。闭环效率指标:单轮耗时(从采集到发布不超过5个工作日)、有效样本占比(清洗后真正进入训练的pair占评估产出pair的比例,目标不低于40%)、训练成本(单轮GPU费用上限)。这些指标固定在每轮迭代结束后出一份简报,重点是看趋势而不是单轮数字。如果连续两轮探索层通过率不再上升,说明评估层的对抗生成缺少新意,需要去更新攻击策略,而不只是压缩训练参数。5. 立项可行性分析:算力、周期、风险与阶段拆分5.1 算力需求与成本测算先给结论:一个每天百万级调用量的业务场景,跑通整套在线自改进闭环,不需要想象中那么夸张的算力。拆开看:对抗评估层:每天评估3000到5000条query,每条query经过多轮攻击和判分,折算成token消耗,单日大约500万到1000万token的推理量。这部分用本地部署的推理服务跑,一张A100或两张L40S级别的卡就可以覆盖。在线DPO训练层:每轮2000到5000个偏好对,序列长度按2000 token算,单轮训练用8张A100(80G)跑半小时到一小时即可完成,折合单轮成本不高。这是在线DPO相比在线PPO最明显的优势,PPO那套需要同时维护actor、critic、reward model多次前向和反向,算力消耗通常要翻3到5倍。判分器和辅助模型:单独部署一个判分服务,和主模型共用推理集群,做一些资源错峰调度即可。如果业务量小,甚至可以用单机多卡方案跑完所有环节,只是节奏慢一些。所以立项的算力门槛并不高,真正的成本在于人力投入和工程联调。5.2 建议的四个执行阶段项目的推进节奏,我建议切成四个阶段,每阶段目标明确、可独立验收。**阶段一:离线底座建设(第1到3周)。**完成对抗评估集初版构建、判分器标定、数据清洗和去重管线开发。这个阶段不碰训练,只把评估层做扎实。验收标准是把评估集通过率作为模型能力基线,人工抽检判分准确率达到90%。**阶段二:离线DPO复现(第4到6周)。**用已有的人工标注偏好数据和模型自博弈离线生成的偏好对,把DPO训练链路完整跑通,复现标准DPO论文中的效果,确认loss下降、生成质量提升、不会崩坏。验收标准是固定测试集上相对SFT基线的胜率提升超过5个百分点。**阶段三:在线闭环联调(第7到10周)。**把评估层、偏好构建层、训练层、发布层串起来,先用小流量灰度模型跑两轮完整循环,重点观察数据回流的稳定性和回归门禁能不能拦住退化。验收标准是连续两轮迭代核心层通过率不跌、探索层通过率提升。**阶段四:常态化运转与自动触发(第11到14周)。**把人工介入降到最低,只保留异常熔断和监督抽检。设定自动触发条件(比如探索层通过率连续三天低于阈值,或者线上负反馈率上升),让闭环自主决定何时开启新一轮迭代。5.3 风险清单与应对策略我把这个项目的主要风险分成四类,并且给出对应的预案。判分器偏见风险:判分器本身有偏好,可能错杀好答案、放过坏答案。应对是双向判分加conflict人工仲裁,以及定期对判分器做对抗标定。自博弈收敛风险:模型反复与自己生成的答案对比,可能收敛到一个平庸但稳定的状态。应对策略是强制混入强弱模型对比样本,以及外部队列提供多样化的query来源。在线训练稳定性风险:数据质量波动、训练过程发散。对应策略是参考模型冻结、学习率压低、回归门禁部署兜底。业务能力偏移风险:闭环聚焦评估集优化,导致非评估范围的能力下降。应对是核心层测试集随业务变化动态更新,且固定case清单持续追加历史翻车样本。5.4 复盘:这套闭环的适用边界最后说点实在的。在线自改进闭环不是银弹,它最适合的场景是:模型已有的能力基础不错,但持续面临新分布、新场景,且可以拿到持续的用户反馈日志。如果模型本身的基座能力很弱,连基础推理都做不好,那么优先做的应该是SFT和更大规模的数据建设,而不是上在线DPO——在线反馈只会强化一个笨模型,让它更擅长用一种笨但一致的方式回答。另外,如果你的业务数据量级太小(每天调用量在万次以内),闭环的样本产出会不足,训练信号稀疏,这时候性价比不如直接人工标注定向优化。我们的经验是每天有效对话量至少要到十万级,闭环才有足够的原料和涨点空间。我个人的体会是:对抗评估加在线DPO这套东西,真正难的从来不是某个模型训练技巧,而是工程体系怎么把及时发现弱点和快速吸收教训串成一个不停转的飞轮。把这个飞轮转起来,模型就不再是一件交付完就折旧的固定资产,而是一个持续进化、持续贴近业务的服务。最后建议团队在立项时就把评估集和回归门禁定义为第一优先级的资产来建设,这一层做得有多扎实,闭环的长期天花板就有多高。
阅读完成 · 觉得有帮助？
