Model Merging & Distillation: 解释合并方法的评估与风险。

Core Concept: 需在多任务上分别评估（防'此消彼长'）、验证无能力退化、注意基座一致性与版本管理。

数学机理：<strong>评估要点</strong>——(1) <strong>逐任务评估</strong>——不能只看'平均分'（因为合并可能'此消彼长'：任务 A 提升 10 分、任务 B 下降 15 分，平均分仍可能'看起来正常'）；故必须<strong>逐任务报告</strong>，并检查是否有任务<strong>显著退化</strong>。(2) <strong>通用能力回归</strong>——合并可能损害<strong>基座模型的原能力</strong>（尤其当任务向量与基座能力冲突时）；故需在<strong>通用基准</strong>（MMLU、常识、语言流畅性）上验证。(3) <strong>鲁棒性评估</strong>——合并后的模型在<strong>分布外/对抗输入</strong>上是否稳定（合并可能使模型'脆弱'）。(4) <strong>校准与不确定性</strong>——合并可能影响模型的校准（置信度）；需评估。(5) <strong>效率指标</strong>——合并后是否真的'零额外开销'（如合并多个 LoRA 可能引入数值差异）；以及是否可量化。(6) <strong>对比基线</strong>——需与 (a) 各单任务模型、(b) 多任务联合训练、(c) 集成 对比，才能判断合并是否'划算'。<strong>风险</strong>——(1) <strong>干扰（interference）</strong>——任务向量冲突导致某些任务退化；缓解：TIES/DARE、调 λ、减少合并的任务数。(2) <strong>基座不一致</strong>——不同基座（或不同版本的基座）的任务向量不能合并（'方向'无意义）；故需<strong>严格记录基座版本</strong>。(3) <strong>版本管理混乱</strong>——N 个适配器 × M 个基座版本 = N×M 个组合；需清晰的命名与元数据（基座版本、任务、λ、训练配置）。(4) <strong>评估集泄漏</strong>——若合并时用评估集调 λ，会高估（需用留出集）。(5) <strong>数值精度</strong>——合并（尤其多次合并）可能引入数值误差；需验证。(6) <strong>'看起来能合并'但实际无效</strong>——某些能力的合并没有实际意义（如两个高度相似的任务，合并后与单个相当）；需与'单任务'基线对比。<strong>最佳实践</strong>——(a) <strong>保存所有原件</strong>（基座 + 各适配器）以便回溯与重合并；(b) <strong>建立评估矩阵</strong>（每个合并配置 × 每个任务的表现）；(c) <strong>用留出集调 λ</strong>；(d) <strong>记录完整元数据</strong>；(e) <strong>优先少量任务合并</strong>（任务越多干扰越大）。

深度剖析与工程权衡：① <strong>'平均分掩盖此消彼长'是评估的经典陷阱</strong>——必须逐任务报告；这是'多任务评估'的基本纪律。② <strong>'基座一致性'是硬约束</strong>——不同基座的向量无法合并；故版本管理至关重要（工程上常用'基座哈希 + 适配器元数据'）。③ <strong>'版本管理'是大规模 PEFT 的实际痛点</strong>——N×M 的组合容易混乱；故需 (a) 严格的命名规范、(b) 元数据记录、(c) 自动化评估。④ <strong>'用评估集调 λ'会高估</strong>——这是常见错误；应用<strong>留出集</strong>调参、<strong>测试集</strong>报告。⑤ <strong>'与单任务基线对比'不可省略</strong>——否则无法判断合并'是否值得'（可能不如直接用单任务模型）。⑥ <strong>面试要点</strong>——被问'合并怎么评估'，应给出'<strong>逐任务（防此消彼长）+ 通用能力回归 + 鲁棒性 + 与单任务/集成对比</strong>'与'<strong>风险（干扰/基座不一致/版本管理/评估泄漏）</strong>'；能指出'平均分会掩盖此消彼长'与'基座一致性是硬约束'是深度理解的标志。