AI4AI测试时能力迁移：用Harness实现强模型到弱模型的知识传递

AI4AI 这个概念描述的是“用 AI 系统去帮助另一个 AI 系统完成任务”。Test-Time 指帮助发生在推理阶段而不是训练阶段。Strong-to-Weak Capability Transfer via Harnesses 进一步限定了迁移方向和关键载体通过 harness外围引导装置把能力从更强模型传递给更弱模型全程不修改弱模型权重。实际项目中经常出现这样的局面业务需要部署一个参数量较小、延迟可控的模型到私有环境或边缘设备但小模型单独回答时质量不稳定。训练阶段调优依赖数据、算力、评测周期短期内很难完成。这时候“测试时帮助”就有明显价值原模型保持不动推理时由 harness 调度强模型做问题改写、答案评判、修订指导。弱模型仍然负责生成但系统整体输出的质量上限被抬高了。下面从问题背景开始讲清楚 Strong-to-Weak 机制为什么成立再给出一套最小可复现的 harness 流水线最后说明如何验证、排查、在生产环境落地。适合三类读者正在做 LLM 应用工程化的开发、研究模型对齐或测试时计算的研究生、以及想在冻结模型权重的前提下提升推理质量的架构师。1. 为什么需要测试时能力迁移而不是继续训练模型1.1 训练时迁移的三条主流路线和各自的瓶颈先看传统做法。要让一个弱模型获得更强能力最常见的是三条路线微调、知识蒸馏、偏好对齐。迁移方式需要什么主要成本部署影响主要风险指令微调 / 全参微调高质量标注数据、训练算力高替换模型权重灾难性遗忘、数据泄露知识蒸馏teacher 模型输出或 logits中替换模型权重蒸馏损失、长尾能力失真RLHF / DPO偏好对、奖励信号高替换模型权重奖励过拟合、训练不稳定这三条路线有一个共同前提你可以修改模型参数。当业务环境不允许修改参数或者改完参数后无法快速验证这个前提就不成立。三个典型场景模型已经部署到离线的边缘设备OTA 更新成本高。团队没有足够的标注数据微调容易过拟合。上游模型版本更新频繁微调成果很快失效。在这些场景下能力迁移不能发生在训练阶段只能发生在推理阶段。这就是 AI4AI at Test-Time 要解决的问题。1.2 测试时迁移把能力放在模型外部测试时迁移的核心变化是“能力载体”变了。微调把能力写进权重测试时迁移把能力写在 harness 里。harness 是一套预设的推理控制逻辑它把一次问答从“单次调用”扩展成“多次调用的循环”输入先被改写或拆分。弱模型生成多个候选答案。强模型对候选答案打分、给批评意见。弱模型根据批评意见修订。系统选择分数最高的输出。这种设计的优点是迭代速度快。改 harness 只需要改提示词和控制流不重新训练几分钟就能验证一组新配置。缺点是每次回答的调用次数变多延迟和成本上升而且生成质量仍然受弱模型本身能力上限约束。它不是万能药而是参数冻结条件下的增量方案。1.3 Harness 与模型的关系一类外部控制回路把 harness 理解成传统软件开发的测试装置更准确。软件测试里test harness 负责驱动被测对象、注入输入、检查输出、报告结果。这里的 harness 也是类似角色驱动向弱模型发送改写后的指令。检查把输出交给强模型评分。修正根据评分和批评触发新一轮生成。因此 harness 不是一个新模型而是一段可编程的中间层。它决定了两个模型以什么顺序、什么频率、在什么条件下交互。研究标题里使用复数 Harnesses也是在强调不同的任务、不同的强弱模型组合需要装配不同形态的 harness而不是一套配置走天下。2. Strong-to-Weak 能力迁移为什么能生效为了让“强模型帮弱模型”在测试时真正成立先要理解两个基础判断强模型可以当裁判弱模型在条件改善后可以生成更好结果。这两点需要分别验证。2.1 先区分 Weak-to-Strong 和 Strong-to-Weak这两个方向很容易混淆。Weak-to-Strong用较弱的模型去监督、解释较强的模型。研究动机是未来如果出现超级智能模型人类自己可能无法高质量监督它于是先验证弱模型能否激发强模型的能力。Strong-to-Weak用较强的模型去指导、评判较弱的模型。目标是把强模型对问题的判断能力转移给弱模型让弱模型在部署时不至于表现太差。两者共享一个假设目标模型内部已经存在或可以被引导出某种能力外部监督只是“激活”和“校准”它而不是从零灌输。对测试时 harness 来说这个假设意味着弱模型当前回答不好不等于它完全没有能力很多时候问题出在输入表达、搜索空间不够、缺少有效反馈这些恰好是 harness 可以干预的。2.2 测试时激活能力的三条途径第一输入重构。弱模型对复杂、歧义、嵌套的问题很容易答偏。harness 可以先用强模型把原始问题改写得更清楚或者把大问题拆成多个小问题逐级回答。这个操作不改变弱模型但改变了它看到的内容。工程上需要注意控制改写程度防止强模型在改写时丢掉原始问题里的关键约束导致弱模型答非所问。第二扩大搜索并选择。弱模型单次采样可能随机失败但如果温度调高、采样多次候选答案中通常会出现质量更好的结果。harness 让弱模型生成 N 个候选再用强模型裁判挑选最佳答案。实际项目中这一步往往带来最明显的提升因为它把“生成器不强”的问题转成“裁判足够强”的问题而后者更好解决。第三批评与修订。弱模型生成初版后强模型先指出具体错误并给出修改建议弱模型带着这些建议再生成一版。这个过程可以重复若干轮。注意这里不是让弱模型自我反思。弱模型自己批评自己经常受限于同样的盲区强模型作为外部裁判才能提供弱模型原本看不到的反馈。2.3 关键分工生成交给弱模型裁决交给强模型测试时 harness 有效的前提是分工清楚。强模型不直接替代弱模型生成最终答案因为如果强模型完整生成答案就不是“能力迁移”而是“模型替换”。实际落地时替换模型往往受部署体积、延迟、成本或数据隐私限制并不允许。更合理的分工是弱模型负责生成候选和修订稿强模型负责判断哪一条更好、哪里需要改。评判任务比生成任务容易强模型不需要写出符合弱模型风格约束的完整答案只需要识别错误、比较优劣、输出修改意见。这样一来部署链路上真正消费的仍然是弱模型强模型只是推理阶段的外部资源。这套分工也解释了为什么