AI4AI 在测试时：通过辅助框架实现强到弱能力迁移

TL;DR 强模型在测试时为弱模型构建推理脚手架（路由 + 确定性代码），无需微调即可将 Theory-of-Mind 基准平均得分从 0.49 提升至 0.91，证明能力转移可在推理时发生。

问题

问题背景

当前 AI 能力迁移研究聚焦于蒸馏（distillation），通过训练小模型复现大模型行为。业界期望低成本、低延迟部署小模型，同时保持较高任务精度。

现有方法局限

主流方法如教师强制（teacher forcing）、在策略蒸馏（on-policy distillation）都需要更新目标模型参数，存在明显不足：

• 训练成本高：需要额外数据、GPU 时和调参，难以快速适配新任务。
• 部署不灵活：一旦环境变化或任务微调，模型需重新训练或增量更新，无法即时应对。
• 忽略认知负荷：现有蒸馏关注提升模型内部能力，却较少优化任务呈现方式；小模型失败可能因任务表述带来的过量认知负荷，而不仅是能力不足。

为什么这个问题难/重要

测试时能力迁移（strong-to-weak scaffolding）允许强模型在推理阶段为弱模型构建 harness（脚手架），无需更新参数。技术难点在于：

• 需要将不稳定模型推理离线转换为确定性代码、基准特定路由和严格答案格式强制，避免弱模型崩溃。
• 强模型本身要在 5% 验证集上迭代优化脚手架，平衡探索与稳定性；研究发现推理努力单调提升 harness 质量，弱目标模型收益最大，但平台效应相对有限。
• 这为边缘部署、多任务路由系统提供了新思路，业界关注度高，可能成为训练时蒸馏的重要补充。

行业类比

就像为普通开发者提供低代码预配置流水线，让能力较弱的模型直接调用强模型设计好的推理脚手架，降低上手门槛。

核心洞察

• 强模型可在测试时通过构建 harness 向弱模型传递能力，无需更新弱模型参数。该视角与训练时蒸馏（如数据蒸馏、on-policy distillation）形成互补：传统方法修改弱模型本身，而 harness 通过外部路由、模板和验证来降低任务认知负荷。独特之处在于把能力传递从“让模型更强”切换到“让任务更易”，开辟了不依赖梯度更新的能力迁移路径，对推理系统设计有直接工程价值。
• 性能提升主要来自将不稳定推理卸载到确定性代码、基准特定路由和严格答案格式约束，而非增加推理步数或采样多样性。这挑战了当前“推理时扩展”的主流假设，表明对弱模型而言，结构化程序化约束比扩大推理预算更有效。工程启示：在构建 agentic 系统时，应优先设计确定性校验器和任务路由器，而非盲目依赖模型自身更长思考。

方法

输入与任务设定

• 强 builder model 与 弱 target model 配对，数据集划分 5% 验证集、95% 测试集。
• builder model 的目标是设计 inference-time harness，不更新 target model 参数。

关键模块

1. Harness 生成：builder model 输出 harness 配置，包含：
   • 路由逻辑 (routing logic)：根据输入特征分派不同处理路径。
   • 确定性求解器 (deterministic solvers)：将不稳定推理步骤替换为代码。
   • 答案格式强制 (answer-format enforcement)：约束输出格式，减少解析错误。
   • 少样本示例 (few-shot exemplars) 与 prompt 模板。
2. 迭代优化循环：在验证集上运行 harness+target model，收集错误；builder model 分析错误模式并修改 harness（如更新路由、增加确定性组件、调整 prompt），重复多轮至稳定。
3. 推理时部署：固化 harness，按顺序执行预处理（路由、格式检查、确定性计算）→ 调用 target model 生成剩余推理 → 格式强制输出最终答案。

输出

• 最终 harness 配置以及 target model 在测试集上的准确率（如平均从 0.49 提升到 0.91）。

差异点：与训练时蒸馏改变 target model 参数不同，该方法完全通过操纵推理时的任务表示与计算流程实现能力迁移，无任何参数更新。

实验

实验设计

本研究在四个 Theory-of-Mind 基准 上评估强到弱 scaffolding：每个 builder model 使用 5% 数据作为 validation set，通过多轮迭代 refine 其构建的 harness（包括路由逻辑、提示模板、确定性求解器、few-shot 示例等），最终在完整测试集上评估 harness 对 weak target model 的增益。这种设计分离了 builder 的构建能力与 target 的执行能力，且 target 参数保持不变。

关键发现

主结果显示，test-time harness 几乎将 平均 target-model 性能 从 0.49 提升至 0.91（↑0.42, 约 86% 相对提升）。消融分析表明，增益主要来自三个方面：

• 将不稳定的模型推理卸载到确定性代码；
• benchmark-specific routing；
• 严格的 answer-format enforcement。 单纯鼓励 target model 更多推理或更广采样并无显著收益。此外，builder 的 reasoning effort 与 harness 质量单调相关；构建平台影响适中；更弱 target model 获得最大增益。

与基线/同类工作的对比

相对于常规 training-time distillation（需更新参数），本方法在 test-time 通过外部 harness 实现能力转移，无任何参数更新，部署更轻量。与其基线（无 harness 的 target model）相比，性能接近翻倍，验证了认知负载降低的价值。该工作将“让模型更强”与“让任务更容易”两条路线解耦，为推理时 scaffold 设计提供了新的实证支撑，但未与 SOTA 蒸馏方法直接对比，且结果限于 ToM 类任务。

行业影响

落地场景

推理时 harness 适用于对延迟、成本敏感且模型能力有限的场景。例如：在线客服机器人、内容审核、实时翻译、边缘设备助手等。这些场景通常部署小模型以降低推理成本，但小模型在复杂任务（如多步推理、严格格式输出）上容易出错。通过 harness 将不稳定推理卸载到确定性代码，可大幅提升可靠性。

商业价值

一方面，无需更新弱模型参数即可提升其性能，省去大量微调数据和算力成本；另一方面，准确率提升减少人工审核和纠错成本，并改善用户体验。例如，在客服场景中，回答格式错误会导致用户困惑或系统解析失败，harness 强制格式可避免此类损失。此外，harness 可快速迭代，降低模型更新周期带来的风险。

跟现有产品 / 工作流的接口

harness 可作为推理服务的前置层，与现有模型服务网关集成。强模型在离线阶段构建 harness（包括路由规则、验证器、提示模板），将配置缓存后，线上请求先经过 harness 处理再交给弱模型，输出经过验证和格式化。该模式与 RAG、工具调用等现有技术兼容，可通过 API 调用强模型生成 harness，实现自动化。

具体落地 use case：

• 电商平台售后客服：使用 7B 级小模型处理用户咨询，强模型构建 harness 将订单查询、退款政策等不同意图路由到专用模板和 API 调用，并用正则验证输出（如订单号格式），将错误率降低，减少人工坐席介入。
• 内容平台评论审核：小模型判断违规类型，harness 强制输出预定义标签并给出置信度阈值，低于阈值自动转人工。

局限

• - 论文仅在四个 Theory-of-Mind 基准上验证，任务类型单一，且均为需要结构化推理的问答/分类任务，未覆盖开放域生成、多步工具调用等场景，泛化性存疑。此外，harness 构建需要 5% 的验证数据用于迭代 refine，如果目标任务标注稀缺，该方法可能失效。未来需测试更广泛的任务分布和少样本/零样本条件下的使用。
• - harness 设计高度依赖 builder 模型对任务的理解和推理能力，如果 builder 本身能力不足或存在认知偏差，可能生成次优的 routing 逻辑或错误地 offload 关键推理步骤，反而损害 target 模型性能。论文虽发现 builder reasoning effort 与 harness 质量正相关，但未探索 builder 能力下限或不同 builder 架构的影响。
• - 与训练时蒸馏相比，测试时 harness 不改变 target 模型内部表征，因此无法弥补 target 模型在基础能力上的根本缺陷（如知识缺失、推理深度不足）。当任务要求模型自身具备领域知识或复杂推理时，仅靠外部脚手架可能触及天花板。论文没有与训练时蒸馏进行直接的公平对比，也未量化 harness 叠加训练时蒸馏的联合收益。