企业官网建设流程全解析

大概半个月前，我接到一个看起来挺常规的任务：把几个在不同垂直领域微调过的大语言模型合并回一个统一模型，要求是各领域能力尽量不退化。听起来像是把几杯果汁倒进一个杯子，结果倒完之后我盯着评测曲线看了整整一个下午——生物医学问答掉了11个点，金融实体抽取掉了8个点，而代码生成居然还涨了2个点。这种“有人欢喜有人忧”的结果让我开始认真研究MergeBench，也就是这篇博文的主题：一个专门用来衡量“合并领域特化大语言模型”（Domain-Specialized LLM Merging）效果的基准测试。MergeBench解决的核心问题很简单，也很现实：当你有多个针对特定领域微调好的模型，如何把它们合到一起，同时保留各自的专业能力，以及这个合并过程是否真的可靠、可复现、可比较。

这篇文章我会从为什么模型合并成为一个刚需开始讲，然后拆解MergeBench到底在测哪些维度，再把我自己跑合并且用类似思路做评测的过程、踩过的坑、以及从结果里反推出来的经验全部写出来。适合谁看？一是正在做模型合并的算法工程师，二是想评估不同合并方案但不知道从哪下手的同学，三是对领域特化模型碎片化问题感兴趣的人。

1. 领域特化模型越堆越多，合并到底解决了什么问题

1.1 模型碎片化的真实场景

先还原一个典型的业务场景。某团队有一个开源底座模型，之后围绕四条业务线各微调了一份专属模型：金融方向的Fin-Lex，负责研报情感分析和实体抽取；生物医学方向的Bio-Read，负责文献问答和术语解释；代码方向的Code-Forge，负责补全与单测生成；客服方向的Agent-Intent，负责多轮意图识别。每份模型都是在一个通用底座上继续训练得到的，效果也确实好，单领域评测都碾压底座。

但麻烦也跟着来了。一份模型对应一份服务，四个模型就是四条推理链路，每个都需要独立的显存、独立的部署脚本、独立的更新流程。更麻烦的是，线上流量不是按领域平分的——某天金融查询特别多，另外三个模型的算力都在空转。这种“模型碎片化”带来的资源浪费和运维复杂度，很多做垂直模型落地的团队都深有体会。

1.2 合并，凭什么和继续训练、蒸馏、MoE放在一起比

面对碎片化，常规思路无非四条。第一，把四个领域的训练数据拼起来，继续训练一个统一模型，但这要求数据还能被合规访问，且训练成本高；第二，做知识蒸馏，用四个专家模型分别蒸馏给一个学生模型，同样需要访问数据和额外训练；第三，做成MoE架构，保留四个专家加路由，但推理时的显存开销和复杂度并没有真正降下来；第四，就是参数合并，直接把四个微调后的模型“在参数空间里”融合成一个，不需要原始数据集，也不需要重新训练。

MergeBench真正关注的就是第四条路。参数合并之所以诱人，是因为它有几个硬优势：数据不落地，保护隐私；合并过程比训练便宜几个数量级；模型结构不变，部署链路不用动。但同时它也有一个致命的不确定性——合并后的效果非常依赖方法、超参数和模型之间的“兼容性”。MergeBench的价值，就是把这团不确定的东西变成一套可以横向对比的量化指标，让你在做选择之前先看到证据。

2. MergeBench的评测蓝图：到底在测哪些能力

2.1 领域模型池与任务集合怎么搭

MergeBench的第一步是定义“合并测试环境”。它选择了一个清晰的范式：先固定一个底座模型，在若干领域上用可控的数据微调出一组专家模型，构成领域模型池。领域数量通常为4到6个，太少体现不出冲突，太多又会让评测成本爆炸。每个专家模型都是严格基于同一底座，使用固定比例的领域数据训练，确保它们之间的差异只来自“领域数据”，而不是训练设置。

任务集合的构建也有讲究。它不会只拿一个大而全的通用benchmark来测，因为那测不出“领域特化”的价值。更合理的做法是为每个专家模型配备两个层面的评测集：一个是该领域的核心能力测试，比如金融模型的实体边界识别和情感极性判断；另一个是跨领域干扰测试，比如金融模型在做完合并后会不会在通用常识上崩掉。这套组合拳的目标是，既测“合并后你还行不行”，也测“合并后你变没变傻”。

2.2 三个评测维度：能力保持、冲突消解、分布外泛化

MergeBench把合并质量拆成了三个可量化维度。

第一个维度叫能力保持率，计算方式是合并模型在专家领域测试集上的得分，除以原始专家模型在同一测试集上的得分。保持率接近1，说明这个合并方法几乎没有破坏领域能力；低于0.85，基本可以判定合并失败。

第二个维度是冲突消解率。多个领域模型合并时，参数更新方向经常互相打架，甲领域要往东调某个权重，乙领域要往西调。MergeBench会统计这类参数冲突的强度，并观察合并算法到底能消解多少冲突。你可以把它理解成“合群程度”：两个能力都强但个性都拧的模型，合起来往往谁都不服谁。

第三个维度是分布外泛化。这一点不是直接测合并模型的平均分，而是看它在训练时没见过的邻近任务、换个提示模板、或者轻微变形的输入下，能不能依然保持稳定输出。合并如果只是简单地把权重平均，很容易在分布内表现尚可、分布外迅速退化。MergeBench特意加这个维度，是为了防止某些方法“背答案”。

2.3 控制变量与防泄漏设计

做基准测试最容易死在数据泄漏上，MergeBench在设计时对这个问题的处理值得借鉴。它要求领域专家模型在微调时使用的训练数据、合并后调超参数用的验证数据、最终打分的测试数据三者严格隔离。如果测试集里的某一题曾经出现在某领域模型的训练语料里，那这个得分就是虚高的。

另一个被很多自建评测忽略的点是提示模板的均衡。不同领域任务原本就有不同的提示风格，代码补全用纯文本，金融抽取用带标签格式，问答用生成式。如果任其自然，合并模型可能只是学会了“适配某个领域的数据格式”，而不是真正学到了领域知识。MergeBench会为每个任务固定一套统一的、与领域无关的评测模板，再额外保留一组异质的提示变体，专门用来衡量格式敏感性。这个细节，直接决定了基准结果的代表性。

3. 从任务向量到稀疏编辑：合并方法在MergeBench下的表现规律

3.1 权重平均为什么在多数场景下表现平庸

所有合并方法都有一个共同的起点：简单权重平均，也就是把所有专家模型的参数逐元素取均值。这个基线实现起来只有几行代码，但效果往往很平庸。原因在于，神经网络参数空间中存在排列对称性——两个结构相同但训练路径不同的模型，可能功能上等价，参数摆放位置却完全不同。直接把参数逐位相加，相当于把两本内容相同但排版不同的书硬叠在一起，字是叠上了，行却对不齐。

权重平均还有一个隐藏问题：各专家的“音量大”程度不一致。某个在大量数据上训练过的金融模型，其参数相对底座的偏移量可能远大于某个数据量少的客服模型。等权平均之后，嗓门最大的专家会主导最终模型，其余领域的能力被稀释。MergeBench的评测里经常能看到这个现象——一份看起来平均分尚可的报告，细看每个领域分数方差极大。

3.2 任务向量家族：TIES与DARE在干什么

权重平均不够好，于是研究者把目光转向“任务向量”。所谓任务向量，就是专家模型参数减去底座模型参数得到的差值，捕捉的是微调带来的“定向变化”。合并过程就变成：底座参数加上所有任务向量的加权和。这等于把“合并模型”从“直接调和参数”转化成“叠加更新方向”，逻辑更清晰，也能分离出每个领域到底改了哪些参数。

TIES-Merging在此基础上做了三件事：裁剪、符号表决、归一化合并。第一步把每个任务向量中幅度最小的部分剪掉，保留有实质贡献的参数；第二步对每个参数位置，看保留的任务向量里正负更新方向哪个占多数，让次要方向服从主要方向；第三步只把符号一致的任务向量做加权平均。这套流程后来被很多工作验证是稳的，它的核心思想是：冲突不是用来强解的，而是先让少数派让步。

DARE的思路则更激进。它发现微调后的任务向量里，绝大多数参数都是冗余的，于是随机丢掉不少比例的更新量，再把剩下的部分按比例放大，最终合并。从MergeBench报告看，DARE在任务向量本身比较稀疏时效果很好，但如果两个专家模型的更新都密集且冲突严重，随机丢弃会让关键参数也被误伤。所以它更适合“微调幅度小、更新集中”的场景，全参微调的专家模型直接套DARE，效果往往会掉。

3.3 我观察到的共性规律

把MergeBench公布的方法横向看完，能抽出几个不太好听但很真实的规律。

第一，没有普世最优解。每个合并方法都有自己适合的“冲突光谱”。轻量微调的模型之间，DARE和简单任务向量加权就很够用；全参微调且领域差异大的模型，TIES这类带冲突消解的会明显更稳。第二，平均分是最会骗人的指标。有的方法平均分很高，但因为直接把某个专家能力给牺牲掉了，放到实际业务里根本不可用。MergeBench的价值恰恰在于把这种“偏科”暴露出来，而不是用高均分掩盖。第三，合并基线之间的差距，远小于“合并方法选错”的差距。也就是说，只要先选对方向——是用任务向量还是稀疏编辑——比事后调参重要得多。

4. 实操：搭建一套可复现的MergeBench式评测流程

4.1 最小可行的实验配置清单

读基准是一回事，自己搭一套能跑的评测流程是另一回事。我基于类似思路搭过一版简化版MergeBench，下面给出最小可行配置，可以直接复用。

模型池建议4个专家模型加1个底座，全部用同一种微调方式，LoRA或全参二选一，不要混用。混用会导致任务向量幅度不可比。领域的选取尽量拉开差异，我这边选了金融、生物医学、代码、客服四类，结构差异越大，越容易暴露方法的缺陷。每个专家模型的评测集按7比2比1切分，7成做微调训练，2成做合并参数选择，1成做最终测试。评测指标统一用准确率和生成式F1，不混用不同体系的分数。

合并时固定一套流程：加载底座模型，逐个加载专家模型的LoRA权重，把它们合并进主权重并保存；对全参微调模型则直接计算任务向量。基线至少跑三个——朴素权重平均、任务向量加权、TIES——再加一个你真正想验证的新方法，一共四个。每种方法在验证集上选择一个最优合并系数，例如在0.1到0.9之间以0.1步长搜一次。最后在测试集上跑三次随机采样，报告均值加减标准差。

4.2 合并后评测最容易踩的三个坑

每个坑我都亲自踩过，写出来供绕行。

第一个坑是分词器不一致。很多微调代码为了适配领域，会扩展词表或调整特殊tokens。合并之前如果不做对齐，模型参数的embedding矩阵尺寸都对不上，直接报错还算是客气的，更惨的是不报错、静默产生乱码输出。处理办法是合并前统一强制使用底座的tokenizer配置，任何领域新增的token都要映射回原有词表，实在映射不了就把对应embedding行置零并在后续微调中冻结。

第二个坑是RMSNorm或LayerNorm的数值尺度敏感。现代底座模型很多用RMSNorm，这类归一化层的缩放参数对平均操作非常敏感。两个专家的Norm权重差一点，直接平均后整个隐藏状态的尺度都会漂移。我的做法是把归一化层单独隔离出来，不参与任务向量计算，保留底座的原始值；如果非合不可，也至少要做逐层归一化后再加权。

第三个坑是评测时的解码参数不一致。合并模型和专家模型在生成式任务上的输出分布差异，会被temperature和top-p的细微差别放大。你可以想象两个模型同一题给出差不多的候选答案，一个采样模式选到A，另一个选到B，最终分数差很多，但这不是合并的锅。控制变量之后我才发现，有些合并方法看起来崩了，其实是解码配置不合适。

4.3 结果解读：别只看平均分

从评测结果里找规律，比跑出数字本身难得多。我的习惯是每次结果出来先看三个东西。

第一是看最差领域分。合并模型的最低单项能力，往往决定了业务上能不能上线。平均分再高，金融实体抽取掉到不可用水平，这个合并就是失败的。第二是看方差。同一合并方法跑三次，如果标准差超过两个点，说明它对初始化或采样顺序敏感，这种不稳定本身就是风险。第三是看验证集和测试集分数差。验证集用的合并系数，在测试集上如果性能出现断崖式下跌，说明合并已经过拟合到了验证分布，这时候要回头检查是不是优化过度。

我曾经认为某个新合并方法效果惊艳，平均分比TIES高了将近3个点。结果按最差领域一看，客服意图识别直接崩了13个点。原因是这个方法天然会把“少数服从多数”做到极致，弱领域在更新方向上完全被其他三个领域淹没。这个教训被记进团队文档里之后，后来所有合并方案报告都强制附最差领域分析。

5. 从评测结果反推训练侧的改进思路

5.1 微调方式对合并成功率的影响

MergeBench这类基准带来的一个反直觉结论是：合并效果好不好，不只是合并方法决定的，从微调那一刻就已经决定了。

全参微调得到的专家模型，参数更新分散在整个权重矩阵里，且不同专家的更新方向高度独立，合并时冲突概率大。LoRA微调则天然把更新限制在低秩子空间，各家专家的任务向量“方向”更容易对齐。在MergeBench式的控制变量实验里，LoRA微调的专家模型在合并后的平均保持率，通常能比全参微调高出几个点。这个差距在稀疏合并方法下尤其明显，因为只有低秩的更新量才容易被裁剪并保留主干。

但这不意味着LoRA一定更好。LoRA的秩和alpha选择会影响任务向量的幅度。我用同一个领域数据微调了两次，一次秩16、一次秩64，合并后后者在领域保持率上明显占优，因为可学习的参数多，表达能力更接近全参微调，同时仍保持了低秩带来的方向一致性。

5.2 合并系数超参数比你想象的更敏感

合并系数是实验里最被人忽视、又最容易翻车的旋钮。任务向量加权公式里的那个lambda，其取值直接决定“专家模型经验”和“底座通用能力”之间的天平往哪边倒。lambda偏小，合并模型趋于底座，数据量少的领域能力会消失；lambda偏大，合并模型趋于专家叠加，可能变得过拟合且通用能力下降。

我的经验是，不同的领域适合的lambda区间可能完全不同。金融专家数据量大、更新稳定，可以承受更大的lambda；客服专家数据量小，稍微加一点就过拟合。如果所有领域共用一个系数，那最后一定有人吃亏。别人在评测时也会观察到：最优lambda通常落在0.3到0.6之间，但在这个区间内，每变化0.1，某些领域的分数就能波动3到5个点。所以每次合并实验，验证集上的系数搜索网格必须记录下来，否则结果无法复现。

5.3 向多语言与多模态扩展时要注意什么

MergeBench的思路有很强的扩展性，但在非纯文本场景下，需要额外增加注意事项。

多语言场景最核心的问题是词表覆盖不均匀。某些语言在底座词表里本来token就少，微调后新增的token会造成embedding矩阵扩张，不同语言专家模型合并时，矩阵尺寸不一致的概率极高。这要求基准对“允许扩展词表”的动作单独设一个维度，否则结果会被对齐操作本身干扰。

多模态场景的问题则在模块边界。语言模型那头合并好了，视觉编码器那头还各自为政，这算合并成功还是失败？一套可信的评测要明确划定合并范围，是只合语言层，还是语言层加视觉塔一起合。我个人倾向于先合语言层并冻结视觉编码器，实验结果会稳定很多。你可以在模型池里同时放两个不同视觉塔的变体，这样评测还能看出“模块间兼容性”对合并质量的影响，这比单纯看总分会更有参考价值。

6. 最后聊几句心得体会

我最近这次合并实验最终选定的是基于TIES的变体，并配合逐领域独立的合并系数，最终把生物医学问答的掉点从11个点收窄到3个点以内，金融实体抽取保持率恢复到0.94。这个过程谈不上惊艳，但它让我对MergeBench这类基准产生了很大的信任感。它教会我的最重要的一件事是：模型合并不是炼丹，它更像拼乐高，先看零件之间的咬合方式，再想怎么用力，比你用再多蛮力都重要。

最后可以分享一个很小的技巧：在正式评测之前，花十分钟做一次“冲量测试”——把两个差异最大的专家模型合并，然后跑十几个典型样例，人工看一眼输出的logit分布是不是正常。这个粗糙的冒烟测试能在正式跑评测前帮你筛掉九成以上的配置错误。模型合并本身不复杂，但它的可复现性、可控性比大多数人想象的要更讲究，有了MergeBench这样能横向比较的尺子，这个方向才算真正进入可以工程化的阶段。